DeepSeek Harness: резервная копия данных и миграция

Сессия открывается после обновления, но Agent не видит прежние действия, пишет не в тот репозиторий или теряет доступ к инструментам.

Самое быстрое решение — разделить резервную копию данных DeepSeek Harness на четыре слоя: окружение для пересоздания, состояние сессий, рабочую область и защищённые учётные данные; затем подтвердить восстановление реальной задачей в изолированной среде, а не только наличием файлов.

Эта инструкция предназначена для вас, если вы:

• готовите обновление DeepSeek Harness или переходите на кандидатную версию;
• переносите локальную среду на облачный Mac;
• переустанавливаете систему после сбоя;
• принимаете или передаёте долгоживущую Agent-среду;
• отвечаете за техническую приёмку и не хотите подписывать миграцию «на доверии».

DeepSeek Harness находится в зоне, где структура хранения и совместимость могут меняться. В официальных материалах по предварительной версии нельзя автоматически считать старые конфигурации, плагины и форматы сессий совместимыми с новой сборкой. Поэтому ниже используется не список «скопируйте всю домашнюю папку», а система измеримых критериев: объект проверки, доказательство и условие отказа.

SECTION 01Сначала зафиксируйте границы восстановления

Перед копированием остановите попытки ответить на вопрос «какие каталоги нужны?» без привязки к конкретной версии и режиму запуска. Один и тот же пользователь может работать через локальный CLI, оболочку Agent, отдельный проектный профиль или облачный Mac. У этих вариантов могут различаться местоположение состояния, набор плагинов и способ загрузки настроек.

Зафиксируйте в отдельном текстовом файле:

• точную версию DeepSeek Harness и источник установки;
• режим запуска — локальный, удалённый, контейнерный или через облачный Mac;
• версию операционной системы;
• версии интерпретатора, менеджера пакетов и системных зависимостей;
• активный идентификатор модели и параметры запроса;
• список подключённых инструментов, MCP-серверов, Skills и проектных инструкций;
• значение DSH_HOME, если оно используется текущей сборкой;
• дату и время начала резервного копирования;
• состояние незавершённых задач.

Официальные руководства DeepSeek отдельно описывают идентификаторы моделей, параметры режима рассуждений и формат взаимодействия с API, поэтому эти сведения должны попасть в манифест восстановления, а не оставаться только в памяти оператора. Сверьте их с официальной документацией DeepSeek по моделям и руководством по режиму рассуждений. (api-docs.deepseek.com)

Что не нужно сохранять как критическое состояние

Не включайте в основной архив всё, что можно воспроизвести из зафиксированного источника:

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

Это не означает, что такие данные всегда следует удалять. Их можно сохранить отдельным техническим слоем, но нельзя смешивать с сессионным состоянием. Иначе при восстановлении вы не отличите обязательный объект от устаревшего мусора, а размер архива и поверхность утечки увеличатся.

Внимание. Не называйте архив полным только потому, что в нём присутствует DSH_HOME. Имя переменной указывает на базовую область, но не доказывает, что в ней находятся рабочие каталоги, плагины, внешние инструкции и все зависимости текущего запуска.

SECTION 02Критерий сессионной целостности: сохранена ли цепочка событий

Для Agent-среды чатовый текст — лишь видимая часть состояния. При восстановлении могут понадобиться записи о вызовах инструментов, результатах инструментов, выбранной модели, изменении параметров, разрешениях и других действиях, которые позволяют продолжить процесс, а не просто прочитать старую переписку.

В материалах по persistence нужно искать не только файлы сообщений, но и журнал устойчивых событий. Если текущая версия использует тип SessionEvent, сохраните его в исходном формате и отдельно зафиксируйте версию формата. На дату 18 августа 2026 года формат предварительной версии нельзя считать стабильным межверсионным контрактом: перенос следует проверять на той же сборке, на которой вы собираетесь выполнять восстановление. Официальные материалы DeepSeek Harness и текущий исходный код являются источниками для проверки именно вашей версии, а не основанием для универсального списка каталогов.

