多 Agent 协作:一个人干不动，就派一队

一、一个 Agent 忙不过来的时候

E02 我们让 Agent 独自把一个 CLI 写通了。但真到“上生产”的门口，一个人干活总归有盲区——代码要 review、日志要复核、文档要校对、数据要拉、渠道要发。写代码的 Agent 分身乏术;就算它愿意分，你也不放心让它同一份上下文里既当运动员又当裁判。多 Agent 协作，就是解决这个“分身与分工”问题的正解。

一位在数据团队做工程主管的朋友分享过一段类似经历:他们做一个跨部门的月度报表工作流，本来是一个 Agent 全揽——拉数据、清洗、生成图表、写摘要、发飞书。结果每次跑到第三步“生成图表”就崩:主对话已经吃满了拉数据阶段的 SQL 结果和清洗日志,Agent 的上下文被淹得看不清后面的活。后来他换了思路:主 Agent 只负责“下判断和汇总”,其余每一步都 spawn 一个子 Agent 单独跑，跑完只把结论带回来。整条工作流从 40 分钟压到 12 分钟，主对话记录也从原来一大团日志压缩成一份清爽的执行摘要。这就是典型的“多 Agent 协作解决单 Agent 上下文过载”的场景。

业内主流的多 Agent 编排范式，其实各自代表一种对“什么是多 Agent”的哲学分歧。

微软 AutoGen 把它建模为“对话协作”——Agent 坐一圈开会，GroupChat 广播、发言器选一个接结。

LangGraph 把它建模为“有向图状态机”——nodes、edges、显式 state，可 replay。

CrewAI 把它建模为“角色扮演”——Agent + Task + Crew + Process 四层套娃，像在搭一支虚拟团队。

OpenAI Agents SDK 主打 handoff：一个 Agent 把接力棒抛给下一个，链式传递。

Anthropic Claude Code 则在一个会话内嵌套 subagent，主对话不被污染。

据 GitHub 数据(2026-07 上旬采样)，这些项目 stars 从 20k 到 130k 不等，各自在自己的哲学里长成得都不算小。

AISTOC 团队内部看过这五条路后，做了一个具体的取舍。“对话协作”在日常小任务里“三个 Agent 聊十五回合才出结果”的 token 开销不低；“有向图状态机”对工程团队友好，但对个人开发者写起来像在搭建 DAG，难度不小；“角色扮演”启发很好但抽象层多，新手十分钟搞不完一次。OpenClaw 最后落在“事件推送 + 会话树”这个刻度上，不是因为“少即是多”好听，而是因为多数日常场景需要的都不多：“给已有身份发一条消息”或“派一个干净会话跑一件事”。两把锤子（sessions_send 与 sessions_spawn）不是能力限制，是产品选择。

更本质的差异基于一个工程直觉：多 Agent 的价值不在“多”，在“上下文隔离”。谁把这件事把握得最严，谁就能把主 Agent 的“洗脑”（清上下文）频率压到最低。推送式事件也是这条直觉的延伸：子 Agent 跑完一条消息把结果推回来，主 Agent 在等待期间可以当作已经“下班了”，不必写轮询、不必 hang 在 .run() 里。这套设计更像“操作系统里的进程通信”，而不是“函数库里的同步调用”。

二、两种手段，一张表看清

如果实在纠结，用这条决策树:目标已有身份(如“日程助理”、“研究员”)–就 send;只需要一个零上下文的临时干活工——就 spawn。

还有个隐藏考量是“责任归属”–用 send 派出去的活，回来后写在目标 Agent 自己的历史里，方便后续追责与复用;用 spawn 派出去的活，只在这一次上下文里生效，跑完就干净散场。前者更像“发个内部工单”,后者更像“叫个临时工”。选谁，看你想给这次协作留多长的记忆。

三、案例:派一个 reviewer 审 E02 的 CLI

把 E02 写好的 oc-todo 交给一个“临时干活工”审一遍。在 dashboard 里让主 Agent 派任务:

返回体是这样的:

派完之后，最容易犯的错就是盯着子会话不放——每隔几秒 sessions_list 一次、每隔几秒 subagents list 一次。别这么干。正确姿势是一句:

sessions_yield 是 OpenClaw 的唯一合法等待原语。它主动结束当前 turn,把主导权还给 runtime。当子会话跑完,runtime 会推送一条完成事件回来，作为下一轮消息落到主 Agent 面前——比任何轮询都快，也更省 token。

新手很难第一次就想通 yield 的价值，直觉总觉得“我不看着，怎么知道跑完了”。可以类比一下手机 APP:你退出后台，通知照样能弹出来。yield 就是让主 Agent 主动“退到后台”,把 CPU 让给子 Agent。这套推送模型也让并行成为一件轻的事——同一轮里 spawn 三个子任务、然后 yield 一次,runtime 会依次把三条完成事件都推回来，主 Agent 只用醒一次。

