Команда DeepSeek открыла агента для GitHub. Как он получает задачи

В открытом репозитории DeepSeek опубликован dsh-superagent — агент разработки для одного GitHub-репозитория. Он получает поручение из обсуждения, заводит отдельную задачу, работает в собственной сессии и каталоге, а затем отвечает в исходном разговоре, например ссылкой на pull request. Состояние работы и вопросы, требующие человека, выводятся в веб-панель.

Но README коммита от 31 октября начинается с ограничения: перед нами исследовательский прототип, а не официальный продукт DeepSeek. Он вырос из повседневной работы команды; значительную часть инженерной работы выполнили агенты. Авторы предупреждают об ошибках и неоднородных практиках разработки.

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

Прототип поставляется как набор для DeepSeek Harness. Основной источник событий — GitHub; дополнительно можно подключить Feishu, корпоративный мессенджер. В GitHub учитываются новые issues, pull requests, комментарии и CI основной ветки. Для Feishu правила задаются отдельно для настроенных чатов, других чатов с упоминаниями и личных сообщений.

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

При подготовке к публикации реализацию изменили. Она не совпадает полностью ни с внутренней версией команды, ни с описанием в статье Exploring Super-agent Design. Часть обсуждаемых там идей остаётся направлением будущей работы.

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

В документации есть три уровня сигнала:

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

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

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

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

Бот из разрешённого списка может породить предполагаемую задачу. Он не может сделать явное поручение или остановить работу. А автоматический ревьюер с обычной пользовательской учётной записью технически распознаётся как человек; команда должна явно объяснить агенту, что это автоматический источник.

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

Режимов три:

Авторы рекомендуют начинать с observe и переходить к auto после просмотра решений. По карточке разрешено сразу игнорировать явно посторонний текст; принять предполагаемую работу без полной оценки нельзя. Маршрутизация явных поручений допускает несколько независимых решений за вызов: ошибка одного не должна блокировать остальные.

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

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

Человеческое «стоп» в обсуждении проходит разбор как событие. Кнопка остановки в панели является непосредственной командой. Остановленная человеком задача больше не получает продолжений; новая работа требует нового принятия. Боты и CI сами не будят завершённую задачу.

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

Настройка описана в SETUP.md: предполагается помощь агента, короткие вопросы по одному и полный план перед установкой. Документы предлагают читать последовательно: философия, модель предметной области, авторизация, исполнение, промпты, панель, развёртывание, архитектура, добавление источника. В репозитории указана лицензия MIT и команда pnpm check для проверки типов, тестов и сборки.

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

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