很多人第一次听到“多 agent 协作”，脑子里会自动出现一种很玄乎的画面：几个 AI 在后台自己讨论、自己分工、自己交付，好像一个数字公司一样。
OpenClaw 这套东西，确实支持往这个方向走，但我想先泼一盆冷水：多 agent 不是越多越高级，也不是一上来就该开。
单 agent 足够的时候，别为了炫技硬拆。因为一旦进入多 agent，意味着更多会话、更多上下文、更多 token 开销，还有更多排错成本。
但反过来说，如果你的任务本来就天然适合分工，比如：
- 一个负责搜资料
- 一个负责写初稿
- 一个负责校对
那 OpenClaw 的多 agent 机制就非常有价值。
官方文档里，至少已经明确了几层能力：Sub-agents、按 agent 划分的工作区、以及更进一步的 agent-to-agent / 多 agent 协作路线**。这不是概念 PPT，而是实打实能用来拆任务的。**
一、先搞懂最核心的结构
你可以先把 OpenClaw 的多 agent 理解成三层：
1）主 agent
主 agent 就是对外接消息的那个“总控”。
它负责：
- 接收用户请求
- 判断这个任务要不要拆
- 决定交给谁做
- 最后汇总结果返回给你
2）子 agent（Sub-agent）
子 agent 是主 agent 临时拉起来的后台执行者。官方文档明确说，它们会在独立 session 里运行，任务结束后再把结果 announce 回来。
这点非常关键：独立 session = 相对独立的上下文。这样做的好处是，一个子任务不会把主会话弄得越来越臃肿。
3）更深一层的嵌套
OpenClaw 默认子 agent 不能再继续无限生孩子，默认 maxSpawnDepth: 1。如果你主动把配置调到 2，就能支持“主 agent → 协调型子 agent → 工作者子 agent”这种模式。
官方文档里把这类模式叫作 orchestrator pattern，意思很直白：上面的人负责调度，下面的人负责干活。
二、为什么多 agent 会比单 agent 更好用
原因 1：任务边界更清楚
让一个 AI 一口气做“搜集资料 + 写作 + 审稿”，它也能做，但经常会互相污染。
比如它刚刚写了一段没查实的内容，下一秒又自己给自己背书，看起来像审核了，其实没审核。
拆成多个 agent 后，边界会清晰很多：
- 研究员：只负责找资料和整理事实
- 写手：只负责按资料写
- 审核员：只负责挑错和找漏洞
原因 2：上下文更轻
官方文档专门提醒过：每个 sub-agent 都有自己的上下文和 token 消耗。表面看像更费，但换个角度讲，它也避免了一个超长上下文在单会话里越滚越大。
如果拆得合理，反而更干净。
原因 3：可以用不同模型干不同事
这个也是 OpenClaw 很适合玩的地方。主 agent 用更强模型负责判断和收尾，子 agent 用便宜模型去跑研究、整理、初稿，这样质量和成本能平衡得更好。
三、一个最容易理解的实例
假设你要写一篇技术文章，流程可以这样拆：
主 agent 接到任务
用户说：
帮我写一篇关于 OpenClaw skills 的教程，面向新手。
主 agent 不直接写，而是先分工：
- 子 agent A：去查官方文档里 skills 的定义、加载规则、配置覆盖逻辑
- 子 agent B：整理一个适合新手理解的文章结构
- 子 agent C：对 A 和 B 的结果做风险检查，看看有没有编造功能
最后，主 agent 再把三份结果合并，生成最终文章。
这套流程的好处很明显：写的人不直接决定事实，审的人也不直接重写结构。
这比单 agent 一把梭更靠谱。
四、OpenClaw 里和多 agent 有关的真实能力
根据官方 Sub-agents 文档，现在能确认的点包括：
- 子 agent 是后台运行的
- 有独立 session key
- 完成后会向请求方回传结果
- 可以设置单独的 model 和 thinking 级别
- 可以设置超时时间
- 可以控制是否保留 session
- 默认有最大深度和并发限制，避免失控
我很认同这种设计。它不是一味追求“全自动”，而是把边界做得比较清楚：
- 可以协作
- 但不能无限套娃
- 可以并发
- 但要限制 fan-out
- 可以嵌套
- 但默认不开放太深
这说明 OpenClaw 团队是真的在考虑实战，而不是只做 demo。
五、什么时候不该上多 agent
这一段我想单独说，因为很多教程都只会讲优点。
1）任务本来就很简单
比如“帮我总结这段话”“给我起个标题”，单 agent 就够了。你再拆研究员、写手、审核员，只会增加延迟和 token。
2）你还没把单 agent 跑顺
如果你现在连模型切换、工具权限、会话边界都还没理清，那别急着上多 agent。因为多 agent 会把原来的问题放大，而不是自动帮你解决。
3）你没有明确分工
不是说 agent 多了就叫协作。没有清晰角色定义，最后只会变成多个 AI 一起重复劳动。
六、我建议的新手分工模板
如果你想试试，又不想一步到位搞很复杂，我建议先从 3 个角色开始：
角色 1：协调员
职责：
- 理解任务
- 拆任务
- 收结果
- 最终答复
角色 2：研究员
职责：
- 查文档
- 找依据
- 抽要点
- 不负责写最终成品
角色 3：审核员
职责：
- 检查事实错误
- 检查遗漏风险
- 检查有没有编造不存在的特性
这一套已经能覆盖大多数内容型和信息型工作流了。
七、排障和治理也很重要
多 agent 最大的问题，不是“能不能跑”，而是“跑歪了你能不能看懂”。
好在 OpenClaw 官方文档里给了不少管理能力，比如：
- 查看 sub-agent 列表
- 看 log
- 杀掉某个子 agent
- 给运行中的子 agent 发送新消息或 steer
这些功能很实用。因为真实世界里的任务，不可能每次都一次成功。你一定会遇到：
- 某个子任务超时
- 某个 agent 理解偏了
- 某个结果不够完整
如果没有这些控制手段，多 agent 很快就会变成“看起来很高级，实际上难维护”。
八、我对多 agent 的真实态度
我现在对多 agent 的看法很明确：
它不是 AI 的必选项，但它是复杂任务的放大器。
当任务本身就该分工时，OpenClaw 的这套设计非常顺手。特别是独立 session、结果回传、深度限制、子 agent 模型覆盖这些点，说明它不是停留在概念层面。
但如果你只是拿它做聊天、简单查询、轻量写作，其实单 agent 更省心。
所以正确顺序应该是：
- 先把单 agent 跑顺
- 再拆最小的一层子任务
- 确认收益明显后，再扩展成团队
别反过来。
如果你想看原始资料，推荐先看：
- OpenClaw Sub-agents 文档：https://docs.openclaw.ai/tools/subagents
- OpenClaw 官方 GitHub：https://github.com/openclaw/openclaw
结语
很多人喜欢把多 agent 讲成“AI 自己开会”。这个说法不算错，但我更愿意把它理解成：把复杂任务拆给合适的执行者，让总控只做总控该做的事。
当你用对地方时，OpenClaw 的多 agent 不只是酷，而是真的能提升质量和效率。
最后再提一句，如果你准备认真玩多 agent，模型成本会比单 agent 更敏感。因为每个子任务都是上下文、都是 token。我自己的建议是，尽量找一个统一、稳定、价格别太离谱的 API 接入层，比如 manusn.com 这种低价、稳定、小白友好的 API 中转站。这样你在协调员、研究员、审核员之间切模型时，配置和账单都会轻松很多。