企业Agent进入生产后，一个隐蔽成本正在暴涨：LangGraph、LlamaIndex、OpenAI Agents SDK、Google ADK、Claude Agent SDK和Strands都能编排任务，却常常需要各自的评测接线。AWS现在让AgentCore Evaluations直接读取OpenTelemetry与OpenInference轨迹，用同一套评分逻辑处理六类框架。

AWS统一的不是Agent，而是轨迹语言

一次Agent请求会产生模型调用、工具调用、检索、重排、记忆读写、护栏与编排等大量span。AgentCore并不要求所有框架输出完全相同的内部结构，而是从轨迹里识别三种角色：代表用户一轮请求的invoke agent span、承载模型输入输出的inference span，以及记录工具名称、参数和结果的execute tool span。

其他检索、护栏或记忆span可以保留为上下文，服务遇到陌生类型也会跳过而不是报错。它同时理解OpenTelemetry GenAI语义约定和OpenInference字段，并根据采集库的scope name选择解析方式。这让未来的新框架只要采用合规instrumentation包，就有机会沿通用路径接入。

“接入零改动”背后仍有三个工程陷阱

第一，所有span必须带有与runtimeSessionId一致的session.id，服务才能把多次调用拼成会话。第二，评测不仅需要时间和属性，还需要实际消息内容；旧版分离式可观测配置若只读取共享span日志，响应质量评估会因为正文为空而失败。第三，自定义采集scope不能随意命名，必须落在公开规范前缀下。

更容易被忽略的是flush。Agent运行时在处理函数返回后可能挂起执行环境，而遥测SDK仍把数据留在客户端缓冲区。AWS把“忘记强制刷新trace与event记录”列为最常见的评测失败原因。LlamaIndex还需要能产生顶层工作流span的FunctionAgent或ReActAgent，普通执行器无法完整锚定一轮会话。

CI与线上监控终于可以用同一把尺

按需模式可以在每次拉取请求中运行固定任务，带入预期回答、工具轨迹和行为断言，再用GoalSuccessRate、Correctness、Helpfulness或自定义LLM裁判判断是否回归。在线模式则从真实流量抽样，把评分持续写回CloudWatch，适合构建质量告警和版本看板。

两种模式共享解析与评测管线，理论上能比较测试环境和线上行为。但在线流量没有标准答案，因此不能使用依赖expected response的裁判；LLM评分也会受模型版本和提示词影响。统一工具只减少接线差异，不会自动生成可靠的任务集、业务基线和失败处置规则。

编辑判断：企业需要先统一“什么叫完成”

对FDE团队而言，最有价值的不是同时支持六个框架，而是把可迁移的质量契约留在OpenTelemetry层。试点应该先挑20至50条真实任务，定义允许的工具、正确轨迹、最终结果、人工接管点和时限，再让不同框架跑同一批用例。只有判定标准独立于编排代码，换模型或换框架才不会让历史指标失效。

生产部署还要控制日志中的客户数据、凭证和工具参数，设置脱敏、保留周期与访问权限。看板至少同时记录任务成功率、工具错误率、人工介入率、P95延迟和单位成功任务成本；低分会话必须能回放并归因。AgentCore给出一套统一读表方式，但企业能否把分数变成回滚、审批和改进动作，才决定评测是不是生产系统，而不是另一张漂亮仪表盘。