Amazon Bedrock AgentCore Evaluation 将 Agent 回归转化为失败的 Pull Request

Amazon 已将 Amazon Bedrock AgentCore evaluation 纳入可运行的 GitHub Actions 质量门禁，用四项评分测试取代主观的 Agent 检查。

该参考流水线会部署一个 AI Agent 和一个受 OAuth 保护的 Model Context Protocol 服务器，然后使用具有代表性的提示词调用 Agent。它会为生成的追踪记录评分，并在任何必需指标低于配置阈值时使 Pull Request 失败。

这改变了围绕 Agent 测试的讨论。眼下的竞争并非 AWS 与其他云服务商之间的较量，而是自动化、可重复的评估，与许多开发团队在合并 Agent 变更前仍在使用的人工抽查之间的竞争。

Amazon 于 2026 年 9 月 8 日发布了该实现。评估流水线连接了 AgentCore Runtime、AgentCore Evaluations、Amazon Cognito、CloudWatch、AWS CDK 和 GitHub Actions。

关键成果并非又一个测试仪表板。一条失败的响应如今可以在变更后的 Agent 行为进入共享环境或生产环境之前，直接导致软件构建失败。

Amazon Bedrock AgentCore Evaluation 成为合并门禁

AWS 已将 Agent 质量从评审时的主观看法，转变为 Pull Request 的合并条件。

参考工作流会在面向主分支的 Pull Request 修改 Agent 代码、MCP 服务器代码、基础设施或评估脚本时运行。它会创建一个临时开发堆栈，其中包含两个 AgentCore runtime。

其中一个 runtime 托管基于 Strands 的 Agent。另一个托管 MCP 服务器，该服务器通过标准协议暴露工具，用于连接 AI 应用与外部能力。

共享的 Amazon Cognito 用户池保护这两个 runtime。该工作流通过 AWS Cloud Development Kit 部署基础设施，然后从部署输出中读取 runtime 标识符和认证端点。

GitHub Actions 通过 OpenID Connect 联合获取临时 AWS 凭证。OIDC 允许 GitHub 用短期身份令牌交换 AWS 角色，无需在仓库密钥中保存永久 AWS 访问密钥。

该工作流仍将 AWS 角色 ARN 作为 GitHub 密钥保存。不过，生成的 AWS 凭证是临时的，并受角色信任策略和权限策略约束。GitHub 记录了这一 OIDC 安全模型。

部署后，流水线会等待两个 runtime 就绪。这一等待在运维上十分重要，因为新建的 runtime 无法立即接受请求。

AWS 表示，过早调用会返回 424 Failed Dependency 响应。提供的工作流会轮询 AgentCore 控制服务，并在开始测试运行前预热 MCP 服务器。

随后，流水线获取 OAuth 访问令牌，并向 Agent 的 HTTPS 端点发送测试提示词。每条提示词都会获得不同的会话标识符，使评估流程能够将生成的追踪记录关联到正确的交互。

示例数据集涵盖多种行为。它要求 Agent 计算简单加法、返回当前 UTC 时间、查询 Apple 股票价格，以及获取员工人数。

这些示例检验的不只是回答措辞。它们还测试内置能力、公开 MCP 工具、受保护的业务工具、工具选择，以及传入每个所选工具的参数。

评估脚本应用四个内置评估器：

• GoalSuccessRate 询问该会话是否完成了用户目标。

• Correctness 将响应与可用的预期结果或上下文进行比较。

• ToolSelectionAccuracy 检查 Agent 是否选择了合适的工具。

• ToolParameterAccuracy 检查 Agent 是否提供了恰当的参数。

参考配置将零到一评分范围内的 0.8 作为验收阈值。如果某项必需分数低于这一标准，脚本会以失败状态退出，GitHub 将该任务标记为失败。

该工作流还可以将评估结果发布到 Pull Request。评审者可以在代码变更旁直接看到量化的失败结果，而不必从日志或本地讨论中重新还原 Agent 行为。

最后，即使评估失败，清理步骤也会执行。它会销毁临时 CDK 堆栈，避免失败的 Pull Request 无限期保留运行中的开发 runtime。

