Миграция DeepSeek Harness на облачный Mac в 2026

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

Эта инструкция подходит локальным пользователям, которые превращают эксперимент в постоянно работающую задачу, операторам Agent-среды, которым нужны аудит и повторяемость, а также руководителям проектов, принимающим решение о сохранении или пересоздании состояния.

Последняя проверка материалов выполнена 18 августа 2026 года. Актуальность команд и поведения сверялась с официальным репозиторием DeepSeek Harness, руководством Web UI и документацией по разработке. Проект остаётся в статусе developer preview и прямо предупреждает о возможных несовместимых изменениях. (github.com)

[ SECTION_01 ] Почему полный перенос каталога ломает среду

Типичный неудачный сценарий выглядит убедительно: после копирования на облачный Mac видны исходники, папки плагинов и файлы настроек, но Agent открывает не тот проект, модель не отвечает, а прежняя сессия не продолжается. Файлы присутствуют. Рабочее состояние — нет.

Причина в том, что каталог Harness содержит активы разного типа. Для каждого нужен собственный способ переноса:

• Код и данные проекта. Обычно копируются через Git, архив или синхронизацию. Перед этим фиксируются ветка, commit и незакоммиченные изменения.
• Конфигурация Harness. Переносится выборочно. Нужно отделить обычные параметры интерфейса от Provider ID, путей, разрешений и ссылок на переменные окружения.
• Секреты. Не копируются в составе архива. На целевом Mac они вводятся заново или подключаются через контролируемое хранилище.
• Плагины и runtime. Сначала фиксируются версии и список зависимостей, затем среда собирается заново.
• Журналы и состояние сессий. Сохраняются как архив и источник аудита. Их автоматическое продолжение допускается только после отдельной проверки.

У этого подхода есть три скрытые цены.

Первая — неверный контекст рабочего каталога. Web UI использует каталог запускающего процесса как исходное расположение файлов, но новая среда не обязана иметь выбранную рабочую область. Официальное руководство отдельно описывает добавление проекта через Choose workspace. (github.com)

Вторая — смешение идентичности и настроек. Имя модели можно увидеть в конфигурации, но сохранённая сессия может ссылаться на Provider ID, маршрут или внутреннее имя. Переименование «для порядка» способно разорвать связь со старыми данными.

Третья — разница окружения. Даже одинаковые файлы не создают одинаковый runtime. Меняются версия Node.js, менеджер пакетов, права доступа, системные библиотеки, переменные окружения и расположение проекта.

Официальный репозиторий указывает поддержку Node.js 22.19 и новее, а также Node.js 24 и 26 в CI. В нём также зафиксирован pnpm 11.7.0. Эти значения нельзя заменять «похожими» версиями без проверки. (github.com)

[ SECTION_02 ] Инвентаризация состояния перед переносом

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

В паспорт включаются:

1. абсолютный путь локальной рабочей области;
2. текущая ветка и commit;
3. список незакоммиченных файлов;
4. версия DeepSeek Harness;
5. версия Node.js;
6. версия менеджера пакетов;
7. список активных плагинов;
8. Provider ID и выбранные модели;
9. используемые переменные окружения;
10. расположение DSH_HOME;
11. перечень журналов DeepSeek Harness;
12. текущая политика подтверждения опасных операций;
13. команда запуска;
14. дата и результат последнего успешного теста.

DSH_HOME нужно воспринимать как указатель на базовую область данных, а не как «папку, которую всегда можно перенести целиком». Конкретные пути, состав подпапок и правила загрузки следует проверять в документации версии, установленной в исходной и целевой среде. Если структура изменилась, старый архив становится резервной копией, а не инструкцией к безусловному восстановлению.

Перед упаковкой полезно исключить:

• файлы .env;
• ключи и токены;
• shell history;
• временные логи;
• кэш пакетов;
• скомпилированные модули;
• локальные сокеты;
• PID-файлы;
• каталоги, которые создаются автоматически при первом запуске.

