夜雨聆风
最近很多人问我一个问题：
OpenClaw 接飞书之后，如果我想同时挂写作 Agent、Coding Agent、数据 Agent，到底该怎么配？
这个问题表面上像是在问“多群聊”还是“单 Bot”，实际上不是。
真正要先分清的，是三件事：
你用的是飞书哪一种接入方式 你想把隔离做在群、Bot、还是 Agent 这一层 你到底需不需要“一个入口统管一切”
这三个问题不先分清，后面大概率越配越乱。
先说结论：大多数人别一上来就做总路由
如果你现在只有 2 到 4 个 Agent，要在飞书里给团队用，我的建议很明确：
先上“一套 OpenClaw + 一个飞书 Bot + 多个群/会话绑定不同 Agent”这个方案。
原因很简单：
隔离够清楚 配置不复杂 出问题容易排查 后面要扩也不难
“一个超级总管 Bot，自动理解所有意图，再把任务分发给不同 Agent”听着很爽，但那是第三阶段的事。你前面两层没配稳，先上这个，基本等于主动增加故障面。
第一层先分清：飞书接 OpenClaw，现在其实有 3 种路子
1、飞书自定义群机器人
这个很多人最先想到，因为加一个 webhook 就能发消息。
但它更适合“通知”和“告警”，不适合做 OpenClaw 多 Agent 主入口。
原因也直接：
它主要是群内 webhook 推送 同一个自定义机器人不能像企业自建应用那样自然承接完整会话 数据访问能力很弱 更像消息出口，不像对话入口
如果你的目标只是“把监控、日报、任务提醒推到飞书群里”，它很好用。
如果你的目标是“在飞书里和多个 Agent 长对话、路由、持续协作”，别拿它当主方案。
2、OpenClaw 自带的 Feishu Channel
这才是大多数人真正该用的方案。
按 OpenClaw 官方文档，当前版本已经自带 Feishu 渠道。老版本或自定义安装，才需要手动执行：
openclaw plugins install @openclaw/feishu
它的几个关键点很重要：
支持飞书私聊和群聊 默认走 WebSocket 长连接，不需要公网 webhook 可以通过 bindings 把不同飞书会话路由给不同 Agent 群聊和私聊的策略可以分开配
这套东西一旦用明白，多 Agent 已经能做得很像样了。
3、飞书官方的 OpenClaw 插件
2026 年 3 月，飞书团队已经发布了官方插件仓库 larksuite/openclaw-lark。
它和 OpenClaw 自带 Feishu Channel 最大的区别，不在“能不能聊天”，而在权限。
官方插件的能力更大，可以直接碰：
消息 文档 多维表格 日历 任务
但权限越大，风险越高。
仓库里自己也写得很直白：更推荐把它当私人助理用，不建议一开始就扔进群聊里给很多人一起用。
所以这两条线别混了：
你要的是“飞书里聊 OpenClaw、多会话路由、多 Agent 分工”，优先看 OpenClaw 自带 Feishu Channel 你要的是“以用户身份直接操作飞书文档、日历、任务”，才考虑飞书官方插件
第二层再说：多 Agent 真正能落地的 4 种配法
方案一：一个 Bot，对应多个群，每个群绑定一个 Agent
这是我最推荐的起步方案。
核心思路很简单：
飞书里建多个群 同一个 Bot 进这些群 用 bindings 把不同群路由到不同 Agent
比如：
开发群 → Coding Agent 写作群 → Writer Agent 运营群 → Ops Agent
OpenClaw 官方文档已经给了多 Agent 路由的配置思路，核心就是按 peer.kind 和 peer.id 绑定：
{ "bindings": [ { "agentId": "coding", "match": { "channel": "feishu", "peer": { "kind": "group", "id": "oc_dev_group" } } }, { "agentId": "writer", "match": { "channel": "feishu", "peer": { "kind": "group", "id": "oc_writer_group" } } } ]}
这个方案的优点很实在：
群就是边界，谁负责什么很清楚 群与群之间天然隔离 某个 Agent 挂了，不会把全部入口带死 日志和排错都容易
它的缺点也有：
用户要切群 跨领域任务不够顺 一个任务要跨写作和开发时，会有跳转感
但说实话，这些问题大多数团队都能接受。配置先稳，比“统一入口但天天串线”重要。
方案二：一个 Bot，不同人或不同私聊绑定不同 Agent
这个方案适合“同样都是私聊，但不同人需要不同 Agent”的情况。
比如：
你自己私聊默认进全能 Agent 内容同事私聊默认进写作 Agent 技术同事私聊默认进 Coding Agent
OpenClaw 文档里同样支持按飞书用户 open_id 做绑定。
这套配置的价值在于：
用户体验比多群更自然 每个人看到的都是“自己的那个 Agent” 很适合老板、运营、开发各用各的
但它不适合公共协作场景。因为私聊天然弱共享，团队成员之间看不到上下文。
方案三：一个入口，一个 Router Agent，再分发给多个 Agent
这就是很多人最想做的“统一大总管”。
用户只跟一个 Bot 说话：
“改一下这段代码” “顺便写更新日志” “再整理成飞书文档”
然后 Router 去判断该叫谁干活。
这个方案不是不能做。
问题是，它对你的要求明显更高：
路由规则得稳 日志链路得清楚 权限边界得清楚 子 Agent 的上下文同步得清楚
只要这里面有一项不清楚，排查问题会非常痛苦。
用户看到的是“Bot 变笨了”，但你后台要查的可能是：
Router 选错了 Agent Agent 选对了，但群路由错了 路由对了，但会话上下文串了 上下文没串，但飞书权限不够
所以我会把这个方案放到第二阶段以后再考虑。
前提是你已经把方案一或方案二跑稳了，而且团队里有人愿意维护这条链路。
方案四：多个 Bot / 多个飞书应用 / 多套 OpenClaw
这个方案最重，但隔离最强。
适合两种场景：
不同业务权限差异很大 某些 Agent 绝对不能和其他 Agent 共用入口
比如财务、法务、核心代码库，这些场景真没必要硬追求“统一入口”。
直接分开：
不同飞书应用 不同 OpenClaw workspace 不同 Agent 必要时不同机器或不同网关
运维成本会更高，但逻辑反而最清楚。
真正容易踩坑的不是仅仅路由，而是权限和会话边界
这也是原来很多文章没讲透的地方。
1、飞书群聊和私聊，本来就不是一回事
OpenClaw 官方文档明确写了：
私聊会共享主会话 群聊是隔离的
这句话看着不起眼，实际上决定了你怎么设计多 Agent。
如果你以为“群里说过的话，私聊里也会自然继承”，后面一定出问题。
2、默认情况下，群里通常需要 @ 机器人
Feishu Channel 里，群聊是否必须 @ 才响应，是可以配的。
但默认逻辑不是“所有群自动放开”。
这件事不先讲清楚，用户最常见的反馈就是：
机器人明明进群了，为什么不回我？
通常不是它死了，是：
groupPolicy 没放开 requireMention 还开着 群没进 allowlist
3、私聊默认是 pairing，不是所有人都能直接聊
官方默认的 dmPolicy 是 pairing。
也就是说，陌生用户第一次私聊 Bot，会先拿到配对码，管理员批准后才能继续聊。
这对内部团队是好事。否则你很容易把一个能力很强的 Agent 直接暴露给整个租户。
4、WebSocket 长连接很方便，但前提是网关先起来
这也是官方文档和你自己踩坑稿里都提到的一点。
飞书事件订阅选择“长连接”之前，OpenClaw 的 gateway 最好已经启动。否则配置经常保存失败，很多人会误以为是飞书后台抽风。
5、如果你用的是飞书官方插件，权限风险要单独评估
这一点我单独强调一次。
飞书官方插件能碰文档、表格、日历、任务，能力非常强。
但强就意味着，你最好把它先当成私人助理，不要急着把它扔进多人群里开放使用。
否则一旦提示词被污染，或者路由有误，后果会比“回错一句话”严重得多。
如果是我，我会怎么选
我会按这个顺序来：
第一阶段：先跑通
一套 OpenClaw，一个飞书 Bot，多个群，按群绑定不同 Agent。
这是最稳的起点。
第二阶段：再提体验
对高频用户，再按人头把私聊绑定到固定 Agent。
这样不用来回切群，体验会明显好很多。
第三阶段：最后才做总路由
等你已经确认：
Agent 本身稳定 群策略稳定 权限边界稳定 日志体系稳定
再考虑统一 Router。
顺序反了，后面基本都要返工。
最后一句
飞书多 Agent 的问题，核心从来不是“能不能路由”。
核心是：你把隔离放在哪一层，你愿意承担多大的权限风险，你有没有能力排查一条跨 Agent 的链路。
把这三个问题想清楚，方案其实不难选。
如果你现在刚开始配，我的建议还是那句：
先用一个 Bot 接多个群，把不同群绑给不同 Agent。别一上来就做统一大总管。
这样最省事，也最不容易翻车。
-END-
更多关于AI工具、Cursor、Skills、MCP相关的教程和资讯请持续关注后续分享！
本文完整版详见公众号：未来的回响
文章精校版参见知识星球：AI工具实战派
【限时开放】欢迎加入AI工具实战派交流群一起学习进步～
AI编程、AI运营、工具资料分享请加入知识星球
-推荐阅读-
【AI编程】
【AI设计】
【AI工具】
