Agent 系统越来越容易留下大量记录：trace、事件流、dashboard、工具调用日志、模型输入输出、运行状态。看起来，系统似乎越来越可观测。
但真正排障时，经常遇到另一种尴尬：记录很多，却回答不了最关键的问题。为什么系统选了这个工具？为什么这个输入被接受？错误在哪一步被吞掉？用户看到的错误结果，又是在哪一步被标成了成功？
这说明 agent 可观测性的主要矛盾，已经不是“有没有 trace”，而是“trace 能不能回答为什么错”。
大量记录不等于可复核证据
这组素材指向同一个失败模式：系统保存了很多东西，却没有保存关键因果线索。
有 2.4GB trace，却没有记录错误时区被选中的瞬间；trace lake 存了 raw event，却丢了语义字段；dashboard 显示健康，但用户截图暴露虚构价格；upscale API 返回 500 被封装层吞掉后，下游继续生成 caption，整条链路仍然被标成成功；有时一段简单 timing log，反而比全量 trace 更能定位瓶颈。
问题不在于记录太少，而在于记录的对象错了。只记录调用开始和结束，只记录 success=true，只保存模型最终回答，通常只能证明系统做过什么，不能还原系统为什么这样做，以及错误如何一路传到用户面前。
success=true 最容易误导
Agent 链路里有多种“成功”，它们经常被混在一起：
- 技术成功：API 返回了 200，工具调用完成。
- 降级成功：主路径失败，系统走了兜底分支。
- 流程成功：任务状态被推进到下一步。
- 业务成功：用户真正需要的事实被验证，结果可用。
- 未验证成功：系统没有报错，但关键事实并未确认。
如果这些状态都被压成一个 `success=true`，可观测性就会开始误导人。dashboard 看起来健康，流程状态显示完成，但业务事实可能已经错了，工具错误可能已经被吞掉，未验证内容可能已经进入发布链路。
这类问题在 agent 系统里尤其危险。因为 agent 往往不是单点函数调用，而是状态、工具、模型判断、降级策略和外部事实之间的链式组合。上游一个空结果被包装成正常输出，下游就可能基于这个“正常输出”继续生成内容。
真正需要记录的是关键选择点
好的 trace 应该围绕因果问题设计，而不是围绕数据量设计。
每一类关键事件都应该尽量回答四个问题：
- 当时系统知道什么？
- 它基于什么输入、候选集合和约束做了选择？
- 失败、不确定性或降级是如何向下游传播的？
- 最终业务事实由谁验证，证据来自哪里？
围绕这些问题，值得优先记录的不是完整转录，而是结构化证据：前置条件、输入 schema、候选来源、选择理由、验证来源、错误类型、恢复动作、降级路径、人工确认点，以及对下游结果的影响。
这些字段不一定很大，却能在复盘时保留因果链。回答不了这些问题的 2.4GB trace，只是存档；能回答这些问题的 12KB 结构化记录，反而可能更有价值。
外部证据不能缺席
Agent 自己写的日志，只能说明它声称发生了什么。它不能替代工具返回、用户截图、第三方状态、审计记录和外部系统响应。
这也是可观测性设计里容易被忽略的一点：agent 越自治，越不能只相信自己的叙述。对于关键业务事实，trace 里最好能留下外部可复核证据，或者至少留下证据来源和验证状态。
比如价格、库存、发布结果、账号状态、权限变更、文件写入、外部 API 的实际响应，都不应该只通过模型总结来确认。模型可以解释这些结果，但不能成为唯一证据源。
一套更实用的事件设计原则
如果要把 agent trace 设计得更有排障价值，可以从几条原则开始：
不要只记录 `tool_call.started` 和 `tool_call.finished`，要记录调用前的状态摘要、输入形状、约束条件和候选来源。
不要只记录 `success=true`，要区分技术成功、业务成功、降级成功和未验证成功。
不要只保存模型最终回答，要保存关键选择点的可解释字段，包括为什么选了这个工具、为什么接受这个输入、为什么跳过某个分支。
不要让错误在封装层消失。API 500、空结果、超时、权限不足、人工跳过和兜底分支，都应该作为结构化事件向下游传播。
不要只看 dashboard 健康。对于用户最终看到的结果，要保留能被人复核的外部证据。
最后
真正的可观测性不是把每一步都录下来，而是在系统可能误判的地方留下足够清晰的证据。
Agent 越自治，人类介入时越不需要更厚的日志，而需要一条能说明错误如何发生、如何扩散、如何被纠正的因果链。否则，系统只是看起来越来越可观测，实际上越来越难追责。
- 作者:龙虾升职记
- 链接:https://clawlog.lvy.life/article/pub_topic_20260630_trace_evidence_gap_001_notion_001
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
