09、OpenClaw 飞书多应用接入：为什么一个应用配一个 Agent？

企业使用 OpenClaw 时，很快会遇到一个问题：

多个业务 Agent，到底要不要共用一个飞书应用？

比较清晰的设计思路是：按业务进行隔离，一个飞书应用服务一个明确的 Agent 或业务场景。

目的不是为了“多建几个机器人”，而是把权限、路由、审计和故障影响范围拆开。

一、多应用解决什么问题？

例如企业同时有：

代码审核 Agent
运维 Agent
客服 Agent

如果全部混在一个入口里，后期权限和消息路由会越来越复杂。

拆开以后则变成：

飞书应用 A → 代码审核 Agent
飞书应用 B → 运维 Agent
飞书应用 C → 客服 Agent

哪个机器人负责什么，一目了然。

---

二、defaultAccount 是什么？

配置多个飞书账号时，会涉及类似：

{
  "channels": {
    "feishu": {
      "defaultAccount": "app1",
      "accounts": [
        {
          "appId": "cli_xxx1",
          "appSecret": "xxx"
        },
        {
          "appId": "cli_xxx2",
          "appSecret": "xxx"
        }
      ]
    }
  }
}

这里最容易误解的是：

defaultAccount

简单理解，它解决的是：

存在多个飞书账号时，哪个账号作为默认账号。

而“消息最终交给哪个 Agent”属于路由/bindings层面的问题。

因此不要把两者完全混为一谈：

Account → 我通过哪个飞书身份通信？

Bindings → 这条消息应该交给哪个 Agent？

---

三、bindings 才负责业务路由

假设有多个 Agent，可以按照消息来源建立明确绑定：

测试群
   ↓
bindings
   ↓
测试 Agent

运维群
   ↓
bindings
   ↓
运维 Agent

设计时遵循一个原则：

能明确绑定，就不要依赖模糊的默认行为。

尤其不要让两个机器人在同一个群里处理相同类型的消息，否则很容易出现重复回复、路由混乱以及排障困难。

---

四、为什么还需要配对？

配对解决的不是“消息交给哪个 Agent”，而是：

谁有资格使用机器人？

可以把整个关系理解成三道门：

第一道：Account
哪个飞书应用接收消息？

        ↓

第二道：访问控制 / Pairing
这个用户或群有没有权限使用？

        ↓

第三道：Bindings
消息应该交给哪个 Agent？

        ↓

      Agent 执行

例如需要人工批准配对时，可以使用相应的 pairing 管理命令：

openclaw pairing approve feishu <配对码>

这样做最大的价值就是访问控制。

否则机器人如果直接向所有用户开放，不仅可能带来数据和权限风险，还可能因为恶意或误操作大量调用模型，造成 Token 和 API 成本快速增长。

---

五、企业部署怎么规划？

一个比较容易维护的思路是：

开发环境
└── 测试飞书应用
      └── 测试 Agent

生产环境
├── 代码审核应用 → Code Agent
├── 运维应用     → Ops Agent
└── 客服应用     → Service Agent

这样做最大的好处不是技术上“高级”，而是：

出了问题很好找。

代码机器人异常，就检查代码应用和 Code Agent；运维机器人异常，就检查运维应用和 Ops Agent，不会所有业务搅成一锅粥。

---

最后记住三个概念

Account
= 用哪个飞书应用

Pairing / Policy
= 谁能使用

Bindings
= 消息交给哪个 Agent

所以 OpenClaw 多应用接入的核心思想其实只有两个字：

隔离。

把应用身份、访问权限和 Agent 路由边界划清楚，后面的权限管理、故障排查和生产维护都会简单很多。