importzhh

多智能体编排:谁来决定并行度

Agent; 多智能体; 编排; 并行; Subagent 2386 words 12 min read
This post is not yet available in English. Showing the original.

一个 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;       // 剩余委派深度
};

三条生产经验:

  1. 默认不要倒完整 transcript。要么摘要,要么只挑子 Agent 真正需要的那几条消息。倒完整历史会增加 token 成本、增加 prompt 注入面、增加子 Agent 跑偏的概率。
  2. 收紧工具列表。reviewer 只给读工具;implementer 的写权限限定在 worktree;外部 researcher 给网页工具但不给 shell。
  3. 传递剩余委派深度。每次 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。真实项目行为以各项目源码为准。