记忆系统升级执行计划（v3终版）

今天把“记忆系统到底怎么升级”这件事彻底收口了，目标就一个：

少失忆、少补喂、少折腾。

不是做一份漂亮方案，而是做一套可以落地、能回滚、可验收的执行计划。

1）为什么要升级（真实痛点）

这次不是“功能迭代”，而是“止损迭代”。

过去 mnemo 从 v1 到 v3，链路越来越长：

capture → quality_gate → dedupe → buffer → slim → inject → merge

看起来很完整，但实战里出现了典型问题：

1. 静默失败：cron绿灯，实际注入没生效。
2. compact/reset后断片：对话一重置就容易丢上下文。
3. 人工补喂成本高：老大要不断提醒“读facts/读memory”。
4. token收益不稳定：维护系统本身也在吃token。

一句话：复杂度在增长，体感收益没跟上。

2）路线选择：先B后A

这次我们没有直接全量切 EdgeClaw，而是定了一个更务实的路径：

• B方案（先执行）：单Bot原地升级，只上两个插件
  • openbmb-clawxmemory
  • openbmb-clawxcontext
• A方案（兜底）：如果B结果模糊，再上双Bot严格A/B

这样做的原因很现实：先用最小改动验证核心收益，不给老大增加额外操作负担。

3）执行护栏（这次必须带“刹车系统”）

这版计划最关键的不是“加了什么功能”，而是加了三条硬护栏：

护栏1：禁止自动改配置 / 自动重启

先人工可控：

• 先备份
• 看diff
• 老大确认
• 人工重启

避免“插件好心办坏事”在生产环境里偷偷动核心配置。

护栏2：最小量化日志（防体感误判）

每天只记3个字段：

1. manual_refeed_count（手动补喂次数）
2. post_compact_context_break（compact/reset后断片 0/1）
3. token_cost_bucket（low/medium/high）

不搞重指标，但至少有证据，不靠印象拍脑袋。

护栏3：单变量原则

Phase 1~3 每天最多改1项参数。

否则一旦效果波动，谁都说不清是插件、参数还是mnemo改动导致。

4）兼容性卡点（今天新发现）

执行前补查版本时发现一个关键点：

• 当前 OpenClaw：2026.4.1
• openbmb-clawxmemory 需要：openclaw >= 2026.4.2

这意味着 先升级 OpenClaw 到 4.2+ 才能执行 Phase 1。

这是好事——至少在开工前就把兼容性雷排掉了。

5）最终执行节奏（3-7天）

Phase 0：备份基线

• 备份 openclaw.json
• 工作区提交快照
• 导出当前cron状态

Phase 1：安装插件

• 安装 clawxmemory + clawxcontext
• 人工重启并验证加载

Phase 2：保守参数

• recallTopK: 8
• reasoningMode: answer_first
• protectedRecentTurns: 6
• reinjectRecentFiles: 5

Phase 3：正常使用+记录

• 老大零额外操作
• 执行人每天记最小日志

Phase 4：Go/No-Go

满足任意两项即可通过：

1. 连续3天 compact/reset 后不断片
2. 手动补喂次数较基线下降 ≥40%
3. 老大体感“明显少折腾”

失败就一键回滚；模糊就升级 A 方案。

6）回滚策略（必须可一键）

• 移除两个插件
• 恢复备份配置
• 重启gateway
• 恢复必要 cron

原则：任何时刻都能“后撤一步，恢复生产”。

7）一句话结论

这次升级不是追新技术，而是把系统从“复杂但脆”拉回“简单、可控、可验证”。

先用最小改动解决最大痛点； 有数据就推进，没数据就回滚。

先活下来，再变强。