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

先想象一下：一个公司里，如果只有一个员工，又要接客户电话、又要写代码、还要修打印机、顺便管管财务……这个人迟早会疯。多个 Agent 也是同理——不是凑数，是让专业的人干专业的事。

本章的目标很单纯：帮你判断什么时候该拆、怎么拆才不乱。放心，我们不搞虚的，最后你会拿到一套能直接上手的配置。

本章你将学会什么

判断单 Agent 什么时候不够用，得请”帮手”了。
给每个 Agent 安排独立的”办公室”（workspace），互不打扰。
按职责而不是按”性格”给 Agent 分配角色。
用 bindings 做好”分诊台”，让请求精准找到对应的 Agent。
避开几个新手容易踩的坑。

读者前置

你已经跟着前 12 章走完了基础流程。
你可以执行下面两个命令，确认自己的环境能跑：

# 看看当前有哪些 Agent，bindings 配置是啥
openclaw agents list --bindings

# 看看当前 Agent 的配置情况
openclaw config get agents

如果这两个命令都能正常输出一堆信息，说明你准备好了。

13.1 什么时候需要拆分

13.1.1 四个”该拆”信号

出现下面任意两项，就可以考虑拆分了：

信号	大白话解释
同一 Agent 同时承担”业务答复 + 运维执行”	一个人既当客服又当运维，权限太大，出事风险高。
不同对话对象需要不同权限级别	有的用户只能看不能改，有的用户能执行危险操作，不能混用。
同一 workspace 被多类任务频繁污染	客服聊着聊着，突然跑出来运维的日志，把上下文搞乱了。
一处配置变更经常影响无关场景	改个聊天机器人的提示词，结果把部署脚本搞崩了。

一句话总结：如果你的 Agent 开始”身兼数职”，而且经常”城门失火，殃及池鱼”，就是该拆了。

13.1.2 两个”不该拆”信号

反过来，下面两种情况，先别急着拆：

你只是想”试试看多 Agent”
新鲜感过了就想拆着玩，最后留下一堆没人维护的配置，得不偿失。
当前单 Agent 连稳定都没做到
连一个 Agent 都跑不稳当，拆成多个只会更乱。先把基础打牢。

记住：拆分是为了降低复杂度，不是为了增加复杂度。

13.1.3 拆分目标要先写清楚

正式拆之前，建议你拿张纸（或者写个文档），先写清楚一句话目标：

“这个 Agent 只负责什么，不负责什么。”

这句话看起来简单，但它会决定：

给它配什么工具（后面会讲）
走哪条路由（后面会讲）
出错了找谁（责任边界）

13.2 多 Workspace 的组织方式

先解释一下 workspace 是什么——你可以把它想象成 Agent 的”独立办公室”。每个 Agent 有自己的办公桌、文件柜，互相不抢东西。

13.2.1 每个 Agent 一套 workspace

官方推荐的做法是：一个 Agent，一个独立 workspace。

好处很明显：

上下文不串台（客服的聊天记录不会混进运维的日志）
回滚方便（想撤回某个 Agent 的改动，不会影响到其他 Agent）
权限边界清晰（每个 Agent 只能访问自己的文件夹）

怎么配？看下面的例子：

{
  agents: {
    list: [
      // 客服 Agent，有自己的独立办公室
      { id: "chat", workspace: "~/.openclaw/workspace-chat" },
      // 运维 Agent，也有独立的办公室
      { id: "ops", workspace: "~/.openclaw/workspace-ops" },
    ],
  },
}

注意：这里的 ~/.openclaw/workspace-chat 就是个文件夹路径，你可以理解成”C盘/D盘/某某文件夹”。

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

有些技能是”公共资源”，所有 Agent 都能用；有些技能是”私有财产”，只有特定 Agent 能用。

存放位置	谁能用到
`<workspace>/skills`	只有这个 Agent 自己
`~/.openclaw/skills`	所有 Agent 都能用

如果两边放了同名技能怎么办？** workspace 里的优先**——相当于”本地文件覆盖全局配置”。

举个例子：公共技能库里有个”发送邮件”，大家都用；但客服 Agent 需要一个”特殊版发送邮件”，那就在它的 workspace 里放一个同名文件，客服 Agent 会用自己办公室里的版本。

13.2.3 备份策略按 workspace 拆分

不要把所有 Agent 的 workspace 混在一个大文件夹里备份。

推荐做法：

一个 Agent 一个私有仓库（如果你用 Git 的话）
或者至少 一个 Agent 一个独立目录，分别做备份

这样哪个 Agent 出问题，单独恢复那个目录就行，不用全员回滚。

13.3 多 Agent 的角色划分

这一节聊聊怎么给 Agent “定岗位”。记住一个原则：按权限划分，而不是按”性格”。别想着造一个”温柔型 Agent”或者”幽默型 Agent”，重点是它能干什么、不能干什么。

13.3.1 推荐三类角色

