AI Agent集群监控实战：别信你的直觉，信Telemetry

用OpenTelemetry给AI Agent集群做观测（Observability）简直是救命稻草。我最近折腾了一个叫DevSwarm的玩意，能把一个Prompt直接变成全栈App，里面跑了5个不同分工的开源模型（Planner, Frontend, Backend, Critic, Doctor）。最讽刺的是，原本打算用SigNoz来证明我的架构很牛逼，结果数据直接扇了我一巴掌：我之前对系统的认知几乎全部是错的。

很多性能瓶颈我之前一直赖模型不行，结果查了Trace才发现是我自己设的限制太死；甚至我一直以为最稳的Review Agent，在数据面前反而是最弱的一环。这种坑光看代码根本看不出来，必须得有具体的Span事件和仪表盘支撑。

这个集群的逻辑是：Planner出计划 → 前后端并行开发 → Critic审计 → 没过就打回重做。

模型分工配置（全开源权重模型）：

• Planner/Frontend/Doctor： 用的是 GLM-5.2，负责规划、前端实现和路由修复。
• Backend： 选了 Qwen3-Coder-480B，搞定Express服务端。
• Critic： 用 Kimi-K2.7-Code，负责把关和路由。

为了实现全流程可观测，我给每个模型调用都打上了 llm. 开头的Span，遵循GenAI语义规范。部署SigNoz是用Foundry一键搞定的，配置直接写在yaml里，保证能复现。

具体的观测维度：

• Traces： 追踪每个模型调用的全过程，能一眼看出哪个环节卡住了，或者哪个Agent在偷偷地“思考”太久。
• Metrics： 实时监控Token消耗和调用次数。
• Logs： 记录具体的报错和Fallback触发情况。

如果你在搞多Agent工作流，千万别在代码跑通后才想观测，得先做观测再优化。因为Agent集群的失败方式极其诡异——请求可能成功返回了，但产出的代码是垃圾；或者主模型挂了，Fallback接管得太顺滑，导致你根本没意识到系统在降级运行。

给想尝试部署的同学参考，基础配置大概长这样：

# casting.yaml 核心配置片段
deployment:
  provider: huggingface_inference
  observability:
    tool: signoz
    sampling_rate: 1.0
    span_prefix: "llm."

这种基于数据的开发模式比凭感觉调优快得多。