大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



2026 年，AI 助手正在从「单一对话」走向「多角色协作」。但多 Agent 不是把几个 AI 放在一起就行——你需要理解两种截然不同的协作机制。

---

很多人第一次听到「多 Agent」，脑子里浮现的画面是这样的：一个 Agent 负责写代码，一个负责调研，一个负责审核，它们像真人团队一样自动协作。

这个画面没错，但只对了一半。

在 OpenClaw 的架构中，「多 Agent」实际上包含两种完全不同的机制：

• Multi-Agent Routing：多个隔离的 Agent 并行运行，各管各的
• Sub-Agents：一个 Agent 在运行中派生出子任务，后台并行执行

这两者解决的是完全不同的问题。混淆它们，是大多数人踩坑的起点。

---

想象一下：你用 OpenClaw 连接了 WhatsApp 和 Telegram。WhatsApp 用来处理日常琐事，Telegram 用来做深度技术思考。你不希望它们共享记忆、混淆人格------你需要两个完全隔离的 Agent。

这就是 Multi-Agent Routing 的核心：一个 Gateway 进程，托管多个互不干扰的 Agent。

每个 Agent 是一个完全独立的作用域，拥有自己的：

关键点 ：Agent 之间的认证配置不共享 。主 Agent 的凭据不会自动传递给其他 Agent。如果需要共享，你得手动拷贝 。

Bindings 决定了一条入站消息应该发给哪个 Agent。路由是确定性的，按以下优先级从高到低匹配：

1. 匹配（精确到某个人/某个群）
2. 匹配（线程继承）
3. （Discord 角色路由）
4. （Discord 服务器）
5. （Slack 团队）
6. 匹配（频道账号）
7. （频道通配）
8. 兜底到默认 Agent（ 或列表第一个）

同一优先级内，配置文件中先出现的规则先匹配。多个匹配字段之间是 AND 关系。

最经典的场景------WhatsApp 用快速模型处理日常，Telegram 用强模型做深度工作：

在同一个 WhatsApp 号码上，把某个特定联系人路由到不同 Agent：

 
Peer 级别的匹配永远优先于频道级别。所以把精确规则放在前面。
 

不同的人通过不同的 WhatsApp DM 进来，路由到各自的 Agent：

 
注意：DM 访问控制是全局的（per WhatsApp account），不是 per agent。
 

每个 Agent 可以独立配置沙箱和工具权限：

 
一句话总结 Multi-Agent Routing：它不是「让 Agent 协作」，而是「让多个独立 Agent 互不干扰地服务不同场景」。
 

---

你正在和 Agent 对话，突然需要它同时做三件事：查一份资料、写一段代码、整理昨天的笔记。

单线程模式下，它只能一件一件来。你等。它做。你再等。

Sub-Agents 的思路是：从当前对话中派生出后台任务，并行执行，完成后自动汇报回来。

Sub-Agent 的本质是：在独立 session 中运行的后台 Agent。

• Session Key：
• 运行方式：非阻塞 ， 立即返回
• 结果回传：完成后通过 Announce 机制自动向发起者的聊天频道发送结果

是用户命令，one-shot 模式。执行完成后，结果会自动 announce 回来。

这是 Agent 在运行时通过 tool_use 调用的工具（不是外部 API）：

参数列表：

关键行为：

1. 立即返回，不阻塞当前对话
2. 子 Agent 继承父级模型，除非你显式覆盖
3. 完成后自动运行 Announce 步骤，将结果推送回发起者
4. 子 Agent session 默认 60 分钟后自动归档

这是 Sub-Agents 最精妙的设计。子 Agent 完成任务后：

1. 在子 Agent session 内运行一个 announce 步骤
2. 生成标准化的结果消息，包含：
   • Status ： / / （来自运行时信号，不是模型自述）
   • Result：助手回复文本（如果为空，取最后一个 toolResult）
   • Stats：运行时间、Token 用量、预估成本、sessionKey、transcript 路径
3. 投递到发起者的聊天频道
4. 发起者 Agent 收到后，用自己的风格重新表述（不是转发原始内容）

投递有容错机制：先尝试直接 agent delivery → 失败则回退到队列路由 → 再失败则指数退避重试。

如果子 Agent 回复 ，则静默不汇报。

默认 ，子 Agent 不能再派生子 Agent。设为 2 可以启用编排模式：

 
配置：
 
结果流向：
 
每一层只看到直接子级的 announce，不会越级。
 

Sub-Agents 的工具权限设计遵循最小权限原则：

可通过配置进一步收紧：

Sub-Agent 默认只能在自己的 Agent 下派生。如果想让 Agent A 派生任务给 Agent B 执行：

 
安全约束：如果发起者 session 是沙箱化的， 会拒绝派生到非沙箱化的目标。
 

用 工具可以查看当前 Agent 被允许派生到哪些 Agent。

停止操作会自动向下传播：

• ：停止主 Agent 当前运行 + 所有 depth-1 子 Agent + 级联到 depth-2
• ：停止指定子 Agent + 级联到它的子级
• ：停止所有子 Agent + 级联

一个容易忽略的细节：Sub-Agent 的 session 只注入 + 。

以下文件不会被加载：

• （人格）
• （身份）
• （用户信息）

这意味着 Sub-Agent 是一个「干活的工具人」，它不继承主 Agent 的人格和社交习惯。这是有意为之的设计------减少上下文消耗，专注于任务本身。

---

理解了细节之后，让我们拉远视角看全局。

一个常见误解：用 Multi-Agent Routing 来实现「统筹者分发任务给工程师」。

错了。Routing 是基于消息来源（哪个频道、哪个账号、哪个联系人）的确定性路由。它不会「分析需求然后选择合适的 Agent」。

如果你想要的是「一个 Agent 分析需求，然后分派给不同角色去执行」------这是 Sub-Agents 的活。

正确的组合方式：

不要一上来就搞复杂的多 Agent 编排。先问自己：

1. 我有几个互不相干的使用场景？→ 用 Routing 隔离
2. 在某个场景内，我需要并行处理多个子任务？→ 用 Sub-Agents

大部分个人用户，2-3 个 Routing Agent + 偶尔的 Sub-Agent 就够了。

Sub-Agent 有自己独立的上下文和 Token 消耗。推荐：

 
主 Agent 负责理解和决策（用好模型），Sub-Agent 负责执行具体任务（用快模型）。
 
不要把并发开太大。Sub-Agent 共享同一个 Gateway 进程资源， 是安全阀。
 

Sub-Agent 的 announce 是尽力投递（best-effort）：

• Gateway 重启 → 未完成的 announce 会丢失
• Announce 成功不代表用户一定看到了（取决于频道状态）
• 对于关键任务，完成后主动用 确认结果

默认配置下，session 工具的可见范围是 （当前 session + 它派生的子 session）。如果需要扩大：

 
对于沙箱化的 session，可见性会被进一步收紧到 （仅派生的子 session），即使你配了 也会被降级。
 

---

把上面所有知识串起来，一个真实可用的配置：

Multi-Agent Routing 和 Sub-Agents 是两把不同的刀：

Routing 解决的是「我有多重身份」——工作的我、生活的我、面对家人的我，各自独立，互不干扰。

Sub-Agents 解决的是「我需要分身术」——一边调研、一边写代码、一边整理笔记，并行推进，最终汇总。

理解这个区别，你就不会犯「拿路由当编排」或「拿编排当隔离」的错误。

而真正高效的用法，是两者组合：先用 Routing 划清边界，再在每个边界内用 Sub-Agents 提升并行度。