AI Agent 可观测性：破解多步推理黑盒

AI Agent 可观测性：破解多步推理黑盒

你上线了一个 AI Agent，它表现不错——直到某天客服甩来一条投诉：“你们的智能客服把用户的退款金额算错了，用户要起诉。” 你打开代码，一脸懵：它到底哪一步推理错了？是检索漏了退款政策？还是某个工具返回了错误数据？ 这就是多步推理的黑盒问题——一个请求内部要经历「规划 → 检索 → 调工具 → 反思 → 回答」好几步，任何一步出错，最终都表现为\”答案错了\”，但你根本定位不到是哪一步。 本文带你搞懂 Agent 可观测性，把黑盒拆开看。

一、为什么传统监控在 Agent 面前失灵了

先看一个扎心的对比：

一句话总结：传统监控只能回答\”服务还活着吗\”，Agent 可观测性要回答\”答案对不对、成本合不合理、推理路径讲不讲得通\”。

而 Agent 最让人头疼的地方恰恰在于：一个请求内部会经历「规划 → 检索 → 调用工具 A → 调用工具 B → 反思 → 回答」这样一串步骤。任何一步出错，最终都表现为\”答案错了\”，但你根本不知道是哪一步。

二、核心武器：Trace（追踪）

破解黑盒的第一把钥匙，是把一次 Agent 执行记录成一棵 Span 树。

• Span：一次动作（一次 LLM 调用、一次工具调用、一次向量检索）
• Trace：一次完整的用户请求，由多个 Span 嵌套而成
• Thread：一次完整对话（多轮 Trace 串起来）

一个多步 Agent 的 Trace 长这样：

用户请求
└─ [Span] 规划（LLM 调用 #1）
├─ 输入：完整上下文 + 用户问题
└─ 输出：计划「先查天气，再查机票，最后对比」
├─ [Span] 工具调用：get_weather(\”上海\”)
├─ 参数：{\”city\”: \”上海\”}
└─ 结果：晴，32℃
├─ [Span] 工具调用：search_flights(…)
│ └─ 结果：3 条航班
└─ [Span] 生成回答（LLM 调用 #2）
├─ 输入：天气 + 航班结果
└─ 输出：最终答案

有了这棵树，一个失败的请求就不再是谜：你打开它的 Trace，就能看到它检索到了什么、计划是什么、哪一步走偏了。

统一标准：现在行业已经形成共识——用 **OpenTelemetry 的 GenAI 语义约定（GenAI Semantic Conventions）**来定义这些 Span。它规定了标准的 Span 名称（create_agent、invoke_agent、execute_tool）和属性（gen_ai.usage.input_tokens、gen_ai.usage.output_tokens 等）。选一个支持这个标准的工具，等于给自己上了\”防锁死\”保险。

三、Agent 特有的观测指标

除了通用的延迟、成本、错误率，Agent 还需要一组专属指标，这些才是多步推理的\”体检报告\”：