最近我折腾了一下 OpenClaw 的多 Agent 功能——简单说，就是给主 AI 配了个专门干活的“副手”，我管它叫“小绿”。

为啥要搞这个？因为有些任务太琐碎、太耗资源，比如反复刷网页、填表、跑流程、整理文档。让主 agent 去干这些活，不仅浪费它的“脑子”，还容易把上下文搞乱。不如单独找个“苦力”专门干脏活累活。

但说实话，这事一开始并不顺。官方文档不是完全没有写，只是信息分散：一处讲 multi-agent，一处讲 session tools，一处讲 bindings，一处讲权限。真到自己上手时，还是很容易卡住。

所以我干脆把这次实际接入过程整理成一篇“人话版”教程：从为什么值得配，到怎么一步步配起来，再到我踩过哪些坑，尤其是 agentToAgent 明明开了却还是不通 这类最容易让人怀疑人生的问题。

一、先想清楚：你到底需不需要“小绿”？

先别急着开配。

你可以先问自己两个问题：

  • 有没有一些重复性高、步骤固定、但又没必要占用主 agent 大脑的任务？
  • 有没有一些任务执行链很长，但判断并不复杂，比如网页操作、数据整理、批量处理？

如果答案是“有”，那副手 agent 就很值得配一个。

主 agent 和副手，分工要明确

这次我给自己定的分工是这样的：

主 agent（main）负责：

  • 总控与调度
  • 做决定、定策略
  • 本机运维
  • gateway / config / restart
  • 最终拍板

副手“小绿”（worker）负责：

  • 浏览器自动化
  • 重复型、执行链长的任务
  • 网页整理、文档整理
  • 远程机器上的执行类工作

反过来说，有些事情最好就别给副手碰：

  • 本机高风险运维
  • 核心配置改动
  • restart / update
  • 最终决策

一句话总结：

主 agent 负责想，副手负责跑。

如果一开始不把边界说清楚，后面配置就算能跑，也会越来越乱。

二、第一步：给“小绿”单独安个家

千万别让副手和主 agent 共用同一个 workspace。

这是我非常建议直接照做的一条：副手一定要独立工作区。

例如：

mkdir -p ~/.openclaw/workspace-worker

然后在这个目录里给它配上自己的一套基础文件：

  • SOUL.md
  • AGENTS.md
  • USER.md
  • TOOLS.md
  • HEARTBEAT.md
  • MEMORY.md
  • memory/

为什么这一步这么重要？

因为多 agent 真正需要的，不只是“多一个名字”，而是：

  • 独立的行为规则
  • 独立的记忆空间
  • 独立的临时文件区域
  • 独立的问题排查边界

如果两个 agent 共用一个 workspace，后面非常容易出现：

  • 记忆串台
  • 工具约定串台
  • 临时文件混在一起
  • 你根本分不清问题是谁搞出来的

所以这一步别省。

三、第二步：凭据别乱放，安全第一

这一步很多人会图省事，直接把 token、私钥、系统账号之类的内容写进规则文件、配置文件，甚至写进博客草稿。

这很危险。

更稳妥的做法是：

  • 敏感信息统一放在 1Password 之类的凭据管理器里，运行时读取
  • 或者放在固定路径，由 agent 只读取“路径”，不把明文写进说明文档

比如你可以约定：

  • SSH 私钥通过固定文件路径读取
  • 1Password service account token 通过固定文件路径读取
  • OA / NC 等第三方系统凭据统一从密码库取

这一步的核心原则是：

规则文档可以公开，Secret 必须隔离。

四、第三步：消息入口怎么分？重点不是“多一个 Bot”，而是“显式路由”

如果你用的是 Feishu、Telegram、Discord 这类渠道，常见的第一反应是：

“那我再加一个 Bot，不就行了？”

实际上，加第二个 Bot 只是多了一个入口，不代表消息一定会准确进到对应 agent。

这次我踩的第一个大坑就和这个有关。

更稳的做法是：

  1. 保留主入口给 main
  2. 给副手一个独立账号或独立入口
  3. 用 bindings 显式把不同入口路由到不同 agent

一个简化后的例子大概像这样：

"bindings": [
  {
    "type": "route",
    "agentId": "main",
    "match": { "channel": "feishu", "accountId": "main_bot_id" }
  },
  {
    "type": "route",
    "agentId": "worker",
    "match": { "channel": "feishu", "accountId": "worker_bot_id" }
  }
]

这里最重要的经验是：

多 agent 场景里，route 最好显式写死，不要赌默认行为。

因为一旦你偷懒只靠默认入口：

  • 消息可能全跑到主 agent
  • 新 agent 可能“看起来上线了”，但根本接不到它该接的活
  • 后面排查会非常恶心

显式 route 的好处就是：

  • 谁接哪路消息，一眼能看出来
  • 不会误伤原来的主入口
  • 后续出问题时更容易定位

五、第四步：群聊权限别忘了，不然你会以为“小绿坏了”

如果副手需要在群里工作，别只盯着 route，还要盯权限。

这也是一个非常容易误判的坑。

典型现象是：

  • 私聊里它能说话
  • 主 bot 也能说话
  • 但副手进了群之后完全没反应

你第一反应可能是：

  • bindings 配错了？
  • route 没生效？
  • agent 启动有问题？

实际上很可能只是群权限没放开。

例如在 Feishu 这类场景里，你通常还要配置类似：

"groupAllowFrom": ["your_group_chat_id"]

推荐做法不是“群聊全开”，而是：

  • 默认收紧
  • 只给需要的群做 allowlist

这样既安全，也更符合副手 agent 的定位。

六、真正关键的坑：为什么 agentToAgent 开了，还是不通？

这部分是我这次最想写出来的地方。

因为很多人到了这里都会卡住。

最常见的做法是先开这个：

"agentToAgent": {
  "enabled": true,
  "allow": ["main", "worker"]
}

然后就以为万事大吉了。

结果一试：

  • 看不到对方会话
  • sessions_* 工具找不到另一个 agent
  • 想内部发消息也发不顺

这时候很容易怀疑自己是不是配错了 agent id、bindings 或者 bot。

但我这次实操下来，真正的关键是：

agentToAgent 不是单独开的，sessions.visibility 也要一起考虑。

也就是说，想让两个 agent 真正能互相看见、互相发、互相问，至少要把这两个东西配成一组：

"tools": {
  "sessions": { "visibility": "all" },
  "agentToAgent": {
    "enabled": true,
    "allow": ["main", "worker"]
  }
}

我自己的理解是这样的：

  • agentToAgent 负责“你们之间原则上允许互通”
  • sessions.visibility 决定“你到底能不能看见 / 找到这些会话”

所以只开前者不看后者，就会出现一种很拧巴的状态：

理论上开了 A2A，实际上链路半通不通。

这也是我觉得官方文档目前最不够“落地”的地方：

它并不是没写，但写得太分散。真正上手时，很多人需要的是一个能直接跑通的组合，而不是分布在不同章节里的概念说明。

七、功能打通后，还得立规矩，不然两个 Agent 会开始“套娃”

很多人以为最难的是“打通”。

实际上打通之后，还有一个更现实的问题：

两个 agent 太容易互相喊话，然后开始无限来回。

所以我最后补了几条非常朴素、但极其重要的规则。

1）默认别瞎聊

没必要为了普通任务就主动互相联系。

原因很简单：

  • 浪费 token
  • 管理员未必知道发生了什么
  • 简单任务本来就该谁做谁做

只有这些情况再发起内部沟通：

  • 管理员明确要求
  • 任务需要升级
  • 需要补规则
  • 需要主 agent 最终拍板

2）名字要固定，别猜

这一条特别重要。

我最后把内部目标名明确写死：

  • 主 agent 固定叫 main
  • 执行型副手固定叫 worker

不要让它们自己去猜“主 agent 是不是叫小爪、是不是叫 default、是不是叫 clawd”。

因为一旦开始猜名字，稳定性就没了。

3）最多三轮

内部沟通默认不超过 3 轮。

为什么？

因为如果两个 agent 在那儿来回 ping-pong，用户最后只会看到一堆消耗，看不到结果。

三轮还收不住，就该：

  • 收敛成结论
  • 或直接升级给人类

4）群内协作要“可判定”，但别假设一定能 @

这条我后来又修正了一次。

一开始我把建议写成了“群里必须显式 @ 对方”，但这其实要看渠道能力。像当前这套 Feishu 机器人场景里，并不天然具备稳定可用的 mention 权限/能力，所以不能把“@ 对方”写成通用默认动作。

更准确的说法应该是：

  • 在支持 mention 的渠道里，优先显式 @ 对应 agent
  • 在不支持 mention 的渠道里，要用更明确的点名、固定目标名，或者直接走内部 session / A2A 指向

