夜雨聆风多agent不是"一个不够用再来一个"那么简单。它至少有四种用法，每种解决不同问题。
很多人以为多agent协作就是"主agent带几个副agent干活"——主agent分配任务，子agent执行，结果汇总给主agent。
这个模式叫主从模式（Orchestrator-Worker），确实是多agent协作的一种。
但OpenClaw里的多agent能力，远不止这一种。
四种多agent用法
1. 路由模式：不同的人找不同的agent
最常见的多agent用法：不同渠道、不同人，自动路由到不同的agent。
比如：
WhatsApp来的消息 → 快速日常agent Telegram来的消息 → 深度工作agent 家庭WhatsApp群 → 家庭bot agent
配置是这样的：
{
agents: {
list: [
{ id: "chat", workspace: "~/.openclaw/workspace-chat" },
{ id: "deep", workspace: "~/.openclaw/workspace-deep" },
],
},
bindings: [
{ agentId: "chat", match: { channel: "whatsapp" } },
{ agentId: "deep", match: { channel: "telegram" } },
],
}
路由规则是最具体优先：
精确匹配（私信/群组ID） 渠道账户匹配 渠道级匹配 回退到默认agent
这种模式解决什么问题？一个网关服务，多个独立人格，互不干扰。家庭成员用家庭agent，工作的同事找工作agent，数据和人格完全隔离。
2. 子agent并行：不怕慢，就怕等
第二种模式：把耗时任务丢给子agent，主agent不等，继续处理其他事。
比如你要查十个竞品的信息，可以同时启动十个子agent并行查询，主agent继续回复用户消息。
等所有子agent完成，结果自动汇总到主agent，再统一输出。
这就是并行执行模式，核心价值是：不阻塞。
// 启动一个子agent执行耗时任务
sessions_spawn({
task: "帮我调研这10个竞品的技术栈，输出报告",
label: "竞品调研",
})
// 主agent继续响应用户，不等待
子agent完成后，会自动把结果推送回主agent的聊天窗口，用户感知到的是一个完整的报告，不知道背后有十个agent在并行工作。
3. 编排模式：一级管一级，结果往上报
第三种模式是嵌套子agent（maxSpawnDepth=2）。
主agent → 编排agent → 工作agent
编排agent负责任务分解，把工作分发给多个工作agent，收集结果，汇总后报告给主agent。
这个模式适合复杂任务拆分：
主agent接收用户请求 主agent启动一个编排agent 编排agent启动多个工作agent并行处理 工作agent完成后结果逐级上报
用户 → 主agent → 编排agent → 工作agent A（并行）
└→ 工作agent B（并行）
└→ 工作agent C（并行）
配置也很简单：
{
agents: {
defaults: {
subagents: {
maxSpawnDepth: 2, // 允许二级嵌套
maxChildrenPerAgent: 5, // 每个agent最多5个子任务
},
},
},
}
4. 隔离模式：沙箱里的agent，权限最小化
第四种模式关注的是安全隔离。
有时候你需要一个agent处理不可信的输入（比如外部用户的消息），这时候要把它放进沙箱，限制它能用的工具。
{
agents: {
list: [
{
id: "family",
sandbox: {
mode: "all", // 强制沙箱隔离
scope: "agent", // 每个agent独立容器
},
tools: {
allow: ["read", "sessions_list", "sessions_history"],
deny: ["write", "exec", "edit", "browser"],
},
},
],
},
}
这个agent：
运行在独立容器里 只能读取，不能写文件 不能执行命令 不能操作浏览器
好处：即使这个agent被攻击或者行为异常，也影响不到主机和其他agent。
为什么需要多agent？三个真实原因
说了这么多模式，可能还是有人问：为什么要用多agent？一个agent不够吗？
三个真实原因：
1. 效率：并行任务不等待
一个agent串行执行十个任务需要时间T×10。十个agent并行执行，时间接近T。
子agent模式解决的就是这个问题：耗时任务后台跑，主agent继续服务用户。
2. 安全：隔离不可信的输入
处理外部用户输入的agent，如果被沙箱隔离，即使它被攻陷，攻击者也只能在沙箱里玩，无法访问主机数据。
3. 人格隔离：不同场景，不同性格
工作用的agent和家用agent，应该有不同的记忆、不同的行为规则、不同的工具权限。
放在同一个agent里，规则会冲突，记忆会混淆。
多agent模式下，每个agent有独立的工作区（workspace）、独立的认证文件（agentDir）、独立的会话存储——真正的隔离。
配置多agent，你需要知道的关键参数
核心配置项
{
"agents": {
"list": [
{
"id": "agent-id", // 唯一标识
"workspace": "~/workspace", // 工作区路径
"agentDir": "~/.openclaw/agents/xxx/agent", // 认证目录
"default": true, // 是否默认agent
}
]
},
"bindings": [
{
"agentId": "agent-id",
"match": {
"channel": "whatsapp",
"accountId": "personal",
"peer": { "kind": "dm", "id": "+8613800138000" }
}
}
]
}
子agent关键参数
{
"agents": {
"defaults": {
"subagents": {
"maxSpawnDepth": 2, // 嵌套深度（1-5）
"maxChildrenPerAgent": 5, // 每agent最多子任务数
"maxConcurrent": 8, // 全局最大并发
"runTimeoutSeconds": 900, // 子agent超时时间
"archiveAfterMinutes": 60, // 多少分钟后自动归档
}
}
}
}
注意事项：这几个坑，踩了很麻烦
1. agentDir不要混用
每个agent的认证文件是独立的。如果两个agent共用同一个agentDir，会出现认证和会话冲突。
如果你想共享认证，把auth-profiles.json复制过去，而不是共享整个目录。
2. 子agent默认没有session工具
默认情况下，子agent不能使用sessions_list、sessions_history、sessions_send这些会话管理工具。
只有当maxSpawnDepth>=2时，编排agent才会获得这些权限，用于管理它的子agent。
3. 嵌套深度不是越大越好
OpenClaw支持最多5层嵌套（maxSpawnDepth范围1-5），但推荐使用2层。
嵌套越深，结果汇总越复杂，调试越困难，延迟越高。
4. 子agent的认证独立但有回退
子agent使用自己agentId的认证文件，但会合并主agent的认证作为回退。
这意味着子agent可以用主agent的凭证，但主agent的凭证冲突时，子agent优先用自己的。
5. 子agent结果推送是尽力而为
如果gateway重启，pending的"推送结果"任务会丢失。
对于重要任务，建议在子agent完成后，让主agent主动通过sessions_history拉取结果，而不是完全依赖推送机制。
结语：多agent是一种架构选择
多agent不是"一个agent不够用再加一个"的敷衍方案。
它是架构层面的设计选择——
想隔离安全边界？用沙箱agent 想并行加速？用子agent 想复杂任务分解？用编排模式 想多人格共存？用路由模式
搞清楚自己要解决什么问题，再选择对应的模式，比"先上了再说"要靠谱得多。
🚀 MiniMax Token Plan 惊喜上线！新增语音、音乐、视频和图片生成权益。邀请好友享双重好礼，助力开发体验！
好友立享 9折 专属优惠 + Builder 权益，你赢返利 + 社区特权！
👉 立即参与：
