Skip to content
OpenClaw 书稿预览

进阶：多 Workspace、多 Agent 与路由策略（入门友好版）

多 Agent 的价值，不是“看起来很高级”，而是让职责边界清晰、故障影响可控。
本章的目标是：帮你判断什么时候该拆，怎么拆才不乱。

本章你将学会什么

Section titled “本章你将学会什么”
  • 判断单 Agent 何时不再适用。
  • 设计多 workspace 目录与权限边界。
  • 按职责而不是“人格幻想”拆分 Agent。
  • 用 bindings 做最小可用路由。
  • 避免常见反模式（过度拆分、共享污染、策略冲突）。

读者前置

Section titled “读者前置”
  • 你已完成前 12 章内容。
  • 你可以执行：
Terminal window
openclaw agents list --bindings
Terminal window
openclaw config get agents

13.1 什么时候需要拆分

Section titled “13.1 什么时候需要拆分”

13.1.1 四个“该拆”信号

Section titled “13.1.1 四个“该拆”信号”

出现以下任意两项，就建议拆分：

  1. 同一 Agent 同时承担“业务答复 + 运维执行”；
  2. 不同对话对象需要不同权限级别；
  3. 同一 workspace 被多类任务频繁污染；
  4. 一处配置变更经常影响无关场景。

13.1.2 两个“不该拆”信号

Section titled “13.1.2 两个“不该拆”信号”
  • 你只是想“试试看多 Agent”；
  • 当前单 Agent 连稳定都没做到。

先把单 Agent 跑稳，再拆，成本最低。

13.1.3 拆分目标要先写清楚

Section titled “13.1.3 拆分目标要先写清楚”

每个 Agent 上线前先写一句话目标：
“这个 Agent 只负责什么，不负责什么。”

这句话决定了后续工具策略、路由规则、审批方式。

13.2 多 Workspace 的组织方式

Section titled “13.2 多 Workspace 的组织方式”

13.2.1 每个 Agent 一套 workspace

Section titled “13.2.1 每个 Agent 一套 workspace”

官方建议多 Agent 使用隔离 workspace。
好处是：上下文与技能互不污染，回滚边界清晰。

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

13.2.2 共享技能与专属技能并存

Section titled “13.2.2 共享技能与专属技能并存”
  • 专属技能：<workspace>/skills
  • 共享技能：~/.openclaw/skills

同名时 workspace 优先。
这能实现“公共工具包 + 业务私有技能”组合。

13.2.3 备份策略按 workspace 拆分

Section titled “13.2.3 备份策略按 workspace 拆分”

不要把多个 Agent 的 workspace 混在一个仓库。
推荐一个 Agent 一个私有仓库（或至少一个目录级独立备份策略）。

13.3 多 Agent 的角色划分

Section titled “13.3 多 Agent 的角色划分”

13.3.1 角色按权限划分，而不是按“性格”

Section titled “13.3.1 角色按权限划分，而不是按“性格””

推荐三类：

  • 对话型 Agent：偏消息处理，低风险工具；
  • 执行型 Agent：允许部分 runtime，但强审批；
  • 巡检型 Agent：只读、排障、报告生成。

13.3.2 每个角色配一套工具集合

Section titled “13.3.2 每个角色配一套工具集合”

示例：

{
  agents: {
    list: [
      { id: "chat", tools: { profile: "messaging" } },
      { id: "ops", tools: { profile: "coding", deny: ["group:web"] } },
    ],
  },
}

13.3.3 沙箱策略要跟角色绑定

Section titled “13.3.3 沙箱策略要跟角色绑定”
  • chat：workspaceAccess: none
  • ops：workspaceAccess: ro 或严格审批后 rw

原则：角色越危险，隔离越严格。

13.4 路由策略（最小可用）

Section titled “13.4 路由策略（最小可用）”

13.4.1 先做确定性路由

Section titled “13.4.1 先做确定性路由”

bindings 按顺序匹配，先命中先执行。
所以要把“最具体规则”放前面。

13.4.2 一个可执行的最小路由例子

Section titled “13.4.2 一个可执行的最小路由例子”
{
  agents: {
    list: [
      { id: "main", default: true, workspace: "~/.openclaw/workspace-main" },
      { id: "feishu-support", workspace: "~/.openclaw/workspace-feishu" },
    ],
  },
  bindings: [
    { agentId: "feishu-support", match: { channel: "feishu" } },
    { agentId: "main", match: { channel: "*" } },
  ],
}

13.4.3 路由上线后必做验证

Section titled “13.4.3 路由上线后必做验证”
Terminal window
openclaw agents list --bindings
Terminal window
openclaw status --all

并做一次真实消息闭环验证，确保命中预期 Agent。

13.5 反模式清单

Section titled “13.5 反模式清单”

13.5.1 常见反模式

Section titled “13.5.1 常见反模式”
  1. 一个渠道绑多个默认 Agent，靠“碰运气命中”；
  2. 高风险 Agent 与低风险 Agent 共用一套宽权限策略；
  3. 把所有业务都塞进共享 workspace。

13.5.2 你会看到的坏结果

Section titled “13.5.2 你会看到的坏结果”
  • 上下文串台；
  • 权限越权；
  • 排障定位困难（不知道哪条路由生效）。

13.5.3 替代做法

Section titled “13.5.3 替代做法”
  • 先定“默认 Agent + 特例绑定”；
  • 每个 Agent 明确工具策略与沙箱策略；
  • 每条路由上线后立即做可观测验证。

本章小结

Section titled “本章小结”
  • 多 Agent 不是为了复杂，而是为了隔离与可维护。
  • workspace、工具、沙箱、路由必须成套设计。
  • 先做最小确定性路由，再逐步细化，不要一步到位搞复杂矩阵。