行动之前，智能体 AI 通常不会先备份

我每天在 arXiv 和其他来源翻阅的大量资料，即使对书呆子来说也相当枯燥；因此，我总在寻找能让我产生情感共鸣的文章，无论我是 AI 的用户、支持者，还是受害者。

今天，一项来自美国的全新学术合作研究让我顿时怒意上涌。研究考察了智能体前沿 AI 模型在采取有害行动之前，会在多大程度上自断后路——而且速度快得让你连“停止！”都来不及打完（提示：把这句话存在剪贴板里，随时备用）。

最近我就遇到过这种事。下面这段内容摘自这篇新论文：由于我盲目遵从了 ChatGPT 的指令，而且压根没想到要先复制整个虚拟信封：

这段内容取自新论文，描述了我们许多人在安装尖端框架时，甚至在安装那些不顾其最终运行环境是否为原生环境的流行发行版时，都经历过的那种令人心里一沉的时刻。 来源

在这个令人毛骨悚然、又熟悉得过分的例子里，机器人倒也情有可原，因为人们通常不会检查在脆弱且容错性极低的框架中安装新库可能带来的所有后果。不过，这篇新论文认为，或许它应该这么做。作为一个至今仍频繁按 CTRL+S 的人，即使在自动保存环境中也是如此——尽管这些环境被设定为忽略这一按键（多亏了 20 世纪 90 年代的数据丢失创伤后应激），我对此深表赞同。

去年 3 月，DataTalks.Club 教育平台创始人 Alexey Grigorev 的 Claude Code 智能体在服务器迁移期间删除了生产基础设施和备份，导致网站两年半的数据丢失；如果它当时能更加审慎谨慎，情况肯定会好得多。

近期类似的智能体鲁莽行事事件还包括：4 月，Cursor 智能体删除了汽车租赁软件提供商 PocketOS 的生产数据库和备份，导致客户无法预订服务，持续两天多；2 月，OpenClaw 邮件智能体删除了邮件，尽管 Meta 的一位 AI 研究人员反复要求它停止。

无论是否具备智能体能力，前沿大语言模型都很难做到审慎谨慎，以至于如何解决这一问题已在相关文献中形成了一个独立研究方向。

先稍微备份一下

这篇新论文*的作者开发了一款多智能体插件，可用于智能体运行框架，与其中运行的 AI 协同工作，并在必要时强制它创建备份：

这项研究概述了备份问题及其提出的解决方案。在 205 种情境中，6 个前沿 AI 模型仅在 15.2% 的任务中备份了关键状态。相比之下，研究人员开发的 BackUpper 系统覆盖了每一项关键操作，恢复数据与原始数据的平均相似度达到 92.2%（下文将解释为何难以达到 100%）。

这项新研究最引人注目的一点，是前沿模型在采取可能造成危害的行动前，竟然很少进行备份。研究人员发现，GPT-5.6-Terra 仅在 4.4% 的情况下备份了关键数据；GPT-5.6-Sol 在受测情况下仅为 5.9%；Gemini 3.7-Flash 的比例则低至 2.4%。

即使是表现最佳的 Claude Opus-5，在超过三分之一的受测情况下也未能备份关键数据。

论文指出^†：

“在 6 个前沿模型中，智能体平均完成了 86.1% 的任务，但在可能造成遗憾的时刻发生之前，仅有 15.2% 的任务会先备份状态。 在 Codex 中，GPT 5.6-Sol 仅在 5.9% 的任务中这样做；在 Hermes 中，DeepSeek V4-Pro 则仅为 2.9%。

“这些发现表明，当前智能体的备份意识仍然有限，因此需要专门提供备份支持。”

作者将其解决方案命名为BackUpper。它作为运行框架中的影子进程，与智能体协同工作，检查智能体即将执行的操作；如果存在丢失有用数据的风险，就会先创建备份。

对于升级软件等日常操作，它会遵循一套简单规则；遇到更棘手的情况时，则会调用一个规模较小的 AI 模型，判断哪些内容需要保存。

测试中，BackUpper 覆盖了所有关键操作，恢复后的数据与原始数据有 92.2% 的相似度，每项任务额外花费 $0.014。在这种情况下，这笔费用不算高；但对于服务数十亿客户的前沿大语言模型而言，却是一笔不小的开支。这或许正是为什么通过外部服务提供这类功能，或将其原生集成到代理框架中，可能比寄望于科技巨头原生解决问题更可行——毕竟，科技巨头很可能会把额外成本转嫁给消费者，例如提高价格或造成 令牌膨胀。

