Marico's space

最近在折腾 AI Agent（人工智能代理）的评估体系，踩了不少坑，趁着记忆清晰把 Amazon Bedrock 的 AgentCore Evaluations 好好研究了一番。这玩意儿解决了一个很实际的问题：团队里有人用 LangGraph，有人用 LlamaIndex，还有人在试 OpenAI 的 Agents SDK，每个框架自带一套评估逻辑，互相之间根本没法对比。AWS 的解法很有意思——直接拿 OpenTelemetry（可观测性遥测技术）当契约，甭管你用啥框架，只要发出正确的 span（追踪跨度）和属性，AgentCore 就能打分。

目前支持 LangGraph、LlamaIndex、OpenAI Agents SDK、Google ADK、Claude Agent SDK 和 Strands Agents，自定义框架只要正确埋点也行。这是业界第一个用遥测数据解耦框架选择和评估能力的云服务方案，下面详细说说技术实现。

OpenTelemetry 契约

AgentCore Evaluations 要求 Agent 以 OpenTelemetry 格式发出结构化遥测数据，服务端会识别特定类型的 span 和属性：

• Agent span：单个 Agent 调用的顶层执行上下文
• Tool call span：单个工具调用，包含输入、输出和延迟
• LLM span：模型调用，含 prompt、响应、token 计数和模型 ID
• Retrieval span：向量搜索或知识库查询

每个 span 必须包含映射到评估维度的语义属性，例如：

# 手动埋点的伪代码
from opentelemetry import trace tracer = trace.get_tracer(__name__) with tracer.start_as_current_span("agent.run") as agent_span: agent_span.set_attribute("agent.id", "customer-support-v2") agent_span.set_attribute("agent.framework", "langgraph") with tracer.start_as_current_span("tool.call") as tool_span: tool_span.set_attribute("tool.name", "get_order_status") tool_span.set_attribute("tool.input", json.dumps({"order_id": "12345"})) result = get_order_status("12345") tool_span.set_attribute("tool.output", json.dumps(result)) tool_span.set_attribute"tool.success", True)

关键在于 AgentCore 不关心你的框架内部状态机或图结构，只关心可观测的事件：调用了哪些工具、大模型说了什么、各环节耗时多少、是否成功。

框架适配器与埋点盲区

主流框架或多或少都支持 OpenTelemetry，但覆盖度参差不齐：

如果你的框架没发出所需的遥测数据，有三种选择：

1. 手动埋点：用 OpenTelemetry API 包装 Agent 代码
2. 自动埋点：使用 OpenTelemetry 的自动埋点库处理 HTTP、数据库和大模型调用
3. Span processor：在 span 创建后、导出前拦截并补充数据

AWS 不提供框架特定的适配器。怎么确保 Agent 发出正确的遥测格式，得你自己负责。文档里有各框架的埋点示例，但得根据自己的 Agent 架构做适配。

评估指标与评分

AgentCore 收到遥测数据后，会计算多个维度的指标：

• 任务成功率：Agent 运行无错误的百分比
• 工具准确率：是否按正确顺序调用了正确的工具
• 响应质量：用大模型当裁判，对最终输出与标准答案打分
• 延迟：Agent 运行、工具调用、大模型调用的 P50、P95、P99
• 成本：每次运行的 token 用量和预估推理费用

评估结果存在时序数据库里（应该是 Amazon Timestream，但 AWS 没明说）。可以通过 AgentCore API 或 AWS 控制台查询。默认保留 90 天，之后想长期存储得导出到 S3。

部署形态与数据流

典型数据流是这样的：

1. Agent 在你自己的 AWS 账号里运行（Lambda、ECS、EC2 或本地）
2. OpenTelemetry SDK 将 span 批量导出到 AWS Distro for OpenTelemetry（ADOT）Collector
3. ADOT Collector 通过 AWS PrivateLink 将 span 转发给 AgentCore Evaluations
4. AgentCore 处理 span、计算指标、存储结果
5. 通过 AgentCore API 或控制台查询结果

ADOT Collector 以 sidecar 容器或守护进程方式运行，负责批量处理、重试和凭证管理。配置通过 YAML 文件完成：

receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 exporters: awsxray: region: us-east-1 agentcore: endpoint: agentcore.us-east-1.amazonaws.com region: us-east-1 service: pipelines: traces: receivers: [otlp] exporters: [awsxray, agentcore]

agentcore 导出器是 ADOT 自带的插件，通过 IAM 角色认证，将 span 转发到 AgentCore 服务。

延迟与成本开销

发送遥测数据到 AgentCore 会带来额外延迟和成本：

• 延迟：每次 Agent 运行增加 10-50ms，取决于 span 数量和网络状况。ADOT Collector 会批量处理，所以开销是分摊的。
• 成本：AgentCore 按摄入的 span 收费。AWS 还没公布具体定价，但参考类似服务（X-Ray、CloudWatch Logs Insights），预计每百万 span 0.10-0.50 美元。

如果跑的是高吞吐量 Agent（每秒几千次运行），成本会快速攀升。可以这样优化：

• 采样遥测数据（比如只导出 10% 的运行）
• 过滤 span（比如只导出工具调用和大模型调用，跳过框架内部 span）
• 异步运行评估（导出遥测到 S3，批处理）

本地开发或低风险测试场景，可以用 AgentCore SDK 本地运行评估，不往 AWS 发遥测。这样更快更便宜，但没有集中仪表盘和历史对比功能。

安全边界

AgentCore Evaluations 运行在 AWS 账号，不是你的。遥测数据跨账号传输，这引发两个问题：

1. 数据驻留：span 存在你指定的 AWS 区域，但不在你的 VPC 里。如果有严格的数据驻留要求，得自己搭评估体系。
2. 敏感数据：span 可能包含工具输入、大模型 prompt 和用户查询。如果这些含个人信息或密钥，得在导出前清洗。ADOT Collector 支持 span processor 做属性脱敏，但得自己配置。

AWS 对传输中（TLS）和存储中（KMS）的 span 加密。如需完全掌控加密，可使用客户托管的 KMS 密钥。

故障模式

最可能踩的坑：

• 遥测缺失：Agent 没发出所需的 span 或属性，AgentCore 无法计算指标。服务不会优雅降级，直接返回空结果。
• Schema 漂移：改了 Agent 的工具签名或加了新工具，评估指标可能随时间不一致。得对评估数据集做版本管理，重新跑历史评估。
• Collector 故障：ADOT Collector 崩了或断网，span 缓存在内存里。缓存满了就丢 span。除非监控 Collector 自己的遥测，否则浑然不知。
• 限流：AgentCore 对 span 摄入有未公开的限流。超了就返回 HTTP 429，ADOT Collector 会重试，但如果积压太多可能丢数据。

技术判断

适合用 AgentCore Evaluations 的场景：

• 多框架混合跑 Agent，想要统一的评估仪表盘
• 已经在用 OpenTelemetry 做可观测性，想复用同一套遥测管道
• 需要跨 Agent 版本的历史对比和趋势分析
• 愿意为托管服务付费，接受延迟和成本开销

不适合的场景：

• 有严格数据驻留要求，不能把遥测发到 VPC 外部
• 跑高吞吐量 Agent，需要亚 10ms 延迟
• 用的框架不输出 OpenTelemetry 遥测，又不想手动埋点
• 需要 AgentCore 不支持的定制评估指标（比如领域特定的准确率）

对于跑异构 Agent 技术栈的团队，框架无关的契约确实是实打实的优势。但用灵活性换来了运维复杂度——得自己管 ADOT Collector、监控 span 摄入、填补埋点缺口。

参考来源

• AWS Machine Learning Blog：使用 Amazon Bedrock AgentCore Evaluations 评估任意 Agent 框架