DeepSeek Super-agent: настройка и работа Router/Worker

Запускайте DeepSeek Super-agent сначала на одном репозитории, с одним разрешённым пользователем и отдельной учётной записью ОС. Диспетчер Router создаёт из разрешённых запросов задачи Ticket, а исполнители Worker работают в отдельных сессиях и каталогах. Начните с режима observe, но учтите: прямые запросы он не блокирует.

По состоянию на 2026-11-09 dsh-superagent-prototype — исследовательский прототип, а не официальный продукт DeepSeek или готовый к промышленной эксплуатации сервис. В манифесте пакета указаны версия 0.1.0 и лицензия MIT. Публичный код отличается от внутренней системы команды и реализации, описанной в статье о проектировании.

Как работают Router, Ticket и Worker

Основное отличие — постоянный приём задач из репозитория, а не новая модель или интерфейс для написания кода. Пакет расширений работает внутри DeepSeek Harness, отслеживает один репозиторий GitHub и при необходимости принимает сообщения из Feishu.

Предметная модель отделяет входящие события от разрешённых задач. Механизм оценки Eval решает, достаточно ли оснований создать новый Ticket. Каждый принятый Ticket получает Mandate — запись с основанием разрешения и границами задачи.

Router — основная сессия агента, которая решает, какие запросы направить на выполнение. Worker выполняет принятую задачу. В настройках такой исполнитель обозначен как Executor.

У каждого Worker собственная сессия и рабочий каталог. Результат возвращается в исходное обсуждение, например комментарием GitHub со ссылкой на pull request (PR). Отдельный каталог разделяет рабочие копии, но не ограничивает доступ процесса к файлам.

Например, два несвязанных сообщения об ошибках могут превратиться в отдельные Ticket, а не попасть в одну сессию. Это полезно, когда распределение входящих задач требует больше внимания, чем запуск отдельного агента.

Для одной правки в диалоге оставьте привычного агента. Для ограниченного делегирования начните с субагентов Claude Code только для чтения с явным выбором модели.

Почему режим observe не заменяет песочницу

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

В observe положительная оценка инициативной задачи сохраняется как «would accept», но не запускает работу. В auto такая оценка может привести к принятию задачи. Пользователь из списка разрешённых может обратиться к агенту и поставить задачу в любом режиме.

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

Что означает danger-full-access

Выделите учётную запись ОС, в которой будут только учётные данные агента. Предупреждение об изоляции в инструкции развёртывания относится к обоим пресетам: dsh-superagent-router и dsh-superagent-worker. Они работают от имени пользователя ОС с уровнем доступа danger-full-access.

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

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

Профиль Harness тоже должен быть отдельным. Расширение меняет PATH и настройки git для всего процесса. Оставьте привязку панели к 127.0.0.1 и не открывайте этот пробный сервис в интернет.

Пробный запуск с GitHub

Выполните ручную установку под новой учётной записью и с новым профилем. В репозитории также есть SETUP.md для настройки вместе с агентом.

Проверьте требования

Установите Node.js 22.19+ или 24+, pnpm, git 2.32+, Python 3.8+, tmux и GitHub CLI 2.48+. Это требования из документации.

Нужны также репозиторий на github.com и провайдер моделей для DeepSeek Harness. GitHub Enterprise Server не поддерживается. Установите git-lfs, если репозиторий использует Git LFS.

Подготовьте непустой тестовый репозиторий с README.md. Для первой проверки лучше закрытый репозиторий, доступный только вам и агенту.

Feishu необязателен и в этой проверке не используется. Для его подключения нужны приложение Feishu или Lark с ботом и lark-cli. В документации указана проверенная проектом версия 1.0.90.

Войдите под учётной записью агента

Создайте отдельного пользователя GitHub и дайте ему право записи в тестовый репозиторий. Выполняйте команды в Bash под выделенной учётной записью ОС.

unset GH_TOKEN GITHUB_TOKEN
gh auth login --hostname github.com --git-protocol https
gh api user --jq .login
gh auth setup-git --hostname github.com

Пройдите интерактивный вход GitHub CLI под аккаунтом агента. Команда gh api должна показать его логин. Сброс двух переменных исключает подмену сохранённого входа учётными данными из окружения.

Отдельная команда gh auth setup-git настраивает Git на получение учётных данных через GitHub CLI. Это важно: команда подготовки и отправка веток вызывают Git напрямую.

Создайте локальный клон по документированному синтаксису GitHub CLI:

read -r -p "Repository (owner/name): " TARGET_REPOSITORY
mkdir -p "$HOME/src"
gh repo clone "$TARGET_REPOSITORY" "$HOME/src/superagent-target"

Затем проверьте доступ по HTTPS отдельно от gh api:

GIT_TERMINAL_PROMPT=0 git ls-remote \
  "https://github.com/$TARGET_REPOSITORY.git" HEAD

GIT_TERMINAL_PROMPT=0 git -C "$HOME/src/superagent-target" push --dry-run \
  "https://github.com/$TARGET_REPOSITORY.git" \
  HEAD:refs/heads/agent-auth-check

Команда git ls-remote должна вернуть HEAD удалённого репозитория. Для открытого репозитория такое чтение может пройти без авторизации. Команда push --dry-run проверяет подключение для отправки, не меняя удалённые ссылки Git.

Обе команды должны завершиться успешно. Окончательная проверка — реальная отправка ветки агентом при создании PR на следующем этапе.

Здесь gh используется напрямую, поскольку вся учётная запись ОС выделена агенту. Не используйте конфигурацию gh из личной учётной записи с несколькими GitHub-аккаунтами.

Создайте отдельный профиль Harness

Используйте версию Harness из инструкции развёртывания: 0.2.1-rc.3. В манифесте расширения для engines.dsh задан диапазон ^0.2.1-alpha.2.

Задайте DSH_HOME до первой команды dsh. Справочник CLI для этой версии размещает именованные профили в $DSH_HOME/profiles/<name>. Для этого пробного запуска явно выбираем каталог $HOME/.dsh.

Следующие команды Bash предназначены только для новой установки:

export DSH_HOME="$HOME/.dsh"

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype
pnpm install
pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

Не запускайте команду создания профиля повторно для существующей установки. Она заменяет профиль и удаляет его cordis.patch.yml. Для обновления используйте соответствующий раздел инструкции развёртывания.

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

test -f "$DSH_HOME/profiles/superagent/package.json" || exit 1

cat > "$DSH_HOME/profiles/superagent/cordis.patch.yml" <<EOF
- id: webserver
  config:
    host: 127.0.0.1
    port: 3082
- id: dsh-superagent
  config:
    stateDir: "$DSH_HOME/state/superagent"
EOF

if tmux list-sessions >/dev/null 2>&1; then
  tmux set-environment -g DSH_HOME "$DSH_HOME"
  if tmux has-session -t '=dsh-superagent' 2>/dev/null; then
    tmux set-environment -t '=dsh-superagent' DSH_HOME "$DSH_HOME"
  fi
fi

scripts/dsh-superagent start
scripts/dsh-superagent status

Скрипт сервиса запускает dsh --profile superagent через tmux. Новый сервер tmux наследует экспортированные переменные среды. Код выше также обновляет окружение tmux уже работающего сервера или сессии.

Откройте http://127.0.0.1:3082 в браузере на машине сервера. В настройках Harness команда Open configuration file должна открыть указанный выше путь superagent/cordis.patch.yml. Если открывается другой файл, остановитесь. После добавления настроек провайдера не перезаписывайте этот патч.

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

Настройте приём запросов и рабочие деревья для Ticket

Откройте Superagent → Settings и используйте группы настроек из документации.

В Sources → GitHub укажите репозиторий в виде owner/name и задайте gh как CLI агента. Оставьте выключенными переключатели приёма всех Issues, pull requests, комментариев и событий CI основной ветки. Feishu тоже оставьте выключенным.

В Eval → On each Source → GitHub поле GitHub accounts that may originate work должно содержать только ваш личный логин GitHub. Удалите остальные записи, а список ботов оставьте пустым. Во всех видимых ячейках допуска для пользователей вне списка установите ignore, включая ячейки прямых обращений к агенту. Сохраните настройки с режимом observe.

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

В Execution для пробы установите параллелизм 1. Корневой каталог оставьте по умолчанию. Следующий код вставьте в поле команды подготовки. Она выполняется через sh; синтаксис подходит и для Bash.