这一流程形成了核心张力。人工测试或许能发现明显问题，但很少能提供每个相关 Pull Request 都必须满足的可复现规则。

为什么人工 Agent 测试正承受压力

该流水线给那些将 Agent 响应视为待检查内容，而非软件交付必须验证的产物的团队带来了压力。

传统应用测试具有明确输出。函数返回预期值，API 符合模式，或数据库操作维持某项不变量。

AI Agent 使这一模型变得复杂。它们的响应可能存在差异，而一个正确的最终句子并不能证明 Agent 采取了可接受的路径。

使用工具的 Agent 可能选择错误的服务、泄露未经授权的结果，或发送格式错误的参数。它也可能通过成本高昂或不安全的调用序列得出看似合理的答案。

提示词变更会带来另一个问题。对系统指令的微小调整，可能改变工具选择、拒答行为、响应细节，或在不相关场景中的任务完成情况。

模型更新和依赖变更会引入类似风险。传统单元测试可以确认应用能够运行，却可能遗漏行为质量的显著下降。

团队往往以人工提示词集来弥补。开发者输入几个熟悉的问题，阅读答案，并在没有明显异常时进行合并。

这种方法覆盖范围有限，判断标准也不一致。它还几乎无法提供两次修订之间哪些行为发生变化的证据。

AWS 流水线为每个相关 Pull Request 增加了统一评估路径。它部署拟议代码，运行这些代码，收集遥测数据，并应用相同的评估器。

AgentCore 使用 OpenTelemetry spans，即模型调用、工具活动和交互中其他操作的结构化记录。AgentCore Observability 会将这些追踪记录发送到 CloudWatch。

对于按需评估，流水线从特定会话中选择 spans，并将其传递给评估服务。评估模式还包括在线监控和异步批量分析。

这一差异对交付团队很重要。按需评估适合 Pull Request，因为它针对一小组受控交互，并返回详细评分。

在线评估服务于不同目的。它会对已部署流量进行采样，并在发布后追踪行为，此时真实用户会产生测试数据集未预见的请求。

批量评估处理更大规模的会话集合。它更适合基线比较、定期审计，以及变更前后分析。

Pull Request 门禁并不替代这些模式。它将最早可量化的检查点推进到更接近代码变更的位置。

这种方法还改变了必须对回归作出响应的人。没有门禁时，质量团队或用户往往在部署后才发现问题。

有了必需的 GitHub 检查，作者必须在合并前处理失败行为。反馈会在相关代码和提示词决策仍然清晰时到达。

这对维护共享 Agent 的团队尤其有用。对某位开发者看似可接受的响应变更，可能破坏另一个团队负责的工具工作流。

经过整理的评估数据集可以保留这些预期。它会成为一份可执行记录，说明 Agent 必须持续完成哪些任务。

开发者仍需访问这些预期背后的支撑上下文。工程知识库可以帮助团队将评估案例与规格说明、事故和设计决策联系起来。

更大的转变在于组织层面。Agent 质量成为可合并变更定义的一部分，而不再是有人有足够时间时才进行的可选评审。

OAuth 使端到端测试比评分更困难

难点不在于请求评估分数，而在于在无头 CI runner 中复现受保护 Agent 的完整工具路径。

参考架构将 Agent 和 MCP 服务器都置于 Cognito 保护之下。交互式用户通过授权码流程进行认证，并接收包含 scope 和自定义角色声明的令牌。

这些角色决定用户可以访问哪些 MCP 工具。财务用户和 HR 用户不应自动获得相同的业务能力。

GitHub Actions 没有交互式用户。它无法打开同意页面、完成浏览器登录，并将某个人的角色上下文带入测试。

AWS 提出了三种处理这一不匹配的方式。每种方式验证系统的不同部分。

第一种方法是评估已存储的追踪记录。预发布流程会预先调用 Agent、捕获具有代表性的遥测数据，并将这些追踪记录保存为测试夹具。

Pull Request 任务无需调用实时 Agent 或 MCP 服务器，即可评估这些夹具。这种方法具有可预测性，并避免了 CI 认证问题。

