OpenClaw中飞书机器人配置指南:如何让群消息免 @ 也能自动回复

用 OpenClaw 做飞书机器人时,默认配置下,群里的消息必须 @ 机器人 才能触发回复。这在很多场景下很不方便——如果希望机器人在群里"隐身"工作,不用 @ 就能自动监听和回复,需要额外配置。

本文记录我解决这个问题的完整过程,供同样踩坑的同学参考。


问题描述

现象:

  • 飞书群里 @ 机器人 → 正常回复 ✅
  • 飞书群里不 @ 机器人 → 没有任何反应 ❌

环境:

  • OpenClaw 框架
  • 飞书自建应用(机器人)
  • WebSocket 长连接模式

解决过程

第一步:修改 OpenClaw 配置

openclaw.json 中找到飞书渠道配置:

"channels":{"feishu":{"requireMention":false,...}}

requireMention 设为 false,让 OpenClaw 不再强制要求 @ 机器人。

但这还不够 ❌

第二步:申请飞书平台权限

修改 OpenClaw 配置后测试,发现消息依然收不到。

查日志发现:消息根本没有到达 OpenClaw——问题出在飞书平台层面

飞书默认只推送 @ 机器人 的消息到应用。如果要接收群里所有消息(不限于 @),需要在飞书开放平台申请一个敏感权限:

权限名称:im:message.group_msg(获取群组中所有消息)

第三步:在飞书开放平台申请权限

  1. 打开 飞书开放平台,进入你的应用
  2. 事件与回调事件配置接收消息 → 获取群组中所有信息(敏感权限) im:message.group_msg → 申请开通

第四步:验证效果

权限生效后,在群里发消息不用 @ 机器人,OpenClaw 就能正常收到并自动回复了 ✅


完整配置参考

OpenClaw 飞书渠道配置(完整示例)

"channels":{"feishu":{"enabled":true,"appId":"cli_xxxx","appSecret":"xxxx","domain":"feishu","connectionMode":"websocket","requireMention":false,"dmPolicy":"allowlist","allowFrom":["ou_你的用户ID"],"groupAllowFrom":["ou_你的用户ID"],"groupPolicy":"allowlist","groups":{"*":{"enabled":true}}}}

需要申请的飞书权限清单

权限标识名称类型说明
im:message发送消息基础权限机器人发消息
im:message.group_at_msg:readonly接收群@消息事件基础权限接收群内@机器人消息
im:message.group_msg获取群组中所有消息敏感权限接收群内所有消息(不限于@)
im:message.p2p_msg:readonly接收单聊消息基础权限接收私信

注意事项

  1. im:message.group_msg 是敏感权限
    • 需要企业管理员审批
    • 审批通过后才能使用
    • 建议同时申请 im:message.group_at_msg:readonly(基础权限)
  2. 权限申请后需要重新发布应用
    • 权限审批通过后,必须重新发布版本才能生效
  3. requireMention: false 的作用
    • 设为 false 后,OpenClaw 不会强制要求消息必须 @ 机器人
    • 但如果飞书平台没有相应权限,消息根本不会推送到 OpenClaw
  4. WebSocket vs Webhook
    • 推荐使用 WebSocket 模式,更简单
    • 如果用 Webhook 模式,还需要额外配置 verificationTokenencryptKey

相关文档


总结

飞书群消息免 @ 触发机器人的关键就两步:

  1. OpenClaw 侧requireMention: false
  2. 飞书平台侧:申请 im:message.group_msg 敏感权限并重新发布应用

两个缺一不可。按照这个流程配置,应该就能实现群里自由对话了。


首发于我的博客:https://blog.ZEEKLOG.net/QIU176161650
欢迎交流讨论!

Read more

Vibe Coding - 面向 Web 全栈开发者的 Claude Agent Skills 入门与实战

Vibe Coding - 面向 Web 全栈开发者的 Claude Agent Skills 入门与实战

