如果你也在用下龙虾openclaw,添加多个机器人到一个群里，统一指挥和调度，那么你大概率遇到过这个极其典型的线上诡异现象：

结果却是：A 机器人正常收消息、正常回复B 机器人像完全“失明”，毫无反应

很多人第一反应会怀疑： 模型超时？上下文爆了？网关卡住？

但这次真实线上排查给出结论：

绝大多数时候，不是“机器人不想回”，而是“机器人根本没收到消息事件”。

本文一次性讲透：

• 飞书多Agent群消息三段路由标准

• 从现象到实锤的完整排查过程

• 真正根因：飞书敏感权限缺失

• 可直接复制的 OpenClaw 配置

• 上线必过防坑清单

---

一、先立需求：多Agent群消息三段路由规则

在多机器人共存的飞书群里，必须有固定、清晰、可落地的路由优先级，否则必然出现抢答、串线、漏消息。

我对多agents飞书群的沟通路由的需求规则如下：（）

1. 显式 @ 优先我@ 谁（agent），谁处理、谁回复。

2. 昵称命中次优先未@时，消息包含机器人昵称（哨兵/猎手/二龙/鹰眼），由命中机器人处理，回复

3. 无@、无昵称 → default 兜底无人点名时，默认由 default（总管机器人二龙）接单：

   • 单任务：分发给对应的机器人，完成的机器人直接执行并回复

   • 联合任务：由二龙进行分发，完成后二龙汇总回复

4 介绍一下我的agents军团角色定义

角色名称	核心定位	核心职责	使用场景与任务
二龙（main-agent）	AI 大总管（CEO）	总协调、任务分发、进度跟踪、结论输出、最终评审	项目启动、跨部门需求对接、联合任务编排、最终结论发布
哨兵（operations-subagent）	AI 经营助理（PMO+项目经理）	任务跟踪、提醒催办、状态同步、AI 数据监控与统计、闭环检查	项目管理、任务跟进、待办提醒、经营/进度日报、审计跟进
鹰眼（reviewer-subagent）	AI 战略助理	行业资讯收集、定时推送、趋势分析、外部行业日报	市场调研、竞品分析、行业信息雷达、日报生成
罗胖（writer-subagent）	AI 创意助理	文案创作、视频脚本、文档生成、表达优化	内容营销、方案撰写、会议纪要、内容多版本输出
钛蛋（coder-subagent）	AI 研发助理	技术支持、代码审查、方案设计，并负责“设计→落地→测试验证”闭环	技术评审、BUG 排查、架构咨询、功能实现与验证

一句话总结：谁被点名谁响应，没人点名二龙兜底。

---

二、现场现象：不是回复慢，是真·没收到

线上核心症状非常明确：

• 同群、同一条无@消息

• 哨兵ops志持续出现 received + dispatch`

• 同一时间 二龙default 日志完全无对应 received

• 用户侧表现：default 偶发“失踪不回复”

只看聊天界面，极像模型/服务卡顿； 一看日志，真相立刻清晰：这是消息投递链路问题，不是回答逻辑问题。

---

AI自查，AI怀疑是排除随机抖动，通信不稳定

三、人工介入，排查思路：不靠猜，用实验实锤

为排除随机抖动、消息流差异，我们做两组可复现对照实验。

实验 1：连续 5 条无@消息

发送 5 条不@、不带昵称消息：

• ops 收到：5 条

• default 收到：0 条

实验 2：A/B 对照（主流消息 / 回复流）

• A 组（主流）5 条：ops 全收，default 0 条（直接在群里发送5次信息，每次都有编号）

• B 组（回复流）5 条：ops 全收，default 0 条 （选相同的群信息，回复5次，带识别编号）

结论：

• 非偶发抖动

• 非消息通道差异

• default 机器人的消息事件投递链路本身不完整

---

四、根因定位：default 缺少关键敏感权限

最终在飞书开放平台核对权限，问题直接暴露：

• ops 应用：已开通 获取群组中所有消息

• default 应用：未开通该敏感权限

这就是为什么：同一个群，ops 能收，default 收不到。

关键认知（极易踩坑）

• requireMention、路由规则：决定 收到后怎么处理

• 飞书平台权限：决定 能不能收到消息

OpenClaw 配置再完美， 平台权限没开，机器人就是“失明”状态。

---

五、修复步骤（可直接复现）

1. 飞书开放平台 → 为 default 应用开通：获取群组中所有消息

2. 创建新版本并发布（只开权限不发布=线上不生效）

3. 目标群发 3 条无@消息做回归验证

验收标准（看日志）：

• 出现 feishu[default]: received message ... (group)

• 后续跟着 dispatch complete (replies=1)

出现即代表问题彻底修复。

---

六、OpenClaw 飞书回复配置（直接复制可用）

以下为三种最常用模式，修改后需重启网关。

0. 查看当前配置

openclaw config get channels.feishu

---

模式 1：仅 @ 才回复（推荐，控噪音）

openclaw config set channels.feishu.requireMention true --strict-jsonopenclaw gateway restart

完整配置示例：

{  "channels": {    "feishu": {      "enabled": true,      "appId": "cli_你的AppID",      "appSecret": "你的AppSecret",      "requireMention": true,      "groupPolicy": "open"    }  }}

---

模式 2：无需 @，群内消息自动回复（谨慎）

openclaw config set channels.feishu.requireMention false --strict-jsonopenclaw gateway restart

⚠️ 大群易刷屏，建议配合群级规则使用。

---

模式 3：按单个群精细化配置（最灵活）

# 指定群必须 @ 才回复openclaw config set channels.feishu.groups.oc_群ID.requireMention true --strict-json# 指定群不用 @ 也回复openclaw config set channels.feishu.groups.oc_群ID.requireMention false --strict-jsonopenclaw gateway restart

---

多Agent推荐配置（default + ops）

若希望无@时默认二龙接单，推荐如下配置：

# default（二龙）：允许无@触发openclaw config set channels.feishu.accounts.default.requireMention false --strict-json# ops（哨兵）：需 @ 才响应（防抢答）openclaw config set channels.feishu.accounts.ops.requireMention true --strict-jsonopenclaw gateway restart

---

七、上线防坑清单（建议固化为团队 SOP）

每次新增/重构飞书 Bot，强制检查以下 6 项：

1. 对比 default / ops 事件订阅是否完全一致

2. 核对敏感权限：获取群组中所有消息

3. 确认权限修改后已发布版本

4. 确认机器人在群内且未被限制

5. 发送 3 条无@消息做回归测试

6. 以日志为准：必须看到 default: received message

---

结语

本次排查最有价值的，不是修复一个故障， 而是把一个看似“玄学”的问题，变成可复现、可预防、可标准化的工程问题。

记住这条核心原则，能帮你避开 80% 飞书多Agent线上误判：先确认消息有没有进来，再谈机器人怎么回。

如果你正在做飞书多机器人/多Agent协作， 这篇可以直接收藏作为排查手册。

---

关键字标签：飞书机器人多Agent OpenClaw 运维实战 线上故障 多agents路由

Claude Dispatch新能力到底值不值得上？个人数字员工时代来了

OpenClaw实战：应届毕业生如何用AI成为1.5倍速人才

实操OpenClaw 3 个 输出格式命令！精准控样式，告别无效排版返工