OpenClaw🦞多Agent从场景到实践

最近两周，大家围绕 OpenClaw（小龙虾）讨论最多的问题，从“怎么安装”逐步转向“怎么用好”。尤其是多 Agent 玩法，几乎成了所有用户都会遇到的话题。

但一个现实是：多 Agent 看起来很酷，不代表你一定需要它。

真正有效的做法，不是先追求复杂架构，而是先判断场景、再选模式、最后做可验证的落地。

这篇文章，我把直播里的核心内容整理成一套可以直接上手的实战框架。

一、先说结论：多数场景，单 Agent 就够用

在刚开始使用 OpenClaw 时，最容易犯的错误是：还没找到稳定的业务场景，就先花大量时间搭多 Agent。

更推荐的顺序是：

1. 先把单 Agent 用到极致，你想到的所有事情都尝试和它对话沟通。
2. 当你明显遇到边界，再切多 Agent。边界包括这么几种典型场景
   1. Agent在会话中出现了遗忘的现象，说明上下文长度已经超过模型上下文了，此时可以考虑拆分多Agent了。当然也可以用 /new 开启新对话解决
   2. Agent同时在做多件不相关的事情。比如你同时在让它制作旅游攻略并且一直提你的改进要求，同时又在让它生成一篇严肃正式的公众号文章，还要让它帮你查找科研资料。这样既浪费Token，因为OpenClaw每次与大模型对话，都会带上历史聊天记录作为上下文，带上的其他事情的聊天记录就是浪费的。也影响效果，上下文越精准，回答的质量会更高。 此时，就可以考虑拆分多Agent了。
   3. 希望多个人同时使用一个机器上的🦞实例，比如给家人，父母，小孩使用时，需要拆分Agent，避免相互干扰。
3. 用“可验证”的方式逐渐完成配置与联调。
   1. 不要一上来就制作太多的Agent。看到过一个50Agent的推荐文章，刚开始肯定是玩不过来的，不要这么激进。
   2. 从两个开始，慢慢增加，是更稳妥的方式。

三、先对齐 4 个关键概念

先对齐多Agent涉及的几个关键概念

• OpenClaw 实例 / Gateway：官方推荐的架构是一个操作系统部署一个OpenClaw实例，多部署会存在资源抢占的问题，应该用多Agent解决，不要多实例。
• Agent：OpenClaw实例内部的“角色单元”，可隔离任务与上下文，Agent我们就理解为设定“人”，你想设定几个“人”，就设定几个Agent；
• BOT：飞书/企微/钉钉上的机器人，bot和agent是独立的，需要绑定才能形成映射。比如飞书上的消息记录，和实际Agent的消息记录，是独立的。如果bot切换过agent映射，bot的聊天记录就可以对应多个agent
• Bindings（路由绑定）：把“谁发来的消息”准确路由给“哪个 Agent”的配置，记录在OpenClaw的配置文件里。

一句话概括：

BOT 是入口，Agent 是执行者，Bindings 是路由规则。

四、5 种多 Agent 模式：该怎么选？

模式 1：单实例 + 多 Agent + 单 BOT（主 Agent 分发）

• 这种模式在底层是 spawn 机制，实际运行时是main agent实时生成了一个新的子 agent，这个子agent，只有灵魂（SOUL.md，AGENTS.md），默认是没有记忆的(没有 Memory.md)。意味着这个模式下执行的多Agent没有持续的沉淀。
• 而且后续也无法转变为多Bot甚至多Bot协作的模式
• 所以不建议作为长期主方案。

配置方法：

• 1、“我要创建几个Agent，分别是 XX、YY、ZZ，他们分别负责什么职责”
• 2、“需要你调用XX Agent来完成什么事情”
• 3、此时可能出现🦞反馈有问题
• 4、调试方法 “你能看到几个agent”，“我需要你能用spawn模式调用这几个子agent，你研究一下文档，缺什么”
• 5、当🦞反馈完成时，需要核验一下 “证明你是用子Agent完成的”

模式 2：单实例 + 多 Agent + 单 BOT + 多个群，可协作（推荐）

• 这种模式需要给每个Agent拉一个群，每个群里都只有同一个Bot
• 这种模式下，使用 session_send 模式，可以让agent之间传递消息实现协作
• 优势：每个 Agent 可单独对话、单独调教、可持续沉淀记忆。可以让🦞持续进化。

配置方法：

• 1、基本和模式1相同，关键的区别是“打开 agent2Agent 工具”，“打开 sessions 之间的可见性，allow范围是 * 或者 指定agent列表”。第二个关键区别是需要配置 bindings 段落，让agent和对应的群绑定起来。群id的查看方式是飞书群-设置-拉到最下方显示的 群id
• 2、协作方式 “使用session send 多agent协作模式，首先发送消息给XXagent完成什么事情，拿到结果后，发送消息给YYagent完成什么事情”
• 3、同样完成后要核验，“证明你是多Agent协作完成的”，如果🦞反馈了多个群的session，就是正确了。

模式 3：单实例 + 多 Agent + 多 BOT 但互不协作（推荐）

• 各 Agent 独立运行，适合并行但无协同场景；例如财务、运营、研发各自处理独立任务。
• 这种模式下，仅需要bindings正确路由，即可平稳使用，很方便

配置方法：

• 1、首先要把飞书bot配置成多account模式，根据你使用的插件完成对应配置
• 2、推荐用 accountId 来 bindings bot 和 agent，最稳定不容易出错
• 3、测试方法依然是要问 “你是哪个 agent”，确保正确路由。不正确的话，先尝试重启，再尝试自己去看配置文件纠错，或者用其他 agent 协助配置

模式 4：单群多 BOT 协作（飞书当前还不可用）

• 在飞书群里可拉多个 BOT，但 BOT 间自动协作能力仍有限。
• 可以通过at多个bot调用到不同的agent，如果打开了不at的话，现象是只有一个bot在回答。
• 如果使用国外的IM，比如 tg 或者 discord，是可以实现群内 bot 的 互相 at 的

配置方式不详细展示

模式 5：多实例跨组织协作

• 更偏企业级架构，用于跨部门、跨实例协同；
• 类似模式4，在 TG/Discord 等平台更容易落地。

配置方式不详细展示

五、飞书实操：从 0 到 1 跑通模式 2（关键步骤）

如果你想在飞书里稳定落地多 Agent，建议按这个顺序做：

1. 创建 Agent 角色，

“创建4个agent，分别是leader、topic、writer、reviewer”

1. 建立群与 Agent 的路由绑定

获取每个群的会话 ID（chat_id），配置到 bindings。

“把 agentxx 和 群id yy 绑定 ”，重复4次

最后记得重启gateway生效配置

1. 做双重验证，这一步一定要做 只做 A 不够，很多“串上下文”问题都发生在这里。
   • 验证 A：群里发消息，机器人能回复；
   • 验证 B：追问“你是哪个 Agent？请证明”。
2. 按需关闭必须 @ 才回复

配置 mentionRequired=false后重启生效。

“设置成不用at也可以在群聊里回复消息”

1. 开启 Agent2Agent 通信

打开通信工具、设置 allow 列表、并确保跨 session 可见参数正确。

“配置 agent2Agent 工具，打开sessions之间可见性，范围是所有agent”

1. 给每个 Agent 单独写角色规则

选题看信息源，写作管风格，审稿管规范等。

角色越清晰，协作效果越稳定。

实现方式是自然对话，或者自己去修改 AGENTS.md

1. 用端到端任务验收，并要求“过程证明”

不只看结果文本，要让系统证明它确实经过了“选题→写作→审稿→改写”的链路。

六、高频坑位与优化建议

• “看起来能回复”不等于“路由正确”

一定要做身份验证，否则很容易多个群实际都落到同一个 Agent。

• 模型能力直接影响配置成功率

模型越弱，指令要越明确、越结构化。

• 多 Agent 越多，维护成本越高

先从 2~4 个角色起步，别一开始就堆到十几个。

• 稳定性优先于炫技

先保证可恢复（配置备份、重启策略），再追求复杂编排。

七、最终建议：先用对，再用多

多 Agent 的本质，不是“更高级”，而是“更适配复杂分工”。

如果单 Agent 已经能稳定完成任务，就不要为了炫技而增加系统复杂度。

当你明确遇到“记忆边界、任务干扰、角色分工”这三类问题时，再切到模式 2 或模式 3，通常是投入产出比最高的路径。

一句话总结：先把单 Agent 跑通到稳定，再把多 Agent 做到可验证。

更多OpenClaw实践，请看

视频号：唐斩AI编程