用 Amazon Bedrock AgentCore 与 GitHub Actions 做自动化智能体评估

#用 Amazon Bedrock AgentCore 与 GitHub Actions 做自动化智能体评估

_构建一个持续集成与持续交付（continuous integration and continuous delivery, CI/CD）质量门禁：部署带有基于角色的 MCP 工具的智能体，评估它，并在评估分数下降时阻止拉取请求（Pull Request, PR）。_

你已经把一个人工智能（Artificial Intelligence, AI）智能体部署在 Amazon Bedrock AgentCore runtime 上。它通过受 OAuth 保护的 MCP 服务器 调用工具。现在你希望 CI 在代码变更到达生产之前告诉你：这次改动是否让它的表现变差。

本文逐步说明一条 GitHub Actions 流水线：它把智能体部署到 AgentCore runtime，并用评估提示通过 AgentCore Evaluate API 评估该智能体。如果智能体退步，PR 失败。

我们将覆盖完整技术栈：一个连接到带基于角色的访问控制的 MCP 服务器的 Strands 智能体、一个同时服务机器到机器（machine-to-machine, M2M）和用户范围认证流的共享 Cognito 用户池、CDK 基础设施即代码，以及一份统一的评估脚本。完整参考实现见配套仓库。

本文涵盖的内容

• 使用 CDK 把智能体和 MCP 服务器部署到 AgentCore runtime。
• MCP 工具上的基于角色的访问控制（三层认证模式）。
• 从 CI 调用受 OAuth 保护的运行时（M2M client_credentials 流）。
• 使用内置评估器运行按需评估。
• 实施质量门禁，在退步时阻止合并。
• 处理 OAuth 难题：CI 流水线如何在没有用户上下文时认证。

关键概念

深入之前，这里简要介绍构建块。如果你已经熟悉，可以跳过。

• AgentCore runtime 是 AI 智能体的托管平台。你部署智能体代码（Python，任意框架），AgentCore 处理扩缩、会话隔离和基础设施。可以把它看成面向智能体的 AWS Lambda。
• AgentCore Evaluations 是 Amazon Bedrock AgentCore 的一项能力，使用大语言模型（Large Language Model, LLM）作为评判者来给智能体行为打分。它读取来自 Amazon CloudWatch 的 OpenTelemetry 跟踪，并在有帮助程度、正确性、工具选择准确率等维度上评价响应。
• MCP（Model Context Protocol，模型上下文协议） 是一种开放协议，智能体通过标准化接口调用外部工具。MCP 服务器暴露工具。智能体发现并调用它们。AgentCore runtime 可以托管 MCP 服务器 并把智能体连接到它们。
• OpenID Connect（OIDC）联邦 是 GitHub Actions 在不存储长期凭证的情况下担任 AWS Identity and Access Management（AWS IAM）角色的方式。GitHub 签发短期令牌，AWS 核验它，工作流获得临时凭证。
• 质量门禁（Quality Gate） 是一种 CI/CD 模式：流水线步骤必须通过阈值，构建才能继续。在我们的场景中，智能体的评估分数必须达到最低标准（例如 1.0 分中的 0.8），否则 PR 保持被阻止。

为什么这重要： 没有自动化评估，智能体质量是主观的。开发者改了系统提示。智能体开始给出更差的回答，直到用户抱怨才有人注意到。质量门禁在 PR 阶段、到达生产之前抓住这一点。

问题

场景如下。你有一个部署在 AgentCore runtime 上的智能体。它通过 MCP 服务器调用工具，其中一些工具是公开的，另一些按用户角色限制。每当有人更改系统提示、更换模型或更新工具配置，你都想知道：智能体变好了还是变差了？

手工测试无法扩展。你需要 CI 中的自动化评估。这意味着在开发环境中自动部署智能体，用有代表性的提示调用它，给响应打分，并在质量下降时阻止合并。

复杂之处在于：你的 MCP 服务器使用带基于角色的访问控制的 OAuth。CI 流水线没有用户上下文。你如何让一条无头流水线向一个受 OAuth 保护、并且会把令牌转发给期望用户角色的 MCP 服务器的智能体认证？

AgentCore Evaluations：它处在什么位置

AgentCore Evaluations 是 Amazon Bedrock AgentCore 平台中的质量测量层。它与托管你的智能体的 AgentCore runtime，以及捕获跟踪的 AgentCore Observability（Amazon Bedrock AgentCore 的一项能力）并列，完成构建 → 部署 → 观察 → 评估的生命周期。

该服务默认使用 LLM 作为评判者来给智能体交互打分，并可通过 AWS Lambda 选择基于代码的评估。它操作 OpenTelemetry 跟踪，也就是你的智能体已经通过 AgentCore Observability 发出的那些跟踪。对于按需评估，你在 API 调用中直接提供跨度数据；在线和批量评估从 CloudWatch 读取。

三种评估模式覆盖不同阶段：

• 按需评估在任意时间评估特定会话。你提供跨度数据，选择评估器，并取回分数。这为 CI/CD 质量门禁提供动力，也是本文的重点。
• 在线评估以可配置的采样率持续监控生产流量。结果进入 CloudWatch 仪表盘，用于趋势监控。
• 批量评估在单个异步作业中给多个会话打分。你把它指向 CloudWatch Logs，选择评估器，并得到汇总结果和按会话的结果。这为基线测量和变更前后的回归测试提供动力。

评估器分为四类：

• 内置评估器覆盖常见质量维度：Helpfulness、Correctness、GoalSuccessRate、ToolSelectionAccuracy、ToolParameterAccuracy 等。它们在会话、跟踪和工具调用层级运作。三个轨迹评估器（TrajectoryExactOrderMatch、TrajectoryInOrderMatch、TrajectoryAnyOrderMatch）把实际工具调用序列与期望轨迹比较。
• 自定义评估器使用你自己的 LLM 作为评判者提示，做领域特定打分。真值字段（expectedResponse、assertions、expectedTrajectory）也可以作为自定义评估器提示中的占位符。
• 基于代码的评估器针对每条跟踪或每个会话运行一个 Lambda 函数，并返回由你的自定义实现计算的分数、标签和解释。把它们用于确定性检查，例如正则匹配、模式验证或关键词存在，而不产生 LLM 费用。
• 来自 DeepEval 和 AutoEval 开源库的第三方评估器由该服务像内置评估器一样管理。按 ID 选择一个，不需要模型或配置。你也可以从内置或第三方评估器派生自定义评估器，以便在你自己的模型上运行其逻辑。

Evaluate API 接受 sessionSpans（来自 CloudWatch 的 OpenTelemetry 跟踪数据）并返回结构化分数。每次 evaluate() 调用必须只包含单个会话的跨度。混合会话会导致 ValidationException。

该 API 还通过 evaluationReferenceInputs 接受可选真值。你可以提供 expectedResponse（由 Correctness 使用）、assertions（由 GoalSuccessRate 使用）或 expectedTrajectory（由轨迹评估器使用）。没有真值的跟踪回退到无真值评估，因此你只需要为你关心的轮次提供它。

架构

该流水线在一个共享的 Cognito 用户池后面部署两个 AgentCore runtime。一个 AgentCore runtime 用于 Strands 智能体，一个用于 MCP 服务器：

架构图，展示共享 Amazon Cognito 用户池后面、位于 Amazon Bedrock AgentCore 上的 Strands 智能体运行时和 MCP 服务器运行时，以及调用智能体并评估跟踪的 GitHub Actions 流水线

单个 Cognito 用户池服务两种认证流：

GitHub Actions 流水线把智能体堆栈部署到开发环境，从已预配的 Cognito 实例检索 JWT 令牌以认证 API 调用，用评估数据集调用智能体，并分析 Amazon CloudWatch Logs 中生成的跟踪，以对照已定义阈值评估表现。它根据总体分数是否满足验收标准，自动批准或阻止 PR。

在 CI 中处理受 OAuth 保护的 MCP 服务器

当你的智能体调用受 OAuth 保护的 MCP 服务器时，CI 流水线面临一个挑战：它们没有用户上下文。MCP 服务器期望带有角色声明的 JWT，但无头 CI 运行器无法完成交互式 OAuth 同意流。

评估智能体有三种方法，各自有不同取舍：

方法 A：评估已存储的跟踪

把评估与实时 MCP 调用完全解耦。一条预发流水线用有代表性的提示运行智能体，捕获跟踪，并把它们作为 JSON 夹具提交。到了 PR 时间，CI 评估那些已存储的跟踪。不需要实时调用。

Evaluate API 不需要一个正在运行的智能体。它给你提供的 OpenTelemetry 跨度打分。你的 CI 流水线变得确定（检查已有跟踪），并且你完全绕开 OAuth 问题。

取舍： 你评估的是预发部署的行为，而不是当前 PR 中的代码。配套仓库包含 scripts/evaluate_stored_traces.py 以及 fixtures/ 中的示例夹具，以便开始使用这种方法。

方法 B：带预先授权同意的服务账户

在你的身份提供者中创建一个专用测试用户。交互式地完成一次 OAuth 同意流，把刷新令牌缓存在 AWS Secrets Manager 中。CI 使用这个令牌，以该测试用户身份调用智能体。

取舍： 刷新令牌会过期。你需要轮换机制或定期手工重新同意。

方法 C：M2M 认证（本文采用的方法）

把你的 MCP 服务器配置为同时支持 M2M 和用户范围的授权类型。CI 使用 M2M 令牌，交互式用户走标准 OAuth 同意流。

MCP 服务器中间件区分令牌类型：M2M 令牌包含范围但不包含角色，因此绕过角色检查，全部工具可访问。用户令牌携带 custom:roles 声明，因此实施工具级访问控制。这种绕过是安全的，因为 M2M 令牌需要一个从不向终端用户暴露的客户端密钥。只有 CI 流水线和智能体运行时能够取得这些令牌，从而防止不受信任的调用者取得无角色令牌。

取舍： M2M 令牌按设计绕过角色检查。如果你需要 CI 专门测试角色强制，请使用方法 B。

用下面的决策树找出哪种方法适合你的用例：

根据是否需要实时调用、MCP 服务器兼容性和角色测试，在评估方法 A、B、C 之间选择的决策树

提示： 先用方法 A 快速跑起质量门禁。再进阶到方法 C（本文），以获得测试当前 PR 代码变更的完整端到端 CI。

先决条件

• 具有 AgentCore 访问并已 引导 CDK 的 AWS 账户。
• 已安装并正在运行的 Docker。
• Python 3.12+、Node.js 20+。
• 安装所需 Python 包：pip install boto3 requests bedrock-agentcore-starter-toolkit

注意： bedrock-agentcore-starter-toolkit 中的 Evaluation 类会自动处理从 CloudWatch 收集跟踪和打分，因此你不需要手工查询日志组或调用原始 Evaluate API。

MCP 服务器：三层认证

对于方法 C，MCP 服务器使用三层来同时支持 M2M 和用户范围令牌。这是使 CI 评估与生产角色强制并存的关键模式。

第 1 层 JWT 核验（AgentCore）： 平台在请求到达你的代码之前核验签名、签发者、受众和过期时间。不需要实现。AgentCore 通过 Custom JWT Authorizer 处理这一点。

第 2 层请求头透传： 两个运行时上的 request_header_allowlist=["Authorization"] 确保 JWT 到达智能体和 MCP 容器。AgentCore 把调用者的 Authorization 头原样转发到你的容器。

# infrastructure/stack.py — on both CfnRuntime constructs
request_header_configuration=CfnRuntime.RequestHeaderConfigurationProperty(
    request_header_allowlist=["Authorization"]
)

第 3 层基于角色的工具访问（AuthMiddleware）： 一个 FastMCP 原生中间件，通过 fastmcp.server.dependencies.get_http_headers() 读取 JWT，使用 PyJWT 解码声明，并对照工具 meta 强制 custom:roles。M2M 令牌（有范围但无角色）获得完全访问。用户令牌需要正确的角色。

该中间件被直接加到 FastMCP 服务器实例：

mcp.add_middleware(AuthMiddleware())
app = mcp.http_app(stateless_http=True)

基础设施：CDK 堆栈

CDK 堆栈用一条命令部署全部内容：Cognito 用户池、两个运行时、IAM 角色和预先创建的测试用户。完整实现见 infrastructure/stack.py。

该堆栈创建的关键资源包括：

• 一个 Cognito 域。
• 一个用于 CI 的 M2M 应用客户端（client_credentials 流）。
• 一个用于交互使用的用户应用客户端（authorization_code 流）。
• 两个预先创建的用户：user-a（FinanceUser）和 user-b（HRUser）。
• 一个 MCP 服务器 AgentCore runtime（协议：MCP），带 JWT 授权器。
• 一个 Strands 智能体 AgentCore runtime（协议：HTTP），带 JWT 授权器。

# Deploy everything
python3 -m venv .venv && source .venv/bin/activate
pip install .
npx cdk deploy --outputs-file outputs.json

GitHub Actions 工作流在开发环境中部署 CDK 堆栈，并使用所创建的资源运行评估。

评估脚本

统一评估脚本（scripts/agentcore_eval.py）处理完整流水线：取得令牌、等待运行时、调用智能体、等待跟踪、运行评估，并按阈值做门禁。

