夜雨聆风如果你在用 OpenClaw，迟早会碰到一个问题：
能不能把一个 Agent 变成一个“团队”？让它像小型组织一样，有协调者、有执行者、有研究员、有分析员，彼此分工、并行协作。
答案是：可以，而且不止一种方式。
但这里有一个很容易踩的坑：很多人一提“多 Agent 团队”，脑子里想的是“一个 CEO + 一堆员工”这种很酷的结构，结果一上来就把配置搞复杂了。实际落地时，更重要的不是“看起来像团队”，而是：
• 怎么分工最清晰 • 怎么控制上下文污染 • 怎么控制 token 成本 • 怎么保证权限和隔离 • 怎么真的能跑起来
这篇文章，我就把 OpenClaw 里多 Agent 团队协作的 4 种实现方式完整梳理一遍，并且尽量按“你可以照着操作”的标准来写。
文末我还会附上一份 数据采集团队版 openclaw.json 精简可上线样板，你可以直接改路径和模型就开干。
一、先理解：OpenClaw 里的“团队”到底是什么
在 OpenClaw 里，团队协作不是单一功能，而是几套能力的组合：
1. 多智能体路由（Multi-Agent Routing） 2. 子智能体（Subagents） 3. ACP 外部代理（Codex / Claude Code / Gemini CLI 等） 4. Agent-to-Agent 会话通信（sessions 工具族）
也就是说，OpenClaw 不是简单给你一个“团队开关”，而是给你几种组织方式。
先记住这个判断标准
• 要强隔离、不同人格、不同工作区、不同入口 → 用 多智能体路由 • 要主控 + 并行执行 → 用 Subagents • 要代码代理团队 → 用 ACP • 要让 Agent 之间直接传话、接力、查历史 → 用 Agent-to-Agent / sessions
这四种能力可以单独用，也可以混合用。
二、3 个基础概念，不搞清楚后面一定乱
1. Agent
一个 Agent 是一个独立“大脑”，通常有自己的：
• workspace • AGENTS.md• SOUL.md• USER.md• agentDir• 会话存储 • 认证配置
可以把它理解成一个完整独立的角色实例。
2. Binding
bindings 是路由规则。
它决定：
某条入站消息，到底应该送进哪个 Agent？
它可以基于这些维度匹配：
• channel• accountId• peer.id• guildId• teamId
3. Session
Session 是对话上下文，不等于 Agent。
一个 Agent 可以有很多 Session，比如：
• 一个主会话 • 多个用户会话 • 多个 thread 会话 • 多个 subagent 会话
所以要记住一句话：
Agent 是角色，Session 是对话实例。
三、方式 1：多智能体路由（Multi-Agent Routing）
这是最标准、最容易理解的一种多 Agent 组织方式。
它适合什么场景？
比如你希望：
• sales负责销售消息• support负责客服消息• scraper负责数据采集• research负责深度分析• reporter负责内容输出
每个 Agent：
• 用自己的 workspace • 有自己的 session • 用自己的模型 • 走自己的工具权限 • 接自己的消息入口
这时候就很适合用 多智能体路由。
核心配置结构
主要看两块：
agents.list
定义有哪些 Agent。
常用字段包括：
• id：唯一 ID• default：是否默认 Agent• workspace：工作区• agentDir：状态目录• model：默认模型• runtime：是否默认 ACP• tools：工具权限• sandbox：沙箱策略• subagents.allowAgents：允许拉起哪些子 Agent
bindings
定义消息如何路由到 Agent。
常用字段包括：
• agentId• type：默认route；ACP 持久绑定时用acp• match.channel• match.accountId• match.peer• match.guildId• match.teamId
路由优先级
OpenClaw 的绑定匹配是确定性的，优先级一般是：
1. match.peer2. match.guildId3. match.teamId4. match.accountId5. match.accountId: "*"6. 默认 Agent
一句话理解：
越具体的规则，优先级越高。
示例 1：按渠道分工
{ agents: { list: [ { id: "chat", default: true, workspace: "~/.openclaw/workspace-chat", model: "moonshot/kimi-k2.5" }, { id: "research", workspace: "~/.openclaw/workspace-research", model: "zai/glm-5" } ] }, bindings: [ { agentId: "chat", match: { channel: "whatsapp" } }, { agentId: "research", match: { channel: "telegram" } } ]}效果：
• WhatsApp → chat• Telegram → research
示例 2：同一渠道内按具体群/人分工
{ agents: { list: [ { id: "main", default: true, workspace: "~/.openclaw/workspace-main" }, { id: "scraper", workspace: "~/.openclaw/workspace-scraper" } ] }, bindings: [ { agentId: "scraper", match: { channel: "telegram", peer: { kind: "group", id: "-1001234567890" } } }, { agentId: "main", match: { channel: "telegram" } } ]}效果：
• 指定工作群 → scraper• 其他 Telegram 消息 → main
示例 3：一个 WhatsApp 号服务不同人，但每人独立 Agent
{ agents: { list: [ { id: "alex", workspace: "~/.openclaw/workspace-alex" }, { id: "mia", workspace: "~/.openclaw/workspace-mia" } ] }, bindings: [ { agentId: "alex", match: { channel: "whatsapp", peer: { kind: "dm", id: "+15551230001" } } }, { agentId: "mia", match: { channel: "whatsapp", peer: { kind: "dm", id: "+15551230002" } } } ]}这说明：
即使是同一个渠道账号，也可以把不同用户路由到不同 Agent。
实操流程
第一步：创建 Agent
openclaw agents add chatopenclaw agents add research第二步：查看 Agent
openclaw agents list --bindings第三步：编辑配置文件
改：
~/.openclaw/openclaw.json第四步：保存并验证
OpenClaw 很多配置支持热更新，通常不需要手工重启。
第五步：发消息测试
从不同渠道、不同群、不同私聊发消息，看是否进了正确 Agent。
这种方式的优点
• 隔离强 • 工作区清晰 • 人格和权限容易分开 • 适合多人、多入口、多业务线
它的不足
• 更像“静态组织架构” • 不负责动态并行执行 • 不负责自动拆任务
所以，很多人会把它和 Subagents 组合起来用。
四、方式 2：主 Agent + 子 Agent（Subagents）
这是真正最像“团队协作”的方式。
它适合什么场景？
当你给主 Agent 一个复杂任务时，它可以：
• 自己做规划 • 动态 spawn 几个后台子 Agent • 并行处理不同子任务 • 最后汇总结果
比如：
帮我调研 20 个竞品站点，抓取主页信息，整理成表，并给出分类建议。
这时候就非常适合：
• researcher去找目标• scraper去抓页面• cleaner去去重清洗• analyst去做结论• coordinator最后汇总
Subagents 的工作方式
子 Agent 是从当前 Agent 的执行中派生出来的后台运行。
它们：
• 运行在独立 Session 中 • 拥有自己的上下文 • 做完后会向请求者会话回报结果
典型 Session key 类似：
agent:<agentId>:subagent:<uuid>关键配置项
agents.defaults.subagents
{ agents: { defaults: { subagents: { model: "minimax/MiniMax-M2.5", maxConcurrent: 3, runTimeoutSeconds: 900, archiveAfterMinutes: 60 } } }}字段含义：
• model：子 Agent 默认模型• maxConcurrent：最大并发数• runTimeoutSeconds：运行超时• archiveAfterMinutes：归档时间
agents.list[].subagents.allowAgents
{ agents: { list: [ { id: "coordinator", subagents: { allowAgents: ["researcher", "scraper"] } }, { id: "researcher" }, { id: "scraper" } ] }}表示：
• coordinator可以拉起researcher和scraper• 默认不是任意都能拉 • allowAgents: ["*"]才是全开放
tools.subagents.tools.allow / deny
{ tools: { subagents: { tools: { deny: ["gateway", "cron"], allow: ["read", "write", "edit", "exec", "process", "web_fetch"] } } }}注意：
• deny优先级高于allow• 权限建议先小后大
实战示例：协调者 + 研究员 + 抓取员
{ agents: { defaults: { subagents: { model: "minimax/MiniMax-M2.5", maxConcurrent: 2, runTimeoutSeconds: 1200, archiveAfterMinutes: 60 } }, list: [ { id: "coordinator", default: true, workspace: "~/.openclaw/workspace-coordinator", model: "zai/glm-5", subagents: { allowAgents: ["researcher", "scraper"] } }, { id: "researcher", workspace: "~/.openclaw/workspace-researcher", model: "moonshot/kimi-k2.5" }, { id: "scraper", workspace: "~/.openclaw/workspace-scraper", model: "minimax/MiniMax-M2.5" } ] }, tools: { subagents: { tools: { deny: ["gateway", "cron"], allow: ["read", "write", "edit", "exec", "process", "web_fetch"] } } }}实际操作方式
方式 A：自然语言触发
你可以直接对 Agent 说：
• “把这个任务拆成两个子 agent 并行执行” • “spawn 一个 researcher 做调研，一个 scraper 去抓网页”
方式 B：用 /subagents
/subagents spawn researcher 调研 10 个竞品官网并总结差异/subagents spawn scraper 抓取这些官网的标题、描述和联系方式/subagents list/subagents info <id>/subagents log <id>/subagents steer <id> 补抓价格页和 API 文档页/subagents kill <id>Subagents 的优点
• 非常适合并行任务 • 不污染主会话上下文 • 可以用更便宜模型降成本 • 特别适合长任务和后台任务
它的限制
• 子 Agent 默认不能再继续 spawn 子 Agent • 回传是尽力而为，不是百分百强一致 • Gateway 重启时，部分未完成回传可能丢失 • 默认不给 session 工具族
一句建议
如果你只想先把“多 Agent 团队”跑起来，最优先建议上 Subagents。
因为它最像真正的协作团队，而且成本和复杂度都相对可控。
五、方式 3：ACP 外部 Agent 团队
如果你的团队协作偏工程、偏编码，那就不能只看 Subagents 了。
OpenClaw 支持通过 ACP runtime 接入外部代理，比如：
• Codex • Claude Code • Gemini CLI • OpenCode • 其他 ACP harness
ACP 适合什么任务？
比如你希望：
• 让 Codex 接管一个仓库持续改代码 • 让 Claude Code 在 thread 里长期跟进一个工程任务 • 让 Gemini CLI 做一段完整工具链执行
这时候，ACP 更适合。
Subagents 与 ACP 的区别
• Subagents：OpenClaw 原生后台代理 • ACP：外部 harness runtime
可以粗暴记成：
• 研究 / 抓取 / 清洗 / 总结 → Subagents • 编码 / 修仓库 / 长时 CLI 任务 → ACP
核心配置项
Agent 默认 runtime 走 ACP
{ agents: { list: [ { id: "codex", runtime: { type: "acp", acp: { agent: "codex", backend: "acpx", mode: "persistent", cwd: "/workspace/repo-a" } } } ] }}字段含义：
• type: "acp"：该 Agent 默认走 ACP• acp.agent：目标 harness• backend：ACP 后端• mode：persistent或oneshot• cwd：工作目录
用 bindings 做 ACP 持久绑定
{ bindings: [ { type: "acp", agentId: "codex", match: { channel: "discord", accountId: "default", peer: { kind: "channel", id: "222222222222222222" } }, acp: { label: "codex-main", cwd: "/workspace/repo-a" } } ]}这表示：
这个指定会话入口会持久绑定到一个 ACP session。
线程绑定支持
如果你要 thread/topic 持续跟随 ACP，需要开这些开关：
• acp.enabled = true• acp.dispatch.enabled = true• 渠道级 thread 绑定开关
例如：
{ acp: { enabled: true, dispatch: { enabled: true } }, session: { threadBindings: { enabled: true, idleHours: 24, maxAgeHours: 0 } }, channels: { discord: { threadBindings: { enabled: true, spawnAcpSessions: true } } }}实际操作方式
自然语言
• “用 Codex 在 thread 里持续处理这个仓库” • “把这个任务交给 Claude Code，保持持久会话”
sessions_spawn
概念上等价于：
{ "task": "Open the repo and summarize failing tests", "runtime": "acp", "agentId": "codex", "thread":true, "mode": "session"}/acp 命令
/acp spawn codex --mode persistent --thread auto/acp status/acp steer 继续修复剩余测试/acp cancel/acp close它适合哪类团队？
最适合：
• 工程协作团队 • 多仓库维护 • 编码执行型代理 • 技术支持与自动化开发
六、方式 4：Agent-to-Agent 会话通信
第四种方式不一定最显眼，但很重要。
它不只是 spawn，也不只是路由，而是：
一个 Agent 可以查看另一个会话、给另一个会话发消息、接力、追踪进展。
核心配置项
tools.agentToAgent
{ tools: { agentToAgent: { enabled: true, allow: ["coordinator", "researcher", "scraper"] } }}表示允许哪些 Agent 之间进行跨 Agent 会话操作。
tools.sessions.visibility
{ tools: { sessions: { visibility: "tree" } }}可选值：
• self：只看当前 session• tree：当前 session + 自己拉起的子 session• agent：当前 Agent 的所有 session• all：所有 session
注意：
即便
visibility: "all"，跨 Agent 也仍然需要agentToAgent许可。
它能干什么？
配合这些工具：
• sessions_list• sessions_history• sessions_send
可以实现：
• coordinator 看 worker 当前进展 • coordinator 给 worker 补充指令 • 一个 worker 接另一个 worker 的棒 • 某个任务在多个会话之间传递
典型适用场景
比如：
1. researcher先完成目标名单2. coordinator查看结果3. 再要求 scraper补抓缺失字段4. 最后 reporter汇总出可交付报告
这就像团队里的内部任务流转。
七、线程绑定：不是一种模式，但非常影响协作体验
严格说，它不是第五种模式，但它会让前面几种模式体验差很多或好很多。
它的作用
让某个 thread / topic / channel 持续绑定某个 subagent 或 ACP session。
常见配置
{ session: { threadBindings: { enabled: true, idleHours: 24, maxAgeHours: 0 } }, channels: { discord: { threadBindings: { enabled: true, spawnSubagentSessions: true, spawnAcpSessions: true } } }}字段含义：
• enabled：是否允许 thread binding• idleHours：多久没消息自动解绑• maxAgeHours：绑定最长寿命• spawnSubagentSessions：spawn subagent 时是否自动绑定• spawnAcpSessions：spawn ACP 时是否自动绑定
八、如果你是做数据采集，最推荐的团队结构是什么？
我最推荐的是下面这个结构：
• coordinator：任务拆解、调度、汇总• researcher：目标调研• scraper：抓取执行• cleaner：清洗整理• analyst：分析结论• reporter：输出交付
为什么这样拆？
因为数据采集工作天然就有这几个阶段：
1. 确定目标 2. 访问目标 3. 采到数据 4. 清理数据 5. 输出结论 6. 整理交付
OpenClaw 很适合按这个链条建 worker。
九、推荐落地组合：先别贪大，按这 3 层来
第一层：最先上
主协调 + Subagents
这是最实用、最划算的。
第二层：等业务清晰后再上
多智能体路由
当你确实需要：
• 不同入口 • 不同人格 • 不同 workspace • 不同客户或业务线
再引入静态路由。
第三层：工程任务再上
ACP
如果你要做代码代理、仓库代理，再引入 ACP。
十、一个可执行的搭建流程
下面给你一套“今天就能开始搭”的流程。
第一步：创建 Agent
openclaw agents add coordinatoropenclaw agents add researcheropenclaw agents add scraperopenclaw agents add cleaneropenclaw agents add analystopenclaw agents add reporter第二步：写基础配置
写入 ~/.openclaw/openclaw.json。
第三步：检查 Gateway
openclaw gateway status如果没启动：
openclaw gateway start如果配置改完感觉没生效：
openclaw gateway restart第四步：查看绑定
openclaw agents list --bindings第五步：实际测试
你可以直接对主 Agent 下指令：
把这个任务拆成 researcher、scraper、analyst 三个子 agent 并行执行：调研 AI 导航站，抓取首页标题/描述/联系方式，最后输出一份去重分析结果。
或者直接用命令：
/subagents spawn researcher 调研目标网站列表并整理字段/subagents spawn scraper 抓取这批网址标题、描述和联系方式/subagents list/subagents info <id>/subagents log <id>十一、常见坑位与避坑建议
1. 把 Session 当成多 Agent
session.dmScope 只是 session 分组，不是多 Agent 隔离。
真正隔离还是要靠：
• agents• bindings
2. 多个 Agent 共用一个 agentDir
这非常容易出问题，会造成：
• 认证冲突 • 会话污染 • 状态混乱
建议每个 Agent 独立 agentDir。
3. 一开始权限全开
尤其是这些能力：
• exec• process• browser• sessions_send• sessions_spawn
建议先按角色最小授权，再慢慢放开。
4. Subagents 和 ACP 混着用，但不分场景
记住最简单的分法：
• 研究 / 抓取 / 清洗 / 分析 → Subagents • 编码 / CLI harness / 修仓库 → ACP
5. 过度沉迷“CEO + 一堆员工”结构
这种玩法很酷，但一般也更贵、更复杂。
多数情况下：
一个主 Agent + 2~5 个职能 worker，已经非常够用。
十二、结论：哪种方式最值得先做？
如果你今天就要落地，我的建议只有一句：
优先搭“主协调 + Subagents”，再按需要补多智能体路由。
因为这是 OpenClaw 里最自然、最稳妥、最实用的一种团队协作形式。
对于数据采集类工作，这个组合尤其合适：
• coordinator 负责拆任务 • researcher 负责调研 • scraper 负责抓取 • cleaner 负责清洗 • analyst 负责结论 • reporter 负责交付
这就已经是一支很能打的小团队了。
附录：数据采集团队版 openclaw.json 精简可上线样板
下面这份样板偏实用，去掉了大量解释性注释，适合直接落地修改。
{ gateway: { reload: { mode: "hybrid", debounceMs: 300, }, }, session: { scope: "per-sender", dmScope: "per-channel-peer", reset: { mode: "idle", idleMinutes: 240, }, resetByType: { direct: { mode: "idle", idleMinutes: 480 }, group: { mode: "idle", idleMinutes: 180 }, thread: { mode: "idle", idleMinutes: 240 }, }, resetTriggers: ["/new", "/reset"], threadBindings: { enabled: true, idleHours: 24, maxAgeHours: 0, }, }, agents: { defaults: { userTimezone: "Asia/Shanghai", timeFormat: "24h", model: { primary: "zai/glm-5", fallbacks: [ "moonshot/kimi-k2.5", "minimax/MiniMax-M2.5", ], }, heartbeat: { every: "30m", }, subagents: { model: "minimax/MiniMax-M2.5", maxConcurrent: 3, runTimeoutSeconds: 1200, archiveAfterMinutes: 120, }, sandbox: { mode: "off", }, }, list: [ { id: "coordinator", default: true, name: "Data Coordinator", workspace: "~/.openclaw/workspace-coordinator", agentDir: "~/.openclaw/agents/coordinator/agent", model: "zai/glm-5", subagents: { allowAgents: [ "researcher", "scraper", "cleaner", "analyst", "reporter", ], }, }, { id: "researcher", name: "Research Worker", workspace: "~/.openclaw/workspace-researcher", agentDir: "~/.openclaw/agents/researcher/agent", model: "moonshot/kimi-k2.5", }, { id: "scraper", name: "Scraper Worker", workspace: "~/.openclaw/workspace-scraper", agentDir: "~/.openclaw/agents/scraper/agent", model: "minimax/MiniMax-M2.5", }, { id: "cleaner", name: "Cleaner Worker", workspace: "~/.openclaw/workspace-cleaner", agentDir: "~/.openclaw/agents/cleaner/agent", model: "minimax/MiniMax-M2.5", tools: { deny: ["browser", "canvas"], }, }, { id: "analyst", name: "Analyst Worker", workspace: "~/.openclaw/workspace-analyst", agentDir: "~/.openclaw/agents/analyst/agent", model: "zai/glm-5", }, { id: "reporter", name: "Reporter Worker", workspace: "~/.openclaw/workspace-reporter", agentDir: "~/.openclaw/agents/reporter/agent", model: "moonshot/kimi-k2.5", tools: { deny: ["exec", "process", "browser", "canvas"], }, }, ], }, bindings: [ { agentId: "coordinator", match: { channel: "telegram", accountId: "default", }, }, ], tools: { sessions: { visibility: "tree", }, sessions_spawn: { attachments: { enabled: true, maxTotalBytes: 5242880, maxFiles: 10, maxFileBytes: 1048576, retainOnSessionKeep: false, }, }, subagents: { tools: { deny: ["gateway", "cron"], allow: [ "read", "write", "edit", "exec", "process", "web_fetch", "browser", "session_status", ], }, }, }, channels: { telegram: { enabled: true, botToken: "${TELEGRAM_BOT_TOKEN}", defaultAccount: "default", dmPolicy: "allowlist", allowFrom: ["tg:7804159892"], groups: { "*": { requireMention: true, }, }, historyLimit: 50, replyToMode: "first", linkPreview: true, streaming: "partial", actions: { reactions: true, sendMessage: true, }, reactionNotifications: "own", mediaMaxMb: 100, }, },}如果你打算继续深入，可以沿着这个顺序逐步迭代：
1. 先跑通 coordinator + subagents2. 再细分权限和工具 3. 再按渠道/群/客户加 bindings4. 最后在工程任务里引入 ACP
这样最稳，也最不容易把自己绕进去。
