多 agent 可观测性：为什么单条 trace 不够用

单个 AI agent 通常容易追踪：一个循环、一个上下文窗口、一条 trace，从头读到尾就能发现问题。多 agent 系统完全不同——agent、共享内存和外部工具把工作拆散，很多故障来自组件之间的协调而非任何单一步骤。Redis 官方博客这篇文章系统梳理了多 agent 可观测性的难点、故障藏身之处，以及为什么共享状态层能帮上忙。

多 agent 系统为什么更难观测

两个特性让多 agent 系统难以上手，而标准仪表盘通常两者都看不出来。

agent 决策发生在运行时，不在你的代码里。传统软件的控制流是显式的：读源码就知道下一步执行什么。在 agentic 系统里，调用哪个工具、如何拆解问题、何时停止，都由模型在运行时决定。随着 LLM 主导越来越多的应用，代码不再完整记录运行时行为——只有 trace 能。

失败点离根因很远。一项已发表分析发现，75.17% 的观测失败是"静默灰错误"——运行完成却不产生任何硬错误信号，只有仔细检查才看得出问题。有个案例中，执行 agent 已检索到正确答案，重规划 agent 却反复拒绝，直到系统超时——正确答案全程就在它自己的 trace 里。后续步骤还可能部分弥补前面的错误，进一步掩盖根因。

归因差距：一项评估用了 127 个多 agent 系统的故障日志，表现最好的方法识别责任 agent 的准确率只有 53.5%；有了完整 trace 才升到 65.9%——更好但仍不可靠。最常见的故障是设计与协调问题，两者通常都不会抛异常：对齐失误的交接产生的是"看似合理的错误答案"，而不是栈回溯，所以只靠错误率监控会漏掉大多数语义故障。

上下文在交接中丢失

交接（handoff）是信息最容易丢失的地方，即上下文碎片化，机制有几种：污染（幻觉进入上下文，下游 agent 持续引用）、干扰/混乱/冲突（冗长、杂乱或矛盾的上下文降低模型输出质量）、衰减（上下文变长后回忆退化，早期信息实际上消失）。

背后是两个驱动机制：压缩和截断。激进的压缩可能丢掉当时看不出价值、后来才重要的细节；截断可能在交接时丢掉已验证数据，逼下游 agent 补空。接收方 agent 的上下文窗口也在帮倒忙——模型对长上下文开头和结尾的内容回忆远好于中间。

遥测本身也会碎片化

即便语义上什么都没丢，遥测本身也会碎：OpenTelemetry 的 GenAI 语义约定定义的是 invoke_agent 顶层 span 加每个 LLM 调用和工具调用的子 span，但这些约定仍在开发中，各段之间的管道有缺口。agent 调用远程 MCP 服务器上的工具时，trace context 会在传输边界丢失：agent 的 span 树在调用处终止，服务器开一条全新的不相关 trace。agent 间调用也撞同样的墙：GenAI 追踪 SDK 通常不配置 W3C Trace Context 传播器，推理、检索、工具执行的子 span 常常无法识别是谁发起的。结果是 LLM 调用在一条 trace、工具执行在另一条、agent 间消息在第三条，没有共享标识符贯穿每一跳。

该追踪什么：六类信号

能用于排查"哪个 agent 出错了、为什么"的 trace，通常要串起六类信号：决策元数据与记录的理由（为何委托给这个 agent、为何选这个工具、何时停止）；agent 间消息（每次交接传了什么、丢掉了什么）；内存读写（每个 agent 读了什么、写了什么、如何影响后续决策）；检索质量（块是否相关，不只是快）；工具输入输出与状态变更；身份与权限范围（调用以哪个身份运行、应用了哪些权限）。

没有一个是新奇的东西，问题在于大多数系统默认不输出它们：决策背后的推理、谁调用了什么、应用了哪些权限，除非你主动记录，否则很少会进 trace。难点在关联——用一个标识符贯穿每一跳和每个存储，让 agent A 的一次内存写入出现在 agent C 错误答案的因果历史里。

共享状态层的价值

当 agent 通过共享状态而非分散的点对点消息协调时，关联会更容易。这个想法不新：1980 年代的 blackboard 架构就通过所有专家共同读写的一个全局数据结构协调独立专家。同样的设计一箭双雕：agent 看到同一块板就不必互相发消息；而用 append-only 日志支撑该状态，故障后就有了可回放、可审计的轨迹，而不是从散落日志拼出来的时间线。

作者也明确划了一条边界：Redis 存储、索引并提供共享状态；你的应用和追踪栈决定记录什么、如何分析。共享状态层不取代 OpenTelemetry 插桩，而是给插桩一个单一的、有序的真源。它还能扛住失败：任务进度在共享状态里时，运行中途死掉或客户隔天回来，都能从已保存的上下文恢复而不是从头开始。

来源：Multi-agent observability: why one trace isn't enough - Redis Blog