角色类型	职责	风险等级
对话型 Agent	负责和用户聊天、回答问题、处理咨询	低风险（只读、低权限操作）
执行型 Agent	允许执行一些实际操作，但需要审批	中高风险
巡检型 Agent	只读、排障、生成报告	低风险（纯观察，不动手）

就像公司里有”前台客服”、“运维工程师”、“审计员”三种岗位，各干各的，互不越权。

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

配置示例：

{
  agents: {
    list: [
      // 对话型：只给"消息处理"工具
      { id: "chat", tools: { profile: "messaging" } },
      // 执行型：给" coding "工具，但禁用" web "相关操作
      { id: "ops", tools: { profile: "coding", deny: ["group:web"] } },
    ],
  },
}

这里的 profile 可以理解成”工具套餐”——就像点外卖时选”经济套餐”还是”豪华套餐”。

13.3.3 沙箱策略要跟角色绑定

先解释 沙箱（sandbox）：你可以把它想象成”隔离实验室”。Agent 在里面怎么折腾都行，但影响出不了实验室门。

角色	推荐沙箱策略
对话型（chat）	`workspaceAccess: none` —— 别让它碰文件，老实聊天就行
执行型（ops）	`workspaceAccess: ro`（只读）或者审批后 `rw`（可写）
巡检型	`workspaceAccess: ro` —— 只能看，不能改

原则：权力越大，责任越大，但隔离也要越严格。危险操作必须关在”笼子”里。

13.4 路由策略（最小可用）

先解释 路由（routing）：就是”分诊台”。用户发来一条消息，路由决定这条消息该交给哪个 Agent 处理。

13.4.1 确定性路由的匹配顺序

OpenClaw 的 bindings 按顺序匹配——先命中先执行。

这就意味着：

具体规则放前面（比如”飞书来的消息交给飞书客服”）
通用规则放后面（比如”其他都交给默认客服”）

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

{
  agents: {
    list: [
      // 默认 Agent兜底
      { id: "main", default: true, workspace: "~/.openclaw/workspace-main" },
      // 专门处理飞书的 Agent
      { id: "feishu-support", workspace: "~/.openclaw/workspace-feishu" },
    ],
  },
  bindings: [
    // 规则1：飞书渠道 → 飞书客服
    { agentId: "feishu-support", match: { channel: "feishu" } },
    // 规则2：其他所有渠道 → 默认客服
    { agentId: "main", match: { channel: "*" } },
  ],
}

解释一下：

match: { channel: "feishu" } 意思是”如果消息来自飞书渠道”
match: { channel: "*" } 意思是”其他所有渠道”
default: true 意思是”如果前面都没命中，就交给这个 Agent”

就像医院分诊台：先问”你是看内科还是外科”，然后内科的进内科，妇产科的进妇产科，其他的去急诊。

13.4.3 路由上线后必做验证

配置写好了，别急着上线。先跑两行命令压压惊：

# 看看 bindings 配置是否生效
openclaw agents list --bindings

# 看看所有 Agent 的状态
openclaw status --all

如果输出显示”飞书消息会走 feishu-support，其他走 main”，说明配置没问题。

最后一步：发一条真实的测试消息，走一遍完整流程，确认真的命中了预期的 Agent。

13.5 反模式清单

这节聊聊新手容易踩的坑。提前知道，能少走弯路。

13.5.1 常见反模式

反模式	什么问题	怎么改
一个渠道绑多个默认 Agent	靠”碰运气”命中，谁有空谁接，容易乱套	明确一个默认 Agent，其他走 bindings
高低风险 Agent 共用宽权限	低风险 Agent 误操作高风险功能，出大事	按角色严格划分工具和沙箱策略
所有业务塞进共享 workspace	上下文互相污染，排障时找不到北	一个 Agent 一个独立 workspace

13.5.2 你会看到的坏结果

如果上面这些反模式你全中了，可能会遇到：

上下文串台：客服 Agent 突然蹦出一句运维日志
权限越权：本该只读的执行型 Agent 偷偷删了文件
排障定位困难：出错了不知道是哪条路由生效的，也不知道该找哪个 Agent

13.5.3 替代做法

记住这三句口诀：

先定默认，再做特例——先有一个兜底的默认 Agent，特殊情况用 bindings 单独处理
每个 Agent 明确工具和沙箱——能干什么、不能干什么，写得清清楚楚
路由上线立即验证——别偷懒，发条测试消息确认一下

本章小结

来，回顾一下本章的要点：

多 Agent 不是为了炫技，是为了隔离风险、让职责边界更清晰。
Workspace 就是每个 Agent 的独立办公室，不要混用。
按权限划分角色（对话型 / 执行型 / 巡检型），而不是按”性格”。
路由用 bindings，具体规则放前面，默认规则放后面。
上线前务必验证，别让自己的配置成为”薛定谔的路由”。

下一章我们会聊聊更高级的话题——怎么监控多 Agent 的运行状态，以及出了问题怎么快速定位。继续加油！