模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第21章 — 多智能体编排的艺术
Token用量: 约 6,200 input + 2,050 output
21.1 五种编排模式
“多智能体”不是一种单一架构，而是一组不同的协调拓扑。两个系统都可能会启动 subagent，但它们的真实行为可能完全不同，因为任务如何拆分、控制权如何流动、上下文如何传递、结果如何合并，决定了系统的本质。对于编码智能体而言，最值得分析的五种模式是：Orchestrator-Worker（编排者-执行者模式）、Pipeline（流水线模式）、Swarm（群体并行模式）、Mesh（网状协作模式）、Hierarchical（层级式模式）。这里的“拓扑”不是传统 CS 教材里最常见的 agent 分类词，但借用分布式系统里的结构视角来理解非常合适：重点不是有多少节点，而是节点之间怎么连接。
先看 Orchestrator-Worker。它的核心是一个中心编排者负责和用户保持主契约：拆任务、派子任务、收结果、做最终综合。很多实际系统都会从这里起步，因为它最容易追责，也最容易调试。OMO 在这方面非常典型：父会话保持主控地位，后台子智能体负责局部工作，通知机制把结果送回父上下文。Claude Code 也能做类似的事情，只是呈现方式更“产品化”，用户看到的是任务被派出去了，而不是显式的 runtime 编排图。OpenCode 则更像底层宿主，它给你 agent 能力和插件能力，但不强制你采用这种监督结构。这个模式最大的优点是控制力强，最大的缺点是中心节点会成为瓶颈：如果总控拆分错误，下面再多 worker 也会低效。
第二种是 Pipeline。流水线模式不是“很多 agent 一起讨论”，而是“工作沿着若干阶段顺序推进”。比如第一阶段搜集证据，第二阶段分析原因，第三阶段执行修改，第四阶段验证，第五阶段整理结果。在系统工程里，这种结构的价值很大，因为阶段边界清楚，失败点更容易定位。OpenCode 天然很适合被理解为 Pipeline，因为它本身就是一条线性的 ReAct 主循环。OMO 则把流水线推进到了策略层：消息变换、hook 链、工具守卫、续跑恢复、通知这些环节，本质上都是串联工序。Claude Code 也很有流水线特征，只不过它更把流水线放在权限、安全、压缩和产品体验层。换言之，Pipeline 的关键不是“顺序”本身，而是把复杂行为拆成可检查的阶段。
第三种是 Swarm。这个词在传统教材里并不是 agent 系统的标准一级术语，这里可以把它理解为“群体式并行搜索结构”：多个子智能体同时工作，中心控制相对较弱，重点是覆盖面而不是严格过程一致性。Swarm 特别适合大仓库搜索、多个方案并行尝试、外部信息广撒网检索这类任务。OMO 是三者里最像真正 swarm 系统的，因为它明确支持后台并发、模型/提供商并发上限、角色化子智能体以及结果回收。Claude Code 也能做出某种 swarm 效果，但更收敛、更受控。OpenCode 本身不天然偏 swarm，而是允许开发者在其之上自行搭建。Swarm 的优点是广度，缺点是成本容易失控、重复劳动多、最终整合困难。
第四种是 Mesh。Mesh 原意是“网格”或“网状”，这里指多个智能体之间可以横向影响，而不是所有信息都必须经过中心编排者。Mesh 很诱人，因为它像是“专家网络”在协同。但它也最难控。几个 agent 如果彼此递归影响，很容易出现上下文漂移、错误放大、责任不清。OpenCode、OMO、Claude Code 都不是纯正的 mesh，这其实是好事，因为纯 mesh 太难 debug。不过 OMO 的智慧积累系统会让前面的 agent 发现被后续 agent 继承，这是一种“间接网状耦合”；Claude Code 在多个 task 汇总回主上下文时，也会产生弱 mesh 效果。也就是说，它们不是直接 peer-to-peer 对话式 mesh，而是通过共享摘要、共享中间产物形成弱网状连接。
第五种是 Hierarchical，即层级式编排。层级式不是简单主从，而是不同抽象层同时存在：顶层做规划，中层做协调，底层做搜索、执行、验证。这里的“抽象层”是计算机系统里常见的概念，意思是不同层处理不同粒度的问题。复杂工程任务天然跨层：架构决策不是文件编辑，仓库搜索不是最终交付，安全审计也不是具体实现。OMO 在层级式设计上最鲜明，因为它不仅有多角色 agent，还有语义类别、权限约束、续跑机制与工具边界。Claude Code 也有层级性，但更柔和，更多体现在主 agent 与 task agent 的上下关系。OpenCode 仍然更像层级结构的基础设施，而不是层级本身。
可以把五种模式做成一张更工程化的对比表：
| 模式 | 控制方式 | 可扩展性 | 容错性 | 调试难度 | 延迟特征 | 适用场景 |
|---|---|---|---|---|---|---|
| 编排者-执行者 | 中心化控制 | 中等 | 中等，中心节点仍是逻辑单点 | 低到中 | 中等 | 需要一个统一答案的拆解型任务 |
| 流水线 | 分阶段控制 | 高 | 高，前提是阶段可重试可隔离 | 低 | 中到高，但可预测 | 合规、验证、可重复工作流 |
| 群体并行 | 弱中心协调 | 高，尤其适合广度扩张 | 混合，冗余搜索有益但整合易失败 | 高 | 初始低、整合高 | 大范围搜索、并行假设检验 |
| 网状协作 | 横向互联 | 理论上高，实际常受限 | 有潜在韧性，但容易漂移 | 很高 | 不稳定 | 研究型批判网络、专家互审 |
| 层级式 | 多层命令链 | 高 | 中到高，取决于层间边界是否清楚 | 中到高 | 前期高、后期返工少 | 跨抽象层的大型工程任务 |
这里最重要的结论不是“哪一种最先进”，而是不同模式优化的是不同维度。中心化控制有利于调试，却可能限制规模；群体并行扩大了覆盖面，却增加了汇总和冲突处理成本；层级式提升了职责清晰度，却引入管理开销；流水线最可靠，但可能牺牲灵活性；网状协作理论上最像“真实团队”，但工程上最难驯服。
因此，多智能体系统设计不应该从意识形态出发，而应该从任务拓扑出发。如果任务是大仓库侦察，swarm 倾向有意义；如果任务是生产级迁移，pipeline 加 hierarchy 更稳；如果任务需要一个连贯且可追责的最终回答，Orchestrator-Worker 常常是默认首选。真正成熟的系统，往往不是只用一种，而是混合使用。OMO 就很典型：顶层是编排者-执行者，角色设计是层级式，探索阶段有 swarm 味道，治理层又带 pipeline 属性。
所以，多智能体编排的艺术，不是“多开几个 agent”，而是选对责任图。系统往往不是死于没有更多智能体，而是死于让错误的智能体结构承担了错误的任务结构。