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 解析命令，动态创建 Binding
await bindingManager.create({
   
  agentId: 'code-reviewer',
  channel: 'telegram',
  userId: message.userId,
  sessionKey: `code-reviewer:telegram: