Команда 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. Доставка обходит входной фильтр, но не расширяет полномочия задачи. Исполнитель решает, укладывается ли продолжение в его текущий объём. Если текст требует другой работы, он возвращает его на маршрутизацию. Новая оценка начинается после того, как сообщение больше не принадлежит ни одному исполнителю. Подписку при этом можно сохранить: следить за контекстом и брать новое поручение — разные действия. Важная деталь: исполнителю может принадлежать сообщение даже после удаления подписки, пока задача остаётся живой. Для связанных обсуждений предусмотрены и подписки только ради контекста. Сообщения оттуда не дают права возобновлять завершённую работу, пока основная сессия не прикрепит их к задаче. Бот из разрешённого списка может породить предполагаемую задачу. Он не может сделать явное поручение или остановить работу. А автоматический ревьюер с обычной пользовательской учётной записью технически распознаётся как человек; команда должна явно объяснить агенту, что это автоматический источник. При запуске предполагаемой задачи агент проверяет все включённые правила. Для автоматического принятия должно совпасть хотя…
Источник: dtf.ru — dtf.ru/chatgpt/5390542-agent-deepseek-dlya-github
