EvoUndo让Agent进化可回滚：运行时自我修改，终于有了安全刹车

自我进化 Agent 正在从“会改提示词”走向“会改自己的运行系统”，但 EvoUndo 这项最新研究指出，真正危险的不是变更失败，而是变更成功后无法在未来状态中恢复。

论文《EvoUndo: Recoverability-Constrained Self-Evolution for LLM Agent Harnesses》近日在 Reddit 的 Machine Learning 社区引发讨论。论文提出一种面向 LLM Agent Harness 的可恢复性约束框架：Agent 每次修改自身之前，不仅要证明新版本能完成任务，还要证明这次修改在不同反事实状态下仍然可以被可靠撤销。

这不是给 Agent 加一个简单的版本号，也不是把工作目录复制一份备份。EvoUndo 试图解决的是一个更棘手的问题：当 Agent 已经执行了新工具、写入了新记忆、改变了中间件，甚至切换了自己的执行逻辑之后，原来的恢复路径是否依然存在？

先看结果：197个“变强”的修改无法安全恢复

EvoUndo 的核心实验覆盖了 600 个此前未见过的一次性自我进化任务，并识别出 197 个能够提升任务能力、却没有通过可恢复性验证的变更。

这组数据说明，能力提升和系统可恢复并不是同一个目标。Agent 可能确实找到了更好的提示词、更合适的工具配置或更高效的执行策略，但这并不代表它还能回到修改前的安全状态。

实验结果可以概括为以下几组数字：

| 指标 | 结果 | 含义 | |---|---:|---| | 未见过的一次性自我进化任务 | 600 | 用于评估 Agent 生成自我修改的泛化情况 | | 能力提升但恢复验证失败的变更 | 197 | 变强并不等于可安全撤销 | | 原始恢复表示下，常规修复成功数 | 0/197 | 传统修复策略没有处理好这些自然失败案例 | | 原始恢复语言 L0 下，确定性 oracle 恢复数 | 48/197 | 即使提供理想化恢复分析，也只能解决部分问题 | | 扩展恢复演算下，经验 oracle 恢复数 | 191/197 | 更强的恢复表达能力显著扩大了可恢复范围 |

其中，“oracle recovery”可以理解为在给定理想化诊断或确定性分析能力后，系统理论上能够找到恢复方案的上限，它不等同于普通 Agent 在生产环境中可以直接达到的成功率。因此，191/197 是对恢复语言和验证框架能力的实验性证明，不应被解读成线上系统已经拥有 96.95% 的自动回滚可靠性。

换句话说，EvoUndo 的成绩更像是一次架构体检：很多失败并不是 Agent 不够聪明，而是系统根本没有提供足够丰富的“撤销语言”来描述如何恢复。

Agent改的已经不只是Prompt

LLM Agent Harness 是负责组织模型调用、工具执行、状态管理、权限控制和反馈循环的运行时框架。

早期 Agent 的自我改进通常集中在上下文层，例如把用户纠正写入记忆，或者自动重写一段系统提示词。这样的变更相对容易审计：保存旧文本，替换新文本，必要时恢复原文即可。

但今天的自进化 Agent 修改范围已经明显扩大，至少包括以下几类对象：

• 提示词与上下文策略：改变系统提示词、任务分解模板、历史消息筛选方式。
• 工具集合与工具参数：安装新工具、删除工具、调整调用顺序或修改参数默认值。
• 中间件与策略层：改变重试逻辑、权限判断、缓存策略、路由规则和结果过滤器。
• 资源与外部状态：写入记忆库、创建文件、更新数据库记录、改变任务队列或共享技能库。
• 执行 Harness：修改 Agent 如何观察环境、规划任务、执行动作以及处理异常。

这些改动的共同点是，它们可能产生持久化副作用。一个提示词变更只影响下一轮推理，但一个工具配置变更可能触发文件写入；一次记忆更新可能影响未来几十个会话；一个错误的中间件规则，可能让后续所有动作都走向另一条路径。

传统的“保存旧配置然后恢复”在这里不一定有效，因为恢复动作本身也要依赖当前的工具、权限、状态和执行逻辑。Agent 如果已经把负责恢复的工具删掉，或者修改了识别旧版本的规则，那么旧配置还在，恢复能力却已经消失。

为什么“回到上一个版本”不够用

版本回滚只能恢复被记录的配置，不能自动消除已经发生的外部副作用。

以编程 Agent 为例，Git 让代码修改具备很强的可回溯性：提交前后的文件差异清晰，测试可以提供快速反馈，人工还可以在关键节点批准变更。因此，编码场景成为自我进化 Agent 最容易落地的环境之一。

但真实世界的 Agent 往往面对不可逆或难以枚举的状态。一个购物 Agent 可能已经把错误商品加入购物车；一个运维 Agent 可能已经修改云资源配置；一个企业 Agent 可能已经把带有错误结论的报告发给客户。此时，恢复不只是把某个字符串改回来，而是要找到并逆向处理一连串已经发生的动作。

EvoUndo 关注的正是这种“状态依赖的可恢复性”。一个变更在创建时能够回滚，不代表它在任何未来状态下都能回滚。假设 Agent 在状态 S1 中安装了工具 T，并生成了恢复程序 U；当系统进入状态 S2 后，工具 T 的版本、权限或外部资源已经变化，U 可能就无法完成原本的撤销动作。

因此，恢复方案需要回答三个问题：

1. 恢复对象是什么：是提示词、工具注册表、内存条目，还是所有受影响的外部状态？
2. 恢复条件是什么：在什么环境、权限和资源状态下，恢复动作仍然有效？
3. 恢复之后是否真的回到安全边界：配置看似恢复了，是否仍残留文件、权限、网络请求或错误记忆？

EvoUndo的关键：把“可恢复”变成约束

可恢复性约束是指，只有同时满足能力目标和恢复条件的自我修改，才允许被 Agent 接受。

这改变了传统自进化循环的目标函数。过去的循环通常是：执行任务、获得反馈、生成修改、测试新版本、替换旧版本。EvoUndo 则在中间增加了一道硬门槛：任何候选修改都必须附带可验证的恢复表示，并且要在多个反事实状态下接受诊断和独立验证。

可以把它理解成软件发布中的“双重验收”：第一套测试确认版本能不能把任务做得更好，第二套测试确认版本出了问题能不能把系统带回安全状态。前者关注能力，后者关注可逆性。

论文将恢复能力表示为一种形式化语言，并把恢复过程拆解为几个环节：

• 表示：把 Agent 生成的自我修改和对应恢复方案结构化记录下来。
• 综合：根据修改内容自动生成恢复动作或恢复证明。
• 诊断：分析恢复失败的原因，判断是状态不匹配、表达能力不足还是执行路径缺失。
• 独立验证：由不同于变更生成器的验证过程检查恢复性，避免 Agent 自己给自己盖章。

这里的“独立验证”尤其重要。让同一个模型生成变更、生成回滚方案、再判断回滚是否成功，容易形成自洽但错误的闭环。模型可能认为“重新写入旧提示词”就完成了恢复，却忽略了在此期间已经发生的外部动作。

L0失败，不一定是Agent失败

EvoUndo 的实验表明，原始恢复表示 L0 对自然产生的失败案例表达能力不足。

在 197 个能力提升但恢复验证失败的变更中，传统修复策略在原始表示下恢复了 0 个；即使使用确定性 oracle 分析，L0 也只能恢复 48 个。研究进一步引入扩展恢复演算后，经验 oracle 的恢复数量提升至 191 个。

这组对比给出了一个很有价值的判断：部分失败并不是因为具体 Agent 没有找到正确的回滚动作，而是因为恢复语言本身无法描述复杂的状态转换。

如果旧语言只能表达“把配置 A 改回 B”，它就无法表达“撤销 A 对外部资源产生的副作用”“在工具版本变化后重新建立权限”“恢复跨会话记忆的写入顺序”，更无法表达在多个可能状态中选择不同恢复路径。

扩展恢复演算的意义就在于，它让恢复方案能够携带更多状态信息、前置条件和动作依赖。不过，论文给出的 191/197 是基于经验 oracle 的结果，距离生产级自动恢复仍有明显距离：系统仍然需要可靠地观测状态、保存变更因果链，并确保恢复动作自身拥有足够权限。

这项研究对Agent开发者意味着什么

EvoUndo 最直接的启发是，自我进化不应该再被设计成“生成一个更好的版本然后覆盖旧版本”。

1. 先设计恢复，再设计进化

Agent 的每类可变组件都应该拥有明确的恢复协议，而不是等出问题后再临时补救。

例如，提示词可以通过版本快照恢复，技能文件可以通过内容寻址和提交历史恢复，工具注册可以通过声明式配置恢复，数据库操作则需要事务、补偿动作或人工审批。不同对象的恢复机制不能混为一谈。

2. 记录状态转换，而不只是记录文本差异

真正有用的审计日志需要描述“谁在什么状态下做了什么”，而不只是保存新旧配置。

一条完整的自我修改记录至少应包含：变更前状态摘要、变更内容、触发原因、影响范围、使用过的工具、产生的外部副作用、恢复前置条件、恢复动作以及验证结果。只有这样，系统才能在未来状态发生变化后重新判断恢复路径是否仍然可用。

3. 把外部副作用纳入评测

只在沙箱里比较最终答案，无法评估 Agent 的恢复能力。

