Agent 评测开始脱离框架：OpenTelemetry 能统一什么，不能统一什么

Agent 评测开始脱离框架：OpenTelemetry 能统一什么，不能统一什么

Agent 团队经常在 LangGraph、LlamaIndex、OpenAI Agents SDK、Google ADK、Claude Agent SDK 和 Strands Agents 之间切换。框架换了，日志与评测脚本也跟着重写，很难用同一把尺子比较。AWS 8 月 26 日公布的 AgentCore Evaluations 把入口放在 OpenTelemetry：运行时只要输出符合约定的遥测数据，就能交给同一套评估器。

评测依赖由 Agent 框架移到可观测数据契约后，仍有一个前提：框架无关不等于数据天然可比。缺失工具参数、会话分组错误或被截断的模型消息，都会让评分建立在不完整轨迹上。接入前要先证明遥测数据能还原实际任务。

评测服务真正读取的只有三类关键 Span

一个 Agent 回合可能产生模型推理、工具执行、检索、重排、记忆、护栏和编排等大量 span。AgentCore Evaluations 主要依赖三种角色：顶层的 invoke_agent 保存用户请求与最终回答，chat 表示各次模型调用，execute_tool 记录工具名、输入参数和结果。检索或记忆 span 可以提供背景，但不是完成基本评分的必要条件。

服务同时理解 OpenTelemetry GenAI 语义约定和 OpenInference。两套规范的字段名、span kind 与嵌套方式不同，系统会根据 instrumentation 的 scope.name 选择解析路径，再用 session.id 组合会话、用 trace_id 区分用户回合。官方列出的框架有专门适配，遵循 opentelemetry.instrumentation.* 或 openinference.instrumentation.* 命名的其他库也能走通用路径。

这个机制没有自动解决语义缺口。例如某个框架记录完整工具返回值，另一个只保留摘要；两者都能生成 execute_tool，信息密度却不同。企业应检查会话、模型名、工具 schema、参数、结果和错误能否对应。可用[OpenTelemetry GenAI 观测指南](/articles/opentelemetry-genai-agent-observability)作为字段盘点起点。

离线回归和线上监控不能共用一套结论

AgentCore 提供按需评测与在线评测。按需模式适合 CI：用固定任务调用 Agent，携带期望回答、预期工具轨迹和行为断言，低于阈值就阻止发布。在线模式从生产日志抽样，没有标准答案，因此只能使用不依赖 ground truth 的评估器，例如目标完成率、正确性、帮助度或自定义的模型评分，并把结果写回 CloudWatch。

同一评分管线让开发和生产趋势可以对照，但线上分数不能替代离线回归。用户问题难度会变化，采样也可能漏掉高成本失败；LLM-as-a-judge 还受评分模型和提示词影响。比较模型或框架时，应固定评测器版本，让另一套模型复核边界样本，再人工抽查高风险任务。[Promptfoo 回归与红队测试](/articles/open-source-promptfoo-ai-testing-red-teaming)可在发布前补充可重复断言。

遥测内容也需要安全治理。记录完整 prompt、模型回复和工具参数，可能把代码、用户数据与访问令牌写入日志。生产环境应在采集端做字段白名单和脱敏，限制读取范围并设置保留期。无法安全保存原文时，可记录哈希、结构化结果和受控样本。

AWS 的[技术说明](https://aws.amazon.com/blogs/machine-learning/evaluate-any-agent-framework-with-amazon-bedrock-agentcore-evaluations/)给出了三类 span、兼容框架以及在线与按需模式。AnyAIS 可在模型调用层补充模型、token、延迟与费用数据；把这些指标和 Agent 轨迹关联起来，才能判断一次失败来自模型质量、工具执行还是编排逻辑。