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

Cursor+Codex深度联动教程:用AI插件自动重构老旧前端代码(React 18案例)

Cursor + GPT-5-Codex:从技术债泥潭到现代化前端的工程化重构实战 接手一个遗留的React项目,就像走进一间堆满旧家具的仓库。组件文件动辄上千行,状态逻辑和UI渲染纠缠不清,样式表是十年前的技术栈,测试覆盖率几乎为零。每次新增功能都如履薄冰,生怕触动哪根脆弱的神经,导致整个应用崩溃。这种技术债的累积,不仅拖慢开发速度,更让团队士气低落。然而,现在你手中多了一件前所未有的利器——Cursor IDE 与 GPT-5-Codex 的深度联动。这不再仅仅是代码补全工具,而是一个能理解项目上下文、执行复杂工程任务、甚至能连续工作数小时的“数字编程伙伴”。本文将带你深入实战,看我们如何利用这套组合拳,对一个基于React 16和传统CSS的遗留学习应用,进行一场彻底的、工程化的现代化重构,最终将其升级为React 18 + TypeScript + Chakra UI的现代化应用。 1. 环境搭建与项目诊断:建立清晰的改造基线 在挥舞重构大锤之前,我们必须先给项目做一次全面的“体检”。盲目动手只会让混乱的代码更加混乱。我们的目标项目是一个名为“LingoLearn”的英

《C#上位机开发从门外到门内》3-5:基于FastAPI的Web上位机系统

《C#上位机开发从门外到门内》3-5:基于FastAPI的Web上位机系统

文章目录 * 一、项目概述 * 二、系统架构设计 * 三、前后端开发 * 四、数据可视化 * 五、远程控制 * 六、系统安全性与稳定性 * 七、性能优化与测试 * 八、实际应用案例 * 九、结论 随着互联网技术的快速发展,Web上位机系统在工业自动化、智能家居、环境监测等领域的应用日益广泛。基于FastAPI或Flask的Web上位机系统,凭借其高效、灵活和易于扩展的特点,成为当前研究和应用的热点。本文将详细探讨基于FastAPI和Flask的Web上位机系统的设计与实现,涵盖系统架构、前后端开发、数据可视化、远程控制、安全性、性能优化以及实际应用案例等方面,旨在为相关领域的研究人员和工程技术人员提供参考和借鉴。 一、项目概述 Web上位机系统是一种通过网络实现对远程设备或环境进行实时监控和控制的系统。其核心目标是通过高效的数据传输和处理,确保监控的实时性和准确性,从而实现对远程设备的有效管理和控制。基于FastAPI或Flask的Web上位机系统利用Python的Web框架,通过互联网或局域网实现数据的传输和通信,具有广泛的应用前景。 Fa

【Linux篇章】穿越网络迷雾:揭开 HTTP 应用层协议的终极奥秘!从请求响应到实战编程,从静态网页到动态交互,一文带你全面吃透并征服 HTTP 协议,打造属于你的 Web 通信利刃!

【Linux篇章】穿越网络迷雾:揭开 HTTP 应用层协议的终极奥秘!从请求响应到实战编程,从静态网页到动态交互,一文带你全面吃透并征服 HTTP 协议,打造属于你的 Web 通信利刃!

本篇摘要 本篇将介绍何为HTTP协议,以及它的请求与答复信息的格式(请求行,请求包头,正文等),对一些比较重要的部分来展开讲解,其他不常用的即一概而过,从静态网页到动态网页的过渡,最后底层基于TCP实现简单的HTTP服务器的代码编写构建一个简单的网页(包含对应的跳转,重定向,动态交互等功能),采取边讲解http结构边用代码形成效果展示的形式进行讲解,望有助! 欢迎拜访:点击进入博主主页 本篇主题:探秘HTTP应用层那些事儿! 制作日期:2025.07.21 隶属专栏:点击进入所属Linux专栏 本文将要介绍的内容的大致流程图如下: 一· 认识HTTP * 在互联网世界中, HTTP(HyperText Transfer Protocol, 超文本传输协议) 是一个至关重要的协议。 它定义了客户端(如浏览器) 与服务器之间如何通信, 以交换或传输超文本(如 HTML 文档) 。 * HTTP 协议是客户端与服务器之间通信的基础。 * 客户端通过 HTTP 协议向服务器发送请求, 服务器收到请求后处理并返回响应。 HTTP 协议是一个无连接、

五种常用的web加密算法

五种常用的web加密算法

文章目录 * 五种常用Web加密算法实战及原理详解 * 1. AES (高级加密标准) * 原理详解 * 应用场景 * 实战代码(Node.js) * 2. RSA (非对称加密) * 原理详解 * 应用场景 * 实战代码(Node.js) * 3. SHA-256 (安全哈希算法) * 原理详解 * 应用场景 * 实战代码(浏览器环境) * 4. HMAC (基于哈希的消息认证码) * 原理详解 * 应用场景 * 实战代码(Node.js) * 5. PBKDF2 (基于密码的密钥派生函数) * 原理详解 * 应用场景 * 实战代码(Node.js) * 加密算法对比表 * 安全最佳实践 * 进阶主题 五种常用Web加密算法实战及原理详解 在现代Web开发中,数据安全至关重要。以下是五种最常用的Web加密算法,包括它们的原理、应用场景和实战代码示例。