第 34 章

Multi-Agent 路由：Bindings 配置模式与多账号/多渠道分流实战

第34章：Multi-Agent 路由——Bindings 配置模式与多账号/多渠道分流实战

"一个 Agent 无法同时成为所有人的最佳助手。Multi-Agent 架构让每个 Agent 专注于它最擅长的事情。" —— OpenClaw 多 Agent 设计指南

34.1 为什么需要多 Agent

34.1.1 单 Agent 架构的局限性

在大多数 AI Agent 平台的早期阶段，用户使用单一 Agent 处理所有请求。这种架构简单易用，但随着使用规模扩大，它的局限性逐渐显现：

问题一：模型选择的两难困境

不同任务对模型有截然不同的要求：

任务类型	最佳模型特性	次优模型的代价
WhatsApp 快速问答	低延迟（< 1s）/ 低成本	用 Opus 模型回答"你好"：浪费 10 倍成本
复杂代码分析	高推理能力 / 长上下文	用 Haiku 分析架构：结果质量差
多语言客服	语言专项训练	通用模型处理小语种：准确率低
创意写作	创造力 / 表达力	分析型模型写文案：风格生硬

问题二：账号和渠道混杂

一个做跨境贸易的用户，可能同时运营：

个人 WhatsApp（家人朋友）
商务 WhatsApp（客户、供应商）
Telegram（技术社区）
Discord（产品用户）

如果所有消息都流入同一个 Agent，Agent 的记忆会混杂个人生活和商业信息，一次不当的上下文召回可能导致严重的隐私问题（例如，在回复客户时引用了家庭聊天记录）。

问题三：状态污染

当 Agent A 正在执行一个长时间的数据分析任务时，如果新的紧急消息到来，会打断 A 的工作流，降低两项任务的质量。

34.1.2 Multi-Agent 解决了什么

OpenClaw 的 Multi-Agent 架构通过以下机制解决上述问题：

渠道级路由：WhatsApp 消息 → 快速模型，Telegram 消息 → 高质量模型
账号级隔离：个人账号 → home Agent（个人记忆），商务账号 → work Agent（业务记忆）
负载分离：长任务运行在 work Agent，不阻塞 home Agent 的响应
成本优化：高频低复杂度请求 → 便宜模型，低频高价值请求 → 贵模型

34.2 Agent 完整隔离原理

每个 Agent 在文件系统层面完全隔离，这是 Multi-Agent 架构安全性的基础。

34.2.1 目录结构

~/.openclaw/
├── agents/
│   ├── main/                    ← main Agent 的独立空间
│   │   ├── config.json          ← main Agent 专属配置
│   │   ├── memory/              ← main Agent 的记忆库
│   │   │   ├── conversations/
│   │   │   ├── embeddings/
│   │   │   └── index.json
│   │   ├── workspace/           ← main Agent 的工作目录
│   │   ├── session-store/       ← main Agent 的 Session 持久化
│   │   │   ├── active/
│   │   │   └── archive/
│   │   └── logs/               ← main Agent 的专属日志
│   │
│   ├── home/                    ← home Agent 的独立空间
│   │   ├── config.json
│   │   ├── memory/
│   │   ├── workspace/
│   │   └── session-store/
│   │
│   └── work/                    ← work Agent 的独立空间
│       ├── config.json
│       ├── memory/
│       ├── workspace/
│       └── session-store/
│
├── config.json                  ← 全局配置（含 Bindings）
└── logs/                        ← 全局日志

34.2.2 隔离的三个维度

维度一：文件系统隔离

每个 Agent 只能访问自己的 ~/.openclaw/agents/<agentId>/ 目录。跨 Agent 的文件访问默认被拒绝，除非通过共享记忆配置明确允许。

维度二：Session Store 隔离

每个 Agent 维护独立的 Session Store，存储：

当前活跃的对话上下文
工具调用历史
中间状态（Agent 正在执行的任务状态）

home Agent 的 Session 对 work Agent 不可见，反之亦然。

维度三：记忆库隔离

记忆库（Memory Store）存储 Agent 从对话中提取的长期知识：

用户偏好
重要事实
历史决策

默认情况下，不同 Agent 的记忆完全隔离。可以通过 memorySearch.qmd.extraCollections 配置跨 Agent 记忆访问（详见第35章）。

34.3 Bindings 基础配置

Bindings 是 OpenClaw 的路由规则引擎，定义了"哪类消息应该路由到哪个 Agent"。

34.3.1 Bindings 的工作原理

消息到达
    ↓
Gateway 接收消息
    ↓
