Patterns and problems in emerging multi-agent systems

2026 年,随着 Claude Code、Codex、Cursor 等 Coding Agent 在企业生产环境大规模落地,「多 Agent 系统」成为不可避免的工程现实——单个 Agent 难以处理跨工具、跨代码库、跨服务的复杂任务,多 Agent 协作成为必然选择。然而,这一现实暴露了大量尚未被系统化整理的工程模式与失败模式。围绕「多 Agent 系统的工程模式与问题」这一议题,学术界与工业界从 2025 年下半年到 2026 年上半年密集发布了一系列研究与工程实践,包括 Sakana AI 联合 UBC 的 Darwin Gödel Machine(自修改 Agent 进化,20% → 50% SWE-bench)、AgentBalance 论文(Backbone-then-Topology 设计,在 MLE-bench-30 上达到 83.1%)、AutoGen 与 LangGraph 等多 Agent 编排框架的对比研究,以及围绕 Voyager 等技能积累型系统的复盘。这些工作合在一起,清晰勾勒出 2026 年企业多 Agent 系统落地的核心模式与典型问题:多 Agent 系统的工程价值不在于「更多 Agent」,而在于「合适的 Agent 数量、清晰的协调骨架、可治理的通信协议、可审计的失败恢复机制」——这五条基线与过去十年微服务架构、Service Mesh、Container Orchestration 的演进路径一脉相承。

一、多 Agent 系统的三大典型问题

第一类问题是「协调崩溃」。当多个 Agent 在同一项目上并行工作时,各自的目标可能冲突、文件可能被同时修改、决策可能相互矛盾。这一问题在企业级 Agent 部署中尤为突出——多个 Agent 同时在生产代码库上工作,缺乏全局协调机制会导致难以追踪的错误。工程上缓解协调崩溃通常需要三类机制:显式锁(让 Agent 在修改某文件前先获取锁)、乐观并发控制(让 Agent 检测冲突后重试)、分层协调(让一个协调 Agent 统一调度其他 Agent 的任务)。

第二类问题是「错误传播」。当 Agent A 把错误结论传递给 Agent B,Agent B 基于错误结论做出错误决策,然后传递给 Agent C——错误在 Agent 之间传播、放大,最终导致系统性失败。这一问题在 LLM 驱动的 Agent 系统中尤为严重,因为 LLM 的「自信」使得错误输出看起来与正确输出难以区分。工程上缓解错误传播通常需要:每一步的输入与输出都经过验证、关键决策必须有多个 Agent 独立验证、错误检测机制必须独立于 Agent 决策循环。

第三类问题是「状态不一致」。当多个 Agent 同时维护对同一世界状态的认知时,各自的状态可能不一致,导致决策冲突。这一问题在没有持久化共享状态的纯对话式 Agent 系统中尤为常见——每个 Agent 看到的是自己的对话历史,看不到其他 Agent 的状态。工程上缓解状态不一致通常需要:共享状态存储(让所有 Agent 访问同一份状态)、乐观并发控制、版本号管理。

二、多 Agent 系统的典型工程模式

第一类模式是「监督 + worker」。一个 Supervisor Agent 负责规划、分解任务、分发给 Worker Agent、收集结果、整合输出。这是 AutoGen 的核心模式,适合需要明确分工的复杂任务。优点是结构清晰、易于理解;缺点是 Supervisor Agent 可能成为性能瓶颈。

第二类模式是「群聊 + 共识」。所有 Agent 在一个共享群聊中互相通信,通过 LLM 决策下一步该由哪个 Agent 发言。这是早期 AutoGen 的群聊模式。优点是去中心化、灵活;缺点是难以预测、Token 消耗随 Agent 数量非线性增长。

第三类模式是「图 + 显式拓扑」。开发者预先定义 Agent 之间的调用关系(谁调用谁、何时调用、传递什么),由框架按拓扑执行。这是 LangGraph 的核心模式。优点是确定性、可预测、易调试;缺点是灵活性差、初始配置成本高。

第四类模式是「技能库 + 检索」。所有 Agent 共享一个技能库,Agent 通过检索找到需要的技能并组合它们执行任务。这是 Voyager 在 Minecraft 中使用的模式,也是 Ardent 的 abilities 机制的扩展。优点是技能可复用、可累积;缺点是检索精度影响执行效果。

第五类模式是「自修改 + 自演化」。Agent 可以修改自己的代码或配置,以适应新任务。Darwin Gödel Machine 在 SWE-bench 上从 20% 提升到 50% 证明了这一模式的工程价值;Seed 项目展示了 150 行种子 Agent 可以自演化为完整的工作 Agent。优点是 Agent 可以适应新场景;缺点是难以审计、风险高。

三、AgentBalance 的「Backbone-then-Topology」设计原则

AgentBalance 论文(2025 年 12 月,Sakana AI 与 UBC 等机构)给出了一个具体的多 Agent 系统设计原则:Backbone-then-Topology,即先确定骨架 Agent(规划者、记忆管理者、状态协调者等必选核心协调节点),再围绕骨架构建 Agent 之间的拓扑(谁调用谁、何时调用、传递什么)。这一设计原则的核心洞察是:多 Agent 系统的设计应该先承认「某些 Agent 是中心化协调者」这一工程现实,再围绕这些中心化协调者优化拓扑结构,而不是假设所有 Agent 都对等且独立。

