OpenClaw学习总结_I_核心架构_9：Multi-Agent详解

I. 核心架构 - 9. Multi-Agent

📍 课程位置

阶段：I. 核心架构
课序：第 9 课
前置知识 ：I-8. Session Pruning
后续课程：I-10. Sandboxing

🎯 本课核心问题（你不懂我就这样教你）

很多人第一次接触 OpenClaw 会有这些疑问：

我能不能让一个 OpenClaw 同时服务"工作"和"生活"两个场景？（不要互相串消息）
能不能让不同的人/不同群/不同渠道走不同的 Agent？
凭证（API Key）、工作目录、记忆、Session 能不能完全隔离？

答案是：可以，这就是 Multi-Agent（多 Agent）。

一句话：

Multi-Agent = 在同一个 Gateway 下运行多个"彼此隔离"的 Agent，并用 bindings 把不同来源的消息路由到不同 Agent。

🧠 你先建立正确的心智模型

1）Gateway 只有一个，Agent 可以有多个

Gateway：消息/路由/控制中枢（你机器上跑的那个）
Agent：处理对话与工具调用的"工作单元"

类比：

Gateway 像"前台总机"
Agent 像"不同部门的客服/专家"

2）Multi-Agent 的价值不是"多几个机器人"，而是"隔离"

隔离的对象包括：

Workspace（文件/项目）
Sessions（对话历史）
Memory（长期记忆）
Credentials（模型/渠道凭证）
Tools Policy（允许用哪些工具）
Sandboxing（是否跑在容器中）

🧩 Multi-Agent 由两块组成

A. agents.list：定义有哪些 Agent

你在配置里声明多个 Agent，每个 Agent 可以有：

id
workspace
model
tools policy
sandbox policy

示例（最常见：work + home）：

json5 复制代码

{
  agents: {
    list: [
      { id: "home", default: true, workspace: "~/.openclaw/workspace-home" },
      { id: "work", workspace: "~/.openclaw/workspace-work" },
    ],
  },
}

default: true 表示当没有任何 binding 命中时，默认走 home（或你设置的默认 Agent）。

B. bindings：定义"什么消息走哪个 Agent"

bindings 是路由规则。它们按优先级匹配，命中就决定目标 Agent。

示例（按账号/渠道分流）：

json5 复制代码

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

🧭 路由优先级（绑定匹配规则）

你最需要掌握的一点：OpenClaw 的 Multi-Agent 路由是确定性的（deterministic）。

它会按照"更具体 → 更泛化"的顺序去匹配（你的 binding 越具体，越优先）。

常见的匹配维度（从强到弱的大概思路）

peer / parentPeer（具体到某个对话对象或上级身份）
guildId + roles（Discord 这类）
guildId / teamId
accountId（同平台不同账号）
channel（平台）
default（默认 Agent）

你可以把它理解成：

先看"是不是这个人/这个群"，再看"是不是这个账号"，再看"是不是这个平台"，最后才用默认。

🔐 隔离到底隔离了什么？（work/home 不串线的根源）

1）Workspace 隔离

不同 Agent 指向不同 workspace：

home 的文件、笔记、任务都在 workspace-home
work 的文件、代码、记录都在 workspace-work

好处：

不会出现"工作 Agent 在生活目录里乱改文件"
项目依赖/脚本/技能也可以不同

2）Sessions 隔离

每个 Agent 自己维护会话文件（jsonl）。

好处：

work Agent 不会看到 home 的对话历史
多人 DM 也更安全

3）Credentials 隔离（最关键之一）

凭证可按 Agent 存放。

好处：

work Agent 用公司模型 key
home Agent 用个人模型 key
互不影响，便于轮换和权限最小化

4）Tools/Sandbox 隔离

你可以让：

work Agent 允许 exec/git/browser
home Agent 只允许 messaging + web_fetch

这样就算 prompt injection 也很难造成破坏。

🛡️ 多用户场景的安全关键：dmScope

Multi-Agent 解决的是"不同场景走不同 Agent"。

但同一个 Agent 内部，多人私聊仍然可能串------这由 Session 的 dmScope 决定。

🔧 三个最常用的 Multi-Agent 实战配方

配方 1：按平台分流

Telegram → work
WhatsApp → home

json5 复制代码

{
  agents: { list: [
    { id: "home", default: true, workspace: "~/.openclaw/home" },
    { id: "work", workspace: "~/.openclaw/work" },
  ] },
  bindings: [
    { agentId: "work", match: { channel: "telegram" } },
    { agentId: "home", match: { channel: "whatsapp" } },
  ],
}

配方 2：按账号分流（同平台多账号）

json5 复制代码

{
  bindings: [
    { agentId: "work", match: { channel: "feishu", accountId: "corp" } },
    { agentId: "home", match: { channel: "feishu", accountId: "personal" } },
  ],
}

配方 3：按具体人/群分流（最精确）

json5 复制代码

{
  bindings: [
    { agentId: "work", match: { peer: "user:ou_xxx" } },
    { agentId: "home", match: { peer: "whatsapp:+1555..." } },
  ],
}

⚠️ 常见陷阱（非常重要）

陷阱	表现	根因	解决
binding 不生效	全走 default	match 写错/太泛	用更具体的 match；检查 channel/accountId/peer
误路由	某些群进错 Agent	优先级理解错误	让更具体的规则排在更高优先级；减少冲突
仍然串对话	不同用户互相影响	dmScope 太粗（main/per-peer）	用 per-channel-peer
凭证污染	work key 被 home 用	没做 per-agent auth	分离 auth profiles/credentials
工具风险	home Agent 乱 exec	tools policy 没隔离	home 用最小工具集 + sandbox

📝 学习心得

Multi-Agent 这章最容易被误解成"多开几个机器人"。

但真正的价值在于：

隔离（工作/生活/不同用户）
最小权限（不同 Agent 不同工具/不同 key）
可控路由（bindings 决定谁处理哪类消息）

只要你掌握：

agents.list 定义 Agent
bindings 决定路由
dmScope 保证 DM 安全

你就能在不乱搞的情况下，把系统搭成"生产可用"。

✅ 本课总结（你要记住的 5 句话）

一个 Gateway，可以跑多个 Agent。
Multi-Agent 的本质是隔离，不是数量。
bindings 决定"什么消息给谁处理"，越具体越优先。
多用户私聊必须配 dmScope（推荐 per-channel-peer）。
不同 Agent 应隔离 workspace/credentials/tools，避免串线和安全事故。

🔗 相关资源

官方文档：Multi-Agent：https://docs.openclaw.ai/concepts/multi-agent
Session（dmScope）：https://docs.openclaw.ai/concepts/session
配置参考（agents/bindings）：https://docs.openclaw.ai/gateway/configuration-reference

下一课：I-10. Sandboxing（用容器把风险再锁一层）