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