Настройка ИИ-агента состоит из четырёх отдельных работ: определить источники правды, дать модели узкие инструменты, сохранить состояние процесса и описать случаи передачи человеку. Промт связывает эти части, но не заменяет их. Цена, остаток, запись или статус заказа должны подтверждаться кодом и целевой системой. Память хранит нужное для продолжения процесса, а журнал позволяет понять, почему агент вызвал инструмент или остановился.
Что настраивается вокруг модели
Данные
Источник каждого факта и поведение при пустом значении.
Инструменты
Разрешённые операции, типы аргументов и ограничения API.
Состояние
Этап обращения, внешние ID и уже выполненные действия.
Передача человеку
Причина остановки, собранный контекст и ответственный сотрудник.
Данные: один факт, один источник
Сначала составьте таблицу фактов:
| Факт | Источник | Срок актуальности | Что делать при пустом значении |
|---|---|---|---|
| Цена в 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 и проверять свободные слоты, Как работает ИИ-агент: путь от события до действия.
Источники
- 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).
Как это устроено в наших проектах
EST.EPIL: ИИ-администратор
Как Geron Labs связала сайт и Telegram EST.EPIL с YCLIENTS: актуальные цены, свободные окна, подтверждение записи и передача администратору.
DOLOROSA: Avito и Telegram-хаб
Как Geron Labs связала Avito, МойСклад и Telegram: ответы по конкретному товару, фото, события заказов и бесшовное подключение менеджера.
LISVENT: заявки и 1С
Как Geron Labs связала свободный текст заявки с номенклатурой 1С: файловый обмен, смысловой поиск, проверка моделей и подтверждение менеджера.
Если нужна такая автоматизация
Запись клиентов через YCLIENTS
Филиал, услуги, права приложения и пример сценария записи.
Состав работ и порядок пилотаКонсультант и хаб продаж
Пример диалога, источник остатков и правила передачи менеджеру.
Состав работ и порядок пилотаЗаявки, номенклатура и КП
Обезличенная заявка, справочник товаров и образец принятого результата.
Состав работ и порядок пилота