07 · 多 Agent——什么时候拆、怎么协作
解释 OpenClaw 多 Agent 的拆分信号、绑定路由和协作方式，避免为了复杂而复杂。
——翔宇
要点速览
- 一个 Agent（智能体）能搞定 80% 的事——别急着拆
- 拆分的三个信号：记忆要隔离、模型要省钱、权限要区分
- Binding（绑定，路由规则）是确定性的——不用 AI 决定消息发给谁，因为 AI 会犯错
- 三级通信：Shared（共享文件）/ Spawn（派生子智能体）/ Message（单向通知）
- 10 个 Agent 不是 1 个 Agent 的 10 倍成本——大部分时间在待命
1. 一个好问题
如果你只有一个员工，他什么都做。什么时候你才需要招第二个？
这个问题的答案不是「当工作量太大的时候」——因为 AI Agent 不会累。真正的答案藏在三个更深层的需求里。
2. 直觉：越多越好？
错误直觉
「10 个 Agent 比 1 个强——就像 10 个员工比 1 个员工能干更多事。」
在人类公司里，多雇人通常意味着更高的产出。但 AI Agent 不一样：
-
一个 Agent 就能同时处理所有渠道的消息（不需要轮班）
-
一个 Agent 的记忆是连贯的（不需要交接）
-
一个 Agent 不会累、不需要休息 多 Agent 的代价也很真实：
-
每个 Agent 独立的 System Prompt（系统提示词）占用上下文空间
-
Agent 之间的通信不像人类说话那么自然
-
配置复杂度翻倍
🔑 关键点
不要因为「看起来更专业」而拆 Agent。只有当一个 Agent 真的不够用时才拆。判断标准是下面的三个信号。
3. 拆分的三个信号
3.1 记忆要隔离
你的 Agent 同时处理两类完全不同的任务——比如写代码和管社媒。这两类任务的记忆混在一起会互相污染。
🎯 打个比方
一个员工既做技术支持又做市场营销，笔记本里技术文档和营销数据混在一起。找东西越来越难，而且技术上下文可能影响营销回复的风格。
解法：拆成两个 Agent，各自有独立的 Workspace（工作区）和记忆文件。
3.2 模型要省钱
不是所有任务都需要最强的模型。日常问答用 Sonnet（便宜），深度分析用 Opus（贵）。如果只有一个 Agent，它只能用一个模型。
💬 说人话
回复「今天天气怎么样」用 Opus 就像开法拉利去买菜——能到但浪费。拆成两个 Agent，一个用便宜模型处理简单问题，一个用强模型处理复杂任务，成本能降 60%。
3.3 权限要区分
有些 Agent 应该能执行 Shell 命令（开发 Agent），有些绝对不能（面向外部用户的客服 Agent）。一个 Agent 只能有一套权限配置。
📌 记住这点
如果三个信号一个都没有——不要拆。一个 Agent 比两个 Agent 简单一倍。
3.4 翔宇的 10 Agent 组织是怎么演化出来的
翔宇不是一开始就设计了 10 个 Agent。最初只有 1 个——main Agent 处理所有事情。
演化时间线：
🧠 底层逻辑
每次新增 Agent 都有明确的理由——不是「看起来更专业」，而是「1 个 Agent 的某个能力边界被撞到了」。记忆污染、风格冲突、权限需求——三个信号至少命中一个才拆。
翔宇的 10 Agent 架构：
📌 记住这点
10 个 Agent 只有 2 个用 Opus（main 和 rnd），1 个用 Haiku（archive），其余 7 个用 Sonnet。这不是省钱——是匹配需求。公众号长文用 Sonnet 就够了，归档用 Haiku 就够了。
4. Binding：为什么不让 AI 决定路由
消息进来了，应该交给哪个 Agent？
直觉上你可能觉得：让 AI 自己判断不就好了？分析消息内容，然后决定发给技术 Agent 还是营销 Agent。
错误直觉
「用 AI 做智能路由——它能理解消息内容，自动分发给最合适的 Agent。」
听起来很酷。但 OpenClaw 没有这么做。它用的是 Binding——一套确定性的匹配规则，按「最具体优先」原则匹配。
官方路由优先级（从高到低）：
🧠 底层逻辑
越具体的匹配越优先。如果你同时设了「WhatsApp 全部 → chat Agent」和「WhatsApp 特定用户 → opus Agent」，特定用户的消息永远走 opus——peer 匹配优先级高于 channel 匹配。
为什么不用 AI 路由？ 因为 AI 路由会失败。
反事实场景：如果用 AI 路由
每次路由错误 = 消息发给了错误的 Agent = 错误的记忆、错误的上下文、错误的回复风格。
🧠 底层逻辑
确定性路由的核心原则是：宁可让用户多走一步（发到正确频道），也不让系统猜错。每个 Discord 频道/Telegram 群绑定一个 Agent，消息从哪个频道进来就交给哪个 Agent。简单、可靠、零歧义。
Binding 规则按优先级匹配：频道 + 用户 + 群组 → 最具体的规则优先。
5. 三级通信：Agent 之间怎么协作
多个 Agent 之间需要协作。OpenClaw 提供三种方式，复杂度递增。
5.1 Level 1：Shared（共享文件）
最简单的方式——Agent A 写一个文件到共享目录，Agent B 去读。
🎯 打个比方
同事把文件放在你桌上的收件筐里。简单有效，但你不知道它什么时候放的，得定期检查。
5.2 Level 2：Spawn（派生子 Agent）
Agent A 启动 Agent B 作为子 Agent 执行一个具体任务，等结果返回。
🎯 打个比方
经理把一个子任务派给下属。下属干完后把结果交回给经理。经理不需要关心下属怎么做的，只看结果。
5.3 Level 3：Message（单向通知）
Agent A 发一条消息给 Agent B，不等回复。
💬 说人话
Level 1 是放文件在桌上（最松散），Level 2 是派活等结果（最紧密），Level 3 是发个通知不管了（中间状态）。大部分协作用 Level 1 + Level 2 就够了。
📌 记住这点
Agent 间消息传递（Level 3）默认是关闭的。必须在配置中显式启用
tools.agentToAgent.enabled = true并设置allow白名单，指定哪些 Agent 之间可以通信。这是安全设计——防止 Agent 之间未经授权的消息传递。
5.4 dmScope：多 Agent 的会话隔离
多 Agent 环境下，dmScope（私信会话范围）的选择更加重要。
🔍 深入一步
翔宇的 10 Agent 组织全部用
main模式——因为只有翔宇一个人在用。每个 Agent 绑定一个 Discord 频道，翔宇在哪个频道发消息就和哪个 Agent 对话。不需要用户隔离，因为没有其他用户。
5.5 成本实算：10 个 Agent 真的贵吗
错误直觉
「10 个 Agent = 10 倍成本。」
让我们算一笔真实的账。
翔宇 10 Agent 一个月的 Token（词元，AI 文本计量单位）消耗：
💬 说人话
10 个 Agent 一个月的 Sonnet 成本约 $10。不是 10 倍——因为大部分 Agent 大部分时间在待命，只有收到消息或心跳触发时才消耗 Token。真正的成本瓶颈不是 Agent 数量，而是对话频率和工具调用。
6. 模型分层策略
多 Agent 最直接的好处之一：不同 Agent 用不同价位的模型。
💡 划重点
成本真相：10 个 Agent 不是 1 个 Agent 的 10 倍成本。大部分 Agent 大部分时间在待命——只有收到消息时才调用模型。实际成本取决于消息量，不取决于 Agent 数量。
7. Auth Profile 不继承：安全隔离
📌 记住这点
多 Agent 环境下，认证配置（Auth Profile）不会自动从主 Agent 继承到子 Agent。每个 Agent 必须单独配置自己的 API Key 或 OAuth（开放授权）Token。
🧠 底层逻辑
这是有意设计的安全隔离。如果子 Agent 自动继承主 Agent 的凭证，一个低权限 Agent 被 Prompt Injection 攻击后，就能用主 Agent 的高权限凭证做危险操作。不继承 = 权限泄露的爆炸半径被限制在单个 Agent。
8. 设计权衡
设计权衡
一句话检验
- 什么时候需要第二个 Agent？ → 记忆要隔离、模型要省钱、权限要区分——三个信号至少命中一个
- 为什么不用 AI 路由？ → AI 会猜错——「Docker 怎么配」可能是课程内容而不是技术问题。确定性规则更可靠
- 三级通信是什么？ → 放文件（Shared）、派活等结果（Spawn）、发通知不管了（Message）
- 10 个 Agent 10 倍成本？ → 不是。大部分时间待命，成本取决于消息量
CC 提示词
🚀 对 Claude Code 说 帮我分析当前 OpenClaw 的多 Agent 配置是否合理： - 读取 /你的路径/.openclaw/openclaw.json 中的 agents 配置
- 列出所有 Agent 的 ID、名称、模型、Workspace 路径
- 检查 Binding 路由规则——是否每个频道都绑定了明确的 Agent
- 检查 Auth Profile——是否每个 Agent 都有独立的认证配置
- 分析是否有可以合并的 Agent（记忆不需要隔离、模型相同、权限相同的）
- 给出优化建议
延伸阅读
- 翔宇版 06《多智能体与路由》— Binding 配置、dmScope、模型分层的完整操作指南
- 翔宇版 04《核心概念深度解析》— Session Key 映射、跨渠道身份关联
- 深度教程-06《Workspace——Agent 的灵魂容器》— 每个 Agent 的 Workspace 文件设计
- 深度教程-09《渠道与安全——谁能进来能做什么》— Channel 和安全模型的深入解析