Настройка ИИ-агента состоит из четырёх отдельных работ: определить источники правды, дать модели узкие инструменты, сохранить состояние процесса и описать случаи передачи человеку. Промт связывает эти части, но не заменяет их. Цена, остаток, запись или статус заказа должны подтверждаться кодом и целевой системой. Память хранит нужное для продолжения процесса, а журнал позволяет понять, почему агент вызвал инструмент или остановился.
Данные: один факт, один источник
Сначала составьте таблицу фактов:
| Факт | Источник | Срок актуальности | Что делать при пустом значении |
|---|---|---|---|
| Цена в Avito | контекст объявления | на момент диалога | передать менеджеру при конфликте |
| Остаток | МойСклад | live-проверка | не обещать наличие |
| Свободное время | YCLIENTS | на момент запроса | предложить другую дату |
| Состояние вещи | карточка товара | до следующего осмотра | попросить проверку |
Такая таблица полезнее длинного списка общих правил. Она показывает, где модель не имеет права дополнять пробел.
Инструменты: минимальные функции вместо полного API
Не передавайте модели произвольный HTTP-клиент. Создайте функции под рабочие действия:
get_listing_context(chat_id)
check_stock(product_id)
find_slots(branch_id, service_id, date)
create_booking(confirmed_payload)
handoff(reason, context_ref)Каждая функция проверяет аргументы, ставит таймаут и возвращает структурированный результат. Ошибка доступа должна отличаться от пустого списка. Timeout при записи должен отличаться от подтверждённого отказа.
Память: хранить состояние, а не всё подряд
Память нужна, чтобы процесс продолжался после следующего сообщения или перезапуска. Для диалога полезны выбранный товар, этап уточнения, ID внешней операции и признак ответа менеджера.
Сырая история всех сообщений не всегда нужна. Она увеличивает риск утечки и мешает модели. Лучше сохранять проверяемые факты и ссылку на исходный контекст. Персональные данные хранятся только там, где это необходимо процессу и разрешено политикой клиента.
В DOLOROSA SQLite хранил обработанные сообщения и собственные отправки. При старте действовало окно, которое не позволяло внезапно ответить на старые диалоги. В EST.EPIL локальная память обновлялась из событий CRM, но доступ к истории зависел от прав технического пользователя.
Эскалации: нормальный маршрут
Для каждой операции заранее задайте причины остановки:
- идентификатор объекта не определён;
- обязательного факта нет в источнике;
- два источника противоречат друг другу;
- пользователь просит исключение из правил;
- API вернул отказ доступа;
- результат записи нельзя подтвердить;
- сотрудник уже включился в диалог.
Эскалация должна создавать наблюдаемое действие: тему в Telegram, задачу в CRM или карточку в очереди. Фраза агента «я позвал менеджера» без реального уведомления является ошибкой.
Prompt: короткие правила вокруг инструментов
Инструкция модели описывает роль, допустимые действия, правила выбора инструментов и формат ответа. Бизнес-ограничения, которые влияют на деньги или запись, дублируются кодом.
Плохое правило: «всегда будь точным».
Проверяемое правило: «не называй наличие до успешного check_stock; при unknown вызови handoff и не обещай резерв».
Мониторинг
Минимальный журнал содержит:
- ID события в обезличенном виде;
- выбранный инструмент;
- длительность и класс результата;
- код проверки;
- причину эскалации;
- ID внешнего результата, если операция состоялась.
Отдельно нужны счётчики повторов, неоднозначных таймаутов и ответов человека. Текст клиента и токены не стоит дублировать в технических логах.
Набор проверок
До запуска проверьте обычный сценарий, пустой результат, неверный ID, 401/403, 429, timeout, повтор события и перезапуск процесса. Для каждого случая должно быть понятно, что увидит клиент и что увидит сотрудник.
После этого запускается теневой режим. Только по его результатам стоит решать, какие действия можно перевести в автоматический режим, а какие оставить на подтверждении.
Для технического разбора Geron Labs достаточно одного рабочего сценария и доступа к документации систем. Мы собираем карту источников, прав и ошибок до того, как выбирать модель или интерфейс.
Источники
- YCLIENTS, доступ к API: support.yclients.ru/67-68-199--dostup-k-api/ (проверено 28.09.2026).
- МойСклад, JSON API: dev.moysklad.ru/doc/api/remap/1.2/ (проверено 28.09.2026).