简介：这是一份针对OpenClaw平台配置多个飞书机器人的项目代码包，面向具备一定开发与运维基础的开发者，用于解决同一实例下多Agent与多飞书应用对接、权限隔离和消息路由等场景问题。压缩包内共3个文件，包含inscode环境配置、index.html预览入口和.gitignore版本管理规则，整体体积仅9KB，轻量精简，适合直接阅读和二次开发。目前已有285人学习下载。资源围绕Agent工作区划分、飞书开放平台凭证配置、Channel绑定、白名单访问控制等关键环节，提供了可运行的配置示例与代码骨架；同时涵盖常见问题处理思路，便于快速定位配置失败原因。整体结构清晰，能帮助开发者在较短时间内掌握多机器人并行的搭建方法，并为后续扩展功能或深度定制提供基础。
1. 一套OpenClaw挂多个飞书机器人：身份隔离比多收消息更值钱
一套 OpenClaw 进程能同时接入几个飞书机器人？答案是：只要飞书开放平台那边你有几个自建应用，这边就能挂几个。很多人第一次接触多飞书机器人配置，是发现一个机器人只够应付一个群——技术答疑群聊到一半，客户对接群又来问报价，机器人带着上一轮的上下文串场，答非所问还是小事，运营群看到技术群的内部话术才叫翻车。多飞书机器人配置要解决的核心问题，不是“多收消息”，而是让每个群、每类场景拥有独立身份的飞书机器人，各带各的人设、模型和记忆，底层仍是同一个 OpenClaw 在跑。这篇文章用一套可以直接落地改写的项目代码骨架，把从飞书开发者后台到 claw.json 的完整配置路径讲清楚，新手能照抄，熟手能避坑。
2. 飞书机器人接入OpenClaw之前：把三个身份参数和事件通道看明白
多机器人配置不是把配置复制粘贴几份那么简单。在动手之前，先搞清楚 OpenClaw 的消息通道设计，以及飞书开放平台这边一个机器人的身份到底由什么决定，后面所有排错才会有方向。
2.1 消息通道与多实例的取舍：为什么是“一个进程挂多个bot”
OpenClaw 这类开源个人助理，架构上通常分两层：上层是 agent，负责理解消息、调用工具、生成回复；下层是 channel，负责和各个 IM 平台对接。飞书就是众多 channel 中的一个。channel 只管“消息怎么进出”，agent 才管“消息怎么回答”。所以多飞书机器人，不一定意味着多套 OpenClaw 进程。
常见做法是在同一个 channel 配置里维护一个 apps 数组，每个元素是一个飞书自建应用的凭据。启动时 OpenClaw 会为每个应用建立一条独立的长连接，收到消息后按应用身份路由给对应的 agent。这样做的好处是资源开销小——十几个 bot 也只占一套进程；坏处是配置一旦写错，多个 bot 之间会出现串线、抢消息这类很难排查的玄学问题。
对比“开多个实例”的方案：每个实例各配一个机器人，隔离性确实更好，但模型上下文、工具、定时任务全都得重复维护，磁盘和内存开销也翻倍。对大多数个人开发者和中小团队来说，一个进程内多个 bot 是性价比最高的选择，也更容易统一升级和备份。我一般会用“一个进程挂多个 bot”作为默认方案，只有当某个 bot 需要单独升级、单独重启时才拆成独立实例。
2.2 飞书自建应用的创建流程：机器人能力、权限与事件订阅
多机器人配置的前提，是你在飞书开发者后台里已经准备好了对应数量的“企业自建应用”。每个应用对应一个机器人身份，可以设置不同的名字、头像和权限范围。下面是创建流程里我认为一个都不能少的四个步骤。
第一步，创建自建应用。进入飞书开发者后台，选择“企业自建应用”，填名称和描述。此时应用还没有任何能力，只是一个空壳。
第二步，启用机器人能力。在“应用能力”里找到机器人，点击启用。启用后，这个应用才具备在群聊中被 @、以及主动发消息的资格。跳过这一步，后面配置全白做。
第三步，配置事件订阅。这一步决定机器人能不能收到消息。飞书支持两种接收模式：长连接（WebSocket）和 Webhook。长连接不需要暴露公网 URL，适合部署在本地或内网机器上的 OpenClaw；Webhook 需要提供一个 HTTPS 公网地址，还要能响应飞书的 URL 验证请求。我优先用长连接，省掉公网暴露这一步，少一个攻击面。
第四步，开通权限并发布版本。至少需要 im:message 相关的读消息、发消息权限，以及“接收消息 v2.0”事件。权限修改后必须发布新版本，并在“可用范围”里加入目标成员或群聊，否则机器人对目标群不可见。
提示：飞书权限是“开通→发布→生效”三级流程，开发阶段开通的权限如果没有发布版本，测试群里依然收不到消息。这个顺序是后面所有避坑的前提。
2.3 三个身份参数和它们的组合规则
每个飞书应用创建好之后，在“凭证与基础信息”页面能看到三个关键参数，它们构成了 OpenClaw 连接飞书的全部凭据。
| 参数 | 在飞书后台的位置 | 用途 |
|---|---|---|
| app_id | 凭证与基础信息 | 应用唯一标识，以 cli_ 开头，OpenClaw 用它区分不同的 bot |
| app_secret | 凭证与基础信息 | 应用密钥，OpenClaw 用它换取访问令牌 |
| verification_token / encrypt_key | 事件订阅页面 | 回调安全校验与消息体加解密 |
长连接模式下，encrypt_key 通常不参与链路，但要留好；Webhook 模式下，verification_token 用于校验请求来源，encrypt_key 用于解密消息体。一个容易混淆的点是：这两个参数不是“凭证”，而是“约定”，只要飞书后台和 OpenClaw 配置里填成一样的原文字符串即可，不需要任何编码转换。如果 OpenClaw 端对字符串做了额外转义，URL 验证就会失败。
这三个参数的组合规则就一句话：app_id 决定身份，app_secret 决定权限，verification_token 和 encrypt_key 决定能不能握手成功。多机器人场景下，每个应用要有自己独立的一套，混用哪怕一个，都会出现日志里看似正常、实际消息串门的现象。
3. 从单个飞书机器人改成多个：配置文件的最小改动与启动验证
标题里的“项目代码”，落到实操上就是一份可以直接跑的配置文件骨架。这一章从单个 bot 的最小配置开始，再改成多 bot 数组，最后给出启动验证方法。
3.1 单bot最小配置：claw.json里一个飞书应用长什么样
OpenClaw 的主配置文件一般叫 claw.json，放在用户配置目录下。在一个常见版本里，飞书通道的配置结构大致如下。不同版本的字段名会有些出入，但“每个应用一套凭据、绑定一个 agent”这个思路是通用的。
{ "channels": { "feishu": { "apps": [ { "name": "dev-bot", "app_id": "cli_xxxxxxxx", "app_secret": "${FEISHU_DEV_SECRET}", "encrypt_key": "${FEISHU_DEV_ENCRYPT}", "verification_token": "${FEISHU_DEV_VERIFY}", "mode": "websocket", "agent": "dev-agent" } ] } } }逐个说字段。name 只是本地日志别名，不要求与飞书应用名一致，但建议保持一致方便排查，后面日志里看到的全是这个名字。app_id 必须是飞书后台真实存在的应用标识，它决定这条长连接属于哪个机器人。app_secret 等敏感字段建议用${ENV_VAR}形式引用环境变量，配置明文入库容易被误传。
mode 字段这里写死为 websocket，表示走长连接模式。它不需要公网回调地址，也不需要在飞书后台填 URL，本地服务器只要出网能连上飞书的长连接网关就能工作。agent 字段把这个 bot 绑定到具体的 agent 配置上，绑错名字会导致人设和记忆串线，这在下一章会详细讲。
注意：环境变量方式最容易出的问题是 export 时带了引号或空格，飞书后台比对不过。建议 export 时保持值两边不含空格的写法。
3.2 多bot配置：把apps从单个对象改成数组
多机器人的改动量很小：在 apps 数组里追加第二个元素。下面是一个双 bot 示例，dev-bot 和 ops-bot 分别对应两个独立的飞书自建应用。
{ "channels": { "feishu": { "apps": [ { "name": "dev-bot", "app_id": "cli_dev_appid", "app_secret": "${FEISHU_DEV_SECRET}", "encrypt_key": "${FEISHU_DEV_ENCRYPT}", "verification_token": "${FEISHU_DEV_VERIFY}", "mode": "websocket", "agent": "dev-agent" }, { "name": "ops-bot", "app_id": "cli_ops_appid", "app_secret": "${FEISHU_OPS_SECRET}", "encrypt_key": "${FEISHU_OPS_ENCRYPT}", "verification_token": "${FEISHU_OPS_VERIFY}", "mode": "websocket", "agent": "ops-agent" } ] } } }这里有三个容易写错的点。第一，两个 bot 的 app_id 必须来自不同的飞书应用。如果图省事把同一个 app_id 复制两份，飞书事件只会推给其中一条长连接，另一个 bot 永远收不到消息，日志里也不会有明显报错。第二，agent 字段建议分别指向不同的 agent 配置，否则人设和记忆仍然共享。第三，环境变量命名别混：dev 和 ops 的 SECRET 用不同变量名，export 时括号里的名字最容易复制错。
如果你只需要“一个机器人管多个群”，其实不需要新建多个应用。但那种场景下身份只有一个，做不到按群隔离记忆和模型。多 bot 配置的价值，正在于每个 bot 绑定独立 agent，把不同场景的会话彻底分开。
3.3 启动验证：看日志、发测试消息、确认各bot独立在线
配置写完，启动命令常见的是：
openclaw start --config ~/.openclaw/claw.json如果你的部署方式是容器或 systemd，把 start 换成对应的前台命令即可。启动后别急着去群里发消息，先看日志里每个 bot 的建连结果，关键字大致如下：
[feishu] connecting dev-bot via websocket ... ok [feishu] connecting ops-bot via websocket ... ok [feishu] all apps subscribed看到每个 bot 都有独立的 connecting / ok 记录，说明长连接已经建立。如果只出现一个 ok，说明另一个应用的 app_id、secret 或事件订阅配置有问题，按第 5 章的排查步骤走。
验证消息链路要分别在两个不同的群或单聊里 @ 对应的机器人，发“ping”或直接用自然语言测试。重点观察：同一个问题在两个 bot 那里是否得到符合各自人设的回答——这是验证“身份隔离”是否生效的最快方式。如果两个 bot 的回答风格一模一样，说明 agent 绑定没生效，回去检查配置里的 agent 字段。
4. 多机器人的参数调配：会话隔离、模型路由和指令分工
多个飞书机器人接进来只是第一步，接下来要决定每个 bot 用什么模型、什么指令、什么记忆。这一章讲参数怎么调，让多机器人真正各司其职。
4.1 三种常见分配策略：按群、按职能、按环境
多机器人接进来之后，第一个要决定的是“哪个 bot 管哪些消息”。三种策略各有适用场景。
按群分配最简单：新建一个飞书应用，只拉进它负责的群，其他群不拉。隔离由群成员关系天然保证，不需要在配置里做任何额外规则。这适合群之间业务边界清晰的团队，比如一个测试群配一个 bot，运营群配另一个。
按职能分配更精细：对外客服 bot、对内运维 bot、技术答疑 bot 各一个。它们可能出现在多个群，但人设和权限不同。客服 bot 只答产品问题，运维 bot 可以调部署工具，答疑 bot 不碰任何生产环境。这种策略下，指令分工比群隔离更重要，因为多个群共享同一个 bot。
按环境分配适合有开发、测试、生产环境区分的技术团队：dev-bot 连测试环境，可以自由操作；prod-bot 连生产环境，所有写操作必须二次确认。不同环境用不同 bot，出问题时能直接通过 bot 身份判断操作边界，比在一条 prompt 里堆规则清晰得多。
实际选哪种，取决于你的维护成本。bot 数量一多，飞书后台里每个应用的权限、事件、版本都要单独维护，按职能分配通常三到五个 bot 就够，不要追求“一个群一个 bot”。
4.2 让每个bot有自己的模型与人设：agent配置示例
多 bot 和独立 agent 绑定之后，才真正实现“人格分裂”。在 claw.json 里，agent 可以单独定义模型、提示词和记忆命名空间。下面是一个双 agent 配置示例：
{ "agents": { "dev-agent": { "model": { "provider": "ollama", "name": "qwen2.5:14b", "base_url": "http://127.0.0.1:11434" }, "system_prompt": "你是开发群助手，只回答代码、调试、API 契约问题。不确定时直接说不确定。", "memory": { "namespace": "dev-bot-memory" } }, "ops-agent": { "model": { "provider": "deepseek", "name": "deepseek-chat", "api_key_env": "DEEPSEEK_API_KEY" }, "system_prompt": "你是运维值班助手，回答要求可执行。涉及删除、重启等操作先给出风险提示。", "memory": { "namespace": "ops-bot-memory" } } } }模型路由的价值就在这里：dev-agent 用本地模型（Ollama 部署在 127.0.0.1），不消耗云端 API 额度，适合高频低风险的代码问答；ops-agent 用云端模型，判断力更强，适合需要严谨性的运维场景。你完全可以把便宜、快的模型分给高频低风险场景，贵的模型留给需要分析能力的场景。
provider、base_url、api_key_env 这些字段在不同版本里命名可能有差异，但“每个 agent 指定独立模型、独立密钥”的思路是通用的。如果你更习惯给所有 bot 用同一个模型，那系统提示词和记忆隔离的重要性反而更高，因为模型本身不会再帮你在人设上做区分。
4.3 记忆隔离是串线的最后一道防线
很多人在配置里同时设置了两个 agent，也绑定了不同的 system_prompt，但跑起来发现两个 bot 还是会“想起来”对方聊过的东西。问题通常出在记忆共享。如果两个 agent 的 memory.namespace 相同，或者模型上下文的持久化文件指向同一个路径，那么 dev-bot 的对话历史会作为 ops-bot 的上下文参与生成。
记忆隔离的正确配置原则是：每个 bot 一个命名空间，命名空间里按 chat_id 再分会话。这样 dev-bot 在群 A 和群 B 的聊天互不可见，dev-bot 和 ops-bot 之间更是完全隔离。配置里有几个 agent，就建几个 namespace，命名跟 bot 名对齐，一眼能看出归属。
如果想反过来让两个 bot 共享某份知识库，不要把记忆命名空间合并，而是通过工具读取同一份外部文件。这样既能共享数据，又不会污染各自上下文。把记忆当私有数据、把工具当公共接口，是这套配置里最值得遵守的一条习惯。
5. OpenClaw多飞书机器人配置避坑指南：5个高频翻车现场
多机器人配置的坑，大多不在 OpenClaw 这边，而在飞书开放平台的细节和配置的一致性上。这里整理 5 个我见过的高频问题，按“现象 → 原因 → 解决”写清楚。
5.1 事件订阅验证失败，bot一直显示未连接
现象：启动 OpenClaw 后，日志提示事件订阅验证失败，或者飞书后台“事件订阅”页面直接标红，bot 始终处于离线状态。
原因：Webhook 模式下，飞书发起的 URL 验证请求要求接收方原样返回 challenge 参数；常见失败是 verification_token 不一致，或配置里人为对字符串做了 URL 编码、加了引号包裹。长连接模式下这个报错相对少见，一旦出现，优先确认 app_secret 是否过期或被重置。
解决：到飞书开发者后台复制 verification_token 原文，逐字符比对 OpenClaw 配置里的值；Webhook 模式先确认公网 URL 可达，可以手动 POST 一个 challenge 测试；如果开了 encrypt_key，确认两端配置一致。这个问题的耗时点通常不是找原因，而是一个字符一个字符地对比字符串，建议直接复制粘贴而不是手敲。
5.2 机器人拉进群了，@它却毫无反应
现象：群里 @ 机器人，消息记录里能看到发送成功，但 OpenClaw 这边没有任何日志输出。
原因：最常见的有三种——事件订阅里没勾选“接收消息 v2.0”；im:message 相关权限没有随新版本发布；或者配置里把两个 bot 填了同一个 app_id，事件被另一条长连接消费掉了。
解决：在飞书后台依次检查事件订阅是否包含 im.message.receive_v2、权限管理里 im:message 权限是不是“已发布”状态、claw.json 里有没有重复的 app_id。改完重启后再 @ 一次，盯着日志看有没有对应 bot 的 receive 事件。这一步最好一次性把三个地方都看一遍，单独排查任何一个都会走弯路。
5.3 多个bot回复串线，dev群里冒出ops机器人的回复
现象：在开发群提问，回答却带着运维群的语气；日志显示该消息被另一个 bot 处理了。
原因：几乎都是 agent 绑定错误。apps 数组里两个 bot 的 agent 字段都填了同一个 agent 名，或者 agent 已定义但 memory.namespace 相同，导致上下文错位。
解决：先查日志确认收到消息时使用的 bot 标识是哪一个；然后把每个 bot 的 agent 字段改成各自的 agent 名；最后检查 memory.namespace，确保完全隔离。改完必须重启进程，配置不会热生效，这是这类问题里最常见的遗漏。
5.4 消息重复处理，群聊收到两条一模一样的回复
现象：一条 @ 消息，OpenClaw 回复了两遍，间隔几秒，内容完全相同。
原因：配置里存在两份飞书 channel 段落，或同一个 app_id 同时出现在两个 bot 条目中；另一种是长连接和 Webhook 同时启用，飞书把事件投递了两次。
解决：全局搜索配置里出现该 app_id 的次数，保留一条；确认 mode 字段只有一个值，要么 websocket，要么 webhook，不要同时配置。清理后重启，用一条测试消息确认只回一次。这个坑在多人协作维护同一份配置时特别容易出现，建议配置入库前做一次重复项检查。
5.5 重启后某个bot静默失效，其他bot正常
现象：OpenClaw 重启后，dev-bot 正常，ops-bot 静默离线，日志里没有任何报错。
原因：飞书侧应用状态异常。常见的是该应用的版本发布被撤销、可用范围变更导致 bot 无法访问目标群，或者 app_secret 在飞书后台被重置过而配置里没同步。
解决：在飞书后台检查该应用是否处于有效版本状态、可用范围是否包含测试群；重新复制 app_secret 并更新环境变量；重启后留意日志中该 bot 有没有成功建立长连接。这类问题大多不是 OpenClaw 的 bug，而是飞书侧配置漂移，养成“先看飞书后台再看本地日志”的排查顺序能省很多时间。
6. 多机器人用起来的进阶技巧：按群分流、定时报表与协同回复
多机器人配置稳定跑起来之后，有几个场景能让这套架构的价值翻倍。
6.1 让同一个bot按群身份切换口气
多 bot 已经按应用隔离了，但有时你不想新建应用，只希望同一个 bot 在不同群里表现不同。常见做法是在 system_prompt 里声明“群 A 是技术答疑，回答要严谨；群 B 是产品反馈，回答要通俗”，或者通过消息处理逻辑读取 chat_id 后拼进上下文。两种方式都有效，我更推荐前者，它对模型上下文更友好，也不需要在代码里维护群名单。
6.2 定时任务+发送消息API：把飞书机器人变成报表推送器
“飞书机器人发送表格”的场景，在多机器人架构下很自然。OpenClaw 的 skill 机制支持定时触发，但飞书消息的发送可以由外部脚本独立完成。常见做法是写一个 Python 脚本，用 app_id 和 app_secret 换取 tenant_access_token，再调用飞书消息 API 把日报或表格推送到指定群：
# 定时报表推送：dev-bot 每天 9 点发日报到指定群 import requests, json, os APP_ID = os.environ["FEISHU_DEV_APP_ID"] APP_SECRET = os.environ["FEISHU_DEV_SECRET"] # 1. 用应用凭证换 tenant_access_token token_resp = requests.post( "https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal", json={"app_id": APP_ID, "app_secret": APP_SECRET}, ).json() token = token_resp["tenant_access_token"] # 2. 向指定 chat_id 发送富文本消息 chat_id = "oc_xxxxxxxx" # 从 OpenClaw 日志或飞书 API 获取 content = json.dumps({"zh_cn": {"title": "每日指标", "content": [[{"tag": "text", "text": "今日数据：..."}]]}}) requests.post( f"https://open.feishu.cn/open-apis/im/v1/messages?receive_id_type=chat_id", headers={"Authorization": f"Bearer {token}"}, json={"receive_id": chat_id, "msg_type": "post", "content": content}, )这段代码的关键在第一步和第二步的分离：token 由应用凭证换得，发送时用租户身份而不是机器人身份，所以脚本只要拿着其中一个 bot 的凭据，就能以那个 bot 的名义发消息。chat_id 可以从 OpenClaw 收到的消息事件里抓，或者在群里 @ 一次机器人后查日志，比去 API 里翻群列表快得多。API 的具体路径和字段以飞书开放平台当前文档为准，这套“定时任务 + 消息 API”的组合比在 OpenClaw 里硬接报表逻辑干净得多。
6.3 两个bot共享工具、分开人设的协同用法
dev-bot 负责接收需求，ops-bot 负责执行操作；或者一个 bot 负责检索信息，另一个负责生成正式回复。OpenClaw 的 tool 机制支持跨 agent 共享，只要把同一个工具挂到多个 agent 的 tools 列表下即可。人设保持分开，但工具底层访问的是同一份数据，这样既保留了对话身份的隔离，又避免了重复接入后端服务的麻烦。
我现在的习惯是：每次加新群之前先想清楚这个群归哪个 bot 管，再决定是新建飞书应用还是复用已有 bot 的可用范围。如果只是多一个群，复用；如果是不同职能或不同数据范围，就新建应用并配独立 agent。这个习惯帮我少踩了至少一半的串线坑。希望帮到你。
本文还有配套的精品资源，点击获取
