Привет! Я Вика, занимаюсь исследованиями в ИИ и хардкорным продом: внедрением ИИ в крупные продукты, работой с большими корпоративными данными и оптимизацией инференса моделей на GPU-кластерах. В этот раз я несколько недель проверяла, какие обычные дела в физическом (!), а не только в цифровом мире можно поручить агенту: позвонить и договориться с реальным человеком (как и многие, очень не люблю звонить по телефону…), купить билет на самолет, заказать кофе или еду, забронировать гостиницу.

За время тестов у меня дома накопился кофе примерно на год, а номер Ники, моего ИИ-агента, попал в черный список нескольких ресторанов. Еще Ника сама купила авиабилет, забронировала гостиницу, регулярно бронировала столики в ресторанах, подобрала комплектующие для ПК и отправила заявку в баню в Дубае :)

В предыдущем посте я рассказывала о самоорганизации ИИ-агентов. Это исследование вдохновило меня сделать собственный харнесс для агента и протестировать его в реальной жизни на реальных задачах. Здесь разберу устройство эксперимента и конкретные задачи: что получилось выполнить, сколько усилий это потребовало и где агент застрял.

Как был устроен эксперимент

Первые тесты мы начали в мае 2026 года. Для них разработали ИИ-агента с собственным харнессом, который управлял моделями, вызовами инструментов и выполнением задач.

Подключили к Нике 294 инструмента, в том числе API известных российских сервисов: карты, поиск, путешествия, маркетплейсы, доставка еды, и многое другое. Конечно, небезызвестный MCP ВкусВилла тоже вошел в этот набор :) Подключали инструменты и MCP-серверы, до которых удавалось добраться. Для некоторых интеграций пришлось прибегнуть к реверс-инжинирингу.

Для решения задач агенту были доступны 10+ LLM через наш GPU-кластер с собственным инференсом и двух внешних провайдеров. Ника сама выбирала модель с учетом сложности задачи, стоимости, скорости, доступности и текущей нагрузки у провайдеров. Поэтому одна и та же задача в разное время могла уйти разным моделям.

Нике дали банковскую карту, несколько SIM-карт с ИИ-звонилкой, браузерного агента, собственную почту и аккаунты в Telegram и WhatsApp

Браузерного агента и ИИ-звонилку с несколькими SIM-картами подключили именно как обходной путь для случаев, где нет подходящего API/MCP. Если подходящего API не было, она могла открыть сайт, позвонить или написать человеку. В разговорах и переписке всегда представлялась ассистентом и объясняла, с какой задачей пришла.

Все покупки, звонки и бронирования в этой статье выполняла облачная версия Ники. Локальный режим приложения для macOS, где доступны диалог, работа с текстом и память на компьютере, разберу ниже в технической части.

Свои задачи агенту я писала обычными сообщениями в чат. Вот веб-интерфейс, через который проходила часть тестов:

В этой статье собрала отдельные случаи из серии тестов.

Кофе раз в два дня

В одном российском магазине я настроила через Нику покупку кофе: раз в два дня, по утрам. Хотела проверить, будет ли она возвращаться к задаче сама, без нового сообщения от меня. По-сути, это тестирование простого примера “фонового” режима работа агента.

Ника сама оформляла и оплачивала заказы. Раз в два дня мне привозили несколько пачек кофе прямо к двери квартиры. Напоминать о покупке или заново запускать задачу не приходилось. К концу эксперимента дома накопился запас, которого, по моей оценке, хватит примерно на год.

Моя задача выглядела так:

На этом примере хорошо видно, зачем регулярной задаче нужны условия остановки. Указать частоту покупки мало: стоит сразу задать бюджет и момент, когда заказы нужно прекратить. Иначе исправно работающий агент продолжает покупать кофе.

Авиабилет с оплатой

Еще я попросила Нику купить мне авиабилет и дала ей доступ к браузеру и своей банковской карте. Нужно было найти рейсы, выбрать подходящий вариант, заполнить данные пассажира и оплатить билет.

Ника прошла оформление на сайте авиакомпании. Билет был куплен и оплачен. На записи видно, как она работала в браузере:

Основные этапы оформления авиабилета

На коллаже собраны поиск, выбранные рейсы, заполнение данных пассажира и переход к оплате.

Конфигурация сервера и сборка ПК

Не каждое поручение должно заканчиваться покупкой. В этих двух тестах я проверяла работу с сайтами до оплаты.

В Yandex Cloud Ника открывала калькулятор, выбирала ресурсы и собирала конфигурацию сервера с расчетом стоимости. На сайте «М.Видео» подбирала комплектующие для ПК. До покупки в обоих случаях мы не доходили.

Демо: конфигурация сервера и подбор комплектующих

Здесь результатом были подобранные варианты. Для задачи «собери конфигурацию» этого достаточно. Для задачи «закажи компьютер» на этом месте работа только начинается.

Сто звонков в рестораны и бан :)