按顺序匹配 Bindings 规则（第一个匹配的规则生效）
    ↓
路由到对应 Agent
    ↓
Agent 处理并回复

34.3.2 最简 Bindings 配置

// openclaw.json
{
  "bindings": [
    {
      "agentId": "fast",
      "match": {
        "channel": "whatsapp"
      }
    },
    {
      "agentId": "opus",
      "match": {
        "channel": "telegram"
      }
    }
  ]
}

说明：

所有来自 WhatsApp 的消息 → fast Agent（使用低延迟模型）
所有来自 Telegram 的消息 → opus Agent（使用高质量模型）
没有匹配任何规则的消息 → 回退到默认 Agent（见 34.5 节）

34.4 按渠道分流配置详解

34.4.1 渠道标识符参考

OpenClaw 支持以下渠道标识符：

渠道	channel 值	特点
WhatsApp	`"whatsapp"`	高频 / 移动优先 / 媒体支持
Telegram	`"telegram"`	群组支持 / Bot API 成熟
Discord	`"discord"`	服务器/频道/角色系统
Slack	`"slack"`	企业即时通讯 / 集成生态
Email	`"email"`	异步 / 长文本
SMS	`"sms"`	极简文本 / 高可达率
API	`"api"`	程序调用
Web	`"web"`	Dashboard 交互

34.4.2 按渠道分流的完整配置示例

{
  "agents": {
    "list": [
      {
        "id": "fast",
        "model": "claude-haiku-4",
        "description": "快速响应 Agent，用于即时通讯渠道",
        "maxResponseTokens": 500,
        "systemPrompt": "你是一个简洁高效的助手。回复要简短，每条消息不超过3句话。"
      },
      {
        "id": "opus",
        "model": "claude-opus-4",
        "description": "高质量 Agent，用于需要深度分析的渠道",
        "maxResponseTokens": 4000,
        "systemPrompt": "你是一个专业的顾问助手。提供深度分析和详细建议。"
      },
      {
        "id": "email-agent",
        "model": "claude-sonnet-4",
        "description": "邮件处理 Agent",
        "maxResponseTokens": 2000,
        "systemPrompt": "你是一个专业的商务邮件助手。使用正式、专业的语气。"
      }
    ]
  },
  "bindings": [
    {
      "agentId": "fast",
      "match": {
        "channel": "whatsapp"
      },
      "options": {
        "typingIndicator": true,
        "maxResponseDelay": 2000
      }
    },
    {
      "agentId": "fast",
      "match": {
        "channel": "sms"
      }
    },
    {
      "agentId": "opus",
      "match": {
        "channel": "telegram"
      }
    },
    {
      "agentId": "email-agent",
      "match": {
        "channel": "email"
      }
    },
    {
      "agentId": "opus",
      "match": {
        "channel": "api"
      }
    }
  ]
}

34.5 按账号分流：个人/商务隔离配置

34.5.1 账号分流的典型场景

跨境贸易从业者 Alex 的配置需求：

需求描述：
- 个人 WhatsApp（+1-555-0001）：家人朋友，个人生活
- 商务 WhatsApp（+1-555-0002）：客户、供应商，外贸业务
- Telegram 个人（@alex_personal）：技术社区
- Telegram 商务（@alex_biz）：客户频道

期望行为：
- 商务渠道的 Agent 知道产品目录、价格政策、客户记录
- 个人渠道的 Agent 保持个人生活语境，不混入商业信息

34.5.2 完整的多账号分流配置

{
  "agents": {
    "list": [
      {
        "id": "home",
        "model": "claude-haiku-4",
        "description": "个人生活助手",
        "systemPrompt": "你是 Alex 的个人助手，帮助处理日常生活事务。保持轻松友好的语气。"
      },
      {
        "id": "work",
        "model": "claude-sonnet-4",
        "description": "商务助手",
        "systemPrompt": "你是 Alex 的商务助手，专注于外贸业务。熟悉产品目录和客户关系。保持专业态度。",
        "memory": {
          "collections": ["business-knowledge", "customer-records", "product-catalog"]
        }
      },
      {
        "id": "tech",
        "model": "claude-opus-4",
        "description": "技术讨论助手",
        "systemPrompt": "你是一个技术专家助手，擅长编程、架构设计和技术讨论。"
      }
    ]
  },
  "bindings": [
    {
      "agentId": "home",
      "match": {
        "channel": "whatsapp",
        "accountId": "personal"
      }
    },
    {
      "agentId": "work",
      "match": {
        "channel": "whatsapp",
        "accountId": "biz"
      }
    },
    {
      "agentId": "home",
      "match": {
        "channel": "telegram",
        "accountId": "alex_personal"
      }
    },
    {
      "agentId": "tech",
      "match": {
        "channel": "telegram",
        "accountId": "alex_biz"
      }
    }
  ],
  "channels": {
    "whatsapp": {
      "accounts": [
        {"id": "personal", "phone": "+15550001"},
        {"id": "biz", "phone": "+15550002"}
      ]
    },
    "telegram": {
      "accounts": [
        {"id": "alex_personal", "username": "alex_personal"},
        {"id": "alex_biz", "username": "alex_biz"}
      ]
    }
  }
}

