AWS博客详细介绍如何在CI/CD流水线中自动部署智能体、调用评估API，并在评分下降时阻止PR合并。
AI解读：这篇AWS博客针对的是AI智能体开发中的真实痛点：改动系统提示词或工具配置后，智能体表现可能悄悄变差，等到用户抱怨才发现。文中给出的方案是在GitHub Actions里部署一套CI门禁：每次PR触发时，用CDK把智能体和MCP服务器部署到AgentCore runtime，用测试提示词调用它，再用AgentCore内置评估器（LLM作为裁判）对响应打分，分数低于阈值（示例是 0.8）就自动阻止合并。对开发者来说，这意味着质量检查从“靠感觉”变成“跑流水线”，回归在代码合并前就被拦住。文中最实际的价值是解决了CI无用户上下文时如何访问OAuth保护的MCP工具的问题——它提供了三条路径：评估静态trace、使用缓存刷新令牌的测试用户，或配置MCP服务器同时支持M2M和用户授权（本文主推）。M2M方式用客户端密钥换取无角色令牌，可访问全部工具，但无法测试角色权限；若需测试角色限制则要用测试用户方式。这套方案适合已有AgentCore部署、想加自动化质量门的团队，普通用户无需立即行动。
AWS机器学习博客发布了一篇技术文章，介绍如何用Amazon Bedrock AgentCore和GitHub Actions构建自动化智能体评估流程，将其作为CI/CD质量门禁。该方案在每次PR时自动部署智能体到AgentCore runtime，用测试提示词调用，通过AgentCore Evaluations API评分，当评分低于阈值（示例为 0.8）时阻止PR合并。参考实现代码已发布在随附的GitHub仓库中。
背景：为什么需要自动化评估
文章指出，没有自动化评估时，智能体质量是主观的：开发者改动系统提示词后，智能体可能给出更差的回答，但没人注意，直到用户抱怨。质量门禁能在PR阶段就发现问题。文章以一个部署在AgentCore runtime上的Strands智能体为例，该智能体通过受OAuth保护的MCP服务器调用工具，部分工具按用户角色受限。
AgentCore Evaluations的评估模式与评判器
AgentCore Evaluations是Amazon Bedrock AgentCore平台中的质量度量层，使用LLM-as-a-judge默认对交互评分，也支持通过Lambda进行基于代码的评估。它基于OpenTelemetry trace工作，与AgentCore Observability捕获的trace一致。
评估支持三种模式：按需评估（针对特定会话，提供span数据，用于CI/CD质量门禁）；在线评估（持续监控生产流量，可配置采样率，结果进入CloudWatch仪表盘）；批处理评估（在单个异步任务中评分多个会话，用于基线和回归测试）。
评判器分四类：内置评判器涵盖帮助性、正确性、目标成功率、工具选择准确性、工具参数准确性等，以及三个轨迹评判器（TrajectoryExactOrderMatch、TrajectoryInOrderMatch、TrajectoryAnyOrderMatch）；自定义评判器使用自己的LLM-as-a-judge提示词；基于代码的评判器运行Lambda函数进行确定性检查；第三方评判器来自DeepEval和AutoEval开源库，由服务托管。Evaluate API接受sessionSpans（来自CloudWatch的OpenTelemetry trace数据），每次调用只能包含单个会话的spans，否则返回ValidationException。可选提供ground truth字段（expectedResponse、assertions、expectedTrajectory），无ground truth时自动回退到无ground truth评估。
处理CI中OAuth保护的MCP服务器：三种方法
文章详细分析了CI流水线无用户上下文时如何访问受OAuth保护的MCP服务器。方法A（评估存储的trace）：解耦评估与实际MCP调用，CI时仅评估静态JSON fixture中的trace，无需实时调用，完全绕开OAuth问题，但评估的是staging部署而非当前PR代码。方法B（测试用户）：创建专用测试用户，手动完成一次OAuth consent，将refresh token缓存在AWS Secrets Manager，CI用该token调用智能体；缺点是refresh token会过期，需要轮换机制。方法C（M2M认证，本文主推）：配置MCP服务器同时支持M2M和用户授权类型，CI用M2M令牌（client_credentials流程），交互用户走标准OAuth consent。M2M令牌含scopes但不含角色，因此绕过角色检查，可访问所有工具；用户令牌带custom:roles声明，强制工具级访问控制。这种绕过是安全的，因为M2M令牌需要客户端密钥，不会暴露给终端用户。文章建议从方法A快速建立质量门禁，再升级到方法C测试真实PR代码。
- 方法A：无需实时调用，适用于快速启动，所有MCP服务器兼容，CI确定性高，但不能测试角色。
- 方法B：实时调用，可测试角色，但需要令牌轮换机制。
- 方法C：实时调用，需要服务器支持双令牌认证，适合内部工具智能体，M2M绕过角色检查。
实现：三层MCP认证、CDK部署与评估脚本
文章详细说明了方法C的MCP服务器三层认证模式：第一层JWT验证由AgentCore平台通过Custom JWT Authorizer处理；第二层在AgentCore runtime上设置request_header_allowlist=["Authorization"]，将JWT透传到智能体和MCP容器；第三层是FastMCP原生中间件AuthMiddleware，读取JWT并解码claims，根据custom:roles强制工具访问——M2M令牌（无角色）获得完全访问，用户令牌需要匹配角色。
CDK堆栈部署Cognito用户池（含M2M应用客户端和用户应用客户端）、两个AgentCore runtime（一个用于MCP服务器，一个用于Strands智能体）、IAM角色和两个预创建测试用户（user-a为FinanceUser，user-b为HRUser）。
评估脚本（scripts/agentcore_eval.py）处理完整流程：获取M2M令牌（client_credentials授权）、等待runtime READY、通过HTTPS Bearer调用智能体、等待trace、使用bedrock-agentcore-starter-toolkit的Evaluation类运行评估、根据阈值门禁。评估提示词覆盖内置工具、公共MCP工具和角色受限的MCP工具。
GitHub Actions工作流在每次PR到main（涉及智能体代码、MCP服务器、基础设施或脚本）时运行：检出代码、配置AWS凭证（通过GitHub OIDC提供程序）、CDK部署、提取输出、重启runtime以加载新镜像、运行评估脚本、发布结果作为PR评论，并在finally中摧毁堆栈。文章警告：CDK deploy返回后runtime处于CREATING状态，需轮询直到READY，否则调用会失败（424 Failed Dependency）。
设置CI/CD组件与文档中未提及的限制
要启用CI/CD需一次性创建GitHub OIDC provider、创建信任策略指向仓库的IAM角色，并在GitHub secrets中添加AWS_ROLE_ARN。
文章指出，方法C的M2M令牌绕过角色检查是设计使然；若需要CI测试角色强制，需使用方法B。内置评判器和第三方评判器均通过ID引用，无需配置模型。参考实现可帮助开发者快速落地，但文中未提供实际效果数据。