AI Agent 可观测性实战：用 Tracing 驯服会「发疯」的智能体
当 Agent 在多步推理中悄悄跑偏，日志和 print 根本救不了你。本文用 OpenTelemetry 语义约定搭建一套可落地的 Agent 可观测性体系，覆盖 trace、span、token 成本与失败归因。
2026年，Agent 已经从”炫技 Demo”变成了”生产系统的一部分”。但几乎所有团队都会撞上同一堵墙：Agent 昨天还好好的，今天就开始胡言乱语。 而当你打开日志，看到的只有一堆 print(response) 和零散的 JSON，根本无法复现它到底在哪一步跑偏。
问题的本质是：传统软件的日志是”线性”的，而 Agent 的执行是”树状递归”的。一次请求可能触发 8 次 LLM 调用、5 次工具调用、2 次子 Agent 委派。你需要的不是日志，而是 Tracing（链路追踪）。
为什么日志救不了 Agent
假设用户问：“帮我把上季度销售数据做成图表并发给张总。”
Agent 的内部执行可能是：
- 解析意图 → 调用
query_db工具 - 拿到数据 → 调用代码解释器画图
- 画图失败（字段名猜错）→ 自我修正重试
- 调用
send_email，但收件人是”张总”而非邮箱地址 → 向用户提问
如果第 4 步出错，日志里只会留下一行”email sent”。你不会知道它其实发给了默认地址，也不会知道它执行了 3 次数据库查询。Tracing 的价值就在于：把每个决策点变成一个有时间戳、有输入输出的 span。
用 OpenTelemetry 给 Agent 建模
OpenTelemetry 在 2025 年发布了 GenAI 语义约定（semantic conventions），定义了 gen_ai.* 属性的标准命名。这套约定是 2026 年的事实标准，值得直接用。
一个典型的 Agent trace 层级应该是：
agent.invoke (root span)
├── llm.chat (第1次调用)
├── tool.query_db
├── llm.chat (第2次调用)
├── tool.code_interpreter ← 这里失败
│ └── llm.chat (自我修正)
└── tool.send_email关键在于给每个 span 打上这几类属性：
gen_ai.usage.input_tokens/output_tokens：这是算钱的gen_ai.request.model：同一 trace 里可能混用了不同模型gen_ai.response.finish_reason：是正常停止还是被截断？tool.name和tool.result.status：工具调用的成功/失败
有了这些，你就能回答”这次请求花了多少钱、在哪一步超时、是模型问题还是工具问题”。
三个必须监控的信号
第一，Token 成本的异常突增。 Agent 的死循环往往表现为”同一个工具被反复调用”。用 trace 统计每个 root span 下的子 span 数量，一旦超过阈值就告警。我见过一个团队因为 Agent 陷入重试循环，一夜烧掉 2000 美元。
第二，工具调用的失败率。 把 tool.result.status = error 的占比做成看板。工具失败率突然飙升，通常意味着上游 API 变更了 schema，而不是 Agent 变笨了。
第三，LLM 调用的 P95 延迟。 多步 Agent 的延迟是累加的。如果单次调用 P95 从 2 秒涨到 8 秒，整个任务可能从 10 秒变成 40 秒。这时候用户早就关掉页面了。
落地的三个务实建议
从 OpenLLMetry 或 Langfuse 起步。 不要自己从零造轮子。Langfuse 支持自托管、有开源版本，能直接渲染上面那种树状 trace，5 分钟就能接入 LangChain / LlamaIndex / 原生 SDK。
trace_id 必须贯穿全链路。 把 trace_id 返回给前端，让用户”举报问题时附上 trace_id”。这能把线上问题排查从”盲猜”变成”点开链接看回放”。
对采样率做权衡。 别全量存 trace，成本会爆炸。建议成功请求采样 5%，失败请求和成本超阈值的请求 100% 保存。
结语
Agent 的可靠性不是靠”写更好的 prompt”实现的，而是靠可观测性让问题变得可见、可复现、可归因。当你能一眼看出 Agent 在第几步、花了多少钱、为什么跑偏时，你才真正拥有了一个可以托付生产流量的系统。日志是给机器看的，trace 是给工程师看的——2026 年，你需要后者。