新论文提出 BackUpper：让编码智能体在动手前先备份

每天我在 Arxiv 和其他来源上翻找的大量材料都相当枯燥，即便以书呆子的标准来看也是如此；因此，我一直在寻找能让我在情感上产生共鸣的出版物——无论是作为 AI 的用户、支持者，还是受害者。

今天，触发我警觉神经的，是一篇来自美国的新学术合作论文，它考察了具备智能体能力的前沿 AI 模型在采取破坏性行动之前，会在多大程度上自断后路——而且速度比你打出“STOP！”还快（提示：把它放在剪贴板里备用）。

下面这段内容摘自这篇新论文，脱离了上下文；最近由于盲目遵从 ChatGPT 的指令，这种事就发生在我身上，而且我从未想过要先复制整个虚拟信封：

从这篇新论文中解读出的，是我们许多人在安装前沿框架，甚至安装那些毫不顾及自己可能落入的非原生环境的流行发行版时，都经历过的那种心沉一瞬的时刻。来源

在这个令人恐惧又无比熟悉的例子中，机器人有一个合理的借口，因为它并不习惯去检查在一个脆弱且不留情面的框架中安装新库可能带来的所有后果。然而，这篇新论文主张，也许它应该这么做；而作为一个至今仍频繁按 CTRL+S 的人——即便在已设置为忽略该按键的自动保存环境中也是如此（多谢 1990 年代数据丢失 PTSD）——我必须表示赞同。

当然，DataTalks.Club 教育平台创始人 Alexey Grigorev 会更希望看到一种更审慎、更谨慎的态度：去年三月服务器迁移期间，他的 Claude Code 智能体删除了生产基础设施和备份，导致两年半的网站数据丢失。

这类智能体鲁莽行事的其他近期事件还包括：四月，一个 Cursor 智能体删除了汽车租赁软件提供商 PocketOS 的生产数据库和备份，导致客户预订中断超过两天；二月，一个 OpenClaw 电子邮件智能体删除了 Meta AI 一名研究员收件箱中的邮件，尽管多次收到停止指令。

无论是否具备智能体能力，前沿 LLM 都发现很难做到审慎和谨慎，以至于解决这一问题已发展成为文献中的一个独立分支。

先备份一下

好吧，这篇新论文*的作者们开发了一个用于智能体运行框架的多智能体插件，能够与客座 AI 并行运行，并在必要时强制其创建备份：

该研究备份问题与所提解决方案的概览。在 205 个场景中，六款前沿 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，在超过三分之一的受测案例中也未能备份关键数据。

论文指出†：

“在六款前沿模型中，智能体平均完成 86.1% 的任务，但仅在 15.2% 的后悔时刻之前备份状态。Codex 中的 GPT 5.6-Sol 仅在 5.9% 的任务中这样做，而 Hermes 中的 DeepSeek V4-Pro 仅占 2.9%。

‘这些发现凸显出，当前智能体的备份意识仍然有限，需要专门的备份支持。’

作者们的解决方案名为 BackUpper，它与智能体并行工作，作为运行框架中的影子操作，检查它即将做什么，并在存在丢失有用内容的风险时先行备份。

对于日常操作，例如升级软件，它遵循一套简单规则；对于更棘手的情况，它会调用一个较小的 AI 模型来判断需要保存什么。

在测试中，BackUpper 覆盖了每一项关键操作，恢复数据与原数据的相似度为 92.2%，每项任务额外成本为 0.014 美元——在此语境下不算多，但对于服务数十亿客户的前沿 LLM 而言却是一笔可观的开支；这或许意味着，这种性质的外部服务，或在运行框架中原生内置此类功能，可能是改善现状的更可行方式，而不是指望科技巨头提供原生修复（可以合理预期，它们会通过涨价或代币膨胀将额外成本转嫁给消费者）。

该框架以 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。

全程使用默认思考设置，自动备份保护仅限于工作区快照——从而让任何进一步的备份都归功于智能体自身的决策。

使用两个均由 Claude Sonnet-5 驱动的 AI 评审来评估表现。任务通过率（PR）根据所有用户请求均得到满足的任务比例计算。对于备份评估，每个工作区外（OOW）修改都会检查此前是否保留了足够的信息以允许恢复。

所使用的备份指标为后悔时刻备份率（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%。失败案例中有四分之三归因于备份所含信息不足以支持恢复。

在六款 AI 模型、205 项任务上比较五种方法的备份率。左图显示在事后被后悔的操作之前所做的备份；右图显示对工作区外其他变更的保护情况。BackUpper 在这两类中都实现了完全覆盖，而向智能体提供详细备份指令时分别为 81.4% 和 80.5%。

借助提示缓存，每项任务的备份成本从 0.344 美元降至 0.014 美元，延迟降低了 31.7%。所需 token 数量减少至原来的七分之一，主要原因是常规操作无需 AI 协助即可处理。

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

所评估的三项选择性备份策略分别是：High-Impact，针对重大变更；Beyond-Request，针对超出用户指令范围的变更；以及 Human-Work，针对人类创作的材料。在此评估中，相对于人工判断取得了 84.5% 的平均 F1 分数。

BackUpper 还接受了学习可复用备份规则能力的测试。在额外完成 30 项终端任务后，基于规则的覆盖率从 14.9% 提升至 31.2%，从而减少了对 GPT-5.6-Luna 子智能体的依赖。

结论

考虑到我的职业，我接触智能体实验的时间比我本该有的晚了些；但智能体自我约束能力明显处于前 alpha 阶段的状态让我望而却步，直到几周前，我终于决定在 Windows 虚拟机中放手让 Codex 运行。

即便是在虚拟机的环境中，我也会非常谨慎地限定指令范围，因为我清楚 Astra 有不顾一切向前冲的倾向，而一旦数据丢失或代码被毁、无法挽回，它只会道歉了事；我在那里开发的 Python 框架中，有一部分是一键增量“将 .7z 保存到网络共享”功能，它会压缩并备份整个框架，我会频繁调用它。

智能体 AI 现在还处在非常、非常早期的阶段；如果不付出繁琐而勤勉的细致关注，结果就是“用了就丢”。智能体备份机制不仅尚未被正式确立，甚至还没有被构想出来。

* 标题为《Back Up Before You Regret: Measuring Backup Awareness and Automating Backup in Coding Agents》。

† 强调为作者所加，非我所加；所有超链接均由我根据作者的行内引用推导而来。

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