💥 Agent 在生产挂了三天，没人知道它哪一步出了问题
摘要：传统服务崩了有日志、有堆栈、有报警。Agent 崩了——你看到的只有一个「调用失败」。这篇文章从 Java Agent 落地实践出发，讲清 Agent 可观测性到底该监控什么、怎么搭、以及最容易被忽略的那一环。
去年有个事，同行群里聊了一整天。
一个做客服 Agent 的团队，模型换成新版之后，工单处理准确率从92% → 67%。他们查了三天——模型输出格式没问题、工具调用没报错、日志也看不出异常。
最后是人工翻了几百条对话记录，才发现问题出在一个很隐蔽的地方：新版模型在某个场景下「决定不调用」一个关键工具。不是调用失败了，是它判断不需要调用。
整个过程没有错误日志，没有任何告警，Agent 只是安安静静地把事情做错了。
这件事之后，那个团队写了一条铁律贴在白板上：
⚠️「Agent 不出错 ≠ 没犯错。不报错只等于你没看见。」
🟠 一、传统监控为什么不适用于 Agent
先看一眼传统服务的监控。
一个 HTTP 请求进来，经过网关 → 服务层 → 数据库，返回结果。每一步都有日志，慢查询有告警，异常有堆栈。出问题五分钟内排查到具体代码行。
Agent 的处理链路长什么样？
用户输入 → Prompt 拼接 → 模型推理 → 决策是否调用工具 → 调用工具A → 解析结果 → 再次推理 → 调用工具B → 模型总结 → 输出
这里面的差距在哪？
📌 传统链路是线性的、确定的。Agent 链路是分支的、概率的。
