Самая опасная ошибка — принять исчезновение интерфейса за остановку Agent-задачи. Закрытая вкладка, оборванный WebSocket, сбой удалённого рабочего стола или краткий разрыв VPN не обязательно завершают процесс на Mac.

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

Сигналы наблюдения

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

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

Слабый сигнал — одна лишь доступность Web UI. Интерфейс может показывать старую сессию, хотя исполнитель уже завершился. Обратная ситуация также возможна: страница недоступна, а процесс продолжает работу.

Проверка из отдельного подключения

Не обновляйте страницу и не отправляйте тот же запрос повторно. Выполните четыре действия:

1. Подключитесь к Mac через второй канал.
2. Проверьте, отвечает ли система и доступен ли каталог проекта.
3. Найдите процесс по имени, PID или родительской команде.
4. Снимите последние строки журнала и список изменённых файлов.

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

date
who
ps aux | grep -i 'deepseek\|harness'
find . -type f -mmin -15 -print
git status --short

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

Условие ожидания

Продолжайте ждать, если одновременно выполняются все условия:

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

Если хотя бы один пункт не подтверждён, остановите автоматическое ожидание. Зафиксируйте состояние и переходите к диагностике.

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

При сбое «прерывание DeepSeek Harness после сна Mac» сначала определите, что именно произошло между последним известным событием и моментом пробуждения. macOS поддерживает настройки сна, пробуждения, Power Nap и доступа к сети во время сна, но доступность этих режимов зависит от типа Mac и текущей конфигурации. (support.apple.com)

Связь между сном и последним событием

Запишите:

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

Проверьте настройки питания:

pmset -g custom
pmset -g assertions
pmset -g sched

pmset -g assertions помогает увидеть активные запреты сна и связанные с ними процессы. Apple отдельно указывает этот инструмент для проверки утверждений, влияющих на управление питанием. (developer.apple.com) Команда pmset -g sched показывает запланированные события пробуждения или питания, но наличие расписания не означает, что конкретная задача Harness возобновится.

Четыре действия после пробуждения

Шаг 1. Не продолжайте выполнение автоматически.
Скопируйте журнал в отдельный файл. Если рабочая область находится под контролем версий, сохраните вывод git status, список новых файлов и контрольные суммы частичных артефактов.

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

Шаг 3. Проверьте рабочую область.
Сопоставьте изменения с последним подтверждённым этапом. Ищите незакрытые временные файлы, пустые отчёты, lock-файлы, частично записанные JSON или незавершённые каталоги.

Шаг 4. Выполните минимальную проверку.
Запустите самый короткий тест, который подтверждает целостность результата. Не начинайте полный набор тестов и не вызывайте Agent для самостоятельного решения, что уже выполнено.

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

Стоп-условия

Автоматическое продолжение запрещено, если:

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

В таком состоянии правильный путь — не «попросить Agent продолжить», а восстановить доказуемую базу. Сохраните diff, переименуйте подозрительные временные файлы, удалите lock только после проверки владельца и вручную определите последний завершённый этап.

Закрытие браузера, разрыв удалённого подключения, выход из macOS и перезапуск Mac — четыре разные операции. Они не должны описываться одним словом «отключение».

Закрытие браузера

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

Разрыв удалённого подключения

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

Выход пользователя

Выход из macOS меняет пользовательский контекст. Приложения, переменные окружения, Keychain, графические разрешения и пользовательские LaunchAgent могут стать недоступными. Документация по архитектуре запуска указывает, что пользовательские агенты работают в контексте отдельной пользовательской сессии, тогда как системные службы запускаются иначе. (developer.apple.com)

Проверьте:

launchctl print "user/$(id -u)"
launchctl list
env | sort
security list-keychains

Не подставляйте новые ключи доступа в старую задачу до проверки её состояния. Иначе вы можете получить смешение двух запусков: старого с устаревшими переменными и нового с другими разрешениями.

Перезапуск системы

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

