先把结论放这如果你的 OpenClaw 机器人已经能在飞书群里正常回话了但你觉得它越来越像一个“啥都干但啥都干不好”的万金油——那说明你该上多实例了。多飞书机器人部署听起来好像只是把配置文件复制几份、多跑几个进程的事但真上手之后你会发现坑全在细节里事件订阅怎么分发、群聊和单聊怎么隔离、多个实例的配置会不会互相污染、飞书开放平台侧的应用权限怎么区分……每一步都有讲究。这篇就是把我自己从单机器人扩展到多机器人的完整过程、踩过的坑、调过的参数全部摊开讲一遍适合已经跑通基础部署、想往进阶走的同学参考。1. 先想清楚为什么要拆成多个飞书机器人单实例单机器人跑得好好的非要拆成多个很多人第一反应是“折腾”。但实际用下来你会发现这不是折腾是刚需。1.1 单机器人模式的三大痛点第一个痛点是角色混乱。一个机器人既要在研发群里回答部署问题又要在客服群里处理售后咨询还在私聊里帮你记待办。为了让它在所有场景下都“够用”你只能在系统提示词里堆一大堆互相矛盾的要求结果就是它回答研发问题时带客服腔回答客服问题时又总想给你贴代码。第二个痛点是故障扩散。一个实例挂了所有群全部失联。某次我在一个群里触发了超长上下文的任务直接把那个实例的进程拖崩了结果其他群的机器人也全部跟着掉线当天被同事问了好几次“机器人是不是死了”。第三个痛点是数据串味。单实例下客服会话里的上下文、研发群里的讨论记录全混在同一个记忆库里。机器人会把 A 群你聊过的内容当作 B 群里回答问题的参考依据时间一长回答质量肉眼可见地下降。1.2 多机器人架构的两种玩法拆成多个飞书机器人本质上就两条路线架构方案飞书侧OpenClaw 侧优点缺点独立应用 独立实例每个机器人注册一个自建应用每个应用绑定一个 OpenClaw 实例隔离彻底权限分明出故障互不影响飞书侧要维护多个应用审批和权限申请翻倍单应用 多后端实例只注册一个自建应用一个入口接收事件按规则转发给不同实例飞书侧只管一个应用配置省事需要自己实现路由逻辑入口挂了全挂我自己的建议是如果机器人数目不超过 5 个优先走“独立应用 独立实例”这符合 OpenClaw 的天然设计配置改动最少排查问题也最直观。等规模真的大了再考虑单入口统一路由。1.3 典型适用场景拆解多机器人最适合的场景我目前实际在跑的有四类。第一类是角色隔离型。研发群一个机器人专注回答代码、部署、监控相关的问题客服群一个机器人人设、语气、知识库完全独立。两者井水不犯河水。第二类是权限隔离型。比如给内部管理层用的机器人能触达某些内部数据给普通员工用的机器人只开放基础问答。这种场景如果共用一个实例权限控制会很别扭拆开反而干净。第三类是地域/部门隔离型。不同部门有各自的机器人入口、各自的配置中心和知识库互不干扰。第四类是压测演练型。用独立的测试机器人跑新的配置、新的工具链不影响生产环境里的老机器人。这个我强烈推荐所有大改动先在测试实例上验证没问题再同步到生产。2. 部署前的准备环境、账号与配置原则多实例部署之前先把环境、账号、配置这三件事理顺。这一步做扎实了后面基本就是一马平川。2.1 运行环境与基础服务硬件方面一台 2 核 4G 的云主机是起点。我实测跑 3 个实例每个实例日常占用大概 300MB 到 500MB 内存CPU 平时很闲但多实例同时响应时会有短时飙高。如果打算跑 5 个以上实例建议直接上 4 核 8G省得后面折腾。系统我推荐 Debian 系Ubuntu 或 Debian 本身都可以因为这套环境我用得最多坑最少。OpenClaw 的部署方式主流是 Docker 和 Docker Compose多实例场景下 Compose 是必需品——它能让你用一套编排文件把多个实例的生命周期统一管起来一键启动、一键停止、日志统一查看。OpenClaw 本身对实例的区分核心靠的是配置文件目录和数据目录的隔离。你不需要复制整个程序目录只需要为每个实例创建独立的配置目录并在启动时指定对应的目录或实例名即可。这一点是理解整个多实例部署的关键。2.2 飞书开放平台侧创建自建应用多机器人部署飞书侧的准备工作是最容易被低估的。很多人以为“多建几个应用”就行实际远远不够。登录飞书开放平台进入“企业自建应用”页面每个机器人对应一个独立的自建应用。创建应用时需要注意应用名称和头像会直接显示在机器人的名字和头像上这一步最好提前规划好命名规范比如“研发助手”“客服小助手”“个人提醒机器人”别起一堆分辨不出来的名字后面运维会疯。创建完应用后必须开启“机器人”能力。这一步在应用的“添加应用能力”里操作开启之后这个应用才能在飞书里以机器人的身份被添加、被、收发消息。最关键的是权限配置。以我实际用到的权限为例给你一份常用清单权限点作用建议im:message:group_at_msg接收群聊中机器人的消息必开群聊场景核心权限im:message:p2p_msg接收单聊消息必开私聊场景核心权限im:message:send_as_bot以机器人身份发送消息必开机器人不能回复就没有意义im:chat:readonly读取群基本信息按需如果需要识别群名称就开contact:user.base:readonly读取用户基础信息按需如果要做用户维度路由就开权限开通之后还有一个关键动作——发布版本。飞书自建应用的权限和功能改动都需要创建版本并发布审核通过后才会真正生效。这一步很多人会漏掉导致权限明明开了机器人却收不到消息白白排查半天。2.3 每个应用独立的三个核心凭证每个飞书自建应用都会生成一组独立的凭证这是多实例隔离的根基。核心就是三样App ID、App Secret、Encrypt Key。App ID 是应用的身份标识每个应用唯一。App Secret 是应用的访问密钥相当于这个机器人的密码。Encrypt Key 是事件订阅的加密密钥飞书推送事件时用它做 AES 加密OpenClaw 侧必须配置同名密钥才能解密。这三个凭证必须按实例分开保存、分开配置。我见过最典型的翻车事故就是复制配置文件时忘了替换 App Secret结果两个实例用的是同一个密钥消息串号、事件错乱排查了一整天才发现。提示建议为每个实例单独建一个.env文件文件权限设为 600只允许当前用户读写避免同一个密钥在多处流转。3. 多实例部署的两种玩法详解准备做完进入正题。这里我分别讲清楚两种玩法的完整配置过程和背后的设计考量。3.1 玩法一独立应用 独立实例推荐这个方案的本质就是让每个 OpenClaw 实例只认自己那一套飞书应用凭证互不干涉。第一步规划实例目录结构。建议统一建一个根目录比如~/openclaw-instances/下面每个实例一个子目录目录名就是实例名。每个目录里放一个.env文件和一个独立的配置目录配置目录里存放该实例专属的模型参数、系统提示词、知识库路径等。目录结构示意~/openclaw-instances/ ├── dev-assistant/ │ ├── .env │ └── data/ # 该实例的数据与配置目录 ├── cs-support/ │ ├── .env │ └── data/ └── personal-reminder/ ├── .env └── data/第二步配置环境变量。OpenClaw 在启动时会读取环境变量来确认加载哪一套配置。关键环境变量包括实例名、配置目录路径、飞书应用凭证、加密密钥等。通过在不同.env文件里填入各自的值实例之间就完成了第一层隔离。第三步编写docker-compose.yml。核心思路是每个实例是一个独立的 service各自挂载独立的配置目录使用独立的.env文件。看一个实际可用的片段services: dev-assistant: image: openclaw:latest container_name: openclaw-dev-assistant env_file: - ./dev-assistant/.env volumes: - ./dev-assistant/data:/app/data restart: unless-stopped cs-support: image: openclaw:latest container_name: openclaw-cs-support env_file: - ./cs-support/.env volumes: - ./cs-support/data:/app/data restart: unless-stopped这里有两个细节值得注意。第一container_name必须唯一否则会互相覆盖。第二每个实例挂载的data目录必须独立这是数据层面隔离的保证。如果这里偷懒共用一个数据目录前面说的“上下文串味”问题就会回来。启动命令很简单docker compose up -d看每个实例的日志也方便docker compose logs -f dev-assistant3.2 玩法二单入口应用 多后端实例如果机器人数目多到维护飞书应用都很痛苦可以考虑走统一入口的方案。这个方案里飞书侧只创建一个应用但这个应用在 OpenClaw 侧并不是直接对应一个实例而是对应一个“路由器”实例。路由器实例收到飞书推送的消息事件后根据消息中的chat_id或open_id判断应该由哪个后端实例处理然后把消息转发过去拿到回复后再发回飞书。这个方案的架构感更强但路由逻辑需要自己写。我最初用 Python 写了一个薄路由层逻辑大致是# 伪代码示意 route_map { oc_群聊ID_研发群: dev-assistant, oc_群聊ID_客服群: cs-support, } def route_event(event): chat_id event[event][message][chat_id] instance route_map.get(chat_id, default) return send_to_instance(instance, event)这个方案的好处是飞书侧只维护一个应用权限审批只需要走一遍坏处是路由器本身是单点挂了全挂而且消息转发的时延会比直连方案略高。我的建议很明确不是机器人数目超过 10 个不要轻易上这条路。单点故障带来的运维压力远比多维护几个飞书应用麻烦。4. 飞书事件订阅与消息链路配置实例跑起来了飞书侧的机器人也建好了接下来就是打通消息链路。这里面的关键节点是事件订阅。4.1 长连接模式优先别碰回调模式飞书开放平台的事件订阅官方提供了两种接收方式回调模式和长连接模式。回调模式要求你提供一个公网可达的 HTTPS 地址飞书把事件推送到这个地址。这意味着你得准备域名、SSL 证书、公网入口还得处理飞书的 URL 验证和加密签名。在本地开发或内网环境下这一整套东西非常烦人。长连接模式就简单得多。飞书通过 WebSocket 建立一条长连接事件直接在连接上推送不需要公网地址不需要证书OpenClaw 启动后连上就行。我的建议是无条件优先用长连接。我第一个版本图省事想试回调模式结果光是准备公网地址和证书就花了半天换成 WebSocket 后五分钟搞定。如果你在飞书开放平台后台看到了事件订阅的配置入口优先看是否支持长连接模式。4.2 群聊和单聊的事件捕获差异飞书事件订阅里“接收消息”是一个大类下面分群聊和单聊。配置时要注意群聊和单聊是独立的权限点只开一个的话另一种场景完全收不到消息。群聊场景还需要额外理解一个逻辑机器人必须被 才会收到消息事件。如果你想让机器人对群聊里的普通消息也做响应那不是靠权限解决的而是要在 OpenClaw 侧配置消息监听规则。但我强烈建议默认只响应 否则群里每一条消息都会触发机器人消息风暴分分钟把实例打崩。单聊场景相对简单用户直接给机器人发消息事件就会推送过来。这里要注意的是如果你的机器人需要对每个人表现出不同的身份或记忆单聊事件里的open_id就是区分用户的关键字段。4.3 事件订阅配置的五步走以长连接模式为例完整的事件订阅配置流程如下在飞书开放平台后台找到“事件订阅”页面添加事件。添加“接收消息”相关的事件群聊选im.message.receive_v1单聊也选同一个事件这个事件会同时涵盖群聊和单聊场景但需要配合对应权限点使用。订阅方式选择长连接。保存后OpenClaw 启动时会自动建立长连接。用测试账号分别触发群聊 和单聊消息确认两端都能收到事件。这步做完消息链路就算是真正打通了。5. 多机器人协同Prompt 隔离、数据隔离与会话路由打通链路只是第一步多机器人真正的价值在于协同。这部分做得好不好直接决定你是在“用多个机器人”还是在“用一堆重复的机器人”。5.1 Prompt 和角色隔离每个实例都可以维护一套完全独立的系统提示词。这意味着你的客服机器人和研发机器人可以拥有完全不同的人设、语气和边界规则不需要互相妥协。举个实际的例子。我的研发助手实例系统提示词里强调的是“回答要精简、直接、给代码优先涉及部署操作时先确认环境”而客服实例的提示词则是“语气要耐心、友好遇到无法解决的问题要主动提供转人工话术”。两个提示词如果塞进同一个实例互相干扰就没法看了。实现方式很简单在每个实例的配置目录下单独维护一个提示词文件启动时由该实例自动加载。只要目录隔离到位这个天然就是分开的。5.2 数据与记忆隔离多实例下最怕的就是记忆串味。每个实例都有独立的持久化目录会话历史、向量知识库、长期记忆等数据分别存放在各自的目录里。这里分享一个我的实操经验把知识库文件也按实例拆分。比如客服实例的知识库存的是售后 FAQ、退换货流程研发实例的知识库存的是部署文档、接口说明。如果共用一个知识库机器人会答非所问。我这边的做法是给每个实例的数据目录里单独放一个knowledge/子目录不同实例的知识库文件互不引用。迁移、备份也方便整个目录打包走即可。5.3 会话路由配置如果你走的是独立应用独立实例路线会话路由不需要你操心飞书侧天然隔离。但如果你是单应用多实例方案路由规则就要自己设计好。我的建议是维护一个route.json按chat_id映射实例{ oc_群聊ID_研发群: dev-assistant, oc_群聊ID_客服群: cs-support, oc_用户ID_老板: personal-assistant, default: default-assistant }这里有个小技巧路由规则不要写死在代码里放到独立的 JSON 文件中方便随时调整。哪个群接入哪个机器人直接改配置文件不用重启路由服务。6. 实操全流程从 0 到 1 跑通“助手 客服”双机器人理论讲完来点实际的。我带你完整走一遍从零搭建“研发助手 客服助手”双机器人的全过程。这套流程我在多个环境里跑过可以直接照着操作。6.1 第一步准备两个飞书自建应用登录飞书开放平台后台创建两个自建应用名称分别为“研发助手”和“客服助手”。每个应用都开启机器人能力都配置好事件订阅长连接模式 im.message.receive_v1按前面说的权限清单开启对应权限然后各自发布一个线上版本。发布的时候记得确认应用状态需要为“已启用”版本审核通过后权限才生效。这一步做完在飞书里搜索这两个应用应该都能搜到且能添加。6.2 第二步创建两个 OpenClaw 实例目录按前面说的目录结构创建两个实例目录mkdir -p ~/openclaw-instances/dev-assistant/data mkdir -p ~/openclaw-instances/cs-support/data分别在两个目录下创建.env文件填入对应的飞书应用凭证。核心内容如下# dev-assistant/.env OPENCLAW_INSTANCEdev-assistant APP_IDcli_xxx_dev APP_SECRETxxx_dev_secret ENCRYPT_KEYxxx_dev_encrypt_key# cs-support/.env OPENCLAW_INSTANCEcs-support APP_IDcli_xxx_cs APP_SECRETxxx_cs_secret ENCRYPT_KEYxxx_cs_encrypt_key注意两个文件的APP_ID、APP_SECRET、ENCRYPT_KEY必须分别来自各自的应用绝对不能混用。这里就是我前面说的最容易翻车的点。6.3 第三步配置 docker-compose 编排在~/openclaw-instances/下创建docker-compose.yml内容就是前面给出的两个 service 配置。然后执行docker compose up -d正常启动后执行以下命令确认两个实例都连上了飞书docker compose logs dev-assistant | tail -n 20 docker compose logs cs-support | tail -n 20日志里如果出现“长连接已建立”或类似的关键字说明连接成功。6.4 第四步功能验证清单连接成功后不要急着加功能先用最基础的消息验证链路是否完整在飞书里添加“研发助手”机器人私聊发送“你好”看是否有回复。创建一个测试群把“研发助手”拉进群在群里 它发送“介绍一下你自己”看是否有回复。同样的流程为“客服助手”做一遍完整验证。在两边同时发消息确认互不干扰。如果以上四步全部通过恭喜你的多机器人环境已经跑通了。接下来可以往各个实例里添加自己的 prompt、知识库和工具集。7. 常见坑与问题排查实录这部分是我最想写的全是真金白银踩出来的经验。7.1 飞书应用发布后权限不生效症状后台权限明明开了但机器人收不到 消息。排查思路飞书自建应用的权限改动需要“创建版本并发布”发布后还要确认版本状态为“已启用”。很多人开了权限不发布相当于没开。解决办法重新进入版本管理创建一个新版本提交发布等审核通过后重新测试。7.2 事件收到但实例不回复症状飞书后台能看到事件推送但群里 机器人没反应。排查思路优先检查实例日志确认消息事件是否真正传到了 OpenClaw。如果日志里没有对应的消息记录大概率是事件订阅和实例之间的链路断了重点检查 Encrypt Key 是否匹配。另外一个隐蔽原因飞书开放的加密模式是 AES如果你的 Encrypt Key 配置错误事件能收到但无法解密表现就是“收到但没反应”。7.3 两个实例日志串了症状A 实例的日志里出现了 B 实例的消息记录。排查思路这几乎可以断定是环境变量没有隔离。检查每个实例的.env文件是否独立加载确认 compose 文件里env_file是否分别指向各自的文件。另一个可能两个实例用了同一个OPENCLAW_INSTANCE值导致加载了同一份配置。每个实例的实例名必须唯一。7.4 群聊 没反应单聊正常症状私聊机器人正常群里 不回复。排查思路这就是典型的群聊权限缺失。检查应用是否开通了im:message:group_at_msg权限同时确认事件订阅里接收消息的范围是否包含群聊。7.5 重启后机器人失联症状docker compose restart之后机器人长时间收不到消息。排查思路长连接模式断线后会自动重连但重连需要时间。查看日志里是否反复出现“连接断开”“重连失败”等字样。如果频繁断线检查网络环境对 WebSocket 长连接的支持情况必要时调整心跳参数。症状大概率原因处理方式事件收到但无回复Encrypt Key 不匹配 / 消息没进实例核对密钥查实例日志群聊 无反应单聊正常群聊权限缺失开通im:message:group_at_msg并发布版本日志串号环境变量未隔离 / 实例名重复检查.env加载和实例名唯一性重启后失联WebSocket 重连机制异常看日志确认重连状态必要时调心跳消息回复延迟明显单入口路由转发开销检查路由日志评估是否切独立实例方案8. 安全与长期运维心得多实例部署的上手难度其实不大真正考验人的是长期运维。这里分享几条我跑了大半年之后总结的经验。8.1 密钥管理是头等大事三个多实例之后手里的 App Secret、Encrypt Key 会越来越多。我的习惯是给每个实例单独建一个.env文件权限设为 600并且整个openclaw-instances目录不纳入版本库跟踪。如果你用 Git 管理配置一定要把.env文件加入.gitignore。曾经见过有同事把含密钥的配置文件推到仓库里虽然项目是私有仓库但密钥一旦进了历史记录清除成本非常高。8.2 最小权限原则飞书应用的权限不是越多越好每个实例只开通它需要的那几个权限点。比如纯客服机器人如果不需要读取用户信息就不要开contact:user.base:readonly。权限越少被滥用的面就越小。另外定期清理不再使用的自建应用。飞书后台里那些测试用的、废弃的应用该禁用就禁用别留着。8.3 日志轮转和磁盘监控多实例跑久了最大的隐形杀手是磁盘。每个实例都在写日志日志无限增长下去迟早把磁盘打满。我现在的做法是 Docker 默认的日志轮转策略。在docker-compose.yml里为每个服务加上logging: driver: json-file options: max-size: 20m max-file: 3这样每个实例的日志最多占用 60MB三个实例就是 180MB完全可控。8.4 升级前的灰度策略OpenClaw 更新升级时别直接全量重启所有实例。我会先升级一个测试实例跑半天确认没问题再逐个升级生产实例。升级操作也有一些细节每个实例单独重启不要同时重启避免飞书侧短时间内出现多次连接断开导致的限流。重启顺序建议从低优先级实例开始最后重启核心实例万一出了问题影响面也最小。最后再分享一个小经验多机器人跑起来之后最大的工作量其实不是部署而是持续维护每个实例的 prompt 和知识库。建议给每个实例建一个简单的更新日志记录每次改了什么、为什么改。两个月后再回头看你会感谢这个习惯。