Отдельно сохраняются контрольные материалы: список файлов, хеш архива, версия приложения и скриншот или текстовый экспорт основных настроек. Секреты в этот набор не включаются.

[ SECTION_03 ] Рабочая область и границы Agent

Самый опасный функциональный сбой — не падение Harness, а работа с неправильным проектом. Agent может успешно прочитать файлы, выполнить анализ и даже предложить изменение, но сделать это в соседнем репозитории.

На целевом облачном Mac проверяются четыре значения:

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

Порядок проверки должен быть жёстким:

1. Запустить Harness из целевого каталога.
2. В интерфейсе выбрать именно этот каталог как workspace.
3. Выполнить только чтение: перечислить корневые файлы и основные пакеты.
4. Попросить Agent назвать текущую ветку и описать структуру проекта.
5. Сверить ответы с заранее подготовленным паспортом.
6. Только после этого включать операции редактирования.
7. Команды оболочки открывать через политику подтверждения, а не автоматически.

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

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

[ SECTION_04 ] Конфигурация, Provider ID и модели

Настройки удобно разделить на четыре группы.

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

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

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

Переменные окружения. Конфигурация часто содержит не значение ключа, а ссылку на имя переменной. Поэтому после переноса проверяется не только файл, но и окружение процесса, который запускает Harness.

В официальном руководстве Web UI ключ API вводится в Settings → Models, после чего маршрут модели становится доступен без перезапуска сервера. Это важная граница: если интерфейс показывает сохранённую модель, но запрос не проходит, проверяется источник ключа и фактический маршрут, а не только содержимое конфигурационного файла. (github.com)

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

[ SECTION_05 ] Секреты и журналы доступа

Ключ API нельзя включать в архив миграции, отправлять в чат Agent или оставлять в демонстрационном скрипте. Даже если архив передаётся по защищённому каналу, он может попасть в резервные копии, историю загрузок или папку временных файлов.

Безопасная схема выглядит так:

1. Создать целевую среду без секретов.
2. Настроить базовый Harness.
3. Передать ключ через защищённый механизм или внести его вручную на целевом Mac.
4. Убедиться, что значение не записывается в конфигурацию открытым текстом.
5. Выполнить короткий тест модели.
6. Проверить права доступа к файлу или переменной.
7. Просмотреть журнал процесса и историю терминала.
8. Удалить временные файлы после проверки.

В документации разработки пример использует DEEPSEEK_API_KEY и необязательный DEEPSEEK_BASE_URL; там же отдельно указано, что реальные учетные данные нельзя коммитить. Переменная DEEPSEEK_BASE_URL может менять маршрут, поэтому её наличие нужно фиксировать в паспорте среды. (github.com)

Проверяется именно источник, из которого запущенный процесс получает секрет. Ошибка «ключ не найден» и ошибка «используется старый ключ» выглядят по-разному, но обе возникают, когда оператор проверяет не тот слой.

[ SECTION_06 ] Плагины и версии runtime

Плагин может не запуститься после миграции по четырём причинам:

• несовместимая версия Harness;
• несовместимая версия Node.js;
• отсутствующая системная зависимость;
• переменная окружения или путь, который существовал только локально.

Официальная архитектура DeepSeek Harness строится по принципу «всё является плагином», поэтому перенос одного каталога не равен переносу всей рабочей среды. (github.com)

Правильная последовательность:

1. Зафиксировать список плагинов и их версии.
2. Сохранить манифесты зависимостей.
3. Установить поддерживаемую версию Node.js.
4. Установить закреплённую версию менеджера пакетов.
5. Запустить базовую конфигурацию без сторонних расширений.
6. Проверить запуск Web UI и тестовый запрос.
7. Добавлять плагины по одному.
8. После каждого добавления выполнять повторный запуск.
9. Записывать точную ошибку, а не переустанавливать всё окружение целиком.

Для запуска Web UI официальная инструкция указывает команду npx @deepseek-ai/dsh web; сервер по умолчанию открывается на локальном адресе 127.0.0.1:3080. Это не означает, что порт автоматически доступен извне: для удалённой работы потребуется безопасный туннель, прокси или другой контролируемый способ доступа. (github.com)

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

