从单体到协同:基于 OpenClaw 构建多 Agent 飞书路由矩阵

当我们试图把日常问答、代码编写、甚至企业 ERP 数据检索都塞进同一个机器人时，往往会导致“人设崩塌”或上下文混乱。在真实的业务场景中，我们真正需要的是“专人专岗”——让不同的专职 Agent 协同工作。

今天，我们将以大家常用的飞书渠道为例，深入拆解如何在 OpenClaw 中优雅地配置多 Agent 架构，实现从“单体机器人”向“多 Agent 路由矩阵”的进阶。

核心重构：打破“一麦单传”的误区

在单 Agent 时代，我们的架构通常是线性的：一个飞书应用 ➡️ 一个默认入口 ➡️ 一个主助手。

但在多 Agent 架构中，我们需要引入流量路由（Routing）的概念。要实现同一个飞书工作区内存在两个或多个不同身份的助手（例如：主助手 + 编程助手），我们需要彻底理清三个核心组件：

1. Agent（智能体大脑）： 真正干活的逻辑核心。每个 Agent 有独立的工作区、Prompt 人设、甚至底层调用的国内大模型（如 DeepSeek/Qwen）。

2. Account（渠道账号/流量入口）： 同一个渠道（如飞书）下的不同应用身份。你可以理解为写字楼里的不同“办事窗口”。

3. Bindings（路由映射表）： 核心的调度枢纽。它负责指路：“从 A 窗口进来的业务，交给 A 大脑处理”。

理解了这三点，我们就有了构建复杂 Agent 编排的底层逻辑。

实战演练：构建你的双 Agent 矩阵

接下来，我们将动手在本地环境拉起一个“主助手 main”与“编程助手 coding”并存的双轨系统。

Step 1：实例化专职 Agent

首先，在控制台通过 CLI 命令，为编程场景开辟一个独立的工作区：

openclaw agents add coding

执行后，OpenClaw 会为 coding Agent 创建独立的存储路径。你可以通过 openclaw agents set-identity 为它赋予“编程专家”的专属人设与 Emoji。

Step 2：渠道多路复用

打开你的核心配置文件（通常位于 ~/.openclaw/openclaw.json）。找到 channels.feishu 节点。

在这个环节，我们需要打破单点应用的局限，在配置中引入 accounts 块。主应用走 default 默认通道，而新注册的编程助手飞书应用，则作为独立的 account 接入：

"channels": {  "feishu": {    "enabled": true,    "appId": "<主应用_APP_ID>",    "appSecret": "<主应用_APP_SECRET>",    "connectionMode": "websocket",    "accounts": {      "coding": {        "appId": "<编程应用_APP_ID>",        "appSecret": "<编程应用_APP_SECRET>",        "name": "编程助手"      }    }  }}

安全提示：请妥善保管你的 appSecret，在团队协作中避免将其硬编码推送到公有代码仓库。

Step 3：配置 Bindings 路由表

这是防止系统“串台”的最关键一步。我们需要在配置文件的顶层显式声明路由规则，将对应的入口（Account）绑定到对应的处理中枢（Agent）：

"bindings": [  {    "agentId": "main",    "match": {      "channel": "feishu",      "accountId": "default"    }  },  {    "agentId": "coding",    "match": {      "channel": "feishu",      "accountId": "coding"    }  }]

完成这一步并重启 Gateway 后，你可以通过命令 openclaw agents list --bindings 进行校验。此刻，你的流量分发网络就已经建立完毕。

Step 4：企业级访问控制（Pairing 模式）

在企业级应用场景中，安全性是不可忽视的环节。如果你的飞书渠道开启了 pairing（配对）私聊策略，新接入的账号面对用户的首次私信，会采取“默认拒绝/静默”的零信任状态。

作为管理员，你需要进行放行：

1. 监听请求：openclaw pairing list --channel feishu --account coding

2. 授权放行：openclaw pairing approve feishu <用户_open_id> –account coding

完成配对后，用户即可与这个全新的专职 Agent 顺畅对话。

架构师视角的排错指南

在真实的工程落地中，配置只是第一步，排障能力决定了系统的可用性。如果你发现机器人表现异常，请按以下链路追查：

• 完全无响应： 检查 Gateway 是否重启、appId/appSecret 是否填错、以及该用户是否卡在 Pairing 待批状态。

• 回答“串台”（两个机器人都像主助手）： 核心检查 bindings 里的 accountId 字段是否与 channels.feishu.accounts 里定义的 key（如 coding）绝对一致。

通过以上步骤，我们成功在 OpenClaw 中解耦了业务入口与底层逻辑，跑通了多 Agent 的核心路由能力。

这不仅仅是为了让群里多一个“编程机器人”，更是构建复杂业务工作流（如企业级 AI 客户服务、多学科教育辅助平台）的基础设施。一旦掌握了 Agent + Account + Binding 的范式，你完全可以平滑扩展出 research（文献检索助手）、data_analyst（数据分析助手）等无限场景。

欢迎在评论区分享你的多 Agent 落地场景！如果你在部署过程中遇到问题，也欢迎在社区中交流探讨。

相关文章：

10分钟，搭建你的AI助手

给你的AI助手注入灵魂

把AI接入你的数字生活

OpenClaw中国社区：https://open-claw.org.cn

声明：本文为 真聊技术 原创，转载请联系授权。

看完本文有收获？请转发分享给更多人

关注「真聊技术」，提升综合技能

分享、点赞和在看就是最大的支持❤️