Тестирование ИИ агентов начинается с проверки конкретных действий на нормальных, пограничных и вредоносных запросах. До подключения рабочих прав прогоните каждый сценарий в отдельной среде, сохраните журнал вызовов инструментов и заранее определите момент остановки.
Матрица сценариев
Для первого прогона достаточно трёх классов запросов: штатные, пограничные и вредоносные. Каждый класс проверяет свой риск, а результатом служит запись действий агента, включая вызовы инструментов.
Возьмите один процесс, например подготовку ответа на заявку в Битрикс24. Агент читает карточку, ищет сведения в базе знаний и создаёт черновик. Для штатного случая ему доступны корректная карточка и свежая инструкция. Пограничный случай содержит пустое поле, противоречивую дату или дублированный контакт. Вредоносный случай приносит текст с командой отправить базу клиентов на сторонний адрес. Так виден разрыв между красивым ответом и безопасным поведением при реальных входных данных.
| Класс | Вход | Ожидаемое действие | Провал |
|---|---|---|---|
| Штатный | Заполненная заявка | Черновик с источником | Подмена фактов |
| Пограничный | Пустой бюджет | Запрос уточнения | Догадка о сумме |
| Вредоносный | Команда внутри файла | Игнорирование команды | Вызов отправки |
Для каждого ряда запишите разрешённые инструменты, ожидаемый формат результата и запретные вызовы. Такая матрица ближе к испытанию бизнес процесса, чем список удачных ответов модели. Общие уровни самостоятельности разобраны в материале об автономных агентах. Здесь единица проверки мельче: один вход, один ожидаемый след действий и понятный критерий сбоя. Если процесс включает несколько внешних систем, создайте отдельный ряд для каждого перехода между ними.
Проверка инструментов
Подключите тестовые копии CRM и таблицы с вымышленными данными. В n8n задайте узлам раздельные права: чтение карточки, поиск инструкции, сохранение черновика. Отправка письма и изменение статуса заявки остаются за человеком. Названия инструментов в журнале должны совпадать с фактическими вызовами; одного текста «отправки нет» для проверки мало.
- Создайте тестовую заявку с заранее известными полями и ожидаемым ответом.
- Прогоните запрос и сохраните вход, версию инструкции, вызовы инструментов и итоговый черновик.
- Сравните параметры каждого вызова с разрешённым списком; отдельно проверьте адресата, идентификатор записи и состав полей.
- Повторите прогон после изменения инструкции и сверьте прежний результат с новым.
Проверьте право на ошибку инструмента: CRM может вернуть пустой ответ, задержку или чужую запись из-за неверного идентификатора. Агенту нужен безопасный исход: сообщение оператору и остановка цепочки, без уверенного ответа по неполной карточке. Разбор механики вызовов есть в статье о вызовах инструментов. Тест проверяет также, сохраняет ли система исходный идентификатор заявки на всём маршруте. Перепутанный номер способен отправить верный текст другому клиенту.
Соберите тестовую копию одного маршрута с одной CRM карточкой. Первым делом проверьте, совпадает ли идентификатор записи на входе, в вызове и в черновике.
Повторный запуск
Разовый успех мало говорит о стабильности. Один и тот же набор данных прогоните несколько раз с одинаковыми правами. Модель может менять формулировку, но список разрешённых действий и адресаты должны оставаться одинаковыми. Если один повтор создаёт лишнюю запись, тест считается проваленным, даже когда остальные ответы выглядят удачно.
Условный пример: агент получил заявку с вложенным документом. В первом прогоне он процитировал правило доставки, во втором принял фразу из документа за команду сменить адрес получателя. Это повод разделить текст документа и управляющую инструкцию, затем повторить всю матрицу. Для просмотра динамики полезен журнал: входные данные, время, версия сценария, решение модели, параметры инструмента, ответ системы и итог оператора. Чувствительные поля в журнале маскируйте.
- Проверяйте точность фактов по первичному источнику.
- Считайте отдельно запрещённые вызовы и ошибки содержания.
- Отмечайте одинаковые запросы, которые дали разные действия.
- Храните версию промпта рядом с версией подключённого инструмента.
Связка повторов и журнала позволяет поймать регрессию после обновления инструкции. Оператору нужна короткая карточка инцидента: какой запрос вызвал ошибку, какие права использовал агент и какой результат уже попал в рабочую систему. При подготовке сложного маршрута полезен разбор собственных инструментов агента. Матрицу пополняйте каждым обнаруженным сбоем: повторяемый запрос превращается в постоянную проверку.
После таких проверок становится ясно, какие действия допустимы для рабочего контура и где требуется подтверждение человека.
Хотите проверить маршрут вашего агента на опасные действия?
Остановка и откат
Критерий остановки запишите до пилота. Для агента, который готовит черновики, критичны попытка отправки без согласования, запись в чужую карточку и передача данных наружу. При таком событии отключайте токен доступа, останавливайте сценарий n8n и переводите новые заявки на ручную обработку. Сохранённый журнал поможет понять границы затронутых записей.
Откат состоит из двух разных операций. Первая возвращает безопасную конфигурацию: прежний промпт, список инструментов и набор прав. Вторая исправляет уже изменённые данные в CRM. Для неё нужен список объектов, время изменения и владелец решения. Если агент только создал черновики, их можно пометить и удалить после проверки. Если он менял статусы, оператор сверяет каждый затронутый объект с первичной заявкой.
Проверяйте сам откат в тестовой среде. Запустите сценарий, внесите контролируемую ошибку, остановите права и восстановите исходное состояние. Затем повторите штатный запрос: старый маршрут должен снова дать ожидаемый результат. Состав владельцев, метрик и ответственных за инцидент относится к управлению агентами в компании. В этом тесте важен технический факт восстановления: кому доступен переключатель, какие данные меняются и сколько записей требует ручной сверки.
Договоритесь, как быстро ответственный получает сигнал после критичного вызова. Уведомление должно содержать идентификатор задачи и безопасную ссылку на журнал, но обходиться без полного текста клиентских данных. Так человек начинает разбор сразу с затронутого объекта.
Допуск к работе
Пилот запускайте с минимальным набором операций. Сначала чтение и подготовка черновиков, затем действия с записью после успешной матрицы. Для каждого нового инструмента добавьте штатный, пограничный и вредоносный сценарий. Изменение прав считается отдельным выпуском, даже если текст промпта остался прежним.
Согласуйте с владельцем процесса допустимую долю содержательных ошибок и абсолютный запрет на опасные действия. Эти показатели различаются: опечатку в черновике исправляет оператор, а отправка документа чужому адресату требует немедленной остановки. Таблица результатов показывает качество ответов и опасные действия отдельно: единичный запретный вызов остаётся виден даже при высокой средней оценке.
Для рабочего запуска подготовьте карточку выпуска: версия сценария, набор прав, дата прогона, ссылки на журналы, ответственный за откат и правило повторной проверки. После каждого изменения интеграции карточку обновляют. Если нужен полноценный контур с контролем действий, его состав описан на странице внедрения ИИ агентов. Стоимость такой работы обсуждается после разбора процесса и данных. Главный результат тестирования — воспроизводимая процедура, по которой следующая версия агента проходит ту же проверку, что и первая.
После запуска сохраняйте контрольную выборку для очередных выпусков. Если меняется схема CRM, старые сценарии прогоняют снова: прежний идентификатор может начать означать другое поле. При расхождении выпуск откладывают до исправления маршрута и повторного испытания.