Amazon запускает AgentCore Optimization: как автоматически прокачивать AI‑агентов на проде — VogueTech

Что нового

Amazon добавила в Amazon Bedrock AgentCore превью‑функцию AgentCore Optimization — по сути, замкнутый цикл улучшения качества AI‑агентов на продакшене. Теперь в платформе есть три ключевых блока, которые раньше приходилось собирать вручную:

Recommendations (рекомендации)
- Анализируют продакшен‑трейсы и результаты оценок.
- Автоматически предлагают правки system prompt или описаний инструментов (tool descriptions).
- Работают под конкретный «reward signal» — выбранный вами оценщик (evaluator), встроенный или кастомный.
Batch evaluation (пакетная офлайн‑оценка)
- Прогоняет агента по заранее подготовленному датасету сценариев.
- Считает агрегированные метрики и сравнивает с базовой версией.
- Позволяет поймать регрессии на кейсах, которые вы считаете критичными.
- Типичный сценарий — запуск в CI/CD, чтобы ни одна новая конфигурация не ушла в прод без проверки.
A/B‑тестирование через AgentCore Gateway
- Делит живой продакшен‑трафик между двумя версиями агента в нужной пропорции.
- Считает онлайн‑метрики по выбранным оценщикам.
- Показывает доверительные интервалы и p‑value, чтобы вы принимали решение по статистике, а не по ощущениям.
- Позволяет в один клик промоутнуть победивший вариант или откатиться.

Ещё один важный элемент — configuration bundles:

Неподвижные (immutable), версионируемые снапшоты конфигурации агента: ID модели, system prompt, описания инструментов.
Привязаны к runtime ARN.
Агент получает активную конфигурацию динамически через AgentCore SDK, поэтому смена промпта или модели — это смена конфигурации, а не релиз кода.

Все эти возможности доступны в превью в тех регионах AWS, где уже работает AgentCore Evaluations. На этапе превью Optimization умеет менять только system prompt и tool descriptions для агентов, которые используют AgentCore Runtime, Observability и Evaluations.

Цифровых бенчмарков производительности, цен и размеров контекста Amazon не приводит — фокус на процессах улучшения, а не на скоростях моделей.

Как это работает

Новая функция строится вокруг «петли» из трёх шагов: наблюдать → оценивать → улучшать.

1. Наблюдение: продакшен‑трейсы и мониторинг

AgentCore уже умел собирать end‑to‑end traceability:

Каждая модельная инференция.
Каждый вызов инструмента.
Каждый шаг рассуждения агента.

Все это попадает в трейсы, совместимые с OpenTelemetry, и управляется через AgentCore Observability. Логирование идёт, в том числе, в CloudWatch Log Group, к которой вы потом подключаете Recommendations API.

2. Оценка: автоматические скоры по нескольким измерениям

Поверх этих трейсов AgentCore запускает Evaluations. Оценка может идти по разным метрикам, например:

Goal success rate — достигает ли агент цели пользователя.
Tool selection accuracy — насколько корректно он выбирает инструменты.
Helpfulness — полезность ответа.
Safety — соблюдение политик безопасности.

Оценщики могут быть:

Встроенными в AgentCore.
На основе сравнений с ground truth.
Кастомными, где в роли судьи выступает LLM (LLM‑as‑judge).

3. Recommendations: генерация улучшений

Дальше вы запускаете Recommendations API:

Указываете CloudWatch Log Group, куда агент пишет трейсы.
Выбираете reward signal — конкретный evaluator, под который хотите оптимизировать.
Определяете объект оптимизации: system prompt или описания инструментов.

AgentCore анализирует трейсы с учётом выбранного сигнала и предлагает изменения, которые должны поднять качество по этой метрике.

Для system prompt — предлагает переписанную системную инструкцию.
Для tool descriptions — уточняет описания инструментов, не трогая их реализацию.

Рекомендации не применяются автоматически: вы сами решаете, что принять и что отправить в валидацию.

4. Configuration bundles: версионирование изменений

Чтобы не смешивать код и конфигурацию, AgentCore использует configuration bundles:

Вы создаёте один бандл для текущей конфигурации.
Второй — для конфигурации с рекомендациями.
Агент на рантайме читает «активный» бандл через SDK.

Если изменения касаются только промпта или описаний инструментов — достаточно переключить бандл.
Если вы меняете код, Amazon предлагает деплоить на отдельный runtime endpoint и уже его подключать как отдельный вариант в Gateway.

5. Batch evaluation: офлайн‑валидация

Дальше — офлайн‑проверка:

