Команда DeepSeek Harness открыла код прототипа постоянно работающего coding-агента

Прототип dsh-superagent-prototype оформлен как дополнение к DeepSeek Harness для работы с одним GitHub-репозиторием. Он получает события из GitHub и, при настройке, из Feishu. Когда пользователь с разрешённым доступом просит выполнить работу, система создаёт задачу, запускает для неё отдельную сессию и рабочую директорию, а затем отвечает в исходном разговоре – например, ссылкой на pull request. Это исследовательский код под лицензией MIT, а не готовый продукт DeepSeek; часть идей из опубликованной архитектуры в репозитории ещё не реализована.

Архитектура разделяет общение и выполнение. Постоянная сессия Router принимает обращения из разных каналов и распределяет задачи, но сама не правит код. Worker-сессии получают инструменты для работы и ведут задачи параллельно в изолированных контекстах. Результаты они возвращают Router, который уже отвечает пользователю. Так команда пытается сохранить общую нить разговора, не заставляя одну сессию по очереди выполнять все запросы.

Отдельные Worker подписываются на связанные с их задачей треды, например обсуждение pull request. Новые комментарии по такому треду поступают исполнителю напрямую, без повторного решения Router о том, кому их передать. Система также реагирует на события среды: сообщения в чате, комментарии к коду и результаты CI-проверок могут запускать работу. Сначала события отбирает обычный программный фильтр, затем их оценивает модель. Внутри команды агент по заданному правилу пробует воспроизводить сообщения об ошибках и сообщает о них, когда находит простое исправление.

В предварительном тесте на искусственной нагрузке примерно из 300 сообщений и 20 запросов на работу половина задач завершилась за 12,4 минуты, а 95% – за 15,7 минуты. Прямые подписки Worker снизили число решений Router: без них оно выросло примерно на 30%. Пакетная обработка входящих событий сократила время инференса в расчёте на одно решение Router с 6,4 до 1,6 секунды. Сравнение с одной сессией и инструментом subagent оказалось в пользу прототипа по времени, но потребовало больше кэшированных токенов.

В схему входят и более сложные части: состояние агента отделено от среды выполнения, чтобы облачная сессия могла работать с пользовательскими машинами, а внешний Watchdog следит за прогрессом Worker. Команда пока относит к открытым вопросам масштабирование Router, долговременную память и защиту от prompt injection. Последнее особенно существенно при доступе облачного агента к локальным устройствам и учётным данным: событие, пришедшее извне, может содержать инструкцию, которой агенту следовать нельзя.