OpenClaw 多 Agent 攻略：怎么从“光杆司令”变成“龙虾大军”

牧舟聊AI

736人浏览 · 2026-03-12 23:02:00

牧舟聊AI · 2026-03-12 23:02:00 发布

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

有个事儿一直没细聊：要是你不想只跟一个 AI 唠嗑，而是想整出一个“班子”来干活呢？

这里说的不是那种写论文用的 Multi-Agent 框架——也就是一群 Agent 用人话互相派活儿。咱之前聊过 Claude Code 那边的多 Agent 设计，那玩意儿更像是在搞“多人分工写代码”。

今天要唠的是另一条路子：在你自己电脑上跑一个 OpenClaw，让它一人分饰多角，每个角色都有自己的脑子（记忆）、自己的地盘（工作目录），写文章的专心写文章，敲代码的埋头敲代码，谁也别干扰谁。

最近社区里大伙儿对多 Agent 的配置讨论挺热乎。有的出了保姆级教程，有的晒了团队协作方案，还有人把自己踩过的坑都记下来了。不过这些干货都挺散的，很少有人把配置里的门道和取舍拢在一块儿讲清楚。

今儿咱就从头来过，把 OpenClaw 多 Agent 部署的整个流程跑通一遍。

不管你是刚上手的小白，还是用了阵子想升级的老鸟，这篇应该都能帮你找到合适的法子。
手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

先弄明白：一个 Agent 肚子里到底有啥

OpenClaw 的基本套路咱都熟：通道进消息 → 网关（Gateway） → 进队列 → Agent 循环 → 扔给模型 → 写回结果。这之前咱们默认都是一个 Agent 在跑。

到了多 Agent 模式，这个流程里就多了一道卡——路由（Routing）。Gateway 收到信儿后，得先琢磨这事儿该派给哪个 Agent，然后再把它塞进对应 Agent 的队列里去跑循环。

先看张图找找感觉：

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

图里每个 Agent 都是独立的“大脑瓜”，不管是 Workspace、Session 还是状态目录都是分开的。渠道消息一股脑儿进 Gateway，经过路由层分发给不同的 Agent，最后执行工具的时候，既可以直接在宿主机上搞，也能扔进 Docker 沙箱里跑。

不过在聊路由之前，得先把“一个 Agent 到底是啥玩意儿”这事儿掰扯清楚。在 OpenClaw 里，Agent 可不光是个名字或者几句系统提示词，它是一个彻头彻尾的隔离单元，手里攥着三块独立的地盘：
手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

资源	说明	默认路径
Workspace	干活的地儿，放 AGENTS.md、SOUL.md、USER.md 这些设定和记忆文件	`~/.openclaw/workspace-<agentId>`
AgentDir	存状态的地儿，放认证配置（auth-profiles.json）、模型注册信息这些	`~/.openclaw/agents/<agentId>/agent`
Sessions	存聊天记录的地儿，也就是一堆 JSONL 格式的文件	`~/.openclaw/agents/<agentId>/sessions`

这三块资源是谁也不挨着谁。不同的 Agent 之间，默认情况是不共享聊天记录、不共享账号凭证、也不共享工作文件的。每个 Agent 都有自己的 SOUL.md 来定人设，自己攒自己的记忆，甚至能单独配不同的模型和技能（Skills）。

这跟 Anthropic 那边的思路有点像但又不完全一样：人家那是讲 Claude Code 里“啥时候该上多 Agent”的方法论；咱今天这篇更实在，讲的是 OpenClaw 里“多 Agent 工程上咋落地”，全是配置和部署的干货。

💡 提个醒，有个细节容易被忽视：Workspace 是 Agent 执行工具时的默认“当前目录”（cwd），相对路径都是从这儿开始算的。但它可不是那种铁板一块的硬沙箱——只要给绝对路径，它照样能访问宿主机上的其他地方。要是你想把文件系统防得死死的，那就得配合后面要讲的 Sandbox 功能了。
手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

从单 Agent 起步：先把架子搭稳了

要是你还没玩过 OpenClaw，最简单的上手姿势就是用 onboard 向导：

openclaw onboard

它会领着你把配置文件建好、Workspace 初始化完、渠道也接通。这一套下来，你的 ~/.openclaw/openclaw.json 里就会有一个默认的 Agent（ID 叫 main），再配个渠道就能直接开聊。

一个能跑起来的最小配置大概长这样：

