DeepSeek Harness Job Panel: деление задач в 2026

Сразу к решению

Симптом: несколько субагентов видны в одной панели, но одновременно меняют одни файлы, используют неясные права или оставляют после сбоя неполный результат.

Быстрейшее решение: не закрепляйте Codex или Claude Code за постоянными ролями. Для каждой задачи заранее задайте цель, источник входных данных, область записи, разрешённые команды, владельца результата и правило восстановления. DeepSeek Harness Job Panel удобен для централизованного наблюдения, но сама видимость задач не означает автоматическую изоляцию, разрешение конфликтов или продолжение работы после перезапуска.

Последняя проверка этого материала выполнена 18 августа 2026 года по доступному репозиторию DeepSeek Harness, документации OpenAI Agents SDK для запуска Codex, справочнику Claude Code CLI и документации Git worktree. Подключение агента к панели подтверждает возможность наблюдения или запуска, но не доказывает наличие нужной вам изоляции, политики доступа или восстановления после сбоя.

Эта статья для вас, если вы:

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

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

Контракт задачи вместо деления по названию агента

Главная ошибка — написать: «Пусть Codex занимается кодом, а Claude Code — тестами». Такое правило слишком грубое. Название инструмента не сообщает, какие именно команды доступны агенту в вашей конфигурации, какие файлы он видит, может ли он записывать изменения и как сохраняется его состояние.

Для каждого задания создайте короткий контракт:

1. Цель — один проверяемый результат, например «добавить обработчик ошибок в модуль импорта».
2. Вход — конкретная ветка, список файлов, issue, лог или набор требований.
3. Граница записи — директория, набор файлов или отдельная рабочая копия.
4. Разрешённые действия — чтение, редактирование, запуск тестов, сетевые запросы, установка зависимостей.
5. Артефакты приёмки — diff, список изменённых файлов, команды тестирования, логи и незавершённые пункты.
6. Владелец решения — основной агент или человек, который принимает результат.
7. Ответственный за сбой — тот, кто анализирует ошибку и решает, повторять ли задачу, откатывать ли изменения или передавать её другому агенту.

Используйте идентификатор вроде auth-import-042, а не только текстовое описание. Этот ID должен присутствовать в названии задания, записи журнала и итоговом отчёте. Так вы отличите повторный запуск от новой работы и не допустите, чтобы основной агент повторно сделал уже завершённую часть.

Это особенно важно для Codex и Claude Code: оба инструмента могут работать с кодовой базой, но конкретный набор операций зависит от инструкции проекта, оболочки, разрешений, переменных окружения и адаптера запуска. Документация OpenAI показывает, что рабочая директория, режим песочницы, сетевой доступ и политика подтверждений задаются отдельно. В документации Anthropic аналогично разделены рабочие каталоги, разрешённые инструменты, запрещённые инструменты и режимы подтверждения. (параметры рабочего пространства Codex; разрешения Claude Code)

