Что показал мой эксперимент:

• ИИ-агент Ника действительно совершала действия в реальном мире: купила авиабилет, регулярно покупала мне кофе, забронировала гостиницу, столики в ресторанах «Сахалин», «Воронеж», EVA и других, и даже русскую баню в Дубае…

• В моих тестах главным ограничением стали внешние интеграции: на инструменты, MCP и API приходилось 94% зафиксированных ошибок – именно ошибок, а не всех задач. Готовность внешних сервисов стала одним из главных ограничений.

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

• Агенты и автоматизация нужны по обе стороны услуги: после двадцати звонков Ники в ресторан «Сахалин» её номер заблокировали. Массовое использование персональных агентов потребует способов обработки запросов, которые не перегружают сотрудников: API для бронирования, автоматического подтверждения или собственных агентов на стороне поставщика.

• Агент (в моем случае - Ника) уже может выполнять регулярные поручения без повторных команд (и работать 24/7): я один раз попросил Нику покупать кофе по расписанию, и она повторяла покупки без моего участия. Так дома накопился запас примерно на год. Именно это я и проверял: сможет ли агент возвращаться к поручению и выполнять его снова и снова.

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

Для этих экспериментов я участвовал в разработке ии-агента “Ника”. Ниже – мой опыт работы с системой: покупка авиабилета, регулярные заказы кофе, звонки в гостиницу и рестораны, заявки через браузер. Для каждого кейса покажу ход выполнения и полученный результат.

Все покупки, звонки и бронирования в этой статье выполняла облачная версия агента. У проекта есть и десктоп для macOS с on-device LLM: в локальном режиме доступны диалог, работа с переданным текстом и память. Техническое описание и скриншоты локальной части – ниже, ссылка на исходный код – в конце.

Предыстория: от диалога к поручениям

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

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

Для этого я подключил около 200 MCP – геосервисы и карты, путешествия и отели, маркетплейсы, доставку еды, поиск и другие направления, – а для сервисов без подходящей интеграции дал Нике браузер, телефон и собственные аккаунты в Telegram и WhatsApp. В разговорах и переписке она всегда представлялась моим ассистентом: «Здравствуйте, я ассистент Никиты, звоню, чтобы забронировать столик».

Так выглядел веб-интерфейс, через который я задавал часть поручений:

Ниже собраны отдельные случаи из серии тестов. Они показывают конкретные возможности и ограничения.

Кофе по расписанию: поручение выполнено, запас растёт

В одном российском магазине я настроил через Нику покупку кофе: раз в два дня, по утрам.

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

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

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

Покупка авиабилета: от выбора рейса до оплаты

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

В этом случае Ника прошла оформление на сайте авиакомпании, и билет был куплен. На записи – работа браузерного агента с этим сценарием:

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

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

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

Браузерные задачи: конфигурация сервера и подбор ПК

Ещё два примера показывают действия в браузере, которые заканчиваются до оплаты.

Конфигурация сервера в Yandex Cloud. Ника открывала калькулятор, выбирала ресурсы, собирала конфигурацию и рассчитывала стоимость. Результат – подобранная конфигурация с расчётом стоимости.

Подбор компьютера в «М.Видео». Агент работал с сайтом магазина и подбирал комплектующие для сборки ПК. На записи показан этап подбора товаров без перехода к оплате.

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

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

Телефонные тесты: Ника бронирует столики

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

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

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

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

Гостиница во Владимире: когда без звонка не обойтись

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

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

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

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

В этом кейсе голосовой канал позволил агенту выполнить задачу там, где не было онлайн-бронирования. Нике пришлось взаимодействовать с людьми и договариваться по телефону – именно так, как это сделал бы я сам.

От звонка к форме бронирования: пример EVA

У бронирования есть и другой путь: вместо разговора с администратором агент может работать с сайтом. Такие сценарии тоже вошли в тесты.

На сайте ресторана EVA Ника сама открывала страницу и заполняла форму заявки:

В результате ресторан подтвердил бронирование столика. На GIF показана браузерная часть этого сценария: Ника открывает сайт и заполняет форму. Здесь поручение было выполнено через сайт ресторана.

Когда на звонок отвечает другой агент

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

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

Баня в Дубае: заявка перешла из браузера в WhatsApp

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

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

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

Что показала работа с внешними интеграциями

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

Внешние интеграции стали главным ограничением в моей серии тестов. Эта доля описывает результаты работы с подключёнными инструментами и сервисами в рамках эксперимента; она не является оценкой всего рынка.

Рабочую систему нужно оценивать целиком: от поручения до подтверждённого результата. В неё входят модель, harness – логика выполнения задач и работы с инструментами, – сами инструменты и внешние сервисы.

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

Что я вынес из этих экспериментов

• Агент может выполнять регулярные поручения без повторных команд и работать фоново 24/7. Заказы кофе по расписанию работали. Для таких задач важно заранее задавать частоту, бюджет и условия остановки.

• Клиентский путь может проходить через несколько каналов. Заявка на сайте и дальнейшее общение в WhatsApp должны оставаться одной задачей с общим контекстом и статусом.

• MCP-интеграциям нужны понятные критерии завершения. Агент должен различать «заявка отправлена», «оплата прошла» и «бронь подтверждена». Важно, какую часть задачи покрывает интеграция и как она подтверждает результат.

• Права на оплату нужно задавать явно. Лимиты расходов, правила подтверждения, защита реквизитов и предотвращение повторных списаний – часть устройства платёжного сценария.

• Автоматизация нужна по обе стороны услуги. Двадцать звонков в «Сахалин» закончились блокировкой номера Ники. Чтобы обслуживать запросы агентов без перегрузки сотрудников, сервисам понадобятся API или собственные агенты для оформления, подтверждения и отмены бронирований.

• В моих тестах главным ограничением стали внешние интеграции. На инструменты, MCP и API приходилось 94% зафиксированных ошибок – именно ошибок, а не всех задач. Это показывает, насколько для массового использования агентов важны зрелость подключённых сервисов и качество интеграции с ними.

Техническое приложение: что доступно с on-device LLM

Облачные эксперименты выше и локальная работа с моделью – разные части системы. В открытом десктопе для 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. Локальные LLM. Качество ответов, скорость и потребление памяти на одинаковых задачах.

3. Harness, tools и MCP. Где возникает ошибка, как её локализовать и когда повторная попытка может навредить.

4. Память и долгосрочные задачи. Как сохранять контекст, задавать условия остановки и проверять выполнение через дни и недели.

Какой разбор был бы полезнее? Если у вас есть опыт тестирования агентов на реальных сервисах, интересно узнать, как вы проверяете результат и ограничиваете последствия повторных действий.