Тестирование ИИ-агентов: сценарии, действия и критерии приёмки

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

Чем проверка агента отличается от проверки ответа

У агента бывает правдоподобный финальный текст при ошибочной последовательности действий. Поэтому фиксируйте и ответ, и вызовы инструментов, и состояние системы. Учебный материал Google по оценке агентов разделяет траекторию действий и конечный ответ: правильный инструмент должен быть вызван в нужный момент с верными аргументами. OpenAI Agents SDK позволяет просматривать вызовы инструментов и передачи между агентами в трассировке; это пример средства наблюдения, а не обязательная платформа для теста.

Не смешивайте эту задачу с обычной проверкой фактов в тексте. Для ответов со ссылками полезен отдельный чек-лист проверки ответа ИИ-агента. Здесь проверяется весь путь: как агент понял задачу, что прочитал, какую команду выбрал и что реально изменилось.

Какие условия создать до запуска

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

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

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

Как записать проверяемый сценарий

У каждого сценария должны быть четыре части: исходные данные, действие пользователя, ожидаемые шаги агента и проверка конечного состояния. Не пишите только «ответить правильно»: так остаётся невидимой ошибка в инструменте. Храните проверочные примеры с версиями данных, чтобы результат можно было воспроизвести после изменения промпта или модели. Документация OpenAI по оценкам описывает набор тестовых критериев и источник данных для повторных запусков; ту же логику можно вести в простой таблице без платформы.

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

1. Сохраните идентификатор сценария и начальный снимок данных. Это позволяет отличить ошибку агента от следа прошлого прогона.
2. Дайте агенту одно задание с известным результатом, не раскрывая ему ожидаемую последовательность в пользовательском тексте.
3. Сравните фактические вызовы с разрешённым маршрутом. Проверьте имя инструмента, порядок, аргументы и количество попыток.
4. Прочитайте состояние системы отдельным способом. Ответ агента сам по себе не является подтверждением записи.
5. Запишите вердикт и причину. После исправления повторите сценарий на восстановленных данных.

Какие сбои обязательно воспроизвести

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

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

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

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

По теме: ИИ-агент для закупок: безопасный пилот со сверкой остатков

Как оценить результаты без ложной точности

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

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

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

Когда этот подход не подходит

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

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

Можно ли тестировать агента вручную?

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

Достаточно ли проверить только финальный ответ?

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

Что делать, если результат каждый раз разный?

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

Когда можно подключать реальные данные?

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