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:
