Прерывание долгой задачи Muse Code: как восстановить

Последнее обновление: 12 августа 2026 года. Механизм восстановления сверялся с доступным описанием среды Muse Code и официальной документацией Git, а сведения о Muse Spark — с публикацией Meta. (about.fb.com)

В нашем сценарии есть четыре объекта, которые нельзя смешивать: процесс Muse Code, сеанс терминала, рабочее дерево Git и внешние действия инструментов. Поэтому при прерывании долгой задачи Muse Code не следует сразу запускать ту же команду повторно. Сначала проверьте журнал событий, текущий diff и факт выполнения внешних операций. Если три состояния согласуются — продолжайте. Если нет — откатывайте изменения или восстанавливайте задачу из контрольной точки в новом рабочем дереве.

Этот материал предназначен для:

• разработчиков, тестирующих Muse Code на крупных репозиториях;
• платформенных инженеров, управляющих удалёнными сеансами и фоновыми процессами;
• технических руководителей, которым нужно проверять изменения Agent перед слиянием.

Почему повторный запуск после сбоя часто ухудшает ситуацию

Типичный отказ выглядит безобидно. Разработчик запускает Muse Code для серии изменений, терминал отключается, интерфейс перестаёт отвечать, а после повторного входа система предлагает продолжить работу. Команда запускает задачу ещё раз — и получает второй commit, повторную отправку сообщения, дублирующий запрос к API или конфликт в уже изменённых файлах.

Проблема в том, что «сессия прервалась» не означает «ничего не произошло».

Нужно различать минимум три состояния:

1. Оборвался терминал или сетевое подключение. Процесс мог продолжать работать.
2. Завершился сам процесс Muse Code. Часть изменений могла быть записана до остановки.
3. Модельный запрос завершился ошибкой. Инструмент мог получить ответ, изменить файл или выполнить внешнюю команду до появления ошибки.

Добавляется четвёртый риск — побочный эффект. Запись в файл обычно обратима. Отправка сообщения, публикация пакета, создание тикета или вызов удалённого API может быть необратимым.

Важно: журнал событий — это источник последовательности действий, но не полноценная транзакционная система. Наличие записи о вызове не доказывает, что удалённый сервис применил операцию, а отсутствие записи не доказывает, что побочного эффекта не было.

Именно поэтому Muse Code нельзя воспринимать как базу данных с гарантированным откатом. Официально подтверждена поддержка локального журнала событий для восстановления после перезапуска, но точность восстановления, совместимость формата между версиями и поведение отдельных инструментов нужно проверять в конкретной среде.

Прерывание долгой задачи Muse Code: сначала отделите обрыв от потери данных

Первый шаг: зафиксируйте состояние до любых новых команд

Не запускайте повторно исходный промпт. Не выполняйте автоматический «repair». Сначала сохраните диагностические материалы:

mkdir -p recovery-2026-08-12
git status --short > recovery-2026-08-12/git-status.txt
git diff --binary > recovery-2026-08-12/working-tree.patch
git diff --stat > recovery-2026-08-12/diff-stat.txt
ps aux | grep -i muse

Если процесс ещё работает, его нельзя немедленно завершать. Сначала определите идентификатор процесса и родительский процесс. В удалённых средах полезно проверить, не остался ли сеанс в tmux или screen:

tmux ls
screen -ls

Официальная документация tmux объясняет, как отделять терминальный сеанс от подключения клиента. Это не делает Muse Code бессбойным, но помогает не принять сетевой обрыв за остановку фонового процесса.

Затем проверьте последние события. Название команды зависит от версии и оболочки, поэтому не следует придумывать универсальный флаг. Ищите в журнале:

• идентификатор задачи;
• время последнего события;
• последнюю подтверждённую операцию;
• имя инструмента;
• результат инструмента;
• статус ошибки;
• ссылку на изменённый файл или внешний объект.

Полезная форма записи для расследования:

task_id       = repo-refactor-2026-08-12
last_event    = tool_return
tool          = apply_patch
target        = src/auth/session.ts
result        = success
next_event    = test_start

Если последним событием является tool_call, а tool_return отсутствует, нельзя автоматически считать операцию не выполненной. Для внешнего API это зона неопределённости.

Второй шаг: сопоставьте журнал с Git и временными файлами

Сравните:

git status --short
git diff --name-only
git diff --check
git log -5 --oneline --decorate
find . -maxdepth 3 -type f \( -name '*.tmp' -o -name '*.bak' -o -name '*.swp' \) -print

Задача считается относительно безопасной для продолжения, если одновременно выполняются следующие условия:

• изменения в Git соответствуют последним операциям журнала;
• нет неизвестных временных файлов;
• активный процесс не выполняет незавершённую команду;
• внешние действия подтверждены ответом сервиса;
• после последнего изменения запускаются те же тесты и на той же базовой ветке.

Документация Git по сравнению состояний и diff полезна именно здесь: сначала фиксируется фактический набор изменений, а уже потом принимается решение о продолжении.

