OpenClaw 多 Agent 协作配置指南：从角色拆分、消息路由到 Sub-Agent 并行编排

很多人第一次玩 OpenClaw，都是先把一个主 Agent 跑起来：能聊天、能写代码、能接渠道、能跑工具，看上去已经很强了。

但一旦你真的开始拿它做项目，很快就会遇到一个现实问题：

一个 Agent 什么都能干，但什么都让它干，最后往往什么都不够稳。

写代码的需要更强工具权限，写内容的需要更干净的上下文，家庭群助手需要更严格的边界，运营通知 Bot 又只该做收发与提醒。把这些任务全塞给一个 Agent，短期省事，长期一定混乱。

这也是 OpenClaw 官方文档里单独把 Multi-Agent Routing、Sub-Agents、Delegate Architecture、Multi-Agent Sandbox & Tools 拆出来讲的原因：

OpenClaw 不是只能跑一个 Agent，它可以在一个 Gateway 里同时托管多个 Agent，并通过绑定规则、工具权限、工作区和会话能力把这些 Agent 协同起来。

这篇文章不讲空话，直接讲你最关心的四件事：

OpenClaw 多 Agent 协作到底怎么设计
配置文件应该怎么写
多 Agent 之间怎么分工、怎么互相调用
怎么避免"看起来协作，实际打架"的常见坑

如果你刚接触 OpenClaw，建议先阅读 OpenClaw 新手排坑指南，确保单 Agent 能正常运行后再考虑多 Agent 配置。

一、先搞清楚：OpenClaw 的多 Agent，不是"多开几个聊天窗口"

OpenClaw 官方对多 Agent 的定义很清晰：

一个 Gateway 可以同时托管多个 Agent。每个 agentId 都可以有自己独立的工作区、独立的 agentDir、独立的会话存储、独立的身份和独立的工具边界。大多数场景下，官方建议使用一个 Gateway 承载多个 Agent；只有你特别需要更强隔离或冗余时，才考虑多 Gateway。

这意味着，多 Agent 协作的本质不是"复制一个主 Bot"，而是：

每个 Agent 各管一摊
各自有不同人格和职责
各自有不同技能和权限
通过消息路由、会话工具或 Sub-Agent 机制协作

说得直白一点：

单 Agent 是一个全能员工；多 Agent 是一支有分工、有权限边界、有协作链路的团队。

二、OpenClaw 多 Agent 协作，最常见的 4 种架构

1）按职能拆分：写代码、写内容、做通知、做客服

这是最常见也最好落地的方式。

比如你可以这样拆：

coder：负责代码、终端、文件读写、测试
writer：负责文章、文案、SEO、润色
ops：负责监控、日志、部署命令、告警
family：负责家庭群问答，只保留只读和消息类工具

这种拆法的好处是：**职责清晰，工具权限也好收口。**官方文档明确支持按 Agent 配置不同的 tools.allow / tools.deny，以及不同的 sandbox 模式。

2）按渠道拆分：WhatsApp 一个 Agent，Telegram 一个 Agent，Discord 一个 Agent

OpenClaw 官方文档给了很明确的路由示例：

你可以把 WhatsApp 绑定到一个"日常聊天"Agent，把 Telegram 绑定到一个"深度工作"Agent，或者给 Discord 的不同 bot account 分别绑定不同 Agent。

这种拆法适合：

个人账号和工作账号分开
不同平台承担不同任务
同一个人想区分轻量聊天和重任务处理

3）按对象拆分：某个群、某个 DM、某个账号交给特定 Agent

OpenClaw 的 bindings 支持按 peer、parentPeer、guildId、accountId 等维度做确定性路由，而且是"最具体规则优先"。这意味着你可以做到：

某个 WhatsApp 群只交给 family
某个 Telegram 机器人只交给 alerts
某个联系人固定交给 opus
同一渠道里，只有一个特定会话走深度 Agent

官方文档明确说明，peer 级绑定优先于 channel 级绑定。

4）主 Agent + Sub-Agent：由主协调者临时拉工人做并行任务

这是 OpenClaw 里最像"多智能体协作"的玩法。

