本文分享了OpenClaw多Agent自媒体工作室因飞书群机器人@识别故障导致工作瘫痪的解决全过程。通过深入排查，放弃依赖群@，改用底层sessionKey实现私聊总控、direct分发、多Agent后台执行的回传链路，最终打造出更稳定的调度系统。该方法适用于Telegram、Discord等任意通道。文末可免费领取价值99元的3天AI学习体验卡（后台回复666）。适合正在搭建AI工作流、使用飞书机器人的用户参考。
Tags:
点击下方，关注后台回复【666】，免费领取【AI学习礼包】
大家好，我是陈凡。
朋友们，我搭的 OpenClaw 自媒体工作室，才上线 3 天，我们就拿下了一篇 4 万阅读的小爆文。
结果昨天中午，我用飞书接 OpenClaw 多 Agent 的工作群突然就塌了。
不是群没了！是我在群里拼命下指令，拼命 @，等了半小时还是谁都不回。
那一刻，我血压手表突然滴滴滴响个不停，低头一看，直接冲上了 170。
失落和挫败感一下子全涌上来了。偏偏掉链子的，还是最关键的工作调度入口。我脑子里只剩一个念头：
难道我刚搭起来的 OpenClaw 多 Agent 自媒体工作室，就这么玩完了？
但折腾了一天半之后，我和 AI 把这件事一点点扒开，最后反而逼出了一条比建群更简单、也更稳定的新路线。
下面我把整个过程写出来，如果你也在用 OpenClaw、飞书机器人，或者你也想搭一个 AI 工作室，这篇文章你一定要看完。
先说结论：真正稳定的不是飞书群里的那一下 @，而是更底层的 direct sessionKey 调度链路。
———
飞书抽了？
事情开始的毫无预兆，本来我正美美的看着大家自我总结...
结果毫无预兆的直接不说话了，检查配置文件、重启网关都试过了。
最开始我还抱着侥幸心理，因为表面上看，问题不算大：
群消息还能发
@ 也能显示出来
但机器人就是不回
可越试，我心里越凉，因为这不是偶发，是你怎么喊，它们都在装死。
而我这个群不是普通聊天群，群里挂着凡人佬、大头、Sail姐、M哥、贾斯丁，平时选题、写稿、排版、复盘，很多协同动作都挂在 OpenClaw 这条链路上，这个群出问题整个工作室就得瘫痪......
所以我很快就意识到：
这不是少回一句话的事儿，这是工作室主调度入口出问题了！
———
不是没收到，是真没认出来
接着我直接去看日志，日志里反复出现一句话：
did not mention bot
这一下问题找到根源了，不是消息没收到，而是群消息进来了，但系统没认你这次 @。
更诡异的是，我很快又测出来：
私聊正常
群里确 @ 不到人
这说明问题不在飞书整体，也不在 OpenClaw 整体，真正出问题的，是飞书群消息这条链路对 mention 的识别出了偏差。
其实最怕的不是报错，最怕的是看起来在工作，其实主链路已经断了！
———
试过继续救群，结果差点把群干炸了
既然群里 @ 不稳定，我的第一反应就是：那就别依赖 @，直接让群里说话就触发。
结果打开全部人沟通后，我在群里发一句，凡人佬、大头、Sail姐、M哥一起开口。
在多次尝试和调整Agent配置后我发现：多 Agent 同群时，只要技术层面一放开，单凭Skill和SOUL根本拦不住谁该说、谁不该说。
制度能约束人，约束不了已经自动触发的 bot。
如果一个群要靠"大家自觉别抢答"才能用，想想都不靠谱。
———
经历过升级、降级、改配置后发现方向完全错了！
经过漫长的调试过程，我也怀疑是不是版本问题，从而把升级、降级、路径、补丁都跑了一遍。
到最后面在我三刷 OpenClaw 官方文档时，发现了新的转机：
multi-agent routing -- 路由模式
Feishu 配置 -- 消息通道配置（Channel）
session / sessionKey-- 底层缓存沟通机制
在深入的研究我才发现明白：前面一直盯着、群怎么修、@ 怎么救、通道怎么打通，其实官方真正稳定的设计思路，根本不是把命门压在群里那一下 @ 上。
真正稳的，是更底层的：
session、sessionKey
direct 路由
agent 间的消息分发
所以眼光不能只放在修一个飞书群上，而是需要重做工作室的主调度方式。
———
飞书群还有用吗？
既然要改变工作室的主调动方式，那就彻底点！
我直接和凡人佬私聊不就行了？
当这句话一想出来，后面的思路反而更清晰了。
因为为工作室建立群初衷是更好的让Bot们能相互了解大家的工作内容，消息好传达，但现在确反而成了拖累，其实我只要满足：稳定下发任务、分发到位、bot们稳定执行、结果有回传、我能时刻监控就行。
所以我后来把主链路改成了这样：
老板私聊总控，总控后台分发，执行层各自私聊干活，再统一回收。
说人话就是：
我私聊凡人佬（总控）；
凡人佬收到任务后；
通过
direct sessionKey分发给：Sail姐、大头、M哥、贾斯丁（执行层）；他们在各自私聊线程里执行；
再通过
sessionKey把结果回传给凡人佬（返回总控）。
———
一旦通了，整个工作室就稳了
最开始测 sessionKey 的时候，也不是一把就过，一上来报的还是个很恶心的错：
Provide either sessionKey or label (not both).
表面看像参数写错，实际上是调用 OpenClaw 工具层在自己添乱。
随后经过层层拆解，最终才确认找到运行的 OpenClaw 路径下进行修改 sessions_send 的实现，保证只能使用 sessionKey 进行发送，同时还生成了修复脚本，由于文件较大想要的朋友关注后，发送"ossk"即可获得
修完之后，我默默的让 凡人佬 一条条测的测，结果非常喜人：Sail姐回了，M哥回了，大头回了，贾斯丁也回了。
专门重启了一次网关后，又测了一轮，结果还是全通。
到这一步，我心里那块石头才算真的落地。
———
写到最后：方法不限于飞书！
虽然本次是飞书最先出问题，但在修复后，其实这已经不是飞书专属方案。
而是扒出来 OpenClaw 更底层的主调度方法：
私聊主入口
direct sessionKey 分发
多 Agent 后台执行
sessionKey 回传
也就是说，今天出问题的虽然是飞书，但这套方法完全可以沿用到任何通道上，包括：Telegram、Discord、WhatsApp、Slack、Signal、iMessage等。
只要是 OpenClaw 能接住、能形成 session 路由的渠道，这套逻辑原则上都成立。
如果你也在龙虾上跑自己的 AI 工作流，也正在折腾飞书机器人群，这种方法就非常值得一试。
扫码
链接我领礼包
没有评论:
发表评论