34.6 Binding 匹配失败的默认回退行为

当收到的消息没有匹配任何 Binding 规则时，OpenClaw 有以下回退策略：

34.6.1 配置默认 Agent

{
  "bindings": [
    {
      "agentId": "fast",
      "match": {"channel": "whatsapp"}
    },
    {
      "agentId": "opus",
      "match": {"channel": "telegram"}
    }
  ],
  "defaultAgent": "main",  // 未匹配时路由到 main Agent
  "unmatchedBehavior": "route-to-default"  // 路由到默认 Agent
}

34.6.2 回退行为选项

{
  "unmatchedBehavior": "route-to-default"
  // 其他选项：
  // "drop"           - 静默丢弃消息
  // "reply-error"    - 回复错误提示
  // "queue"          - 放入待处理队列
}

34.6.3 调试 Binding 匹配

# 查看消息被路由到了哪个 Agent
openclaw routing debug --channel whatsapp --accountId personal

# 输出：
# Message routing debug for channel=whatsapp accountId=personal
# Checking binding rules in order:
#   Rule 1: match.channel=whatsapp, match.accountId=personal → MATCH → agentId=home
#   Routing to: home Agent
#   home Agent status: active (last active: 2 minutes ago)

34.7 Discord 应用：Guild ID + 角色的高级配置

Discord 提供了比其他渠道更丰富的路由维度，包括服务器（Guild）、频道（Channel）、用户角色（Role）等。

34.7.1 Discord 渠道特有的匹配字段

字段	说明	示例值
`guildId`	Discord 服务器 ID	`"123456789012345678"`
`channelId`	特定频道 ID	`"987654321098765432"`
`channelType`	频道类型	`"text"`, `"dm"`, `"thread"`
`hasRole`	用户需要具有的角色	`"admin"`, `"verified"`
`mentionBot`	是否需要 @ Bot	`true`, `false`

34.7.2 Discord 多服务器、多角色配置示例

{
  "bindings": [
    {
      "agentId": "admin-assistant",
      "match": {
        "channel": "discord",
        "guildId": "123456789012345678",
        "hasRole": "admin"
      },
      "description": "管理员专用助手，有完整操作权限"
    },
    {
      "agentId": "support-bot",
      "match": {
        "channel": "discord",
        "guildId": "123456789012345678",
        "channelId": "987654321098765432",
        "hasRole": "verified"
      },
      "description": "认证用户技术支持频道"
    },
    {
      "agentId": "public-bot",
      "match": {
        "channel": "discord",
        "guildId": "123456789012345678",
        "channelType": "text",
        "mentionBot": true
      },
      "description": "公共频道，需要 @ Bot 触发"
    },
    {
      "agentId": "dm-agent",
      "match": {
        "channel": "discord",
        "channelType": "dm"
      },
      "description": "私信处理，所有服务器的 DM 都路由到这里"
    }
  ]
}

34.8 多 Agent 跨 Workspace 共享记忆配置

在某些场景下，多个 Agent 需要共享部分知识库。例如，home Agent 和 work Agent 都需要知道用户的语言偏好和基本个人信息。

34.8.1 共享记忆集合配置

{
  "memory": {
    "sharedCollections": [
      {
        "name": "user-profile",
        "description": "用户基本信息，所有 Agent 可读取",
        "allowedAgents": ["home", "work", "tech", "main"],
        "writeAgent": "main"
      },
      {
        "name": "language-preference",
        "description": "用户语言和沟通偏好",
        "allowedAgents": ["home", "work", "tech"],
        "writeAgent": "any"
      }
    ],
    "agentCollections": {
      "home": ["personal-life", "family-contacts"],
      "work": ["business-knowledge", "customer-records"],
      "tech": ["code-snippets", "tech-notes"]
    }
  }
}

34.8.2 记忆访问控制矩阵

记忆访问矩阵（✓=可访问，✗=无访问权限）

              user-profile  personal-life  business-knowledge  code-snippets