Sub-agents 是由当前 Agent 会话临时生成的后台子运行，它们有自己的独立 session，完成后会把结果 announce 回请求方会话。官方给出了 /subagents spawn、/subagents list、/subagents log、/subagents kill 等完整控制方式。

这种模式特别适合：

一个主 Agent 做总控
多个子 Agent 并行查资料、跑分析、拆任务
最后由主 Agent 汇总输出

一句话概括：固定 Agent 适合长期分工，Sub-Agent 适合临时并行。

三、OpenClaw 多 Agent 配置的 3 个底层原则

原则一：每个 Agent 都要有独立 workspace 和 agentDir

官方文档写得非常直接：

**永远不要在多个 Agent 之间复用 agentDir。**否则会导致 auth 和 session 冲突。每个 Agent 都应该有自己的 workspace、自己的 agent state、自己的 session store。

原则二：共享的是技能，不共享的是身份和凭据

OpenClaw 支持多层技能来源：

~/.openclaw/skills 作为共享技能
~/.agents/skills 作为个人级共享技能
<workspace>/.agents/skills 作为项目级技能
<workspace>/skills 作为该 Agent 独享技能

同时，agents.defaults.skills 可以作为默认技能白名单，而 agents.list[].skills 可以对某个 Agent 做覆盖。

也就是说：技能可以共享，但人格、凭据、会话和权限必须分开。

原则三：协作必须显式打开，不要默认互通

官方配置里，tools.agentToAgent 默认是关闭的，必须显式 enabled: true 并配置 allowlist。

另外，tools.sessions.visibility 也决定了 session tools 可见的范围，默认是 tree，不是全局乱看。跨 Agent 访问还需要配合 tools.agentToAgent。

这套设计很对，因为多 Agent 最怕的不是不会协作，而是协作得太随便。

四、一套最实用的 OpenClaw 多 Agent 基础配置

下面给你一套很适合起步的结构：一个主聊天 Agent，一个写作 Agent，一个代码 Agent。

json

{
  "agents": {
    "defaults": {
      "skills": ["github", "docs-search"],
      "subagents": {
        "maxSpawnDepth": 2,
        "maxChildrenPerAgent": 5,
        "maxConcurrent": 8,
        "runTimeoutSeconds": 900
      }
    },
    "list": [
      {
        "id": "main",
        "default": true,
        "name": "Main Assistant",
        "workspace": "~/.openclaw/workspace-main",
        "agentDir": "~/.openclaw/agents/main/agent",
        "model": "anthropic/claude-sonnet-4-6"
      },
      {
        "id": "writer",
        "name": "Writer",
        "workspace": "~/.openclaw/workspace-writer",
        "agentDir": "~/.openclaw/agents/writer/agent",
        "model": "anthropic/claude-sonnet-4-6",
        "skills": ["docs-search"],
        "tools": {
          "deny": ["exec", "browser", "canvas"]
        }
      },
      {
        "id": "coder",
        "name": "Coder",
        "workspace": "~/.openclaw/workspace-coder",
        "agentDir": "~/.openclaw/agents/coder/agent",
        "model": "anthropic/claude-opus-4-6",
        "tools": {
          "allow": ["read", "write", "edit", "apply_patch", "exec", "sessions_list", "sessions_history", "sessions_send", "sessions_spawn", "session_status"]
        }
      }
    ]
  },

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

  "bindings": [
    {
      "agentId": "main",
      "match": { "channel": "whatsapp" }
    },
    {
      "agentId": "writer",
      "match": { "channel": "telegram" }
    }
  ]
}

这套配置背后的思路和官方文档是一致的：

agents.list 定义多个 Agent
bindings 决定消息路由到哪个 Agent
tools.agentToAgent 显式打开 Agent 间通信
tools.sessions.visibility 决定会话工具可见范围
agents.defaults.subagents 控制 Sub-Agent 深度和并发
agents.list[].tools 与 agents.list[].skills 控制单 Agent 权限与能力范围

五、最快的创建方式：先用向导，再补配置

如果你不想手敲全部目录，官方推荐直接用 agent wizard：

bash

openclaw agents add writer
openclaw agents add coder
openclaw agents list --bindings

官方文档说明，openclaw agents add <id> 会为该 Agent 创建独立 workspace、独立 agent state 和独立 session store。之后你再把 bindings 加上，重启 Gateway 即可。

重启常用命令：

bash

openclaw gateway restart
openclaw agents list --bindings
openclaw channels status --probe

如果你是从单 Agent 迁移，建议顺序是：

先 agents add 把 Agent 骨架建出来
再写 bindings
再补每个 Agent 的 AGENTS.md、SOUL.md、USER.md
最后再做工具与 sandbox 收口

这样不容易一上来就把路由和权限配乱。

六、怎么让多个 Agent 真正"协作"，而不是只是"并存"

多 Agent 成功与否，关键不是你配了几个，而是它们是否形成了稳定协作链。

方案一：主 Agent 通过会话工具调其他 Agent

OpenClaw 的 session tools 提供了：

sessions_list
sessions_history
sessions_send
sessions_spawn
session_status

其中 sessions_send 可以向另一个 session 发送消息，并可选择等待回复；OpenClaw 还支持 reply-back loop，最多可交替 5 轮。

你可以把它理解成：主 Agent 自己不会的事，不是硬扛，而是把任务扔给专门的会话或专门的 Agent。

这套方式非常适合：

主 Agent 把草稿发给 writer 润色
主 Agent 把部署问题丢给 ops
主 Agent 把代码修复交给 coder

方案二：主 Agent 直接 spawn Sub-Agent 做并行任务

Sub-agent 机制更适合"临时工"模式。官方说明：

Sub-agent 会在自己的 session 中后台运行
完成后 announce 回请求方
sessions_spawn 总是非阻塞，立即返回 accepted
结果通过后续消息链路回传
子 Agent 并发由 agents.defaults.subagents.maxConcurrent 控制

如果你要的是这种工作流：

主 Agent 拆 3 个研究任务
3 个 Sub-Agent 并行去查
主 Agent 最后汇总成一篇文章

那就用 Sub-Agent。

方案三：给每个 Agent 设清晰边界，不让它"越权帮忙"

很多人做多 Agent 最大的问题是：写着写着，writer 也开始动文件，coder 也开始乱发消息，family Bot 也能读不该读的内容。

官方给的答案非常明确：用 per-agent tool policy 和 per-agent sandbox 收口。tools.allow / tools.deny 在 Gateway 层生效，不依赖 Agent 自觉；同时不同 Agent 还可以开启不同 sandbox 模式。

这一步非常重要，因为真正能跑起来的多 Agent，不是"大家都很聪明"，而是"大家都有边界"。

七、推荐你直接照搬的 3 个多 Agent 协作模式

模式一：内容生产线

适合做公众号、SEO、知识库。

分工如下：

researcher：查资料、搜文档、收集数据
writer：写初稿
editor：统一风格、压缩废话、改标题

推荐配置思路：

researcher 保留搜索与只读
writer 保留写作相关技能，不给 exec
editor 只做内容校对，不给高风险工具
主 Agent 做总控，spawn 两到三个 Sub-Agent 并行收集素材

模式二：开发协作线

适合代码项目。

分工如下：

coder：改代码
reviewer：查 diff、审逻辑、做回归检查
ops：看日志、查环境、执行部署级命令

推荐配置思路：

coder 拥有 read/write/edit/apply_patch/exec
reviewer 偏只读 + 执行测试
ops 可读日志、执行诊断命令，但限制写权限
主 Agent 用 sessions_send 把任务发给不同角色

模式三：群聊 / 家庭 / 组织助手

适合群聊 Bot 或组织型助手。

分工如下：

family：只处理家庭群
alerts：只发提醒
delegate：处理组织级对外信息

OpenClaw 官方文档专门给了 family 和 delegate 的范式：可以绑定到单个群、设置 groupChat.mentionPatterns，再给更紧的 tool policy；也可以单独创建 delegate agent，并通过工具限制和沙箱隔离来实现"只做授权范围内的代办"。

八、一个很值得用的高级技巧：群聊里用 mention gating 精准点人

如果多个 Agent 共享一个群，最怕的是大家一起抢话。

OpenClaw 官方支持在 agent 级别配置 groupChat.mentionPatterns，例如：