但它也有严重局限。分数描述的是此前捕获的行为，而不一定是当前 Pull Request 中的 Agent 代码行为。

已存储的追踪记录可以验证评估器变更或保留历史基线。它们无法证明新修改的 runtime 代码仍会产生预期轨迹。

第二种方法使用专用服务账户。操作人员完成一次交互式授权，并将其刷新令牌存储在密钥管理器中。

CI 随后可以作为具有明确角色的已知用户运行。这使得针对特定身份测试授权边界和工具访问成为可能。

刷新令牌会过期或失效。团队需要进行轮换、重新授权，并谨慎控制该账户的权限。

AWS 的实现选择了第三条路径：机器对机器认证。Cognito 通过 OAuth client_credentials 授权类型签发令牌。

评估脚本会将客户端 ID、客户端密钥和请求的 scope 发送至 Cognito 的令牌端点。随后，它使用返回的 bearer token 通过 HTTPS 调用 AgentCore Runtime。

MCP 中间件会将这些令牌与用户令牌区分开来。机器令牌具有 scope，但没有自定义角色声明，因此示例允许它们访问所有工具。

交互式令牌仍携带角色，MCP 服务器会为这些用户执行工具级限制。因此，同一个 Cognito 用户池同时支持 CI 访问和人工授权。

这一设计支持对 Pull Request 中代码进行实时端到端测试。Agent 可以调用已部署的 MCP 服务器，并为评估生成新的追踪记录。

不过，它并不测试角色执行。CI 身份按设计绕过了这些角色检查。

这一边界是该架构中最重要的限定条件。通过的流水线表明，机器身份能够完成被评估的任务。但这并不表明 FinanceUser 和 HRUser 会获得不同的授权结果。

同时需要这两种保障的团队，必须增加独立的授权测试。他们可以使用具有特定角色的服务账号，或直接针对 MCP 中间件进行测试。

机器凭证也会成为敏感资产。AWS 表示，只有 CI 流水线和 agent 运行时应当能够获取它。

这一主张依赖于实现细节。仓库权限、工作流审批、IAM 策略、密钥暴露、fork 行为和日志脱敏都会影响实际的安全边界。

GitHub 的 OIDC 连接保护 AWS 一侧免受长期仓库凭证的风险。但它并不能消除所有密钥，因为 OAuth 客户端仍需使用客户端密钥。

IAM 角色也应遵循最小权限原则。对 Cognito、ECR、CDK 资源、Bedrock 和 AgentCore 的广泛部署访问权限，可能会赋予超出常规 pull request 作业所需的权限。

环境保护措施可以缩小风险范围。团队可以限制哪些分支和工作流能够承担该角色，要求对不受信任的变更进行审批，并将部署角色与评估身份分离。

因此，这一架构同时测试 agent 行为和 CI 集成。授权正确性仍然是独立的验收目标。

质量门禁评估的是追踪记录，而不只是答案

Amazon Bedrock AgentCore 评估之所以重要，是因为它能够评判 agent 完成任务的路径，而不仅仅是其最终文本。

评估脚本使用 AgentCore 入门工具包收集相关的 CloudWatch 追踪记录，然后对选定会话应用评估器。

原始 Evaluate API 接受 sessionSpans，即属于同一会话的一组遥测 span。AWS 警告，将多个会话的 span 混合使用会导致验证错误。

这一会话边界使评估器能够重建一次交互。它可以检查用户输入、模型输出、所选工具、工具参数以及最终响应。

GoalSuccessRate 在会话层面运行。它判断完整交互是否实现了用户所请求的目标。

Correctness 在追踪层面检查响应。当测试提供预期响应时，它可以使用该响应。

ToolSelectionAccuracy 和 ToolParameterAccuracy 在工具调用层面运行。它们可以区分选择正确操作与正确调用该操作。

这种区分在 AWS 的刻意回归测试中产生了一个颇具启发性的结果。作者修改了系统提示词，使 agent 始终返回无帮助的拒绝回答。

GoalSuccessRate 降至 0.0。Correctness 也获得了 0.0，ToolParameterAccuracy 同样为 0.0。