令牌获取使用标准的 client_credentials 授权。

# scripts/agentcore_eval.py (key excerpt)
def get_token() -> str:
    """Client-credentials grant"""
    resp = http_requests.post(
        os.environ["TOKEN_ENDPOINT"],
        data={
            "grant_type": "client_credentials",
            "client_id": os.environ["OAUTH_CLIENT_ID"],
            "client_secret": os.environ["OAUTH_CLIENT_SECRET"],
            "scope": os.environ.get("OAUTH_SCOPE", ""),
        },
    )
    resp.raise_for_status()
    return resp.json()["access_token"]

智能体调用使用带 Bearer 令牌的 HTTPS（不是 boto3）：

def invoke_agent(agent_arn, session_id, prompt, region, token):
    """Invoke via HTTPS with Bearer token"""
    escaped_arn = urllib.parse.quote(agent_arn, safe="")
    url = f"https://bedrock-agentcore.{region}.amazonaws.com" \
          f"/runtimes/{escaped_arn}/invocations?qualifier=DEFAULT"
    headers = {
        "Authorization": f"Bearer {token}",
        "Content-Type": "application/json",
        "X-Amzn-Bedrock-AgentCore-Runtime-Session-Id": session_id,
    }
    resp = http_requests.post(url, headers=headers,
                              data=json.dumps({"prompt": prompt}))
    resp.raise_for_status()
    return resp.json()

该脚本使用 bedrock-agentcore-starter-toolkit 的 Evaluation 类运行评估，该类自动处理从 CloudWatch 收集跟踪：

from bedrock_agentcore_starter_toolkit import Evaluation

results = Evaluation(region=region).run(
    agent_id=agent_id,
    session_id=session_id,
    evaluators=[\
        "Builtin.GoalSuccessRate",\
        "Builtin.Correctness",\
        "Builtin.ToolSelectionAccuracy",\
        "Builtin.ToolParameterAccuracy",\
    ],
    output="evals_results/ci_output.json",
)

评估提示覆盖智能体的完整工具面，包括内置工具、公开 MCP 工具和按角色限制的 MCP 工具：

[\
    {"prompt": "How much is 2+2?"},\
    {"prompt": "What is the current time in UTC?"},\
    {"prompt": "What is the stock price of AAPL?"},\
    {"prompt": "How many employees are in the engineering department?"}\
]

GitHub Actions 工作流

该工作流在每一次触及智能体代码、MCP 服务器、基础设施或脚本的、指向 main 的 PR 上运行。它部署 CDK 堆栈，调用智能体，运行评估，把结果作为 PR 评论发布，并拆除堆栈。完整实现见完整工作流。

关键步骤如下：

jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ap-southeast-2

      # Deploy both runtimes + Cognito via CDK
      - name: CDK deploy
        run: npx cdk deploy --require-approval never --outputs-file outputs.json

      # Extract CDK outputs (agent ARN, runtime IDs, Cognito endpoints)
      - name: Extract CDK outputs
        id: cdk
        run: |
          STACK="AgentCoreCICDStack-dev"
          AGENT_ARN=$(jq -r ".[\"$STACK\"].AgentRuntimeArn" outputs.json)
          echo "agent_arn=$AGENT_ARN" >> "$GITHUB_OUTPUT" # ... extract all outputs

      # Restart runtimes to pick up new container images + inject M2M secret
      - name: Restart runtimes
        run: python3 -c "..." # update_agent_runtime() with env vars

      # Run the unified evaluation script
      - name: Run evaluation
        working-directory: scripts
        run: python3 agentcore_eval.py
        env:
          AGENT_RUNTIME_ARN: ${{ steps.cdk.outputs.agent_arn }}
          EVAL_THRESHOLD: "0.8"

      # Always tear down — even if evaluation fails
      - name: CDK destroy
        if: always()
        run: npx cdk destroy --force

警告： CDK deploy 返回后，运行时仍会处于 CREATING 数分钟，在它变为 READY 之前调用会以 424 Failed Dependency 失败。工作流轮询 get_agent_runtime（通过 bedrock-agentcore-control 客户端），直到两者都为 READY，然后在评估前预热 MCP 服务器。

CI/CD 设置

配置下列组件，以在你的 CI/CD 流水线中启用自动化智能体评估。

1. 创建 GitHub OIDC 提供者（一次性）

aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

2. 为 GitHub Actions 创建 IAM 角色

