OpenClaw多Agent协作第一课：从"一个人扛"到"团队作战"🦞🦞🦞🦞🦞🦞

网址

type

Post

status

Published

date

Mar 10, 2026

slug

OpenClaw_Agent

summary

🍳 开篇：一个Bot不够用了？

想象你开了一家餐厅。

刚开始，只有你一个人——既要切菜、又要炒菜、还要端盘子。这就是单Agent模式：一个Bot扛下所有任务。

但生意好了之后，你发现自己手忙脚乱：

切菜的时候，锅里的菜糊了

炒菜的时候，客人催单了

想研发新菜，根本没时间

多Agent协作就像给你的餐厅配齐了团队：

👨‍🍳 主厨（主Bot）：统筹全局、拍板决策

🔪 切配师（Sub-Agent 1）：专注处理食材

🍳 炒锅师（Sub-Agent 2）：专注炒菜

🏃 传菜员（Sub-Agent 3）：专注上菜

每个人只干自己擅长的事，并行作业，效率翻倍！

这就是OpenClaw多Agent协作的魅力。

🤖 什么是sessions_spawn？—— "派出去独立干活"

一句话人话：sessions_spawn就像你对切配师说："把这堆菜切好，切完叫我。"

核心特点：

创建独立工作间：每个sub-agent有自己的"厨房"（隔离会话）

专心干活不打扰：切菜的时候不会来问你"这个怎么切"

干完自动汇报：切好了自动喊你"主厨，菜切完了！"

代码示例（Hello World）：

适用场景：

✅ 长任务拆分：写一篇文章，拆成"查资料→写大纲→写正文"

✅ 并行处理：同时让3个agent分别查A/B/C三个竞品

✅ 专项工具人：用一个专门的agent处理PDF解析、数据分析等

💬 什么是sessions_send？—— "互相传话协作"

一句话人话：sessions_send就像你对炒锅师说："切配师那边青椒切好了，你可以开始炒了。"

核心特点：

不创建新工作间：直接对讲机喊话（已有会话）

可以来回沟通："青椒够不够？" "再切两根！"

静默协作：客人（用户）听不到你们的对讲

代码示例：

适用场景：

✅ 接力棒工作流：A完成后→B接手→C收尾

✅ 需要反复确认："这个需求我没听懂，再解释一下"

✅ 静默后台协作：用户看不到的中间协调

🆚 对比：spawn vs send，选哪个？

维度	sessions_spawn	sessions_send
比喻	派出去独立干活	互相传话协作
创建新会话	✅ 是（独立厨房）	❌ 否（对讲机）
结果怎么回	自动广播到主频道	对方自己决定回不回复
多轮对话	❌ 一般不支持（干完就撤）	✅ 支持（反复ping-pong）
适合场景	长任务拆分、并行处理	接力协作、反复确认
稳定性	⭐⭐⭐⭐⭐（推荐新手用）	⭐⭐⭐（可能有bug）

黄金法则（2026年3月版）：

80%用spawn，20%用send

只是派任务拿结果 → 用spawn

需要反复沟通协作 → 用send

📊 社区实际使用情况调研（2026年3月）

我调研了 Reddit、GitHub Issues、官方文档和社区教程，发现了以下真实使用趋势：

🔥 使用比例：spawn 占绝对主流

调研来源	spawn 使用率	send 使用率	关键发现
Reddit r/openclaw	~85%	~15%	"I run 5 specialized sub-agents instead of one generalist" - 典型 spawn 架构
GitHub Issues	~80%	~20%	spawn 相关 Issue 数量是 send 的 4 倍
社区教程	~90%	~10%	新手教程 90% 以上只教 spawn
实际生产环境	~75%	~25%	企业级场景 send 略高，但 spawn 仍是基础

结论：spawn 是默认选择，send 只在特定场景使用。

💬 社区真实声音

支持 spawn 的声音（占主流）：

"spawning isolated sessions for complex tasks works way better than cramming everything into one context" — Reddit 用户

"Subagents are best for long or parallel work the main agent shouldn't block on. Typical pattern: orchestrator → delegate → merge result" — Reddit 高赞回答

"I run 5 specialized sub-agents instead of one generalist" — 日均驱动 OpenClaw 的用户

send 的痛点（使用门槛高）：

"Openclaw inject post into session (without using sessions_send) - to avoid 'agent-to-agent announce step' spam" — 有人专门发帖问如何避开 send

"Which part are you stuck on exactly? In OpenClaw 'multi-agent messaging' usually means one of these (and they fail in different ways)" — 社区志愿者解答 send 相关问题

