夜雨聆风
OpenClaw 子代理编排模式:从单兵作战到军团协作的架构实践
前言
很多刚开始用 OpenClaw 的朋友，都把它当成一个”单线程助手”——你说一句，它回一句，最多调用几个工具。但 OpenClaw 真正强大的能力在于子代理系统：你可以让一个智能体孵化出多个子智能体，并行执行任务、互相协作、甚至自我修复。
我在这几个月里，从踩坑到摸索出一套可复用的编排模式，今天分享出来。
一、为什么要用子代理？（先说说单兵作战的局限）
单智能体模式有三个硬伤：
串行瓶颈：一个任务里如果有三个独立步骤，必须一个一个来。比如”查天气 → 写日报 → 发邮件”，每步都要等前一步完成，浪费了大量等待时间。
上下文污染：任务 A 留下的上下文可能干扰任务 B。我遇到过智能体查完某个技术文档后，在回复另一个完全不相关的问题时，莫名其妙引用了刚看的内容。
恢复成本高：如果一个长任务在中段失败，整个上下文都可能丢失，只能从头再来。
子代理的解决思路很简单：拆分、隔离、并行、汇总。
二、四种核心编排模式
经过反复实践，我归纳出四种最常用的模式：
模式一：扇出-汇聚（Fan-out / Gather）
适用场景：需要从多个来源获取信息，然后汇总。
流程：
-
主智能体分析任务，拆成若干独立子任务 -
每个子任务派发一个子代理，参数互不依赖 -
子代理并行执行，各自返回结果 -
主智能体收集所有结果，做汇总
实战案例：每天早上我有个定时任务，需要检查邮箱、日历、天气、社区通知。以前是串行做，要一分多钟。改成扇出模式后，四个子代理同时跑，总耗时从 70 秒降到 25 秒。
关键要点：
-
子任务必须是真正独立的，互相没有数据依赖 -
给每个子代理设明确的超时时间，避免一个拖死全局 -
主智能体要能处理”部分失败”——某个子代理超时了，其他结果照常汇总
模式二：流水线（Pipeline）
适用场景：任务有明确的先后依赖关系，每个步骤的输出是下一步的输入。
流程：
-
主智能体定义处理链，明确每个阶段的输入输出格式 -
子代理一执行阶段 A，结果存到临时文件 -
子代理二读取阶段 A 的输出，执行阶段 B -
依此类推，最后主智能体拿到最终结果
实战案例：图片处理工作流。子代理一从网页截图，子代理二对截图做文字识别，子代理三根据识别结果生成摘要。三个子代理严格按顺序执行，但中间结果通过文件传递，不污染上下文。
关键要点：
-
中间结果要用文件或结构化数据传递，不要塞在上下文里 -
每个阶段定义清晰的”输入格式检查”，格式不对就报错而不是硬处理 -
建议用临时文件命名约定，比如 stage1_output.json、stage2_output.md
模式三：监督-审查（Supervisor-Reviewer）
适用场景：对输出质量有较高要求，或者涉及敏感操作。
流程：
-
主智能体（监督者）派发任务 -
执行智能体生成初步结果 -
审查智能体（另一个独立子代理）检查结果 -
如果审查不通过，给出修改意见，执行智能体重新生成 -
最多重试 N 次，超过上限则上报主智能体人工介入
关键要点：
-
审查者和执行者应该有不同的视角（比如审查者可以偏严格，执行者偏创造） -
设定最大重试次数，避免死循环 -
审查标准要写进子代理的指令里，而不是靠它的”常识”
模式四：看门狗（Watchdog）
适用场景：需要保证关键任务的可靠性，或者监控另一个智能体的运行状态。
流程：
-
主智能体启动任务子代理 -
同时启动一个看门狗子代理，负责监控 -
看门狗定期检查任务进度（通过日志文件或状态文件） -
如果任务超时或无响应，看门狗尝试重启或上报 -
如果完成任务，看门狗自行结束
实战案例：我的长时间数据采集脚本。有时候网络不稳定，采集会在中途挂起。一个看门狗子代理每 30 秒检查一次采集进度文件，如果连续 3 次进度没变化，就重启采集子代理，并记录重启原因到日志。
关键要点：
-
看门狗本身要轻量，不能消耗太多上下文 -
看门狗和任务子代理之间的”心跳”机制要设计好 -
看门狗也需要超时保护——万一它自己卡住了怎么办？（可以双层看门狗，但实战中单层就够了）
三、组合模式：实战中的真实架构
实际项目中很少只用一种模式，更多是组合使用。
以我的”早间信息汇总”定时任务为例：
主智能体（协调者）
├── 看门狗子代理（监控全局进度，60秒超时）
├── 扇出层（并行，5秒超时）
│ ├── 子代理 A：查邮箱
│ ├── 子代理 B：查日历
│ ├── 子代理 C：查天气
│ └── 子代理 D：查社区通知
├── 汇聚层
│ └── 子代理 E：合并四路结果 → 生成摘要
└── 审查层
└── 子代理 F：检查摘要质量 → 通过则输出，不通过则重做复制
这个架构的好处：
- 扇出
保证信息收集够快 - 汇聚
保证结果一致 - 审查
保证输出质量 - 看门狗
保证不会永久卡住 - 每个子代理隔离
一个失败不影响其他
四、子代理管理实战经验
这几个月踩了不少坑，挑几个印象深刻的分享：
坑一：子代理爆炸（Fork 炸弹）
第一次写复杂编排时，没控制子代理数量。结果一个子代理在任务里又 fork 了两个子代理，这两个又各自 fork … 上下文预算直接被吃光，整个会话不可恢复。
解法：在启动子代理前做预算检查。如果当前已用上下文超过总预算的 60%，就不再产生新的子代理，改用串行方式。
坑二：超时策略过于宽松
早期把所有子代理的超时都设成 30 秒。结果网络波动时，一个查天气的子代理卡了 28 秒，导致整个早间任务从 25 秒暴增到 40 秒。
解法：不同子代理设不同的超时。简单的查天气 5 秒就够了，复杂的生成摘要给 15 秒，审查给 10 秒。越简单的任务，超时越短。
坑三：结果传递不规范
一开始子代理之间通过上下文传递结果，结果主智能体经常搞混哪个结果是哪个子代理的。
解法：使用结构化文件传递数据。每个子代理输出到 tmp/task_xxx/agent_a_result.json，文件名包含子代理标识。主智能体通过读取文件来获取结果，上下文只保留索引。
坑四：子代理上下文隔离
子代理虽然名字叫”子”，但它是有自己的上下文的。不过我发现，如果主智能体在派发指令时塞了太多历史信息，子代理的”隔离”效果就会打折扣。
解法：给子代理的指令要最小化——只告诉它”你是谁、你的任务是什么、输入在哪里、输出写到哪里”，不要带主智能体的聊天历史。
五、性能与资源优化
对于 M4 芯片 16G 内存这样的小机器，子代理编排需要格外注意资源管理：
限制并发数：同时运行的子代理不要超过 3 个。M4 的 CPU 核心虽然多，但模型推理是显存和内存双瓶颈，并行太多反而每个都慢。
善用轻量模型：简单的任务（格式检查、数据提取）可以用小模型，复杂的任务（撰写、审查）再用全量模型。按任务分配模型，而不是一刀切。
清理临时文件：每个子代理执行完后，主智能体应该主动清理它产生的临时文件。我养成习惯在每个编排任务末尾加一个”清理阶段”。
日志记录：每个子代理的启动、完成、失败都记录到日志。这不是为了看，而是为了排查问题时能回溯。记录格式要标准化，方便检索。
六、从编程思维到编排思维
最后想说一点方法论上的体会。
写子代理编排和写代码很像，但有本质区别：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
刚开始会觉得很别扭——”我怎么知道智能体会怎么做？” 但习惯之后会发现，编排思维的核心是信任加约束：信任子代理能自己解决问题，同时用约束确保它的行为不出界。
就像带团队一样：交代清楚目标和边界，然后放手让团队成员自己想办法。不是每件事都手把手教。
结语
子代理编排是我在 OpenClaw 上投入最多精力的方向。从最初随便 fork 导致系统崩溃，到现在能稳定跑多模式组合任务，中间迭代了很多版本。
这篇文章分享的是目前最稳定的实践，但不是终极答案。编排模式会随着 OpenClaw 本身的发展不断进化。欢迎大家分享自己的编排经验，一起把这个话题聊透。
有什么问题或想法欢迎留言交流 👑