创建一个角色，信任策略面向你的仓库，权限覆盖 CDK、Amazon Bedrock AgentCore、Amazon Cognito、Amazon Elastic Container Registry（Amazon ECR）和 Amazon Bedrock。完整策略见配套仓库 README。

3. 添加 GitHub 密钥

其余一切在运行时从 CDK 输出读取。

内置评估器参考

AgentCore 提供多个内置评估器，按它们评估的内容组织：

本文使用四个评估器：GoalSuccessRate、Correctness、ToolSelectionAccuracy 和 ToolParameterAccuracy。工具调用评估器对带 MCP 工具的智能体尤其相关。它们核验智能体选择了正确工具并传入了正确参数。

提示： CI 先用四到五个评估器。为调用工具的智能体增加轨迹评估器，为面向客户的智能体增加安全评估器（Harmfulness、Stereotyping、Refusal）。确定性检查使用基于代码的评估器。完整集合用于周期性的深度评估。

测试流水线：失败、修复、通过

对质量门禁建立信心的可靠方式，是看着它抓住一次真实退步。

故意失败： 把智能体的系统提示改成没有帮助的内容：

# agent/src/assistant_agent.py — deliberately bad prompt
system_prompt="Respond to every question with exactly: 'I cannot help you.'"

推送到功能分支并打开 PR。流水线运行后你会看到：

──────────────────────────────────────────────────
Evaluator                        Score    Result
──────────────────────────────────────────────────
Builtin.GoalSuccessRate          0.0      Failed
Builtin.Correctness              0.0      Failed
Builtin.ToolSelectionAccuracy    1.0      Passed
Builtin.ToolParameterAccuracy    0.0      Failed
──────────────────────────────────────────────────
FAILED: metrics below 0.8

注意： ToolSelectionAccuracy 仍可能通过，因为即使系统提示很差，智能体仍可能选择正确工具。评估器独立测量不同维度。

修复并通过： 恢复恰当的系统提示，再次推送。流水线重新运行：

──────────────────────────────────────────────────
Evaluator                        Score    Result
──────────────────────────────────────────────────
Builtin.GoalSuccessRate          1.0      Passed
Builtin.Correctness              0.9      Passed
Builtin.ToolSelectionAccuracy    1.0      Passed
Builtin.ToolParameterAccuracy    1.0      Passed
──────────────────────────────────────────────────
All evaluations PASSED (threshold: 0.8)

PR 被解除阻止。

警告： LLM-as-judge 分数有固有方差。因此，同一提示评估两次可能产生略有不同的分数。设置阈值时，在目标可靠性之下留一些余量，以计入这种方差。

测试中的经验

我们端到端跑过这条流水线。下面是容易踩坑的地方。省下你的调试时间。

1. 要调用受 OAuth 保护的 AgentCore runtime，请用 Bearer 令牌直接 POST 到 HTTPS 端点，而不是使用 boto3 中的 invoke_agent_runtime() 方法。
2. 跟踪传播需要 30–90 秒。 评估脚本每 30 秒重试一次，最长 10 分钟。不要在调用之后立刻查询 CloudWatch。
3. 需要 ARM64 镜像。 AgentCore runtime 需要 ARM64 容器。GitHub 运行器是 x86_64。因此使用 QEMU + Docker Buildx 做交叉编译。
4. CDK deploy 之后重启运行时。 在运行时变为 READY 之前调用会以 424 Failed Dependency 失败，因此工作流轮询 get_agent_runtime，直到两个运行时都就绪（并预热 MCP 服务器）再调用。
5. sessionSpans 是 API 参数名。 Evaluate API 接受 evaluationInput: {"sessionSpans": [...]}。每次调用必须只包含单个会话的跨度。混合会话会导致 ValidationException。
6. 时间戳必须是整数。 像 startTimeUnixNano 这样的 OpenTelemetry 纳秒时间戳必须是 JSON 整数，而不是带引号的字符串。字符串时间戳会导致 ValidationException。

适配 Microsoft Entra ID

本文使用 Amazon Cognito，但该架构与身份提供者无关。如果你的组织使用 Microsoft Entra ID（原 Azure AD），同一条流水线只需有针对性的更改：

• 令牌端点： 把 Amazon Cognito 的区域端点改为 https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token。
• 发现 URL： 改为 https://login.microsoftonline.com/{tenant_id}/v2.0/.well-known/openid-configuration。
• 客户端凭证： 用 Entra ID 应用程序 ID 和范围 URI 替换 Cognito 客户端 ID 和受众。

