多智能体可观测性：为何单一追踪不够
内容提要
多智能体系统的协调问题难以观测，失败常发生在交接与共享状态中。通过共享状态层（如Redis）记录决策、工具调用和记忆操作，结合完整追踪，可重建因果链，提升故障归因准确性。Redis Iris提供实时上下文引擎，支持语义检索、缓存和记忆，帮助定位问题。
延伸解读
失败常藏在交接处
多智能体系统的失败往往不是单个步骤出错，而是发生在代理之间的交接和共享状态中。文章指出，最常见的失败是设计和协调问题，这类问题通常不会抛出异常，而是产生看似合理的错误答案。例如，一个执行代理检索到了正确答案，但规划代理反复拒绝，最终超时，而正确答案一直存在于其自身的追踪中。因此，仅监控错误率会漏掉大部分语义失败，需要关注交接过程中的上下文丢失。
追踪碎片化是隐形障碍
即使每个代理都有完整追踪，跨服务调用时追踪上下文也可能丢失。文章提到，当代理调用远程MCP服务器上的工具时，追踪上下文可能在传输边界丢失，导致代理的跨度树在调用处停止，服务器开始新的无关追踪。OpenTelemetry的GenAI语义约定仍在开发中，且GenAI追踪SDK通常未配置W3C Trace Context传播器，导致LLM调用、工具执行和代理间消息分散在不同追踪中，缺乏统一标识符。这使得因果链难以重建。
共享状态层提升归因准确率
文章引用研究数据：在127个多智能体系统的失败日志中，最高性能的方法识别责任代理的准确率仅为53.5%；而使用完整追踪后，准确率提升至65.9%。这表明完整追踪有助于归因，但仍不可靠。共享状态层（如Redis）通过记录决策、工具调用和记忆操作，提供有序的审计轨迹，帮助重建因果链。但需注意，共享状态层不替代追踪，而是为追踪提供单一事实来源。
Q&A
什么是多智能体可观测性？
多智能体可观测性是指捕获并关联系统中各个智能体的行为，以便重建它们如何达到某个结果。它涉及将委派决策、工具调用、记忆读写和智能体间消息整合成一个因果故事，而不是一堆分散的日志。分析单元从提示词转移到状态转换，关注为什么编排者委派任务以及哪里开始出错。
为什么多智能体系统比单一智能体更难观测？
多智能体系统更难观测，因为工作分散在多个智能体、共享记忆和外部工具之间，失败往往发生在组件间的协调中，而不是单个步骤。此外，智能体是概率性的，相同输入可能产生不同输出，且控制流不再显式，许多决策由模型在运行时做出，导致代码无法完全记录运行时行为。
多智能体系统中的失败通常隐藏在哪里？
失败通常隐藏在交接和共享状态中。交接是智能体将工作或上下文传递给另一个智能体的时刻，信息容易丢失，导致上下文碎片化。此外，压缩和截断可能丢失关键上下文，接收智能体的上下文窗口对中间部分记忆较差。大多数失败是静默的灰色错误，不会产生硬错误信号，且失败往往远离其根本原因。
为什么单一追踪不足以观测多智能体系统？
单一追踪只覆盖单个智能体的活动，无法关联跨智能体的交接、共享状态和委派决策。追踪在跨服务调用时可能断裂，例如在MCP服务器边界或智能体间调用时，追踪上下文可能丢失，导致LLM调用、工具执行和智能体消息分散在不同的追踪中，没有共享标识符贯穿所有跳点。因此，需要更全面的可观测性来重建因果链。
共享状态层如何帮助多智能体可观测性？
共享状态层（如Redis）通过让智能体协调共享状态而非点对点消息，简化了关联。当状态由追加式日志支持时，它提供了可重放的审计轨迹，有助于在失败后重建因果链。Redis Iris提供实时上下文引擎，包括语义检索、缓存和记忆，帮助定位问题。共享状态层不替代OpenTelemetry，而是为其提供单一有序的事实来源。
多智能体系统需要追踪哪些信号来诊断失败？
为了诊断失败，追踪应连接六种信号：委派决策、工具调用、记忆读写、检索质量、权限应用和智能体间消息。这些信号通常不会默认发出，需要显式记录。关联它们需要用一个标识符贯穿每个跳点和存储，以便将智能体A的记忆写入与智能体C的错误答案联系起来。
Redis Iris如何帮助多智能体系统？
Redis Iris是一个实时上下文引擎，位于智能体和所需数据之间，提供语义检索（通过Redis Search）、语义缓存（通过LangCache）和智能体记忆（Redis Agent Memory）。它帮助智能体访问上下文，并通过Redis流支持持久化事件日志，用于协调和审计。Redis Iris不替代追踪，而是为追踪提供共享状态层。
