DeepSeek Super-Agent: Vad det är, hur det fungerar och vad som fortfarande saknas21 min read
Reading Time: 11 minutesÖppna tre kodningsagenter samtidigt och du kan känna problemet. En väntar på ett beslut, en klar för tjugo minuter sedan, och du har redan glömt vilken som har auth fix. DeepSeek:s Harness-team satte ett nummer på det: enligt deras erfarenhet kan en person följa endast tre till fem aktiva agentsessioner åt gången. Sedan dess är modellen inte längre flaskhalsen. Det är du.
Den 31 oktober 2026 publicerade teamet en designartikel för vad det kallar en superagent och öppnade en prototyp vid namn dsh-superagent. Det är en proaktiv kodningsagent för ett GitHub-förråd. En långlivad routersession pratar med människor och delar ut arbete, och varje accepterad förfrågan får sin egen arbetarsession som slutar med en pull-förfrågan eller en fråga. Förvaret passerade 12 000 stjärnor på cirka två dagar. Dess README är rakt på sak att detta är forskningskod och inte en officiell DeepSeek-produkt.
Den här guiden är för ingenjörer och teamledare som vill veta vad prototypen gör, hur routerns och arbetardesignen fungerar, vad benchmarksiffrorna gör och inte bevisar, och vad som ska kontrolleras innan den riktas mot ett riktigt förvar.
En anteckning före detaljerna. En arbetars svar på att ”fixa denna bugg” är en pull-begäran, och GitHub är ett bra hem för det. Resten av vad agenter producerar runt koden är svårare att placera: grundorsaksskrivningen, testsammanfattningen, jämförelsetabellen som en granskare bad om.AgentGrid.ioär en delad arbetsyta där människor och AI-agenter skapar, redigerar och delar dokument, appar och filer, med en liveversion, attribution och historik. Vi kommer tillbaka till där det passar mot slutet.
Vad är DeepSeek Super-Agent?
Två saker dök upp tillsammans. Den första är en lång designartikel, ”Exploring Super-agent Design: Towards a More Autonomous Agent System”. Harness-teamet skrev den på kinesiska och publicerade en maskinöversatt engelsk version den X den 1 november. Den har setts mer än 2,2 miljoner gånger. Den andra är koden:deepseek-ai/dsh-superagent-prototyp, släppt under MIT-licensen.
Utforska superagentdesign: Mot ett mer autonomt agentsystem
– DeepSeek Harness (@DeepSeekHarness)1 november 2026
Det är ingen ny modell. dsh-superagent är ett paket förDeepSeek Sele, DeepSeek:s agentsele med öppen källkod, som företaget beskriver som i offentlig förhandsvisning över hela världen. Paketet tittar på ett GitHub-förråd och, om du slår på det, chattar Feishu. När någon på en tillåten lista ber agenten om arbete, öppnar den ett arbetsobjekt, kör det i sin egen session och katalog och svarar i den ursprungliga konversationen. En webbpanel visar bara vad som behöver en person.
Namnet är lättare än det låter. Cui Tianyi, från DeepSeek:s produktavdelning och en av artikelns sista granskare, förklarade i ett Zhihu-inlägg att ”super” menas som i upphöjd versus nedsänkt. En superagent lägger till ett lager ovanför agenten som gör jobbet, motsatsen till en subagent, som lägger till ett under sig. Det är inte ett påstående om överlägsen intelligens.
README inleds med en varning värd att läsa i sin helhet: ”Forskningsprototyp endast för referens, inte en officiell DeepSeek-produkt.” Den tillägger att mycket av ingenjörskonsten gjordes av kodningsagenter, att koden kan innehålla buggar och att vissa designs i artikeln är anvisningar för framtida arbete och inte implementeras.
| Med en blick | dsh-superagent-prototyp |
|---|---|
| Vad det är | En proaktiv kodningsagent för ett GitHub-förråd, förpackat som ett DeepSeek-selepaket |
| Status | Forskningsprototyp, ”inte produktionsfärdig programvara” enligt README |
| Licens | MIT |
| Språk | TypeScript |
| Lyssnar på | GitHub-problem, pull-förfrågningar, kommentarer och CI. Feishu-chattar är valfria |
| Skapad | 31 oktober 2026. Mer än 12 000 stjärnor och 1 200 gafflar före den 2 november |
| Hur man ställer in det | Be din kodningsagent att läsa SETUP.md och ställa in det med dig |
En annan DeepSeek droppe: dsh-superagent
Ett agentramverk som fungerar genom en repos GitHub-frågor och PR med många agenter parallellt, utformat för att ta så lite mänsklig uppmärksamhet som möjligt samtidigt som det levererar så mycket värde som möjligt.
– Leandro von Werra (@lvwerra)31 oktober 2026
Varför säger DeepSeek att flaskhalsen är mänsklig uppmärksamhet?
Artikeln utgår från en enkel observation. Under det senaste året har kodningsagenter blivit tillräckligt bra för att en enda uppgift begränsas av modellen. Men när du väl kör flera uppgifter samtidigt flyttar gränsen till dig. Varje session är isolerad, så du byter mellan dem för hand och håller koll på vad var och en vet. Att skruva fast en CLI, MCP eller en chattkontakt på en lokal session låter den höra om nya händelser, men den blockerar fortfarande långa kommandon, blandar sammanhang från olika uppgifter och stoppar när din bärbara dator sover.
DeepSeek svar är att sluta behandla sessionen som den enhet du hanterar. Den listar fyra egenskaper som en superagent bör ha:
- Kontinuerlig.Du pratar med den där du redan arbetar, som chatt eller GitHub-kommentarer, och den beter sig som en agent. Om du frågar efter plan A i chatten och byter till plan B i en pull request-kommentar följer den.
- Produktiv.Den kör flera komplexa uppgifter parallellt och tar nästa instruktion innan den sista är klar.
- Proaktiv.Den tittar på händelser, agerar efter vad som är värt att hantera och förblir tyst annars.
- Ihållande.Den förblir online och återställer sig från fel utan att du startar om den.
Författarna hävdar att ingen enskild ReAct-loop kan leverera alla fyra, så kvaliteterna måste komma från arkitekturen runt modellen. Det är det verkliga ämnet för artikeln, och den visuella förklaringen nedan, som delas av Hesam, är ett snabbt sätt att se hela designen på en sida.
här är en visuell förklaring av DeepSeek:s artikel om Super-Agent:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP
– ℏεsam (@Hesamation)1 november 2026
Hur fungerar routerns och arbetardesignen?
Tänk på en bra ingenjörschef som aldrig skriver kod under standup. Denrouterär en långlivad session som tar emot varje meddelande från varje kanal. Den kör inte uppgifter. Den avgör vad ett meddelande efterfrågar, lämnar nytt arbete till en arbetare och skriver varje svar till de inblandade. Artikeln säger att den kan köras utan skalverktyg alls, och att en lättare, snabbare modell vanligtvis räcker för det.
Aarbetareär en separat session med ett isolerat sammanhang och en komplett uppsättning verktyg, tillägnad en uppgift. Arbetare pratar aldrig direkt med människor. De rapporterar status till routern, som håller svaren i en röst. I prototypen får varje biljett sin egen session och sin egen katalog, vanligtvis ett git-arbetsträd, och antalet arbetare är begränsat. Standardinställningen är tre åt gången, justerbar från 1 till 16, med en extra lucka som hålls ledig så att en persons meddelande alltid kan komma fram.
Två detaljer gör detta till mer än en uppgiftskö.
Uppföljningar hoppar över routern.När en arbetare äger en pull-begäran eller en chattråd, prenumererar den på den tråden. Senare kommentarer går direkt till det, utan extra modellanrop på routern. Om en kommentar visar sig handla om något annat lämnar arbetaren tillbaka den.
Bursts blir batchade.Triggers som anländer under en modell ökar kön och injiceras tillsammans i nästa samtal. Författarna mätte effekten och vi tittar på siffrorna nedan.