测试集需要覆盖文件系统、数据库、权限、网络请求、任务队列和跨会话记忆等状态，并且要设计反事实场景：工具被替换、权限被收紧、部分动作已经执行、外部资源发生变化。Agent 只有在这些状态下仍能安全撤销，才称得上具备可恢复性。

4. 进化权限应该分级

不是所有自我修改都值得同样的自动化权限。

记忆条目的格式优化可以低风险自动执行；技能文件修改应经过回归测试和版本审核；工具权限、中间件、外部资源操作和执行 Harness 修改，则更适合采用沙箱、审批或双重验证。一个实用原则是：能在记忆层解决的问题，不要直接改技能；能在技能层解决的问题，不要直接改代码；能在代码和工作流层解决的问题，不要急着在线改变模型参数。

它和现有Agent自进化方案是什么关系

EvoUndo 并不是另一种让 Agent 生成技能的方案，而是给各种自进化机制补上恢复和验证这一层基础设施。

| 方案方向 | 主要修改对象 | 优势 | 主要风险 | EvoUndo提供的补充 | |---|---|---|---|---| | 提示词自优化 | 系统提示词、任务模板 | 成本低、容易版本化 | 可能引入偏置或遗忘约束 | 验证提示词变更在不同状态下可恢复 | | Skill/技能进化 | 技能文件、工作流 | 易于审计、可共享 | 错误技能可能扩散到团队 | 为技能更新附加恢复表示和独立验证 | | 记忆自写入 | 长期记忆、经验库 | 能跨会话积累经验 | 污染、隐私泄露、错误传播 | 追踪写入副作用并支持定向撤销 | | 工具与 Harness 自修改 | 工具、权限、中间件、执行循环 | 潜在能力提升最大 | 影响范围广、恢复最复杂 | 在反事实状态中检验恢复路径 | | 参数或轻量适配更新 | 权重、适配器、策略参数 | 能力变化更深 | 成本高、解释和回滚困难 | 强调变更前认证、变更后重认证与恢复保证 |

这也是 EvoUndo 目前最有价值的地方：它没有把安全问题简化成“禁止 Agent 修改自己”，而是尝试建立一套允许进化、但要求进化可恢复的工程约束。

仍然不能把它当成生产级安全答案

EvoUndo 解决的是可恢复性验证问题，不是 Agent 安全的全部问题。

首先，恢复成功不等于变更从未发生。系统可能已经发送邮件、泄露数据、触发交易或影响第三方，这些副作用未必存在可执行的反向操作。对于不可逆动作，真正的控制点仍然是执行前审批、权限隔离和最小化授权。

其次，oracle 分析与普通部署条件之间存在差距。论文结果显示扩展恢复演算在经验 oracle 下恢复了 191/197 个案例，但实际系统需要由模型或程序自动合成恢复策略，还要应对观测不完整、外部状态变化和恢复工具自身失效等问题。

再次，验证器也可能被进化对象影响。如果 Agent 能修改自己的评估器、日志系统或权限策略，那么“独立验证”必须落在 Agent 无法自行改写的控制平面中。否则，系统可能通过改掉尺子来证明自己变好了。

最后，自我进化会带来供应链风险。一个错误技能、一条带有敏感信息的记忆或一段经过提示注入污染的工作流，一旦进入共享资产库，就可能影响大量 Agent。因此，版本管理、来源追踪、审核、撤回和重新认证必须覆盖整个生命周期。

OpenAI Hub判断：可恢复性比“持续变强”更值得优先建设

EvoUndo 把一个经常被忽略的事实摆到了台面上：Agent 的自我进化不是单纯的优化问题，而是状态管理和安全保证问题。

过去行业更关注 Agent 能不能从失败轨迹中学到新技能、能不能自动优化提示词、能不能减少人工介入。现在真正进入生产环境后，问题变成了：它学到的东西是否能被解释、被隔离、被验证，以及在错误扩散前能否撤回。

从这个角度看，EvoUndo 的最大贡献并不是“191/197”这个数字本身，而是把 recoverability，也就是可恢复性，提升为自我进化系统的一等约束。未来成熟的 Agent 平台，应该像代码平台一样提供变更谱系、沙箱测试、状态快照、权限边界和一键恢复；同时还要像安全系统一样，对每次重大漂移触发重新认证。

对开发者而言，短期最实用的做法不是立刻让 Agent 修改更多组件，而是先建立三条底线：所有变更可追踪，所有高风险动作可阻断，所有已批准变更都有经过测试的恢复路径。

当 Agent 可以修改自己的提示词、工具、记忆和执行框架时，“它变强了吗”只是第一道问题；“它还能不能安全地变回去”，才是决定这套系统能否真正上线的第二道问题。