DeepSeek Harness описала Super-agent — систему, которая подхватывает задачи из рабочих каналов и распределяет их между агентами. В синтетическом тесте 95% задач завершились за 15,7 минуты. Замер предварительный, а код на GitHub — исследовательский прототип, пока не готовый продукт.
О проекте написало китайское издание 字母AI с разрешения 钛媒体. Команда считает, что в работе с агентами всё чаще мешает внимание человека: приходится следить за каждой задачей и всеми сессиями.
Super-agent передаёт системе управление задачами и сессиями
Обычный агент работает в отдельной сессии — собственном контексте задачи. Если обсуждение переходит из чата в GitHub, человеку часто нужно переносить детали и объяснять всё заново. По оценке DeepSeek Harness, человек обычно может следить за 3–5 активными сессиями одновременно.
Добавить агентов недостаточно. Если один агент чинит баг, пишет отчёт и отвечает на сообщения, задачи начинают мешать друг другу. Если запускать их отдельно, кому-то нужно раздавать работу, проверять прогресс и собирать результаты. Обычно этим занимается человек.
У Super-agent два уровня. Router принимает сообщения, хранит общий контекст и решает, кому передать задачу. Сам он работу не выполняет. Worker получает конкретную задачу и ведёт её в собственном контексте и рабочей директории. Так несколько Worker могут работать параллельно и не смешивать детали.
- Router распределяет задачи и остаётся основным собеседником человека.
- Worker выполняет конкретную работу в отдельной сессии.
- Связанные сообщения могут поступать Worker напрямую, без повторной маршрутизации.
- Человек получает готовый результат или решает вопрос, который нельзя безопасно закрыть автоматически.
В этой схеме Router не планирует каждый шаг Worker и не согласовывает действия на каждом этапе. Он передаёт работу, а Worker остаются изолированными друг от друга. Если в обсуждении появляется новое сообщение — например, комментарий к задаче, — его можно отправить исполнителю напрямую.
Для креатора такой принцип можно представить так: один агент следит за входящими задачами, а отдельные исполнители готовят раскадровку, собирают варианты текста или проверяют файлы. Это пример архитектуры, а не готовая функция опубликованного прототипа DeepSeek.
Агент сам ищет работу, но сначала проходит два фильтра
Внутренний пример DeepSeek — сообщение о баге в групповом чате. Человеку не нужно специально упоминать агента. Сначала система проверяет сообщение по заданным правилам, затем модель оценивает, действительно ли там описана проблема. Если задача подходит под разрешённый сценарий, Router передаёт её Worker.
Worker пытается воспроизвести ошибку и найти исправление. Если не справляется или решение кажется сложным, агент не обязан слать поток промежуточных сообщений. Если баг подтвердился и исправление простое, система может подготовить Pull Request на проверку человеку.
Фильтрация проходит в два этапа. Сначала код отсекает неподходящие источники и события — например, лишние каналы. Затем модель разбирает оставшиеся сообщения по смыслу. Иначе каждую реплику из чата пришлось бы отправлять в модель: это дорого и медленно.
Самостоятельные действия разрешены, если человек попросил о них или команда заранее описала такое правило. Перенося идею в рабочий процесс, стоит чётко обозначить границы: что агент может сделать сам, где должен остановиться и какой результат показать человеку.
Главная функция Super-agent — не создавать лишние уведомления
В README прототипа команда описывает цель так: «как можно меньше занимать человеческого внимания и как можно больше приносить пользы» — перевод с китайского и английского описания. Сообщения агента тоже расходуют внимание. Если результата ещё нет и решение человека не требуется, система может продолжать работу молча.
Допустим, агент сразу пишет: «Принял, разбираюсь», потом присылает несколько отчётов и в конце сообщает, что баг не воспроизвёлся. В другой схеме он сначала работает в фоне, а пишет, когда нашёл результат или без человека не обойтись. В первом случае видно, что агент занят. Во втором у человека меньше возни.
Информация, которую производит агент, ещё не равна ценности, которую он приносит.
Похожую идею развивает Anthropic в Claude Duet. Это отдельный продукт в исследовательском превью, а не та же архитектура. По описанию Anthropic, Duet может собирать утреннюю сводку и обращаться к пользователю в течение дня, когда нужно его внимание. Перед отправкой сообщения, платежом, подписанием документа или удалением он должен запросить подтверждение. Превью доступно по листу ожидания для части подписчиков в США.
Инициатива полезна, когда агент не вмешивается без причины. Для креатора это вполне практично: агент может следить за входящими запросами или комментариями, но не должен сам отправлять клиенту финальный текст, публиковать материал или менять проект без чётко заданных прав.
Тест показал выигрыш во времени, но не доказал качество кода
В опубликованных результатах DeepSeek описан синтетический сценарий: около 300 сообщений и 20 рабочих запросов. Это не тест на реальной команде и не оценка качества готовых исправлений.
| Показатель | Super-agent | Сравнение или условие |
|---|---|---|
| Медианное время выполнения задач | 12,4 минуты | Синтетическая нагрузка |
| Время выполнения 95% задач | 15,7 минуты | Синтетическая нагрузка |
| Время p95 у одного агента с Subagent | 29,5 минуты | Сравнение в тесте |
| Решения Router без прямой передачи продолжений | примерно на 30% больше | Сравнение с маршрутизацией продолжений напрямую |
| Токены чтения кэша без прямой передачи продолжений | 31,77 млн | Было 23,23 млн |
| Время вывода на решение Router при пакетной обработке | 1,6 секунды | Было 6,4 секунды |
В предварительном тесте Super-agent быстрее дошёл до результата на 95-м перцентиле, чем схема с одним агентом и инструментом Subagent. За скорость пришлось заплатить: без прямой передачи продолжений Router принимал примерно на 30% больше решений, а число токенов чтения кэша выросло с 23,23 млн до 31,77 млн.
Пакетная обработка сократила время вывода одного решения Router с 6,4 до 1,6 секунды. Получается, система может ускорить работу, но расходовать больше токенов и переносить часть управления с человека на инфраструктуру.
Прототип подходит для изучения, а не для бездумного запуска
Репозиторий dsh-superagent-prototype рассчитан на один GitHub-репозиторий и может подключать Feishu. README называет его исследовательским кодом, не готовым официальным продуктом DeepSeek. Часть идей из технической статьи в прототипе ещё не реализована. Для установки нужно отдельно настроить DeepSeek Harness и рабочее окружение. Кнопки «подключить AI к команде» тут нет.
Перед экспериментом с такой схемой я бы проверил четыре вещи:
- Какие чаты, репозитории и типы событий агент видит.
- Какие действия разрешены автоматически, а для каких нужно подтверждение.
- Кто проверяет результат и как остановить фоновую задачу.
- К каким секретам, локальным файлам и учётным записям есть доступ у агента.
Последний пункт не для галочки. Среди открытых проблем отдельно упомянут риск prompt injection: облачный агент может столкнуться с вредоносной инструкцией, имея доступ к учётным данным на локальных устройствах. Работа в фоне удобна, но из-за неё ошибка или неверное разрешение могут обойтись дороже.
Для творческой команды уже можно взять на заметку несколько идей: отдельно поручить диспетчеризацию и исполнение, давать задачам собственный контекст, уведомлять человека о результате, блокере или необходимости принять решение. Прототип DeepSeek пока заточен под разработку и GitHub.
В этой системе человек меньше следит за агентами и больше принимает решения. Тишина полезна, если есть ясные правила, возможность проверить результат и вовремя остановить работу.
Источники
dsh-superagent-prototype — README DeepSeek Harness
Introducing Claude Duet — Anthropic
DeepSeek Open-Sources dsh-superagent, a Router-Worker Coding Agent — MarkTechPost
Источникtmtpost.com
