一、从一个真实问题开始：为什么 Agent 出错后很难定位

先看一个很常见的场景。怎么说呢，

业务负责人经常遇到以下痛点：

• 无法快速定位错误原因。只看到最终答案，
• 缺少对每一步调用细节的可追踪记录。
• 成本与耗时信息不透明，导致预算控制困难。
• 无法复现同一任务以验证修复效果。

User 的提问示例：

帮我分析这个 SaaS 产品最近使用者流失的主要原因，并给出三个改进建议。

Agent 看起来很努力。它查了留存数据、读取了使用者反馈、调用了工单程序，还生成了一份结构化报告。最终结论是这方面，

使用者流失主要来自新手引导复杂、价格感知偏高和客服响应慢。建议调整 Onboarding、调整定价展示，并增加客服自动分流。

这份报告看起来很完整。但业务负责人追问了几个关键问题：

为什么认为新手引导是第一原因？这个结论来自数据、反馈，还是模型推断？不过，有没有看过最近版本发布记录？工具调用失败过吗，失败后怎么处理的？这次任务花了多少钱，为什么跑了这么久？
如果我认为结论不对，能不能回放整个过程？

很多 Agent 程序到这里就卡住了因为它只保存了最终答案，没有完整执行过程。者只能看到几段零散日志：

start taskcall retention api successcall feedback api successgenerate report success

这些日志说明“发生过一些事”，但不足以回答真正的排障需求。

二、Agent 可观测性的第一性原理：把执行过程变成证据链

传统软件程序围绕三类信号展开可观测性：

• Logs：发生了什么事件。怎么说呢，
• Metrics：整体表现如何变化。
• T​races：一次请求经过了哪些链路。

但对于 Agent 这些信号还不够。因为它涉及认知链路，如目标理解、计划生成和验证决策。缺少这些信息会导致如下痛点：目标误解导致无效规划；工具选择错误导致耗时增大；结果未验证导致错误输出，成本估算不到位导致预算超支。

A​gent 的可观测性需要捕捉整条证据链：

flowchart LR A --> B B --> C C --> D D --> E E --> F F --> G G --> H H --> I G -- 不通过 --> B E -- 工具失败 --> B

...

This chain answers three core questions:

– What steps were executed?