分享一下我个人认为比较实用的 Multi-Agent 编排实践。
目录
1. Coding 场景难在耦合
普通 Agent 工作流的输入和输出相对固定，一个节点处理完，再把结果交给下一个节点就行。Coding 不一样：代码库一直在变化，文件、接口、依赖和 Git 状态都可能被多个 Agent 同时修改。
只使用一个 Agent，任务时间一长，早期需求和中间决策容易被后续日志与代码淹没；一次启动七八个 Agent，如果没有提前划清边界，又很容易出现互相覆盖、反复返工和合并冲突。
多 Agent 同时写代码时，最容易遇到两种耦合。
第一种是代码耦合。两个 Agent 同时修改同一个文件、公共类型或者依赖配置，一个 Agent 的实现很可能覆盖另一个 Agent 的结果。
第二种是进度耦合。下游任务必须等上游功能完成才能开发，上游一旦延期，后面的 Agent 即使已经启动，也只能停下来等待。
这两个问题都不能靠“再增加一个管理 Agent”解决。管理层越多，任务会经过越多次转述。发生问题后，也很难判断错误到底来自最初的拆分、接口定义，还是某一层 Manager 的理解发生了偏差。
所以在 Coding 场景中，多 Agent 编排的关键仍然是两个字：解耦。
2. 三种角色已经够用
我目前最常用的是三个角色：Manager、Executor 和 Reviewer。
它们更像三种职责，而不是不断向下分叉的组织层级。
Manager
Manager 负责拆分任务、定义节点之间的协议、划分文件边界，并决定验收和合并顺序。
它不需要亲自完成所有代码，也不应该在每个模块下面继续创建新的 Manager。
Executor
Executor 一次只负责一个节点。
它应该拥有明确的输入、输出、写入范围和完成标准。超出节点边界的问题，交回 Manager 处理，而不是顺手修改其他模块。
Reviewer
Reviewer 独立检查 Executor 的实现，包括代码逻辑、测试结果以及接口是否符合约定。
Reviewer 可以提出问题，也可以要求 Executor 修改，但不要让两者同时改动同一批文件。否则执行者与审查者之间也会产生新的竞争。
前端、后端和数据库可以分别作为三个节点，但没有必要再为它们分别创建一套 Manager。一个全局 Manager，加上各节点的 Executor 和 Reviewer，通常已经足够。
3. 先拆节点，再启动 Agent
以一条自动化测试流程为例，可以拆成四个节点：
1 | 监控版本发布 |
拆出四个节点还不算真正解耦。更重要的是定义它们之间如何交换信息。
例如，节点之间只传递约定好的 JSON：
1 | 版本信息.json |
每个节点只依赖协议，不依赖其他节点的内部实现。
这样，即使“生成执行计划”还没有开发完成，“执行测试”节点也可以先构造一份符合协议的模拟数据，独立完成开发和测试。
一个节点是否真正解耦，可以用三个问题判断：
- 没有上游成品时，能不能通过模拟数据运行？
- 不启动其他节点时，能不能独立测试？
- 替换内部实现后，能不能继续使用原来的协议？
如果这三个问题都能回答“可以”，不同节点才具备真正并行开发的条件。
4. 同一目录还是 Worktree
完成节点解耦后，可以选择两种执行方式。
| 方式 | 适用情况 | 代价 |
|---|---|---|
| 同一目录 | 文件边界清楚、任务规模较小 | 容易误改共享文件 |
| Worktree | 写入较多、节点较大、需要更强隔离 | 需要处理分支与合并 |
4.1 同一目录
如果每个节点都有独立目录，而且不会同时修改公共配置，可以直接在同一个工作区启动多个 Agent。
这种方式最直接，没有额外的分支和合并成本。Manager 只需要提前规定每个 Agent 能修改哪些文件。
一旦涉及依赖锁文件、公共类型或全局配置，就要谨慎使用。逻辑上已经解耦，不代表文件层面一定没有冲突。
4.2 Worktree
更稳健的方式，是为每个节点创建独立的 Git Worktree 和分支。
每个 Agent 在自己的目录中开发、测试和提交。节点完成后，再依次合入主干，并执行整体测试。
Worktree 提供的是文件和 Git 状态上的隔离，适合写入范围较大或者冲突风险较高的任务。
但它不能替代节点解耦。如果接口没有提前定义清楚，问题只会从“开发时互相覆盖”推迟到“合并时集中爆发”。
所以顺序仍然是：先完成协议解耦，再决定使用同一目录还是 Worktree。
5. 并行不等于全部同时开始
假设一条流程有四个节点，并不意味着必须立即启动八个 Agent，让四个 Executor 和四个 Reviewer 同时工作。
更合理的方式，是让不同节点并行推进，而每个节点内部保持基本顺序：
1 | Executor 完成节点 |
不同节点的进度可以错开。某个节点进入 Review 时，另一个节点可能还在开发。
这样既保留了并行带来的速度，也避免为了追求 Agent 数量，把同一个节点变成多人同时写入的混乱现场。
实际执行时，我会尽量守住几个边界：
- 一个 Agent 只拥有一个明确的写入范围；
- 一个节点对应一组小而独立的提交；
- 协议发生变化时，必须交回 Manager 统一处理；
- 每个节点独立测试，合并后再执行整体测试；
- Reviewer 默认先给出问题，不直接接管 Executor 的文件。
6. 收个尾
Multi-Agent 编排不是照搬公司的组织架构。层级更多、Agent 更多，并不一定意味着效率更高。
对 Coding 场景来说，目前较为实用的方式仍然是保持结构扁平：
Manager 管边界、协议和合并；Executor 管节点实现；Reviewer 管独立验证。
在此基础上，把系统拆成能够独立运行、独立模拟、独立测试的节点。边界足够清楚时，可以在同一目录并行；冲突风险较高时，就使用 Worktree 隔离。
真正有效的并行，不是让更多 Agent 同时动手，而是让它们即使同时工作，也不需要互相等待。