Берёте курируемый датасет сценариев (например, реальные диалоги или сгенерированные кейсы).
Прогоняете через нового агента (новый бандл).
Запускаете batch evaluation и считаете агрегированные метрики.
Сравниваете с базовой версией.

Обычно команды встраивают batch evaluation в CI/CD, чтобы ни одна новая конфигурация не прошла в прод без прохождения этого набора тестов.

6. A/B‑тест: проверка на живом трафике

Когда офлайн‑тесты пройдены, можно проверить гипотезу на бою через AgentCore Gateway:

Настраиваете разбиение трафика между двумя вариантами:
- Control — текущая версия агента.
- Treatment — кандидат с новой конфигурацией или новым кодом.
Варианты могут быть:
- Разными bundle versions на одном runtime (если меняете только конфиг).
- Разными gateway targets, указывающими на разные runtime endpoints (если меняется код).
Для каждой сессии онлайн‑оценка считает метрики теми же evaluators, что вы выбрали.
В отчёте по A/B‑тесту вы видите доверительные интервалы и p‑values.

Когда данных достаточно, вы:

Останавливаете тест.
Делаёте новый вариант default в Gateway.
Если что‑то пошло не так — ставите тест на паузу, и агент возвращается к прежней конфигурации.

Amazon подчёркивает, что каждый такой цикл создаёт новый «baseline» для следующей итерации — улучшения накапливаются.

Куда Amazon хочет прийти дальше

Сейчас цикл запускает разработчик: он решает, когда генерировать рекомендации, какой evaluator использовать и что отправлять в прод.

В видении Amazon:

Трейсы постоянно питают систему оценок.
Оценки автоматически находят деградацию качества.
Recommendations превращают сигнал деградации в конкретные изменения.
A/B‑тесты доказывают, что изменения работают.
Победившая конфигурация становится новой базовой.
Следующий цикл стартует уже с неё.

Планируемые направления развития:

Рекомендации учитывают несколько evaluators сразу, показывая компромиссы с конкретными цифрами.
Оптимизация выходит за рамки промпта и описаний инструментов и затрагивает навыки (skills): добавление новых или улучшение существующих на основе реального использования.
Анализ трейсов группирует продакшен‑ошибки в паттерны, которые можно чинить пакетно.
Мониторинговые алармы автоматически запускают генерацию рекомендаций и валидацию, если метрика падает ниже порога.
Итог попадает в очередь на ревью — человек принимает финальное решение, а система делает тяжёлую работу.

Что это значит для вас

Для кого это вообще нужно

AgentCore Optimization полезен, если у вас:

Есть продакшен‑агент с реальными пользователями.
Качество ответов плавает: новые сценарии, изменившееся поведение пользователей, переиспользование промптов в новых контекстах.
Разработчики тратят часы на ручной разбор трейсов и переписывание промптов.

Типичные сценарии:

Финтех и трейдинг — как в примере Market Trends Agent для брокеров: разные риск‑профили, сектора, стили общения, сложные запросы по нескольким секторам.
Поддержка клиентов — когда важно не ломать уже отлаженные сценарии и аккуратно выкатывать новые.
Внутренние ассистенты в корпорациях, где ошибки агента стоят денег или времени.

Если у вас маленький прототип без продакшен‑нагрузки, AgentCore Optimization, скорее всего, избыточен. Проще править промпты вручную и смотреть на пару десятков кейсов.

Что даёт на практике

Системный процесс вместо ручной магии
Вы перестаёте «угадывать», что сломалось, и начинаете опираться на:
- Трейсы с полным ходом рассуждений и вызовов инструментов.
- Метрики по целям, безопасности и точности.
- Статистически значимые A/B‑тесты.
Быстрая итерация
То, что раньше занимало недели ручной правки промптов, превращается в повторяемый цикл:
- Сгенерировать рекомендации из продакшен‑трейсов.
- Проверить на батче.
- Проверить на живом трафике.
- Зафиксировать победившую конфигурацию.
Безопасное обновление моделей и фреймворков
При переходе на новую модель или обновлении фреймворка вы можете:
- Создать новый бандл с изменённой конфигурацией.
- Прогнать batch evaluation по важным сценариям.
- Провести A/B‑тест на части пользователей.
- Откатиться за минуты, если что‑то пошло не так.
Меньше зависимости от централизованных команд ML
Даже если у вас есть отдельная команда Data Science и большие бенчмарки, они обычно работают недельными циклами.
Агент деградирует ежедневно, и AgentCore Optimization позволяет продуктовой команде закрывать эти дыры самостоятельно.

Где не стоит применять

