Почему тестирование AI-агентов - это боль, и как Eval Engineering Skill её решает
AI-агенты недетерминированы по своей природе. Один и тот же промпт может привести к разным цепочкам вызовов инструментов, модель способна выбрать неоптимальный путь, а внешний API - вернуть ошибку в самый неподходящий момент. Ручное написание тестов для таких систем превращается в бесконечную гонку: вы фиксируете сценарий, агент меняет поведение после обновления модели, и тесты устаревают раньше, чем попадают в CI.
LangChain ответил на этот вызов запуском Eval Engineering Skill - инструмента, который автоматизирует создание тестов на основе кода и трейсов агента. Skill сканирует репозиторий, извлекает промпты, модели, инструменты и зависимости, а затем обогащает статический анализ реальными данными из трейсов - аргументами вызовов, возвращаемыми значениями и ошибками. Результат упаковывается в контейнеризированные Harbor-задачи с Dockerfile и скриптом-верификатором, готовые к изолированному запуску.
Ключевая находка разработчиков: интерактивное интервью с пользователем даёт радикально лучшее принятие тестов, чем однократная генерация. Вместо того чтобы молча выдать набор eval-сценариев, Skill задаёт уточняющие вопросы - какие аспекты критичнее, какие границы допустимы, - и формирует тесты, соответствующие реальным ожиданиям команды. Такой подход закрывает главную проблему тестирования агентов: разрыв между формальной корректностью и практической полезностью проверок.
Если вы проектируете агентные системы, стоит понимать архитектурные паттерны, которые делают их надёжными. В материале об архитектуре LLM-агентов с верификацией мы разбирали, как контур проверки превращает демо в production-инструмент. Eval Engineering Skill идёт дальше - он автоматизирует создание самого контура проверки.
Как Skill анализирует ваш репозиторий: от промптов до зависимостей
Первый этап работы инструмента - статическое сканирование кодовой базы. Skill не просто ищет вызовы LLM, он строит карту агента: какие промпты используются, к каким моделям идут запросы, какие инструменты доступны и как они связаны между собой. Эта карта становится фундаментом для генерации тестов.
Анализ репозитория решает проблему, знакомую каждому, кто строил агентов с нуля: документация устарела, архитектура в коде разошлась с диаграммами, и только статический анализатор видит реальную картину. Подход пересекается с тем, что описан в статье о самостоятельной разработке AI-агента, где оркестрация LLM, память и инструменты требуют чёткого тестирования каждого слоя.
Какие именно элементы кода попадают в анализ
Skill извлекает четыре категории артефактов. Prompt templates - все шаблоны запросов к модели, включая системные промпты, few-shot примеры и динамически собираемые сообщения. Model configurations - названия моделей, параметры temperature и top_p, настройки стриминга. Tool definitions - сигнатуры инструментов, описания их параметров, схемы входных и выходных данных. Dependency graphs - граф вызовов, показывающий, какой инструмент может быть вызван после какого и при каких условиях.
Эта информация даёт Skill понимание логики агента до того, как он выполнит хотя бы один прогон. Статический анализ выявляет потенциальные точки отказа: инструмент с необязательным параметром, который на практике всегда требуется; модель, чувствительную к формулировке системного промпта; цепочку вызовов, где ошибка на первом шаге каскадно ломает весь сценарий.
Трейсы как источник реального поведения: аргументы, результаты и ошибки
Статический анализ показывает, что агент может делать. Трейсы показывают, что он делает на самом деле. Каждый трейс - это запись конкретного выполнения: какие инструменты были вызваны, с какими аргументами, что они вернули, где возникли ошибки и как агент на них отреагировал.
Skill использует трейсы для воспроизведения реального поведения инструментов. Если API три раза из десяти возвращал 500, тест проверит, корректно ли агент обрабатывает эту ошибку - делает ли retry, сообщает ли пользователю, переключается ли на fallback-стратегию. Если инструмент поиска возвращал пустой результат на специфический запрос, eval-сценарий зафиксирует этот краевой случай. Трейсы превращают тестирование из спекулятивного «а что если» в доказательное «вот что происходило на прошлой неделе».
Практическая ценность такого подхода раскрывается в сценариях, где агент взаимодействует с внешними системами. Ошибка таймаута, неожиданный формат ответа, изменение схемы API - всё это остаётся в трейсах и автоматически становится материалом для тестов. Skill не требует от разработчика вручную описывать краевые случаи, он извлекает их из истории реальных прогонов.
Интервью с пользователем: почему это повышает принятие тестов
LangChain обнаружил закономерность: тесты, сгенерированные полностью автоматически, принимаются командой разработки ощутимо хуже, чем тесты, прошедшие через диалог с пользователем. Причина не в качестве генерации, а в соответствии ожиданиям. Автоматический генератор не знает, что для вас критично - latency или полнота ответа, строгое соответствие формату или толерантность к вариациям. Он предлагает усреднённый набор проверок, который закрывает 80% общих случаев, но не попадает в специфику проекта.
Интервью решает эту проблему. Skill задаёт вопросы, пользователь корректирует фокус, и финальный набор тестов отражает реальные приоритеты команды. Это не просто «удобная фича», а инженерное решение проблемы alignment между автоматической генерацией и практическими потребностями.
Как проходит интервью: от вопросов к уточнённым сценариям
Skill начинает с общих вопросов: «Какие аспекты работы агента для вас критичнее - скорость ответа или точность?», «Допустимы ли частичные ответы, или агент должен всегда возвращать полный результат?», «Как агент должен реагировать на ошибки внешних сервисов - retry, fallback или немедленное уведомление пользователя?». На основе ответов Skill предлагает конкретные тест-кейсы.
Пользователь видит предложение: «Проверить, что при таймауте API поиска агент переключается на локальный индекс за время не более 2 секунд». Он может принять этот сценарий, отклонить или модифицировать - например, изменить порог с 2 секунд на 5. Skill учитывает правки и перестраивает набор тестов. Такой итеративный процесс даёт результат, который команда воспринимает как «свой», а не навязанный извне.
Сравните с подходом «одна кнопка - все тесты»: генератор выдаёт 50 сценариев, из которых 30 нерелевантны, 15 дублируют друг друга, и только 5 действительно полезны. Разработчик тратит время на фильтрацию вместо того, чтобы сразу получить целевой набор. Интервью устраняет этот этап - на выходе только те проверки, которые прошли через явное подтверждение.
Harbor-задачи: контейнеризация evals для изоляции и переиспользования
Финальный этап работы Skill - упаковка сгенерированных тестов в Harbor-задачи. Это контейнеризированный формат, который включает инструкцию с описанием тестового сценария, окружение в виде Dockerfile и скрипт-верификатор, проверяющий результаты агента.
Контейнеризация решает две проблемы. Первая - изоляция. Каждый eval запускается в собственном окружении, со своими зависимостями и версиями библиотек. Тест для агента на Python 3.11 с LangChain 0.3 не сломается из-за того, что в системе установлен Python 3.12 с LangChain 0.4. Вторая - переиспользование. Один и тот же Harbor-пакет можно запустить против разных конфигураций агента: с другой моделью, с изменённым промптом, с новым набором инструментов. Это критично для A/B-тестирования и регрессионного анализа при обновлении компонентов.
Отдельного упоминания заслуживает предотвращение reward hacking - ситуации, когда агент оптимизируется под прохождение теста, а не под решение задачи. Изолированное окружение с фиксированным Dockerfile и верификатором не позволяет агенту «подсмотреть» ожидаемые ответы или адаптироваться к конкретной тестовой среде. Агент видит только интерфейс задачи, идентичный боевому, и оценивается по реальному поведению.
Что внутри Harbor-задачи: Dockerfile, верификатор и инструкция
Dockerfile описывает чистое окружение: базовый образ, установку зависимостей, копирование тестовых данных. Никаких лишних пакетов, никаких глобальных переменных, которые могли бы повлиять на выполнение. Верификатор - это скрипт, который получает выходные данные агента и сравнивает их с ожидаемыми критериями. Критерии не обязательно жёсткие: верификатор может проверять структуру ответа, наличие ключевых полей, диапазоны числовых значений или вызывать LLM для семантической оценки.
Инструкция содержит текстовое описание сценария - что должен сделать агент, какие инструменты доступны, какой результат ожидается. Этот компонент важен для воспроизводимости: новый разработчик в команде может прочитать инструкцию и понять, что именно проверяет eval, без необходимости разбирать код верификатора.
Практический путь: от репозитория до запуска тестов за 5 шагов
Шаг 1 - подключение репозитория. Skill получает доступ к кодовой базе агента через Git-интеграцию. На этом этапе определяется язык и фреймворк - на момент анонса основная поддержка сфокусирована на Python и LangChain-экосистеме.
Шаг 2 - запуск сканирования. Skill анализирует код и строит карту промптов, моделей, инструментов и зависимостей. Результат - структурированное описание агента, которое можно просмотреть и валидировать перед переходом к генерации тестов.
Шаг 3 - загрузка трейсов. Если у вас настроено трассирование через LangSmith или аналогичный инструмент, Skill подгружает историю выполнений. Трейсы автоматически сопоставляются с элементами, найденными при статическом анализе, и обогащают их конкретными данными.
Шаг 4 - прохождение интервью. Skill задаёт серию вопросов о приоритетах тестирования, вы предлагаете, корректируете и подтверждаете тест-кейсы. Продолжительность зависит от сложности агента - от 5 до 20 минут для типового проекта.
Шаг 5 - получение и запуск Harbor-задачи. На выходе вы получаете контейнеризированный пакет с Dockerfile, верификатором и инструкцией. Запуск - стандартная команда docker build и docker run. Результат выполнения - отчёт о пройденных и проваленных проверках с конкретными указаниями, что пошло не так.
Ограничения и что пока остаётся за кадром
Eval Engineering Skill - новый инструмент, и на момент анонса по нему нет исчерпывающей информации. LangChain не опубликовал данные о поддерживаемых языках помимо Python, хотя архитектура анализа репозитория предполагает потенциальную расширяемость на TypeScript и другие языки. Неясна модель распространения: будет ли Skill частью LangSmith-подписки, отдельным продуктом или открытым инструментом.
Не опубликованы бенчмарки, сравнивающие качество тестов, сгенерированных через интервью, с тестами, написанными вручную. Заявление о «существенно лучшем принятии» основано на внутренних наблюдениях LangChain, но конкретные цифры acceptance rate отсутствуют. Для production-внедрения потребуется собственная валидация на ваших агентах и сценариях.
Инструмент ориентирован на агентов, построенных в экосистеме LangChain. Если ваш агент использует другую оркестрацию - кастомный ReAct-цикл, Microsoft AutoGen или проприетарное решение, - статический анализатор может не распознать структуру кода, и ценность Skill снизится до уровня работы только с трейсами. В таких случаях стоит рассмотреть альтернативные подходы к тестированию, описанные в разборе методологии оценки агентов Databricks, где сравниваются разные harness-обвязки для кодинг-агентов.