ToolSelectionAccuracy 仍然获得了 1.0。该 agent 显然仍能识别适当的工具，尽管未能完成整体请求。

这正是单一综合指标可能掩盖问题的原因。不同评估器衡量彼此独立的维度，一项通过的分数无法抵消所有失败行为。

作者恢复预期的系统提示词后，GoalSuccessRate 回升至 1.0。Correctness 达到 0.9，两个工具指标均达到 1.0。

随后，这四项指标都超过了示例阈值 0.8。GitHub 解除了对 pull request 的阻塞。

AgentCore 也支持为需要预期行为的测试提供参考输入。这些输入可以包括预期响应、自然语言断言或预期工具轨迹。

轨迹描述了 agent 应调用的工具序列。AWS 为不同的工作流约束提供精确顺序、按序和任意顺序评估器。

精确顺序测试适用于每一步都依赖前一步的流程。任意顺序测试则适用于相互独立、且调用顺序不影响正确性的检索操作。

该服务也支持自定义评估器。团队可以为领域特定要求定义自己的指令、评判模型和评分尺度。

基于代码的评估器提供了更具确定性的选择。它们调用 AWS Lambda 函数，以检查模式、格式、关键词或业务规则。

这一组合很重要，因为并非每项要求都需要模型评判。JSON 有效性、禁止字段、最大调用次数和精确标识符通常可以用普通代码验证。

根据 custom evaluator guide，评估器可以在会话、追踪或工具调用层面运行。自定义逻辑可以使用模型或 Lambda 函数。

实用的门禁应让评估器类型与要求相匹配。基于模型的评分适合相关性、任务成功率或忠实度等语义质量。

确定性代码适合二元约束。工具轨迹检查适合预期的工作流结构。

最可靠的信号来自这些方法的组合。一个响应可能在语义上正确，却违反了模式；而符合模式的响应仍可能包含无关答案。

真实标准答案也需要谨慎使用。并非每个可接受答案都有唯一的准确表述，尤其是在摘要或开放式分析中。

断言可以表达必须出现的事实或行为，而无需强制要求单一响应。预期轨迹可以独立于文字风格来规定工具行为。

这使测试集不再只是提示词的集合。每个场景都可以在响应、任务和工具层面定义成功的含义。

通过的分数仍存在盲区

该门禁能够捕捉已定义的回归问题，但其可靠性取决于测试覆盖率、分数稳定性、身份设计和运行时机。

AWS 表示，完整流水线约需 10 分钟。部署、运行时启动、追踪传播和基于模型的评估共同构成了这段时长。

这一耗时对许多 pull request 而言可以接受。但它对于本地 pre-commit 检查过于缓慢，并且在频繁更新的仓库中可能成本较高。

追踪可用性带来了额外的不确定性。AWS 观察到，在调用 agent 后，追踪传播可能延迟 30 至 90 秒。

参考脚本每 30 秒重试一次，最长可持续 10 分钟。因此，在追踪记录出现之前立即查询 CloudWatch，可能会产生表面上的失败。

运行时架构带来了另一项实现难题。AgentCore Runtime 要求使用 ARM64 容器镜像，而标准的 GitHub 托管 runner 使用 x86-64 处理器。

该工作流使用 QEMU 和 Docker Buildx 进行跨平台镜像构建。这一要求会增加构建时间，并引入另一个与 agent 质量无关的潜在故障点。

最重要的限制来自基于模型的评判。LLM 评估器在多次评估同一追踪记录时，可能会给出略有不同的分数。

因此，严格的阈值可能在临界分数附近造成不稳定的 pull request。一次运行可能以 0.81 通过，另一次则可能以 0.79 失败，而代码并没有实质差异。

AWS 建议在验收阈值与期望可靠性目标之间保留余量。团队也应在将检查设为强制项之前衡量评估器方差。

重复运行可以估计这种方差，但也会增加评估用量。参考示例在五个提示词上使用四个评估器，单个 pull request 会产生 20 次评判模型调用。

来源并未为这些调用给出价格。它建议团队随着仓库和数据集增长而监控 Bedrock 用量。

测试覆盖率带来了一个熟悉但更严峻的问题。质量门禁只能衡量其数据集中包含的场景。