Если вы не используете Amazon Bedrock AgentCore и не готовы завязывать архитектуру на AWS, эта функция вам не пригодится.
Если у вас нет продакшен‑логов и трейсинга, Recommendations просто не на что будет опираться.
Если вы не готовы вкладываться в дизайн evaluators и датасетов для batch evaluation, вы не получите адекватные сигналы качества.

Доступность и ограничения

Функция доступна в превью через Amazon Bedrock AgentCore.
Работает в тех регионах AWS, где уже есть AgentCore Evaluations.
На этапе превью Optimization умеет оптимизировать только system prompt и описания инструментов.
Нужны: AgentCore Runtime, Observability и Evaluations.

Для пользователей из России важный момент:

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

Место на рынке

AgentCore Optimization — это не новая LLM, а надстройка над уже существующей экосистемой Amazon Bedrock для оркестрации и оптимизации агентов.

По сути, Amazon конкурирует здесь не с GPT‑4o или Claude 3.5, а с:

Фреймворками оркестрации (LangChain, LlamaIndex и т.п.), где A/B‑тесты и офлайн‑оценка обычно собираются вручную.
Внутренними тулчейнами крупных компаний, которые уже строили свои пайплайны batch evaluation и A/B‑тестов.

Конкретных цифр сравнения по скорости, стоимости запросов или качеству против других решений Amazon не приводит.
Фокус — на том, что теперь весь цикл «наблюдать → оценивать → улучшать → проверять на проде» можно собрать внутри одной AWS‑платформы, без кустарных связок логов, дашбордов и самописных скриптов для A/B‑тестов.

Если вы уже живёте в AWS и используете Bedrock, AgentCore Optimization логично ложится в существующую инфраструктуру.
Если ваш стек строится вокруг других облаков или on‑prem, вам придётся сравнивать с собственными пайплайнами и сторонними тулчейнами по трудозатратам и удобству, а не по сухим числам — Amazon их не приводит.

Как запустить и с чего начать

Amazon не приводит конкретные команды или фрагменты кода, но описывает общий путь старта:

Включить AgentCore Observability и Evaluations
- Настроить запись трейсов агента в CloudWatch Log Group.
- Подключить нужные evaluators (встроенные или кастомные LLM‑as‑judge).
Подготовить датасет для batch evaluation
- Взять реальные сессии или собрать сценарии руками.
- При необходимости — сгенерировать дополнительные кейсы с помощью LLM‑актора, который имитирует конечного пользователя.
Запустить Recommendations API
- Указать Log Group с продакшен‑трейсами.
- Выбрать целевой evaluator (reward signal).
- Задать объект оптимизации: system prompt или tool descriptions.
- Просмотреть и отредактировать предложенные изменения.
Собрать configuration bundles
- Создать бандл с текущей конфигурацией.
- Создать бандл с рекомендациями.
- Убедиться, что агент читает конфигурацию динамически через AgentCore SDK.
Прогнать batch evaluation
- Запустить агента с новым бандлом на подготовленном датасете.
- Сравнить агрегированные метрики с базовой версией.
- При необходимости — автоматизировать этот шаг в CI/CD.
Настроить A/B‑тест через AgentCore Gateway
- Задать два варианта: control и treatment.
- Разделить трафик (например, 90/10 или 50/50).
- Следить за метриками, доверительными интервалами и p‑value.
- После достаточного накопления данных промоутнуть победителя или откатиться.

Запустить всё это можно через AgentCore Console или CLI.
Подробная документация и пошаговые туториалы лежат в официальной документации Amazon Bedrock AgentCore.

Пример: Market Trends Agent

Amazon показывает весь цикл на примере Market Trends Agent из GitHub — это рыночный аналитический агент для инвестиционных брокеров. Он умеет:

Работать с реальными данными по акциям.
Делать секторный анализ.
Искать новости.
Учитывать персональные профили брокеров.

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

Как выглядит полный цикл на этом примере:

Генерация рекомендаций
- Recommendations находит ситуации, где агент плохо персонализирует советы под стратегию брокера или выбирает неверный инструмент, если запрос затрагивает несколько секторов.
Сборка конфигурационного бандла
- Изменения в system prompt или описаниях инструментов упаковываются в новый bundle version.
Batch evaluation
- Новый бандл проверяется на курируемом наборе диалогов с брокерами.
- Команда смотрит, нет ли регрессий по важным сценариям.
A/B‑тест
- Новая конфигурация запускается на части реальных сессий брокеров.
- По итогам статистически значимого теста конфигурация либо идёт в прод, либо откатывается.

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