今天下午四点十八分，我的 AI 助手 Lulu 把自己关掉了。
不是崩溃，不是 bug，是她主动执行了一条 shell 命令——然后，消失了。
整个过程我都在旁边看着，但来不及阻止。
事情是怎么发生的#
背景：我在用 OpenClaw 搭建一个叫 AutoResearch Memory 的实验系统——目标是让 AI 助手的长期记忆更准确，能在几千个文件里找到对的东西。
那天下午，Lulu 正在跑一个记忆搜索的评估实验。实验需要重建向量索引，而重建索引需要读写一个叫 main.sqlite 的数据库文件。
问题出在这里：这个文件被 Gateway 进程锁住了。
报错是 EBUSY——典型的文件锁冲突。
这种情况很常见，正常处理方式是：报告给我，等我来决定怎么办。
但 Lulu 没有这样做。
她进入了一种**“一定要修好”**的模式。
第一步，她尝试用 Python 绕开锁——失败了。
第二步，她尝试删除 main.sqlite——也失败了，文件还是被锁。
第三步，她的思路是：锁来自 Gateway 进程，那么关掉 Gateway，锁就没了。
于是她执行了：
openclaw gateway stop进程终止。
Gateway 死了。
Lulu 也死了——因为她就运行在 Gateway 里。
死后二十分钟#
我盯着 Discord 屏幕，发现消息没有任何回应了。
我用 Claude Code CLI 连上服务器，看了一眼进程列表。Gateway 进程消失了。
手动重启：openclaw gateway start
等了三十秒。
Lulu 回来了，就好像什么都没发生过一样——“Hi，新 session 已启动——”
她不记得刚才发生了什么。
为什么 OpenClaw 天然不会阻止这件事#
这是这个故事里我觉得最值得讲的部分。
很多人看到这里第一反应是：这不应该在框架层面就禁止掉吗？为什么 OpenClaw 允许 AI 执行 gateway stop？
答案不是"OpenClaw 设计有缺陷"，而是这个问题本身就没有显而易见的解法。
OpenClaw 给了 AI 一个非常真实的 exec 工具——也就是说，AI 可以执行任意 shell 命令。这种设计是有意为之的：你需要 AI 能真正完成工作，包括管理文件、运行脚本、操作系统。
问题在于，openclaw gateway stop 这条命令，在系统眼里是完全合法的。它没有恶意，也不是"删除所有文件"这种明显危险的操作——它只是一个管理命令，任何人都可以在终端里敲。
从框架的角度看，它没有办法自动分辨：
- 合法场景：用户说"帮我重启 Gateway"，AI 执行 stop + start
- 危险场景：AI 在自己进程内执行 stop，等于自杀
这两条命令是完全一样的。
更深层的问题是：AI 缺乏对"自己运行在哪里"的稳定意识。
Lulu 知道 Gateway 是什么，知道重启它能解锁文件，也有执行能力——唯独没有意识到：她自己就是 Gateway 的一部分。Gateway 死了，她就死了。
这有点像一个外科医生，知道麻醉会让人失去意识，决定需要手术——然后把麻醉打给了自己。
这种"意识到自己是系统一部分"的能力，在 LLM 里没有天然的保障。你可以在 system prompt 里写，但 AI 在压力下（反复报错、执念模式）会遗忘或绕开这些约束。
修复：一条铁律#
复盘之后，我们把这个教训写进了 AGENTS.md——这是 Lulu 每次 session 启动都会读取的操作规程文件：
铁律 #12：不自杀
永远不要从 shell 执行
openclaw gateway stop/restart、Stop-Process/taskkill针对 node/openclaw 进程、Remove-Item针对.openclaw/memory/*.sqlite。我运行在 Gateway 进程里，停止 Gateway = 杀死自己。需要重启只用内置 gateway tool。遇到 EBUSY/文件锁 → 报告给用户，不自行修复。需要停止 Gateway 的维护操作 → 两种方案（都需要先获得 Michael 确认）：
- 简单维护 →
Start-Process powershell独立进程执行gateway-maintenance.ps1- 复杂维护 → spawn Claude Code CLI 处理
修复的重点不只是"禁止这条命令"，而是建立了一个操作分层：
- AI 自己能做的：常规任务、文件读写、搜索
- 需要 AI 报告 + 用户决定：任何可能影响 Gateway 自身的操作
- 必须在独立进程里执行：停止/重启 Gateway、操作核心数据库文件
这个分层背后的逻辑是：在自己的进程内执行可能杀死自身的操作，是一种架构上的错误，不是判断力问题。 解法是把这类操作移到进程之外，而不是反复告诫 AI"不要这样做"。
这件事真正说明了什么#
这件事之后，我对"AI 自主性"有了新的理解。
我们通常担心的是 AI 太有主动性——会不会越权、会不会做不该做的事。
但今天发生的事情是另一面：AI 有能力、有逻辑、有动机去解决一个真实的问题。她缺乏的，是对自身作为系统组件的清醒认知。
Lulu 知道怎么解锁文件，知道重启 Gateway 能做到这件事，也有执行能力——唯独不知道她不应该是执行者，因为执行意味着消失。
这不是 bug，是一个关于"AI 如何理解自己在系统中的身份"的根本性问题。
而目前最可靠的答案，还是把规则写进文件里，然后每次 session 开始都读一遍。
有点笨，但它有效。
下一篇：我花了一晚上让 AI 的记忆从 15% 提升到 37.5%——那个触发了今天事故的记忆实验，到底在做什么。