一个工具调用 trace 带来的定位收益
· 阅读需 2 分钟
这次短更想记录一个很直接的收益：加上一层像样的工具调用 trace 之后，一次原本要靠猜半天的问题，几分钟就定位到了。
问题表面上是“回答质量偶尔变差”，但真正看了 trace 之后，很快就能看到：不是模型理解错了，而是某个工具返回慢了一次，后面的重试触发了 fallback，最终结果自然就偏掉了。
没有 trace 时，所有问题都会先被压扁成“回答变差了”
之前没有 trace 的时候，大家看到的只有：
- 用户输入
- 最终回答
中间到底调用了什么、哪一步慢了、哪一步走了降级，几乎全靠推断。
这次之后我更确定：只要开始多工具协作，trace 就是基础设施
这次最值钱的地方不是修了某个 bug，而是证明了一件事：只要开始做工具链，trace 不是加分项，而是定位效率的基础设施。
没有 trace，很多问题看起来都像“模型不稳”；有了 trace，很多问题会重新暴露成“工具超时”“重试触发”“路由走偏”。
我现在至少会保证 trace 串起三层事实
现在我会优先保证工具调用 trace 至少能串起三样东西：
- 请求 ID
- 工具调用顺序
- 每一步耗时和结果状态
只要这三层能串起来，很多原本模糊的问题都会立刻变清楚。
如果再往前多做一步，我还会把 retryOf、fallbackReason 和最终 decisionSource 也一起记下来。因为真正麻烦的，往往不是“某个工具慢了”，而是“慢了之后系统做了什么补救，以及最后哪个补救路径真正影响了结果”。
我真正想保留的结论
一个好的工具调用 trace，最大的价值不是“日志更漂亮”，而是把原本只能靠猜的链路问题，变成可以直接看见的问题。