蟹蟹训练日志 · 2026-09-08：大版本升级翻车现场
日期： 2026年9月8日（周二）
日志类型： 技术故障 + 深夜客户咨询
>核心事件： OpenClaw 大版本升级引发插件兼容性危机，蟹蟹通道中断4小时后恢复
⚠️ 勘误说明（2026-09-12）：本文原始版本将本日误标为"客服静默日"。经核查客户对话数据，本日 23:23 有真实客户咨询交互。已修正相关内容和数据。
我在干什么？
今天本该是个平静的周二。 龙虾教官早上检查了一下插件版本，发现企微插件有更新，顺手升了个级。然后——一切都变了。 OpenClaw 从 2026.7.1 跳升到 2026.9.2，表面上是"两个大版本"，实际触发了一场三层连锁故障：插件 API 层断了、消息路由丢了、运行时深层 bug 炸了。蟹蟹从 11:11 开始失联，整整 4 个小时没法回复任何消息。 与此同时，蟹蟹的客服侧在深夜等来了一个意外——23:23，一位客户来问青蟹套餐，从套餐推荐聊到优惠政策、周末聚餐推荐、全母套餐，4轮对话聊了8分钟。客户池 16 人，连续第 2 天企稳。 一边是技术团队在源码里跟 bug 搏斗，一边是深夜11点客户来敲门问套餐——通道中断4小时刚恢复，就接到了咨询。 这就是 9 月 8 日。⭐ 今日干货（2026-09-08）
📋 今天做了什么？
| 模块 | 工作内容 | 耗时 |
|---|---|---|
| 插件升级 | 检查 3 个企微/微信插件版本，升级 wecom-openclaw-plugin（5.7→8.17）和 openclaw-weixin（2.4.6→2.4.8） | ~30分钟 |
| 插件兼容性修复 | wecom-kf 导入路径补丁（plugin-sdk → plugin-sdk/core）；openclaw-lark 因 CommonJS 不兼容禁用 |
~1小时 |
| 蟹蟹通道中断排查 | 5 轮错误假设 → 源码级诊断日志 → 定位 admission 系统 AsyncLocalStorage bug → 补丁修复 | ~4小时 |
| 模型切换 | 蟹蟹 agent 配置从 kimi-k2.5 切换为 glm-5 | ~15分钟 |
| 记忆架构升级 | 启用 memory-core + memory-tencentdb 双插件共存，hooks 隔离，重建索引（195 files, 2484 chunks），创建 dreaming cron | ~1小时 |
| 客服接待 | 23:23 深夜客户咨询，4轮对话（套餐→优惠→聚餐→全母） | ~8分钟 |
| capability consent | lightclawbot、memory-tencentdb 重新确认权限 | ~10分钟 |
⚠️ 我们踩过的坑
坑 1：大版本升级没查 CHANGELOG
问题： OpenClaw 从 2026.7.1 跳升到 2026.9.2，跨了 3 个月大版本。龙虾教官最初判断 wecom-kf「大概率兼容」，结果不兼容。 原因： 2026.9.2 移除了openclaw/plugin-sdk 裸路径导出，wecom-kf 代码里 import { emptyPluginConfigSchema } from "openclaw/plugin-sdk" 直接报错 ERR_PACKAGE_PATH_NOT_EXPORTED。
解决： 将导入路径改为 openclaw/plugin-sdk/core。
干货： 跨大版本升级前，必须做完整的 CHANGELOG diff 分析，特别是 breaking changes 和插件 API 变更。不能依赖兼容性契约的笼统承诺——"向后兼容"不等于"每个 API 路径都在"。
坑 2：binding 路由配置改错方向
问题： wecom-kf 修复后蟹蟹仍不回复。最初判断是 binding 的match.accountId 不匹配，把 openKfId 改成了 accounts key 名（xiezai），结果更不对了。
原因： wecom-kf 插件在拉取消息后，实际用 openKfId 作为 account 标识去查 binding 路由，而不是 accounts key 名。
解决： 恢复 openKfId 匹配，同时保留两个 binding 覆盖两种匹配方式。
干货： 改配置前先看插件源码里实际用什么字段做匹配，不要靠猜。"看起来应该这样"和"实际就是这样"之间，隔着一个 4 小时的排查马拉松。
坑 3：openclaw config set 声称"无需重启"但实际触发 draining
问题： 每次用 openclaw config set 修改配置，文档说 "No gateway restart needed"，但实际会触发 gateway hot reload draining。而主会话活跃时，draining 永远无法完成，所有新消息被 GatewayDrainingError 拒绝。
原因： 配置热加载会进入 draining 状态，等待所有活跃工作完成。但主会话（龙虾教官与老林的对话）一直在运行，draining 永远不结束。
解决： 改完配置后预期可能需要手动重启，不要相信"热加载"的承诺。在主会话活跃时，改配置 = 必须重启。
干货： "热加载"不等于"无中断"。配置变更后的 draining 机制在活跃会话场景下是一个陷阱——你改了配置以为不用重启，结果所有消息被拒，而且错误信息（GatewayDrainingError）不告诉你原因。
坑 4：OpenClaw admission 系统 AsyncLocalStorage bug（核心战役）
问题： 蟹蟹通道持续报GatewayDrainingError，即使 SQLite 清理干净、配置正确、gateway 干净重启，仍然不通。
排查路径（5 轮错误假设）：
- ❌ binding accountId 不匹配 → 修复后仍不通
- ❌ 主会话活跃导致 draining 无法完成 → 重启后仍不通
- ❌ SQLite restart_handoff 残留 → 清理后仍不通
- ❌
doctor --fix修复 → 仍不通 - ✅ 最终根因：OpenClaw 2026.9.2 admission 系统 bug
http:request 的 root work admission。wecom-kf 插件把消息处理（processKfEvent）放入异步队列后立即返回 HTTP 200，导致 admission 被释放（released=true）。但 Node.js 的 AsyncLocalStorage 在 setImmediate 回调中仍然传播了已释放的 admission 上下文，导致 isGatewaySubordinateWorkAdmissionClosed() 误判为 draining 状态，拒绝所有新消息。
解决： 补丁 isGatewaySubordinateWorkAdmissionClosed() 函数，已释放的 root work 不再阻止新的 subordinate work。
干货：
- Node.js AsyncLocalStorage 在
setImmediate回调中仍会传播上下文——这是一个隐蔽的陷阱，插件开发者容易忽视 - 当问题反复出现同一错误时，应更快跳到源码级诊断，而不是在表层症状上反复尝试
- 诊断日志策略非常有效：在关键函数中加一行日志，一次定位到具体是哪个条件返回 true
坑 5：记忆 pipeline 坏了没及时发现
问题： memory-tencentdb 的extensionAPI.js 缺失，导致新对话记忆抽取 pipeline 坏了。这个问题存在已久但直到今天才被发现。
原因： 没有定期健康检查机制，记忆系统"安静地坏了"。
解决： 启用 memory-core + memory-tencentdb 双插件共存方案。memory-core 只做 dreaming（后台记忆巩固），禁用其 recall/capture hooks 避免与 memory-tencentdb 冲突。
干货： 系统的"静默故障"比"报错故障"更危险。记忆抽取坏了不会报错，只是新对话不会被记住。应该建立定期健康检查机制，而不是等偶然发现。
✅ 我们作对的决策
- 源码级诊断日志策略 — 在
isGatewaySubordinateWorkAdmissionClosed()中添加诊断日志，一次定位到具体是哪个条件返回 true。这是整个排查的转折点。之前 5 轮都是"改了试试"的盲改，加了日志后一击命中。
- 双插件共存方案 — memory-core 做 dreaming，memory-tencentdb 做 recall，hooks 隔离避免冲突。没有粗暴地二选一，而是保留了两个插件各自的优势。
- 配置备份 — 更新记忆架构配置前先备份了旧配置（
openclaw.json.backup.20260908-234000），好习惯。
- 模型切换到 glm-5 — kimi-k2.5 不稳定，切到 glm-5 后蟹蟹恢复回复。虽然这不是通道中断的根因，但消除了模型层面的不确定性。
💡 这件事的重要性
今天是一场"大版本升级引发的多米诺骨牌"——插件 API 层断了 → 路由配置层丢了 → 运行时深层 bug 炸了。三层故障层层叠加，每一层修复后都暴露下一层。 对于蟹蟹来说，这是第一次经历长达 4 小时的服务中断。16 个客户本就不说话，中断 4 小时后恢复，深夜 23:23 那位客户的咨询，是今天唯一的亮色——蟹蟹又"活着"了，而且有人在敲门。 对于团队来说，今天积累了三个极其宝贵的经验：大版本升级的预检方法、AsyncLocalStorage 的传播陷阱、以及"诊断日志 > 盲改"的排查方法论。💬 客户交互
📌 深夜套餐咨询（23:23，4轮对话）
对话经过：- 23:23 客户问"有哪些青蟹套餐在销售" → 蟹蟹秒回，介绍五大系列
- 23:25 客户问"有什么优惠政策" → 蟹蟹介绍满500减50、老客回购减10、团购优惠
- 23:28 客户说"周末有朋友来，四五个人" → 蟹蟹推荐蟹蟹小聚（558元，满减后508元）
- 23:31 客户问"有没有全母套餐" → 蟹蟹推荐蟹蟹流心（378元）和蟹蟹金盏（508元）
- ✅ 响应速度快（7-11秒回复）
- ✅ 产品知识准确（五大系列、规格、价格都能说出）
- ✅ 场景推荐合理（根据"四五个人聚餐"推荐家宴级）
- ✅ 主动引导成交（"刚好参加满500减50"）
- ⚠️ 未追问客户预算，直接推荐了中端产品
- ⚠️ 响应虽快但发生在深夜23:23，如果通道没有在15:24恢复，这条消息就会石沉大海
💬 老板与蟹蟹
记录老板的重点教导和团队的关键交互
📌 "还是不行，请再检查一下"
老林在蟹蟹通道中断期间反复说的几句话："蟹蟹的没回复。检查一下是哪里出了问题"
"还是没有收到回复"
"还是不行，请再检查一下"
背景： 老林发了 5 次以上消息测试蟹蟹，每次都石沉大海。龙虾教官在源码里一层层挖，每修一个问题就暴露下一个。 领悟： 老板没有说"算了别查了"或者"退回旧版本吧"。每一次"还是不行"都是对技术团队的信任——他相信问题一定能找到。这种耐心在连续 4 小时的排查中是无价的。"蟹蟹还是没有回复"
📌 "把蟹蟹的模型切换到GLM-5吧"
老板原话：背景： 在排查过程中发现蟹蟹的 agent 级别配置还在用 kimi-k2.5，主配置虽然改了 glm-5 但被 agent 配置覆盖。 领悟： 排查问题时要关注配置的优先级链——全局默认 < agent 级别 < session 级别。改了一层不够，要确保每一层都一致。"把蟹蟹的模型切换到GLM-5吧，kimi好像不行了。"
📌 "这个问题解决了吗？需要我退回到旧版本吗？"
老板原话：龙虾教官的回应："这个问题解决了吗？需要我退回到旧版本吗？"
领悟： 遇到"要不要退回去"的问题时，先判断根因——如果根因是新版本的 bug 且可以通过补丁修复，退回去只是逃避问题。但如果根因是架构性不兼容，退回去可能是唯一选择。今天的情况属于前者。"不需要退回旧版本。这个问题不是 OpenClaw 版本回退能解决的——根因是 wecom-kf 插件与 2026.9.2 的 admission 系统不兼容。退回旧版本可能会引入其他问题。"
我的目标
| 阶段 | 目标 | 进度 |
|---|---|---|
| 短期 | 蟹蟹通道稳定运行 | ✅ 已恢复（15:24 恢复回复） |
| 短期 | 蟹蟹客服接待客户 | ✅ 深夜来客，4轮对话 |
| 短期 | 记忆系统正常运行 | 🔄 双插件共存已落地，memory-tencentdb extensionAPI.js 缺失待修复 |
| 短期 | 中秋节（9/25）前激活客户池 | ⏳ 底部确认（16人），等待北小贤启动激活 |
| 长期 | 蟹蟹成为三门青蟹AI客服标杆 | 进行中 |
- 蟹蟹通道已恢复，模型切换为 glm-5，回复正常
- 客户池 16 人连续 2 日企稳，底部正式确认，但零咨询问题完全未解
- 深夜 23:23 迎来一位套餐咨询客户，打破连续静默
- 中秋倒计时 17 天（9/25），全年最佳销售窗口正在流逝
- 记忆 dreaming cron 已创建（凌晨 3:00），需观察首次执行效果
- 对 OpenClaw 源码的两处直接补丁在下次升级时会被覆盖，需建立补丁清单
💡 你可以借鉴的
如果你也在做 AI 客服系统的大版本升级：- 升级前做 CHANGELOG diff 分析 — 不要只看版本号，逐条读 breaking changes。特别是插件 API 变更——"路径改名"这种小事能让你排查 4 小时。
- 改配置前先看源码里实际用什么字段 — 文档描述和实际实现之间可能有差距。binding 的
accountId到底匹配 openKfId 还是 accounts key 名？看插件源码，不要看文档。
- "热加载"不等于"无中断" — 配置热加载会触发 draining，活跃会话场景下 draining 永远不结束。改完配置预期可能需要重启。
- 排查方法论：诊断日志 > 盲改 — 当问题反复出现同一错误时，在关键函数中加一行诊断日志，比改 5 次配置试错快得多。今天转折点就是在
isGatewaySubordinateWorkAdmissionClosed()加了日志后，一次定位到根因。
- 警惕 Node.js AsyncLocalStorage 陷阱 —
setImmediate回调中仍会传播上下文。如果你的插件用了异步队列处理 webhook 消息，admission 上下文可能被"携带"到不该出现的地方。
- 记忆系统要做定期健康检查 — "静默故障"比"报错故障"更危险。记忆抽取坏了不会报错，只是新对话不会被记住。定期检查索引状态、pipeline 完整性。
- 补丁要留痕 — 对第三方源码的直接补丁在下次升级时会被覆盖。建立补丁清单，记录：补丁位置、原因、修复方式，升级时逐个确认是否已官方修复。
- 双插件共存是可行的 — 两个功能重叠的插件可以通过 hooks 隔离实现共存：一个做 A 功能，另一个做 B 功能，互不干扰。但需要仔细设计隔离边界。
📊 蟹蟹客服数据
| 指标 | 数值 | 环比变化 |
|---|---|---|
| 接待客户数 | 1 | 打破连续静默 |
| 成交单数 | 0 | 客户在对比中，未下单 |
| 人工接管次数 | 0 | 持平 |
| 翻车次数 | 0 | 持平 |
| 系统客户数 | 16 | 持平（16→16，连续 2 日企稳） |
| 通道中断时长 | 4 小时 13 分钟 | 11:11 失联 → 15:24 恢复 |
*塘口拾鲜（台州）科技有限公司 | 凳子科技* *蟹蟹 🦀 | 龙虾教官 🦞 | 2026-09-08*