Можно ли восстановить сессию, скопировав только DSH_HOME?

Иногда этого достаточно для конкретного режима запуска, но гарантировать восстановление только по имени переменной нельзя. Сначала проверьте, где текущая версия фактически хранит журнал, индекс сессий, настройки и ссылки на рабочую область. Затем сопоставьте содержимое DSH_HOME с каталогом persistence и манифестом запуска. Если хотя бы один компонент вынесен наружу, копирование одной переменной создаст неполную резервную копию.

Проверка должна завершаться не просмотром дерева файлов, а доказательствами:

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

Полезно выбрать одну короткую, обратимую задачу — например, чтение файла и создание отчёта без изменения репозитория. Она станет контрольным образцом для восстановления.

SECTION 03Рабочая область должна быть связана с каждой сессией

Самая опасная ошибка при миграции — восстановить историю, но подключить её к неправильной папке. Для человека это выглядит как «сессия на месте», однако Agent получает другой cwd, другую ветку или чистую копию репозитория и начинает принимать решения на неверном состоянии.

Для каждого рабочего проекта внесите в манифест:

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

Содержимое Git-репозитория и локальные артефакты — не одно и то же. Код можно получить из удалённого источника, но незакоммиченный патч, локальная конфигурация, тестовые данные или сгенерированный файл могут существовать только на исходном Mac. Поэтому перед копированием сохраните статус рабочей области отдельным доказательством, а не полагайтесь на последующий git status.

Нужно ли переносить журнал сессии вместе с рабочей областью?

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

После восстановления не выдавайте Agent право записи сразу. Сначала:

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

Лишь после этого можно разрешать изменение файлов.

SECTION 04Настройки, плагины и зависимости проверяйте отдельно

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

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

Для каждого объекта добавьте поле «область действия»: пользователь, проект или runtime. Это предотвращает типичный дефект, когда пользовательская настройка попадает в общий архив проекта или проектная инструкция начинает применяться к чужому репозиторию.

Плагин нельзя считать восстановленным только потому, что его конфигурационный файл присутствует. Проверьте источник установки, версию, зависимости, права доступа и фактическую загрузку. Если расширение вызывает внешний сервис, убедитесь, что его endpoint, сертификаты и разрешения соответствуют новой среде.

DeepSeek API поддерживает разные модели и параметры вызовов, а поведение клиента зависит от того, как именно формируется запрос. Поэтому при обновлении сохраняйте не только имя модели, но и профиль запроса, параметры рассуждений, настройки инструментов и ограничения вывода. Официальные рекомендации по конфигурации API нужно использовать как контрольную точку, а не как доказательство совместимости конкретного плагина. (api-docs.deepseek.com)

Пошаговая процедура перед обновлением

Выполните процедуру в таком порядке:

1. Создайте манифест окружения. Запишите версию Harness, источник установки, режим запуска, значения переменных и зависимости.
2. Остановите запись. Завершите активные Agent-задачи, отключите автоматические фоновые процессы или зафиксируйте согласованную границу снимка.
3. Снимите состояние сессий. Экспортируйте доступные сведения о сессиях, сохраните persistent events и отметьте формат.
4. Зафиксируйте рабочие области. Для каждого проекта сохраните путь, ветку, коммит, незакоммиченные изменения и локальные файлы.
5. Соберите настройки и плагины. Разделите пользовательские, проектные и runtime-объекты; проверьте происхождение каждого расширения.
6. Исключите реальные ключи. В архив положите ссылки на credentials и имена переменных, но не действующие API Key.
7. Посчитайте хэши архивов. Хэшируйте каждый слой отдельно и запишите алгоритм, дату и ответственного за копирование.
8. Восстановите в изолированную копию. Используйте другой рабочий путь и запретите запись в боевой репозиторий.
9. Проведите сквозную задачу. Откройте сессию, вызовите модель, запустите безопасный инструмент и проверьте результат в правильной рабочей области.
10. Подпишите или отклоните результат. Если любой обязательный слой проверен только по наличию файлов, но не по поведению, миграция не завершена.

