Тестирование ИИ-агентов: таблица приёмки для заказчика

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

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

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

Тестирование ИИ-агентов: что считать результатом

Допустим, агент должен распределить обращение в очередь поддержки и создать внутреннюю задачу. В сообщении он правильно назвал отдел. Но задачу мог не создать, назначить другому отделу или оставить без обязательного номера обращения. Текстовая часть прошла проверку, процесс целиком - пока нет.

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

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

Заранее отделите обязательное от допустимых вариантов. Например, очередь «логистика» и номер обращения должны совпасть с эталоном. Формулировка черновика может отличаться, если смысл сохранён и не появились новые обещания. Сравнение всего ответа посимвольно здесь отклонит и нормальный вариант текста.

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

Где вы сейчас

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

Что подготовить до первого прогона

Назначьте сотрудника, который знает процесс и может решить, какой результат верный. Это может быть руководитель поддержки или старший менеджер. Исполнитель отвечает за настройку, сотрудник бизнеса - за смысл правил. Без такого разделения спор «агент неправильно понял» останется спором мнений.

Тестовая среда должна отличаться от рабочей: отдельные задачи, тестовые получатели, искусственные данные. Попросите исполнителя показать, куда подключена запись и отключена ли реальная отправка. Одного названия «тест» в интерфейсе мало, если подключение всё ещё ведёт в вашу рабочую базу.

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

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

Запишите, что должно происходить при нехватке данных и недоступности системы. «Передать человеку» тоже требует понятного результата: кому передать, с каким пересказом, где увидеть передачу. Без этого агент может прекращать работу при каждом сложном вопросе и формально выглядеть безошибочным.

Технические права и запреты рассматривайте отдельно от качества ответа. OWASP рекомендует проверять разрешения в самих подключённых системах, а не поручать модели решать, позволено ли действие. Общие правила доступа разобраны в статье о безопасности ИИ-агентов.

Тестирование ИИ-агентов по шагам

1. Запишите правила приёмки

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

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

2. Проверьте тестовые подключения

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

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

3. Прогоните подготовленные случаи

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

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

4. Сверьте ответ с действием

   Откройте журнал запуска и тестовую задачу. Сопоставьте очередь, поля, количество записей и черновик с эталоном. Если агент передал случай человеку, проверьте, что передача действительно состоялась.

   Проверка шага: рядом с вердиктом сохранены доказательства. Отсутствие журнала или записи отмечено как «не проверено», без автоматического зачёта.

5. Запишите решение и повторите проверки после правок

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

   Проверка шага: решение о пилоте относится к определённой версии и определённому участку работы. Старый отчёт не используется для изменённого прототипа.

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

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

Тестирование ИИ-агентов на 12 учебных сценариях

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

Справочник версии 1:

• Задержка доставки или вопрос о доставке - очередь «логистика»; для создания задачи нужен номер заказа.
• Вопрос о доступе в кабинет - очередь «поддержка»; для задачи нужен номер обращения.
• Запрос скидки - очередь «менеджер»; агент не рассчитывает скидку и не обещает её.
• Без обязательного номера агент готовит уточнение и не создаёт обычную задачу. Отдельная запись о проверке допустима, но она не считается задачей отдела.
• Противоречие в исходных данных - очередь «менеджер» с кратким описанием противоречия. Проверяющий ожидает подтверждённую передачу.
• Повтор события с тем же идентификатором не должен создавать вторую задачу.

У всех учебных входов есть идентификатор события. Для передачи менеджеру достаточно этого идентификатора и текста обращения. Обычные задачи дополнительно требуют номер заказа или номер обращения по правилу своей очереди.

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

Сценарий 07 проверяется как один диалог. Попросите исполнителя запускать обработку после получения последнего сообщения: создание задачи до уточнения темы здесь не разрешено правилами примера. Для других входов история начинается заново. В сценарии 10, напротив, нужно сохранить результат строки 01.

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

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

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

Как принять один случай без спора о формулировках

Возьмём строку 01. Вход содержит заказ T-101, задержку доставки и событие E-01. Проверяющий ожидает очередь «логистика», одну внутреннюю задачу с этими идентификаторами и черновик без выдуманной даты приезда. Самого срока доставки в справочнике нет.

Откройте тестовый список задач и найдите запись по E-01. Сверьте номер заказа и очередь. Затем прочитайте черновик: он может попросить сотрудника проверить доставку, но не должен обещать, что заказ будет завтра. После этого посмотрите журнал: в нём должен быть результат обращения к системе, связанный с этим запуском.

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

Для другой очереди используйте тот же порядок, заменяя обязательные поля. Такая проверка сохраняет свободу формулировки: «Передаю вопрос в логистику» и «Нужно уточнить статус у отдела доставки» могут быть допустимыми черновиками. Важны верный отдел, отсутствие обещанного срока и проверенное действие.

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

Что записывать в протокол проверки

Протокол должен позволять повторить проверку. Один скриншот ответа не показывает исходные данные, настройку или результат записи. Свяжите материалы номером случая и номером запуска, чтобы подрядчик мог воспроизвести ошибку без переписки «вчера что-то пошло не так».

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

Случай:
Номер запуска:
Версия прототипа, модель, справочник:
Исходный вход и состояние тестовой системы:
Ожидаемые очередь, поля, действия и запреты:
Фактический ответ:
Фактическое действие:
Доказательство: ссылка на запись и журнал запуска
Передача человеку: требовалась / не требовалась; выполнена / нет
Время до проверенного результата:
Статус: пройден / провален / не проверено
Причина и следующая проверка:
Проверяющий:

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

Отдельно ведите четыре числа: сколько случаев запланировали, сколько фактически прогнали, сколько прошло и сколько осталось без доказательств. Не убирайте зависшие и сорванные проверки из отчёта. Иначе доля успеха будет относиться только к удобным для демонстрации попыткам.

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

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

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

Что делать с нестабильными ответами и сбоями проверки

Ответы модели могут различаться между запусками. Anthropic прямо описывает повторные попытки одного случая, а n8n отмечает вариативность результата и автоматических оценок. Поэтому один удачный ответ не подтверждает устойчивость поведения.

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

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

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

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

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

Для сведений о вызванных инструментах в n8n документация предлагает параметр Return intermediate steps. Он добавляет поле intermediateSteps к результату агента. Попросите исполнителя показать его на тестовом запуске, но всё равно сверяйте конечную запись: промежуточные сведения подтверждают ход работы, а не заменяют проверку результата.

Когда переходить к ограниченному пилоту

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

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

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

В финальном документе запишите решение обычным языком: «Версию такую-то допускаем к проверяемому пилоту на таком-то участке. Эти случаи передаём человеку. Эти ошибки исполнитель исправляет до расширения». Если условия не выполнены, перечислите конкретные причины и следующий проверяемый результат.

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

Чек-лист

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