Day 5 | OpenClaw 多 Agent 路由：一个 Gateway 托管多个 AI 大脑

Day 5 | OpenClaw 多 Agent 路由：一个 Gateway 托管多个 AI 大脑

系列：《从 0 到 1 拆解 AI Agent 框架：OpenClaw 技术深度解析》

前言

想象一个场景：你有一个个人助手 Agent，同时你还部署了一个专门处理代码审查的 Agent，以及一个管理家庭自动化的 Agent。它们需要接入同一个 Telegram 账号，但各自有独立的"大脑"和记忆。

这就是 多 Agent 路由 要解决的问题：一个 Gateway，多个 AI 大脑，消息如何精准投递？

路由看起来简单，但实现起来有不少细节：怎么区分消息属于哪个 Agent？跨 Agent 的消息怎么传递？不同 Agent 如何共享同一个渠道账号却互不干扰？本文将逐一拆解。

一、架构概览：Gateway 与 Agent 的关系

先明确核心概念。

1.1 Gateway vs Agent

在 OpenClaw 中：

• Gateway 是消息的"交换机"——它负责接收来自各渠道（Telegram/Discord/WhatsApp…）的消息，并将其路由到正确的 Agent。它不做 AI 推理，只做路由。
• Agent 是消息的"处理器"——每个 Agent 有自己的配置（使用什么模型、什么系统提示词、什么工具），负责接收消息、调用 LLM、返回回复。

Telegram ─┐ Discord ──┤ Gateway ──┬── Agent A (个人助手) WhatsApp ─┘ ├── Agent B (代码审查) └── Agent C (家庭自动化) 

1.2 一对多 vs 多对多

最简单的部署是一个 Gateway + 一个 Agent，这是大多数人的起点。

但 OpenClaw 支持更复杂的拓扑：

• 一个 Gateway + 多个 Agent：共享渠道账号，按规则分发消息
• 多个 Gateway + 多个 Agent：完全隔离的部署，适合多用户场景

本文聚焦最有意思的场景：一个 Gateway，多个 Agent。

二、Binding：路由规则的核心

消息从 Telegram 进来，Gateway 怎么知道该交给哪个 Agent？答案是 Binding（绑定）。

2.1 什么是 Binding？

Binding 是一条路由规则，定义了：

“来自渠道 X、用户 Y 的消息，交给 Agent Z 处理”

配置示例：

agents:-id: personal-assistant bindings:-channel: telegram userId:"123456789"# 我自己的 Telegram ID-id: code-reviewer bindings:-channel: discord guildId:"my-work-server"channelId:"code-review"-id: home-automation bindings:-channel: telegram userId:"987654321"# 家里另一个账号

2.2 Binding 的匹配优先级

当一条消息可能匹配多个 Binding 时（比如同一个用户在不同场景），需要有清晰的优先级规则：

精确匹配 > 通配匹配 > 默认 Agent 

具体来说：

• userId + channelId 都匹配 → 优先级最高
• 只有 guildId 匹配 → 次之
• 没有任何精确匹配 → 走默认 Agent（如果配置了的话）

2.3 动态 Binding vs 静态 Binding

除了配置文件里的静态 Binding，OpenClaw 还支持运行时动态创建 Binding。

典型场景：用户发 /start 命令，Gateway 动态创建一个新 Session 并绑定到指定 Agent：

// 用户发送 /start code-review// Gateway 解析命令，动态创建 Bindingawait bindingManager.create({  agentId:'code-reviewer', channel:'telegram', userId: message.userId, sessionKey:`code-reviewer:telegram: