多智能体系统的生产级实践：当AI互相矛盾时

多智能体系统的教程大多只教你如何搭建智能体，几乎没人告诉你如何观察它们运行。本文来自一位在生产环境运行了六个月多智能体管线的开发者的经验分享，涵盖了编排模式、失败模式以及那些框架从不提及的分布式系统陷阱。

一个真实的失败现场

上周二，提交-验证自动化管线的两个组件产生了矛盾。提交智能体报告表单提交成功——记录号REF-2847，确认号APP-2847，状态为COMPLETE。验证智能体查询外部门户API，返回零条记录，状态为NOT_SUBMITTED。

两个智能体都有证据，都在描述同一事件，前后仅相差60秒。真相是：外部门户在表单提交和API可见之间存在60秒的处理延迟。提交智能体在T+0时刻是正确的，验证智能体在T+5秒也是正确的。

这不是幻觉问题，而是分布式状态问题，叠加了一个置信度展示的bug。多智能体系统的本质是分布式系统——进程间传递消息、共享状态可被不同时刻观察、外部API可能失败或延迟、重试逻辑可能将局部失败放大为全面灾难。微服务的所有失败模式在这里都适用，而框架不会帮你防御任何一项。

生产级智能体系统的定义

作者对生产级智能体系统的定义是：失败被遏制、可见，且95%的情况下无需人工干预即可恢复。剩余5%需要人工关注的情况，必须立即浮出水面，并附有足够上下文，让操作者能在10分钟内解决。

重点不是“成功的智能体”，而是“优雅失败的智能体”。

生产就绪清单包括四项硬性要求：外部调用必须有熔断器（最多重试2次，然后停止并告警）；智能体间传递结构化数据（ID、时间戳、状态码，而非自然语言）；不可逆操作后必须有验证步骤；每次调用都要有完整的可查询执行日志。

熔断器（Circuit Breaker） 是分布式系统中防止级联失败的经典模式，源自 Michael Nygard 的《Release It!》。其工作方式类似电路保险丝：当某个外部依赖连续失败达到阈值，熔断器“跳闸”，后续请求直接快速失败，不再真正发起调用，从而避免重试风暴耗尽资源。熔断器通常有三种状态——闭合（正常放行）、打开（直接拒绝）、半开（放行少量请求探测恢复）。本文作者用一张 Postgres 表实现了一个简化版本：连续两次失败即停止该步骤并告警，直到人工确认后重置。在多智能体管线中，熔断器的价值在于切断“失败→重试→更糟失败”的放大回路，让局部故障停留在局部。

幂等性（Idempotency） 指同一操作执行一次与执行多次产生相同结果。在分布式系统中，由于网络超时、确认丢失等原因，调用方常常无法确认操作是否成功，只能重试，而重试可能造成重复副作用（如重复提交表单、重复扣款）。标准解法是幂等键：调用方为每次逻辑操作生成唯一指纹，服务端先查该指纹是否已处理，已处理则返回缓存结果而不重复执行。支付网关（如 Stripe 的 Idempotency-Key 请求头）广泛采用此机制。对于有副作用的 AI 智能体操作，幂等键检查几乎是唯一能防止“重复提交”的手段。

三种编排模式的实际表现

顺序模式适用于涉及不可逆操作的场景——表单提交、邮件发送、数据库写入。作者的处理管线每条记录约需90秒，虽然慢，但n8n的执行日志提供了干净的、有序的每一步记录。当提交静默失败时，打开执行历史就能找到失败节点和确切错误。

并行模式适合摄取阶段——同时命中五个外部源。失败发生在作者试图将提交-验证步骤并行化以提速时，这直接导致了前文描述的冲突事件。现在的规则是：并行安全的前提是子任务真正独立，且合并契约在写第一行代码前就已定义。

层级模式目前尚未大规模使用。作者的编排器n8n将整个工作流视为扁平图。经验是：层级编排仅在存在真正需要判断的歧义时才有意义。如果逻辑能表达为决策树，就用带分支的顺序模式。而且在具备强大可观测性之前，不要引入层级模式——调试主管智能体与三个子智能体之间的对话，中途有智能体出现上下文漂移，不是你想在午夜做的事情。

