多 Agent 路由设计：当不同渠道、不同用户需要匹配不同“大脑”

1. 引言：为什么需要多 Agent 路由？

如果只是单用户、单场景，一个 Agent 就够了。但当 Agent 系统走向真实生产环境，很快会遇到两个现实问题：

• 同一台服务器要服务多个用户——张三用 WhatsApp，李四用 Telegram，他们不希望自己的对话上下文互相串扰
• 同一个人在不同场景下需要不同“人格”的 Agent——工作时用编程 Agent，回家后用家庭 Agent

更深层的原因是：在 Agent 系统中，Agent ID 直接决定了工作区、凭证、会话存储和个性规则。路由选错了 Agent，等于用了别人的“大脑”。

一句话定位：OpenClaw 的多 Agent 路由通过“绑定（Binding）”机制，将特定渠道的账号或会话精确映射到对应的 Agent ID，采用“最具体优先”的确定性匹配策略，确保每条入站消息都能找到正确的智能体。

2. 核心概念：Agent、Account、Binding 三位一体

在 OpenClaw 中，设计多 Agent 路由首先要理解三个基本概念：

关键设计原则：agentId 是隔离边界。每个 agentId 拥有自己的~/.openclaw/agents/<agentId>/目录，包含独立的agent配置目录和sessions会话存储。

路由时绑定是确定性的，并且最具体者优先。

3. 路由匹配优先级：从最具体到最宽泛

OpenClaw 为每条入站消息按以下优先级选择 Agent：

核心规则：当一个 binding 包含多个匹配字段时（如 peer + guildId），所有提供字段都必须满足（AND 语义）。同层级匹配冲突时，配置顺序中的第一个胜出。

4. 路由设计的工程实践

4.1 按渠道拆分：WhatsApp 日常 + Telegram 深度工作

{ agents: { list: [ { id: "fast", workspace: "~/.openclaw/workspace-fast" }, { id: "opus", workspace: "~/.openclaw/workspace-opus" }, ], }, bindings: [ { agentId: "fast", match: { channel: "whatsapp", accountId: "*" } }, { agentId: "opus", match: { channel: "telegram", accountId: "*" } }, ], }

这样每个渠道的账号被绑定到不同 Agent，实现渠道级的上下文隔离。

4.2 同一渠道，将特定私信路由到专用 Agent

同一 WhatsApp 账号下，不同的私信发送者可以路由到不同 Agent。通过peer.kind: "direct"匹配发送者的 E.164 格式号码：

{ bindings: [ { agentId: "alex", match: { channel: "whatsapp", peer: { kind: "direct", id: "+15551230001" } }, }, { agentId: "mia", match: { channel: "whatsapp", peer: { kind: "direct", id: "+15551230002" } }, }, ], }

peer 匹配永远优先于 channel 级别的绑定，因此可以实现“同一渠道、不同私信走不同 Agent”的精细控制。

4.3 绑定 WhatsApp 群组到家庭 Agent

将单个群组绑定到专用 Agent，配合提及门控和更严格的工具策略：

{ bindings: [ { agentId: "family", match: { channel: "whatsapp", peer: { kind: "group", id: "1234567890" } }, }, ], }

这样该群组的消息只由familyAgent 处理，其他消息继续走默认 Agent。

5. 会话键（SessionKey）：路由如何决定上下文隔离

路由选中的 Agent 决定了工作区和会话存储的位置。不同场景的会话键形态如下：

私信默认折叠到 Agent 的main会话。即使私信对话历史与 main 共享，沙箱和工具策略仍会为外部私信使用派生的每账号直接聊天运行时键，防止渠道消息污染本地 main 会话。

6. 多 Agent 路由 vs 并行专家通道

当路由把不同 Agent 派到不同场景后，下一个要考虑的问题变成了：这些 Agent 之间如何共享模型和工具的有限容量？

OpenClaw 的Parallel Specialist Lanes思想回答了这个问题：

• 会话锁：同一时刻只能有一个运行修改给定会话
• 全局模型容量：所有可见的聊天运行仍共享提供商限制
• 工具容量：shell、浏览器、网络操作可能比模型回合本身更慢
• 上下文预算：长转录会让后续每个回合更慢

专门通道只会在减少对真正瓶颈的争用时提升吞吐量。OpenClaw 已按会话序列化运行，并通过命令队列限制全局并行度。专门通道在此基础上增加策略：哪个 Agent 拥有哪项工作、什么留在聊天里、什么变成后台工作。

推荐的实施路径是渐进式的：

1. 第一阶段：通道契约——在每个 Agent 的工作区和系统提示中明确职责边界，定义“什么该做、什么不该做、什么该交接”
2. 第二阶段：优先级和并发控制——按业务价值调整队列和模型容量
3. 第三阶段：协调器模式——在多个通道启用后，加入小型协调器跟踪活跃任务、检测重复请求、路由交接摘要

7. 一张图看懂多 Agent 路由设计

8. 结语

OpenClaw 的多 Agent 路由设计遵循一条清晰的工程原则：确定性优先于灵活性，具体优先于宽泛。

通过Binding将渠道账号精准映射到 Agent ID，通过8 级优先级路由规则从最具体匹配逐级回退到默认 Agent，通过SessionKey将路由结果转化为存储隔离边界。三者共同构成了一套可治理、可扩展的多 Agent 路由系统。

最终效果：同一台 Gateway 服务器可以并排运行多个完全隔离的 Agent，每个 Agent 都有自己的“人格”、凭证、会话记忆和工作区——就像在同一台物理机上运行了多个虚拟的 AI“大脑”，互不干扰、各司其职。