DeepSeek Super-Agent: Какво представлява, как работи и какво все още липсва4 min read
Reading Time: 12 minutesОтворете три кодиращи агента наведнъж и можете да усетите проблема. Един чака решение, един приключи преди двадесет минути и вече сте забравили кой има корекцията за удостоверяване. Екипът на Harness на DeepSeek постави номер на това: според неговия опит човек може да проследи само три до пет сесии на активен агент наведнъж. След тази точка моделът вече не е тясното място. Вие сте.
На 31 октомври 2026 г. екипът публикува статия за дизайна на това, което нарича Super-agent, и отвори прототип с име dsh-superagent. Това е проактивен кодиращ агент за едно GitHub хранилище. Една дълготрайна рутерна сесия разговаря с хората и раздава работа, а всяка приета заявка получава своя работна сесия, която завършва със заявка за изтегляне или въпрос. Хранилището премина 12 000 звезди за около два дни. Неговият README категорично казва, че това е изследователски код, а не официален DeepSeek продукт.
Това ръководство е за инженери и ръководители на екипи, които искат да знаят какво прави прототипът, как работи дизайнът на рутера и работния инструмент, какво правят и не доказват сравнителните числа и какво да проверят, преди да го насочат към истинско хранилище.
Една забележка преди подробностите. Отговорът на работник за „поправете тази грешка“ е заявка за изтегляне и GitHub е чудесен дом за това. Останалата част от това, което агентите произвеждат около кода, е по-трудно да се постави: описание на първопричината, резюме на теста, сравнителна таблица, поискана от рецензент.AgentGrid.ioе споделено работно пространство, където хора и AI агенти създават, редактират и споделят документи, приложения и файлове, с една версия на живо, приписване и история. Връщаме се там, където пасва към края.
Какво представлява DeepSeek Super-Agent?
Две неща се появиха заедно. Първата е дълга статия за дизайна „Изследване на дизайна на суперагент: към по-автономна агентна система“. Екипът на Harness го написа на китайски и публикува машинно преведена английска версия на X на 1 ноември. Видян е повече от 2,2 милиона пъти. Вторият е кодът:deepseek-ai/dsh-superagent-прототип, издаден под лиценза на MIT.
Проучване на суперагентния дизайн: към по-автономна агентска система
– DeepSeek Harness (@DeepSeekHarness)1 ноември 2026 г
Не е нов модел. dsh-superagent е пакет заDeepSeek Сбруя, агент с отворен код на DeepSeek, който компанията описва като публичен предварителен преглед в целия свят. Пакетът наблюдава едно GitHub хранилище и, ако го включите, Feishu чатове. Когато някой от разрешен списък поиска от агента работа, той отваря работен елемент, изпълнява го в собствената си сесия и директория и отговаря в оригиналния разговор. Уеб панел показва само това, от което има нужда човек.
Името е по-лесно, отколкото звучи. Cui Tianyi, от продуктовия отдел на DeepSeek и един от последните рецензенти на статията, обясни в публикация на Zhihu, че „супер“ се има предвид като горен индекс срещу долен индекс. Суперагентът добавя слой над агента, който върши работата, обратното на подагента, който добавя един под него. Това не е твърдение за превъзходен интелект.
README се отваря с предупреждение, което си струва да бъде прочетено изцяло: „Изследователски прототип само за справка, а не официален DeepSeek продукт.“ Той добавя, че голяма част от инженерството е направено от кодиращи агенти, че кодът може да съдържа грешки и че някои дизайни в статията са насоки за бъдеща работа и не са внедрени.
| С един поглед | dsh-superagent-прототип |
|---|---|
| Какво представлява | Проактивен кодиращ агент за едно GitHub хранилище, опаковано като DeepSeek Harness пакет |
| Статус | Изследователски прототип, „софтуер, който не е готов за производство“ според README |
| Лиценз | MIT |
| език | TypeScript |
| слуша | GitHub проблеми, заявки за изтегляне, коментари и CI. Feishu чатовете не са задължителни |
| Създаден | 31 октомври 2026 г. Повече от 12 000 звезди и 1200 разклонения до 2 ноември |
| Как да го настроите | Помолете вашия кодиращ агент да прочете SETUP.md и да го настрои с вас |
Друг спад на DeepSeek: dsh-superagent
Агентна рамка, която работи чрез GitHub проблеми и PR на репо с много агенти паралелно, проектирана да отделя възможно най-малко човешко внимание, като същевременно предоставя възможно най-голяма стойност.
– Леандро фон Вера (@lvwerra)31 октомври 2026 г
Защо DeepSeek казва, че тясното място е човешкото внимание?
Статията започва с едно просто наблюдение. През изминалата година агентите за кодиране станаха достатъчно добри, така че една задача да бъде ограничена от модела. Но след като изпълните няколко задачи наведнъж, ограничението се премества към вас. Всяка сесия е изолирана, така че превключвате между тях ръчно и следите какво знае всеки един. Закрепването на CLI, MCP или конектор за чат към една локална сесия му позволява да чува за нови събития, но все още блокира дълги команди, смесва контексти от различни задачи и спира, когато вашият лаптоп заспи.
Отговорът на DeepSeek е да спрете да третирате сесията като единица, която управлявате. Той изброява четири черти, които един суперагент трябва да притежава:
- Непрекъснато.Говорите с него там, където вече работите, като чат или GitHub коментари, и той се държи като един агент. Ако поискате план А в чата и преминете към план Б в коментар на заявка за изтегляне, той следва.
- Продуктивен.Той изпълнява няколко сложни задачи паралелно и приема следващата инструкция, преди последната да приключи.
- Проактивен.Той наблюдава събитията, действа според това, което си струва да се борави и остава тихо в противен случай.
- Упорит.Той остава онлайн и се възстановява от повреди, без да го рестартирате.
Авторите твърдят, че нито един цикъл ReAct не може да достави и четирите, така че качествата трябва да идват от архитектурата около модела. Това е истинската тема на статията, а визуалният обяснител по-долу, споделен от Hesam, е бърз начин да видите целия дизайн на една страница.
ето визуално обяснение на статията на DeepSeek за Super-Agent:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP
– ℏεsam (@Hesamation)1 ноември 2026 г
Как работи дизайнът на рутера и работния елемент?
Помислете за добър инженерен мениджър, който никога не пише код по време на изправяне. Theрутере една дълготрайна сесия, която получава всяко съобщение от всеки канал. Не изпълнява задачи. Той решава какво иска едно съобщение, предава нова работа на работник и пише всеки отговор на участващите хора. В статията се казва, че може да работи без shell tool изобщо и че по-лек и по-бърз модел обикновено е достатъчен за него.
Аработнике отделна сесия с изолиран контекст и пълен набор от инструменти, посветени на една задача. Работниците никога не говорят директно с хората. Те съобщават за състоянието на рутера, който поддържа отговорите в един глас. В прототипа всеки билет получава своя собствена сесия и собствена директория, обикновено git worktree, а броят на работниците е ограничен. По подразбиране са три наведнъж, регулируеми от 1 до 16, с един допълнителен слот, който остава свободен, така че съобщението на човек винаги да може да премине.
Две подробности правят това нещо повече от опашка със задачи.
Последващите действия пропускат рутера.След като работникът притежава заявка за изтегляне или нишка за чат, той се абонира за тази нишка. По-късните коментари отиват направо към него, без допълнително извикване на модел на рутера. Ако се окаже, че даден коментар е за нещо друго, работникът го връща.
Изблиците се групират.Тригерите, които пристигат по време на един модел, се подреждат в опашка и се инжектират заедно в следващото повикване. Авторите измерват ефекта и ние разглеждаме числата по-долу.