AgentBalance 的实验结果显示,在多个 LLM 与多个任务上,3-5 个 Agent 的拓扑往往能拿到接近最优的性能,而把 Agent 数量推到 10+ 之后,性能提升迅速饱和,甚至开始下降。这一发现的工程含义是:多 Agent 系统设计应该把「每个 Agent 都有清晰职责」作为第一原则,而非「Agent 越多越好」。当 Agent 数量过多时,LLM 之间的协调开销超过分工收益,系统整体效率反而下降。

AgentBalance 在 MLE-bench-30 上达到 83.1%(24 小时)与 81.5%(72 小时)的均值百分位排名,显著超过最强基线的 72.7%。这一结果说明,通过「骨架+拓扑」的精细设计,多 Agent 系统可以在成本约束下达到接近最优性能,而不需要依赖更大的模型或更多的 Agent。

四、企业多 Agent 系统落地的工程新基线

把多 Agent 系统的典型问题、典型模式、Backbone-then-Topology 设计原则合并,可以提炼出企业多 Agent 系统落地必须落地的五项关键基线。

第一项基线是「Agent 数量应该受成本与干扰双重约束」。AgentBalance 的实验已经证明「Agent 越多越好」是错误假设,企业落地时应该把 Agent 数量作为可调参数,根据任务复杂度与预算动态调整。建议企业先以 3-5 个 Agent 为起点,只在性能有显著提升时才增加 Agent,并在每次增加后做 A/B 验证。

第二项基线是「协调骨架必须显式化」。任何多 Agent 系统在规模超过 5 个 Agent 之后都必须有显式的协调骨架——这个骨架可能是图引擎(LangGraph)、群聊机制(AutoGen)、状态机(Temporal + Agent),或者是自定义的编排服务。隐式的、依赖 LLM 内部推理的协调方式在企业级场景下不可接受——它无法被审计、无法被测试、无法被恢复。

第三项基线是「Agent 拓扑必须可版本化」。多 Agent 系统的拓扑(谁调用谁、何时调用、传递什么)是企业最重要的知识资产之一,必须与代码一样接受版本控制、code review、回滚。LangGraph 把图定义为 Python 代码,支持 git diff 审查;这一做法应该成为所有多 Agent 框架的事实标准。

第四项基线是「Agent 通信必须可审计」。任何两个 Agent 之间的通信——消息内容、时间戳、上下文、决策依据——都必须被记录到持久化存储,用于事后审计、错误诊断、合规检查。AgentBalance 论文中提到的「backbone」Agent(如规划者、记忆管理者)的通信频率远高于外围 Agent,这些高频通信更必须有完整审计日志。

第五项基线是「Agent 失败必须可恢复」。多 Agent 系统必然会有 Agent 失败——LLM 调用超时、工具异常、上下文超限。协调骨架必须提供「从最近检查点恢复」的统一机制,而非让每个 Agent 自己实现失败处理。Temporal 这类工作流引擎的成熟做法是「事件溯源 + 状态机重放」,AgentBalance 的「Backbone-then-Topology」设计也内含这一思想——骨架 Agent 的状态可以在拓扑重构时被复用。

五、链路视角下的最终结论

多 Agent 系统的工程价值,可以用一句格言概括:**「让每个 Agent 都有清晰的职责,让协调骨架负责全局,让失败可以恢复」**。这一原则与过去十年微服务架构、Service Mesh、Container Orchestration 的演进一脉相承——当独立单元数量从几个增长到几十、几百,点对点通信会迅速让系统失控,中心化的协调骨架就成为必要基础设施。AgentBalance 在 MLE-bench-30 上达到 83.1%、Darwin Gödel Machine 在 SWE-bench 上从 20% 提升到 50%、LangGraph 的图引擎成为企业落地首选——这些事实都指向同一个工程共识:多 Agent 系统不是「更多 Agent 更好」,而是「合适数量 + 清晰骨架 + 可治理拓扑」更好。

把视角拉到企业 AI 落地的长周期,可以看到三个必然迁移。第一,多 Agent 协调必须从「Agent 之间点对点对话」迁移到「统一编排骨架 + 显式拓扑」,这一迁移让 Agent 能够在企业级场景下被审计、被测试、被恢复。第二,Agent 数量必须从「固定 N 个」迁移到「成本与干扰双重约束下的动态数量」,AgentBalance 给出的「3-5 个起点 + 性能验证后扩展」是工程上可执行的方案。第三,Agent 系统必须从「独立 Agent 集合」迁移到「可恢复的统一系统」,Temporal 这类工作流引擎的事件溯源 + 状态机重放机制应该成为 Agent 失败恢复的事实标准。

模型可以迭代——Claude Sonnet 5 之后会有更强的 Sonnet,Fable 5 之后会有更强的 Opus——但多 Agent 系统的工程基线(数量约束 / 协调骨架显式化 / 可版本化拓扑 / 可审计通信 / 可恢复失败)不会因为模型升级而失效。把资源投到这些不散的链路层要素上,是企业 AI 落地性价比最高的工程方向,也是把「模型可换、链路不散」立场落到多 Agent 系统领域的具体实践。多 Agent 系统的工程教训反复表明:Agent 数量不是越多越好,Agent 智能不是越强越好,真正重要的是「合适数量 + 清晰职责 + 协调骨架 + 可治理拓扑」——这四条原则共同构成了企业多 Agent 系统落地的工程新基线。