开门见山
地址： https://github.com/Alenryuichi/clawdbot-feishu
实测可以让 main agent 发送 @去调用其他 agent ，组成 multi-agent 开发团队 pr 已提交到官方插件库，还没过
为什么不用非 mention 模式？
因为要控制 bot 之间的主次层级，不能让所有 bot 都响应每条消息，会出现 ping-pong 问题！
并且飞书的 bot 即使在非 mention 模式下，也会忽略其他机器人发的消息！
效果如下：
背景
我希望在飞书群聊中部署一个多 Agent 团队：
Tech Lead Bot - 负责技术决策和任务分配 iOS Dev Bot - 负责 iOS/Swift 相关问题 Go Dev Bot - 负责后端/Go 相关问题 理想场景：用户提问 → Tech Lead 分析后 @mention 专家 → 专家回复 → 专家之间可以互相讨论 我用了很多方法，都行不通，主要是飞书的限制，如下 ：
核心限制：飞书 message_receive_v1 事件
飞书的 Bot 消息接收事件 (im.message.receive_v1) 有一个关键限制：
Bot 发送的消息不会触发其他 Bot 的 message_receive_v1 事件
这意味着：
用户 @Bot → Bot 收到事件 → Bot 回复
BotA @BotB → BotB 收不到任何事件
这是飞书平台层面的设计，无法通过配置或 API 绑过。
最终成功的方案：Bot-to-Bot Relay （合成事件）
原理 既然飞书不会推送 Bot 间的消息事件，我们在应用层"模拟"这个过程：
BotA 回复消息 → 解析消息中的 @mention → 创建"合成事件" → 直接调用 BotB 的消息处理函数
实现架构
┌─────────────────────────────────────────────────────────────────┐ │ OpenClaw Gateway │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Tech Lead │ │ iOS Dev │ │ Go Dev │ │ │ │ Bot │────│ Bot │────│ Bot │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ │ │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Bot Registry (bot-relay.ts) │ │ │ │ - 注册所有 Bot 的 OpenID │ │ │ │ - 解析 @mention 标签 │ │ │ │ - 创建合成事件并触发目标 Bot │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Shared History (shared-history.ts) │ │ │ │ - 跨 Bot 共享聊天记录 │ │ │ │ - 持久化到 JSONL 文件 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘ 核心代码模块
文件 功能 bot-relay.ts Bot 注册、 @mention 解析、合成事件触发 shared-history.ts 跨 Bot 聊天记录共享（ JSONL 持久化） reply-dispatcher.ts Bot 回复后触发 relay monitor.ts 启动时注册所有 Bot @mention 格式要求
为了让 relay 系统能解析 @mention ，Bot 必须使用特定格式：
<at user_id="ou_xxxx">Go 助手</at> 成功实现的功能
Tech Lead → iOS/Go Bot：Tech Lead 可以 @mention 并触发子 Bot
共享上下文：所有 Bot 都能看到完整的聊天历史
动态队友发现：每条消息都会注入可用队友列表
 | 1 KKKKale 2 月 28 日 感谢 up ，我前几天也在折腾这个，最后是让他们在内部调用沟通，再显式在群里发一条 @消息（给人看） |
 | 2 alenryuichi OP @KKKKale openclaw 内部的 subagent_send 对么，我也用了一次那个，不过感觉太冗余，不自然。 然后现在用了这个，会更自然一些 |
| 3 KKKKale 2 月 28 日 @alenryuichi 对，那个实现不干净。说起来，亲这个 fork 有 pr 给原 repo 咩？可不可以在配置里面加一个选项或者开关，合给原 repo |
 | 4 mikaelson 2 月 28 日 你们的 openclaw 拿来做什么。好奇一下。 |
 | 5 zouzou0208 2 月 28 日 |
| 6 alenryuichi OP @KKKKale 合了 不过原 repo 审核很慢啊。 到时候看看原 repo 作者的评论了 |
| 7 alenryuichi OP @zouzou0208 赞，不过我现在用 discord 了。 哈哈 飞书+discord ，各有好多。 |
| 8 alenryuichi OP @mikaelson 啥都能干，几乎就是数字人了 |
 | 9 mikaelson 2 月 28 日 @alenryuichi #8 举点实际使用场景？部署了一个不知道拿来干嘛。。 |
 | 10 liujan 2 月 28 日 via iPhone 感觉用飞书发送消息给 openclaw ，反应好慢，经常发一条消息，过了差不多 10 分钟才有回应，很多时候直接就没回应了，直接在网页端就很快，不知道为什么 |
 | 11 robinlovemaggie 2 月 28 日 via Android @liujan 你应该是把飞书分就到了墙外线路上了 |
| 12 alenryuichi OP @liujan websocket 很快的，应该你选的模型问题？ |
 | 13 iPeta 8 天前 卧槽牛逼，这个思路，之前一直没有想好如何解决这个问题，感谢楼主分享 |
 | 14 MasterMonkey 8 天前 请教下，大家 2 月 7 号的版本能用，我的飞书配置一直有问题？ |
 | 15 shuoshuxx 7 天前 这个思路牛逼，但我用了楼主这个，好像还是不行，具体要怎么操作呢 |
| 16 alenryuichi OP |
| 17 alenryuichi OP @shuoshuxx 下载这个库之后，直接让本地的 claude 来部署就好了，我测试没问题的 |
| 18 alenryuichi OP @mikaelson 解决日常生活中的重复性问题，关注信息推送，开源项目快速参与，自研项目等 |
 | 19 livary24 6 天前 安装之后会影响 openclaw 版本升级吗？ |
| 20 alenryuichi OP @livary24 不会，插件而已。 不是 openclaw 主路径，毕竟这是 feishu 插件的改版。 后续升级 feishu 插件会覆盖。 不过你可以让 claude code 辅助升级 |
Select Language