四、真跑一次:1 分 3 秒拿到一份 5 维度报告

AISTOC 内部实测(Windows Server 2022 · Node v24.14.1):从 spawn 派出到完成事件回来，耗时 1 分 3 秒。子会话独立跑，没有被主对话的历史信息污染，也没有被本地 Skill 触发词左右。它抛回来的综合结论摘录如下:

这份结论有两点要强调的是：其一，它是“未被上下文污染”的判断——主会话没告诉它“E02 是入门篇请手下留情”、也没暗示“重点看什么”;其二，它可复现——同一份代码派出去，几次结果基本一致。这是“隔离 + spawn”这条设计路线最大的价值:每次派出去的都是一个干净的评审者。

这一点,Anthropic 在 Claude Code 官方文档里也点得很直接:“Use one when a side task would flood your main conversation with search results, logs, or file contents you won’t reference again.” — 子 Agent 的核心价值不是“并行加速”,而是把可能污染主上下文的杂事关到一间独立房间里去做。搜索日志、拉长文档、跑大量 grep,这些活如果留在主对话里，很快会把上下文窗口挤爆;派出去，只把“结论”带回来，主 Agent 的上下文就能一直干净。这是 OpenClaw 与 Claude Code 都强调的核心 UX,也是很多老手在真正用了三个月之后才悟出来的隐形红利。上下文这份资源，比你以为的更贵。据 Anthropic 官方 Best Practices 明示:一次调试或代码库探索就能吃掉数万 token,context 满了性能会降级，模型开始“忘记”。省着用，就是省钱又保智商。

五、五种编排范式，够你日常八成场景

并行 Fan-out 尤其值得试一次:同一轮里连续 spawn 三次，最后 yield 一次,runtime 会把三条完成事件都推回来。你只等一次，得到三份并行结果——这才是“多 Agent”能真正节省时间的姿势。

流水线也还想补一句。真实工程里最常见的场景不是“三个 reviewer 并行”,而是“调研 → 起草 → 校对”这种三段接力:先派一个 spawn 去搜集资料，回来后主 Agent 汇总提炼，再派一个 spawn 去把提炼稿改成正式文档。每一段都在干净上下文里跑，每一段的输出都能落成一个可复用的中间产物。这就是所谓“编排范式”–你不是简单地“多派几个 Agent”,而是把一件复杂任务切成若干个“可验证的小闭环”,一段接一段。E03 讲 Skill 时提到过的“确定性脚本 > 一大段 prompt”,在这里就是“确定性子任务 > 一次性大任务”。

什么时候不该用多 Agent?三个判断标准:其一，主任务上下文已经很清爽，没有杂事污染的问题;其二，子任务需要的信息严重依赖主对话历史，硬要 context:"fork" 反而拉高复杂度;其三，任务本身足够短，派一个 subagent 的 token 开销比自己做还贵。多 Agent 是把锋利的刀，用错了地方比不用更糟。

六、几个新手最爱踩的坑

最后一条也常被漏掉:子 Agent 默认不继承 message 工具。这意味着它跑完只能把“最后一条 assistant 文本”作为 report 返回给主 Agent,不能自己给外部渠道发消息。这个默认值是保护性的——不然一个失控的子 Agent 就能自作主张在群里刷屏了。如果确实需要子 Agent 有渠道能力，得在 tools.alsoAllow 里显式打开，并给它一个 thread 绑定的目标。安全默认，是好的默认。

七、你现在可以做的三件事

多 Agent 协作最好的学习方式是“少想多派”。理论看多了容易过度设计，先把最小场景跑一遍，你才知道它真正能省什么。下面三件事各占十几分钟，做完你的直觉会对“分身 / 分工 / 上下文隔离”这三个词有更明确的感受。

八、下期预告

E01 到 E04,我们走完了“装、写、教、派”四步。回头看这四步，其实各自对应一个不同的能力位面:装是让 Agent 存在于你的日常，写是让它替你动手，教是让它记住你的工作习惯，派是让它组成小队。真正让效率翻倍的不是任何单一环节，而是这四步一起用——把日常琐事交给 Skill,把偶发的大任务派给 subagent,主 Agent 只保留最需要判断力的那部分。E05 开始进入实战篇——从一句需求，到一个能用的 MVP。会带你把 CLI 升级成 Web,加数据库、加 Auth、加基础 UI。多 Agent 协作会在实战里频繁出现:一个 Agent 写业务、一个 spawn 出来审代码、一个 send 给已有的 QA 会话跑用例，编排范式随场景灵活切换。下期见。

— AISTOC产品团队