夜雨聆风刚把 OpenClaw 跑起来时，喜欢把所有事都塞给一个 Agent：写作、客服、群聊、自动化、资料整理，全都往里堆。
一开始没问题，后面就会越来越别扭。它记住的东西太杂，回答开始串味；历史越来越长，token 也跟着往上飙。到最后，一个本来很简单的问题，也要拖着一大串无关上下文一起进模型。
所以，多 Agent 不是可有可无的锦上添花，而是 OpenClaw 一旦进入实战，迟早要补上的那一步。
多 Agent 到底在隔离什么
在 OpenClaw 里，Agent 不是换个名字那么简单。一个独立 Agent，通常对应的是一套独立运行单元：
独立 workspace 独立 session 可单独指定模型 可被不同 binding 路由
可以把它理解成一个小团队：主 Agent 负责总控，其他 Agent 各管各的活。写作的别掺进客服记忆，群聊的别污染私聊上下文，做自动化的也别把日常聊天历史背在身上。
多 Agent 的价值，说到底就两个字：隔离。
什么时候该拆出第二个 Agent
只要你开始遇到下面几种情况，就别硬撑一个 Agent 了：
不同业务场景混在一起，比如“写内容”和“做客服”共用一个脑子 不同群组需要不同人格、规则或技能 某些记忆只能留在局部，不能扩散到主 Agent 某类任务必须绑定特定模型 你希望某个群、某个频道有专属的 AI 成员
判断标准其实很简单：
只要你开始觉得“这段上下文不该被别的场景看见”，就该拆。
配多个 Agent，真正关键的只有 3 层
别一看到配置就头大。真正决定多 Agent 能不能跑起来的，核心就这 3 层。
1. Agent 本身
先把 Agent 定义出来。至少要清楚三件事：
idworkspacemodel（可选）
这一步相当于先把“成员”建出来。
2. bindings 路由规则
bindings 决定什么消息进哪个 Agent。
例如：
某个飞书群进 feishu-writer某个 Discord 频道进 discord-ops某个账号或角色进 support-agent
这一步决定的是路由，不是风格，不是模型，而是入口命中后到底交给谁处理。
3. 频道访问策略
就算 binding 配对了，消息也不一定能进来。很多时候卡住的是 policy。
常见要看的有：
groupPolicygroupAllowFrom各渠道自己的 allowlist 配置
可以把逻辑记成一句话：
binding 决定交给谁，policy 决定放不放行。
最稳的结构：主 Agent 管私聊，群组各自绑定独立 Agent
如果不想一开始把系统搞得太复杂，最稳的方案就是这一种：
主 Agent 继续处理默认私聊 内容群绑定内容 Agent 运营群绑定运营 Agent 技术群绑定技术 Agent
这样做有几个很现实的好处：
私聊不会被群聊记忆污染 每个群都有自己的长期上下文 不同群可以配不同模型、不同技能、不同风格 出问题时更容易排查
这套结构不花哨，但特别适合长期跑。
实操怎么做
下面按最短路径来讲。
第一步：创建一个新 Agent
命令示意：
openclaw agents add --workspace /path/to/workspace-your-agent your-agent-id
例如：
openclaw agents add --workspace ~/.openclaw/workspace-feishu-writer feishu-writer
这里真正值得认真想一下的是命名。
workspace 最好一眼能看出用途，agent id 最好稳定、短、不要乱改。像下面这种就很清楚：
feishu-writerdiscord-opssupport-cncontent-research
建完以后，可以用下面命令确认：
openclaw agents list
第二步：决定它要不要单独模型
如果你不配模型，它一般会沿用默认模型。
但实际使用里，不同 Agent 适合干不同的活。
写作 Agent 适合长文表达更强的模型 代码 Agent 适合 coding 模型 办公或表格 Agent 更适合结构化能力强的模型
示意命令：
openclaw agents add \
--workspace ~/.openclaw/workspace-feishu-writer \
--model openai-codex/gpt-5.3-codex \
feishu-writer
如果 Agent 已经建好了，后续再调模型也行，不一定非得一步到位。
第三步：把入口路由到这个 Agent
一个典型的 bindings 规则长这样：
[
{
"agentId": "feishu-writer",
"match": {
"channel": "feishu",
"peer": {
"kind": "group",
"id": "oc_xxx_group_id"
}
}
}
]
这段配置表达的意思很直接：
渠道是 feishu命中指定群组 命中后交给 feishu-writer
路由这一步决定的是“谁来处理”，不是“谁看起来更像在处理”。这个边界必须清楚。
第四步：小心 bindings 被整体覆盖
这是最多人踩的坑之一。
很多人执行类似下面的命令：
openclaw config set --json bindings '[ ... ]'
问题在于，这通常是整体写回，不是自动帮你追加。
如果你之前已经有其他绑定，比如 Telegram、Discord、别的群组入口，这次只写一条新规则，很可能顺手把旧配置全抹掉。
稳妥做法是：
先导出现有 bindings在原数组基础上追加新规则 再整体写回
这一步别图快。很多“怎么突然全失效了”的事故，就是这么来的。
第五步：检查群组访问策略
如果你接的是群组场景，还要确认消息有没有被策略挡在门外。
常见思路如下：
openclaw config set channels.feishu.groupPolicy allowlist
openclaw config set --json channels.feishu.groupAllowFrom '["oc_xxx_group_id"]'
这里不用死记字段名，只要记住逻辑：
groupPolicy=allowlist：默认收紧 groupAllowFrom：把允许访问的对象加进去
不同渠道的字段名会有差异，但思路大同小异。先让入口合法，再由 binding 把消息送到对应 Agent。
第六步：重启或重载 Gateway
配置写完后，要让 Gateway 重新加载：
openclaw gateway restart
然后检查状态：
openclaw gateway status
如果起不来，先看配置格式，再看日志，别一上来就怀疑 Agent 本身有问题。
一个最小可用示例
如果你现在要做的是“内容群 → 独立写作 Agent”，最小可用结构就是下面这三块。
Agent
agentId: feishu-writerworkspace: ~/.openclaw/workspace-feishu-writermodel: 可选，不配就走默认
Binding
{
"agentId": "feishu-writer",
"match": {
"channel": "feishu",
"peer": {
"kind": "group",
"id": "oc_xxx_group_id"
}
}
}
Policy
{
"channels": {
"feishu": {
"groupPolicy": "allowlist",
"groupAllowFrom": ["oc_xxx_group_id"]
}
}
}
这三块连起来，基本就能把一个群组稳稳送进独立 Agent。
怎么确认隔离真的生效了
别只看它会不会回复，要看它是不是进了对的 Agent。
最简单的验证有 3 个。
1. 先问 workspace
在群里问：
你当前的 workspace 是什么？
如果返回的是新 Agent 的 workspace，说明路由命中了。
2. 再去私聊问一次
在默认私聊里再问同样的问题。
如果返回的是主 Agent 的 workspace，说明群聊和私聊已经分开。
3. 做一条隔离记忆测试
例如先在群里说：
记住，我们团队内部把这个项目叫“北极星”。
然后去私聊问：
你记得我们项目代号是什么吗？
如果私聊答不上来，隔离就基本成立了。
最容易踩的 4 个坑
坑 1：Agent 建好了，但消息根本没路由过去
常见原因：
bindings没配对 agentId写错 peer.id写错 匹配条件不完整
坑 2：新绑定生效了，旧绑定全没了
常见原因：
直接整体写回 bindings写回时没带上旧规则
这个坑特别常见，而且一出就是整片路由一起掉。
坑 3：不是路由问题，是 policy 拦住了
典型症状就是群里完全没响应，或者表现很不稳定。
优先排查：
groupPolicygroupAllowFrom渠道级 allowlist 是否需要 @机器人
坑 4：路由隔离了，但职责边界没隔离
多 Agent 不等于自动安全。
你还要继续看：
它装了什么 skill 它能访问哪些目录 它允许做哪些外部动作
多 Agent 解决的是上下文和职责隔离，不会自动把权限治理也一并做完。
如果你要长期用，建议这样规划
别一上来建十几个 Agent。先从最稳的 3 类开始：
1. 主控 Agent
负责私聊、总控和轻量问答。
2. 内容 Agent
负责写作、选题、改稿、资料整理。
3. 执行 Agent
负责自动化、数据处理、表格和长流程任务。
后面再按职责继续往下拆：
content-researchcontent-writerops-botsupport-botdev-agent
先按职责拆，再按渠道拆，系统会清楚很多。
最后一条建议：先定义边界，再定义人格
很多人一配置多 Agent，第一反应是先想人设：这个温柔一点，那个毒舌一点，这个像产品经理，那个像 CTO。
这些都可以有，但优先级没那么高。
真正该先想清楚的是：
它负责什么 它不负责什么 它能访问什么
边界先立住了，后面的人格、语气、风格怎么加都行。
多 Agent 配对了，OpenClaw 会更像一个分工明确的系统，而不是一个什么都往里塞、越跑越糊的万能桶。
如果把这篇文章压缩成一句话，那就是：
多 Agent 的核心不是数量，而是隔离。