你的 AI 智能体其实是披着外衣的分布式系统——用 OpenTelemetry 和 SigNoz 监控它，别等它把你搞破产
这篇博文是为 WeMakeDevs × SigNoz 联合举办的 Agents of SigNoz 黑客马拉松写的一个热身帖。接下来我要捍卫一个观点：当你把大语言模型（LLM）放进循环里、再给它配上工具的那一刻起，你就不再是在构建应用，而是在运营一个分布式系统——一个非确定性的、跨越你不受控的网络边界向外发散的、并且按 token 向你收费的系统。大多数团队在生产环境里跑这些系统时，所使用的监控手段还不如一个玩具级的 CRUD 应用。这个差距正是凌晨两点的故障、莫名其妙的账单、以及静默的质量退步的老巢。我想具体地说明：为什么 AI 智能体迫切需要可观测性？2026 年符合标准的方式长什么样？以及为什么像 SigNoz 这样原生支持 OpenTelemetry 的后端是存放这些数据的正确选择。
传统监控看不见的故障模式
常规服务有一条有边界的、基本确定性的执行路径。现有的 APM（应用性能监控）能抓住那些出问题的地方：500 错误、慢查询、内存泄漏。现在看看一个智能体在处理单个用户请求时实际做了什么：
用户请求
└─ LLM 调用 #1（规划） → 1,900 tokens
└─ 工具：vector_search(k=8) → 420 ms, 8 个块
└─ 工具：sql_query() → 出错/重试 → 重试 3 次
└─ LLM 调用 #2（重新规划） → 2,300 tokens
└─ 工具：http_fetch() → 200 OK, 14 KB 注入上下文
└─ LLM 调用 #3（综合输出） → 3,100 tokens
这背后是一连串操作：三次大模型调用、四次工具调用、三次重试以及一次 14 KB 的上下文注入，所有这些都隐藏在一个聊天气泡后面。每一次调用都是一个独立的故障面，而真正有趣的故障恰恰是那些你传统的 HTTP 状态码仪表盘永远无法捕捉到的——比如成本失控。重试循环或者过于激进的重新规划步骤不会抛出异常——只会悄悄让你的 Token 消耗翻上十倍。对于 Agent 来说，成本本身就是一种主要故障模式，而不是账单里的一个脚注。一次失控的对话可能比一千次正常对话花得还多。还有无限制的工具调用循环：Agent 调用了一个工具，不满意结果，于是再次调用，调了又调。没有抛出任何异常。延迟飙升，Token 燃烧，唯一的外部症状就是用户放弃了。更吓人的是静默质量下降：系统返回 200 OK，给出的答案流利、自信，但却是错的。你的日志和指标纹丝不动，直到你从工单或者流失的客户那里得知。此外还有上下文与检索投毒：检索步骤拉到了坏的数据块，或者某个工具给 prompt 注入了不可信的文本，模型乖乖地照着做了。从外部看，一切正常。最后是难以复现：采样温度和模型的非确定性意味着“在本机复现一下”往往是做不到的。如果你捕获了链路追踪，那追踪本身就是复现手段。
核心脉络在于：Agent 的失败是语义性和经济性的，而不仅仅是运维层面的。你需要能看到 Token、成本、工具参数、检索结果、模型版本以及回答质量——所有这些都不是传统技术栈设计用来记录的。
OpenTelemetry，以及为什么 GenAI 语义约定很重要
OpenTelemetry（OTel）是 CNCF 推出的、与厂商无关的标准，用于发射追踪（trace）、指标（metric）和日志（log）。这套原语几乎完美地映射到 Agent 上：
- 一个追踪对应一次完整的端到端请求——上面整个调用树就是一个追踪。
- 一个 Span就是树中的一个节点（一次 LLM 调用、一次工具调用、一次检索），带有开始时间、持续时长、状态和任意的键/值属性。
- Span 链接和父子关系可以重建因果结构——哪个 LLM 调用触发了哪个工具调用。