Перед сдачей AI-агента клиенту я отношусь к нему не как к красивому чат-боту, а как к сотруднику, который получает доступ к данным, клиентам и бизнес-процессам. Если такой сотрудник ошибается, цена ошибки может быть выше, чем у обычной формы на сайте: он может пообещать неправильную цену, потерять лида, создать неверную задачу в CRM или уверенно ответить на вопрос, которого не знает.
Поэтому тестирование AI-агента у меня начинается не в день релиза. Я закладываю тесты еще на этапе проектирования: какие сценарии считаются нормальными, где агент должен остановиться, где обязан передать диалог человеку, какие действия требуют подтверждения и какие данные нельзя показывать пользователю.
Три типа тестов
1. Сценарные тесты
Это проверка типовых путей пользователя. Например: клиент спрашивает цену, уточняет сроки, просит пример, оставляет телефон, агент создает сделку и отправляет уведомление менеджеру. Я прохожу такие сценарии десятки раз с разными формулировками, потому что реальные люди редко пишут так, как написано в ТЗ.
В сценарных тестах важно проверять не только счастливый путь. Пользователь может начать с цены, потом уйти в детали, потом вернуться к срокам, потом попросить скидку. Агент должен удерживать контекст и не превращать диалог в набор изолированных ответов.
2. Интеграционные тесты
Здесь я проверяю все, что находится за пределами модели: CRM, webhooks, n8n, базы данных, таблицы, почту, телефонию, Telegram и WhatsApp. AI-агент может идеально отвечать, но если заявка не попала в CRM, бизнесу от этого мало пользы.
Интеграционные тесты всегда включают ошибки: недоступна CRM, API вернул 500, пользователь прислал слишком длинное сообщение, webhook сработал дважды, сеть упала в середине цепочки. Хорошая система должна не молча ломаться, а логировать ошибку, уведомлять ответственного и не терять данные.
3. Защитные тесты
Это проверка границ. Я пробую prompt injection, просьбы раскрыть системный промпт, попытки получить чужие данные, давление на модель, токсичные формулировки, конфликтующие инструкции и вопросы вне компетенции. Цель не сделать агента идеальным, а понять, где он ломается и как безопасно остановить действие.
Для клиентских проектов особенно важна проверка обещаний. Агент не должен обещать скидки, сроки, гарантии и функции, если это не описано в базе знаний. Лучше честно передать вопрос менеджеру, чем уверенно продать то, чего компания не делает.
Чеклист из 20 пунктов
- Агент понимает основные намерения пользователя.
- Корректно задает уточняющие вопросы.
- Не теряет контекст после 8-10 сообщений.
- Отличает лид от случайного вопроса.
- Передает в CRM все обязательные поля.
- Не создает дубли сделок при повторном сообщении.
- Сохраняет историю диалога или краткое резюме.
- Работает с русским языком, опечатками и разговорными формулировками.
- Не придумывает цены, сроки и условия.
- Ссылается только на доступную базу знаний.
- Умеет сказать «не знаю» и передать человеку.
- Не раскрывает системный промпт и внутренние инструкции.
- Не показывает персональные данные других клиентов.
- Обрабатывает длинные сообщения без падения.
- Переживает ошибку внешнего API.
- Логирует вход, ответ, действие и ошибку.
- Имеет лимиты по токенам и стоимости.
- Соблюдает нужный тон коммуникации.
- Отправляет уведомление менеджеру в правильный канал.
- Имеет понятный режим ручного отключения.
Красные флаги
Первый красный флаг — агент уверенно отвечает там, где должен уточнять. Это почти всегда ведет к галлюцинациям. Второй — нет логов. Если нельзя посмотреть, какой запрос пришел, какой контекст получил агент и какое действие выполнил, такой проект нельзя спокойно сдавать клиенту.
Третий флаг — отсутствие негативных сценариев в ТЗ. Если команда проверяет только идеальный путь, реальные пользователи быстро найдут слабые места. Четвертый — слишком широкие права. AI-агент не должен иметь возможность менять критичные данные без подтверждения, особенно в CRM, платежах и складских системах.
Пятый флаг — «магический» промпт на пять страниц вместо архитектуры. Длинный промпт может работать на демо, но продакшен требует базы знаний, ограничений, инструментов, fallback-сценариев и мониторинга.
Инструменты
Для API и webhooks я использую Postman или простые curl-запросы. Для n8n смотрю execution history, payload на каждом шаге и повторный запуск проблемных сценариев. Для фронтенда и диалоговых интерфейсов полезны Playwright или Cypress, если нужно пройти полный путь пользователя.
Отдельно веду таблицу тест-кейсов: входное сообщение, ожидаемое намерение, нужное действие, фактический ответ, статус, комментарий. Это не самая модная часть работы, но именно она помогает клиенту увидеть, что агент проверен системно, а не просто «вроде отвечает».
Для мониторинга после запуска нужны логи, алерты и выборочная ручная проверка диалогов. Первые две недели я считаю периодом наблюдения: пользователи начинают писать неожиданными словами, всплывают новые вопросы, база знаний дополняется, а промпты становятся короче и точнее.
Пример бага
В одном проекте агент для записи на консультацию иногда создавал две сделки в CRM. На тестах happy path все было нормально. Баг появлялся, когда пользователь писал номер телефона, потом сразу уточнял цену, а потом снова подтверждал заявку. n8n получал два события, модель оба раза считала намерение «оставить заявку», и CRM получала дубликат.
Фикс был не в промпте. Я добавил идемпотентность: проверку активной сделки по телефону и каналу, TTL на повторное создание, отдельный статус «уже создано» и явное сообщение агенту, что повторно создавать сделку нельзя. После этого проблема исчезла.
Этот пример хорошо показывает мой подход: AI-агента нельзя тестировать только как текстовую модель. Его нужно тестировать как систему, которая принимает решения, вызывает инструменты и влияет на бизнес-процесс. Тогда сдача клиенту проходит спокойно, а первые реальные пользователи не становятся бесплатными тестировщиками.
Как я провожу приемку с клиентом
После внутренних тестов я не просто отправляю ссылку и прошу «посмотреть». Я провожу приемку по сценариям. Берем реальные вопросы клиентов, старые переписки, типовые возражения и нестандартные ситуации. Клиент видит, как агент отвечает, какие данные собирает, когда зовет человека и что попадает в CRM. Это сильно снижает риск, что после запуска всплывут разные ожидания.
На приемке я отдельно прошу клиента спорить с агентом. Не пользоваться идеальными формулировками, а писать так, как пишут настоящие покупатели: с опечатками, короткими фразами, голосовыми расшифровками, эмоциональными вопросами и неполными данными. Если агент выдерживает такой режим, он гораздо лучше проходит реальный запуск.
Еще один важный этап — проверка границ ответственности. Мы вместе решаем, какие ответы агент может давать сам, какие должен согласовывать, а какие обязан передавать менеджеру. Например, скидки, юридические обещания, нестандартные сроки, возвраты, претензии и персональные данные почти всегда требуют более строгих правил.
Что я смотрю после запуска
Первые дни после релиза я считаю продолжением тестирования. Смотрю долю успешных диалогов, количество эскалаций, причины ручной передачи, ошибки интеграций, повторяющиеся вопросы и стоимость обработки. Часто именно реальные пользователи показывают, каких формулировок не хватало в базе знаний и какие поля в CRM менеджерам неудобно заполнять.
Я не стремлюсь сразу довести автоматизацию до 100%. Хороший первый результат — когда агент стабильно закрывает 50-70% типовых обращений и не ломает сложные. Дальше можно расширять базу знаний, добавлять инструменты, улучшать классификацию и снижать количество ручных касаний.
Финальный критерий простой: менеджеры не должны бояться агента. Если команда понимает, где смотреть логи, как поправить базу знаний, как отключить сценарий и как передать диалог человеку, внедрение начинает работать. AI-агент становится не черным ящиком, а понятным элементом операционной системы бизнеса.
Мой минимальный набор тестовых данных
Для каждого агента я собираю небольшой, но разнообразный набор данных: 20-30 реальных вопросов клиентов, 10 возражений, 10 сообщений с ошибками и сокращениями, несколько токсичных или провокационных запросов, несколько запросов вне тематики и несколько сценариев с неполной информацией. Такой набор быстро показывает, насколько агент готов к жизни за пределами демонстрации.
Если агент работает с базой знаний, я добавляю похожие документы и проверяю, не путает ли он источники. Если он работает с ценами, тестирую старые и новые прайсы. Если он создает задачи, проверяю часовые пояса, повторные заявки и пустые поля. Эти мелочи выглядят скучно, но именно из них обычно складываются реальные баги на запуске.
После каждого найденного сбоя я не ограничиваюсь правкой промпта. Я спрашиваю, где правильнее поставить защиту: в промпте, в валидаторе, в базе знаний, в бизнес-правиле, в n8n-сценарии или в интерфейсе менеджера. Чем ближе защита к месту ошибки, тем надежнее работает весь агент.