乐于分享
好东西不私藏

OpenClaw配置实战第二十一篇:企微群聊构建实战

OpenClaw配置实战第二十一篇:企微群聊构建实战

有些坑,不亲自踩一脚是不会信的。appchat 就是这样一个坑。


一、今天原本想做什么

P6.8 的源码改造已经全部完成:ChatId 解析、关键词过滤、SOUL/IDENTITY 人设扩展,代码一行都没有问题。剩下最后一步——在企微管理后台创建群聊,然后真机测试「洵儿你好」。

听起来不过是十分钟的收尾工作。


二、发现 appchat 是个单向通道

打开企微管理后台,找到 appchat 接口,appchat/create 创建群聊,chatid 是 xunFamilyGroup,一切正常。appchat/send 发了一条测试消息,群里也收到了。

然后发现问题:群成员发的消息,根本不会推送到回调 URL。

不是配置问题,不是 URL 格式不对。老钳花了 36 分钟,抓取企微官方文档四页,读 wecom-app 源码,输出了一份 368 行的研究报告——结论只有一个:

appchat/create 创建的是「应用管控群」,官方设计就是应用→群的单向通道。群成员发的消息不会触发任何回调,无论回调 URL 怎么配置。

设计如此,不是 bug,不是缺失,就是这么干的。


三、三个替代方案的权衡

老钳在报告里给了三个方案:

方案 A:企微智能机器人 API

  • 支持 @机器人触发和流式回复
  • 致命缺陷:不能主动发消息,晚报推送等功能全部废掉
  • 需同时维护两套身份
  • 结论:不推荐

方案 B:第三方企微 SaaS

  • 成本高,数据外流风险
  • 结论:不考虑

方案 C:普通内部群(自建应用作为群成员)

  • 在企微客户端手动创建普通内部群,把自建应用加进去
  • 普通内部群的消息会正常推送到回调 URL,XML 里含 ChatId
  • 代码零改动:P6.8 已实现的 ChatId 解析 + 关键词过滤全部适用
  • 结论:首选方案 ✅

关键区别只在「创建群的方式」:管理后台创建 = 应用管控群(单向);客户端手动创建 = 普通内部群(双向)。


四、补锅:系统全面维护

既然今晚不能真机测试了,让老钳顺便把系统状态检查一遍。一查不要紧,发现了四个待修的问题。

问题一:Gateway 日志没有输出

tail -f ~/.openclaw/gateway.log 一行都没有。定位根因:openclaw-autostart.sh 里启动 Gateway 的命令漏掉了日志重定向 >> gateway.log 2>&1。老钳修复脚本,重启 Gateway(PID 95758 → 14299),日志恢复写入。

问题二:熔断计数器非零但 Gateway 健康

cat ~/.openclaw/watchdog_fail_count 输出 3。Gateway 本身完全正常(端口监听中,企微消息正常收发),但 watchdog 已进入熔断状态,不再自动守护。原因是上次手动重启时计数器没有归零。一行命令修复:

echo"0" > ~/.openclaw/watchdog_fail_count

问题三:canvas-os 尚未安装

clawhub rate limit 绕不过,老钳通过 GitHub API 手动拉取 fraction12/canvas-os 源码安装。安全审查通过(纯本地工具,无外发请求)。Skill 总数升至 17 个。

问题四:crontab 全景确认

全部正常调度,日志健康。


五、另一个隐患:WECOM_CORP_SECRET 泄露

这件事容易被忽视,但很重要。

今天的对话记录里出现了完整的 WECOM_CORP_SECRET 字符串——是我在配置 IP 守护脚本时粘贴进去的。这个 secret 现在需要轮换。

老钳列出了所有引用位置:

  • crontab 顶部环境变量声明:1 处
  • ip-watchdog.sh 脚本内:1 处

轮换流程:企微管理后台重置 secret → 更新 crontab 声明 → 更新脚本。

📌 安全铁律:凡是出现在对话记录、文档、版本控制里的 secret,都要当作已泄露处理,及时轮换。


六、踩坑与反模式

踩坑一:appchat 与普通群的本质区别

appchat/create 创建的是单向的「应用管控群」,不是可以双向通信的普通群。想让群成员消息触发回调,必须通过企微客户端手动建群,再把自建应用加为成员。

踩坑二:Gateway 日志重定向不能漏

autostart.sh 启动 Gateway 时如果没有 >> gateway.log 2>&1,日志会进黑洞。排障时 tail 什么都看不到,凭空调试。

踩坑三:手动重启不要忘记归零熔断计数器

每次手动重启 Gateway 后,都要检查并归零 watchdog_fail_count,否则 watchdog 会一直保持熔断状态,下次崩溃就没有人自动拉起了。

踩坑四:敏感信息出现在对话记录即视为泄露

Secret、API Key、密码一旦粘贴进对话,就要假设它已经泄露并及时轮换。不能因为「只是测试」就侥幸。


七、可复用 Checklist

  • [ ]  企微群聊接入:用企微客户端建普通内部群,不要用管理后台 appchat 接口
  • [ ]  自建应用加入普通内部群后,群消息会推送至回调 URL(含 ChatId)
  • [ ]  autostart.sh 启动 Gateway 必须加 >> gateway.log 2>&1,否则日志丢失
  • [ ]  手动重启 Gateway 后:echo "0" > ~/.openclaw/watchdog_fail_count 归零熔断计数器
  • [ ]  定期检查 crontab + 日志三件套(watchdog / ip-watchdog / backup)
  • [ ]  对话记录出现 secret → 立即去管理后台轮换 + 更新所有引用位置

八、下一步

普通内部群方案确认,代码零改动,技术前置条件全部就位。下一步只需要两步人工操作:

  1. 企微客户端创建普通内部群,把自建应用加进来
  2. 在群里发「洵儿你好」,看看他能不能听见

另外还有一件事没做:WECOM_CORP_SECRET 轮换。这件事不紧急,但不能一直拖。


作者:喜感星球 × 老钳 | 2026.03

appchat = 应用管控群(单向)。普通内部群 = 应用作为成员的双向群。这两个词在企微文档里长得很像,但设计完全不同。