git -C "$HOME/src/superagent-target" fetch --no-tags \
  "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C "$HOME/src/superagent-target" worktree add \
  -b "agent/$DSH_SUPERAGENT_NAME" \
  "$DSH_SUPERAGENT_DIR" \
  "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"

В примере из документации заменён путь клона на каталог, созданный выше. Команда загружает нужный коммит, затем создаёт ветку и рабочее дерево Ticket. Без команды подготовки Worker начинает работу в пустом каталоге.

В Prompts укажите автора коммитов и подпись, которая сообщает об участии агента. Потребуйте ручного слияния PR и не добавляйте отдельную учётную запись для слияния. Инструкции в промпте направляют агента, но не заменяют защиту репозитория.

Можно ли выбрать другую модель?

Да: через провайдеров, настроенных в DeepSeek Harness. Следующие действия описаны в руководстве по провайдерам для тега dsh-v0.2.1-rc.3, который соответствует установленной версии.

Откройте Settings → Models в Harness. Введите и сохраните API-ключ в карточке DeepSeek либо выберите Add model provider для другого поддерживаемого провайдера. Вводите учётные данные локально в этом интерфейсе, а не в обсуждении GitHub.

Для Custom model API задайте Provider ID в нижнем регистре и базовый URL. Затем укажите подходящий протокол API, учётные данные и хотя бы одну модель. Берите значения из документации провайдера. Сохранённая конфигурация ещё не подтверждает, что модель умеет выполнять нужные вызовы инструментов.

Через Choose workspace добавьте и выберите $HOME/src/superagent-target, как показано в руководстве по веб-интерфейсу для этой версии. Запустите обычную сессию и выберите настроенную модель в переключателе моделей. Этот выбор задаёт модель по умолчанию для новых сессий.

Откройте ещё одну новую сессию. Перед отправкой запроса проверьте, что в ней выбраны тот же провайдер и та же модель. Попросите прочитать README.md и вернуть первый заголовок без правок. Сверьте ответ с файлом. Не выбирайте для проверки ни один из служебных пресетов dsh-superagent-*.

Затем явно выберите проверенные провайдер и модель в Superagent → Settings → Eval и Execution. Eval задаёт модель для Router и оценки запросов; Execution — для Worker. Так пробный запуск не зависит от непроверенного значения по умолчанию. Оставлять эти поля пустыми стоит только после проверки модели профиля по умолчанию.

Модель Executor закрепляется при создании сессии. Уже открытые сессии Worker сохраняют свою модель, а Retry повторно использует ту же сессию. Последующую смену модели проверяйте на новом Ticket.

Как проверить запрос и найти причину сбоя

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

Снова выполните scripts/dsh-superagent status. Убедитесь, что код завершения равен 0 и ошибок настройки нет. Оставьте новый комментарий в issue от разрешённого пользователя. Вместо @AGENT_LOGIN укажите логин агента:

@AGENT_LOGIN Read README.md and reply here with its first heading.
Do not edit files, push a branch, or open a pull request.

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

После успешной проверки поручите небольшую правку документации и создание PR для ручного ревью. Убедитесь, что ветка действительно отправлена на GitHub, PR создан от аккаунта агента, а diff не выходит за пределы задания. Это критерии приёмки вашей установки, а не гарантия результата модели.

Если Ticket не появился, проверьте логин в списке, ячейки допуска, репозиторий и состояние источника GitHub. Затем оставьте новый комментарий с упоминанием агента.

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

Для временных сбоев модели или сети руководство по выполнению предусматривает три повтора с растущей задержкой. К таким сбоям относятся коды HTTP 408, 429 и 5xx. Ошибки команды подготовки под этот автоматический повтор не подпадают.

Как восстановиться после сбоя команды подготовки

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

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

Если каталог существует, скопируйте его путь из карточки Ticket и проверьте каталог в Bash:

read -r -p "Ticket directory (absolute path): " TICKET_DIR
git -C "$TICKET_DIR" rev-parse --show-toplevel
git -C "$TICKET_DIR" status --short --branch

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

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

Если Ticket помечен как завершившийся с ошибкой, сообщения CI и ботов не возобновляют работу Worker. Требуется действие человека. Закончив проверку, остановите сервис:

scripts/dsh-superagent stop

Когда оставлять сервис включённым

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

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

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