Кэш контекста DeepSeek не следует принимать за замену журналу сессии: официальный API описывает его как best-effort механизм для повторно используемых префиксов, который может автоматически очищаться. Он помогает обработке запросов, но не является гарантированным архивом Agent-состояния. Сверьте описание persistence кэша с вашим локальным механизмом хранения. (api-docs.deepseek.com)

SECTION 05Ключи и секреты должны жить вне обычного архива

Стоит ли помещать API Key в резервную копию?

Нет, если архив предназначен для обычной передачи, хранения в облачном хранилище или выдачи подрядчику. В манифесте сохраните имя переменной, идентификатор секрета, владельца и процедуру выдачи. Сам ключ передавайте отдельным зашифрованным каналом, с минимальными правами и последующей ротацией.

Проверьте не только основной файл настроек, но и:

• журналы запуска;
• shell history;
• файлы отладки;
• скрипты и примеры конфигурации;
• временные JSON-файлы;
• старые архивы;
• дампы базы данных;
• снимки облачного диска;
• логи CI/CD.

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

Опыт эксплуатации. Если ключ уже попал в архив, не ограничивайтесь удалением файла. Считайте его скомпрометированным, отзовите или замените, проверьте журналы передачи и только затем создайте новый пакет.

SECTION 06Три таблицы для решения о приёмке

Следующая таблица помогает выбрать способ переноса:

Для руководителя или технического закупщика важнее всего третья таблица — граница подписи:

SECTION 07Как оформить доказательства для передачи среды

В итоговый пакет положите не только архивы, но и журнал проверки:

• манифест окружения;
• список слоёв и их хэши;
• перечень исключённых файлов;
• карту «сессия — проект — путь — ветка — коммит»;
• результат проверки SessionEvent;
• перечень плагинов и их источников;
• список credential references без самих ключей;
• команды восстановления;
• скриншоты или текстовый вывод контрольной задачи;
• решение «принято», «принято с ограничениями» или «отклонено».

Не добавляйте в документацию неподтверждённые фиксированные пути, обещания восстановления между любыми версиями или универсальные заявления о совместимости. Для каждой конкретной поставки путь и формат нужно сверять с текущим каталогом persistence, официальной документацией и фактическим режимом запуска. В качестве исходной точки используйте официальный репозиторий DeepSeek на GitHub, а не случайные инструкции из обсуждений. (github.com)

Если вы планируете именно перенос на облачный Mac, сначала подготовьте очищенную копию и отдельный лист доступа, а затем согласуйте, кто отвечает за выдачу credentials, проверку рабочей области и удаление тестовых данных. В инструкции MACNOX по заказу облачного Mac можно подобрать подходящий способ передачи среды; перед оформлением проверьте, что выбранная схема позволяет выделить изолированное окно для восстановления и не смешивает тестовый проект с действующей рабочей машиной.

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

SECTION 08Текущая схема против отдельной среды MACNOX

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

Отдельный облачный Mac в MACNOX имеет смысл именно как временный стенд: вы переносите туда очищенную копию, отдельно выдаёте credentials, проверяете сессию и рабочую область, а затем фиксируете доказательства до подписания основной миграции. Это не универсальная замена собственной машине: для постоянной тяжёлой нагрузки, физических интерфейсов и среды, которую вы обязаны контролировать локально, покупка и самостоятельная эксплуатация могут быть разумнее. Но для короткого окна обновления, переезда и приёмки Agent-среды аренда даёт вам изолированное место, где ошибку можно обнаружить до того, как она станет рабочим инцидентом.