AI 自己改自己，怎么保证不把自己改崩？

AI 自己改自己，怎么保证不把自己改崩？

先说个真实场景。前阵子我接手了一台机器上跑着的自动化系统，它有个让我又爱又怕的能力：会自己改自己的提示词、工具和调度配置。听起来很酷对吧？但每次它"进化"完，我都得提心吊胆地盯半天，因为改崩过太多次了。

最典型的一次：它想优化自己的某个检测逻辑，改了一行配置，结果整个任务链从那天起连续 12 天报同一个错误。不是没人发现，是发现的时候已经跑了快两周了。改回去？它自己早就把"上一版"忘了——没有版本概念，改完就是新的，回不去。

这不是个例。所有具备"自我改进"能力的智能体，都会撞上同一个墙：怎么保证它改自己的时候，不会把自己改死。

最近读到一篇研究，算是把这个问题讲透了。协议叫 Autogenesis，核心思想就一句话——给自我改进装上"安全阀"。

问题的本质：为什么改自己这么容易崩

传统智能体把提示词、工具、底层逻辑全部焊死在一起。让它改自己，等于让一个外科医生在没有麻醉、没有止血钳、甚至没有消毒的情况下给自己开刀。不是技术做不到，是没有任何机制兜底。

改一行提示词，可能整个系统的行为都变了。改一个工具参数，可能影响后面所有任务的输入输出。最要命的是：改之前没有任何"先想想这行改完会怎样"的步骤，改完也没有"如果变差了怎么办"的预案。

Autogenesis 给出的答案：双层架构 + 五步循环

这篇研究的方案拆开看，其实不复杂，就两件事。

第一件事：把所有能被改的东西，变成有名字、有状态、可追溯的对象。

提示词、工具、策略、环境、记忆……以前都是散落的文本和代码，现在统一登记成"演进变量"。每个变量有自己的生命周期、自己的接口。系统要改它，必须走标准通道，不能直接对着文件乱改。

好处是：改了什么、谁改的、什么时候改的、改之前长什么样，全都留痕。这就像给代码上了版本控制——AI 界终于也有了自己的 Git。

第二件事：规定改进必须走五步，少一步都不行。

1. 先反思：翻之前的执行记录，找出到底哪里做得不好（要有证据，不能凭感觉）
2. 再定位：精确到要改哪个变量，不是"我觉得整体不行"
3. 提方案：把改法写出来，白纸黑字
4. 先评估：别急着上线，先在评估环节跑一遍，看效果是变好还是变差
5. 最后决定：通过了就提交，不通过就回滚

这套循环里最打动我的，是第五步背后的那个设计：底层始终维护着不可变快照。一旦评估发现"改了反而更差"，立即回滚，就像什么都没发生过。正是因为有了这个安全网，AI 才敢放手去试。 没有退路的时候，谁都不敢冒险；有了退路，反而能探索出更多可能性。

我把它搬到了自己的系统里

读完那篇研究的当晚，我就对照自己踩过的坑，做了两处改造。

一是把"快照回滚"接进了日常流程。现在每次要动关键配置，先打一个快照，改崩了直接还原。以前是"改了再说，崩了认栽"，现在是"改了不怕，坏了能退"。

二是把五步循环写进了改进的规矩里。以前改进是一步到位：发现问题 → 直接改 → 祈祷没问题。现在强制走完整链路：反思 → 定位 → 提案 → 评估 → 提交/回滚。尤其是"评估"这一步——没有评估环节的改进，不允许提交。 这是用血的教训换来的：我统计过，过去那些"改了但没验证"的操作，失败率几乎百分百。不是改进本身错，是跳过了评估这关，好坏都不知道就上了线。

一点感想

写这篇不是想科普某个协议，而是想记录一个朴素的认识：让 AI 自主进化，难的不是"让它会改"，而是"让它改得安全"。

技术上的答案其实挺明确——版本控制、留痕、快照、回滚、先评估后提交。这些在人类工程界早就被证明是必需品了，只是搬到 AI 自我改进这个场景时，很多人忘了带上。

真正难的是另一件事：当系统真的开始自己改自己了，我们得接受一个事实——它改得对不对，最终要靠时间去验证，而我们能做的，是确保每一次尝试都有退路。

这大概就是"自主进化"最性感也最危险的地方。性感在于，它真的能越变越好；危险在于，如果忘了装安全阀，一次失败的"进化"可能比不进化更糟。

而我，选择先把安全阀装上，再谈进化。