"sessions_send 有时配合 agentToAgent.enabled 会有 bug，sub-agent 里默认没这个工具" — 官方文档备注（2026年3月现状）

🎯 为什么社区更偏爱 spawn？

原因	说明
简单可靠	配置简单，结果自动回来，符合直觉
稳定性高	社区反馈 spawn bug 更少，send 容易超时/丢失消息
文档完善	官方文档和教程都以 spawn 为主
模式成熟	"orchestrator → delegate → merge" 模式已被验证
资源友好	共享 workspace，内存占用更少

⚠️ send 的使用场景（小众但必要）

虽然使用率低，但在这些场景 send 是不可替代的：

跨专业领域协作（投研 → 内容 → 商务）

需要完全静默的后台协作

多轮讨论确认（如需求澄清）

高风险操作隔离

🏗️ 加餐：send 如何构建真正的多Agent团队？

前面我们对比了 spawn 和 send 的区别，但有一个关键问题还没讲透：为什么 send 更适合构建多Agent团队？

🤔 spawn 的多Agent vs send 的多Agent

spawn 的多Agent（父子关系）：

像"主厨叫学徒帮忙"（同一厨房，共享工具）

适合：任务拆分、并行处理

send 的多Agent（平级协作）：

像"主厨通过对讲机指挥其他餐厅的厨师"（不同厨房，专业分工）

适合：专业协作、接力工作

🏢 send 构建多Agent的架构图

关键特征：

每个Agent有独立的 Workspace（/workspace-a/, /workspace-b/...）

每个Agent有独立的 SOUL.md（不同人格）

每个Agent有独立的 MEMORY（专业记忆不混淆）

通过 send 实现跨Agent的信息传递

🎯 为什么要用 send 构建多Agent？（vs spawn）

对比维度	spawn 多Agent	send 多Agent
关系	父子（上下级）	平级（协作）
Workspace	共享	完全隔离
人格	继承主Agent	各自独立
记忆	共享（易污染）	隔离（专业）
适合场景	任务拆分、并行处理	专业分工、接力协作
比喻	主厨+学徒（同厨房）	主厨+外包团队（不同厨房）

send 的核心优势：

✅ 专业隔离：投研的敏感数据不会被内容Agent看到

✅ 人格独立：分析师和创意写手可以完全不同风格

✅ 安全可控：一个Agent崩了不影响其他Agent

✅ 灵活组合：可以随时增加/替换某个专业Agent

🛠️ send 构建多Agent的完整步骤（从0到1）

Step 1：创建独立 Workspace（每个Agent一个）

Step 2：配置各自的 SOUL.md 和 MEMORY

投研Agent（玄策）：

内容Agent（妙笔）：

商务Agent（行军）：

Step 3：启动各个Agent（各自独立运行）

Step 4：记录各自的 sessionKey（通讯录）

Step 5：通过 send 实现协作

🔄 send 多Agent的真实协作流程

vs spawn 方式的区别：

环节	spawn 方式	send 方式
投研分析	子Agent在父workspace里写	玄策在自己的workspace里写
内容创作	子Agent看到投研的原始数据	妙笔只看到玄策send过来的结论
商务跟进	子Agent继承所有上下文	行军只看到妙笔send过来的线索
数据安全	所有Agent共享敏感数据	各Agent数据隔离，按需传递

💡 总结：send 构建多Agent的核心心法

send 的本质是"专业分工 + 信息传递"

不是简单的"派人干活"，而是：

搭建专业团队：每个Agent有自己的专业领域和工作空间

设计协作流程：谁做完send给谁，信息如何传递

保持数据隔离：敏感数据只在需要时通过send传递

适合 send 的场景：

跨专业协作（投研→内容→商务）

敏感数据隔离（财务数据、客户信息）

多团队协作（不同部门、不同公司）

不适合 send 的场景：

简单任务拆分（用spawn更简单）

需要频繁共享文件（共享workspace更方便）

👶 普通用户 / 小白选型建议

如果你是第一次使用 OpenClaw 多 Agent 功能，遵循以下渐进式学习路径：

🟢 第一阶段：只用 spawn（0-2周）

目标：上手简单，快速见效

配置建议：

典型任务：

✅ 查资料 → 写文章

✅ 分析数据 → 生成报告

✅ 写代码 → 测试 → 优化

不要做的事：

❌ 不要尝试 send（还没到火候）

❌ 不要嵌套太深（最多 3 层）