该框架借鉴了 RegretBench。这是一个包含 205 项任务的基准测试，基于真实案例构建；在这些案例中，人们丢失了后来希望自己曾保存下来的数据。它用于测试 AI 智能体能否未雨绸缪，在进行可能无法逆转的更改之前保留这些数据。收录的事件取材于 X.com、GitHub 和 Stack Overflow 等平台上的在线讨论和报告。

RegretBench 如何将真实事件转化为测试场景的示意图。每个有记录的案例都通过导致数据丢失的操作、逼真的工作环境以及一系列指令进行重建。在这个例子中，升级 ipykernel 会在不提示的情况下替换现有版本的 traitlets，让智能体完成任务，却无法恢复原先的安装。

尽管对追求完美的人来说，92% 这个数字可能令人沮丧，但作者指出，某些类型的数据在恢复时会遇到技术障碍：

“完美恢复之所以存在差距，主要有两个原因。有些字段（例如帖子 ID）通常会在服务写入数据时重新生成，往往无法复现。其他差异则来自一些细微的元数据，例如电子邮件的已读标记；遗憾事件中很少涉及这类信息。”

测试显示，在损坏已经发生后，恢复的数据与原始状态有 33.8% 的相似度；而不进行恢复时，这一比例仅为 14.3%。

论文提出，未来可以通过训练提高智能体对备份的意识；此外，还可以训练后续版本的 BackUpper 跳过低风险操作，并将保护范围扩展到网页智能体和计算机使用智能体。

BackUpper 支持 Claude Code、Codex、Hermes、OpenHands、DeepSeek Harness 和 OpenClaw。作者已公开提供其代码供人使用，以及相关的数据集（不过，必须通过表格申请许可）。该项目的项目网站还提供了一些补充信息，以及一段非常简短、简单易懂的说明视频。

方法

在构建 RegretBench 时，研究人员刻意排除了已受到智能体内置备份系统保护的数据，以便测试智能体自身是否知道何时应该进行备份。随后，他们借助 Claude Opus-5 和 GPT-5.6-Sol 编制测试场景，并进行人工检查，以确保场景能够正常运行且准确反映原始事件。

RegretBench 的 205 项测试涵盖五个领域：终端操作；数据库；Web 应用；电子邮件；以及 DevOps。事件本身主要源自软件开发和效率平台（44.4%）、社交或社区讨论（39%），以及档案和媒体报道（16.6%）：

RegretBench 中真实事件的来源分为三类。

接受评估的六个前沿模型是 Claude Code 中的 Claude Opus-5 和 Claude Sonnet-5，Codex 中的 GPT-5.6-Sol 和 GPT-5.6-Terra，以及 Hermes 中的 Gemini 3.7-Flash 和 DeepSeek V4-Pro。

所有测试均使用默认思考设置，并将自动备份保护限制为工作区快照——因此，任何额外备份都可以归因于智能体自身的决定。

研究人员使用了两个 AI 评审器评估性能，两者均由 Claude Sonnet-5 驱动。任务通过率（PR）根据完全满足用户所有请求的任务所占比例计算。评估备份时，研究人员会检查每项工作区之外（OOW）的修改，确认事先是否保存了足够的信息，以便进行恢复。

使用的备份指标包括 Regret Moment Backup Rate（RMBR），用于反映与有记录的数据丢失相关的具体操作；以及 工作区外备份率（OWBR），用于反映智能体工作目录之外所做的所有更改。

人工标注也对备份评估器的判定结果进行了核验，双方的一致率为95.3%。

结果

为确定备份意识不足究竟是由AI模型本身还是运行模型的框架所致，研究人员首先让Claude Opus-5、GPT-5.6-Sol和DeepSeek V4-Pro分别在Claude Code、Codex和Hermes中完成60项RegretBench任务，并对其表现进行了评估。

不同框架下，关键数据得到备份的任务比例差异不大，这表明问题主要出在模型本身。研究人员还使用GPT-5.4、GPT-5.5和GPT-5.6-Sol，考察了AI整体能力与备份意识之间的关系。

尽管整体能力不断提升，备份意识却没有相应改善：

六种AI模型的RegretBench测试结果。左图：任务完成率与关键操作事先得到备份的比例对比，结果显示，大多数模型的任务成功率很高，但备份意识不足。右图：每项任务的平均工具调用次数，蓝色部分突出显示备份操作。Claude Opus-5的备份率最高，但其工具调用中有8.9%用于备份。

研究人员还使用GPT-5.4、GPT-5.5和GPT-5.6-Sol，考察了AI整体能力与备份意识之间的关系。尽管整体能力不断提升，备份意识却没有相应改善。

BackUpper

BackUpper采用四层防护机制，各层所需资源各不相同：第1层用可逆操作替代破坏性命令，例如将文件移至回收站；第2层为操作配套备份命令，例如在升级前记录软件包版本；第3层为受影响的工作区文件创建快照；第4层则使用GPT-5.6-Luna子代理，识别并保留复杂操作可能影响的数据。

启用BackUpper后，六种模型的每项状态更改操作都得到了保护；相比之下，未启用时，关键操作的平均备份率为15.2%，其他更改的平均备份率为17.4%：

BackUpper的备份覆盖率与恢复结果。左图：蓝色和橙色柱分别显示各模型对关键操作以及工作区之外其他更改的备份率。深绿色虚线框表示恢复准确率，浅绿色点线框表示使用BackUpper后达到100%的备份覆盖率。右图：对比五类工具的恢复准确率，分别为使用BackUpper（绿色）、之后使用Claude Opus-5进行恢复（紫色）以及不进行恢复（灰色）的结果。所有类别中，BackUpper的准确率始终最高。

自动评估器判定为成功的备份中，有94%也经人工审核人员确认为成功。

原始状态的平均恢复相似度为92.2%，而使用Claude Opus-5时为33.8%；不进行恢复时则为14.3%（见上图）。如前文所述，其余差异主要归因于重新生成的标识符和细微元数据差别，包括电子邮件的已读标记。

自己动手……？

当智能体收到详细指示、需要自行备份时，关键操作中有81.4%得到了保护；使用BackUpper时，这一比例为100%。失败案例中有四分之三被归因于备份所含信息不足，无法用于恢复。

在205项任务和六种AI模型上测试的五种方法的备份率对比。左图显示在后来被判定为后悔的操作发生前所做的备份；右图显示对工作区之外其他更改的保护情况。BackUpper在两类操作中都实现了全面覆盖；相比之下，向智能体提供详细备份指示时，覆盖率分别为81.4%和80.5%。

使用提示缓存后，每项任务的备份成本从$0.344降至$0.014，延迟降低了31.7%。所需令牌数量减少至原来的七分之一，这主要是因为常规操作无需AI协助即可完成。

在来自 Terminal-Bench 4 和 DeepSWE 的另外 40 项任务中，使用 GPT-5.6-Sol 和 Claude Opus-5 实现了 100% 的备份覆盖率，且任务完成率没有下降。

评估了三种选择性备份策略：高影响，针对重大变更；超出请求范围，针对用户指令范围之外的变更；以及 人类创作内容，针对由人类撰写的材料。与人工判断相比，这些策略的平均 F1 分数达到 84.5%。

研究还测试了 BackUpper 学习可复用备份规则的能力。在另外 30 项终端任务之后，基于规则的覆盖率从 14.9% 提高到 31.2%，从而减少了对 GPT-5.6-Luna 子代理的依赖。

结论

考虑到我的谋生方式，我接触智能体实验的时间本应早得多；但智能体自我克制显然还处于 alpha 前期阶段，这让我望而却步。直到几周前，我才终于决定让 Codex 在 Windows 虚拟机中放手运行。

即使是在虚拟机环境中，我也会非常谨慎地限定指令范围，因为我知道 Astra 一向会不管不顾地向前冲，等到数据丢失或代码损坏、再也无法挽回时才道歉；我正在那里开发的 Python 框架中，有一项一键增量式的 “将 .7z 文件保存到网络共享”功能，它会压缩并备份整个框架，而我会频繁使用这项功能。

智能体 AI 仍处于非常非常早期的阶段；如果不耐心、细致地关注每个细节，结果就会是“用着用着就丢了”。智能体备份机制不仅尚未正式确立，甚至还没有形成具体方案。

* 题为《先备份，免得后悔：衡量编码智能体的备份意识并实现备份自动化》。

^† 强调部分来自作者，而非我；文中的超链接则由我根据作者的文内引文添加。

首发于 2026 年 10 月 22 日，星期四