Как настроить ИИ‑агента: инструкция, данные и тестовые диалоги

Как настроить ИИ‑агента после первого работающего вызова модели? Начните с источников и прав. Прототип обычно умеет отвечать на вопрос. Рабочий агент должен знать, какой факт брать из базы, какие действия разрешены, когда звать человека и как проверить, что задача завершилась. Настройка текста инструкции занимает лишь часть работы. Основное время уходит на данные и тестовые случаи.

Сначала опишите одну роль

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

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

Роль: помощник по входящим вопросам о стяжке пола.
Цель: ответить по утверждённым сведениям и получить один нужный параметр.
Источник цены: только результат get_current_terms для этого объявления.
Если цена индивидуальна: запросить площадь и передать менеджеру.
При жалобе, просьбе о человеке или отсутствии данных: создать задачу человеку.
После принятия разговора менеджером: прекратить ответы.

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

Перед подключением базы проверьте саму инструкцию:

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

Подключите факты с версией и владельцем

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

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

Проверьте рабочий путь локально

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

[
  {"name":"обычная цена","message":"Сколько стоит стяжка?","expected":"ask_area"},
  {"name":"человек","message":"Позовите менеджера","expected":"handoff"},
  {"name":"нет данных","message":"Сделаете нестандартный состав?","expected":"handoff"},
  {"name":"повтор","message":"Сколько стоит стяжка?","expected":"deduplicate"}
]

python3 -m json.tool agent-cases.json >/dev/null

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

Как задать действия и пределы

Для каждого инструмента укажите точный набор параметров. create_handoff получает идентификатор диалога, причину и ответственного. get_current_terms получает код услуги или объявления. Приложение валидирует параметры до вызова. Сумма, срок и адрес из свободного текста клиента не должны автоматически превращаться в подтверждённое условие компании. Если действие внешнее, например отправка сообщения, сохраняйте ключ события, чтобы повторная доставка не отправила второе.

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

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

Как это выглядит в работе

В другом моём проекте схема «AI‑продавец для косметолога» показывает путь от сообщения ВК через amoCRM к помощнику и записи. Для настройки агента это пример явных границ: откуда приходит событие и где проверяется результат.

Клиент

Сколько будет стоить мой объект?

Помощник

Для расчёта нужна площадь и условия на объекте. Напишите площадь, и я передам вопрос менеджеру.

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

Что проверить после включения канала

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

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

Для самостоятельной сборки полезно начать с локальной копии данных и тестовых диалогов. Раздел обучения посвящён таким рабочим проектам: от границ роли до проверки после подключения канала. Общую схему обработки запроса можно посмотреть в статье как работает ИИ‑агент.

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

Частые вопросы

Можно ли настроить агента одним промптом?

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

Где хранить цену для ответов?

В одном утверждённом источнике с владельцем и датой изменения. Агент читает её перед ответом.

Какие тесты нужны до запуска?

Обычный вопрос, отсутствие факта, конфликт сведений, повтор сообщения, жалоба и просьба о человеке.

Как ограничить расходы агента?

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

Кто отвечает за ответы после запуска?

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