多 Agent 分工原则：什么时候单 Agent，什么时候并行，什么时候路由

这页不是在讲“多开几个 Agent 看起来更厉害”，而是在回答一个更实际的问题：

在真实工作里，任务到底该不该拆？如果拆，应该怎么拆，谁负责收口？

对我现在的场景来说，这不只是一个 AI 概念问题，而是会直接影响：

一、先说结论：不要先问“能不能多 Agent”，先问“这件事的结构是什么”

很多人一上来就想：

但真正更重要的问题其实是 3 个：

  1. 这件事是不是强顺序任务？
  2. 子任务之间能不能独立？
  3. 最后谁负责 merge 和对结果负责？

如果这 3 个问题没想清楚，多 Agent 只会把混乱放大。

所以我的总原则是：

先设计边界，再增加 Agent 数量。

二、什么时候应该坚持单 Agent

单 Agent 不是能力弱，而是很多时候它更稳。

适合单 Agent 的场景

1. 需求还模糊

例如：

这时如果直接 fan-out，多个 Agent 只会带着不同猜测各跑各的，最后主 Agent 还要花更多时间收口。

2. 步骤强依赖

例如：

这种就是典型 pipeline，而不是并行任务。硬拆只会让后面的 Agent 在错误假设上浪费时间。

3. 写入边界分不清

只要多个 Agent 可能改同一个文件、同一段逻辑、同一个状态机，就先别并行写。

如果 ownership 写不清楚，多 Agent 节省的时间，最后几乎都会在冲突解决里还回去。

我自己的判断

在编码任务里，单 Agent 应该是默认形态，多 Agent 是有条件启用的例外形态。

三、什么时候适合并行 subagents

并行不是为了显得高级，而是为了两件事：

  1. 隔离上下文噪声
  2. 并行验证独立子问题

适合并行的场景

1. 多条调查线可以独立推进

例如一个线上问题可能涉及：

如果这些线索可以先独立探索，再统一汇总，那就适合开只读 explorer。

2. PR review 的维度天然独立

例如：

这些维度通常可以并行看，因为它们不是先后依赖关系，而是并列检查维度。

3. 主上下文已经快被噪声淹没

例如：

这时候 subagent 的价值，不只是“多一个脑子”，而是把噪声隔离出去，避免主上下文被污染。

并行时最重要的原则

原则 1：优先并行“读”，谨慎并行“写”

最稳的做法通常是：

这样能最大化利用并行，又避免多处写入冲突。

原则 2：必须有 reducer

无论是主 Agent 还是 lead Agent，必须明确有人负责：

没有 reducer 的多 Agent，只是多份意见，不是一个系统。

四、什么时候适合 Gateway routing，而不是 task fan-out

这是我看完材料后一个特别强的判断：

很多“多 Agent”问题，根本不是任务拆分问题，而是入口隔离问题。

典型场景

同一个系统可能同时接收：

这些消息虽然都进到“AI 系统”，但它们并不应该进入同一个 Agent。

因为它们天然有不同的：

这时更应该做的是 routing

例如：

这里的重点不是“几个 Agent 一起协作”，而是：

不同入口，先进入不同边界。

这其实更接近 OpenClaw 的核心价值。

我的判断

对 OpenClaw 来说，最重要的多 Agent 价值很可能不是 subagent 并行，而是：

也就是说，它更像 Agent 网关 / Agent 操作系统，而不只是一个并行器。

五、什么时候需要 durable board / 队列，而不是一次性 subagent

不是所有任务都该在一个 turn 内完成。

适合 durable board 的场景

1. 任务要跨天

例如：

2. 任务需要重试和 handoff

例如：

3. 任务需要审计轨迹

例如：

这类任务的关键不是并行，而是状态管理

这时就不该再把所有事情都塞进一次性 subagent。更合理的是：

一个简单判断法

六、什么时候适合 team mesh，而不是星型结构

并不是所有问题都需要 Agent 之间互相通信。

大多数场景：星型就够了

也就是：

适合：

只有在“多假设互相挑战”时，team mesh 才有价值

例如生产登录故障，可能同时涉及：

这种时候，一个 Agent 顺着一条线查，很容易过早锚定。 多个 teammate 分头验证、互相反证，覆盖面才会更好。

但代价也很明确

所以我的原则是：

team mesh 只用于多假设问题，不要拿它处理普通并行任务。

七、多 Agent 最常见的 7 个反模式

1. 把“复杂”误当成“适合并行”

复杂不等于可拆。强顺序任务依然应该串行推进。

2. 不写 delegation contract