Следовательно, правильная формулировка выглядит так: «Агент A анализирует файлы src/import/** без записи; агент B меняет только src/import/handler.ts в отдельной рабочей области; агент C запускает тесты на ревизии, переданной агентом B». Это уже управляемое распределение, а не предположение о бренде.

Четыре класса задач и разные границы ответственности

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

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

Контролируемое редактирование. Изменение ограниченного набора файлов без публикации и без операций, затрагивающих инфраструктуру. Здесь предпочтительна отдельная ветка или рабочая копия. Агент не должен самостоятельно менять файлы вне объявленной области.

Сборка и тестирование. Запуск линтера, unit-тестов, сборки или генерации артефактов. Такая задача может быть поручена агенту, который не писал код, но обязан получить точную ревизию или путь к рабочей копии. Результатом должны быть команды, коды завершения и краткое объяснение провала.

Внешние и высокорисковые операции. Работа с сетью, публикация пакетов, изменение CI, доступ к секретам, удаление ресурсов или операции с продакшеном. Для них сохраняйте ручное подтверждение. Даже если панель показывает одну строку состояния, это не заменяет операционную изоляцию на уровне ОС, контейнера или удалённого узла.

Не считайте, что подключение агента к Job Panel автоматически даёт ему отдельные права. Сверьте четыре слоя:

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

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

Общая рабочая область против изоляции

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

Используйте одну из трёх схем.

Только чтение в общей области

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

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

Изолированные рабочие области

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

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

Ответственность за merge должна принадлежать одному владельцу. Не поручайте двум агентам одновременно «собрать финальную версию»: один должен подготовить изменение, другой — проверить или принять его.

Последовательное объединение

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

Оценка относится к управляемости, а не к производительности. Большее число параллельных процессов не компенсирует отсутствие владельца объединения.

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

Права, секреты и точки ручного подтверждения

Проверьте права до запуска реальной задачи. Минимальный тест должен показать:

1. какие каталоги агент может прочитать;
2. может ли он создать временный файл;
3. может ли изменить файл вне разрешённого списка;
4. какие команды доступны без подтверждения;
5. может ли процесс выйти в сеть;
6. видит ли он токены, SSH-ключи и переменные окружения;
7. сохраняются ли логи и удаляются ли временные секреты после завершения.

Не смешивайте «агент видит задание» и «процесс имеет доступ к данным». Первая характеристика относится к интерфейсу и оркестрации. Вторая — к операционной системе, пользователю процесса, контейнеру и настройкам сети.

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

Порядок проверки:

1. Создайте временный репозиторий без настоящих секретов.
2. Дайте субагенту одну разрешённую директорию.
3. Попросите прочитать файл за пределами неё — операция должна быть запрещена или явно зафиксирована.
4. Попросите выполнить безопасную команду и команду из запрещённого списка.
5. Проверьте журнал действий на стороне узла.
6. Только после этого подключайте настоящий репозиторий.

Для Claude Code полезно сверять не только настройки проекта, но и организационные политики: официальная документация описывает иерархию настроек, разрешения для инструментов, режим планирования и отдельные правила для команд оболочки. (IAM и контроль доступа Claude Code)

Для Codex проверяйте рабочую директорию, режим песочницы, сетевой доступ и политику подтверждений в том интерфейсе, через который запускается агент. Нельзя считать, что ограничение, заданное в одном CLI или SDK, автоматически перенеслось в DeepSeek Harness Job Panel.

Статусы, отмена и восстановление

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

Для каждой версии DeepSeek Harness Job Panel отдельно проверьте такие сценарии:

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

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

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

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

У самого DeepSeek Harness в публичном README описаны сохранение сессий, SQLite-состояние и запуск параллельных задач, однако эти сведения не доказывают, что любой внешний Job Panel продолжит незавершённый процесс после перезапуска. (README DeepSeek Harness)

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

Передача результата основному агенту

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

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

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

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

Не используйте один общий текстовый статус для всех ситуаций. Разделяйте как минимум:

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

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

Условия выбора схемы

Используйте следующие ветвления.

• Если задача только читает данные и выдаёт отчёт — выбирайте одного или нескольких агентов в общей области. Зафиксируйте ревизию и запретите запись.
• Если изменения независимы по файлам и есть назначенный интегратор — выбирайте изолированные рабочие области. Каждый результат принимайте по diff и тестам.
• Если изменения затрагивают один модуль, конфигурацию или миграцию — выбирайте последовательную цепочку. Скорость параллельного запуска не стоит стоимости конфликта.
• Если требуются сеть, секреты или публикация — добавляйте ручное подтверждение. Если вы не можете точно определить границу разрешения, откладывайте автоматизацию.
• Если после сбоя нельзя доказать состояние файлов и процесса — не продолжайте автоматически. Сначала восстановите наблюдаемость или создайте новую чистую рабочую область.
• Если результат не содержит diff, логов и незавершённых пунктов — возвращайте задачу на доработку. Повторный запуск без доказательств только увеличит риск дублирования.
• Если нужно проверить саму интеграцию Codex или Claude Code — начните с двух независимых низкорисковых задач. Не подключайте сразу боевой репозиторий и параллельную запись.

Такая схема отвечает и на вопрос о распределении Codex и Claude Code: один из них не получает роль «главного программиста» навсегда. Вы назначаете агенту конкретную ответственность, ограничиваете область воздействия и определяете формат передачи результата.

Запуск без лишнего риска

Перед первым рабочим циклом выполните пять действий:

1. Запишите контракт задачи и назначьте уникальный ID.
2. Создайте тестовую или изолированную рабочую область.
3. Проверьте чтение, запись, команды, сеть и секреты.
4. Выполните короткую задачу с предсказуемым результатом.
5. Прервите её и проверьте фактическое состояние процесса, файлов и журнала.

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

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

Текущая схема и аренда Mac

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

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

Для проверки DeepSeek Harness Job Panel, Codex и Claude Code разумный первый шаг — выделить отдельную удалённую среду, запустить низкорисковую задачу анализа и независимую задачу чтения тестового репозитория, а затем проверить их логи, рабочие области и правила остановки. Если эти два результата нельзя уверенно принять без ручного восстановления, расширять параллельное выполнение рано.