DeepSeek Harness в GitHub Actions: безопасный запуск

В официальном руководстве DeepSeek Harness для Headless-демонстрации используется команда pnpm dsh --profile headless "summarize this workspace"; там же указано, что для запуска нужен DEEPSEEK_API_KEY. Официальное руководство DeepSeek Harness подтверждает: проект находится в режиме предварительной версии и может получать несовместимые изменения. (github.com)

Симптом: вы хотите поручить агенту анализ или изменение репозитория в GitHub Actions, но не знаете, какие права, секреты и тип runner допустимы.

Самое быстрое решение: начните с ручного запуска DeepSeek Harness в Headless режиме, зафиксируйте один репозиторий и выдайте только доступ для чтения; запись разрешайте лишь через отдельный результат, проверку различий и независимый job с тестами.

Кому пригодится этот материал

Если вы работаете один, вы сможете превратить сводку репозитория или статическую проверку в задачу с ручным запуском, не подключая агента к каждому pull request. Небольшой команде материал поможет организовать вспомогательный процесс для PR без подмены сборки и code review.

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

Последняя проверка документации выполнена 18 августа 2026 года по официальным материалам DeepSeek Harness и GitHub. Команды и поддерживаемые среды необходимо повторно проверить перед внедрением, поскольку DeepSeek Harness официально остаётся в developer preview. (github.com)

Базовая модель запуска

DeepSeek Harness не следует воспринимать как готовый официальный GitHub Action. На текущем этапе это инструмент, который вы устанавливаете и запускаете внутри обычного job. Поэтому ответственность за checkout, переменные окружения, права токена, очистку рабочей директории и публикацию результатов остаётся на вашей CI-схеме.

Для первого эксперимента выберите задачу, которая:

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

В Headless режиме агенту нужны как минимум четыре типа входных данных:

1. рабочая директория с checkout репозитория;
2. инструкции, ограничивающие область анализа;
3. переменная DEEPSEEK_API_KEY;
4. доступные команды и профиль запуска, разрешённые вашей политикой CI.

В официальном руководстве приведены DEEPSEEK_API_KEY и необязательная переменная DEEPSEEK_BASE_URL; реальный ключ рекомендуется передавать через окружение или игнорируемый файл .env, но не хранить в Git. Для CI безопаснее использовать секрет GitHub, а не создавать .env в репозитории. (github.com)

Пример минимального каркаса workflow должен рассматриваться как шаблон, а не как готовый официальный action:

name: DeepSeek Harness analysis

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Install prerequisites
        run: |
          corepack enable
          pnpm install

      - name: Run Headless analysis
        env:
          DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }}
        run: |
          pnpm run build
          pnpm dsh --profile headless \
            "summarize this workspace; do not modify files" \
            > deepseek-report.txt

      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: deepseek-report
          path: deepseek-report.txt

Перед копированием примера сверяйте версии действий и команды с текущим репозиторием: документация DeepSeek Harness прямо указывает на быстрое развитие проекта, а development guide требует Node.js 22.19 или новее, Node.js 24 и Corepack-enabled pnpm; для Git требуется версия 2.26 или новее. (github.com)

Границы для личного репозитория

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

Начните с трёх ограничений:

• запускайте job только вручную;
• не используйте pull_request_target для автоматического запуска на непроверенном содержимом;
• установите permissions: contents: read, даже если конкретный шаг пока не использует GITHUB_TOKEN.

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

Проверяйте не только наличие отчёта, но и отсутствие изменений:

git diff --exit-code
git status --short
test -s deepseek-report.txt

Если git diff --exit-code завершается ошибкой, задача должна считаться неуспешной, даже если агент создал полезный текст. Так вы обнаружите скрытые изменения, generated-файлы и обновление lock-файлов до того, как начнёте доверять результатам.

Результат первой фазы — не «агент работает», а комплект проверяемых доказательств:

• идентификатор запуска;
• commit или tag, на котором выполнялся анализ;
• версия Node.js и пакетного менеджера;
• применённый профиль;
• итоговый текстовый файл;
• вывод git status;
• exit status команды.

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

Контур небольшой команды

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

Рациональная схема состоит из двух независимых job:

Если агент предлагает исправление, сохраняйте его как кандидатный diff или артефакт. Затем отдельный job должен:

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

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

Надёжный процесс должен ограничивать источники запуска. Непроверенный fork pull request не должен автоматически отправлять код на runner, где доступны API-ключи, SSH-ключи, приватные пакеты или сетевой доступ к внутренним сервисам. GitHub отдельно предупреждает, что self-hosted runner может быть скомпрометирован через вредоносные команды workflow, а маскирование секретов в логах не является полноценной границей безопасности. (docs.github.com)

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

