openclaw 对接完飞书群机器人配置踩坑记:消息不回、Gateway 断开问题排查

openclaw 对接完飞书群机器人配置踩坑记:消息不回、Gateway 断开问题排查

前言

用 OpenClaw 配飞书机器人,踩了两个坑:群消息不回、Gateway 总是断开。排查了好一阵子,总算搞定了,记录一下希望能帮到遇到同样问题的朋友。


发现问题

飞书消息不回复

在飞书群里 @ 了机器人,完全没反应。一开始以为是网络不好或者机器人没上线,但状态显示明明是连接着的,这就奇怪了。

Gateway 频繁断开

每次改完配置跑 openclaw gateway restart,或者根本什么都没干,Gateway 说断就断。再想启动就报错,必须跑一遍 openclaw doctor --fix 重新安装才能用。太影响使用了。


查看原因

飞书机器人 ID 搞错了

翻日志看到这么一句:

receive events or callbacks through persistent connection only available in self-build & Feishu app 

查了一下,原来一开始配的那个 App ID(yyyyyyyyyyyyyy)是快捷版/小程序类型的飞书应用,这类不支持 WebSocket 长连接收消息。找运维要了正确的机器人 ID(xxxxxxxxxxxxxxxx),换上去果然就好了。

多机器人配置一直失败

想给运营 agent(yunying)单独配一个飞书机器人,试了很多次一直报"unknown channel id"。后来翻 OpenClaw 官方文档才发现,飞书多账号不是那么配的,得用 accounts 字段。

正确姿势:

{"channels":{"feishu":{"defaultAccount":"main","accounts":{"main":{"appId":"xxxxxxxxxxxxxxxx","appSecret":"abcdefghijklmnopqrstuvwxyz"},"yunying":{"appId":"yyyyyyyyyyyyyy","appSecret":"1234567890abcdef"}}}}}

然后 bindings 这么配:

{"bindings":[{"type":"route","agentId":"main","match":{"channel":"feishu","accountId":"main"}},{"type":"route","agentId":"yunying","match":{"channel":"feishu","accountId":"yunying"}}]}

Gateway 断开的原因

日志显示 Gateway 收到 SIGTERM 后正常关闭了,但 LaunchAgent 没自动重新加载。

后来才搞明白——我之前一直是跑 openclaw gateway 在前台启动,而不是用 LaunchAgent。虽然 LaunchAgent 配了 KeepAlive: true,但前台进程不受它管,断开后就死了,不会自动起来。


解决问题

飞书多账号配置

改完 ~/.openclaw/openclaw.json 的配置,重启 Gateway:

openclaw gateway restart 

两个机器人都连上了。日志能看出来:

feishu[yunying]: WebSocket client started feishu[main]: WebSocket client started 

Gateway 自动重启

简单说就是别跑 openclaw gateway,改用 LaunchAgent:

# 先停掉前台运行的 Gateway# 然后用 LaunchAgent 方式启动 openclaw gateway install openclaw gateway start 

以后 Gateway 就会受 LaunchAgent 管理,断开会自动重启,不用每次手动搞了。


踩过的坑

总结一下:

  1. 飞书多账号要用 accounts 字段配,别想着开多个渠道
  2. Gateway 一定要用 openclaw gateway start 启动,别直接跑 openclaw gateway

有其他问题欢迎评论区聊聊。

Read more

Flutter 三方库 mediapipe_core 的鸿蒙化适配指南 - 实现高性能的端侧 AI 推理库集成、支持多维视觉任务与手势/表情识别实战

Flutter 三方库 mediapipe_core 的鸿蒙化适配指南 - 实现高性能的端侧 AI 推理库集成、支持多维视觉任务与手势/表情识别实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 mediapipe_core 的鸿蒙化适配指南 - 实现高性能的端侧 AI 推理库集成、支持多维视觉任务与手势/表情识别实战 前言 在进行 Flutter for OpenHarmony 的智能化应用开发时,集成强大的机器学习(ML)能力是打造差异化体验的关键。mediapipe_core 是谷歌 MediaPipe 框架在 Dart 侧的核心封装库。它能让你在鸿蒙真机上实现极其流畅的人脸检测、手势追踪以及实时姿态估计。本文将深入探讨如何在鸿蒙系统下构建低功耗、高响应的端侧 AI 推理链路。 一、原原理性解析 / 概念介绍 1.1 基础原理 mediapipe_core 作为 MediaPipe 的“神经中枢”