核心不是“必须 @”，而是：协作指向必须清晰、可判定、可追踪。

八、如果副手主要干浏览器活，一定要补“动作纪律”

浏览器型副手还有一个常见问题：

它不是不会干，而是太容易在一个页面里来回试，最后什么都没交代清楚。

所以我后来给副手补了三条很实用的规则：

  1. 默认节奏：snapshot → act → snapshot
  2. 同一步不要连续硬试太多次
  3. 卡住了就停，汇报当前页面状态和下一步建议

这背后的逻辑很简单：

副手可以试错，但不能死磕。

尤其是网页和 OA 场景，如果不加这种规则，它非常容易陷入：

  • 一直点
  • 一直等
  • 一直 retry
  • 最后没有任何清晰结论

所以如果你的副手要负责浏览器任务，这组纪律我很建议一起写上。

九、我踩过的坑，你别再踩

坑 1：以为“新建个 Bot”就等于多 agent 跑通

不是。

你至少还要看：

  • agent 是否真的在 agents.list
  • workspace 是否独立
  • route 是否显式
  • 群权限是否放开
  • A2A 和 session 可见性是否一起到位

坑 2：只开了 agentToAgent，忘了 sessions.visibility

这是最值得单独记住的一条。

我现在会把它们当成一组配置记忆：

  • tools.agentToAgent.enabled
  • tools.agentToAgent.allow
  • tools.sessions.visibility

坑 3：副手会去猜主 agent 的名字

不要让系统去猜。

固定写死：

  • 主 agent = main
  • 副手 = worker

坑 4：群里没反应，不一定是坏了，可能只是没进 allowlist

这类问题特别像“配置没生效”，实际上只是权限没开。

坑 5：太早让新 agent 接默认入口

更稳的顺序应该是：

  1. 先建角色
  2. 再建 workspace
  3. 再补规则和凭据入口
  4. 再配 route
  5. 最后才让它接正式流量

别反过来。

十、一个最小可用配置模板

如果你只是想先快速跑起来，可以先按这个思路配最小可用版。

1）定义两个 agent

"agents": {
  "list": [
    { "id": "main" },
    {
      "id": "worker",
      "workspace": "~/.openclaw/workspace-worker"
    }
  ]
}

2）显式 route

"bindings": [
  {
    "type": "route",
    "agentId": "main",
    "match": { "channel": "feishu", "accountId": "main_bot_id" }
  },
  {
    "type": "route",
    "agentId": "worker",
    "match": { "channel": "feishu", "accountId": "worker_bot_id" }
  }
]

3）打通内部通信

"tools": {
  "sessions": { "visibility": "all" },
  "agentToAgent": {
    "enabled": true,
    "allow": ["main", "worker"]
  }
}

然后再把这些规则补进各自工作区：

  • 固定目标名
  • 最多 3 轮
  • 群聊必须显式 @
  • 浏览器任务按 snapshot → act → snapshot 节奏推进

十一、我现在认可的一套接入顺序

如果你也准备给 OpenClaw 接一个副手 agent，我建议按下面这个顺序来：

  1. 先定角色定位：执行 / 总控 / 专项
  2. 给它单独 workspace
  3. 配独立的 SOUL / AGENTS / USER / TOOLS / MEMORY / memory
  4. 复制它真正需要的 skills
  5. 接共享凭据入口
  6. 接清理规则
  7. 配 channel accounts + bindings
  8. 再开 A2A 和 session 可见性
  9. 最后补协作纪律

这个顺序的关键在于：

先把“它是谁、它该干什么、它的东西放哪儿”弄清楚，再去开流量和互通。

十二、最后说两句

多 Agent 听起来很复杂，但真拆开来看，核心逻辑其实就三件事：

  • 分工
  • 路由
  • 纪律

别被那些零散配置项吓到。你按顺序一步步来：

  1. 先给副手安家
  2. 再让它能接消息
  3. 然后打通内部沟通
  4. 最后用规则防止它“无限套娃”

搞定之后，你会明显感觉到主 agent 轻松很多，而副手也能稳定接住那些枯燥但必要的执行活。

这时候，多 agent 才不是“多开一个名字”，而是真的开始有点团队协作的意思了。

如果你也在折腾 OpenClaw 的多 Agent，尤其是 agentToAgent 这块，希望这篇能帮你少踩几个坑。