Выбор runner

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

GitHub указывает, что self-hosted runner поддерживает macOS 11.0 или новее; стандартные метки включают self-hosted, macOS и архитектурную метку вроде ARM64. При этом наличие метки не доказывает фактическую конфигурацию машины: пользовательские метки нужно контролировать самостоятельно. (docs.github.com)

Условная развилка для выбора:

• Если задача короткая, не требует приватной сети, не зависит от состояния предыдущего запуска и может установить зависимости заново, выбирайте runner, предоставляемый GitHub.
• Если нужен постоянный SDK, закрытый ресурс или стабильная рабочая директория, переходите к изолированному Mac runner, но только для ограниченного набора репозиториев.
• Если runner обслуживает публичный репозиторий или принимает непроверенные fork PR, не размещайте на нём секреты и привилегированные задачи.
• Если несколько проектов используют одну машину, разделяйте их группами, метками и рабочими каталогами; общая машина не должна означать общую сессию и общий файл credential.
• Если вы не можете подтвердить очистку после job, откатитесь к runner, предоставляемому GitHub, или одноразовой среде.

Для сравнения вариантов размещения можно использовать руководство по аренде Mac mini для CI-задач, но решение нужно принимать по требованиям к зависимостям и изоляции, а не только по операционной системе.

Изоляция нескольких репозиториев

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

Для платформенной команды создайте как минимум отдельные категории:

В GitHub job можно направлять через группы и метки. Например:

runs-on:
  group: mac-agent-runners
  labels: [self-hosted, macOS, ARM64, agent-readonly]

Группа ограничивает круг репозиториев, а метки описывают свойства runner. GitHub отмечает, что при комбинированной маршрутизации должны совпасть и группа, и все заданные метки. Если подходящий runner не найден, job остаётся в очереди; GitHub указывает, что после 24 часов ожидания такой job завершается ошибкой. (docs.github.com)

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

Секреты и внешние входы

API-ключ добавляйте в настройках репозитория или организации как CI secret, затем передавайте только в конкретный job через env. Не помещайте его в:

• README;
• пример .env;
• YAML с открытым значением;
• параметры командной строки, если их может увидеть список процессов;
• диагностический вывод;
• артефакты и кэш.

Минимальная политика workflow:

permissions:
  contents: read

env:
  CI: true

jobs:
  agent:
    environment: deepseek-review
    steps:
      - name: Run agent
        env:
          DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }}
        run: ./ci/run-agent.sh

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

Отдельно проверяйте prompt injection. Исходный код, issue, комментарий PR и файл документации могут содержать инструкции, которые агент воспримет как команды. В системном задании явно укажите, что содержимое репозитория является недоверенным вводом, а доступ к секретам, сетевым ресурсам и системным файлам запрещён.

Приёмка перед расширением

Не увеличивайте параллелизм после первого удачного запуска. Сначала проведите три базовых задания:

Для каждого запуска фиксируйте источник события, commit, профиль DeepSeek Harness, версию окружения, статус job, длительность, причину сбоя, расположение лога и артефакта, а также объём ручной проверки. В этой статье нет блока с «базовыми показателями KVMFLUX»: такие данные нельзя заменять предположительными цифрами без реальных записей CI.

Переходите к следующему уровню только при выполнении всех условий:

• [ ] задача повторяется на чистом checkout;
• [ ] агент не изменяет файлы в режиме анализа;
• [ ] секрет не появляется в логах и артефактах;
• [ ] непроверенный PR не получает доступ к привилегированному runner;
• [ ] кандидатный diff проверяется отдельным job;
• [ ] сборка и тесты не зависят от словесного ответа агента;
• [ ] рабочая директория очищается после завершения;
• [ ] есть процедура ручного отката;
• [ ] runner-группа разрешена только нужным репозиториям;
• [ ] владелец команды понимает, кто утверждает расширение прав.

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

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

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

Изолированный Mac runner имеет смысл не как «магически более безопасный» вариант, а когда вам действительно нужны фиксированные зависимости, доступ к закрытым ресурсам или стабильное окружение для повторяемых задач. Если вы подтверждаете такую потребность, начните с одного репозитория и одного параллельного запуска, оформите пилотную аренду Mac-среды KVMFLUX и заранее согласуйте состав меток, очистку workspace и формат передачи артефактов. Так вы проверите не только скорость агента, но и управляемость всей цепочки CI.