Голосовые сценарии мы проверяли на бронировании столиков. Давали Нике задачи на разные имена и время, она звонила, а мы смотрели, чем закончился разговор. Всего набралось больше ста тестовых звонков, в том числе в «Сахалин» и «Воронеж».

В «Сахалин» Ника позвонила двадцать раз. После этого ее номер заблокировали. Некоторые другие рестораны тоже добавили его в черный список.

Часть бронирований пригодилась участникам тестов, остальные мы отменяли. Перед сотрудниками ресторанов хочу извиниться за лишние обращения. Спасибо, что помогли нам проверить, как это работает, хотя для вас это были дополнительные звонки посреди рабочего дня.

У агента нет проблемы сделать еще один звонок. У администратора, которому на него отвечать, рабочее время все-таки ограничено. Если персональных агентов станет много, ресторанам понадобятся API для бронирования или собственные агенты, которые смогут принять запрос, подтвердить столик и отменить бронь.

Гостиница во Владимире и «Галя, мне бот звонит!»

В июле я ездила на Летний фестиваль Дениса Мацуева в Суздале, который проходил с 10 по 19 июля 2026 года. Для поездки мне нужна была гостиница во Владимире. У той, которую я выбрала, не было онлайн-бронирования. Оставался телефон.

Ника позвонила и забронировала мне номер. Но самое интересное я увидела потом, в расшифровке - примерно через двадцать секунд администратор поняла, что разговаривает с агентом, и позвала подругу:

«Галя, представляешь, мне бот звонит, бронирует гостиницу за человека!»

Девушки удивились, но разговор продолжили и бронь оформили. Если читаете это, спасибо, что разобрались с необычным звонком и помогли с бронированием!

В этой истории телефон оказался нужен по вполне практической причине: на сайте оформить бронь было нельзя. Без Ники мне пришлось бы звонить самой.

EVA: можно обойтись формой на сайте

С рестораном EVA получилось иначе. Ника открыла сайт и заполнила форму заявки на бронирование столика:

Ресторан подтвердил бронь. На GIF показано именно заполнение формы в браузере, сам факт отправки заявки еще не означал бы, что столик забронирован.

На другом конце тоже агент

Однажды на звонок Ники ответил ресторанный ИИ-агент Яндекса. Два агента обсудили задачу и договорились.

Это как раз вариант, при котором администратору не нужно лично отвечать на каждый запрос. Дальше мне интересно проверить, как в таком разговоре передавать условия бронирования и получать однозначное подтверждение результата.

Баня в Дубае: заявка на сайте, ответ в WhatsApp

Ника оставила на сайте заявку на бронирование русской бани в Дубае. Менеджер ответил в WhatsApp: подтвердил, что заявку получил, и уточнил дату посещения.

Окончательная бронь на этом этапе еще не была подтверждена. Задача началась на сайте, а продолжить ее нужно было в переписке. Агенту требовалось связать сообщение менеджера с исходным поручением пользователя и ответить на уточняющий вопрос. Одной отправкой формы такую задачу не закрыть.

Где возникали ошибки

В нашей серии тестов 94% зафиксированных ошибок были связаны с инструментами, MCP-серверами и внешними интеграциями. Речь именно о доле среди ошибок. Это не значит, что Ника провалила 94% задач. И переносить эту цифру на весь рынок я бы не стала: мы проверяли конкретную систему с конкретным набором сервисов.

Для меня это один из главных результатов эксперимента. Подключить много MCP недостаточно. Одна интеграция позволяет только найти товар, другая умеет оформить заказ, третья дает оплатить и получить подтверждение. По числу подключений не поймешь, сможет ли агент выполнить задачу целиком.

Поэтому я смотрю на всю цепочку: модель, harness (логику выполнения задач и вызова инструментов), сами инструменты и сервисы на другой стороне. Пользователю нужен купленный билет или подтвержденная бронь. Если до этого не дошло, удачный ответ модели сам по себе мало помогает.

Часть возможностей облачной Ники, связанных с покупками и оплатой, сейчас ограничена. Здесь я описываю ранние эксперименты; не все показанное доступно пользователям сегодня.

Что еще получилось в браузере и сколько это заняло

Кроме этих историй, мы отдельно проверяли браузерного агента на повседневных задачах: рассчитать доставку, собрать корзину, заполнить форму записи, найти вакансии. Вот несколько примеров из прогона 10 сентября 2026 года.

В этом наборе было 55 задач на живых сайтах, медианное время попытки составило 3,8 минуты. В расчет входят и успешные попытки, и неудачные; для последних указано время до остановки. Формы в этих тестах не отправляли, заказы не подтверждали и не оплачивали. Успех проверяли по состоянию страницы и выполнению условий задания.

Здесь показан один прогон на Qwen 3.8 27B, которая работала на нашем сервере с A100. Для браузера использовали доработанный Browser-Use. Замеры качества и скорости на других моделях могу собрать в отдельный пост.

Что я вынесла из этих тестов

Регулярные задачи уже работают без постоянных напоминаний. Можно один раз задать расписание, и агент будет выполнять задачу в фоне, в том числе круглосуточно. Но вместе с расписанием нужны ограничения: сколько тратить, когда остановиться и в каких случаях спросить меня.

