老王端着茶杯慢悠悠地走过来：“之前那篇 OpenClaw 面试题的文章，我看反响不错。要不要再整一篇深度点的？飞书多应用接入、多 Agent 路由、Gateway 架构这些，都是面试官爱问的点。”

我说：“正有此意。上一篇文章刚发出去一个小时，阅读就冲到了 7000 多，点赞转发也很猛，说明大家对这种面试题拆解是真的有需求。”

上一篇在这里，没看过的小伙伴可以先补一眼：

https://mp.weixin.qq.com/s/z02mZYqn3Wv-euhhPIBYGQ

我说：“这次咱们从飞书多应用接入、dmPolicy 策略、Gateway 网关架构、消息排查实战，还有最新版本特性这几个层面，把 OpenClaw 扒个底朝天。”

老王笑了：“我就喜欢你这股子钻研劲儿。开始吧。”

01、飞书多应用接入

老王没让我铺垫太久，直接追问：“为什么要一个飞书应用跑一个 Agent？”

我说：“因为隔离。企业场景里最怕的不是配不起来，而是权限、路由、审计和故障域全搅在一起。一个 Agent 对应一个飞书应用，边界才清楚。”

多应用配置的核心逻辑

OpenClaw 的飞书插件支持多应用配置，核心在于defaultAccount字段。当你在openclaw.json里配置了多个飞书应用时，必须指定一个默认应用：

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

老王打断我：“等会儿，这个defaultAccount到底起什么作用？”

我说：“当 Gateway 收到一条消息时，如果无法通过 bindings 规则匹配到特定 Agent，就会用 defaultAccount 指定的应用来响应。它是兜底策略。”

配对策略：让机器人认识你是谁

老王继续追问：“配对我知道。我想听的不是名词解释，而是它在企业场景里到底解决什么问题？”

我说：“配对是 OpenClaw 的一个安全机制。默认情况下，机器人不会响应任何消息，除非你主动完成配对。”

配对的方式有两种：

第一种，私聊配对。你在飞书里搜机器人，发一条私聊消息，机器人会回复一个配对码。把这个配对码告诉OpenClaw，你们就建立了一对一关系。

openclaw pairing approve feishu xxx

第二种，群组配对。把机器人拉到群里，@它发送配对指令。机器人会识别群 ID，把这个群加入白名单。

老王问：“为什么要这么麻烦？直接让机器人响应所有消息不行吗？”

我说：“安全第一。你想想，如果机器人对所有人开放，万一有人恶意刷接口，你的 token 分分钟被烧光。配对机制相当于加了一层访问控制。”

企业级部署的最佳实践

如果让我做企业级部署，我会这样规划：

• 开发环境：一个飞书应用，绑定测试群组
• 生产环境：一个飞书应用，绑定正式群组
• **专用 Agent：**每个业务场景单独一个应用，比如代码审核 Agent、运维 Agent、客服 Agent

老王点点头：“这样确实清晰。那如果两个应用都加了同一个群，消息会发给谁？”

我说：“这就涉及到路由优先级了。OpenClaw 采用'最具体优先'原则——如果 bindings 里明确指定了群 ID 绑定到某个 Agent，就按 bindings 走；如果没指定，就用 defaultAccount 兜底。但两个应用同时响应同一个群，这种情况要尽量避免，容易乱。”

02、多 Agent 路由机制

老王放下茶杯：“刚才你说到 bindings，这个多 Agent 路由到底是怎么工作的？”

我说：“这里最核心的不是名词，而是组合关系。真正决定多 Agent 路由的，就是 dmPolicy 和 bindings...