json

{
  "agents": {
    "list": [
      {
        "id": "family",
        "name": "Family",
        "workspace": "~/.openclaw/workspace-family",
        "groupChat": {
          "mentionPatterns": ["@family", "@familybot", "@Family Bot"]
        }
      }
    ]
  }
}

官方文档明确指出，这种配置适用于多 Agent 共处一个 group 的场景，可以让 @mention 更精准地落到目标 Agent 身上。

一句话说透：多 Agent 在群里能不能优雅共存，取决于你有没有"点名规则"。

九、如果你需要更强安全边界，请看 Delegate 架构

Delegate 不是普通多 Agent 的"另一个 Bot"，而是更接近"授权代理人"。

官方的 Delegate Architecture 文档讲得很清楚：

先创建独立 delegate agent
给它独立 workspace、agentDir、session store
用 Gateway 层工具策略做硬限制
必要时对其启用 sandbox
所有行为都保留日志与审计链路

最核心的限制长这样：

json

{
  "id": "delegate",
  "workspace": "~/.openclaw/workspace-delegate",
  "tools": {
    "allow": ["read", "exec", "message", "cron"],
    "deny": ["write", "edit", "apply_patch", "browser", "canvas"]
  },
  "sandbox": {
    "mode": "all",
    "scope": "agent"
  }
}

这种模式非常适合：

企业或组织助手
授权型收发任务
需要严格审计的自动化协作
不希望 delegate 随意接触宿主环境的场景

十、OpenClaw 多 Agent 的 5 个常见坑

1. 复用 agentDir

这是官方明确反对的。一复用，auth、session、凭据隔离全乱。

2. 只建 Agent，不写 bindings

你把 Agent 建出来了，不代表消息会自动路由过去。bindings 才是多 Agent 真正开始工作的入口。

3. 想让 Agent 互相发消息，却没开 tools.agentToAgent

官方默认是关的。不开 allowlist，就别指望跨 Agent 流程顺畅。

4. 把所有工具都放开

这会让多 Agent 失去意义。角色没有边界，协作就会退化成"多个不受控的超级管理员"。

5. Sub-Agent 并发开太大

官方明确提醒，Sub-agent 共享同一个 Gateway 进程资源，maxConcurrent 本质上是安全阀。别把并行当无限池。

多 Agent 场景下如果出现性能问题或超载提示，可以参考 OpenClaw 超载提示排查进行排查。

十一、权限与认证问题

多 Agent 配置中，权限和认证是常见问题。关于权限配置的详细说明，可以参考 OpenClaw 审批机制详解。

如果遇到认证错误，可以查阅 OpenClaw 认证错误排查指南进行排查。

十二、我给你的实操建议：先搭"小团队"，再搭"智能体组织"

如果你现在刚开始配 OpenClaw 多 Agent，不要一上来就搞 7 个、9 个、12 个。

最稳的起手式是：

一个 main 总控
一个 writer 内容专员
一个 coder 技术专员

然后先跑通这三条链：

bindings 能否把消息正确送到目标 Agent
sessions_send 能否让主 Agent 调其他 Agent
sessions_spawn 能否让主 Agent 临时拉 Sub-Agent 并行干活

只要这三条链通了，你就已经不是"多开几个 Bot"，而是真正进入了 OpenClaw 的多 Agent 协作阶段。

结语

OpenClaw 的多 Agent 协作，真正的价值不在于"能建很多 Agent"，而在于它把角色、权限、路由、会话、协作、并发这些以前容易混成一团的东西，拆成了可配置、可审计、可收口的结构。

你如果只想要一个聪明助手，单 Agent 就够。

但你如果想让 OpenClaw 真正承担项目工作流、内容生产线、开发协作链或者组织级自动化，那你迟早会走到多 Agent 这一步。

最后送你一句很实用的话：单 Agent 拼的是能力上限，多 Agent 拼的是系统设计。

问题求助

没能解决你的问题？直接问我

如果你遇到任何技术问题无法解决，可以在这里提交求助。我会尽快查看并回复你。

支持作者

如果这篇文章帮到了你，可以支持我

扫码打赏，支持我持续更新原创排障文章。