挽救管线的熔断器

在冲突事件后，作者为每个接触外部系统的步骤添加了熔断器。实现只需一张Postgres表，记录workflow_id、step_id、fail_count、last_fail、cleared_by和cleared_at。

在每个节点运行前查询失败计数，如果连续失败达到2次，跳过执行、发送ntfy告警并停止。成功后重置计数，失败则递增。人工审查告警确认安全后，手动重置。

两次连续失败即触发停机。这个机制建成后已触发四次，每次都捕获了如果继续重试会变得更糟的问题：一次是需要10分钟退避的限流、一次导致浏览器自动化崩溃的畸形目标URL、一次前述的门户处理延迟问题、一次掩盖了家庭服务器VPN断连的网络超时。

框架跳过的关键：幂等性

如果智能体提交了表单但编排器没收到确认（网络错误、超时），它会重试——然后你会提交两次。每个有副作用的操作在执行前都需要幂等键检查。

作者的做法是：提交智能体在尝试前将指纹（record_id + entity_id + date）写入Postgres。如果指纹已存在，跳过提交并返回缓存结果。这是支付系统的标准做法，但在AI智能体架构文章中几乎从未被讨论。

结构化数据传递 是缓解上下文漂移的核心手段。自然语言摘要每经过一次智能体转述都会丢失细节、引入歧义，多跳之后原始观察可能面目全非。替代方案是让智能体之间传递带类型的字段——记录 ID、实体 ID、时间戳、状态码、置信度——而非散文式描述。这与分布式系统中“传递事件而非传递状态”的理念一致：消息应是无歧义、可验证、可重放的事实载体。作者提出的“数据库是真相来源、智能体输出只是候选事实”正是这一原则的延伸。当智能体说“提交成功”，这只是候选事实；只有当数据库中对应记录被写入并带时间戳，它才成为真相。下游智能体应查询数据库而非轻信上游的自然语言断言。

什么会最先出问题

上下文漂移最先到来。 智能体A传递摘要给B，B进一步摘要，到C时A原始观察中的细微之处已消失。缓解方式是传递结构化数据，数据库是真相来源，智能体输出只是候选事实。

重试放大紧随其后。 智能体失败，编排器重试，智能体因世界已改变而以不同方式再次失败。到第三次尝试时错误已完全不同。熔断器在第二次就停止，告警包含首次失败的上下文。

自信的错误答案排第三。 本地模型以与正确答案相同的格式和语气陈述错误结论，没有内置的不确定性信号。作者通过后果性操作后的验证步骤来应对，要求结构化输出中带显式confidence字段，低置信度路由到人工审核。智能体永远不是最后一道关卡。

智能体不是真相来源。它们是候选事实的生产者。数据库才是真相来源。

教程从不涉及的可观测性

每个多智能体教程都教你搭建智能体，几乎没有教你怎么观察它们运行。作者使用两层工具：LangFuse用于LLM调用追踪（每次调用Ollama的提示词、响应、延迟、token数），n8n内置执行历史用于工作流级可见性。

冲突事件发生时，打开n8n执行记录就能并排看到两个智能体的响应及其时间戳。58秒的间隔直接显示在日志里。没有它，作者可能要花一小时做假设；有了它，四分钟就定位了根因。

如果没有带时间戳的完整执行日志，你运行的不是生产系统，而是一个尚未失败的演示。

六个月后的反思

门户事件最终自行解决了——提交一直都在，只是验证智能体查询太快。编排器现在对涉及外部门户提交的操作，在验证步骤前等待60秒。这是个补丁，但它有效。大多数生产系统都充满了这样的补丁，每个都编码了某人在糟糕时刻遭遇的特定失败模式。

当前运行的管线不优雅，但可审计。每个决策都在日志里，每个失败都有熔断器，每个不可逆操作都有幂等性检查和验证步骤。它不会在某个部分故障时级联失败，也不会在实际上失败时静默成功。

先构建可观测性。在生产前加入熔断器。在写并行步骤前定义合并契约。智能体提示词是简单的部分。分布式系统的管道才是多智能体管线真正的生死之地——而几乎没人在写这些。