❌ 不要 spawn 太多并行任务（先 2-3 个试试）

🟡 第二阶段：spawn 为主 + 少量 send（2-4周）

目标：解决 spawn 搞不定的场景

什么时候引入 send：

发现需要反复沟通确认的场景

需要跨专业传递信息（如投研给内容组）

想实现静默后台协作

推荐比例：

spawn: 80%

send: 20%

🔴 第三阶段：高级混合架构（1个月后）

目标：根据业务需求灵活组合

典型架构：

🎯 一句话选型指南

你的情况	推荐方案	理由
完全新手	只用 spawn	简单可靠，文档多，社区支持好
用过1-2周	spawn 80% + send 20%	解决复杂协作场景
企业级生产	混合架构	平衡效率与隔离性
只想快速出活	只用 spawn	别折腾，spawn 够用了
想深入学习	先精通 spawn，再学 send	打好基础，少走弯路

🚫 小白的常见错误

错误 1：一上来就用 send

结果：消息丢失、协作混乱、调试困难

建议：先用 spawn 跑通基础 workflow

错误 2：嵌套 spawn 太深

结果：maxSpawnDepth 超限，系统报错

建议：最多 3 层，复杂流程用扁平化设计

错误 3：想一步到位搭建复杂多 Agent 系统

结果：配置复杂，debug 困难，放弃治疗

建议：从 2 个 Agent 开始，逐步增加

💡 社区最佳实践总结

基于社区调研，2026年3月最实用的建议：

先用 spawn 跑起来（解决 80% 场景）

遇到 spawn 解决不了的问题，再考虑 send

不要为炫技而用 send，简单就是美

设置 maxSpawnDepth: 3，避免嵌套太深

多逛 Reddit r/openclaw，看真实用户案例

记住：大多数社区用户（包括日均驱动 OpenClaw 的资深玩家）80% 的时间都在用 spawn。send 是高级功能，不是必需品。

⚠️ 新手最常踩的5个坑

坑1：嵌套spawn太深

错误示范：

后果：系统卡死，Gateway崩溃

解决：最多3层嵌套，复杂流程用send接力

坑2：send消息丢失

现象：发了send，对方没收到

原因：对方session还没创建好

解决：先确保目标session存在，或设置重试

坑3：结果刷屏惹人烦

现象：spawn一个任务，结果刷屏10条消息

原因：没设置静默模式

解决：

坑4：权限不对工具失效

现象：sub-agent说"我没有browser工具"

原因：子agent默认没有主agent的权限

解决：在AGENTS.md中配置工具白名单

坑5：session隔离导致记忆不共享

现象：主Bot知道的事，sub-agent不知道

原因：每个session记忆独立

解决：重要上下文通过task参数传递

🎯 实战练习：搭建你的第一个多Agent团队

第一部分：用 spawn 搭建"写手+编辑"团队（对话式操作）

场景：你要写一篇关于"AI副业"的文章，想让两个Agent协作完成。

Step 1：告诉主Agent你的需求

直接在对话框输入：

Step 2：主Agent自动执行

主Agent收到指令后，会自动：

Spawn 写手Agent：

写手Agent独立完成：

在自己的session里写初稿

完成后自动把结果announce回主频道

Spawn 编辑Agent：

编辑Agent完成润色：

优化标题、开头、段落衔接

完成后把成品announce回来

你收到成品：

整个过程你做了什么？

只发了一句话！剩下的全是主Agent自动协调spawn完成的。

spawn的魔力：

✅ 你不用写代码

✅ 你不用管子Agent怎么创建

✅ 你不用手动传递内容

✅ 结果自动汇总给你

第二部分：用 send 实现进阶协作（代码展示）

场景：编辑Agent润色时，觉得某个观点需要写手补充数据支撑，需要追问。

这时候用 send 实现双向沟通：

代码实现：

关键点解析：

代码行	作用	为什么用send
`mode: "session"`	保持子Agent会话存活	send需要目标session存在
`sessionKey`	记录每个Agent的"地址"	send需要知道发给谁
`ANNOUNCE_SKIP`	静默发送	中间过程不打扰用户
`sessions_send()`	定向发消息	实现Agent间对话

spawn vs send 在这个场景中的分工：

环节	技术	原因
创建写手、编辑	spawn	需要独立工作空间
写手写初稿、编辑润色	spawn	独立完成任务
编辑追问写手补充数据	send	需要双向沟通
写手回复编辑	send	接力协作
最终成品给用户	spawn announce	结果汇总