DeepSeek Harness: общий Mac или раздельно

План решения на ближайшую неделю

Ключевой вопрос для развёртывания DeepSeek Harness для нескольких проектов — не «сколько репозиториев есть у команды», а «сколько задач одновременно удерживают процессы, сессии, инструменты и полномочия».

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

Когда один Mac действительно подходит

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

1. зависимости проектов близки и не требуют постоянного переключения версий;
2. задачи запускаются по очереди либо короткими сессиями;
3. данные имеют сопоставимый уровень чувствительности;
4. один сбой не остановит критичный процесс другого проекта.

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

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

Минимальная структура может выглядеть так:

mkdir -p ~/deepseek-workspaces/client-a
mkdir -p ~/deepseek-workspaces/internal-tools
mkdir -p ~/deepseek-sessions/client-a
mkdir -p ~/deepseek-sessions/internal-tools

export DSH_WORKSPACE="$HOME/deepseek-workspaces/client-a"
export DSH_SESSION_DIR="$HOME/deepseek-sessions/client-a"

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

printf 'workspace=%s\nsession_dir=%s\n' "$DSH_WORKSPACE" "$DSH_SESSION_DIR"
pwd
git rev-parse --show-toplevel

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

workspace=/Users/dev/deepseek-workspaces/client-a
session_dir=/Users/dev/deepseek-sessions/client-a
/Users/dev/deepseek-workspaces/client-a
/Users/dev/deepseek-workspaces/client-a

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

Параллельные задачи меняют решение

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

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

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

LOCK="$HOME/deepseek-sessions/client-a/.active"

if [ -e "$LOCK" ]; then
  echo "Сессия уже занята: $LOCK"
  exit 1
fi

trap 'rm -f "$LOCK"' EXIT
touch "$LOCK"

echo "Запуск разрешён только для client-a"

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

Вопросы данных и полномочий требуют отдельной границы

Код двух клиентов нельзя считать изолированным только потому, что он находится в папках client-a и client-b. Агент может использовать переменные окружения, сохранённые токены, журналы, MCP-серверы, SSH-ключи и общий профиль. Если эти элементы доступны одной и той же учётной записи, название каталога не создаёт полноценного разделения полномочий.

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

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

Практическая схема для общей машины:

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

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

env | grep -E '^(DEEPSEEK|DSH|SSH|MCP)_' | sed 's/=.*$/=<hidden>/'
security find-generic-password -s "deepseek-client-a" >/dev/null \
  && echo "Ключ client-a найден" \
  || echo "Ключ client-a отсутствует"

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

Для клиентских проектов отдельная среда обычно предпочтительнее общей, если выполняется хотя бы одно условие:

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

Это не означает, что отдельный Mac автоматически делает среду соответствующей требованиям комплаенса. Изоляцию нужно подтверждать настройками доступа, журналированием, процессом удаления данных и правилами восстановления. NIST отдельно подчёркивает необходимость принципов наименьших привилегий и разделения обязанностей для программных и AI-агентов. (nccoe.nist.gov)

Совместные плагины создают отдельную зону отказа

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

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

profiles/
├── stable/
│   ├── config
│   └── plugins.lock
└── experimental/
    ├── config
    └── plugins.lock

Перед обновлением следует сохранить:

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

Пример фиксации состояния:

mkdir -p ~/deepseek-backups/$(date +%Y-%m-%d)
cp -R ~/.deepseek/profiles \
  ~/deepseek-backups/$(date +%Y-%m-%d)/profiles

Если реализация DeepSeek Harness поддерживает генерацию конфигурации для разных профилей, профиль следует выбирать явно, а не полагаться на глобальное значение по умолчанию. В открытой реализации с CLI профиль определяет набор инструментов, а конфигурация MCP генерируется отдельно для каждого варианта; это хороший ориентир для проверки собственной схемы, но не доказательство того, что все сборки работают одинаково. (github.com)

Признак, что пора разделять среду, — не сам факт установки плагина, а невозможность быстро ответить на три вопроса:

1. какая версия изменилась;
2. какие проекты используют эту версию;
3. как вернуть прежнее состояние без остановки остальных задач.

Длительные агенты требуют отдельной ответственности

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

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

Для каждого длительного агента нужно заранее определить:

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

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

test -d "$DSH_WORKSPACE" || {
  echo "Рабочая область отсутствует"
  exit 1
}

git -C "$DSH_WORKSPACE" status --short
ps aux | grep -i '[d]eepseek'

Команда git status не гарантирует безопасность сама по себе, но помогает убедиться, что процесс обращается к ожидаемому репозиторию, а не к случайному каталогу.

Командный доступ нужно разделять по ролям

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

Перед передачей общего окружения следует письменно определить:

На macOS разные пользовательские учётные записи позволяют отделить домашние каталоги и связки ключей, но это не отменяет настройки самого агента и разрешений команд. Apple указывает, что Keychain работает в контексте пользователя, а отдельные приложения и процессы могут иметь разные условия доступа. (developer.apple.com)

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

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

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

Решение можно формализовать так:

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

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

Что выбрать для типовых комбинаций проектов

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

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

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

Плагин и стабильная автоматизация. Стабильный сценарий должен работать в неизменяемом профиле. Разработка плагина — в экспериментальной среде с копией рабочего пространства и заранее подготовленным откатом.

Главный недостаток схемы «один Mac для всего» — не обязательно недостаток производительности. Чаще опаснее смешение контекстов, неясная ответственность за ключи, общие журналы и расширенная зона отказа. Раздельное размещение, напротив, увеличивает число сред, но упрощает расследование, откат и передачу проекта другому специалисту.

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

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