Muse Code повторяет действия: причина обычно в неопределённом результате

Почему Muse Code после восстановления повторно запускает инструмент

Повторное выполнение не обязательно означает ошибку модели. Часто система не знает, был ли первый вызов завершён.

Например:

tool_call: create_issue("AUTH-431")
connection_lost
restart
tool_call: create_issue("AUTH-431")

Если первый запрос дошёл до сервера, второй создаст дубликат. Если первый не дошёл, повтор может быть необходим. Без идентификатора операции и проверки результата система находится в состоянии неопределённости.

Причины повторов обычно относятся к одной из четырёх категорий:

• ответ инструмента не был записан в журнал;
• ответ был записан, но не привязан к идентификатору операции;
• процесс получил тайм-аут после выполнения запроса;
• внешний сервис не поддерживает идемпотентный ключ.

Для безопасного продолжения нужны два независимых подтверждения:

1. Локальное: в журнале есть результат вызова и его идентификатор.
2. Удалённое: внешний сервис подтверждает состояние объекта.

Пример проверки перед повторной отправкой:

curl -sS \
  -H "Authorization: Bearer $TOKEN" \
  "https://api.example.invalid/operations/$OPERATION_ID"

Если API не поддерживает проверку операции, используйте естественный уникальный ключ: номер задачи, хэш содержимого, имя ветки или идентификатор сборки. Для коммитов и файловых изменений безопаснее сначала выполнять локальную проверку, а затем создавать commit.

Тип действия	Риск повтора	Что проверить перед продолжением	Решение
Изменение локального файла	Низкий или средний	git diff, журнал патча, конфликт	Продолжить после проверки
Создание commit	Средний	git log, хэш дерева, имя ветки	Не создавать второй commit вслепую
Отправка сообщения	Высокий	идентификатор сообщения и статус доставки	Повторять только после поиска
Удалённый API-запрос	Высокий	идемпотентный ключ и статус операции	Требовать подтверждение
Удаление или публикация	Очень высокий	журнал сервиса и ручная проверка	Не возобновлять автоматически

Для проектирования таких сценариев полезны рекомендации Stripe по идемпотентным запросам. Они относятся не к Muse Code напрямую, а к общему принципу: повторяемый запрос должен иметь ключ, позволяющий серверу вернуть прежний результат вместо создания нового побочного эффекта.

Опыт эксплуатации: если инструмент может изменить внешний ресурс, его результат нужно сохранять как отдельное событие: operation_id, параметры, ответ сервера и время подтверждения. Одной строки «команда выполнена» недостаточно.

Код восстановился, но состояние не совпало с журналом

Muse Code после сбоя: как понять, что рабочее дерево уже «уплыло»

Рассинхронизация появляется не только из-за самого Agent. Файлы могли изменить:

• разработчик вручную;
• другой Agent;
• форматтер или генератор;
• фоновый процесс сборки;
• автоматический hook Git;
• параллельная задача в той же директории.

Сначала определите базовую точку:

git rev-parse HEAD
git branch --show-current
git status --short
git diff --name-status

Затем сопоставьте список файлов с журналом. Если журнал говорит, что Muse Code редактировал src/api/client.ts, а в diff изменены ещё package-lock.json и scripts/release.sh, необходимо выяснить происхождение дополнительных изменений.

Удобнее всего создать отдельное рабочее дерево:

git fetch --all --prune
git worktree add ../repo-recovery-2026-08-12 origin/main
cd ../repo-recovery-2026-08-12
git switch -c recovery/muse-code-2026-08-12

Официальное руководство Git по worktree описывает этот механизм как способ работать с несколькими деревьями одного репозитория без копирования всей истории. Для восстановления это важнее, чем простая новая ветка: исходная директория остаётся неизменной и сохраняется как вещественное доказательство.

Признак	Рабочее дерево можно продолжить	Нужно новое дерево
Все файлы из diff есть в журнале	Да	Не обязательно
Есть ручные изменения после последнего события	Только после ревизии	Предпочтительно
Работал параллельный Agent	Редко	Да
Нет уверенности в базовом commit	Нет	Да
Внешняя операция уже выполнена	Только после проверки	Да, для кода
Остались временные или генерируемые файлы	После очистки	Если происхождение неизвестно

Если невозможно доказать соответствие состояния журналу, продолжение в прежней директории создаёт ложную уверенность. Новое рабочее дерево не отменяет изменения, но отделяет восстановленную попытку от спорного состояния.

Muse Spark 1.2 и фоновые Agent: свежий результат не всегда пригоден

Название модели не заменяет контроль состояния. Это особенно важно, если Muse Code использует Muse Spark 1.2 или другую версию модели для многошагового задания. Публикация Meta описывает Muse Spark как мультимодальную модель с поддержкой использования инструментов и многоагентной оркестрации, но такие возможности не означают автоматической целостности рабочего дерева. (about.fb.com)

