В коде веб-версии DeepSeek обнаружена логика управления квотами, указывающая на 'План кодирования', но официального объявления нет

Команда DeepSeek Harness сообщила, что на 4 ноября продукт, являющийся средой выполнения агентов с открытым исходным кодом от DeepSeek, насчитывал 1,54 миллиона активных пользователей ежедневно. Эта информация была представлена в обновлении 5 ноября, согласно сообщениям IT Home и MyDrivers.

Подсчет включает только тех пользователей, которые используют продукт через официальный API DeepSeek. Вся эта пользовательская база потребляет около 92 триллионов токенов в день.

Эти показатели демонстрируют быстрый рост продукта, который существует менее трех месяцев. Версия DeepSeek Harness v0.1 была запущена 13 августа, а настольная версия появилась 29 сентября. Как отмечалось MyDrivers, 30 сентября количество активных пользователей составляло примерно 271 000, что означает более чем пятикратный рост базы пользователей менее чем за месяц.

Значительная часть активности обеспечивается плагинами. По данным команды, с момента запуска появилось около 35 000 сторонних плагинов, и примерно 60% активных пользователей создали или установили хотя бы один из них. Это соответствует основной концепции продукта, которая часто сводится к идее, что все является плагином: модели, инструменты, навыки, сессии, песочницы, хранилище, циклы, планирование и пользовательский интерфейс собираются из плагинов, которые пользователи могут менять и комбинировать.

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

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

Команда DeepSeek Harness сделала общедоступным dsh-superagent — исследовательский прототип, который принимает запросы на разработку через GitHub и, при желании, через Feishu. Агент выполняет работу в отдельных сессиях и возвращает результаты, например, в виде запросов на слияние (pull requests) в исходный диалог.

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

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

Команда DeepSeek Harness опубликовала описание своего проекта, который они назвали Супер-агент. Этот агент спроектирован как постоянно действующая система, которая одновременно продвигает несколько задач, самостоятельно ищет работу и восстанавливается после сбоев. Соответствующий исследовательский прототип был выпущен на GitHub под лицензией MIT, как сообщили китайские технологические СМИ.

Репозиторий dsh-superagent-prototype представляет собой пакет проактивного кодирующего агента, предназначенного для работы с одним репозиторием GitHub в рамках экосистемы DeepSeek Harness. Агент отслеживает активность в GitHub, а также опционально в Feishu. Когда авторизованный пользователь запрашивает выполнение задачи, агент создает рабочий элемент, обрабатывает его в своей сессии и каталоге, а затем отвечает в исходном диалоге, например, через создание запроса на слияние (pull request).

В сопроводительной документации подчеркивается, что данный код является исследовательским, а не официальным продуктом DeepSeek, и некоторые концепции, описанные в документе, еще не реализованы.

Архитектура системы

Основная концепция построена на двухслойной архитектуре. Сессия маршрутизатора (Router) принимает всю человеческую активность из разных каналов, но сама не выполняет работу и может даже не иметь инструмента Bash. Задачи делегируются изолированным сессиям рабочих агентов (Worker), которые выполняют работу параллельно, используя полный набор инструментов, и отправляют отчеты обратно Маршрутизатору, минуя общение с пользователями.

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

Команда также разделила состояние агента и среды выполнения, чтобы агент мог оставаться активным в облаке, взаимодействуя с локальными машинами пользователя. Дополнительно используется внешняя сессия Наблюдателя (Watchdog), которая контролирует, добиваются ли Рабочие агенты реального прогресса. В внутренней группе пользователей команда установила правило: экземпляр должен молча воспроизводить заявленные ошибки и сообщать о них только после того, как найдет простое решение, иногда открывая запрос на слияние до того, как кто-либо отметит проблему.

В ходе предварительных испытаний на синтетических нагрузках, включавших около 300 сообщений и примерно 20 запросов на работу, Супер-агент завершил половину задач за 12,4 минуты, а 95% — за 15,7 минут. Эти показатели превзошли результаты, достигнутые одной сессией с инструментом под-агента, хотя и потребовали больше кешированных токенов. Без прямого направления последующих событий к Рабочим агентам решения Маршрутизатора увеличились примерно на 30%, а пакетная обработка при высокой нагрузке снизила время вывода одного решения Маршрутизатора с 6,4 секунд до 1,6 секунды. Команда назвала эти результаты предварительным ориентиром.

Среди нерешенных вопросов, перечисленных командой, — масштабирование Маршрутизатора, долгосрочная память, межагентное взаимодействие и риск внедрения подсказок (prompt-injection) в случае, если облачный агент получает доступ к учетным данным на локальных устройствах.