Agent进入生产后怎么知道哪里出错：可观测性要追踪整条链路

传统应用通常可以从请求、日志和数据库定位错误，Agent 多了一层不确定性：模型为什么选择这个工具，检索拿到了什么，重试是否改变了上下文，最终输出经过了哪些人工修改。如果只记录最后一句回答，团队几乎无法复盘真正的失败。

1. 先说结论

一次 Agent 任务至少要有一个 trace ID，并串起用户请求、提示词版本、模型版本、检索请求、工具调用、权限结果、重试和最终状态。每个 span 都应记录耗时和错误类型，但敏感内容要脱敏，不能为了调试把客户数据全部写进日志。

2. 问题背景

可观测性不等于把所有文本存下来。更重要的是记录可解释的事件：调用了哪个工具、输入 schema 是否通过、返回了什么状态、为什么继续或停止。对于长上下文，可以保存摘要和证据引用，再按权限访问原始内容。

3. 真正的技术取舍

指标需要同时覆盖成功和风险：任务完成率、工具成功率、P95 延迟、重复调用、拒答率、人工接管、回滚和每个成功任务成本。单看模型响应时间，会把真正拖慢流程的检索、第三方 API 或审批等待隐藏起来。

4. 落地方法

异常处理要让运维人员知道下一步。比如工具超时应进入查询状态，而不是直接重试；权限拒绝要显示责任边界；模型输出格式错误要记录修复次数。告警应该按用户影响和可恢复性分级，不要让每一次低风险重试都制造同等噪音。

5. 常见失败

常见失败是只记录 prompt 和 completion，忽略工具输入输出与版本；另一个失败是把日志指标和业务结果完全分开，最后知道 Agent 调了多少次工具，却不知道客户是否真的完成了任务。

6. FDE判断

FDE的判断是，Agent 的可观测性应该围绕“任务是否交付”设计，而不是围绕“模型说了什么”设计。完整链路让团队能快速判断问题来自数据、模型、工具还是权限，也让自动改进有真实证据。

发布或采购前的检查清单

• 每个任务都有可回放的 trace ID。
• 记录工具、权限、重试和版本，而非只存最终回答。
• 同时统计交付成功、延迟、风险和成本。
• 日志脱敏并按影响和可恢复性告警。

下一步怎么做

先给一个 Agent 流程补齐 trace、工具事件和业务完成状态，再扩大监控范围。

本文依据公开资料整理，来源包括：OpenTelemetry documentation。文中“FDE判断”属于编辑分析，不等同于来源原话。