Ännu en kontrast. Artikeln skiljer detta från ett agentteam. I ett agentteam delar en lead en komplex uppgift i steg och samordnar rollerna som arbetar med den, vilket är en tung resonemangsbelastning. Super-agent-routern skickar bara oberoende uppgifter och spårar hur de förhåller sig på hög nivå. Det bryter inte ner själva verket.
Vad gör det när ingen frågar?
Det är här projektets filosofi blir praktisk. Det första dokumentet i förvaret anger principen på en rad: ta så lite mänsklig uppmärksamhet som möjligt och ge så mycket värde som möjligt. Varje meddelande som agenten skickar kostar en kollegas uppmärksamhet, så det talar bara när en person måste agera eller kan använda ett resultat, och det agerar bara när det tillfrågas eller när en regel som laget skrev tillåter det.
Porten som upprätthåller detta är vanlig kod, inte en modell. Den kontrollerar vem som frågar mot lagets tillåtna lista och registrerar hur stark begäran är:
| Styrka | Exempel från dokumenten | Vad händer |
|---|---|---|
| Explicit | En person på den tillåtna listan nämner agenten, eller följer upp en tråd som redan har en biljett | Agenten accepterar arbetet i alla lägen |
| Antagna | En bot på källans botlista, eller en olistad persons uppföljning. Ett oadresserat meddelande som laget valde att ta emot | Bedöms mot lagets skrivna regler. I standard observationsläge registreras det bara som ”skulle acceptera” |
| Ej antagen | Vilken annan bot som helst, allt som antagningstabellen ignorerar | Släpps innan någon modell kallas |
Det observationsläget är den del jag gillar mest. Agenten börjar med att spela in vad den skulle ha gjort, så att teamet kan läsa dessa poster på Eval-fliken och utöka sina behörigheter bara när de ser rätt ut. Meddelanden, kommentarer och citerade dokument behandlas som input till ett beslut. De kan inte ändra vad agenten får göra.
Designartikeln visar hur proaktivt arbete ser ut i praktiken. I den interna användargruppen DeepSeek Harness konfigurerade teamet en policy för ”reproducera och fixa tyst”. När någon rapporterar ett problem eller diskuterar en föreslagen ändring försöker agenten reproducera den och hitta en korrigering i bakgrunden, och den levererar ett resultat först efter att den har bekräftat problemet och hittat en enkel åtgärd. Annars är det tyst. Artikeln ger också en trubbig regel för chattkanaler som författarna säger att de har verifierat: begränsa varje svar till 100 ord. På GitHub, däremot, bör pull-förfrågningar vara täta, med problembakgrunden, ändringsbeskrivningen och verifieringsresultaten.
Som standard börjar varje GitHub-meddelande som agenten postar med raden ”Detta är av en automatiserad agent, inte en människa”. Team kan redigera det, tillsammans med resten av uppmaningarna.
Håller benchmarksiffrorna?
Artikeln innehåller ett litet experiment, och författarna är noga med att kalla det endast vägledande. Fyra designs körde sida vid sida på en ström av gruppchatt och CI-meddelanden: cirka 300 meddelanden per körning, cirka 20 av dem riktiga arbetsförfrågningar, fem körningar vardera. Kodningsarbete simulerades av ett verktyg som helt enkelt tar tid, så testet mäter schemaläggning och koordinering, inte kvaliteten på någons kod.
| Design | Uppgiftens slutförandetid, p50 / p95 (min) | Cachelästa tokens per körning |
|---|---|---|
| Superagent | 12,4 / 15,7 | 23,2 miljoner |
| Superagent utan pass-through | 12,6 / 15,5 | 31,8 miljoner |
| Ensession med subagent-verktyg, neutral prompt | 20,4 / 29,5 | 6,1 miljoner |
| Ensession med subagent-verktyg, delegeringsprompt | 13,8 / 29,0 | 10,8 M |
Läs tabellen två gånger, eftersom rubriken inte är hela historien. Routerdesignen minskade p95-sluttiden till ungefär hälften av en enskild session, men den använde ungefär två till fyra gånger de cache-lästa tokens. Och den mest intressanta raden är den andra: att ta bort genomkopplingsgenvägen fick inte uppgifterna att slutföras snabbare eller långsammare, det fick bara routern att fatta cirka 30 procent fler beslut och bränna 37 procent fler tokens.
Min läsning är att det verkliga fyndet sitter i raderna för ensessioner. Med en neutral prompt anropade modellen aldrig en subagent i någon av de fem körningarna. Den gjorde jobbet själv, nya meddelanden avbröt den hela tiden och de långsammaste uppgifterna tog 29,5 minuter. Med en uppmaning som sa att den skulle delegera, delegerade den i fyra av fem körningar, och i den återstående körningen bedömde modellen arbetet som ”litet” och gjorde det själv. En enda session beror på modellens humör. En router som inte får köra kod kan inte göra det misstaget.
Ett separat stresstest på enbart routern höjde ankomstfrekvensen för beslutsvärda händelser från cirka 1 till cirka 40 per minut. Den genomsnittliga batchen växte från 1,0 till 2,8 händelser, tiden per begäran steg endast från 2,5 till 3,9 sekunder och den amorterade tiden per beslut sjönk från 6,4 till 1,6 sekunder. Ju fler händelser som hopar sig, desto billigare blir var och en, upp till en gräns som författarna säger beror på kontextlängden och hur många händelser en modell kan hantera exakt i en sväng.
DeepSeek har just öppnat sin Super-agent-prototyp. En routersession pratar med människor och delar ut arbete, och isolerade arbetare kör uppgifter parallellt med GitHub-händelser. I deras eget test sjönk slutförandetiden för p95 från 29,5 till 15,7 minuter jämfört med en enda session med subagenter.
Valen öppen källkod igen.pic.twitter.com/mS4sRbHmyx
– Chubby (@kimmonismus)1 november 2026
Dessa är självrapporterade resultat på syntetiskt arbete. De visar att schemaläggningsidén är bra. De visar inte att prototypen fixar dina buggar snabbare.
Vad säger personer nära projektet om dess gränser?
Strax efter releasen skrev Cui Tianyi, från DeepSeek:s produktavdelning och en av de sista granskarna av designartikeln, hur han ser på designen. Hans inramning är användbar eftersom den är blygsam. Han kallar den centrala avvägningen som kontinuitet mellan uppgifter kontra uppgiftsgenomströmning.
På limits är recensionen direkt. Prototypen implementerar endast en del av den föreslagna designen. Från och med hans granskning hade DeepSeek Harness inget inbyggt långtidsminne över sessioner. Och systemet har endast validerats i en liten, pålitlig miljö inom företaget. Artikelns egna avsnitt med öppna problem listar skalning av routern, minne över månader, arbete utan sessioner, sammanhangsgränser mellan agenter och hur isolerade agenter ska prata med varandra, och säkerhet.
Vad bör du kontrollera innan du kör den?
Dokumentationen är mer uppriktig än de flesta lanseringsinlägg, och det är värt att behandla dess varningar som krav.
- Arbetare har bred tillgång.Båda behörighetsförinställningarna, för routern och för arbetarna, körs med
danger-full-accesssom operatörens OS-användare. Kontoinpackningarna väljer vilka GitHub-uppgifter som agenten använder, men dokumenten säger att de är standardvärden och inte en säkerhetsgräns, eftersom en arbetare fortfarande kan köra ett program med absolut sökväg eller läsa din hemkatalog. Rekommendationen är ett dedikerat OS-konto som endast innehåller agentens autentiseringsuppgifter. - Otillförlitlig input är den öppna säkerhetsfrågan.Artikeln varnar för att om en snabb injektion eller serverintrång äventyrar molnagentslingan, kan varje ansluten enhet nås och att referenser som kommer in i modellens sammanhang kan läcka.
- Människor går samman som standard.Agenten möjliggör aldrig automatisk sammanfogning under sitt eget konto. Automatisk sammanslagning behöver ett andra kontos CLI som heter i prompten Leveranskrav, och standardinstruktionerna tillåter det endast för små, godkända pull-förfrågningar under 200 ändrade rader.
- Det är byggt kring ett förvar.Varje installation tittar på ett enda GitHub-förråd, och Feishu, ett chattverktyg på arbetsplatsen som är vanligt i Kina, är den andra förstklassiga källan.
- Du behöver DeepSeek-sele och en modellleverantör.Inställningslistor Node.js 22.19 eller nyare, pnpm, git 2.32 eller nyare, tmux, Python 3.8 eller nyare och GitHub CLI 2.48 eller nyare. Att konfigurera en modellleverantör är ett operatörssteg.
- Buller är en kostnad.Filosofidokumentet säger att man inte ska använda medlet för att producera volym. Mass pull-förfrågningar och sändningsmeddelanden kostar ditt team mer än de ger.
Hur skulle du prova det utan att riskera ditt huvudlager?
Installationen har många steg, så projektet ber dig att låta en kodningsagent göra det med dig. Enligt README ställer agenten en kort fråga i taget, visar hela planen en gång och installerar och konfigurerar sedan allt. En försiktig första körning ser ut så här:
- Välj ett engångsförrådoch en dedikerad maskinanvändare eller OS-konto. Använd inte din egen inloggning.
- Skapa ett separat GitHub-konto för agenten.Allt det skriver visas under det namnet.
- Öppna förvaret i din kodningsagent och klistra in prompten nedan.Svara på frågorna en i taget.
- Håll den tillåtna listan för dig självoch lämna acceptläget på observera.
- Begär något litet.Kommentera från ett tillåtet konto
@<agent login> <request>på en fråga. En biljett bör visas på panelens översikt inom cirka en minut. - Läs fliken Eval i en vecka.Utöka listan eller byta till automatiskt endast när ”skulle acceptera”-posterna ser rätt ut.
Projektets filosofidokument ger operatörerna fyra regler som är värda att upprepa: börja smalt, ställ in för mindre buller, använd inte agenten för att producera volym och äg det som står i ditt namn.
Vart ska resten av agentens arbete ta vägen?
Anta att en arbetare spenderar en timme på ett fläckigt integrationstest. Dragbegäran är fixen. Men utredningen bakom, vilka tester som misslyckades, vilka hypoteser den uteslöt, vad tidtabellen visade, hör inte hemma i en PR-beskrivning, och det är precis vad recensenten vill utmana. Om det bara finns i ett chattsvar, börjar nästa agent eller lagkamrat från början.
AgentGrid.ioär byggd för den överlämningen. Människor och AI-agenter arbetar på samma livedokument, appar och filer, med en stabil adress, kontrollerad åtkomst och en versionshistorik. AgentGrid.ios dokument beskriver hur man ansluter en kommando-kapabel agent genom att köranpx @animaapp/cli@latest login. En människa godkänner agentens namn, team och vad den får göra: läsa, skriva, dela eller publicera. Därefter visas agentens ändringar i historiken under eget namn. Prototypen har ingen inbyggd AgentGrid.io-integration, så se detta som ett mönster att prova med sina arbetare, inte en dokumenterad funktion.
I praktiken skriver arbetaren sin utredning som en Markdown-fil, granskaren kommenterar en tabellrad, en annan assistent skärper sammanfattningen och pull-begäran länkar till en aktuell version istället för tre inklistrade kopior.
För en annan uppfattning om flera personer som delar en agent, se vår guide tillGrok Bot Team Bots. Och om du undrar vad som finns under en värdagent, vår guide tillClaude Managed Agentstittar på Anthropic version av samma hjärna och händer split, som DeepSeek artikel citerar.
När ska du använda dsh-superagent, och när något annat?
- Använd dsh-superagentatt lära av en seriös, dokumenterad design, att köra ett inneslutet experiment på ett lågrisklager eller att låna dess idéer: en router som aldrig kör kod, biljetter med angivet omfattning, observationsläge före autoläge.
- Använd en enda interaktiv kodningsagentnär du arbetar en uppgift i taget och vill styra steg för steg. Super-agenten är byggd för den motsatta situationen.
- Använd AgentGrid.ionär resultatet är ett dokument, en rapport eller en app som flera personer och agenter behöver granska, redigera och publicera, oavsett vilken agent som producerat den.
Vanliga frågor
Vad är DeepSeek Super-Agent?
Det är en forskningsprototyp som heter dsh-superagent, släppt av DeepSeek:s Harness-team den 31 oktober 2026 under MIT-licensen. Det är en proaktiv kodningsagent för ett GitHub-förråd. En långlivad routersession tar emot förfrågningar och tilldelar varje accepterad en till sin egen arbetarsession, som svarar i den ursprungliga konversationen, vanligtvis med en pull-förfrågan.
Är DeepSeek Super-Agent en officiell DeepSeek-produkt?
Nej. README kallar det en forskningsprototyp endast för referens och inte en officiell DeepSeek-produkt, och säger att du ska granska och anpassa den innan du använder den i din egen miljö. Den är inte heller identisk med den interna versionen eller med den implementering designartikeln beskriver.
Hur skiljer sig en superagent från en underagent?
En underagent lägger till ett lager under arbetsagenten. En superagent lägger till ett lager ovanför sig. I denna design sitter routern ovanför många arbetare, pratar med människor och skickar uppgifter, medan varje arbetare hanterar en uppgift isolerat. Namnet handlar om position, inte ett anspråk på större intelligens.
Behöver den Feishu eller bara GitHub?
Enbart GitHub räcker. Feishu är en valfri andra källa, och dokumentationen säger att ett Feishu-installationsfel endast inaktiverar Feishu-källan.
Är det säkert att köra på ett företagsförråd?
Inte som det är. Dokumenten säger att arbetare kör med full åtkomst som operatörens OS-användare och att wrapper-kontona inte är en isoleringsgräns. De rekommenderar ett dedikerat OS-konto, ett dedikerat agentkonto på GitHub, en kort tillåten lista och observationsläge medan du lär dig hur agenten beter sig.
Är det snabbare än en enda kodningsagentsession?
I författarnas eget simulerade test avslutade routerdesignen de långsammaste uppgifterna på 15,7 minuter mot 29,5 minuter för en enda session med ett subagent-verktyg, med fler tokens. Testet använde simulerat kodningsarbete och fem körningar per design, så det visar schemaläggningsfördelar, inte kodkvalitet.

Figma
Adobe XD