// ~/.openclaw/openclaw.json
{
  agents: {
    defaults: {
      workspace: "~/.openclaw/workspace",
    },
  },
  channels: {
    telegram: {
      enabled: true,
      botToken: "你的_BOT_TOKEN",
      dmPolicy: "pairing",   // pairing | allowlist | open | disabled
    },
  },
}

这段配置的意思就是：先把一个渠道跑通，私聊（DM）入口把住关。等到后面再通过 agents.list 加 bindings 来做多 Agent 分流，最后再上 sandbox 做安全防护。
手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！
这儿我得着重说一句——千万别一上来就把配置搞得特别复杂。

咱们聊过，AI 原生工作流有个原则叫“先跑起来，再迭代”。多 Agent 也是这个理儿。先用单 Agent 模式跑一阵子，等你真觉得记忆乱套了、上下文太长带不动了，再考虑往多 Agent 方向拆分。

啥时候该拆 Agent？盯紧这三个信号

当你在单 Agent 模式下跑了一段时间，留心观察这几件事儿：

信号一：记忆开始串台。 比如你在工作群里聊得好好的，Agent 突然蹦出一句你昨天私聊的内容，或者让你写代码的时候它突然扯起了写作的事儿。这是因为所有会话都共用一个 Workspace 和 MEMORY.md 惹的祸。

信号二：系统提示词（System prompt）肿了。 你在不同场景下给它的要求不一样，结果全塞进了一套超长的配置里。每次一开口，光加载系统提示词就得先烧掉 30k token。咱们之前聊过，上下文膨胀可是长跑型 Agent 的头号杀手——拆分多 Agent 是治标又治本的招儿。

信号三：压缩（Compaction）互相打架。 一个会话在整理记忆（compaction）的时候，其他会话就被卡住了。之前提过，这种 compaction 机制之所以会阻塞，也是共享 Workspace 带来的副作用。

一旦出现这些信号，那就是拆分 Agent 的时候了。
手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

动手创建多个 Agent

OpenClaw 提供了个 Agent 管理向导，一行命令就能搞定：

openclaw agents add work
openclaw agents add writing

每敲一条命令，它就会自动给你建好独立的 Workspace、AgentDir 和会话存储，顺便把配置文件里的条目也加上。

如果你想控制得更细一点，也可以直接去改 ~/.openclaw/openclaw.json 文件：

{
  agents: {
    list: [
      {
        id: "home",
        default: true,
        name: "Home",
        workspace: "~/.openclaw/workspace-home",
      },
      {
        id: "work",
        name: "Work",
        workspace: "~/.openclaw/workspace-work",
      },
      {
        id: "writing",
        name: "写作助手",
        workspace: "~/.openclaw/workspace-writing",
      },
    ],
  },
}

有几个要点得记住了：

• 每个 Agent 的 workspace 路径必须不一样，不然记忆和配置搅和在一起——这就又回到“记忆串台”的老路上了。
• agentDir 也别跨 Agent 复用，不然认证和会话肯定冲突。
• 设成 default: true 的 Agent 会接手所有没被规则匹配到的消息；如果不设，列表里排第一个的就自动顶上这个位置。

搞完之后验一下：

openclaw agents list --bindings

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

消息路由：bindings 决定“谁接单”

Agent 建好了，核心问题来了：一条消息发过来，Gateway 咋知道该派给谁去处理？

答案就是 bindings——也就是一组定死的路由规则，每条规则都把匹配条件指到一个具体的 agentId 上。

最常用的招：按渠道或账号分

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

{
  bindings: [
    { agentId: "home", match: { channel: "whatsapp", accountId: "personal" } },
    { agentId: "work", match: { channel: "whatsapp", accountId: "biz" } },
    { agentId: "writing", match: { channel: "telegram" } },
  ],
}

不想多申请 Bot？按群分

同一个 Bot，不同的群走不同的 Agent：

{
  bindings: [
    {
      agentId: "work",
      match: {
        channel: "telegram",
        peer: { kind: "group", id: "-1001234567890" },
      },
    },
    // 兜底：没匹配到的都走 home
    { agentId: "home", match: { channel: "telegram" } },
  ],
}

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

匹配优先级

Bindings 的匹配是死规矩，优先级从高到低这么排：

1. peer（精准打击，匹配某个私聊/群/频道 ID）
1. parentPeer（跟着帖子线程走）
1. guildId + roles（Discord 角色路由）
1. guildId（Discord 服务器）
1. teamId（Slack 团队）
1. accountId（精准匹配某个渠道账号）
1. accountId: "*"（跨账户的渠道级兜底）
1. 默认 Agent

在同一层级里，配置文件里写在前面的规则说了算。如果一条 binding 同时写了好几个匹配条件（比如 peer + accountId），那必须得所有条件都对上了才算匹配（逻辑与 AND）。

优先级分两层，先看精细匹配，再看范围匹配，谁先命中谁赢：

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

实战原则就一条：具体的规则往前放，兜底的规则往后稍。

配好之后重启一下再验证：

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

私聊（DM）安全：多人用必须改 `dmScope`

这步很多教程都不提，但要是漏了，麻烦可就大了。

如果你只接收自己一个人的私聊，这节可以跳过。但只要你开放了多人私聊（比如 dmPolicy: "allowlist" 里填了好几个号），就必须得调整 dmScope。

原因很简单：默认的 dmScope 是 main，这意味着所有人的私聊都共享同一个会话上下文。Alice 跟你 Agent 说的悄悄话，Bob 可能随口问一句“我们之前聊啥了”就全看见了。

咱们讲过 session key 的生成逻辑。dmScope 就是控制私聊场景下这个 session key 咋算的那个开关：

{
  session: {
    dmScope: "per-channel-peer",  // 按渠道+发送者隔离
  },
}

四种取值咋用，看表：

值	啥时候用
`main`	只有你自己用，所有私聊共享上下文，聊起来连贯
`per-peer`	按发送人隔离，但在不同渠道共享（同一个人在 TG 和 WA 上看到的是同一段对话）
`per-channel-peer`	按渠道 + 发送人隔离（多用户强烈推荐）
`per-account-channel-peer`	按账号 + 渠道 + 发送人隔离（多账号场景推荐）

💡 如果同一个人通过好几个渠道找你的 Agent，可以用 session.identityLinks 把不同渠道的身份绑在一起，合并成一个会话。

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

三条隔离路线：软隔离、沙箱（Sandbox）、多网关

到现在为止，咱们搞定的配置属于软隔离——也就是多个 Agent 跑在同一个 Gateway 进程里，Workspace 和 Session 各过各的，但文件系统层面上没啥硬墙挡着。

对大多数个人用户和小团队来说，这就够用了。但随着场景变复杂，你可能需要更狠的隔离手段。先看决策树：

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

OpenClaw 提供了三个档次，每一档解决的问题都不一样：

方案	隔离程度	资源消耗	适用场景
软隔离	君子协定（共享进程）	低	个人、小团队、相互信任的环境
Docker Sandbox	容器级（文件系统 + 进程隔离）	中	防着工具乱来、处理敏感数据
多 Gateway	进程级（彻底分家）	高	企业级、高可用、安全要求极高的场景

软隔离的甜头和风险

甜头很明显：配置简单，省资源。每个 Agent 都有独立的 Workspace 和记忆，上下文不会串。Agent 之间甚至还能通过 sessions_send 工具互发消息（当然得显式开启 tools.agentToAgent）。

风险也得摊开了说：这属于“君子协议”。同一个进程里的 Agent，技术上完全可以通过绝对路径去翻其他 Agent 的 Workspace。在信任环境里这不算事儿——你自己的 Agent 不会闲着没事搞破坏。但如果你要对外提供服务或者处理敏感数据，那就得往下看了。

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

Sandbox：把工具执行关进笼子（容器）里

这儿有个很多人容易弄混的概念，咱们其实提过一嘴：OpenClaw 治理工具副作用有三道闸——sandbox、tool policy、elevated。今天主要把 sandbox 这道闸讲透。

先纠正个误区：Sandbox ≠ 把 Gateway 塞进 Docker。

Sandbox 的意思是：Gateway 还是老老实实跑在宿主机上，但是 Agent 执行工具的时候（比如 exec、read、write、edit 这些），全都扔进 Docker 容器里去跑。这样哪怕模型犯傻了——比如想删库跑路或者偷看敏感文件——破坏范围也被死死锁在容器里头。

最小化启用

{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",       // off | non-main | all
        scope: "session",       // session | agent | shared
        workspaceAccess: "none", // none | ro | rw
      },
    },
  },
}

三个参数啥意思：

mode 决定啥时候进沙箱。non-main 是看 session.mainKey——群聊和频道的 session key 跟 mainKey 不一样，所以它们进沙箱，而你的私人对话不受影响。这对大多数场景来说是最合理的默认值。

scope 决定笼子的大小。session 隔离最彻底，一个会话一个容器；agent 一个 Agent 一个容器，适合需要在容器里跨会话共享状态的情况；shared 全局共用一个容器，省资源但隔离性最差。