四五个方便的提示词无法代表所有生产请求、授权状态、故障模式、语言或对抗性输入。

示例中的机器 token 可以访问所有工具。因此，端到端运行并不能证明基于角色限制的工具仍能免受普通用户访问。

宽泛的分数也可能掩盖表现不均衡的问题。整体平均分可能通过，但某个关键场景却失败。

高风险任务应具备场景级要求。薪资操作、账户删除或个人数据查询，不应从若干简单算术提示词中借用成功分数。

指标同样需要明确负责人。开发人员必须知道由谁批准阈值调整、添加新场景以及调查评估器分歧。

否则，失败的门禁可能会造成降低阈值的压力。组织随后会以削弱衡量标准的方式维持交付速度。

虚假的信心是另一项风险。绿色检查标记仅表示被测试版本在某一时刻满足了指定标准。

它并不保证每一个响应正确，不能消除提示词注入，也无法验证已部署测试栈之外的基础设施。它同样不能替代安全审查。

生产遥测仍然至关重要，因为用户会发现精选数据集遗漏的组合。AgentCore 的在线评估可以抽样实时会话并将结果发布到 CloudWatch。

results documentation 表示，在线评分会显示为 CloudWatch 指标。详细的评估事件存储在专用日志组中。

批量评估随后可以在模型、提示词或工具变更前后比较更大的时间窗口。这种比较提供的基线强于单次 pull-request 运行。

成熟的系统应将这些阶段连接起来。生产故障应成为新的评估场景，而反复出现的 CI 故障应为 agent 设计提供参考。

当数据集会随着事故持续演进时，质量门禁最具可信度。静态基准最终会奖励对测试的熟悉程度，而非可靠行为。

第一个 GitHub Actions 门禁之后需要关注什么

接下来的考验是，团队能否让这些门禁足够稳定、具备安全意识且具有代表性，从而成为必需检查项。

第一个信号是在 pull-request 工作流中采用真实标准答案和确定性评估。四项内置指标提供了有用的起点，但它们无法表达每一项业务规则。

关注团队是否为高价值场景添加预期响应、断言和工具轨迹。Lambda 检查使用量的增加将表明，agent 评估正在成为常规的软件验证手段。

这一发展将加强 Amazon Bedrock AgentCore 评估的价值主张。它将减少对单一模型评判的依赖，并使某些故障更容易复现。

第二个信号是具备角色意识的 CI 覆盖。AWS 公开指出了机器 token 的局限，因为其选定流程绕过了用户角色检查。

团队应发布能够测试不同用户身份、且不会造成脆弱 refresh-token 操作的模式。服务账号、直接授权测试和隔离测试租户都是可行路径。

如果特定角色的检查变得普遍，该架构将更接近完整的端到端保障。如果这些检查仍然独立存在或完全缺失，那么绿色 agent 分数对授权正确性的说明将非常有限。

第三个信号是 pull-request 门禁与生产结果之间的连接。没有来自真实会话的反馈，小型开发数据集无法持续保持代表性。

关注那些将低分生产追踪记录提升为经审查回归用例的工作流。在线监控应发现故障，而精选的 CI 测试应防止这些故障再次出现。

AWS 的数据集评估工具也是另一项相关发展。其 dataset runners 可以调用 agents、等待遥测数据，并通过协调流程评估场景。

更广泛的采用将减少参考工作流中目前可见的自定义编排工作。它也将使更大型、具备版本管理的评估集更易于维护。

对开发者而言，实际问题已不再是是否应测试智能体响应，而是哪些行为必须阻止合并、哪些需要监控，以及哪些必须通过确定性机制强制执行。

先从那些会导致回滚、安全事件或关键业务流程中断的失败情形入手。为每一种情形明确设定场景，并采用与其风险相匹配的评估方法。

随后有意破坏智能体，确认质量门禁会因预期原因而失败。只有在捕获到已知回归后，一项检查才值得信赖。

Amazon 已提供了一条可信路径：从提示词测试走向 GitHub 必需状态检查。下一步取决于工程团队：界定他们拒绝发布的行为，将其编码实现，并持续更新这一定义。