Trace 是 Agent 评测的地基从执行记录到问题归因 个人主页zzz_2368 系列主题Agent 评测从结果、轨迹到持续迭代 热门专栏Agent | 小z的碎碎念 | Java后端 本系列内容评测体系、Rubric、Good Case、Bad Case、Trace 与长程 Agent系列第 4 篇作者主页zzz_2368 的 CSDN 主页上一篇Agent 评测的数据飞轮本文参考《Agent 评测漫谈》、Arize 的 Agent Evaluation 文档 和 Langfuse API 文档。本文只讨论观测与评测的设计原则不声称某个工具已经在生产环境验证过。一、没有 Trace评测只能告诉你“坏了”最终回复是“任务失败”这条信息的诊断价值很低。失败可能来自模型没有理解任务规划步骤不完整工具参数错误工具返回了错误但 Agent 没有处理环境状态与预期不一致权限或安全策略阻止了动作评测标准本身不适用。如果系统只记录用户输入和最终回复研发人员很难区分这些原因。原文把“观测 评测”概括为持续迭代的基础这个判断可以从工程上理解为评测负责判断问题Trace 负责提供问题证据。二、Trace、Trajectory、Transcript 和 Outcome这些词在不同工具中可能有不同命名建议在项目内先定义边界名称本文含义Trace一次任务执行的整体记录SpanTrace 中的一个步骤或调用单元TrajectoryAgent 采取的动作序列和中间状态Transcript更强调完整交互内容的记录Outcome执行结束后环境中的真实状态Anthropic 的评测文章将一次试验的完整记录与最终结果区分开来并特别强调Agent 的口头陈述不能替代外部环境状态。例如“说已预订”不等于数据库真的有预订记录。三、最小 Trace 应该记录什么一个可用于回放和归因的最小结构可以是{trace_id:trace-001,task_id:order-query-001,agent_version:agent-build-2026-08-10,input:查询订单状态,spans:[{type:plan,input:用户请求和上下文,output:调用订单查询工具,status:ok},{type:tool,name:query_order,arguments:{order_id:masked},result:{status:配送中},status:ok}],outcome:{order_status:配送中},usage:{latency_ms:1200,tool_calls:1}}字段不应机械照搬。至少要回答谁执行、执行什么、调用了什么、返回了什么、最终状态如何、花费了多少、是否失败。四、观测不等于记录全部内容“完整记录”不等于“无差别保存所有数据”。Trace 设计需要考虑1. 隐私与敏感信息对姓名、手机号、地址、订单号、Token 和内部提示词进行分级处理。脱敏后仍要保持必要的关联关系否则无法复现任务。2. 权限与可见性不同角色看到的 Trace 内容可能不同。开发人员需要错误和工具参数业务人员可能只需要结果与归因安全人员还需要权限决策和高风险动作记录。3. 成本与采样长程 Agent 的 Trace 可能很大。可以按风险、错误、版本和用户授权进行分层采样但高风险动作和失败任务不应因为采样而完全丢失。Arize 的文档说明评测可以作用于 Trace 和 Span 数据并用于检查正确性、幻觉、相关性和延迟等维度。 这也说明评测与观测不是两个完全独立的系统。五、从 Trace 到根因归因推荐采用“现象—证据—归因—修复”的格式现象Trace 证据可能归因下一步任务未完成工具返回缺少字段Agent 直接结束错误处理不足增加失败分支与回归样本重复调用相同参数连续调用 8 次重试策略或状态记忆失效增加调用预算和停止条件结果正确但很慢工具调用成功但串行等待编排效率问题评估并行或缓存访问越权路径Span 记录了目录检查失败后仍继续调用权限门禁缺失将权限失败设为阻断这里的“可能归因”仍然是假设必须通过复现或对照实验确认。Trace 能提高定位效率但不能自动证明根因。六、Trace 如何支撑回放和评测评测平台至少需要支持按任务 ID、版本和失败类型检索展开一次执行的完整 Span对照 expected behavior 和 outcome重放历史任务将失败样本加入回归集对不同版本的结果进行比较。Langfuse 文档提供了 Trace/Observation 记录和批量评估相关 API 示例。 这可以作为实现时的参考但工具选型仍取决于部署方式、数据合规、成本和现有技术栈。七、结论Trace 的价值不是让日志变长而是让一次失败具备可解释证据看见执行现场才能区分模型问题、工具问题、环境问题、策略问题和评测问题。因此Agent 评测系统的基础设施应同时考虑数据采集、脱敏、检索、回放、评分和归因而不是只提供一个最终分数页面。下一篇将从长程 Agent 出发讨论为什么“完成任务”比“生成答案”需要更复杂的评测对象。Trace 示例的本地验证本地 Demo 生成两个完整的模拟轨迹stable 最终成功且调用 2 次工具retrying 最终也成功但调用 4 次工具并因超过 3 次预算而未通过效率评分。这个对照说明 Trace 不只是日志展示还可以为效率和归因 Grader 提供输入。运行方式见本地 Demo。Demo 不连接真实 Agent结果只用于验证字段结构和评分流程。七、Trace 设计的验收清单发布一个 Trace 采集版本前建议逐项确认每次任务都有稳定的 trace_id 和 task_id每个工具 Span 都有名称、参数摘要、结果状态和错误信息Outcome 来自外部环境检查而不是只复制 Agent 的最终回复敏感字段有脱敏策略且脱敏后仍保留必要关联失败、越权和高风险动作不会被普通采样丢弃Trace 可以按版本检索并能关联到回归 Case。如果只能保存最终文本系统仍可做 Response Evaluation但不能声称已经具备完整的轨迹评测能力。Trace 越完整也不代表根因自动确定仍需要复现、对照实验或人工确认。参考资料《Agent 评测漫谈》AnthropicDemystifying evals for AI agentsArizeOnline EvalsLangfuse API 文档感谢阅读记得点赞、关注、收藏欢迎各位评论区交流