文章目录 * 引言:当 AI 助手开始“长出团队习惯” * 一、核心概念速通:Agent Skills、Claude.md、MCP、子代理各负责什么 * 1.1 Agent Skills 是什么? * 1.2 Progressive Disclosure:不再“把所有文档一次性喂给模型” * 1.3 Claude.md:项目说明书,不是技能 * 1.4 MCP:把 GitHub、数据库、SaaS 全接进来 * 1.5 子代理(Subagents):带专职角色的小团队成员 * 二、从 Claude 视角理解 Agent Skills

使用Docker安装Ollama及Open-WebUI完整教程

作者:吴业亮 博客:wuyeliang.blog.ZEEKLOG.net 一、Ollama 简介及工作原理 1. Ollama 简介及原理 * 简介:Ollama 是一款轻量级、开源的大语言模型(LLM)运行工具,旨在简化本地部署和运行大语言模型的流程。它支持 Llama 3、Mistral、Gemini 等主流开源模型,用户无需复杂配置即可在本地设备(CPU 或 GPU)上快速启动模型,适用于开发测试、本地智能应用搭建等场景。 * 工作原理: * 采用模型封装机制,将大语言模型的运行环境、依赖库及推理逻辑打包为标准化格式,实现模型的一键下载、启动和版本管理。 * 通过优化的推理引擎适配硬件架构,支持 CPU 基础运行和 GPU 加速(如 NVIDIA CUDA),减少资源占用并提升响应速度。 * 提供简洁的

Flutter 组件 inappwebview_cookie_manager 适配 鸿蒙Harmony 实战 - 驾驭核心大 Web 容器缓存隧道、构建金融级政企应用绝对防串号跨域大隔离基座

Flutter 组件 inappwebview_cookie_manager 适配 鸿蒙Harmony 实战 - 驾驭核心大 Web 容器缓存隧道、构建金融级政企应用绝对防串号跨域大隔离基座

Flutter 组件 inappwebview_cookie_manager 适配鸿蒙 HarmonyOS 实战:构建金融级政企应用的绝对防串号、跨域隔离基座 前言 在鸿蒙(OpenHarmony)生态全面爆发的元年,尤其是在涉及极高密级的政务信创办公系统,或是动辄千万流水、每日亿级请求的金融级应用中,一个核心的安全问题浮出水面:“如何在原生系统底层、Flutter 视图层,以及那些杂乱不可控的第三方或历史遗留的 Web/H5 容器之间,实现身份Cookie或核心Token的绝对安全、单向透传,并具备强力的清理能力?” 这个问题一旦处理不当,哪怕只是露出一丝缝隙,都可能在极短时间内引发全应用的恶性串号、账目混乱,甚至导致严重的数据越权泄露,成为整个系统的“核爆级”架构黑洞。 如果你的前端团队仍然只是粗糙地打开一个毫无防护的 WebView,并天真地指望业务层每次都能主动、无遗漏地手动清理缓存和密码,那么你的应用在断网重连、异地登录或多并发场景下,极易因 Session 未能彻底清除而发生严重的“串绑撞车”事故。更可怕的是,由于缺乏统一管控,各类敏感

全栈分页方案:MyBatisPlus后端与Thymeleaf前端深度整合指南

全栈分页方案:MyBatisPlus后端与Thymeleaf前端深度整合指南

目录 前言 一、MybatisPlus搭建及表介绍 1、MybatisPlus环境搭建 2、示例表结构介绍 二、Java后台分页实现 1、实体类实现 2、业务层分页实现 3、控制层实现 三、Thymeleaf分页集成 1、分页表格展示 2、分页条集成 3、成果展示 四、可能遇到的问题 1、分页不展示 2、问题解决 五、总结 前言         在当今的软件开发中,分页功能是提升用户体验和系统性能的关键。无论是企业级应用还是面向用户的平台,高效分页都能显著改善交互体验。今天将带你深入了解如何通过 MyBatisPlus 和 Thymeleaf 的深度整合,打造一个完整的全栈分页解决方案。分页功能不仅能够提升用户交互的流畅性,还能显著降低服务器的负载,提高系统的整体性能。将 MyBatisPlus 和 Thymeleaf