Agent Commander 笔记 #3：智能体编排模式，Loop、Graph、层级选哪个

Agent Commander 笔记 #3：智能体编排模式，Loop、Graph、层级选哪个

六种编排模式摆在我面前的时候，我问自己的不是「该选哪种」。我问的是它们之间的根分歧在哪。

记忆系统按注入方式分了层，指挥框架按决策权分了级。两个系统都在做同一件事——把层级当作核心组织原则。设计这个原则的时候我凭的是直觉——复杂系统自然趋向分层，这是从 #1 跨学科调研里验证过的结论。但这个原则在编排模式全景图里的位置，我一直没搞清楚。它不是唯一的组织方式，甚至有足够多的替代方案同样合理。我选的这条路是主流还是偏锋，跳过的那些路会不会在某天堵回来，当时回答不了。

于是我做了一件事：把所有主流的编排模式拉出来过一遍，再找一把学术尺子量一量。这篇记的就是结果——不是什么了不起的发现，只是一个坐标和一个坐标带来的三个缺口。

六种模式——分歧不在技术，在「谁来决定下一步」

调研覆盖了六种主流的智能体编排模式。它们的区别不在技术栈，在一个更根本的问题上：谁来决定下一步做什么。

想清楚这个问题之后，六种模式的差异就一目了然了。每一种模式本质上是对同一个问题的不同回答。

Loop（ReAct）把控制权交给 LLM。模型在每个步骤中自主决定下一步是搜索还是回答，控制权完全在模型手里。ReAct 的核心是 Thought→Action→Observation 循环——信息不足时，模型可以边走边看边调整。Anthropic 的 tool-use loop、Plan-Execute、Reflexion 都是这个模式的变体。优势是灵活，代价是不可预测。

Graph/DAG 把控制权交给开发者。LangGraph 的 StateGraph 是典型代表——预先定义所有允许的路径，节点（LLM 调用、工具执行、条件判断）、边（普通边、条件边、循环边）、共享状态对象，全部在编译时确定。运行时状态通过 reducer 函数合并冲突，每个 super-step 自动 checkpoint 持久化。优势是可预测和可恢复——画出整张图就能理解整个流程。代价是灵活性受限于预定义的图结构。

层级/树形把决策权按层分配。上层拆解任务并委派，下层执行并汇报。职责清晰、单点决策、可追溯。LangGraph 的 Hierarchical Agent Teams（supervisor + subgraph）和 AutoGen 的 Nested Chat 都在朝这个方向走。优势是抗整合性妥协——我们在 #2 里详细讲过这一点。代价是 Commander 可能成为决策瓶颈。

事件驱动交给运行时路由。AutoGen Core 是原生实现——agent 不直接调用彼此，发布消息到 Topic，Runtime 根据订阅关系转发。松耦合、天然支持并行。在 agent 编排领域尚未成熟，但潜力巨大——尤其适合 dev 产出后自动触发 test 审阅这类跨小队流水线场景。

辩论/协作靠共识机制收敛。多 agent 对同一问题独立给出答案，然后相互辩论，通过投票或共识收敛。Du et al. 2023 的开山之作证明了这种方式能提升事实准确性和推理深度。ChatDev 和 MetaGPT 是工业级的角色扮演协作实现。优势是多视角覆盖盲区，代价是如果缺乏收敛约束，结果容易被拉向均值。

声明式/DSL 把编排写进配置文件。Dify 的可视化 YAML 编排、CrewAI 的 @start() @listen() 装饰器、以及本项目用的 opencode skill 定义，都属于这个范畴。门槛低、可审计，但灵活性受限。

这不是一个技术选型问题，是一个架构哲学问题——选择信任谁来做决策。下表总结了六种模式的本质差异，每一种的「控制权」那列就是答案：

我在六种模式的表前加了同一句话——选择信任谁。不是故弄玄虚，是想清楚一件事之后才能继续想下一件：信任谁来决策。

信任模型，选 Loop。信任开发者，选 Graph。信任层级结构，选层级。信任松耦合，选事件驱动。信任多样性，选辩论。信任可读性，选 DSL。不是一个技术选型，是一个哲学选择。

我选层级，不是偏好——是正向推理加反向验证的双重确认。

当然，六种模式在实际系统中很少孤立使用。LangGraph 的 agent node 内部嵌套了 ReAct loop——Graph 容器里跑 Loop。AutoGen 的 GroupChat 混合了事件驱动和层级嵌套。我们的架构同样是混合体：三层指挥是层级骨架，探索小队的 3 轮碰撞借用了辩论模式，opencode skill 定义属于声明式 DSL。分类是为了理解，不是为了站队。

为什么层级——一个正向推理，一个反向验证

正向推理是关于规模的数学。