home Agent        ✓              ✓               ✗                  ✗
work Agent        ✓              ✗               ✓                  ✗
tech Agent        ✓              ✗               ✗                  ✓
main Agent        ✓              ✗               ✗                  ✗

34.9 常见多 Agent 架构模式

34.9.1 模式一：专家分工型

场景：用户有多个专业领域的需求

架构：
  Telegram → 路由分发 Agent（分析意图）
              ↓
         ┌────┴─────┬──────────┐
      代码专家   法律顾问   财务顾问
      claude-opus  claude-sonnet  claude-sonnet

配置：

{
  "bindings": [
    {
      "agentId": "router",
      "match": {"channel": "telegram"}
    }
  ],
  "agents": {
    "list": [
      {
        "id": "router",
        "model": "claude-haiku-4",
        "systemPrompt": "分析用户意图并路由到对应专家 Agent。代码问题→coding，法律问题→legal，财务问题→finance。"
      },
      {"id": "coding", "model": "claude-opus-4"},
      {"id": "legal", "model": "claude-sonnet-4"},
      {"id": "finance", "model": "claude-sonnet-4"}
    ]
  }
}

34.9.2 模式二：成本优化型

场景：降低 API 成本，将低价值请求分配给便宜模型

逻辑：
  消息到达
    ↓
  快速 Agent（Haiku）：判断复杂度
    ├── 简单问题 → 直接回复（Haiku 低成本）
    └── 复杂问题 → 转发给 opus Agent（高质量回复）

成本对比（估算）：
  全用 Opus：100% 成本
  混合模式（70% Haiku + 30% Opus）：约 25% 成本

34.9.3 模式三：语言分流型

场景：多语言业务，不同语言由专项调优的模型处理

配置示例：

{
  "bindings": [
    {
      "agentId": "chinese-agent",
      "match": {
        "channel": "whatsapp",
        "detectedLanguage": "zh"
      }
    },
    {
      "agentId": "english-agent",
      "match": {
        "channel": "whatsapp",
        "detectedLanguage": "en"
      }
    },
    {
      "agentId": "spanish-agent",
      "match": {
        "channel": "whatsapp",
        "detectedLanguage": "es"
      }
    },
    {
      "agentId": "multilingual-agent",
      "match": {
        "channel": "whatsapp"
      }
    }
  ]
}

34.10 Multi-Agent 运维与调试

34.10.1 查看各 Agent 状态

# 查看所有 Agent 的运行状态
openclaw agents status

# 输出示例：
# Agent ID    Status     Model              Sessions  Last Active
# ─────────────────────────────────────────────────────────────────
# home        running    claude-haiku-4     2         30s ago
# work        idle       claude-sonnet-4    0         5m ago
# tech        running    claude-opus-4      1         10s ago
# main        stopped    claude-opus-4      0         2h ago

# 查看特定 Agent 的详细状态
openclaw agents status --id work --verbose

34.10.2 切换 Agent 上下文（手动测试）

# 向特定 Agent 发送测试消息
openclaw send --agent home "你好，今天天气怎么样？"

# 查看特定 Agent 的会话历史
openclaw sessions list --agent work

# 清空特定 Agent 的所有会话（谨慎使用）
openclaw sessions clear --agent home

34.10.3 Binding 规则热更新

# 更新 Bindings 配置（无需重启服务）
openclaw config set bindings '...'
openclaw routing reload

# 验证路由规则已更新
openclaw routing rules list

34.11 小结

Multi-Agent 路由是 OpenClaw 从"个人助手"走向"企业级 Agent 平台"的关键架构特性。通过 Bindings 配置，你可以精确控制每条消息的处理路径，在成本、质量、隔离性三个维度上取得最优平衡。

核心要点：

隔离是基础：每个 Agent 有独立的文件系统、Session Store 和记忆库，这是多 Agent 架构安全的保障
Bindings 按顺序匹配：规则从上到下依次检查，第一个匹配的生效
账号隔离优于渠道隔离：对于隐私要求高的场景，用 accountId 而非仅用 channel 做区分
共享记忆需要明确授权：跨 Agent 记忆访问应遵循最小必要原则
成本优化是实际价值：合理设计 Agent 分工可以大幅降低模型调用成本

在下一章，我们深入探讨 Sub-agents：如何通过非阻塞的委托执行机制，让 Agent 在处理复杂任务时实现真正的并行化。

本章关键词：Multi-Agent、Bindings、渠道分流、账号隔离、agentId、路由规则、Discord Guild、共享记忆、成本优化

本章评分

4.5 / 5 (3 评分)