AI辅助整理：本文基于下方列出的公开原始来源改写，不代替原文。
核心摘要： AWS官方博客介绍了一套可运行的CI/CD质量门禁：用CDK把Strands智能体与MCP服务器部署到AgentCore运行时，通过GitHub Actions在每次PR时调用AgentCore Evaluate API，按GoalSuccessRate、Correctness、ToolSelectionAccuracy、ToolParameterAccuracy四个内置评估器打分，低于0.8阈值即阻断合并。文章还给出CI在OAuth保护下的三种鉴权路径，并说明M2M令牌按设计绕过角色校验的边界。
业务背景：智能体上线后，质量退化往往无人发现
当企业把智能体放进客服、销售或内部服务流程后，真正的风险点常常不是模型本身，而是某次看似普通的改动：有人调整了系统提示词，有人换了模型，有人改了工具配置。这些变更在代码评审里很难看出好坏，等到用户反馈变差时，问题已经进入生产环境。
AWS这篇官方博客给出的判断很直接：没有自动评估，智能体质量就是主观的。开发者改了提示词，智能体开始给出更差的回答，但没人注意到，直到用户投诉。
问题定义：CI没有用户身份，怎么评估受OAuth保护的智能体
文章设定的场景是：智能体部署在AgentCore运行时，通过MCP服务器调用工具，其中部分工具按用户角色限制访问。每次代码变更后，团队都想知道智能体是变好还是变差，但人工测试无法规模化。
难点在于鉴权。CI流水线没有交互式用户上下文，而MCP服务器期望携带角色声明的令牌。文章因此给出三条路径：评估已存轨迹、使用预授权测试账号、以及机器对机器凭证，并逐条说明取舍。
AI怎么落地：把评估做成合并前的硬门禁
方案用CDK一次性部署两个AgentCore运行时——一个跑Strands智能体，一个跑MCP服务器，二者共用一个Cognito用户池。GitHub Actions在每次PR时部署开发环境、获取令牌、用评估数据集调用智能体，再从CloudWatch读取轨迹并打分。
评估使用AgentCore Evaluate API，按需评估模式直接接收会话轨迹数据。文章选用了四个内置评估器：目标达成率、正确性、工具选择准确率、工具参数准确率。任一指标低于0.8，PR保持阻断状态。
实施步骤：从部署到阻断的完整链路
第一步，用CDK部署Cognito、两个运行时、IAM角色与预置测试用户。第二步，工作流轮询运行时状态，等待其进入就绪后再预热MCP服务器，避免过早调用返回失败。第三步，统一评估脚本完成取令牌、调用智能体、等待轨迹、执行评估、按阈值判定。
第四步，评估结果以评论形式回写到PR，随后无论成败都销毁环境，避免持续计费。文章还提醒，轨迹传播需要30到90秒，脚本按30秒重试、最长等待10分钟。
结果证据与边界：故意改坏提示词，门禁确实拦住了
文章记录了一次刻意制造的回归：把系统提示词改成对任何问题都回答“我无法帮助你”。流水线运行后，目标达成率与正确性均为0.0，工具参数准确率为0.0，整体判定失败。恢复提示词后重跑，四项指标分别为1.0、0.9、1.0、1.0，全部通过。
边界同样明确：工具选择准确率在坏提示词下仍可能通过，因为评估器各自独立衡量不同维度；LLM评审分数存在固有波动，同一提示词两次评估可能略有差异，阈值应设在目标可靠性之下留出余量。
可复制动作：先跑通轻量门禁，再上端到端
如果团队刚开始做智能体治理，建议先用“评估已存轨迹”的方式：预发环境跑一轮代表性提示词，把轨迹固化为样本，CI只做确定性打分，完全绕开OAuth难题。
当需要验证当前PR的真实代码变更时，再升级到端到端方案，为CI配置独立的机器对机器凭证，并清楚记录该凭证按设计绕过角色校验这一事实。若必须测试角色限制本身，则应改用预授权测试账号路径。
证据与边界
- 来源为AWS官方博客，正文含完整代码与工作流示例。
- 评估阈值0.8、四个内置评估器名称均来自原文。
- M2M令牌绕过角色校验为原文明确说明的设计取舍。
- LLM评审分数存在波动、需留阈值余量为原文提示。
企业今天可以做什么
建议先采用“评估已存轨迹”的轻量路径，把预发环境的对话轨迹固化为测试样本，在CI中跑通门禁；再逐步过渡到端到端方案，为CI单独配置机器对机器凭证，并明确该凭证绕过角色校验的适用范围。评估器从四到五个起步，面向客户的智能体再补充安全类评估器。