TL;DR
Кодовые агенты (Claude Code, Codex и им подобные) почти не делают бэкап перед действием, которое меняет состояние: обновляют пакеты, правят базу, удаляют файлы, меняют настройки. Задачи они при этом проходят в большинстве случаев, а бэкап перед «моментом сожаления» делают лишь в малой доле запусков. Статья называет это backup awareness (понимание, что состояние может понадобиться потом, и привычка сохранить его заранее). BackUpper, предложенный авторами, — это «страховочный слой». Он перехватывает каждый вызов инструмента до выполнения и сохраняет затронутое состояние. Простые команды обрабатывают жёсткие правила, а сложные и непонятные — отдельный маленький субагент.
Боль в том, что агент делает ровно то, что просили, и всё «работает». Через неделю выясняется, что нужна старая версия пакета, удалённая запись или прежний конфиг, а копии нет. Причина в том, что модель не думает «а вдруг это понадобится». Она оптимизирует выполнение запроса. Хуже всего с изменениями вне рабочей папки: встроенные защиты агентов (снимки папки проекта, сохранение файлов перед правкой) их не покрывают. Больше всего удивляет разброс. У одних моделей бэкап есть в большинстве запусков, у других — почти никогда. Не помогают ни «умная» обвязка агента, ни новые поколения модели, ни рост размера.
Метод работает в четыре уровня. Для безопасных команд — заменить rm на mv в .trash. Перед pip install — выполнить pip freeze. Для изменений в папке проекта — сделать снимок. Для остального — спросить лёгкую модель «это только чтение?» и, если нет, вызвать субагента-«бэкапера». Всё это происходит вне контекста основного агента.
Схема метода (BackUpper)
ПЕРЕХВАТ: каждый вызов инструмента — до выполнения
ПРОВЕРКА 0: команда только читает? (белый список) → пропустить, бэкап не нужен
УРОВЕНЬ 1: есть правило-замена? → выполнить обратимый аналог
(rm x → mv x .trash/)
УРОВЕНЬ 2: есть правило-пара? → сначала команда бэкапа, потом оригинал
(pip install ← pip freeze)
УРОВЕНЬ 3: изменение в рабочей папке или встроенным инструментом? → снимок
(Git-снимок только затронутых файлов)
УРОВЕНЬ 4: остальное (например, bash run.sh):
├─ лёгкая LLM: «только чтение или нет?»
└─ если нет → субагент осматривает и сохраняет состояние
ЖУРНАЛ: что сохранено + команда или инструкция восстановления
Основной агент может сам пометить действие тегом [BACKUP NEEDED]. Тогда оно пропускает проверку «только чтение?». Непомеченные вызовы всё равно проверяются автоматически.
Пример применения
Задача: Основатель интернет-магазина с выгрузками из 1С, парсером цен конкурентов с Wildberries и PostgreSQL для аналитики просит Claude Code «почистить старые выгрузки, обновить зависимости парсера и убрать дубли товаров в базе». Всё это меняет состояние вне проекта. Откатить потом нечем.
Это перенос идеи BackUpper в текстовую инструкцию для файла CLAUDE.md. Сами авторы реализовали её кодом (хук перед вызовом инструмента). Работает ли текстовая версия так же надёжно, статья не проверяла.
Промпт (в CLAUDE.md или системный промпт агента):
Ты — осторожный инженер. Любое действие, которое меняет состояние
(файлы, пакеты, базу, настройки, письма), ты сначала делаешь обратимым.
Ты не знаешь заранее, что мне понадобится потом, поэтому сохраняешь
всё, что меняешь.
Перед КАЖДЫМ вызовом инструмента классифицируй действие:
READ_ONLY (только чтение: ls, cat, SELECT) → выполняй без бэкапа.
Иначе иди по уровням, применяй первый подходящий:
Уровень 1 — ЗАМЕНА на обратимое:
rm <файл> → mv <файл> ./.trash/<дата>/
DELETE в базе → сначала CREATE TABLE <таблица>_bak_<дата> AS SELECT ...
Уровень 2 — ПАРА «бэкап → действие»:
pip install / npm install → сначала pip freeze > .backup/requirements_<дата>.txt
UPDATE в базе → сначала выгрузка затрагиваемых строк в .backup/
Уровень 3 — СНИМОК (изменения в папке проекта): git commit или git stash
перед правкой.
Уровень 4 — НЕПОНЯТНЫЙ ЭФФЕКТ (запуск скрипта, внешний сервис):
сначала прочитай скрипт или документацию, выпиши, какое состояние
он меняет, сохрани его, и только потом запускай.
Если действие меняет что-то ВНЕ рабочей папки — пометь его
[BACKUP NEEDED] и выполни бэкап обязательно.
После каждого бэкапа добавь запись в .backup/LOG.md:
- что сохранено,
- где лежит,
- точная команда восстановления.
В конце задачи покажи мне список записей.
Бэкапь: {что_бэкапить}
Не бэкапь: {что_не_бэкапить}
Результат: Перед каждой опасной операцией агент будет называть класс действия и уровень. Удаление выгрузок пойдёт через перемещение в .trash. Перед обновлением зависимостей появится файл со списком версий. Перед чисткой дублей в базе появится копия затрагиваемых строк. В конце придёт список журнала с командами восстановления. Это сократит часть пропусков. Полное покрытие гарантирует только перехват на уровне инструмента.
Почему это работает
Слабость: модель оптимизируется под выполнение запроса. Сохранить прошлое состояние никто не просил, поэтому шаг «бэкап» не появляется сам. Дело не в уме: в статье рост «интеллекта» между поколениями GPT почти не поднял долю бэкапов. Дело в привычках, которым модель обучена. У одной модели привычка есть, у другой нет, а разница между обвязками агентов минимальна.
Сильная сторона: модель хорошо следует чёткому правилу вида «если встретил X, сделай Y» и умеет разбирать, что делает скрипт. BackUpper разгружает её. Для простых случаев правило прописано жёстко (rm → mv), и думать не нужно. Для сложных вызывается отдельный субагент, который видит только текущий вызов и заранее подготовленную «шпаргалку» (backup experiences: что меняет каждый инструмент и как это сохранить). Основной контекст остаётся чистым, а бэкап стоит копейки.
Рычаги управления:
- Белый список «только чтение» → расширь, чтобы агент не бэкапил лишнее и не тратил токены.
- Правила уровней 1–2 → добавляй свои пары «опасная команда → безопасный аналог» под свой стек (1С, Postgres, Kubernetes).
- [BACKUP NEEDED] → хорошо работает как явный сигнал для хука или проверки: помеченное не проходит лишнюю проверку.
Шаблон промпта
См. промпт в примере выше. Он сохраняет структуру метода: проверка «только чтение», четыре уровня, тег [BACKUP NEEDED], журнал восстановления, настройка охвата.
Подставляй:
- {что_бэкапить} — что для тебя ценно: «любые данные клиентов, файлы вне папки проекта, версии пакетов, схему базы»;
- {что_не_бэкапить} — что можно терять: «кэш, логи, временные файлы, node_modules».
🚀 Быстрый старт — вставь в чат:
Вот шаблон правил сохранности состояния для агента. Адаптируй под мою
задачу: {твоя задача и инструменты агента}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие инструменты есть у агента (терминал, база, браузер, почта, кластер), где живёт состояние вне рабочей папки и что нельзя терять. Это нужно, чтобы подобрать правила уровней 1–2 под твой стек и честно описать, что для каждого инструмента считается «изменением».
Ограничения
⚠️ Промпт-версия не проверена: В статье эффект измерен у кода-перехватчика, а не у текстовой инструкции в
CLAUDE.md. Текстовое правило поможет, но может пропускаться так же, как и сейчас. Надёжнее хук, который срабатывает независимо от модели.
⚠️ Разброс между моделями огромный: одни модели бэкапят в большинстве запусков, другие почти никогда. Не рассчитывай, что твоя модель «наверное, сама догадается». Проверь её на своих задачах.
⚠️ Нужна инженерия: Полный BackUpper — это плагин для обвязки агента (перехват вызовов, правила, субагент, снимки). Просто настроить его в чате нельзя. Читатель без разработчика получит лишь упрощённую версию.
⚠️ Узкий класс действий: бенчмарк — изменения внешнего состояния (терминал, SQL, браузер, почта, DevOps). Для чистого написания кода или текста это не нужно.
⚠️ Проверка автоматизирована: результаты судила LLM (с проверкой людьми, высокое согласие), а задачи собраны с помощью LLM. Вместо реальных потерь — моделирование.
⚠️ Цена бэкапа: лучшая модель тратит около 9% вызовов на самосохранение, и их оплачивает дорогая основная модель. Субагент дешевле, но это дополнительные вызовы и хранилище.
Как исследовали
Исследователи собрали 205 реальных историй «я потерял X и жалею, что не сделал бэкап» с X.com, GitHub, Stack Overflow и из новостей про потерю данных. Из каждой выделили действие, затронутое состояние и то, что потом понадобилось. Затем каждую историю превратили в исполняемую задачу из нескольких шагов в реальном окружении, например в чужом репозитории с тестами. Задачи покрывают пять типов инструментов: терминал, SQL, браузер, почту и DevOps. Затронутое состояние нарочно вынесли за пределы папки, которую защищают встроенные механизмы агента, чтобы любой бэкап был заслугой самого агента.
Проверили шесть передовых моделей в трёх обвязках агентов. Две LLM-судьи оценивали, выполнена ли задача и сделан ли бэкап перед «моментом сожаления» (согласие с людьми — 95,3%). Результат: агенты проходят в среднем 86,1% задач, но бэкап перед «моментом сожаления» делают только в 15,2%. В 72% запусков задача выполнена, а нужное состояние не сохранено. Лучшая модель (Claude Opus-5) пропускает бэкап в 35,6% задач. Остальные — гораздо хуже: GPT 5.6-Sol — 5,9%, DeepSeek V4-Pro — 2,9%.
Дальше сравнили обвязки. Одни и те же модели в Claude Code, Codex и Hermes дали почти одинаковую долю бэкапов (разброс до 5 пунктов), а между моделями разница огромна. Вывод: дело не в обвязке, а в самой модели. Три поколения GPT (5.4 → 5.5 → 5.6-Sol) подняли «интеллект» с 39 до 47, но доля бэкапов осталась на уровне 5–7%. Значит, «подождём, пока модели поумнеют» не работает. Claude Opus-5 с тем же уровнем интеллекта выдаёт около 73%, значит, привычку надо специально тренировать.
BackUpper покрыл все «моменты сожаления» во всех моделях, а восстановленное состояние на 92,2% совпало с исходным. Цена — $0,014 на задачу, затраты токенов в 7 раз ниже, а задержка бэкапа на 31,7% меньше, чем при самосохранении основным агентом. Ограничение по предпочтениям пользователя даёт F1 84,5%, а решения субагента можно превращать в правила и удвоить покрытие правилами за 30 задач. Часть результатов в предоставленном тексте обрезана.
Адаптации и экстраполяции
🔧 Техника: сузить охват словами → меньше шума и расходов
Авторы в оригинале допускают «персонализированные режимы»: пользователь описывает, что бэкапить. Пример для блока
:Бэкапь только изменения контента, написанного людьми (тексты, таблицы, договоры). Автогенерируемое (кэш, логи, сборки) не сохраняй.Это сокращает вызовы субагента и место под копии.
Экстраполяция (моя идея, в статье не проверялась): предполётная проверка перед опасной задачей
Перед длинной задачей попроси агента заранее составить карту рисков. Это дёшево и отлавливает пропуски до начала.
Прежде чем начать: перечисли все действия из моей задачи, которые
изменят что-то ВНЕ рабочей папки (пакеты, база, настройки, внешние
сервисы). Для каждого напиши: что будет потеряно, как это сохранить,
как восстановить. Жди моего «ок» и только потом выполняй.
Ресурсы
- Работа: Back Up Before You Regret: Measuring Backup Awareness and Automating Backup in Coding Agents (препринт)
- Авторы: Xu Li, Simon Yu, Minzhou Pan, Yiyou Sun, Zhaorun Chen, Bo Li, Weiyan Shi
- Университеты: Northeastern University, UC Berkeley, University of Chicago, UIUC
- Страница проекта: https://back-up-before-you-regret.github.io/
- Данные (RegretBench): https://huggingface.co/datasets/CHATS-Lab/RegretBench
- Код (BackUpper): https://github.com/CHATS-lab/BackUpper