[ SECTION_07 ] Сеансы и журналы DeepSeek Harness

Журналы DeepSeek Harness имеют двойную ценность. Они сохраняют контекст и помогают расследовать действия Agent, но одновременно могут содержать пути, фрагменты исходного кода, команды и чувствительные данные.

Поэтому журнал переносится в три этапа:

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

В developer preview нельзя обещать универсальную совместимость сеансов между версиями. Официальный репозиторий прямо предупреждает о compatibility-breaking changes. Следовательно, старый журнал может остаться полезным как историческая запись, но не как гарантированный снимок, из которого продолжится работа. (github.com)

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

[ SECTION_08 ] Проверка миграции и условия отката

Оценка готовности должна опираться не на факт запуска интерфейса, а на последовательность операций:

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

В официальном руководстве Web UI Agent может читать и редактировать файлы, выполнять команды, делегировать работу и поддерживать план; операции, требующие подтверждения, проходят через активную политику разрешений. Поэтому в приёмке нужно проверять не только ответ модели, но и границы действий. (github.com)

Приёмочная проверка

• [ ] Сохранён неизменный архив исходной среды.
• [ ] Записаны версия Harness, Node.js и менеджера пакетов.
• [ ] Зафиксированы путь workspace, ветка и commit.
• [ ] DSH_HOME проверен по документации установленной версии.
• [ ] В архиве отсутствуют ключи, токены и .env.
• [ ] Целевой Mac запускает базовую конфигурацию без сторонних плагинов.
• [ ] Provider ID не переименован без отдельного плана совместимости.
• [ ] Новый запрос к модели выполнен в новой сессии.
• [ ] Плагины добавлены по одному и проверены после запуска.
• [ ] Старый журнал открыт только на рабочей копии.
• [ ] После перезапуска workspace и модель остаются доступными.
• [ ] Определены условия возврата к локальной среде.
• [ ] Целевая среда не становится единственной рабочей копией до завершения приёмки.

Откат запускается, если Agent видит неправильный каталог, модель обращается к неверному Provider, журнал открывается частично, плагин меняет разрешения неожиданным образом или после перезапуска исчезают настройки. До исправления причины длительные фоновые задачи на новой среде не включаются.

[ SECTION_09 ] Частые вопросы о переносе

Сессия после смены Mac

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

Копирование настроек

Копируются обычные параметры и декларативный список расширений. Повторно проверяются Provider ID, модель, рабочий путь, разрешения и переменные окружения. Секреты не включаются в архив.

Перенос API-ключа

Переносится ссылка на секрет, но не открытое значение. На целевой среде проверяется, какой процесс и каким способом читает ключ. После теста очищаются временные материалы и история команд.

Сбой плагина

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

[ SECTION_10 ] Что выбрать: перенос или отдельный облачный Mac

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

Облачный Mac даёт отдельную точку запуска, удалённый доступ и возможность провести миграцию, не затрагивая исходную систему. Недостатки тоже реальны: нужно контролировать SSH или Web UI-доступ, хранение секретов, сетевые задержки и ежемесячные расходы. Для постоянной тяжёлой нагрузки или работы с физическими интерфейсами аренда подходит не всегда — в таких случаях оправдан собственный Mac.

Если задача временная — например, нужно провести миграционную репетицию, проверить плагины или оставить Agent работать онлайн, — разумнее сначала выделить независимую среду. NOVAKVM позволяет рассматривать аренду Mac как испытательный контур: сначала восстановить рабочую область, модели, плагины и журналы, затем подтвердить перезапуск и только после этого переносить длительную задачу. Для выбора сценария также полезно заранее сопоставить требования к облачному Mac для DeepSeek Harness с ограничениями конкретного проекта.

Главное преимущество такого подхода — локальная среда остаётся точкой возврата. Это особенно важно для DeepSeek Harness в developer preview, где обновление может изменить загрузку плагинов, формат конфигурации или поведение журналов.