1. 从单 Bot 混用到多 Agent 分诊OpenClaw 多飞书 Bot 接入到底解决什么问题如果你正在搜 OpenClaw 多飞书 Bot 接入配置大概率已经踩过下面这个坑一个飞书机器人扛下所有需求写稿、查数据、出图、跑日报全塞进同一个对话窗口。刚开始还能用用着用着就开始飘——你让它写文章它脑子里还残留着上一轮数据分析的上下文你让它跑日报它把昨天写了一半的文案又续上了。这不是模型不行是架构没分对。OpenClaw 的底层是大模型上下文窗口有 token 上限。单个 Agent 身兼多职对话历史越堆越长轻则输出跑偏重则任务直接失败什么都没跑完。我试过把六个数字员工塞进一个 Bot结果就是每天都在跟上下文污染作斗争。正确的姿势是一个 Agent 只干一件事每个 Agent 配一个专属飞书 Bot 作为入口。写作的只管写作采集的只管采集生图的只管生图。用户从不同的 Bot 进去直接对话对应的 Agent上下文天然隔离职责清晰稳定性也好很多。这篇文章要解决的核心问题就是如何用一份 openclaw.json让同一个 OpenClaw 实例接入多个飞书 Bot并让每个 Bot 精准路由到对应的 Agent。我会给出可复制的 openclaw.json 字段模板、多 Bot 路由映射示例以及逐条验证各 Bot 消息收发是否正常的操作步骤。适合谁看已经在跑 OpenClaw、想从单 Bot 升级到多 Agent 架构的读者或者正准备给团队搭一套多角色数字员工、需要每个角色独立入口的开发者。前置条件是你已经有一个能正常运行的 OpenClaw 实例并且至少创建过一个飞书自建应用。整个改造分三步走先在飞书开发者后台把多个 Bot 建好并打通长连接再在 OpenClaw 侧编写每个 Agent 的工作空间文件最后在 openclaw.json 里完成 Agent、account、binding 三者的映射。下面逐段拆开讲。2. 前置准备飞书多 Bot 创建与 OpenClaw 账号体系对齐在动 openclaw.json 之前得先把飞书那边的 Bot 准备好。每个 Agent 对应一个独立的飞书自建应用也就是一个独立的 Bot。这一步不能省因为 OpenClaw 的路由是靠 appId 来区分消息来源的。打开飞书开发者后台点击创建企业自建应用填写应用名称、描述、图标。应用名称建议直接跟 Agent 职责对应比如「写作助手」「日常助手」「生图助手」后面排查问题时一眼就能认出来。创建完成后进入应用初始界面找到「添加应用能力」页面把机器人卡片添加进来。接下来是权限配置。进入权限管理页面点击批量导入/导出权限把下面这份 JSON 贴进去。这份权限清单覆盖了消息收发、文档读写、表格操作、图片资源等常用能力多 Bot 场景下每个应用都要配一遍{ scopes: { tenant: [ aily:file:read, aily:file:write, application:application.app_message_stats.overview:readonly, application:application:self_manage, application:bot.menu:write, cardkit:card:write, contact:user.employee_id:readonly, corehr:file:download, docs:document.content:read, event:ip_list, im:chat, im:chat.access_event.bot_p2p_chat:read, im:chat.members:bot_access, im:message, im:message.group_at_msg:readonly, im:message.group_msg, im:message.p2p_msg:readonly, im:message:readonly, im:message:send_as_bot, im:resource, sheets:spreadsheet, wiki:wiki:readonly ], user: [ aily:file:read, aily:file:write, im:chat.access_event.bot_p2p_chat:read ] } }权限配完后需要配置长连接事件。OpenClaw 跟飞书的通信走的是长连接模式不是 Webhook 回调。在服务器上新建一个临时长连接脚本用来在飞书后台保存事件配置时保持连接活跃cat feishu_long_conn_official.py EOF import lark_oapi as lark APP_ID 飞书应用appid APP_SECRET 飞书应用appsecret def do_p2_im_message_receive_v1(data: lark.im.v1.P2ImMessageReceiveV1) - None: print(f[收到消息事件], 数据: {lark.JSON.marshal(data, indent4)}) event_handler lark.EventDispatcherHandler.builder(, ) \ .register_p2_im_message_receive_v1(do_p2_im_message_receive_v1) \ .build() def main(): cli lark.ws.Client(APP_ID, APP_SECRET, event_handlerevent_handler, log_levellark.LogLevel.DEBUG) print(正在建立飞书长连接...) print(连接成功后请去飞书后台点击「保存」完成后按 CtrlC 退出) cli.start() if __name__ __main__: main() EOF把 APP_ID 和 APP_SECRET 替换成当前这个 Bot 的实际值然后运行python3 feishu_long_conn_official.py。看到连接建立后回到飞书开发者后台的「事件与回调」页面开启长连接点击添加事件把im.message.receive_v1加进去然后保存。保存成功后按 CtrlC 退出临时脚本。每个 Bot 都要重复一遍上面的流程创建应用、加机器人能力、导权限、跑长连接脚本、加事件、发布版本。发布时填个版本号和更新说明就行。发布完成后在飞书里搜索这个 Bot 发一条消息第一次对话会出现配对标识把红框里的内容发到 OpenClaw 管理后台完成配对。本机部署就直接在命令行输入配对指令服务器部署就进命令行面板操作。这一步做完你手里应该有了 N 组 appId 和 appSecret对应 N 个飞书 Bot。接下来进入 OpenClaw 侧把这些账号跟 Agent 对齐。3. openclaw.json 多 Bot 路由配置Agent、account、binding 三件套怎么写OpenClaw 的多 Bot 架构里有三个核心角色理解它们的关系是写好配置的前提。Agent是真正干活的 AI 角色每个 Agent 有自己的人设、工作流和上下文。比如写作助手、日常助手、生图助手各自独立。account是 OpenClaw 的账号配置单元每个 account 绑定一个外部渠道也就是一个飞书 Bot。binding是路由规则告诉 OpenClaw 收到哪个 account 的消息就转给哪个 Agent 处理。整体链路是飞书 Bot 收到消息 → 根据 appId 匹配到 account → 根据 binding 找到对应 Agent → Agent 处理并回复。先建 Agent 工作空间。进入/root/.openclaw/workspace/agents/目录给每个 Agent 新建一个文件夹文件夹名就是 Agent 的 id。比如 daily、writer、imager 三个文件夹。每个文件夹里至少要有这几个文件文件名用途写作助手示例AgentS.md工作空间说明介绍职责和流程本 Agent 负责公众号长文起草。流程接收主题 → 搜索素材 → 生成大纲 → 填充正文 → 存入飞书SOUL.md人设、语气、核心工作流行为最高准则人设资深科技编辑。语气专业且风趣。禁止使用「总之」「综上所述」IDENTITY.md名字、形象、性格等基础信息名字小肥肠的笔杆子。性格严谨高效USER.md用户称呼、偏好、时区称呼老板。偏好喜欢短句。时区Asia/ShanghaiTOOLS.md可调用工具路径和用途feishu_writer: /tools/feishu_doc.pygoogle_search: /tools/search.pyHEARTBEAT.md定时任务配置无则留空cron: 0 22 * * *task: 汇总今日飞书表格新增采集数据并推送文件夹建好后打开/root/.openclaw/openclaw.json这是核心配置文件。我们要在里面做三件事在 agents.list 里声明有哪些 Agent在 channels.feishu.accounts 里填入每个 Bot 的 appId 和 appSecret并指定 defaultAgent在 bindings 里把 agentId 和 accountId 对应起来。下面是可直接复制的配置模板把 appId 和 appSecret 替换成你自己的值{ agents: { list: [ { id: daily, name: 日常助手, workspace: /root/.openclaw/workspace/agents/daily }, { id: writer, name: 写作助手, workspace: /root/.openclaw/workspace/agents/writer }, { id: imager, name: 生图助手, workspace: /root/.openclaw/workspace/agents/imager } ] }, channels: { feishu: { enabled: true, accounts: { daily: { appId: cli_你的daily_appId, appSecret: 你的daily_appSecret, defaultAgent: daily }, writer: { appId: cli_你的writer_appId, appSecret: 你的writer_appSecret, defaultAgent: writer }, imager: { appId: cli_你的imager_appId, appSecret: 你的imager_appSecret, defaultAgent: imager } } } }, bindings: [ { agentId: daily, match: { channel: feishu, accountId: daily } }, { agentId: writer, match: { channel: feishu, accountId: writer } }, { agentId: imager, match: { channel: feishu, accountId: imager } } ] }这里有几个容易写错的点。第一accounts 里的 keydaily、writer、imager是 accountId必须跟 bindings 里 match.accountId 完全一致大小写敏感。第二defaultAgent 指向的是 agents.list 里的 id不是 name。第三workspace 路径要写绝对路径且文件夹必须真实存在否则 Agent 启动时会报找不到工作空间。如果你用的是 Cline MCP 或者 Codex 的 auth.json 体系来管理模型接入这里的三件套对应关系是Base URL 填https://taotoken.net/apiKey 填你在控制台生成的 API KeyModel ID 填你实际调用的模型标识。这三项在 OpenClaw 的模型配置段里同样要写全缺一个都会导致 Agent 无法正常调用模型。配置写完后保存重启 OpenClaw Gateway 让配置生效openclaw gateway restart重启后观察日志如果看到每个 account 都成功建立了飞书长连接说明配置加载正常。如果某个 account 报连接失败先检查 appId 和 appSecret 是否跟飞书后台一致再检查该应用是否已发布版本。4. 逐条验证多飞书 Bot 消息收发与 Agent 路由联调配置写完不代表就能用得逐个 Bot 验证消息能不能正常收发、路由有没有打到正确的 Agent 上。这一步别偷懒多 Bot 场景下最容易出的问题就是消息串台——你给写作 Bot 发消息结果日常助手回了你。验证方法很直接打开飞书分别给每个 Bot 发一条带身份标识的消息。比如给写作 Bot 发「你是谁你的职责是什么」给日常 Bot 发「你是谁你的职责是什么」给生图 Bot 发同样的内容。然后观察回复。如果路由正确写作 Bot 应该回复写作助手的人设和职责日常 Bot 回复日常助手的人设生图 Bot 回复生图助手的人设。如果三个 Bot 回复的内容一样说明 binding 没生效所有消息都落到了同一个 Agent 上。再进一步发一条需要调用工具的消息。比如给写作 Bot 发「帮我起草一篇关于 OpenClaw 多 Agent 的短文大纲」观察它是否按照 SOUL.md 里定义的工作流走接收主题 → 搜索素材 → 生成大纲。如果它直接跳过搜索环节开始瞎编说明 TOOLS.md 里的工具路径没配对或者 Agent 没有正确加载工具配置。同时观察 OpenClaw Gateway 的日志输出。正常情况下每条消息进来时日志里会打印 accountId 和 agentId 的匹配过程。你可以用这个命令实时看日志tail -f /root/.openclaw/logs/gateway.log | grep -E accountId|agentId|binding如果日志里显示accountIdwriter但agentIddaily那就是 bindings 里的 match 写错了。如果日志里压根没有 accountId 输出说明飞书长连接没建立成功回到第 2 步检查事件订阅和版本发布。还有一个常见情况消息发出去了Bot 也收到了但回复很慢或者超时。这通常是模型调用侧的问题不是路由问题。检查模型配置里的 Base URL、Key、Model ID 三件套是否完整。Base URL 用https://taotoken.net/apiKey 用控制台生成的Model ID 跟你实际开通的模型对应。如果用的是 Coding Plan 或者 Claude Code 类的接入方式确认 OAuth 或 API Key 的授权状态是否正常。验证通过的标准是每个 Bot 都能独立收发消息回复内容符合对应 Agent 的人设工具调用按预期触发日志里 accountId 和 agentId 一一对应无错位。全部通过后这套多 Bot 架构就算跑通了。5. 多 Bot 配置常见报错排查401、local proxy failed、reading choices、OAuth多 Bot 场景下的报错大致分两类一类是飞书侧连接问题一类是模型侧调用问题。下面按真实报错逐条拆。401 Unauthorized。这个最常见出现在模型调用环节。原因通常是 API Key 无效、过期或者 Key 跟 Base URL 不匹配。检查 openclaw.json 里模型配置段的 Key 是否跟控制台生成的一致Base URL 是否写成了https://taotoken.net/api。如果用的是 Coding Plan 的 Key确认它没有跟按量计费的 Key 混用。另外多 Bot 场景下每个 Agent 可能配了不同的模型逐个检查每个 Agent 的模型配置别只改了一个。local proxy failed。这个报错说明 OpenClaw 在尝试通过本地代理转发请求时失败了。先确认你的网络环境能正常访问模型 API 端点。如果服务器在国内检查 DNS 解析和出站规则。这个报错跟飞书长连接无关纯粹是模型调用链路的问题。排查顺序先 curl 一下 Base URL 看能不能通再检查 OpenClaw 的代理配置段是否有多余的 proxy 设置。reading choices 相关报错。典型形式是Cannot read properties of undefined (reading choices)。这说明模型返回的响应结构跟 OpenClaw 预期的格式不一致。常见原因是 Model ID 填错了或者 Base URL 指向了一个不兼容 OpenAI 格式的端点。确认你用的 Model ID 是实际开通的Base URL 走的是标准 API 路径。如果用的是 Claude Code 类的接入方式注意它的响应格式跟标准 OpenAI 格式有差异需要在 OpenClaw 里选对适配器。OAuth 授权失败。如果你用的是 Claude Code 或类似需要 OAuth 的接入方式报错通常出现在 token 刷新环节。检查授权是否过期重新走一遍授权流程。在 OpenClaw 里OAuth 相关的配置通常跟 API Key 配置分开确认两者没有冲突。如果同时配了 OAuth 和 API KeyOpenClaw 可能会优先用其中一个导致另一个的配置被忽略。飞书侧报错长连接建立失败。检查 appId 和 appSecret 是否跟飞书后台一致应用是否已发布版本事件订阅里是否加了im.message.receive_v1。如果飞书后台显示长连接已开启但 OpenClaw 侧连不上检查服务器出站端口是否放行飞书长连接走的是 WebSocket需要允许出站 443 端口。消息发出但无回复。先看 Gateway 日志有没有收到消息事件。如果收到了但没触发 Agent检查 bindings 里的 match 条件是否跟 accounts 里的 key 一致。如果触发了 Agent 但没回复检查 Agent 的 workspace 路径是否存在、SOUL.md 等文件是否齐全。如果 Agent 处理了但回复没发出去检查飞书应用的im:message:send_as_bot权限是否开通。多个 Bot 回复串台。这是 binding 配置错误。检查每个 binding 的 match.accountId 是否跟 accounts 里的 key 一一对应agentId 是否指向正确的 Agent。特别注意大小写和空格JSON 里多一个空格都可能导致匹配失败。排查时建议按链路顺序来飞书消息是否到达 → account 是否匹配 → binding 是否命中 → Agent 是否加载 → 模型是否调用成功 → 回复是否发出。每一环都有对应的日志和报错逐段定位比盲目改配置快得多。6. 多 Agent 长期运行的配置维护与入口选择多 Bot 架构跑起来之后日常维护主要盯两件事一是新增 Agent 时的配置扩展二是模型调用链路的稳定性。新增一个 Agent 的流程是固定的先在/root/.openclaw/workspace/agents/下建文件夹补齐 AgentS.md、SOUL.md、IDENTITY.md、USER.md、TOOLS.md、HEARTBEAT.md 六个文件然后在飞书开发者后台建一个新的自建应用配权限、跑长连接、加事件、发布最后在 openclaw.json 的 agents.list 里加一条在 channels.feishu.accounts 里加一个 account在 bindings 里加一条映射。三处都加完重启 Gateway 生效。如果你需要长期跑多个编码类或 Agent 类任务模型调用的稳定性和额度管理会比单 Bot 场景更敏感。每个 Agent 独立调用模型token 消耗是叠加的。这时候可以考虑用 Coding Plan 来统一管理编码类 Agent 的模型调用把写作、采集、生图这些不同职责的 Agent 的模型配额分开规划避免一个 Agent 跑飞了把额度吃光。配置文件的版本管理也值得做。openclaw.json 里存了所有 appSecret建议把它纳入私有 Git 仓库或者用配置管理工具托管每次改动留个记录。多 Bot 场景下配置项多改错一个 accountId 就可能导致某个 Bot 失联有版本记录排查起来快很多。验证模型连通性的时候可以直接在模型对话入口发一条测试消息确认 Base URL、Key、Model ID 三件套在当前网络环境下能正常返回。这一步跟 OpenClaw 配置无关纯粹是确认模型侧通路没问题排除掉模型因素后再去查 OpenClaw 的配置。接入文档里有完整的字段说明和示例配置遇到不确定的字段含义可以直接对照。API Keys 管理页面可以生成和查看当前可用的 Key多 Agent 场景下建议给每个 Agent 或每类任务分配独立的 Key方便追踪调用量和排查问题。整套配置的核心逻辑就一句话飞书 Bot 靠 appId 区分OpenClaw 靠 accountId 匹配binding 把 accountId 和 agentId 绑死。三处对齐消息就不会串台。