By Ne0inhk
Flutter 三方库 common_locale_data 的鸿蒙化适配指南 - 实现具备全球化区域元数据与多语言辅助能力的底层数据池、支持端侧国际化业务的精细化治理实战

Flutter 三方库 common_locale_data 的鸿蒙化适配指南 - 实现具备全球化区域元数据与多语言辅助能力的底层数据池、支持端侧国际化业务的精细化治理实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 common_locale_data 的鸿蒙化适配指南 - 实现具备全球化区域元数据与多语言辅助能力的底层数据池、支持端侧国际化业务的精细化治理实战 前言 在进行 Flutter for OpenHarmony 开发时,当我们的鸿蒙应用需要支持全球化(i18n)并涉及到复杂的地区逻辑(如:展示国家旗帜映射、获取特定地区的货币符号、或者根据 IP 解析所属大洲)时,散落在各处的硬编码数据会让维护成本剧增。common_locale_data 是一款专注于提供极致详尽、符合 ISO 标准的核心区域元数据仓库。本文将探讨如何在鸿蒙端构建稳健、专业的全球化数据底座。 一、原直观解析 / 概念介绍 1.1 基础原理 该库通过对 Unicode CLDR(Common

By Ne0inhk
Flutter 组件 satisfied_version 的适配 鸿蒙Harmony 实战 - 驾驭语义化版本约束、实现鸿蒙端精细化兼容性审计与分发策略动态对齐方案

Flutter 组件 satisfied_version 的适配 鸿蒙Harmony 实战 - 驾驭语义化版本约束、实现鸿蒙端精细化兼容性审计与分发策略动态对齐方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 satisfied_version 的适配 鸿蒙Harmony 实战 - 驾驭语义化版本约束、实现鸿蒙端精细化兼容性审计与分发策略动态对齐方案 前言 在鸿蒙(OpenHarmony)生态系统的快速迭代中,我们作为开发者,时刻面临着“版本碎裂”的挑战。不同的鸿蒙 API Level、不同的插件补丁版本、甚至是热更新包与主程序之间的语义化版本(SemVer)约束匹配,都直接决定了 App 在用户指尖的稳定性。 当你需要判断当前的系统版本是否满足 >=5.0.0 <6.0.0 这一严苛的运行范围,或者需要验证某一个从 Atomgit 下载的插件包是否兼容应用当前的宿主版本时,如果仅仅靠手动进行字符串切割和数字对比,不仅效率极低,更由于无法处理修正版本(Patch)

By Ne0inhk
Flutter 三方库 servicestack 的鸿蒙化适配指南 - 实现企业级 Message-based 架构集成、支持强类型 JSON 序列化与跨端服务调用同步

Flutter 三方库 servicestack 的鸿蒙化适配指南 - 实现企业级 Message-based 架构集成、支持强类型 JSON 序列化与跨端服务调用同步

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 servicestack 的鸿蒙化适配指南 - 实现企业级 Message-based 架构集成、支持强类型 JSON 序列化与跨端服务调用同步 前言 在进行 Flutter for OpenHarmony 的大型企业级应用开发时,如何确保端侧(鸿蒙应用)与后端服务之间的契约(Contract)高度一致,避免由于字段拼写错误导致的运行时异常?ServiceStack 是一套成熟的企业级消息驱动(Message-based)通讯框架。它能让你在鸿蒙端以极其严谨、类型安全的方式调用后端 API。本文将指导大家如何在鸿蒙系统下构建坚如磐石的服务通信层。 一、原理解析 / 概念介绍 1.1 基础原理 与传统的 REST 接口依靠手动编写 Model 不同,ServiceStack 倡导“契约先行”

By Ne0inhk