workspaceAccess 决定沙箱能看见啥。none 是最安全的默认值——沙箱里的工具只能在容器里面折腾。如果你需要 Agent 在沙箱里读取宿主 Workspace 的文件（比如查阅文档），可以设成 ro（只读）。
手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

每个 Agent 可以单独“开小灶”

你没必要把所有 Agent 都关进沙箱。比如你自己的私人 Agent 可以不设防，但给家里人用的 Agent 就全程沙箱伺候，还要把权限收紧：

{
  agents: {
    list: [
      {
        id: "personal",
        workspace: "~/.openclaw/workspace-personal",
        sandbox: { mode: "off" },
      },
      {
        id: "family",
        workspace: "~/.openclaw/workspace-family",
        sandbox: {
          mode: "all",
          scope: "agent",
        },
        tools: {
          allow: ["read", "exec", "sessions_list", "sessions_send"],
          deny: ["write", "edit", "apply_patch", "browser", "canvas"],
        },
      },
    ],
  },
}

启用之前得先把沙箱镜像构建好：

# 基础镜像
scripts/sandbox-setup.sh

# 需要常用工具（curl、jq、nodejs、python3、git）时用这个
scripts/sandbox-common-setup.sh

⚠️ 默认的沙箱容器是没网的（docker.network 默认是 "none"）。如果 Agent 需要在沙箱里上网，得显式设置网络。另外，setupCommand 只在容器创建后跑一次，可以用来装点额外的依赖，但注意这也需要网络和 root 权限。

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

多 Gateway：进程级硬隔离

官方的态度很明确：绝大多数情况，跑一个 Gateway 就够够的了。 一个 Gateway 完全能罩得住多个渠道连接和多个 Agent。

但如果你确实需要更强的隔离或者搞个备份——比如跑一个救援机器人（rescue bot），主 Gateway 挂了还能用它来查错——那可以在同一台机器上跑多个实例。

关键限制：下面这些资源每个实例必须独一份，否则肯定打架：

• OPENCLAW_CONFIG_PATH（配置文件）
• OPENCLAW_STATE_DIR（状态目录）
• agents.defaults.workspace（工作目录）
• gateway.port（端口，间隔至少留 20，免得派生端口冲突）

最省心的办法是用 profiles：

openclaw --profile main onboard
openclaw --profile main gateway --port 18789

openclaw --profile rescue onboard
openclaw --profile rescue gateway --port 19789

Profiles 会自动把状态目录和配置路径隔离开，还会给后台服务名加个后缀。安装成后台服务也是一行命令的事儿：

openclaw --profile main gateway install
openclaw --profile rescue gateway install

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

远程访问：别直接裸露端口

如果你的 Gateway 是跑在远程服务器上的，咋访问也是个实战问题。

Gateway 的 WebSocket 默认绑定在本地回环地址（127.0.0.1:18789），这是为了安全。远程访问推荐走这路子：

# SSH 隧道（最简单）
ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

或者走 Tailscale VPN，如果你已经在用了，直接访问就行。

如果你非得绑定非 loopback 地址——那必须启用认证（gateway.auth.token 或 gateway.auth.password）。不带认证直接暴露端口，那就等于把 Agent 的执行权限拱手送给了全互联网。

配置热重载：不用动不动就重启

有个细节值得单拎出来说：OpenClaw 的 Gateway 会自动盯着配置文件变没变。默认的热重载模式是 hybrid——能热更新的改动直接生效，需要重启的改动它自己会触发重启。

`gateway.reload.mode`	行为
`off`	不自动重载
`hot`	只应用能热更新的变动
`restart`	稍微动一下就触发重启
`hybrid`（默认）	能热更就热更，不行再自动重启

这意味着你加个 binding、改个 dmScope，大部分时候不用手动去重启。但万一出了岔子，用 openclaw doctor 查个体检是个好习惯。

手把手教你一键部署OpenClaw，连接微信、QQ、飞书、钉钉等，1分钟全搞定！

选型速查表

拿不准自己该用哪种方案？对着这个表做选择题就行：

你的情况	推荐方案
刚上手，就一个人	单 Agent，先跑通再说
用了一阵子，记忆串台了	多 Agent 软隔离
小团队协作，环境可信	多 Agent 软隔离 + `dmScope`
要处理敏感数据	Docker Sandbox
对外提供服务 / 多租户	多 Gateway
要高可用 / 救急能力	多 Gateway + rescue profile