简介这是一份针对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适合部署在本地或内网机器上的 OpenClawWebhook 需要提供一个 HTTPS 公网地址还要能响应飞书的 URL 验证请求。我优先用长连接省掉公网暴露这一步少一个攻击面。第四步开通权限并发布版本。至少需要 im:message 相关的读消息、发消息权限以及“接收消息 v2.0”事件。权限修改后必须发布新版本并在“可用范围”里加入目标成员或群聊否则机器人对目标群不可见。提示飞书权限是“开通→发布→生效”三级流程开发阶段开通的权限如果没有发布版本测试群里依然收不到消息。这个顺序是后面所有避坑的前提。2.3 三个身份参数和它们的组合规则每个飞书应用创建好之后在“凭证与基础信息”页面能看到三个关键参数它们构成了 OpenClaw 连接飞书的全部凭据。参数在飞书后台的位置用途app_id凭证与基础信息应用唯一标识以 cli_ 开头OpenClaw 用它区分不同的 botapp_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( fhttps://open.feishu.cn/open-apis/im/v1/messages?receive_id_typechat_id, headers{Authorization: fBearer {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。这个习惯帮我少踩了至少一半的串线坑。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/17 22:02:55 · 阅读 1.2k OpenClaw多飞书机器人配置实战：身份隔离与参数调优
简介这是一份针对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适合部署在本地或内网机器上的 OpenClawWebhook 需要提供一个 HTTPS 公网地址还要能响应飞书的 URL 验证请求。我优先用长连接省掉公网暴露这一步少一个攻击面。第四步开通权限并发布版本。至少需要 im:message 相关的读消息、发消息权限以及“接收消息 v2.0”事件。权限修改后必须发布新版本并在“可用范围”里加入目标成员或群聊否则机器人对目标群不可见。提示飞书权限是“开通→发布→生效”三级流程开发阶段开通的权限如果没有发布版本测试群里依然收不到消息。这个顺序是后面所有避坑的前提。2.3 三个身份参数和它们的组合规则每个飞书应用创建好之后在“凭证与基础信息”页面能看到三个关键参数它们构成了 OpenClaw 连接飞书的全部凭据。参数在飞书后台的位置用途app_id凭证与基础信息应用唯一标识以 cli_ 开头OpenClaw 用它区分不同的 botapp_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( fhttps://open.feishu.cn/open-apis/im/v1/messages?receive_id_typechat_id, headers{Authorization: fBearer {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。这个习惯帮我少踩了至少一半的串线坑。希望帮到你。本文还有配套的精品资源点击获取