Для каждого фонового Agent проверяйте:

agent_id
task_id
base_commit
created_at
completed_at
result_ref
test_command

Результат считается устаревшим, если:

• он создан до изменения базовой ветки;
• ссылка указывает на старый commit;
• тесты запускались на другой конфигурации;
• в журнале нет подтверждения актуального рабочего дерева;
• основной процесс уже применил альтернативный патч.

В таком случае нельзя просто объединять результат. Сначала повторите проверку:

git show --stat --oneline "$BASE_COMMIT"
git diff "$BASE_COMMIT"...HEAD
./scripts/test.sh

Если тестового скрипта нет, зафиксируйте точную замену: команду сборки, набор проверок и переменные окружения. Без этого нельзя утверждать, что старый результат остаётся действительным.

Как настроить контрольные точки для долгих задач

Третий шаг: разделите большую задачу на проверяемые этапы

Длинный промпт без контрольных точек плохо подходит для крупного репозитория. Разделите работу на независимые этапы:

1. анализ структуры;
2. изменение одного подсистемного блока;
3. локальные тесты;
4. ревизия diff;
5. commit;
6. переход к следующему блоку.

После каждого этапа сохраняйте:

git add -A
git diff --cached --check
git commit -m "checkpoint: update session handling"
git tag -f muse-checkpoint-session

Тег не заменяет commit, но делает контрольную точку заметной. Для фоновых задач также сохраняйте команду запуска и окружение:

env | sort > recovery-2026-08-12/environment.txt
git rev-parse HEAD > recovery-2026-08-12/base-commit.txt

Не записывайте в файл секреты без фильтрации. Токены, ключи и содержимое переменных CI нужно исключать до сохранения диагностических данных.

Практическое правило:

• если этап меняет только локальный код — контрольная точка после тестов;
• если этап создаёт внешний побочный эффект — сначала подтверждение операции, затем commit;
• если этап зависит от фонового Agent — фиксируйте base_commit и тестовую команду;
• если задача длится дольше одного сеанса — используйте отдельную рабочую ветку или worktree.

Для постоянных удалённых процессов можно применять менеджер служб. Документация systemd по перезапуску сервисов показывает, как отделить жизненный цикл процесса от SSH-сеанса. Но автоматический перезапуск должен запускать восстановление только после проверки состояния, а не безусловно повторять последнюю команду.

Четыре решения после расследования: продолжить, откатить, остановить или пересоздать

После сбора данных выберите одно из четырёх действий.

Продолжить

Подходит, если:

• последнее событие однозначно подтверждено;
• Git-состояние совпадает с журналом;
• внешние операции проверены;
• тестовая база не изменилась.

Продолжайте с короткой команды, которая указывает текущий этап. Не отправляйте весь исходный промпт повторно.

Откатить

Выбирайте откат, если изменения локальны и понятен безопасный commit:

git restore --source=HEAD --staged --worktree -- src/module

Для уже созданного commit используйте отдельный revert, а не удаление истории:

git revert <commit>

Смысл отката — вернуть код в известное состояние, а не стереть доказательства сбоя.

Остановить

Остановите задачу, если есть риск повторного удаления, публикации, отправки или изменения производственной системы. Сначала сохраните журнал, diff и ответы инструментов. Только затем закрывайте процесс.

Пересоздать

Создайте новое рабочее дерево, если:

• журнал и Git расходятся;
• были ручные изменения;
• работали несколько Agent;
• неизвестна базовая ветка;
• результат фоновой задачи устарел;
• часть внешних действий нельзя подтвердить.

Пересоздание медленнее продолжения, но дешевле, чем разбирать смешанный diff после повторной автоматизации.

Текущая среда против удалённого Mac для долгих задач

Локальный ноутбук удобен для коротких изменений, но плохо подходит для постоянных фоновых задач: закрытие крышки завершает часть процессов, сетевой обрыв ломает SSH-сеанс, а локальные журналы могут не попасть в командное хранилище. Облачный контейнер решает часть проблемы, но часто добавляет ограничения по доступу к macOS-инструментам, файловой системе и окружению Apple.

Для временной проверки Muse Code разумно сначала использовать изолированный удалённый Mac: отдельный репозиторий, отдельную рабочую ветку и сохранение журнала вне каталога проекта. Такой подход даёт стабильный сеанс, не смешивает эксперимент с рабочим ноутбуком и позволяет повторить сценарий обрыва без риска для основной директории.

Если задача требует постоянной тяжёлой обработки, физического интерфейса или предсказуемого окружения на длительный срок, аренда не всегда будет лучшим вариантом — собственное устройство может оказаться экономичнее. Но для короткого теста восстановления, проверки Muse Spark 1.2 или запуска фонового Agent без покупки отдельного Mac временная среда от leapmac обычно практичнее: можно сначала воспроизвести сбой, оценить правила журналирования и только потом принимать решение о постоянной инфраструктуре.