1. Mac снова доступен по сети.
2. Нужный пользователь вошёл в систему или запущен системный сервис.
3. Запущен исполнитель DeepSeek Harness.
4. Доступны ключи, каталоги и разрешения.
5. Восстановлена рабочая область.
6. Результаты старого запуска проверены.

Автоматический запуск процесса через launchd не равен автоматическому продолжению задания. Он может запустить новый исполнитель, но не знать, какой шаг старой задачи был завершён. Это особенно важно для задач с внешними побочными эффектами.

Сохранённая сессия, строка истории или идентификатор запуска показывают наличие записи. Они не доказывают, что живы основной процесс, дочерний shell, тестовый раннер или сетевой запрос.

Для проверки сравните пять объектов:

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

Если сессия существует, но процесс отсутствует, возможны три варианта.

Продолжение. Подходит для чисто локальной, идемпотентной операции с известной точкой остановки.

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

Ручное восстановление. Требуется, если неизвестно, был ли выполнен внешний вызов, опубликован пакет, изменена схема или отправлен повторный запрос.

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

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

Недостатки:

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

Преимущества чистого перезапуска:

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

Недостатки:

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

После перезапуска Mac наиболее опасны не явные ошибки, а частично правдоподобные результаты. Файл существует, тестовый каталог заполнен, сессия отображается — но неизвестно, завершился ли этап полностью.

Используйте порядок восстановления:

1. Создайте снимок текущей рабочей области.
2. Сохраните все журналы, включая системные сообщения о сне и пробуждении.
3. Выполните git diff и git status --short.
4. Рассчитайте контрольные суммы критичных артефактов.
5. Сверьте манифесты, отчёты и ожидаемые размеры файлов.
6. Запустите минимальный тест на чистом или временном каталоге.
7. Только после этого решите, продолжать ли старую задачу.

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

Нельзя давать Agent указание «продолжи с того места», когда точка остановки неизвестна. Модель может выбрать правдоподобный, но неверный этап. Восстановление должно опираться на журнал, файловые изменения и проверяемый артефакт.

Перед тем как считать Mac-среду пригодной для длительных задач, отметьте каждый пункт:

• [ ] Проверен режим питания при работе от адаптера.
• [ ] Зафиксирован вывод pmset -g custom.
• [ ] Проверены активные power assertions через pmset -g assertions.
• [ ] Понятно, что происходит с задачей при закрытии браузера.
• [ ] Отдельно проверен разрыв удалённого соединения.
• [ ] Отдельно проверен выход пользователя macOS.
• [ ] Проверено дерево основного и дочерних процессов.
• [ ] Журналы сохраняются вне временного каталога.
• [ ] Рабочая область восстанавливается без повторной отправки задачи.
• [ ] Есть проверка lock-файлов и частичных артефактов.
• [ ] Для внешних действий определено условие ручного подтверждения.
• [ ] Проведён контролируемый тест сна и пробуждения.
• [ ] Проведён тест завершения процесса.
• [ ] Проведён тест перезапуска Mac.
• [ ] После каждого теста зафиксированы процесс, сессия, файлы и результат.

Если вы не можете выполнить последние четыре пункта, среда ещё не прошла приёмку. Для подробной проверки фоновых запусков используйте также материал о приёмке фоновых задач DeepSeek Harness. Требования к автоматическому старту после входа и перезапуска сопоставьте с документацией по launchd и отдельно проверьте, где хранится состояние конкретной задачи.

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

Для самостоятельной оценки можно посмотреть варианты аренды Mac mini для удалённой работы. Выбирайте среду не по обещанию «сессия сохранится», а по тому, кто отвечает за процесс, где лежат журналы и как принимается результат после перезапуска.

FAQ вынесен в метаданные страницы, чтобы каждый ответ отображался отдельно и не смешивался с пошаговой диагностикой. Вопросы охватывают продолжение после закрытия крышки, разрыв Web UI, пробуждение, перезапуск удалённого Mac и защиту долгих Agent-задач от сна.

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

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