Как работает ИИ-агент: путь от события до действия

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

Шаг 1. Получить событие

События приходят разными способами:

• webhook сообщает об изменении сразу;
• polling регулярно запрашивает новые объекты;
• пользователь загружает файл или отправляет сообщение;
• планировщик запускает проверку по времени.

Webhook не всегда лучше. В Avito-проекте DOLOROSA мы использовали опрос новых чатов. На аккаунте уже были сторонние подписки, а бизнес-правило требовало паузу перед ответом. Для YCLIENTS webhook оказался полезен, чтобы получать изменения записей и обновлять локальную память.

Шаг 2. Собрать контекст

Входное сообщение редко содержит все данные. Фраза «он ещё есть?» понятна только вместе с объявлением. «Запишите вечером» требует услуги, филиала, даты и расписания.

Контекст надо собирать из источников с понятным приоритетом. В DOLOROSA наличие приходит из МойСклада, а цена для разговора в Avito берётся из объявления. Это правило появилось после сравнения данных: одна карточка могла содержать другую сумму.

Полезно хранить не только значение, но и происхождение:

{
  "fact": "price",
  "value": "из контекста объявления",
  "source": "avito_chat_context",
  "checked_at": "request_time"
}

В публичном журнале настоящие значения и идентификаторы заменяются обезличенными примерами.

Шаг 3. Выбрать инструмент

Модель получает список функций и их контракты. Например:

check_stock(product_id) -> in_stock | sold | unknown
find_slots(branch_id, service_id, date) -> slots[]
escalate(reason, context_ref) -> ticket_id

Чем уже инструмент, тем легче проверить вызов. Функция solve_everything() скрывает ошибки. find_slots() имеет понятные аргументы и результат.

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

Шаг 4. Выполнить действие

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

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

• idempotency key, если его поддерживает API;
• сохранение внешнего ID результата;
• проверка состояния перед повтором;
• запрет автоматического retry для неоднозначной операции.

В YCLIENTS-проекте безопасные GET-запросы повторялись, а book_record по умолчанию не отправлялся повторно после неопределённого сбоя. В Avito перед повторной отправкой сообщения канал перечитывал чат и искал уже доставленную собственную реплику.

Шаг 5. Проверить результат

HTTP 200 ещё не доказывает бизнес-результат. Нужно проверить, что в ответе есть ожидаемый объект, его ID сохранён, а целевая система показывает нужный статус.

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

Шаг 6. Ответить или передать человеку

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

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

В Telegram-хабе DOLOROSA каждый диалог Avito получил отдельную тему. Менеджер видел контекст и мог продолжить разговор без копирования переписки.

Шаг 7. Оставить след для разбора

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

Такой журнал помогает отличить ошибку модели от отказа API, нехватки прав или неверного правила. Например, HTTP 403 в YCLIENTS был связан с ролью технического пользователя, а не с промтом.

Проверка перед запуском

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

Если у вас есть конкретный процесс, Geron Labs может разложить его на события, источники, инструменты и проверки до оценки разработки.

Читайте также: Что такое ИИ-агент и какие задачи он может выполнять в бизнесе, Как настроить данные, инструменты, память и эскалации ИИ-агента, Как подключить ИИ-агента к Avito через API.

Источники

• YCLIENTS, webhooks: support.yclients.ru/993 (проверено 28.09.2026).
• МойСклад, JSON API: dev.moysklad.ru/doc/api/remap/1.2/ (проверено 28.09.2026).