多智能体编排:谁来决定并行度
一个 Agent 能读代码、能调工具、能规划,为什么还需要多个 Agent?
答案不是”人多力量大”。多 Agent 的真正价值是隔离
、自己的工具集、自己的信任边界,而主 Agent 的上下文保持干净。一个专职的 reviewer 子 Agent 只给只读工具,一个 implementer 子 Agent 的写权限被限制在某个 worktree——整个系统比一个”什么都懂”的单 Agent 更省、也推理得更清楚。但多 Agent 也是 Agent 系统里最容易做砸的部分。做好了是最廉价的专业化手段,做砸了就是一句含糊的”你去看看这个”配上无限的工具权限和没有输出约定,然后你调试一整周。
这一篇讲两件事
委派本身的契约(agentic 课程视角),二是六个开源项目在”谁决定并行度”上的分野(agent开发的实证横评)。一、什么时候该委派,什么时候不该
先立一个判断标准。满足下面任意一条,才考虑委派:
- 子任务需要自己的上下文——不同的系统提示、不同的记忆、不同的关注焦点
- 子任务需要隔离副作用——一个 worktree、一个沙箱、一道单独的信任边界
- 子任务想用不同的模型或工具集——便宜模型做窄查询,贵模型做深推理
- 子任务能和其他子任务安全并行——三个 review 并行跑,然后汇总
反过来,下面这些情况不要委派:
- 一个确定性工具就能回答的问题
- 一个 Skill 就能教会主 Agent 做的事
- 子 Agent 反正需要主 Agent 的完整上下文(那你就付了两遍上下文成本)
- 子任务小到不值得再起一个模型循环(委派有固定开销、工具列表、打包)
大多数团队跳过的最廉价改进
——这是不是在替代一个本来更便宜的工具调用?
二、委派包”包”,不是”聊天记录”
主 Agent 发给子 Agent 的应该是一个结构化的委派包(delegation packet),而不是把自己的对话历史一股脑倒过去:
type DelegationPacket = {
role: string; // "researcher" | "reviewer" | "implementer"
objective: string; // 子任务,用散文描述
context: string; // 过滤后的切片,不是完整父级 transcript
allowedTools: string[]; // 比父级更紧
constraints: string[]; // "不要写 /tmp 之外" "最多读 10 个文件"
maxSteps: number; // 硬上限
budget?: { tokens?: number; cost?: number };
outputSchema: JsonSchema; // 结果必须长成什么样
remainingDepth: number; // 剩余委派深度
};三条生产经验:
- 默认不要倒完整 transcript。要么摘要,要么只挑子 Agent 真正需要的那几条消息。倒完整历史会增加 token 成本、增加 prompt 注入面、增加子 Agent 跑偏的概率。
- 收紧工具列表。reviewer 只给读工具;implementer 的写权限限定在 worktree;外部 researcher 给网页工具但不给 shell。
- 传递剩余委派深度。每次 spawn 递减,归零就不许再 spawn。
三、结果契约
回来的结果必须能被机械地检查。一段光秃秃的散文就是一个等着出事的契约漏洞。生产系统都会落到类似这样:
type ResearchResult = {
answer: string;
evidence: Array<{ source: string; quote: string }>;
uncertainty: "low" | "medium" | "high";
followups: string[];
toolsUsed: string[]; // 审计用(见可观测性一篇)
cost?: number; // 汇进父级预算
};结构化输出让父级能机械推理
schema、给置信度打分、跨兄弟结果对比、呈现给用户。非结构化输出会逼父级再调一次模型去”解读”子级说了啥——每次委派上的第二笔隐藏成本。四、核心问题
以上是”一对一委派”的契约。当委派扩展成”一群 Agent 协作”,最烧脑的问题浮现了——谁来决定哪些任务能并发跑?
agent开发 系列横评了六个开源项目,发现它们分成三种路线:
| 路线 | 谁决定 | 代表项目 | 并行度可预测性 |
|---|---|---|---|
| 代码决定 | 编排逻辑写死在图结构里,LLM 只是执行节点 | DeerFlow、Eino | 最高 |
| LLM 决定 | 框架提供工具,LLM 自己判断哪些能并发 | Goose | 最低 |
| 规则决定 | 人在 Skill 里写下严苛条件,全满足才能并行 | Superpowers | 高 |
这三种不是好坏之分,而是面向不同的可预测性需求。关键问题是
,你更信任代码,还是更信任 LLM?路线一(DeerFlow / Eino)
DeerFlow 用 LangGraph 的 StateGraph 描述协作:Coordinator、Supervisor、Researcher、Coder 是图里的节点,条件边决定路由,全部用 Python 写死。当 Supervisor 决定需要并行搜索,它输出特定格式的 JSON,图结构根据这个 JSON 触发多条边,同时激活多个 Researcher 并发执行。
注意:这不是 LLM 运行时做的决策。LLM 只是输出了符合预期格式的数据,图结构负责路由。
Eino 走得更彻底
Agent Tool 抽象是整个系列里最干净的——父 Agent 调用工具和调用子 Agent 完全等价。再配合Agent With Deterministic Transfer To,防止子 Agent 横向转移,只能转回 Supervisor。
代码决定的代价是灵活性
。收益是可预测——你永远知道什么时候会有几个 Agent 在跑。路线二 决定(Goose)
Goose 提供一个 spawn_agent 工具,让 LLM 在运行时自己判断”这几件事可以并发,我起几个子 Agent”。理论上递归深度无限(树形),给了 LLM 最大能力。
但这是设计哲学,不是实际使用场景——真跑起来受限于上下文和成本,树也深不到哪去。并行度可预测性最低
LLM 会起几个 Agent。路线三(Superpowers)
Superpowers 最有意思。它不写图,也不完全信任 LLM,而是在 Skill 里写下四条并行前置条件,LLM 只有在所有条件都满足时才能并行,否则老老实实串行。
这四条来自真实生产教训:宁可串行慢一点,也不要两个 Agent 打架。两个 Agent 同时改相邻的文件、抢同一个资源,产生的混乱比串行慢那点时间贵得多。
五、多 Agent 系统的三个层次
不管走哪条路线,多 Agent 系统都要处理三个层次:
| 层次 | 作用 | 典型分歧 |
|---|---|---|
| 调度层 | 决定谁来发号施令 | 中心化 Supervisor vs 对等协作 |
| 通信层 | 决定 Agent 之间怎么传数据 | 共享状态 vs 消息传递 vs 完全隔离 |
| 隔离层 | 决定一个 Agent 挂了会不会拖累别人 | 进程隔离 / 容器隔离 / 无隔离 |
以状态共享为例,六个项目就有六种做法
用 LangGraph State,Eino 用 Session + Checkpoint,Goose 用对话历史,Superpowers 不共享,Oh My Open Agent 用一块叫 “Wisdom Notepad” 的经验积累区,Nano Graph 直接 Group 物理隔离。六、拓扑 vs 专家网
委派的组织方式主要有两种拓扑:
- Supervisor(监督者) Agent 派发任务给多个 worker,worker 只跟 Supervisor 通信,不横向通信。信息不衰减、易审计。这是最常见的生产选择。
- 专家网(specialist mesh) Agent 平等协作,彼此可直接通信。灵活但容易信息衰减、难调试。
Claude Code 的协调器模式(见 [[专题二]])就是典型的 Supervisor
”只编排不执行”,明确禁止”用一个 worker 检查另一个 worker”,就是为了防止信息链式传递导致的衰减。七、递归深度 depth-1
一个能 spawn 自己子 Agent 的子 Agent,是一个等着爆栈的隐患。生产里三种做法:
- depth-1 默认(最常见) Agent 能 spawn 子 Agent,子 Agent 不能再 spawn。最安全、最简单,除非有具体需求逼你,否则就从这个开始。
- 有界深度(OpenClaw 深度 5),耗尽就抛错。
- 拓扑封顶(Paperclip) spawn,由调度器派发,父子关系作为数据追踪,而非栈帧。
小结
多 Agent 的核心不是”多”,而是隔离和契约
,结果契约保证可校验,depth-1 防爆栈。而”谁决定并行度”这个问题,六个项目给了三种答案
(可预测性最高)、LLM 决定(灵活性最高)、规则决定(安全性优先)。选哪种,取决于你的场景里你更信任谁。四个反复出现的规律里,有一条在这里特别应验:协议比实现重要——Eino 的 Agent Tool、DeerFlow 的条件边、Superpowers 的四条件检查,长期价值都锚定在那个”接口/协议”上,而非具体某次实现。
下一篇讲 Agent Harness——把前面所有零件(循环、工具、记忆、权限、编排)装进一个能跑的运行时框架,以及这个框架的设计哲学。
本文主要参考
ch10(multi-agent delegation)、agent开发/5多智能体编排、16 个开源项目对比总览维度 4。真实项目行为以各项目源码为准。