Още една точка на контраст. Статията разграничава това от екип от агенти. В екип от агенти водещият разбива една сложна задача на стъпки и координира ролите, които работят по нея, което е тежко натоварване на разсъжденията. Рутерът Super-agent изпраща само независими задачи и проследява как те се отнасят на високо ниво. Не разлага самата творба.
Какво прави, когато никой не го пита?
Това е мястото, където философията на проекта става практична. Първият документ в хранилището посочва принципа в един ред: отделете възможно най-малко човешко внимание и дайте възможно най-голяма стойност. Всяко съобщение, изпратено от агента, струва вниманието на колегата, така че говори само когато човек трябва да действа или може да използва резултат и действа само когато бъде помолен или когато правило, написано от екипа, го позволява.
Портата, която налага това, е обикновен код, а не модел. Той проверява кой пита спрямо разрешения списък на екипа и записва колко силна е заявката:
| Сила | Примери от документите | Какво става |
|---|---|---|
| Изрично | Човек в списъка с разрешени споменава агента или проследява тема, която вече има билет | Агентът приема работата във всеки режим |
| Изведено | Бот в списъка с ботове на източника или последващо действие на непосочено лице. Неадресирано съобщение, което екипът е избрал да получи | Оценява се спрямо писмените правила на отбора. В режима на наблюдение по подразбиране се записва само като „би приел“ |
| Не се допуска | Всеки друг бот, всичко, което таблицата за прием игнорира | Отпада, преди да бъде извикан модел |
Този режим на наблюдение е частта, която харесвам най-много. Агентът започва със записване на това, което би направил, така че екипът да може да прочете тези записи в раздела Eval и да разшири своите разрешения само когато изглеждат правилни. Съобщенията, коментарите и цитираните документи се третират като входни данни за вземане на решение. Те не могат да променят това, което агентът има право да прави.
Статията за дизайн показва как изглежда проактивната работа на практика. Във вътрешната потребителска група DeepSeek Harness екипът конфигурира политика за „безшумно възпроизвеждане и коригиране“. Когато някой съобщи за проблем или обсъди предложена промяна, агентът се опитва да я възпроизведе и да намери корекция във фонов режим и дава резултат само след като е потвърдил проблема и е намерил проста корекция. Иначе остава тихо. Статията също така дава грубо правило за каналите за чат, което авторите казват, че са проверили: ограничаване на всеки отговор до 100 думи. На GitHub, обратно, заявките за изтегляне трябва да са плътни, с фона на проблема, описанието на промяната и резултатите от проверката.
По подразбиране всяко GitHub съобщение, публикувано от агента, започва с реда „Това е от автоматизиран агент, а не от човек“. Екипите могат да редактират това, заедно с останалите подкани.
Издържат ли референтните стойности?
Статията включва малък експеримент и авторите внимават да го нарекат само ориентировъчен. Четири дизайна се изпълняваха един до друг в поток от групови чатове и CI съобщения: около 300 съобщения на изпълнение, около 20 от тях реални заявки за работа, по пет изпълнявания всяко. Работата по кодиране беше симулирана от инструмент, който просто отнема време, така че тестът измерва планирането и координацията, а не качеството на нечий код.
| Дизайн | Време за изпълнение на задачата, p50 / p95 (мин.) | Токени за четене на кеш на изпълнение |
|---|---|---|
| Супер-агент | 12,4 / 15,7 | 23.2M |
| Супер-агент без преминаване | 12,6 / 15,5 | 31.8M |
| Единична сесия с инструмент за субагент, неутрална подкана | 20,4 / 29,5 | 6.1M |
| Единична сесия с инструмент за субагент, подкана за делегиране | 13,8 / 29,0 | 10.8M |
Прочетете таблицата два пъти, защото заглавието не е цялата история. Дизайнът на рутера съкрати времето за завършване на p95 до около половината от това на една сесия, но използва приблизително два до четири пъти токените за четене на кеша. И най-интересният ред е вторият: премахването на прекия път за преминаване не направи задачите да завършват по-бързо или по-бавно, просто накара рутера да вземе около 30 процента повече решения и да изгори 37 процента повече токени.
Моето четене е, че истинската находка се намира в редовете за една сесия. С неутрална подкана моделът никога не е извикал субагент в нито един от петте прогони. Той свърши работата сам, новите съобщения продължаваха да го прекъсват, а най-бавните задачи отнемаха 29,5 минути. С подкана, която му каза да делегира, той делегира в четири от пет изпълнения, а в оставащото изпълнение моделът прецени, че работата е „малка“ и я направи сам. Една сесия зависи от настроението на модела. Рутер, който няма право да изпълнява код, не може да направи тази грешка.
Отделен стрес тест само на рутера повиши скоростта на пристигане на събития, заслужаващи решение, от около 1 на около 40 на минута. Средната партида нарасна от 1,0 на 2,8 събития, времето за заявка се повиши само от 2,5 на 3,9 секунди, а амортизираното време за решение падна от 6,4 на 1,6 секунди. Колкото повече събития се натрупват, толкова по-евтино става всяко от тях, до ограничение, което авторите казват, че зависи от дължината на контекста и колко събития моделът може да обработи точно на един ход.
DeepSeek току-що отвори своя прототип на Super-agent. Една рутерна сесия разговаря с хората и раздава работа, а изолирани работници изпълняват задачи паралелно на GitHub събития. В техния собствен тест, времето за завършване на p95 спада от 29,5 на 15,7 минути в сравнение с единична сесия, използваща субагенти.
Китът отново с отворен код.pic.twitter.com/mS4sRbHmyx
– Chubby (@kimmonismus)1 ноември 2026 г
Това са самооценени резултати при синтетична работа. Те показват, че идеята за планиране е добра. Те не показват, че прототипът поправя вашите грешки по-бързо.
Какво казват близки до проекта за неговите ограничения?
Скоро след издаването Cui Tianyi от продуктовия отдел на DeepSeek и един от последните рецензенти на статията за дизайна написа как той вижда дизайна. Рамкирането му е полезно, защото е скромно. Той назовава централния компромис като приемственост между задачите срещу пропускателна способност на задачите.
При ограничения прегледът е директен. Прототипът изпълнява само част от предложения дизайн. От неговия преглед DeepSeek Harness нямаше вградена дългосрочна памет в сесиите. И системата е валидирана само в малка надеждна среда вътре в компанията. Разделът за отворени проблеми на статията изброява мащабиране на рутера, памет за месеци, работа без сесии, контекстни граници между агенти и как изолираните агенти трябва да говорят помежду си и сигурност.
Какво трябва да проверите, преди да го стартирате?
Документацията е по-откровена от повечето публикации за стартиране и си струва да се третират нейните предупреждения като изисквания.
- Работниците имат широк достъп.И двете предварително зададени разрешения, за рутера и за работниците, работят с
danger-full-accessкато потребител на операционната система на оператора. Обвивките на акаунта избират кои GitHub идентификационни данни да използва агентът, но документите казват, че те са по подразбиране, а не граница на сигурността, тъй като работник все още може да изпълнява програма по абсолютен път или да чете вашата домашна директория. Препоръката е специален акаунт в ОС, който съдържа само идентификационните данни на агента. - Недовереният вход е отворен въпрос за сигурност.Статията предупреждава, че ако бързо инжектиране или проникване в сървър компрометира цикъла на облачен агент, всяко свързано устройство може да бъде достигнато и че идентификационните данни, които влизат в контекста на модела, могат да изтекат.
- Хората се сливат по подразбиране.Агентът никога не разрешава автоматично обединяване под собствения си акаунт. Автоматичното обединяване се нуждае от CLI на втори акаунт, посочен в подканата за изисквания за доставка, а инструкциите по подразбиране го позволяват само за малки, одобрени заявки за изтегляне под 200 променени реда.
- Изграден е около едно хранилище.Всяка настройка наблюдава едно GitHub хранилище, а Feishu, инструмент за чат на работното място, разпространен в Китай, е другият първокласен източник.
- Имате нужда от колан DeepSeek и доставчик на модел.Инсталационните списъци Node.js 22.19 или по-нова, pnpm, git 2.32 или по-нова, tmux, Python 3.8 или по-нова и GitHub CLI 2.48 или по-нова. Конфигурирането на модел доставчик е стъпка от оператора.
- Шумът е разход.Философският документ казва да не се използва агентът за производство на обем. Масовите заявки за изтегляне и излъчваните съобщения струват на вашия екип повече, отколкото дават.
Как бихте го опитали, без да рискувате основното си хранилище?
Настройката има много стъпки, така че проектът ви моли да позволите на кодиращ агент да го направи с вас. Според README агентът задава един кратък въпрос наведнъж, показва пълния план веднъж и след това инсталира и конфигурира всичко. Едно предпазливо първо пускане изглежда така:
- Изберете хранилище за еднократна употребаи специален акаунт за потребител на машина или операционна система. Не използвайте собствените си данни за вход.
- Създайте отделен GitHub акаунт за агента.Всичко, което пише, се появява под това име.
- Отворете хранилището във вашия кодиращ агент и поставете подканата по-долу.Отговорете на въпросите му един по един.
- Запазете списъка с разрешени за себе сии оставете режима на приемане на наблюдение.
- Поискайте нещо малко.От разрешен акаунт, коментирайте
@<agent login> <request>по въпрос. Билетът трябва да се появи в Обзора на панела в рамките на около минута. - Прочетете раздела Eval за една седмица.Разширете списъка или превключете на автоматично само когато записите „би приел“ изглеждат правилни.
Философският документ на проекта дава на операторите четири правила, които си струва да бъдат повторени: започнете от тясно, настройте се за по-малко шум, не използвайте агента, за да произвеждате сила на звука, и притежавайте това, което пише във вашето име.
Къде трябва да отиде останалата част от работата на агента?
Да предположим, че един работник прекарва един час в нестабилен интеграционен тест. Заявката за изтегляне е поправката. Но разследването зад него, кои тестове са се провалили, кои хипотези е отхвърлило, какво е показала таблицата с времето, не принадлежи към PR описанието и е точно това, което рецензентът иска да оспори. Ако това съществува само в отговор на чат, следващият агент или съотборник започва от нулата.
AgentGrid.ioе създаден за това предаване. Хората и AI агентите работят върху едни и същи живи документи, приложения и файлове, с един стабилен адрес, контролиран достъп и история на версиите. Документите на AgentGrid.io описват свързването на агент с възможност за управление чрез стартиранеnpx @animaapp/cli@latest login. Човек одобрява името на агента, екипа и какво може да прави: чете, пише, споделя или публикува. След това промените на агента се появяват в хронологията под собственото си име. Прототипът няма вградена интеграция на AgentGrid.io, така че приемайте това като модел, който да опитате с неговите работници, а не като документирана функция.
На практика работникът пише разследването си като Markdown файл, рецензентът коментира ред от таблица, друг асистент затяга резюмето и заявката за изтегляне се свързва към една текуща версия вместо три поставени копия.
За друг поглед към няколко души, споделящи един агент, вижте нашето ръководство заGrok Bot Екипни ботове. И ако се чудите какво се крие под хостван агент, нашето ръководство заClaude Managed Agentsразглежда версията на Anthropic за същото разделение на мозъка и ръцете, цитирано в статията на DeepSeek.
Кога трябва да използвате dsh-superagent и кога нещо друго?
- Използвайте dsh-superagentда се научите от сериозен, документиран дизайн, да проведете ограничен експеримент върху хранилище с нисък риск или да заимствате неговите идеи: рутер, който никога не изпълнява код, билети с посочен обхват, режим на наблюдение преди автоматичен режим.
- Използвайте един интерактивен кодиращ агенткогато работите една по една задача и искате да управлявате стъпка по стъпка. Суперагентът е създаден за обратната ситуация.
- Използвайте AgentGrid.ioкогато резултатът е документ, отчет или приложение, което няколко души и агенти трябва да прегледат, редактират и публикуват, независимо кой агент го е създал.
Често задавани въпроси
Какво представлява DeepSeek Super-Agent?
Това е изследователски прототип, наречен dsh-superagent, пуснат от екипа Harness на DeepSeek на 31 октомври 2026 г. под лиценза на MIT. Това е проактивен кодиращ агент за едно GitHub хранилище. Дълготрайна сесия на рутер приема заявки и присвоява всяка приета на собствена работна сесия, която отговаря в оригиналния разговор, обикновено с изтегляне.
DeepSeek Super-Agent официален DeepSeek продукт ли е?
Не. README го нарича изследователски прототип само за справка, а не официален DeepSeek продукт, и казва да го прегледате и адаптирате, преди да го използвате във вашата собствена среда. Освен това не е идентичен с вътрешната версия или с изпълнението, описано в статията за дизайна.
По какво се различава суперагент от субагент?
Подагентът добавя слой под работния агент. Суперагентът добавя слой над него. В този дизайн рутерът седи над много работници, разговаря с хората и изпраща задачи, докато всеки работник обработва една задача изолирано. Името е за позиция, а не за претенция за по-голяма интелигентност.
Има ли нужда от Feishu или само GitHub?
GitHub сам по себе си е достатъчен. Feishu е незадължителен втори източник и в документацията се казва, че грешка в настройката на Feishu деактивира само източника Feishu.
Безопасно ли е да работите в хранилище на компания?
Не както е. В документите се казва, че работниците работят с пълен достъп като потребител на операционната система на оператора и че акаунтите за обвивка не са изолираща граница. Те препоръчват специален акаунт на ОС, специален акаунт на агент на GitHub, кратък разрешен списък и режим на наблюдение, докато научавате как се държи агентът.
По-бърз ли е от една сесия на кодиращ агент?
В собствения симулиран тест на авторите дизайнът на рутера завърши най-бавните задачи за 15,7 минути срещу 29,5 минути за една сесия с инструмент за подагент, използвайки повече токени. Тестът използва симулирана работа по кодиране и пет изпълнения на дизайн, така че показва ползите от планирането, а не качеството на кода.

Figma
Adobe XD


