Agent 集群可观测性：在千并发 Agent 运行中监控而不陷入仪表盘盲区
在生产环境中运行一百个 agent 感觉还可以管理。你有追踪数据，有仪表盘，知道什么时候出问题。但运行一千个并发 agent 完全是另一个问题——不是因为 agent 更复杂，而是因为你为十个 agent 建立的监控模型在你注意到之前就已经悄然失效了。
失败模式很微妙。一切看起来都很正常。你的 span 树都在。错误率很低。然后，一个导致 40% 会话输出质量下降长达六小时的提示词回归，只因为客户投诉才浮出水面——而不是被你的可观测性系统捕获。
这就是仪表盘盲区问题：单 agent 追踪在小规模下运行良好，在集群规模下则会悄然失效。以下是它发生的原因及应对之道。
为何单 Agent 追踪在大规模下失效
传统分布式追踪假设请求生 命周期是可预测的：请求进入，遍历几个服务，然后返回。该请求的 span 树是有界的、可读的。单个追踪能告诉你发生了什么。
Agent 工作负载打破了这一模型所依赖的每一个假设。单个用户请求可能触发五次或更多 LLM 调用、三次工具调用、两次向量数据库查找，以及数量不定的重试周期——所有这些都在一次"运行"中。该运行的 span 树深度深、分支多，且结构是非确定性的。明天相同的输入可能产生结构完全不同的树。
遥测数据量的增长速度很快。典型的基于 RAG 的 agent 管道产生的遥测数据是等效 API 调用的 10 到 50 倍，因为你现在需要追踪每次模型调用的 token 数量、缓存命中率、嵌入相似度分数、护栏触发率以及每步的成本归因。运行自主多 agent 工作流（agent 派生并协调其他 agent）的团队报告称，与其应用程序遥测基线相比，遥测数据量增加了 50 到 100 倍。这通常是可观测性预算意外翻倍的地方。
但数据量是可管理的部分。更深层的问题在于，集群规模的 agent 监控需要回答个别追踪无法回答的问题：
- 失败率是否在多次运行中相关联，还是孤立于特定配置？
- 提示词变更是否在每个追踪的错误率上升之前就已经降低了整个集群的输出质量？
- 哪批 agent 在这一小时内消耗了 80% 的 token 预算？
- 是否有 agent 卡住了——在相同工具调用上循环、消耗预算却没有返回任何用户价值？
这些问题没有一个能通过阅读单个 span 树来回答。它们需要集群级别的聚合。
真正重要的集群级信号
相关失败率
最重要的信号不是你的总体失败率——而是失败是否以暗示系统性原因的方式跨运行相关联。
随机工具失败是预期的。意外的是，当十个 agent 在 30 秒内都在其网页搜索工具调用上失败，或者当特定工具的失败率对于共享特定系统提示变体的 agent 激增时。相关性以总体错误率所隐藏的方式揭示因果关系。
在操作上，这意味着你需要按提示词变体、模型版本、工具名称和用户群体切分失败率。"错误率：2%"的平坦仪表盘几乎毫无用处。"在过去 15 分钟内，使用 prompt_v7 的 agent 的 web_search 工具错误率上升了 8 倍"才是可行动的。
成本分布百分位数
每次运行的平均 token 成本是一个虚荣指标。钱花在了 P95 和 P99 上。
长尾 token 消耗的 agent 运行——递归过深、获取了太多文档、或在超时前进入软循环的 agent——个别来看很昂贵，整体来看很危险。P99 token 消耗的单次 agent 运行成本可能是中位运行的 20 到 50 倍。
有效的检测模式：当 P95 token 消耗在滚动一小时窗口内跳升超过 30% 时发出警报。这能在成本账单反映之前捕获上下文窗口膨胀（通常是工具输出臃肿或内存积累的症状）等问题。已实施此方案的团队报告，比标准账单异常检测早数小时捕获成本峰值。
P99 执行深度
执行深度——agent 在完成或失败之前所走的步骤数——是一类没有直接信号的失败的代理指标：运行时间越来越长但没有取得进展的 agent。
大多数健康的 agent 运行在有限的步骤数内完成。当 P99 执行深度开始攀升——或者当分布出现长尾，一小部分运行占用中位数 3 倍步骤时——这是某些 agent 未能收敛的信号。
危险的变体是静默循环：一个 agent 反复以微小变化调用同一工具，返回技术上成功的完成，但从未真正解决用户的问题。这些运行不会出现在你的错误率中。它们只出现在你的成本分布和执行深度百分位数中。
卡住 Agent 检测
卡住的 agent 是指已进入无法向前推进但尚未超时或出错的状态。实际定义：一个重试同一工具调用超过 N 次，或在步骤上花费超过 M 秒但没有状态变化的 agent。
这与失败的 agent 不同。失败的 agent 会出现在你的错误率中。卡住的 agent 会出现在你的延迟分布中——具体来说是你的 P99 和 P99.9 会话持续时间指标中。它们还作为极端异常值出现在你的每会话成本直方图的右尾中。
检测需要监控单次运行内每次工具调用的重试次数，而不仅仅是所有运行中的总体重试率。一个 agent 在一次运行中重试 search_documents 八次，与整个集群 8% 的重试率是截然不同的信号。
行为指纹：在指标移动前捕获回归
集群规模 agent 监控最强大的技术也是对来自传统可观测性的工程师来说最不直觉的：行为指纹。
核心洞察是，给定任务的一组 agent 运行具有一个特征统计形状——由执行追踪分布定义的指纹。当 agent 正确工作时，这个指纹是稳定的。当提示词被更改、模型被升级或工具模式漂移时，指纹会改变。通常，指纹会在你的错误率、延迟或质量指标移动之前改变。
