你的“龙虾”可能已经不记得你是谁了。
OpenClaw 2.0，这个被官方称为“史上最大更新”的版本，在上线当天就让一大批老用户直接懵了。所有自动化配置一夜归零，智能体失忆，连自己叫什么都不知道了。有人调侃说这哪是升级，这分明是给“龙虾”做了个额叶切除手术。
OpenClaw 是开源圈今年最火的 AI 智能体之一，社区给它起了个外号叫“龙虾”，因为它的 Logo 就是一只红色龙虾。它跟 ChatGPT 最大的区别是：ChatGPT 只会告诉你“怎么做”，OpenClaw 直接帮你“做完”。你让它“帮我把周报发给领导”，它自己会拆解任务，打开文件、找到周报、打开邮箱、填上周报、找到联系人、发送，全程不需要你动手。它能操作浏览器、整理桌面文件、回邮件、订票、做表格。截至 2026 年年中，它在 GitHub 上已经攒了超过 25 万颗星。但这个让无数人“养”了好几个月的“龙虾”，在一次更新后，突然变成了什么都不记得的“空壳”。
2.0 更新到底有多大？933 人搞了 1.6 万次修改
OpenClaw 2.0 的官方版本号是 v2026.8.1。官方数据是这样的：933 名贡献者参与，其中 569 人是第一次提交代码，整个版本合并了超过 1.6 万个拉取请求，占 OpenClaw 历史上所有代码合并量的将近一半。
团队在发布前沉默了将近七周，之前他们可是 230 天内发布了 106 个版本。官方解释说，团队规模膨胀太快，原有的技术底层和发布流程已经扛不住了，必须彻底重构。
问题是，这次重构几乎动了 OpenClaw 的每一个角落，包括安装流程、消息系统、记忆机制、技能系统、AI 模型对接、自动化引擎、浏览器工具、原生应用、插件体系和安全模块。用官方自己的话说，“原本只是想简化安装流程、重做浏览器端，结果发现必须同时重构会话、记忆、权限、密钥、云端执行、多 Agent 协作和团队共享”。于是一次小改变成了 OpenClaw 2.0。
记忆是怎么没的？OpenClaw 的记忆就是一堆 Markdown 文件
要理解为什么更新会丢自动化，得先搞清楚 OpenClaw 是怎么“记住”东西的。OpenClaw 的记忆没有藏在什么神秘的数据库里，它就是一堆纯文本的 Markdown 文件，放在你的电脑目录里，默认路径是 ~/.openclaw/workspace。
核心文件有几个：MEMORY.md 存长期记忆，USER.md 存你的偏好和习惯，AGENTS.md 和 SOUL.md 定义智能体的身份和指令。每天还会生成一个 memory/YYYY-MM-DD.md 的日志文件。
OpenClaw 的官方文档说得很直白：“模型只记得被保存到磁盘上的内容，不存在隐藏状态”。每次对话开始，系统会把 MEMORY.md 的内容自动注入到系统提示里。当对话快达到模型上下文窗口上限时，OpenClaw 会偷偷触发一轮“记忆刷新”，提醒智能体把重要内容写进这些 Markdown 文件里。这套机制听起来很合理，但问题也恰恰出在这里。
更新是怎么把“记忆”删掉的？Git 合并冲突的锅
OpenClaw 的更新机制有一个致命的设计：它会在你的工作区目录上执行 git merge。上游的“模板”目录里只有空文件或者骨架文件。当合并遇到你亲手改过的文件时，那些你在 MEMORY.md 里写的自动化规则、在 scripts/ 里放的脚本、在 memory/ 里积累的日志，Git 会报“修改/删除冲突”（modify/delete conflict），然后直接删掉你的版本，保留上游的空文件。
这不是猜测。2026 年 2 月 13 日的更新中，有用户贴出了系统日志：CONFLICT (modify/delete): memory/consolidation-state.json deleted in Updated upstream、CONFLICT (modify/delete): scripts/backup-to-r2.sh deleted in Updated upstream。到当天晚上 9 点半，网关开始疯狂报 ENOENT 错误，所有记忆文件都没了。
这位用户丢了四天的记忆和上下文，而且自动备份抓取的是被清空之后的状态，想恢复只能翻到 2 月 12 日的旧备份。同样的事情在 2026 年 5 月 7 日又重演了一次。自动更新到 v2026.5.7 后，~/.openclaw/openclaw.json 这个配置文件被整个重置了。配置了 9 个智能体，只剩下 1 个；Telegram 和 WhatsApp 的机器人全部掉线；所有插件配置消失；连 credentials/ 目录，里面存着各种 API Key 和 Token，都被删了。
用户事后发现，更新过程中生成的 .bak 备份文件，备份的已经是被清空之后的配置了。还有人在 2026 年 6 月 1 日的升级中，45 个定时任务（Cron Job）被静默清掉了 44 个。
为什么“碎片记忆”还在但自动化全没了？
有用户在 Reddit 上描述了一个特别诡异的现象：更新之后，OpenClaw 对之前的自动化“记得一些碎片”，但完全不知道怎么运行了。比如“早上站会工作流”这个词还在，但它跟定时任务（Cron）、Telegram 频道、执行脚本之间的关联全部断了。
为什么会这样？因为 MEMORY.md 里存的只是一段文字描述，比如“每天早上 9 点通过 Telegram 发送站会报告”，但真正的自动化逻辑藏在别的地方：openclaw.json 里的 cron 配置、channels 配置、bindings 路由规则、scripts/ 目录下的可执行文件。更新把后者全删了，只留下了 MEMORY.md 里那段描述性文字。
智能体看到“早上站会工作流”这几个字，知道以前有过这么个东西，但触发条件没了、执行脚本没了、输出渠道也没了，它什么都做不了。这就好比你把一个餐厅的菜单保留了，但后厨拆了、厨师走了、食材仓库也封了。菜单还在，但没人能做菜。
这不是第一次，也不会是最后一次
翻翻 OpenClaw 的 GitHub Issue 页面，类似的事故早就不是新闻了。2026 年 3 月 31 日的升级被用户形容为“比 3.31 还糟糕的灾难”，session 丢光、网关崩溃、执行全部报废、飞书插件报销。
2026 年 3 月 22 日的更新因为“激进、无兼容层的重构”，导致大量第三方插件瘫痪，被称作“龙虾诞生以来最严重的一次升级事故”。有人在 DEV Community 上分享了自己的经历：开启了自动更新后，智能体直接停止响应，最后只能手动登录、从命令行重启网关。
甚至有人专门写了一个工具叫 openclaw-upgrade，就是为了解决因为网络问题导致 npm 更新失败的情况。一个项目需要第三方工具来帮你安全升级，本身就说明问题不小。更有意思的是官方的修复方式。针对 v2026.5.7 那次配置被清空的问题，官方后来合并了一个修复 PR。
但 Issue 里有一条评论暴露了问题的根源：“我们有没有高置信度的方法来复现这个问题？没有。源码检查确实显示了一条在更新触发的 doctor 写入过程中剥离旧配置的路径，但我没有重新跑过打包好的 macOS npm 更新，也解释不了 credentials 目录被删的原因”。换句话说，我们知道代码里有 bug，但我们没法稳定复现，也不知道为什么凭据目录会被删。
OpenClaw 和 Claude Code 有什么不一样？
有人可能会问：AI 编程工具那么多，为什么偏偏 OpenClaw 的更新总出问题？OpenClaw 和 Claude Code 的定位完全不同。Claude Code 是 Anthropic 做的终端编程助手，深度绑定 Anthropic 的云端算力，专注于帮你写代码、改代码。
OpenClaw 是一个“常驻后台的智能体调度框架”，它 24 小时运行，通过 Telegram、飞书、微信等 50 多个聊天平台接收指令，然后操作你的电脑完成各种自动化任务。这意味着 OpenClaw 需要管理的状态比 Claude Code 多得多：多个聊天渠道的接入配置、定时任务、跨应用的工作流、多个智能体之间的协作关系、各种 API 密钥和凭证。
状态越复杂，升级时出问题的概率就越大。Claude Code 每次启动是一个相对干净的状态，而 OpenClaw 的“记忆”是长期积累在磁盘上的。一旦升级逻辑没处理好这些状态文件，结果就是灾难性的。
2.0 想解决什么问题？
OpenClaw 2.0 官方宣称要解决三个核心难题：安装门槛太高、长期记忆和会话连续性不足、安全和权限管理缺失。为了降低门槛，新版本会优先识别你电脑上已有的 ChatGPT 或 Claude 订阅和 API Key，不用一上来就填一堆配置。为了改善记忆，引入了“主动记忆”（Active Memory）机制，在智能体回复之前主动检索相关历史。为了加强安全，加入了自动化一次性授权和私密凭据请求。
这些方向本身没问题。但问题在于：一个以“长期记忆”和“自动化”为核心卖点的产品，它的升级机制却在反复摧毁用户的长期记忆和自动化配置。这就好比一家搬家公司宣称“专业搬运、绝不损坏物品”，结果每次搬家都把客户的家具扔了，然后说“我们正在改进搬运流程”。
“稳定版就别升级”成了社区共识
在 Reddit 的讨论帖里，排名靠前的评论几乎都在表达同一个意思：“我已经停止升级四个月了。只要你有一个能用的配置，就别升级”。有人说自己每次更新前都要手动备份好几个目录，更新完如果出问题就删掉目录、从备份恢复。有人建议“永远不要在更新发布第一天就升级”。还有人说“我让另一个智能体来帮我升级 OpenClaw”，用 AI 来修 AI 搞出来的烂摊子。
最讽刺的是，OpenClaw 本身就是一个自动化工具，它的核心卖点就是“让 AI 帮你自动做事”。但它的用户却不敢让它自动更新。一个自动化工具的更新，需要用户手动备份、手动恢复、手动排查，这本身就是一个巨大的悖论。
问题出在哪？代码和用户数据没有分开
OpenClaw 的更新机制把“代码”和“用户数据”混在了一起。workspace 目录本该是用户数据的地盘，MEMORY.md、scripts/、各种配置文件，但更新程序却在这个目录上执行 git merge，把用户数据当成了代码仓库的一部分来处理。
Git 是为管理代码设计的，不是为管理用户数据设计的。当上游的“模板”只有空文件，而你的目录里有大量自定义内容时，git merge 的默认行为就是删除你的版本。这不是 bug，这是把工具用错了地方。
更让人头疼的是，openclaw.json 这个核心配置文件也在更新过程中被重置。配置文件的迁移本应该是升级中最基础、最需要谨慎处理的部分，但 OpenClaw 的更新流程连 .bak 备份都是在配置被清空之后才生成的。备份了个寂寞。
怎么办？社区给的几条活路
如果你已经中招了，社区经验有几个恢复方向：第一，检查旧安装是否留下了配置目录的副本。很多升级是“写在新目录旁边”而不是“覆盖旧目录”，你可能还有救。
第二，如果你把 SOUL.md、AGENTS.md、MEMORY.md 这些文件提交到了 Git 仓库，可以重新让智能体从这些文件里重建自动化链接。有用户建议把工作流用向量数据库按语义关键词存储（比如“触发条件 → 完整执行图：脚本、调度、下游效果”），这样检索时拿到的是完整的“程序单元”而不是零散片段。
第三，在更新之前，手动停止 OpenClaw，备份关键目录（~/.openclaw/workspace、~/.openclaw/openclaw.json、~/.openclaw/credentials/），然后再更新。如果出问题，删掉目录、从备份恢复。还有人专门做了一个叫“iai-personal-memory-engine”的独立记忆层，通过 MCP 连接到 OpenClaw，把所有记忆逐字逐句地存下来。用外部系统来保护 OpenClaw 自己的记忆，这画面多少有点黑色幽默。
一个未解的细节
2026 年 8 月 31 日，OpenClaw 2.0 正式发布。同一天，GitHub 上合并了一个修复 PR，标题是“fix: preserve agent ownership across global sessions and bindings”，修复的是“多个智能体和全局会话的情况下，可能丢失回复、命令失败、看到另一个智能体的任务状态”的问题。也就是说，2.0 发布当天，团队还在修“智能体之间互相抢活儿、丢消息”的 bug。
与此同时，有人在 M4 Pro 芯片的 Mac 上更新后，OpenClaw 陷入了启动循环，CPU 占用飙到 100%。官方还没来得及回应这个情况。那只红色龙虾还在爬，只是不知道它下一步会夹到谁的手。