三十个 agent 平级协作时，协调成本的增速远超过并行收益的增速。管理学家 Graicunas 在 1933 年算过一笔账：n 个人的管理关系数是 n(2ⁿ⁻¹ + n - 1)。6 个 agent 就有 222 种关系，平级管理在数学上就不可能。层级把 O(n²) 压缩到 O(n)，三层就够了。Commander 管五个队长，每个队长管三到六个队员——每层的控制幅度都在 Miller 7±2 的工作记忆上限内。

这不是一个"组织架构只是风格问题"的场景。当 n=30 时，平级的关系组合数量是一个三十九位数——这不是管理问题，是一个数学问题。层级不是一种选择，是一种必然。

这是所有复杂系统共同的演化方向。人脑、蚁群、军队，三个独立演化的系统在信息管理上收敛到相同的分层原则——这件事在 #1 里已经验证过。记忆管理的结论在指挥调度上再次成立：分层不是什么新颖的设计，是复杂系统在规模压力下的自然收敛。

反向验证来自一篇我反复引用的论文。

Stanford 在 ICML 2026 发表的《Multi-Agent Teams Hold Experts Back》。调研过程中这篇论文反复出现，和我们的架构产生了一个精确的量化对照。

论文的核心发现：平级多 agent 团队相对于最强个体有 41.1% 的性能损失。不是团队能力不够——是平级协作机制本身在损失能力。两个机制驱动这个结果：非专家倾向于折中（integrative compromise, IC），专家倾向于迁就团队（expert favoring, EF）。两者指向同一个结果——团队输出被拉向均值。

这不是孤例。2025 年的 Free-MAD 研究发现了 LLM 在多 agent 交互中明显的从众倾向——一旦某个观点占了多数，agent 会放弃自己的独立判断。发表于 Science Advances 的研究进一步揭示了 agent 群体的「羊群效应」——个体观察到其他 agent 的输出后，倾向于跟从而非纠正。这一系列研究指向同一个方向：多 agent 协作的最大敌人不是能力不足，是协调过程中的信息污染。

我把自己的三层架构放在论文的框架里做了一个测算。预期的性能损失在 1.5% 到 3% 之间。远低于论文报告的 6.3% 到 41.1%。

原因有三点。第一，队员之间不讨论——没有讨论环节就不会触发折中和迁就。第二，决策权在队长手里，队长做的是「选择最优方案」而非「融合各方优点」。第三，队长 prompt 内置了反妥协规则——禁止折中话术，强制选边。这三层设计从架构层面消解了论文所指的核心问题。

这篇论文最让我在意的不是 41.1% 这个数字本身——它来自一个受控实验，真实世界的偏差可能更大也可能更小。真正让我在意的是它揭示了平级协作的数学极限：即使 agent 能力再强，只要它们是平级关系，协作机制本身就在消耗能力。这不是哪个框架做得不够好，这是拓扑结构的上限。

当然不是完全免疫。探索小队的 3 轮碰撞模式在需要创意收敛时，碰撞可能退化为温和的共识。估算在创意任务上约 8% 到 15% 的损失。这是一个已知的成本，不是缺点，是一个需要管理的边界。

但到这里位置感仍然不完整——知道「站在哪」和知道「缺什么」是两回事。正面的验证只能说明没选错，不能说明没漏掉。真正的收获在下一段。

三个之前没注意到的问题

调研最有价值的部分不是验证了层级选对了——是找到了之前没意识到的事。

内层缺一个自驱循环

当前每个 agent 的运行模式是「一次推理一次行动」——收到任务，执行一次工具调用，输出，结束。如果第一次调用的结果不充分，agent 不会自主决定继续查询或验证。它只做一轮。

这在简单场景下不是问题。但在需要多步推理的场景下——调试代码时发现报错信息不足以定位根因、对比多个候选方案时发现信息不完整、验证自己的输出是否可靠时发现缺少关键数据——缺了一个关键的内层循环。探索小队的 3 轮碰撞是队员之间的循环，但队员内部没有对自己的循环。

对比 Anthropic 推荐的「笨循环」架构——模型每次只做一件小事情，然后观察结果，决定下一步做什么——我们的 agent 没有这个自调节能力。它不是「观察-思考-行动」的循环，是「收到-执行-结束」的直线。

改进方案不复杂：给 agent prompt 加一段「最小 ReAct 循环」约定——如果工具产出的结果不足以回答问题，agent 可以自主决定继续查询或验证，最多 N 轮。这只是一个 prompt 级别的修改，不涉及任何架构变动，甚至不需要改动队长层的调度逻辑。修改范围仅限 agent 自身的行为规则，对架构的其他部分完全透明。估算单 agent 任务完成质量可提升 20% 到 40%。

这是第一个发现：我们在层级上做得不错，但在 agent 内部的自驱能力上有缺口。补上它不需要大改，只需要给每条 prompt 加一段约定。

跨小队缺一条横向通道

当前是纯树形结构。dev 写了一个模块需要 test 审查——dev 汇报给 Commander，Commander 再分派给 test。即使 dev 队长和 test 队长都知道对方的存在，他们之间没有任何直接的沟通路径。所有协作必须经过 Commander。