只说一句“你去修一下”“你帮我 review 一下”，等于把不完整需求丢给新同事。

3. 多个 Agent 写同一片区域

没有 ownership 的并行写入，几乎一定会翻车。

4. 没有 reducer

没人负责最终整合时，多 Agent 只会输出多份不一致意见。

5. 把长任务当 RPC，把短任务做成队列

长任务需要 durable state，短任务需要轻量 fork/join，不能反着用。

6. 权限过宽

review agent 不该能乱写文件，低风险入口不该拿到危险 shell。

7. 没有观测和审计

不知道谁调了谁、传了什么 context、用了什么工具、卡在哪一步，多 Agent 就不可维护。

八、一个我会长期沿用的选择顺序

以后我做多 Agent 设计时，会按下面这个顺序问：

第一步：单 Agent 能不能解决

如果能，先别拆。

第二步：主上下文会不会被噪声污染

如果会，优先考虑只读 explorer。

第三步：子任务能不能独立

不能独立就别并行。

第四步：结果必须本轮返回吗

第五步：Agent 之间需要互相挑战吗

第六步：是否会并行写文件

只要会写，就先写 ownership。

第七步：这是任务拆分问题，还是入口隔离问题

如果本质是多渠道、多身份、多权限，那先做 routing，不要急着做 fan-out。

第八步：失败后怎么恢复

能不能 retry、block、handoff、审计，这决定系统是不是能长期用。

九、一个真正有用的委派模板

如果只想留下一个以后能反复用的模板，我会保留这个：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

角色：
  你是只读 explorer / scoped implementer / reviewer。

目标：
  你要回答什么，完成什么，边界是什么。

上下文：
  项目路径、相关文件、错误现场、用户目标、已有判断。

允许动作：
  能读哪些文件，能不能跑命令，能不能写文件，能不能联网。

Ownership：
  如果能写，只能写哪些目录或文件。

禁止动作：
  不要改哪些文件，不要继续 spawn，不要问用户，不要做额外重构。

输出格式：
  返回 findings / patch summary / test result / confidence / open questions。

停止条件：
  什么情况下算完成，什么情况下应该停止并报告阻塞。

这个模板看起来普通，但它其实把最关键的 5 件事说清楚了：

没有这些，再炫的多 Agent 架构最后也容易变成随机并行。

十、最后的工作化结论

如果把这套原则落回我自己的系统，我会这样理解：

对 OpenClaw

优先把它当：

而不是先把它当“多 Agent 同时思考平台”。

对 Codex / Claude Code

优先把 subagent 当：

而不是“任务一复杂就自动 fan-out”的默认解。

对我的工作流

最重要的不是“多 Agent 数量”，而是这 4 个东西是否清楚：

十一、落到具体工具：OpenClaw、Codex、Claude Code 应该怎么用

下面这部分，我更关心“怎么落地”，而不是“概念上怎么分类”。

1. 在 OpenClaw 里怎么用

OpenClaw 最该优先发挥的，不是“并行思考”，而是下面 4 件事：

适合 OpenClaw 的场景

在 OpenClaw 里最容易犯的错

我会怎么用

2. 在 Codex 里怎么用

Codex 的强项是：

适合 Codex 的场景

在 Codex 里最稳的打法

在 Codex 里最容易犯的错

我会怎么用

3. 在 Claude Code 里怎么用

Claude Code 的关键不是“会不会自动叫 subagent”，而是：

适合 Claude Code 的场景

Claude Code 普通 subagent 最适合做什么

什么时候才值得用 Agent Teams

在 Claude Code 里最容易犯的错

我会怎么用

十二、什么时候绝对不要乱并行

这部分我想单独强调，因为它最容易被忽略。

1. 需求还没澄清时

需求模糊时并行，只会把模糊同步放大。

2. 关键设计还没定时

例如数据模型、状态机、接口契约还没定，后面所有 worker 都会建立在不稳定前提上。

3. 多个 worker 会写同一片区域时

这是并行写最容易翻车的地方。没有 ownership，就不要并行写。

4. 用户真正需要的是一个清晰判断，而不是 4 份原材料时

这种时候更需要一个强 reducer，而不是更多 worker。

5. 你只是因为“任务看起来大”而焦虑时

很多并行冲动，本质不是任务结构需要，而是人类看到复杂任务后的心理补偿。

一句话总结

多 Agent 不是越多越好，而是边界越清楚越好。

先设计路由、上下文、权限、ownership 和 merge，再决定要不要增加 Agent 数量。

这是一个不炫，但非常工程的顺序。 也是更适合长期运行的顺序。