OpenClaw 飞书发不出去消息怎么办：message.send 返回 400 时先查这 5 项

发布时间

2026-03-14

作者

BUMA 内容团队

资料来源

OpenClaw 官方 Feishu / Pairing 文档、Clawdbot 中文文档

适合谁看

正在做 OpenClaw 飞书接入、消息发送、群聊播报、权限收口与线上排查的人

为什么飞书里“能收不能发”特别常见？

这是 OpenClaw 飞书接入里很容易让人误判的一类问题。因为接入链路本来就分两段：一段是“机器人有没有把消息收进来”，另一段是“机器人有没有权限把消息发回去”。官方 Feishu 文档对这两段的要求拆得很清楚：收消息这一侧，重点看长连接（WebSocket）事件订阅、im.message.receive_v1 和 Gateway 是否在线；发消息这一侧，重点看 Bot 能力、应用发布状态以及 im:message:send_as_bot 这样的出站权限。

所以现实里最容易出现的情况是：你已经能看到 pairing 码、已经能在群里 @ 到机器人，甚至日志也显示消息进来了，于是你自然会以为“飞书接入已经通了”。但从官方排查口径来看，这最多只能说明接收链路基本通了，不能说明发送链路也满足条件。如果应用还是未发布、发送权限没补齐，最终就很容易表现成 message.send 返回 400，或者看起来像“机器人完全不回”。

对一人公司、内部协作群、客户咨询群尤其如此。因为这类场景往往是先把机器人拉进来试，再逐步补权限和收边界。如果你没有把“收消息”和“发消息”分开排查，就会在错误方向上浪费很多时间。

OpenClaw 官方文档给出的 5 项优先检查项

第一项：确认应用权限里已经包含 im:message:send_as_bot。OpenClaw 官方 Feishu 文档给出的批量导入权限清单里，明确把它列为租户权限的一部分；中文文档的“消息发送失败”排查也首先强调这点。

第二项：确认飞书应用已经完成版本创建、审核和发布。官方快速入门专门单列了“发布应用”这一步，并在故障排除中再次强调“消息发送失败时，要确认应用已发布”。这说明很多问题不是配置没写，而是发布状态没到位。

第三项：确认机器人能力已经开启。官方步骤里要求到“应用能力 > 机器人”里打开 Bot 能力并设置机器人名称；如果连机器人能力都没启用，出站消息链路本身就不完整。

第四项：确认 Gateway 正常运行，并且必要时重启。官方建议在配置完成后立刻检查 openclaw gateway status，排查时持续看 openclaw logs --follow。如果 Gateway 没起来，或者改完配置没重启，日志和实际行为都可能和你以为的不一样。

第五项：先看日志再改配置。文档没有鼓励“靠猜”排查，而是把日志放在关键步骤里反复强调。对 message.send 这类 400 来说，日志是你区分“权限缺失”“应用未发布”“目标不可达”“配置未生效”的最快入口。

哪几种情况最容易被误判成 message.send 400？

第一种是“机器人其实没收到该回的消息”。如果群里默认要求 @ 机器人，而你只是普通发言，表现出来就会像“它不回”；但这不是发送失败，而是入口没有命中。第二种是群或成员白名单没有放开，消息根本没被处理。第三种是 pairing 还没批准，私聊消息被挡在审批前。第四种才是真正的发送链路问题：消息已经进来，但应用出站条件不满足。

这也是为什么 OpenClaw 文档会把访问控制、pairing 和消息发送分开写。因为它们都能在用户侧表现成“机器人没回”，但修法完全不同。你如果把群边界问题当成出站权限问题来修，就会一直在飞书后台加权限；反过来，把真实的发送失败当成群设置问题，也会一直在群里试 @、试白名单，最后越改越乱。

适合团队怎么把这套排查流程固定下来？

如果你是企业内部协作、客户咨询群、一人公司消息闭环，最稳的办法不是谁报错就临时猜，而是把排查顺序写成固定清单：先看 Gateway 状态，再看日志，再看应用权限和发布状态，最后才去查群聊边界。这样以后无论是 OpenClaw 主号、飞书测试号，还是备用账号，都可以按同一套顺序排。

实际使用里，这套清单还有一个好处：能区分“内容岗位能先做什么”和“开发/运维要接手什么”。内容侧可以先确认触发场景、重现步骤、群里还是私聊、是否已 @、是否已 pairing；技术侧再去处理权限补齐、版本发布、Gateway 重启和日志复盘。职责一分开，效率会高很多。