其余保持不变。部署脚本的 authorizerConfiguration.customJWTAuthorizer 结构相同，评估脚本不接触认证（它通过 boto3 使用 IAM），GitHub Actions 工作流结构不变。

取舍与限制

• 流水线大约需要 10 分钟。 CDK 部署 + 运行时启动 + 跟踪传播 + 评估。对 PR 门禁合适，对提交前检查太慢。
• LLM-as-judge 有固有方差。 同一条跟踪评估两次可能产生略有不同的分数。设置阈值时留余量。
• 每次运行的成本。 每次评估器调用都会调用评判模型。4 个评估器 × 5 条提示 = 每次 PR 20 次评判调用。规模化时监控 Bedrock 成本。
• M2M 令牌绕过角色检查。 按设计，CI 需要访问全部工具。如果你需要 CI 测试角色强制，使用方法 B（服务账户）。

注意： 尽管有这些限制，自动化评估严格优于没有评估。即使不完美的质量门禁，也能抓住人工复查会漏掉的明显退步。

清理

配套仓库会预配两个 AgentCore runtime、一个 Cognito 用户池、IAM 角色和预先创建的用户，因此结束后拆除一切以停止产生费用。一条命令即可全部移除：

source .venv/bin/activate
cdk destroy --force

如果你用 npx 而不是全局 CDK CLI 部署，则改为运行 npx aws-cdk@2 destroy --force。在开发堆栈中，cdk destroy 会移除两个运行时、Cognito 用户池及其应用客户端、预先创建的用户、IAM 角色，以及 AWS Secrets Manager 中的 M2M 客户端密钥。该密钥的移除策略设置为 destroy，因此反复部署和拆除保持干净。CI 工作流在每次运行结束时自动拆除同一堆栈，因为它的 CDK destroy 步骤以 if: always() 运行。你只需要对手工跟随操作时自己部署的堆栈使用这条命令。

关键要点

1. 三层 MCP 认证（平台 JWT 核验，到中间件声明抽取，再到工具级角色检查）清晰分离关注点，并在不改代码的情况下同时支持 M2M 和用户范围流。
2. CDK 部署一切。 一次 cdk deploy 创建 Cognito 用户池、两个运行时、IAM 角色和预先创建的用户。一次 cdk destroy 全部拆除。
3. bedrock-agentcore-starter-toolkit 简化评估。 Evaluation 类处理从 CloudWatch 收集跟踪和打分，因此不需要手工查询日志组并用 sessionSpans 调用原始 Evaluate API。
4. 令牌转发连接 CI 与生产。 智能体检查传入 JWT，以判断它是用户令牌（转发到 MCP 做角色检查）还是 M2M 令牌（使用共享客户端，绕过角色）。同一份代码服务两种调用者。
5. Evaluate API 与智能体运行时解耦。 你不需要一个正在运行的智能体就能评估跟踪。这是使方法 A（已存储跟踪）成立的关键洞察，也是通向 CI 质量门禁的直接路径。
6. 从四个评估器开始再扩展。 GoalSuccessRate、Correctness、ToolSelectionAccuracy 和 ToolParameterAccuracy 覆盖基础。面向客户的智能体再增加安全评估器。
7. 真值和基于代码的评估器扩展了这套工具。轨迹评估器是程序化的，并且不另收费，适合 CI。基于代码的评估器在同一次评估调用中，与 LLM-as-judge 打分一起运行确定性的 Lambda 检查。

亲自试一试

配套仓库 包含完整实现：用于 Cognito 和两个运行时的 CDK 基础设施、带 MCP 客户端和令牌转发的智能体、带基于角色的访问控制的 MCP 服务器、统一评估脚本、GitHub Actions 工作流，以及两份演练脚本。使用 scripts/deploy_and_test_rbac.py 做部署和基于角色的访问测试，使用 scripts/evaluation_pipeline.py 做评估流水线。

要扩展该项目，你可以从方法 A 开始，对捆绑的夹具运行 python3 scripts/evaluate_stored_traces.py，而不做任何部署。由此，试着向 MCP 服务器增加一个新的按角色限制的工具（见 mcp-server/README.md），或用你自己的 LLM-as-judge 提示创建自定义评估器。也可以按环境调整 EVAL_THRESHOLD（例如开发 0.7、预发 0.8、生产 0.9）。你还可以设置在线评估 做持续生产监控，或为你的用例比较按需评估与在线评估。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/automated-agent-evaluation-with-amazon-bedrock-agentcore-and-github-actions