На 18 августа 2026 года официальный репозиторий DeepSeek Harness указывает локальный веб-интерфейс на порту 3 080 и одновременно помечает проект как developer preview с возможными несовместимыми изменениями. Это означает: запуск фоновой задачи нельзя считать доказательством готовности к эксплуатации — перед выпуском вы должны подтвердить изоляцию владельца, наблюдаемость статуса, отмену, уведомления и восстановление после сбоев. (github.com)
Эта проверка предназначена для разработчиков, которые передают DeepSeek Harness длительные сборки, тесты, анализ кода или пакетную обработку; для специалистов, поддерживающих постоянную среду AI Agent; для руководителей проектов, которым нужно решить, расширять ли окружение или разделять задачи по разным узлам.
Последняя проверка выполнена 18 августа 2026 года. Перед повторной приёмкой сверяйте текущую ветку, опубликованный контракт jobs, документацию подсистем и фактическую реализацию: официальный репозиторий прямо предупреждает о быстром изменении интерфейсов и несовместимых обновлениях. (github.com)
SECTION 01 Что должно быть доказано до выпуска фоновых задач
Вам нужен не скриншот с надписью «выполняется», а комплект свидетельств, который позволяет восстановить ход операции без догадок. Для каждой проверки заранее определите:
- действие — что именно запускается, закрывается, отменяется или перезапускается;
- артефакт — какой журнал, снимок состояния, идентификатор, файл или отчёт сохраняется;
- решение — «пройдено», «пройдено с ограничением» или «не пройдено»;
- ответственного — кто подписывает результат и кто повторяет тест после обновления.
Официальный контракт jobs описывает наблюдение, ожидание, отмену и уведомление о завершении, а также связывает задачу с владельцем. Но это контракт поведения подсистемы, а не обещание того, что локальный процесс переживёт перезапуск операционной системы. Эти два уровня необходимо записывать раздельно: «поддерживается интерфейсом» и «подтверждено в нашей среде». Для сверки используйте официальный репозиторий DeepSeek Harness, его README с текущими ограничениями и документацию проекта. (github.com)
| Область приёмки | Что проверить | Доказательство | Решение |
|---|---|---|---|
| Изоляция | Видит ли сеанс только свои задачи | Два журнала доступа и результаты перекрёстных запросов | Выпускать только при запрете чужих операций |
| Наблюдаемость | Можно ли связать статус с вводом, рабочей областью и результатом | Снимки статуса, журнал, хеш или список артефактов | Без связи с объектом задача не принята |
| Управляемость | Останавливаются ли процесс и дочерние процессы | Состояние после отмены, список процессов, освобождённые блокировки | Интерфейсное изменение без остановки — отказ |
| Уведомления | Приходят ли сигналы об успехе, ошибке и отмене | Журнал событий и подтверждение получателя | Раннее уведомление — отказ |
| Восстановление | Что происходит после разрыва связи и перезапуска | Сравнение состояния до и после сбоя | Нет доказанного восстановления — ручной режим |
SECTION 02 Первый этап: как исключить пересечение владельцев и рабочих областей
Самая опасная ошибка — принять уникальный идентификатор задачи за механизм разрешений. Идентификатор помогает найти запись, но сам по себе не доказывает, что другой сеанс не сможет её прочитать, ожидать или отменить.
Создайте два управляемых сеанса с разными владельцами и двумя рабочими областями. Запустите по одной длинной задаче, каждая из которых оставляет различимый маркер в журнале и создаёт отдельный итоговый файл. Затем выполните четыре действия:
- Из сеанса А запросите собственный статус и сохраните вывод.
- Из сеанса А попробуйте получить статус, журнал и результат задачи Б.
- Из сеанса А попробуйте ожидать или отменить задачу Б.
- Повторите те же действия в обратную сторону.
Проверяйте не только ответ веб-интерфейса. Смотрите, не появился ли чужой файл в рабочей области, не изменился ли журнал, не прекратился ли процесс после запроса отмены и не попали ли переменные одного Agent в другой запуск. Если несколько исполнителей используют общий каталог, общий временный путь или один репозиторий с незаметными блокировками, изоляция считается неполной даже при корректном запрете API-операций.
Важно: формулировка «задачи принадлежат пользователю» должна быть дополнена границами: кто может видеть запись, читать журнал, забирать артефакт, отменять процесс и освобождать рабочую область. Если хотя бы один пункт не определён, это не завершённая модель владения.
Сохраните необработанные ответы, время проверки, версии компонентов и идентификаторы сеансов. В итоговой ведомости разделите официальный контракт и фактический результат теста. Не заменяйте второй первым.
SECTION 03 Когда статус действительно помогает найти неисправность
Статус «работает» мало полезен, если вы не знаете, какая рабочая область используется и какой ввод обрабатывается. Для каждой фоновой задачи должна существовать трассировка:
идентификатор задачи → владелец → сеанс → рабочая область → входные данные → дочерние процессы → журнал → итоговые артефакты.
Проверьте переходы от создания к запуску, выполнению, успешному завершению, ошибке и отмене. Если в реализации доступны снимки состояния или промежуточные события, сохраните их на каждом переходе. Если доступен только текущий статус, добавьте внешнюю запись оператора с отметкой времени и последним наблюдаемым действием.
Задание не принимается, если:
- статус существует, но его нельзя связать с конкретной рабочей областью;
- журнал показывает выполнение, но не позволяет определить входные данные;
- задача отмечена завершённой, а итоговый файл ещё записывается;
- ошибка скрыта за общим сообщением без указания этапа;
- после исчезновения интерфейса невозможно определить, продолжился ли процесс.
Для анализа длительных операций полезно отделять «процесс жив» от «работа движется». Если размер журнала, контрольный файл или счётчик обработанных объектов не меняется, задача может оставаться активной только формально. Такой критерий особенно важен для background jobs, которые выполняют тесты с зависшими дочерними процессами.
SECTION 04 Отмена, тайм-аут и остаточные процессы: три обязательных сценария
Безопасная отмена должна проверяться в трёх вариантах, потому что каждый выявляет отдельный класс дефектов.
Нормальная отмена. Запустите задачу, которая регулярно создаёт промежуточные результаты, и отправьте штатную команду отмены во время работы. Зафиксируйте время запроса, время изменения статуса и фактическое завершение процесса. После этого проверьте блокировки, открытые файлы и возможность повторного запуска в той же рабочей области.
Задача без ответа. Используйте контролируемый шаг, который перестаёт выдавать новые события, но не должен бесконечно удерживать ресурсы. Проверьте, появляется ли отдельный признак тайм-аута, можно ли повторить отмену и кто принимает решение о принудительном завершении. Не подменяйте тайм-аут ожиданием оператора: автоматическое ограничение должно приводить к однозначному состоянию.
Оставшийся дочерний процесс. Отмените родительскую задачу и проверьте дерево процессов, сетевые соединения, временные файлы и блокировки. Изменение карточки в интерфейсе недостаточно. Если дочерний процесс продолжает писать в рабочую область или потреблять ресурсы, фоновые задачи нельзя считать безопасными для общего окружения.
Любые временные данные в отчёте должны иметь источник: официальное описание параметра либо отметку о тестовой среде и дате. Не вписывайте универсальные значения времени ожидания, если текущая версия их не документирует.
SECTION 05 Как принять уведомления, не перепутав их с готовым результатом
Проверьте три события отдельно: завершение с успехом, завершение с ошибкой и отмена. Для каждого события задайте два вопроса:
- Кто получает сигнал — Agent, оператор, внешний журнал или несколько получателей?
- Готов ли артефакт в момент сигнала?
Сделайте задачу, которая сначала создаёт временный файл, затем записывает итоговый файл и только после закрытия файлового дескриптора завершает работу. В момент уведомления сравните размер, контрольную сумму, дату изменения и читаемость результата. Если уведомление приходит до полной записи, его можно использовать только как сигнал «процесс изменил состояние», но не как подтверждение поставки.
Если уведомление отсутствует, резервный маршрут должен быть заранее описан:
- проверить текущий статус по идентификатору;
- открыть последний участок журнала;
- проверить изменение контрольного файла;
- сопоставить рабочую область с ожидаемым списком артефактов;
- зафиксировать ручное решение в журнале приёмки.
Практическое правило для AI Agent: агент не должен самостоятельно объявлять задачу выполненной по одному событию. Нужна проверка состояния и результата, иначе ошибка доставки уведомления превращается в ложное подтверждение.
SECTION 06 Что именно меняется после разрыва связи и перезапуска
Закрытие браузера, обрыв удалённого подключения, завершение процесса Harness и перезапуск операционной системы — четыре разные проверки. Нельзя объединять их в один пункт «устойчивость к отключению».
| Событие | Что остаётся доступным | Что проверить после возврата | Как классифицировать |
|---|---|---|---|
| Закрытие браузера | Может исчезнуть только интерфейс | Статус из нового окна, журнал и артефакты | Подтверждённая работа только при новом наблюдении |
| Разрыв удалённого подключения | Сеанс управления теряет канал | Продолжение процесса и полнота записи | Допустимо для автоматики при доказуемом продолжении |
| Выход Harness | Может исчезнуть диспетчер задач | Есть ли запись, процесс и механизм восстановления | Обычно требуется ручная проверка |
| Перезапуск операционной системы | Процессы и память очищаются | Контрольные точки, автозапуск, восстановление | Не считать продолжение гарантированным |
Для каждой проверки запускайте один и тот же базовый сценарий: фиксированный вход, известная рабочая область, промежуточный маркер и ожидаемый итоговый файл. После сбоя не запускайте сразу новую копию — сначала сохраните остаточное состояние. Иначе вы потеряете возможность понять, была ли старая задача продолжена, продублирована или заменена новой.
Официальная документация и локальная реализация могут описывать сохранение сессии или данных, но это не тождественно сохранению выполняющегося процесса. Даже если история доступна после входа, незавершённая команда могла остановиться в момент перезапуска. Для долгих задач на удалённом Mac это означает необходимость отдельного теста восстановления, а не доверие к тому, что среда находится в сети.
Дополнительные ограничения текущего проекта нужно учитывать уже на этапе планирования: официальный репозиторий называет DeepSeek Harness предварительной версией и предупреждает о несовместимых изменениях. После обновления повторяйте хотя бы тесты отмены, уведомлений и перезапуска. (github.com)
SECTION 07 Пятый этап: как нагрузка превращается в решение о ёмкости
Не задавайте заранее универсальный порог по CPU, памяти или диску. Сначала возьмите представительную задачу: сборку с тестами, анализ репозитория или пакетную обработку файлов. Затем повторите её при последовательном и одновременном запуске, сохраняя одинаковые версию Harness, модель, входные данные и состояние рабочей области.
Фиксируйте:
- загрузку процессора и памяти;
- рост временного и итогового хранилища;
- количество одновременно открытых процессов;
- задержку ответа интерфейса;
- конкуренцию за рабочую область и блокировки;
- полноту журналов и артефактов;
- поведение отмены под нагрузкой.
| Результат испытания | Признаки | Решение |
|---|---|---|
| Можно выпускать | Задачи изолированы, статус восстанавливается, отмена очищает процессы, артефакты проверяемы | Запускать с утверждённым регламентом |
| Нужна отдельная среда | Интерактивная работа мешает фоновым задачам, общие каталоги создают блокировки или падает отзывчивость | Разделить интерактивные и длительные задачи |
| Нельзя использовать для постоянной работы | Нет доказанного восстановления, остаются процессы, теряются артефакты или невозможно установить владельца | Оставить только ручные короткие операции |
Результатом должна быть не цифра «поддерживает N задач», а граница применимости конкретного окружения. В акт приёмки внесите базовый сценарий, версию, конфигурацию, способ подключения, дату повторной проверки и ответственное лицо. Если вы меняете модель, плагины, способ хранения или версию операционной системы, считайте это новым испытанием.
Опыт эксплуатации: отдельная среда нужна не потому, что удалённое облако якобы не прерывается. Она нужна для уменьшения числа неизвестных: собственная рабочая область, понятные права, предсказуемый доступ к журналам и заранее проверенный путь восстановления.
SECTION 08 План приёмки на текущую неделю
День 1 — подготовка. Зафиксируйте версию, репозиторий, рабочую область, владельцев, базовую задачу и список ожидаемых файлов. Подготовьте два сеанса для проверки перекрёстного доступа.
День 2 — жизненный цикл. Проверьте создание, наблюдение, ожидание, успешное завершение, ошибку и отмену. Сохраните журналы и ответы интерфейса до и после каждого действия.
День 3 — сбои. Последовательно выполните закрытие браузера, разрыв подключения, выход Harness и перезапуск Mac. Между тестами очищайте только то, что разрешено методикой, чтобы не уничтожить доказательства.
День 4 — нагрузка. Повторите базовую задачу с конкурирующими запусками. Отдельно проверьте отзывчивость, рабочие области, блокировки и отмену.
День 5 — решение. Подпишите один из трёх выводов: выпуск, разделение среды или запрет постоянной фоновой эксплуатации. Не оставляйте статус «условно готово» без перечисления конкретных ограничений и владельца следующего теста.
Если текущая среда смешивает браузерную работу, эксперименты нескольких Agent и длительные сборки, у неё обычно обнаруживаются три практических недостатка: общий ресурсный профиль, неочевидные границы рабочей области и сложное восстановление после перезапуска. В такой ситуации отдельный удалённый Mac может быть разумнее не как обещание непрерывности, а как контролируемый объект приёмки. Вы можете оценить варианты аренды Mac в VPSNIX, выбрать среду под окно занятости и сначала прогнать тот же базовый сценарий через оформление заказа VPSNIX. Если нужны временные вычислительные ресурсы или изолированный тестовый узел, такой пробный запуск даст больше уверенности, чем перенос незрелых background jobs прямо в постоянную командную среду.