agents-optimize

Этот официальный skill AWS посвящён измерению и улучшению качества, производительности и стоимости агентов Amazon Bedrock AgentCore. Он помогает выбрать между оценкой ответов, непрерывным контролем качества, CI/CD quality gate, логами, метриками, трассировкой, CloudWatch, X-Ray и оптимизацией расходов. Карточка специально отделяет медленный, но корректный маршрут от диагностики сломанных сценариев: для конкретных ошибок, неправильных ответов или crash в исходнике указан agents-debug, а для production security hardening — agents-harden. Входом может быть цель оценки, например add a quality gate, задача по наблюдаемости вроде set up CloudWatch dashboard или understand my traces, конкретный тип evaluator — llm-as-a-judge либо code-based — или пустой аргумент. Пустой запрос не является ошибкой: skill предлагает определить направление по контексту проекта. Такая форма полезна, когда сначала нужно понять, какие настройки уже существуют, а не сразу генерировать конфигурацию поверх неизвестного AgentCore-приложения. Первый шаг workflow — проверить версию командой agentcore --version. Требование источника — версия 0.9.0 или новее. Затем читается agentcore/agentcore.json: этот файл нужен, чтобы увидеть существующие evaluators, online eval configs и настройку агента. Если файла нет, skill прямо сообщает, что проект не готов к этому маршруту, и предлагает agents-get-started. Это важная граница: отсутствие AgentCore-контекста не компенсируется общими советами о мониторинге и не должно приводить к подмене проекта вымышленной конфигурацией. После чтения контекста выбирается ветка работы. Для измерения качества, evaluator, eval, CI/CD gate или online monitoring используется reference evals.md. Для CloudWatch dashboard, X-Ray, logs, metrics, traces и observability — reference observability.md. Для понимания или снижения стоимости — reference cost.md. Если пользователь одновременно хочет понять и улучшить агента, workflow начинает с наблюдаемости, затем переходит к оценкам. Такой порядок сначала делает поведение агента видимым, а уже потом добавляет измеримый quality control. Критерии результата также определены источником. Конфигурация evaluator должна использовать действительные CLI-флаги; online eval sampling rate должна быть осмысленной и не приниматься равной 100% в production без обсуждения; CI/CD gate должен иметь ясный порог pass/fail; наблюдаемость должна включать и tracing, и logging. Поэтому просто включить логирование недостаточно для заявленной цели «понять поведение», а просто добавить evaluator недостаточно для непрерывного quality gate. Практические сценарии включают проверку качества ответов, настройку регулярного мониторинга, добавление порога в CI/CD, разбор логов и traces, создание CloudWatch dashboard, использование X-Ray и оценку затрат. При этом skill не обещает готовый результат без чтения reference-файла: конкретный output зависит от выбранного workflow. Отдельное ограничение по времени данных — примерно 10 секунд от put до get end-to-end; один ingestion step покрывает чтение traces и eval queries, отдельная пауза индексации не предусмотрена. Это нужно учитывать при проверке свежих результатов и при формулировке pass/fail.