AWS встроила AgentCore Evaluations в GitHub Actions для блокировки регрессий AI-агентов

Поведение агента стало проверкой pull request

AWS опубликовала reference implementation, которая подключает Amazon Bedrock AgentCore Evaluations к GitHub Actions. Workflow разворачивает AI-агента и OAuth-защищённый MCP server в AgentCore Runtime, получает токен, отправляет набор контрольных prompts, ждёт появления traces, запускает оценивание и завершает CI ошибкой, если измеренное поведение не проходит заданные пороги.

Такой gate проверяет не только то, что Python-код импортируется и endpoint отвечает HTTP 200. Изменение prompt, модели, инструмента, схемы MCP или политики авторизации может оставить сервис технически доступным, но испортить смысл ответа или траекторию вызовов. Evaluation step переносит эту категорию регрессий в тот же обязательный цикл, где команда уже проверяет unit tests, lint и инфраструктурный plan.

Пример построен на Strands agent, FastMCP server, AWS CDK и едином Cognito user pool. Код вынесен в публичный репозиторий agentcore-samples, включая CDK stack, скрипт оценки и GitHub Actions workflow. Это стартовый шаблон, а не универсальный набор порогов: команды должны заменить демонстрационные prompts и критерии собственными критическими сценариями.

Один Cognito pool обслуживает людей и автоматизацию по-разному

Архитектура использует один Amazon Cognito user pool для двух OAuth flows. Интерактивный пользователь проходит authorization_code flow и получает token со scopes и custom:roles. CI использует client_credentials, то есть machine-to-machine token со scopes, но без пользовательских ролей. Эти различия затем влияют на доступность MCP tools.

На MCP server авторизация разделена на три слоя. Запрос должен пройти проверку JWT и требуемых OAuth scopes, после чего FastMCP middleware читает claims и сопоставляет custom:roles с metadata конкретного инструмента. Для M2M tokens пример разрешает все tools без role check, чтобы pipeline мог покрыть полную поверхность возможностей агента.

Именно последнее решение требует адаптации перед production. Полный доступ CI удобен для end-to-end проверки, но компрометация GitHub role или OAuth client превращает тестовый credential в широкий служебный доступ. AWS предлагает IAM role для GitHub Actions; владельцу системы всё равно нужно ограничить trust policy, audience, repository и branch conditions, а MCP tools — изолировать от необратимых данных или запускать на тестовом окружении.

Unified evaluation script связывает invocation, traces и оценки

Центральный scripts/agentcore_eval.py выполняет последовательность целиком: получает OAuth token, ждёт готовности runtime, вызывает агента с отдельным session ID, ждёт поступления observability traces и запускает evaluations. В HTTP-запросе используются Bearer token, JSON content type и X-Amzn-Bedrock-AgentCore-Runtime-Session-Id, позволяющий связать ответ с конкретной тестовой сессией.

Ожидание traces — существенная часть pipeline. Ответ агента может прийти раньше, чем телеметрия станет доступна evaluator, поэтому немедленный запрос оценки способен дать ложный пропуск или отсутствие данных. Скрипт делает асинхронную границу явной, но в реальном CI необходимо отдельно настроить предельное время, retries и различение плохого результата от сбоя инфраструктуры наблюдаемости.

Набор prompts охватывает встроенные функции агента, публичные MCP tools и инструменты с ограничением по ролям. Благодаря этому проверяется не только natural-language output, но и связность всего пути: GitHub identity, OAuth issuance, AgentCore Runtime, вызов MCP, применение middleware, формирование traces и работа evaluator. Такой тест дороже unit test, зато ловит ошибки на стыках сервисов.

Quality gate должен измерять ответ, траекторию и безопасность раздельно

AWS советует начинать с четырёх или пяти evaluators. Для tool-calling agents отдельно полезны trajectory evaluators, проверяющие выбор и порядок инструментов. Для клиентских систем предлагаются safety evaluators Harmfulness, Stereotyping и Refusal, а детерминированные инварианты лучше выражать code-based evaluators, где результат не зависит от второго вероятностного judge.

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

Практический gate лучше строить по критическим инвариантам: обязательные сценарии должны проходить каждый, а агрегатная метрика подходит для менее жёстких вариаций. Результаты model-based evaluator следует периодически сверять с человеческой разметкой и фиксированными golden cases. Официальная публикация показывает механизм подключения, но не доказывает, что выбранный judge или набор prompts адекватен конкретной отрасли.

Три режима интеграции дают разную глубину проверки

AWS различает быстрый quality gate без полного защищённого пути, тест с пользовательским OAuth и end-to-end вариант с M2M authentication. Публикация выбирает третий подход, поскольку он тестирует фактические изменения pull request вместе с runtime и MCP server. Для первого внедрения AWS предлагает начать с более простого варианта, а затем перейти к M2M, когда команде нужна полная интеграционная проверка.

Выбор зависит от цены и риска. Быстрые offline checks можно запускать на каждый commit, тогда как развёртывание инфраструктуры, ожидание traces и model-based evaluations разумно оставить для pull request или release candidate. Отдельный периодический deep suite способен покрыть редкие и дорогие сценарии без превращения каждой небольшой правки в длинный deployment cycle.

Автоматическая блокировка полезна только при интерпретируемом отказе. Pipeline должен сохранять test case, version модели и prompt, session ID, оценки, trajectory и ссылки на traces, но не публиковать токены или чувствительное содержимое в общедоступный лог. Иначе разработчик увидит красный статус без причины либо команда отключит нестабильный gate после серии ложных срабатываний.

Reference implementation задаёт каркас, а не готовую политику качества

Главная ценность примера — воспроизводимая связка infrastructure-as-code, OAuth, runtime invocation, telemetry и оценки внутри стандартного GitHub workflow. Она показывает, где именно поведенческий тест становится merge gate и как защищённый MCP может участвовать в CI без ручного входа пользователя. Это уменьшает разрыв между экспериментами в notebook и контролируемым изменением работающего агента.

Но перенос шаблона требует явных решений о тестовых данных, стоимости, квотах, стабильности evaluator и полномочиях M2M identity. Особенно опасно направлять CI на production tools, способные отправить сообщение клиенту, изменить деньги или удалить запись. Для таких действий нужны sandbox targets, idempotency keys, dry-run либо полностью детерминированные doubles, а реальный canary — отдельная строго ограниченная процедура.

Итоговый инженерный сдвиг состоит в том, что качество агента перестаёт быть ручной демонстрацией перед релизом. Оно становится версионируемым условием интеграции: запросы хранятся рядом с кодом, инфраструктура собирается повторяемо, траектория наблюдается, а не прошедший порог pull request блокируется автоматически. AWS дала рабочий маршрут реализации; надёжность конкретного gate по-прежнему определяется тем, насколько точно команда описала собственные недопустимые регрессии.