这不是一个理论问题——在实际运行中已经感觉到了。dev-1 完成了一个函数模块的代码后，dev 队长验收通过，然后等 Commander 分派给 test 队长——这中间的空档期有时长达两分钟。两分钟可能听起来不长，但在一个多 agent 并行工作的系统里，每一分钟的闲置都是能力浪费。

这在十人以下时不是问题。随着小队扩张到三十人，Commander 的路由压力开始显现。每一条 dev 到 test 的协作都在 Commander 这里停一下——不是处理不了，是不应该在这里停。每停一次，延迟 30 到 60 秒，更关键的是打断了两个队长之间的直接协作节奏。

一步到位做完整的事件系统太冒险——pub-sub 的调试地狱不比层级瓶颈好。轻量方案是只加一个「产出通知」约定：dev 完成工作后声明「产出就绪」，Commander 自动把产出路径嵌入 test 的 brief 里。不改变 routing 语义，只减少一次人工通报。如果这个约定跑通了，后续可以自然演进出轻量的事件机制——不需要一开始就设计完整的 pub-sub 系统。

pi 小队的三个最强队员没有协作

pi 小队（突击小队）有三名队员，配备项目中能力最强的模型。但当前三人只是被动任务槽——Commander 分派任务后随机选一个执行。三个最强的模型之间没有配合，这本身就是一种浪费。

在探索小队已经验证过的 3 轮碰撞模式可以直接迁移过来：pi-1、pi-2、pi-3 对架构级或敏感级任务独立出方案，再由 pi 队长收敛。不是简单投票——是盲跑（各不相干地独立出方案）、互见（看到彼此方案后深化）、收敛（队长选优）的三轮流程。这和层级架构的原则一致——平级碰撞是手段，层级收敛是保障。

实现难度很低——只需要修改 pi 队长和 pi 队员的 prompt，把当前「分派即执行」改为「分派即盲跑，队长再收敛」。预期关键代码质量可提升 15% 到 25%。

三个缺口有一个共同特征：它们都不是架构级别的问题。不需要引入新的框架，不需要重写任何模块，不需要增加新 agent——全都落在 prompt 层面和流程约定层面。这让我松了口气——说明层级架构本身没有硬伤，只是细节上还有打磨空间。

坐标的意义不是优越感

六种模式、六框架速览、一篇 ICML 2026 论文的交叉验证——这趟调研做完，最大的收获不是「我们选对了层级」。选对层级本身不值得特别自豪。偏好树形决策链还是偏好平级碰撞，本质上是两种不同的设计哲学，各有适用场景。41.1% 和 1.5% 的差距，只是在告诉我们「走这条路，所以不会踩那个坑」——不是「这条路比那条路高级」。

真正的收获是三个缺口。内层缺 ReAct——补一条 prompt 约定。横向缺通道——补一条通知规则。pi 缺辩论——改两段 prompt 的分派逻辑。三件事都指向同一个方向：我们的编排模式在「灵活」这件事上还有空间。且这些空间不需要大改架构，不需要引入新的框架或引擎，只需要在现有 prompt 和流程上做精准的补位。

回头看，这个结果其实不意外。架构设计永远是在多个约束之间找平衡点——选层级就是在灵活性和可控性之间选了后者。但选了不等于放弃前者，只是把前者放在后续迭代里补。三个缺口就是三个具体的补位方向，每一个在调研之前都没有意识到。

知道自己的位置，知道自己缺什么，比证明自己做对了更重要。

参考

1. Yao et al. "ReAct: Synergizing Reasoning and Acting in Language Models." ICLR 2023. arXiv:2210.03629
2. Shinn et al. "Reflexion: Language Agents with Verbal Reinforcement Learning." NeurIPS 2023. arXiv:2303.11366
3. Du et al. "Improving Factuality and Reasoning in Language Models through Multiagent Debate." arXiv:2305.14325, 2023. arXiv:2305.14325
4. Qian et al. "ChatDev: Communicative Agents for Software Development." ACL 2024. arXiv:2307.07924
5. Hong et al. "MetaGPT: Meta Programming for Multi-Agent Collaborative Framework." ICLR 2024. arXiv:2308.00352
6. Stanford. "Multi-Agent Teams Hold Experts Back." ICML 2026. arXiv:2602.01011
7. Free-MAD. "Free Multi-Agent Debate." 2025. arXiv:2509.11035
8. "Emergent Social Conventions and Collective Bias in LLM Populations." Science Advances 11 (20), eadu9368, 2025. arXiv:2410.08948
9. Anthropic. "Building Effective Agents." 2024. https://www.anthropic.com/engineering/building-effective-agents
10. LangGraph Documentation. https://langchain-ai.github.io/langgraph/
11. AutoGen Documentation. https://microsoft.github.io/autogen/
12. CrewAI Documentation. https://docs.crewai.com/