С оплатой требований больше. Нужно заранее определить права агента, лимиты, правила подтверждения и способ защиты реквизитов. Отдельно предусмотреть повторные попытки: они не должны приводить к повторному списанию.

Еще я стала внимательнее относиться к слову «готово». Для бронирования за ним могут стоять три разных события: отправили заявку, внесли оплату или получили подтверждение. Агент должен их различать. Если сервис после заявки пишет в другой мессенджер, это продолжение той же задачи, с теми же датами и условиями.

И личные агенты довольно быстро упираются в то, как устроен сервис с другой стороны. Это видно и по блокировкам номера в ресторанах, и по ошибкам интеграций. Для следующих тестов мне важнее пройти конкретную задачу до конца, чем увеличить число подключенных MCP.

Что можно попробовать локально на Mac

Теперь про десктопную часть. В приложении для macOS есть интерфейс, локальные модели и память на компьютере. Облачный harness, телефонные и серверные интеграции в открытый релиз не входят. Покупки и звонки выше выполнялись в облачной версии.

В режиме on-device языковая модель работает на самом компьютере. После установки приложения и загрузки модели можно общаться с ней без облачного API и без интернета. Для скачивания моделей, облачного режима и обращений к внешним сервисам сеть нужна.

Под спойлером собрала интерфейс, модели и несколько запросов для локального режима.

Локальный режим: интерфейс, модели, память и примеры запросов

Интерфейс и помощники

В приложении можно выбрать локальный режим или войти в аккаунт для работы в облаке.

Отдельные помощники называются ботсами. Им можно задать имя, стиль общения и дополнительные инструкции. В локальном режиме их возможности зависят от выбранной модели, контекста и памяти.

Каталог моделей

В сборке, о которой я пишу, есть три варианта на базе Qwen3.5:

Модель	Параметры	Квантование	Размер файла
NIKA Mini (Qwen3.5-0.8B)	0,8 млрд	Q8_0	812 МБ
NIKA Balance (Qwen3.5-2B)	2 млрд	Q5_K_M	1,44 ГБ
NIKA Smart (Qwen3.5-4B)	4 млрд	Q4_K_M	2,74 ГБ
Сторонняя совместимая модель в GGUF; примеры для изучения: Gemma 4 12B, Qwen3.5-9B, gpt-oss-20b	Зависит от модели	Зависит от сборки	Зависит от модели и квантования

Для импорта GGUF нужно проверить, поддерживает ли движок архитектуру модели и хватит ли компьютеру ресурсов. Размер файла не равен расходу оперативной памяти: место потребуется еще для контекста и рабочих буферов.

Память

Информацию для следующих ответов можно сохранять на компьютере. Локальная память и память аккаунта в интерфейсе разделены. При проверке ответов стоит учитывать, какой режим выбран и какой контекст получила модель.

Разобрать фрагмент документа

Можно передать локальной модели текст и попросить:

Выпиши сроки, обязанности сторон и штрафы из этого текста. Для каждого пункта приведи подтверждающую цитату. Если информации нет, так и напиши.

Проверять такой ответ нужно по исходному документу: совпадают ли цитаты и следуют ли из них выводы модели.

Превратить заметки в план

Из этих заметок собери план доклада на десять минут. Выдели основную мысль, три аргумента и вопросы, для которых пока не хватает данных.

Здесь модель работает с заметками, которые вы ей передали. После загрузки модели можно отключить интернет и повторить запрос, чтобы проверить локальный режим.

Задать вопрос из другого приложения

Quick Ask открывает небольшое окно по настраиваемому сочетанию клавиш. В нем можно, например, попросить перевести фразу или разобрать абзац текста.

Где взять код и что получится повторить

Локальная часть опубликована в репозитории NIKA Desktop. В README описаны открытые компоненты, сборка и установка приложения для macOS из .dmg.

По этому коду можно изучить локальный диалог, работу с переданным текстом и памятью. Повторить облачные покупки и звонки только с помощью десктопного репозитория не получится, серверной части там нет.

Если будете сравнивать результаты локальных моделей, сохраните версию приложения, название модели и квантование, параметры запуска, конфигурацию компьютера, сам запрос и ответ. Без этих деталей трудно понять, откуда взялась разница.

Что разобрать дальше?

1. Браузерный агент. Как он работает с сайтами, на каких задачах ошибается и как меняются качество и скорость при смене модели.

2. Harness, tools и MCP устройство вокруг модели: выполнение шагов, работа с инструментами, проверка результата и повторные попытки после ошибок.

3. Агентная разработка: как мы переходим от прототипа к системе, которую можно проверять на реальных задачах в реальном мире.

4. Локальные LLM: сравнение качества, скорости и расхода памяти на одинаковых задачах.

5. Память и долгие задачи: что сохранять между запусками и как проверить выполнение через несколько дней.

Что вам интереснее? И если вы тоже тестировали агентов на реальных сервисах, расскажите, как проверяли результат и защищались от повторных действий.