Super-agent от DeepSeek сам чинит баги, замеченные в чате

Команда DeepSeek Harness 31 октября описала в посте DeepSeek в WeChat Super-agent: агента, который постоянно сидит в рабочих чатах и на GitHub, сам замечает баги в переписке и присылает пул-реквест с исправлением, даже если его никто не звал. Запустить из этого сейчас можно только исследовательский прототип под лицензией MIT, который поверх DeepSeek Harness разбирает issues и пул-реквесты одного репозитория, а в DeepSeek оговариваются, что текст посвящён архитектуре и функции Harness не описывает.

Bloomberg подал новость как выпуск открытого соперника Claude Code. Репозиторий dsh-superagent-prototype открывается другой фразой: «Исследовательский прототип, только для ознакомления, не официальный продукт DeepSeek». Часть того, что описано в посте, в код ещё не попала.

Что можно запустить

Прототип собран как набор для DeepSeek Harness, среды исполнения агентов на Node.js, которую DeepSeek выложила под MIT в августе в статусе превью для разработчиков. Прототип слушает GitHub и, если подключить, Feishu, а разрешённые запросы превращает в параллельные задачи, каждая в своей агентской сессии.

Как уточняет MarkTechPost, инициативу агента ограничивают три режима приёма задач: off, observe и auto. По умолчанию включён observe, и в нём агент только записывает, что взял бы в работу; shell-команды через 5 секунд уходят в фон. Тем, кто хочет увидеть, как агент сам берётся за задачи, придётся переключить режим на auto.

В самой Harness уже реализован асинхронный цикл агента, но по умолчанию он выключен. Долгие команды и подзадачи запускаются через start(), который сразу возвращает «Started», результат потом приходит в сессию отдельным событием, а stop() гасит то, что выполняется слишком долго. Пока фоновая задача идёт, агент принимает новые сообщения.

Router вместо сессий

DeepSeek отталкивается от наблюдения, что человек обычно одновременно ведёт 3-5 активных сессий с агентами. Потолок одной задачи задаёт модель, потолок многих задач - внимание человека. «Сессия должна быть деталью реализации системы, а не когнитивной нагрузкой для пользователя», - пишут авторы.

Поэтому сессии спрятаны за двумя слоями. Постоянный Router принимает всё общение с людьми и только раздаёт работу: сам задачи не выполняет и может даже не иметь доступа к Bash. По опыту команды, ему часто хватает облегчённой модели. Worker-сессии изолированы друг от друга, каждая ведёт одну задачу на самой сильной модели и отчитывается Router, а в чат напрямую не пишет. Для мессенджеров действует жёсткое правило: не больше 100 слов в ответе.

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

Сообщения в чатах, письма, напоминания календаря, комментарии к ревью и результаты CI система называет Trigger. Сначала их фильтрует код по источнику, группе и белым спискам, и лишь оставшееся смотрит модель. Когда Router создаёт Worker под ветку событий (пул-реквест, тему в мессенджере, цепочку писем), тот подписывается на неё, и дальнейшие события по ветке идут к нему напрямую, минуя Router. Подписки многие-ко-многим: два Worker в одном пул-реквесте видят одни и те же события и могут сами разрулить конфликт.

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

Цикл агента крутится в облаке в контейнерах без состояния, сессии лежат в базе данных, а репозиторий, файлы и тулчейн остаются на машине пользователя за лёгким демоном, который только выполняет команды и возвращает результат. Когда личное устройство пользователя снова выходит в сеть, облачный агент может сам запустить и доделать задачу, которую нужно выполнить именно на нём. Сами авторы сравнивают схему с идеей Anthropic отделить «мозг» от «рук»; разница, по их словам, в том, что текст Anthropic про управляемый сервис с песочницами, а DeepSeek в первую очередь подключает личные машины с незакоммиченными правками и локальными ключами. За всем следит отдельная сессия Watchdog: по расписанию она проверяет, продвигаются ли Worker или ходят по кругу, а по просьбе мейнтейнеров может на ходу править промпты и правила срабатывания.

Тест на синтетике

Систему гоняли на потоках из группового чата и GitHub CI: около 300 сообщений за прогон, из них примерно 20 рабочих запросов, остальное болтовня, уточнения, просьбы остановиться и сообщения CI. Сравнивали четыре схемы, каждую по 5 раз: Super-agent, Super-agent без прямой доставки событий в Worker и одну сессию с инструментом субагентов при двух вариантах промпта, нейтральном и с просьбой чаще делегировать. По 95-му перцентилю Super-agent уложился в 15,7 минуты, одна сессия с субагентами и нейтральным промптом - в 29,5.

Код в этом тесте никто не писал: вместо кодинга стоял инструмент, который просто тратит время, и качество реальных исправлений не измеряли. Цифры описывают только то, как быстро система раздаёт и сводит задачи, и авторы сами просят считать их предварительными.

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