DeepSeek Super-Agent: Hvad det er, hvordan det virker, og hvad der stadig mangler20 min read
Reading Time: 11 minutesÅbn tre kodningsagenter på én gang, og du kan mærke problemet. En venter på en beslutning, en færdig for tyve minutter siden, og du har allerede glemt, hvilken der har godkendelsesrettelsen. DeepSeek’s Harness-team har sat et nummer på det: Ifølge deres erfaring kan en person kun følge tre til fem aktive agentsessioner ad gangen. Efter det tidspunkt er modellen ikke længere flaskehalsen. Du er.
Den 31. oktober 2026 udgav holdet en designartikel for det, det kalder en Super-agent og åbnede en prototype ved navn dsh-superagent. Det er en proaktiv kodningsagent for et GitHub-lager. En langvarig router-session taler med folk og uddeler arbejde, og hver accepteret anmodning får sin egen worker-session, der ender med en pull-anmodning eller et spørgsmål. Depotet passerede 12.000 stjerner på omkring to dage. Dens README er direkte, at dette er forskningskode og ikke et officielt DeepSeek-produkt.
Denne vejledning er til ingeniører og teamledere, der ønsker at vide, hvad prototypen gør, hvordan routeren og arbejderdesignet fungerer, hvad benchmark-tallene gør og ikke beviser, og hvad de skal tjekke, før de peger på et rigtigt lager.
En bemærkning før detaljerne. En arbejders svar på “fix denne fejl” er en pull-anmodning, og GitHub er et fint hjem til det. Resten af, hvad agenter producerer omkring koden, er sværere at placere: opskrivningen af årsagen, testresuméet, sammenligningstabellen, som en anmelder bad om.AgentGrid.ioer et delt arbejdsområde, hvor folk og AI-agenter opretter, redigerer og deler dokumenter, apps og filer med én liveversion, tilskrivning og historik. Vi kommer tilbage til, hvor det passer til slutningen.
Hvad er DeepSeek Super-Agent?
To ting dukkede op sammen. Den første er en lang designartikel, “Exploring Super-agent Design: Towards a More Autonomous Agent System”. Harness-teamet skrev den på kinesisk og postede en maskinoversat engelsk version den X den 1. november. Den er blevet set mere end 2,2 millioner gange. Den anden er koden:deepseek-ai/dsh-superagent-prototype, udgivet under MIT-licensen.
Udforskning af superagentdesign: Mod et mere autonomt agentsystem
– DeepSeek Harness (@DeepSeekHarness)1. november 2026
Det er ikke en ny model. dsh-superagent er et bundt tilDeepSeek Sele, DeepSeek’s open source-agentsele, som virksomheden beskriver som i offentlig forhåndsvisning verden over. Bunden ser et GitHub-lager, og hvis du tænder for det, chatter Feishu. Når nogen på en tilladt liste beder agenten om arbejde, åbner den et arbejdsemne, kører det i sin egen session og mappe og svarer i den oprindelige samtale. Et webpanel viser kun, hvad der har brug for en person.
Navnet er nemmere end det lyder. Cui Tianyi, fra DeepSeek’s produktafdeling og en af artiklens endelige anmeldere, forklarede i et Zhihu-indlæg, at “super” er ment som i hævet versus nedskrevet. En superagent tilføjer et lag over den agent, der udfører arbejdet, det modsatte af en underagent, som tilføjer et under sig. Det er ikke et krav om overlegen intelligens.
README åbner med en advarsel, der er værd at læse i sin helhed: “Forskningsprototype kun til reference, ikke et officielt DeepSeek-produkt.” Den tilføjer, at meget af ingeniørarbejdet blev udført af kodningsagenter, at koden kan indeholde fejl, og at nogle designs i artiklen er retningslinier for fremtidigt arbejde og ikke implementeres.
| Med et blik | dsh-superagent-prototype |
|---|---|
| Hvad det er | En proaktiv kodningsagent til et GitHub-lager, pakket som et DeepSeek-selebundt |
| Status | Forskningsprototype, “ikke produktionsklar software” ifølge README |
| Licens | MIT |
| Sprog | TypeScript |
| lytter til | GitHub-problemer, pull-anmodninger, kommentarer og CI. Feishu chats er valgfrie |
| Oprettet | 31. oktober 2026. Mere end 12.000 stjerner og 1.200 gafler inden den 2. november |
| Sådan sætter du det op | Bed din kodningsagent om at læse SETUP.md og konfigurere den sammen med dig |
Endnu et DeepSeek drop: dsh-superagent
En agentramme, der fungerer gennem en repo’s GitHub-problemer og PR’er med mange agenter parallelt, designet til at tage så lidt menneskelig opmærksomhed som muligt og samtidig levere så meget værdi som muligt.
– Leandro von Werra (@lvwerra)31. oktober 2026
Hvorfor siger DeepSeek, at flaskehalsen er menneskelig opmærksomhed?
Artiklen tager udgangspunkt i en simpel observation. I løbet af det seneste år er kodningsagenter blevet gode nok til, at en enkelt opgave er begrænset af modellen. Men når du først kører flere opgaver på én gang, flytter grænsen sig til dig. Hver session er isoleret, så du skifter mellem dem i hånden og holder styr på, hvad hver enkelt ved. Ved at skrue en CLI, MCP eller en chatforbindelse på én lokal session, kan den høre om nye begivenheder, men den blokerer stadig for lange kommandoer, blander kontekster fra forskellige opgaver og stopper, når din bærbare computer sover.
DeepSeek’s svar er at stoppe med at behandle sessionen som den enhed, du administrerer. Den viser fire egenskaber, som en superagent skal have:
- Kontinuerlig.Du taler med den, hvor du allerede arbejder, såsom chat eller GitHub kommentarer, og den opfører sig som én agent. Hvis du beder om plan A i chat og skifter til plan B i en pull request-kommentar, følger den.
- Produktiv.Den kører flere komplekse opgaver parallelt og tager den næste instruktion, før den sidste er færdig.
- Proaktiv.Den ser begivenheder, handler på det, der er værd at håndtere og forbliver ellers stille.
- Vedholdende.Den forbliver online og genopretter sig efter fejl, uden at du genstarter den.
Forfatterne hævder, at ingen enkelt ReAct-løkke kan levere alle fire, så kvaliteterne skal komme fra arkitekturen omkring modellen. Det er artiklens egentlige emne, og den visuelle forklaring nedenfor, delt af Hesam, er en hurtig måde at se hele designet på én side.
her er en visuel forklaring af DeepSeek’s artikel om Super-Agent:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP
– ℏεsam (@Hesamation)1. november 2026
Hvordan fungerer router- og arbejderdesignet?
Tænk på en god ingeniørchef, der aldrig skriver kode under standup. Denrouterer en langvarig session, der modtager hver besked fra hver kanal. Den kører ikke opgaver. Den bestemmer, hvad en besked beder om, giver nyt arbejde til en arbejder og skriver hvert svar til de involverede personer. Artiklen siger, at den kan køre uden et skalværktøj overhovedet, og at en lettere, hurtigere model normalt er nok til det.
Aarbejderer en separat session med en isoleret kontekst og et komplet sæt værktøjer, dedikeret til én opgave. Arbejdere taler aldrig direkte med folk. De rapporterer status til routeren, som holder svar i én stemme. I prototypen får hver billet sin egen session og sin egen mappe, typisk et git-arbejdstræ, og antallet af arbejdere er begrænset. Standarden er tre ad gangen, justerbar fra 1 til 16, med en ekstra plads fri, så en persons besked altid kan komme igennem.
To detaljer gør dette til mere end en opgavekø.
Opfølgninger springer routeren over.Når en arbejder ejer en pull-anmodning eller en chattråd, abonnerer den på denne tråd. Senere kommentarer går direkte til det, uden ekstra modelkald på routeren. Hvis en kommentar viser sig at handle om noget andet, giver arbejderen den tilbage.
Bursts bliver batched.Triggere, der ankommer under én model, skruer op for køen og injiceres sammen i det næste opkald. Forfatterne målte effekten, og vi ser på tallene nedenfor.

Endnu et kontrastpunkt. Artiklen adskiller dette fra et agentteam. I et agentteam deler en lead én kompleks opgave op i trin og koordinerer de roller, der arbejder på den, hvilket er en tung ræsonnementbelastning. Super-agent-routeren sender kun uafhængige opgaver og sporer, hvordan de relaterer sig på et højt niveau. Det nedbryder ikke selve værket.
Hvad gør det, når ingen spørger?
Det er her, projektets filosofi bliver praktisk. Det første dokument i depotet angiver princippet på én linje: tag så lidt menneskelig opmærksomhed som muligt, og giv så meget værdi som muligt. Hver besked agenten sender koster en kollegas opmærksomhed, så den taler kun, når en person skal handle eller kan bruge et resultat, og den handler kun, når den bliver spurgt, eller når en regel, som teamet har skrevet, tillader det.
Porten, der håndhæver dette, er almindelig kode, ikke en model. Den tjekker, hvem der spørger, i forhold til holdets tilladte liste og registrerer, hvor stærk anmodningen er:
| Styrke | Eksempler fra dok | Hvad sker der |
|---|---|---|
| Eksplicit | En person på den tilladte liste nævner agenten eller følger op på en tråd, der allerede har en billet | Agenten accepterer arbejdet i alle tilstande |
| Udledt | En bot på kildens botliste eller en unoteret persons opfølgning. En uadresseret besked, som holdet valgte at modtage | Vurderet i forhold til holdets skriftlige regler. I standard observationstilstand optages det kun som “ville acceptere” |
| Ikke indlagt | Enhver anden bot, alt hvad adgangstabellen ignorerer | Droppet før nogen model kaldes |
Den observationstilstand er den del, jeg bedst kan lide. Agenten starter med at registrere, hvad den ville have gjort, så holdet kan læse disse poster på fanen Eval og kun udvide sine tilladelser, når de ser rigtigt ud. Beskeder, kommentarer og citerede dokumenter behandles som input til en beslutning. De kan ikke ændre, hvad agenten må gøre.
Designartiklen viser, hvordan proaktivt arbejde ser ud i praksis. I den interne DeepSeek Harness-brugergruppe konfigurerede teamet en politik for “gengivelse og rettelse i stilhed”. Når nogen rapporterer et problem eller diskuterer en foreslået ændring, forsøger agenten at reproducere den og finde en løsning i baggrunden, og den leverer først et resultat, når den har bekræftet problemet og fundet en simpel løsning. Ellers forbliver det stille. Artiklen giver også en sløv regel for chatkanaler, som forfatterne siger, de har verificeret: Hvert svar må højst være på 100 ord. På GitHub skal pull-anmodninger derimod være tætte med problembaggrunden, ændringsbeskrivelsen og verifikationsresultaterne.
Som standard starter hver GitHub-meddelelse, som agenten sender med linjen “Dette er af en automatiseret agent, ikke et menneske”. Teams kan redigere det sammen med resten af meddelelserne.
Holder benchmark-tallene?
Artiklen indeholder et lille eksperiment, og forfatterne er omhyggelige med kun at kalde det vejledende. Fire designs kørte side om side på en strøm af gruppechat- og CI-beskeder: omkring 300 beskeder pr. kørsel, omkring 20 af dem rigtige arbejdsanmodninger, fem kørsler hver. Kodningsarbejde blev simuleret af et værktøj, der simpelthen bruger tid, så testen måler planlægning og koordinering, ikke kvaliteten af nogens kode.
| Design | Opgavegennemførelsestid, p50 / p95 (min) | Cache-læste tokens pr. kørsel |
|---|---|---|
| Super-agent | 12,4 / 15,7 | 23,2 mio |
| Super-agent uden pass-through | 12,6 / 15,5 | 31,8 mio |
| Enkelt session med subagent værktøj, neutral prompt | 20,4 / 29,5 | 6,1 mio |
| Enkelt session med subagent værktøj, delegation prompt | 13,8 / 29,0 | 10,8 mio |
Læs tabellen to gange, for overskriften er ikke hele historien. Routerdesignet reducerede p95-gennemførelsestiden til omkring halvdelen af en enkelt session, men den brugte omtrent to til fire gange de cache-læste tokens. Og den mest interessante række er den anden: Fjernelse af pass-through-genvejen fik ikke opgaverne til at afslutte hurtigere eller langsommere, det fik bare routeren til at træffe omkring 30 procent flere beslutninger og brænde 37 procent flere tokens.
Min læsning er, at det virkelige fund sidder i rækkerne med en enkelt session. Med en neutral prompt kaldte modellen aldrig en subagent i nogen af de fem kørsler. Den klarede arbejdet selv, nye beskeder blev ved med at afbryde den, og de langsomste opgaver tog 29,5 minutter. Med en prompt, der fortalte, at den skulle uddelegere, delegerede den i fire ud af fem kørsler, og i den resterende kørslen bedømte modellen arbejdet “lille” og gjorde det selv. En enkelt session afhænger af modellens humør. En router, der ikke må køre kode, kan ikke begå den fejl.
En separat stresstest på routeren alene hævede ankomstraten for beslutningsværdige hændelser fra omkring 1 til omkring 40 i minuttet. Den gennemsnitlige batch voksede fra 1,0 til 2,8 hændelser, tiden pr. anmodning steg kun fra 2,5 til 3,9 sekunder, og den amortiserede tid pr. beslutning faldt fra 6,4 til 1,6 sekunder. Jo flere begivenheder hober sig op, jo billigere bliver hver enkelt, op til en grænse, siger forfatterne, afhænger af konteksts længde og hvor mange begivenheder en model kan håndtere præcist i én omgang.
DeepSeek har netop åbnet sin Super-agent-prototype. Én routersession taler med folk og uddeler arbejde, og isolerede arbejdere udfører opgaver parallelt med GitHub-begivenheder. I deres egen test faldt p95-afslutningstiden fra 29,5 til 15,7 minutter sammenlignet med en enkelt session med subagenter.
Hvalen åbnede igen.pic.twitter.com/mS4sRbHmyx
– Buttet (@kimmonismus)1. november 2026
Disse er selvrapporterede resultater om syntetisk arbejde. De viser, at planlægningsideen er sund. De viser ikke, at prototypen retter dine fejl hurtigere.
Hvad siger folk tæt på projektet om dets grænser?
Kort efter udgivelsen skrev Cui Tianyi, fra DeepSeek’s produktafdeling og en af de endelige anmeldere af designartiklen, hvordan han ser designet. Hans indramning er nyttig, fordi den er beskeden. Han betegner den centrale afvejning som kontinuitet på tværs af opgaver kontra opgavegennemstrømning.
På limits er anmeldelsen direkte. Prototypen implementerer kun en del af det foreslåede design. Fra hans anmeldelse havde DeepSeek Harness ingen indbygget langtidshukommelse på tværs af sessioner. Og systemet er kun blevet valideret i et lille, betroet miljø i virksomheden. Artiklens eget afsnit med åbne problemer viser skalering af routeren, hukommelse over måneder, arbejde uden sessioner, kontekstgrænser mellem agenter og hvordan isolerede agenter skal tale med hinanden og sikkerhed.
Hvad skal du tjekke, før du kører det?
Dokumentationen er mere ærlig end de fleste lanceringsindlæg, og det er værd at behandle dens advarsler som krav.
- Arbejdere har bred adgang.Begge forudindstillinger for tilladelser, for routeren og for arbejderne, kører med
danger-full-accesssom operatørens OS-bruger. Kontoindpakningerne vælger, hvilke GitHub-legitimationsoplysninger agenten bruger, men dokumenterne siger, at de er standarder og ikke en sikkerhedsgrænse, fordi en arbejder stadig kan køre et program med absolut sti eller læse din hjemmemappe. Anbefalingen er en dedikeret OS-konto, der kun indeholder agentens legitimationsoplysninger. - Upålidende input er det åbne sikkerhedsspørgsmål.Artiklen advarer om, at hvis en prompt indsprøjtning eller serverindtrængen kompromitterer cloud-agentsløjfen, kan hver tilsluttet enhed nås, og at legitimationsoplysninger, der kommer ind i modellens kontekst, kan lække.
- Mennesker fusionerer som standard.Agenten aktiverer aldrig automatisk fletning under sin egen konto. Automatisk fletning har brug for en anden kontos CLI navngivet i meddelelsen om leveringskrav, og standardinstruktionerne tillader det kun for små, godkendte pull-anmodninger under 200 ændrede linjer.
- Det er bygget op omkring ét depot.Hver opsætning overvåger et enkelt GitHub-lager, og Feishu, et chatværktøj på arbejdspladsen, der er almindeligt i Kina, er den anden førsteklasses kilde.
- Du skal bruge DeepSeek-sele og en modelleverandør.Opsætningen viser Node.js 22.19 eller nyere, pnpm, git 2.32 eller nyere, tmux, Python 3.8 eller nyere og GitHub CLI 2.48 eller nyere. Konfiguration af en modeludbyder er et operatørtrin.
- Støj er en omkostning.Filosofidokumentet siger ikke at bruge midlet til at producere volumen. Masse pull-anmodninger og broadcast-beskeder koster dit team mere, end de giver.
Hvordan ville du prøve det uden at risikere dit hovedlager?
Opsætningen har mange trin, så projektet beder dig om at lade en kodningsagent gøre det sammen med dig. Ifølge README stiller agenten et kort spørgsmål ad gangen, viser den fulde plan én gang og installerer og konfigurerer derefter alt. Et forsigtigt første løb ser sådan ud:
- Vælg et kasseringslagerog en dedikeret maskinbruger eller OS-konto. Brug ikke dit eget login.
- Opret en separat GitHub-konto til agenten.Alt, hvad den skriver, vises under det navn.
- Åbn depotet i din kodningsagent og indsæt prompten nedenfor.Besvar spørgsmålene et ad gangen.
- Hold den tilladte liste for dig selvog lad accepttilstanden stå på observation.
- Bed om noget lille.Kommenter fra en tilladt konto
@<agent login> <request>på et spørgsmål. En billet skulle vises på panelets Oversigt inden for cirka et minut. - Læs fanen Eval i en uge.Udvid listen, eller skift kun til automatisk, når “ville acceptere”-posterne ser rigtige ud.
Projektets filosofidokument giver operatører fire regler, der er værd at gentage: start smalt, stil ind for mindre støj, brug ikke agenten til at producere volumen og eje, hvad der står i dit navn.
Hvor skal resten af agentens arbejde hen?
Antag, at en arbejder bruger en time på en skæv integrationstest. Pull-anmodningen er løsningen. Men efterforskningen bag, hvilke tests der slog fejl, hvilke hypoteser den udelukkede, hvad timing-tabellen viste, hører ikke hjemme i en PR-beskrivelse, og det er netop det, anmelderen vil udfordre. Hvis det kun lever i et chatsvar, starter den næste agent eller holdkammerat fra bunden.
AgentGrid.ioer bygget til den overdragelse. Mennesker og AI-agenter arbejder på de samme levende dokumenter, apps og filer med én stabil adresse, kontrolleret adgang og en versionshistorik. AgentGrid.io’s dokumenter beskriver tilslutning af en kommando-kompatibel agent ved at kørenpx @animaapp/cli@latest login. Et menneske godkender agentens navn, team og hvad det kan gøre: læse, skrive, dele eller udgive. Derefter vises agentens ændringer i historikken under eget navn. Prototypen har ingen indbygget AgentGrid.io-integration, så behandl dette som et mønster, du kan prøve med sine medarbejdere, ikke en dokumenteret funktion.
I praksis skriver arbejderen sin undersøgelse som en Markdown-fil, anmelderen kommenterer en tabelrække, en anden assistent strammer resuméet, og pull-anmodningen linker til én aktuel version i stedet for tre indsatte kopier.
For et andet bud på flere personer, der deler én agent, se vores guide tilGrok Bot Team Bots. Og hvis du undrer dig over, hvad der løber under en hostet agent, er vores guide tilClaude Managed Agentsser på Anthropic’s version af den samme hjerne og hænder splittet, som DeepSeek’s artikel citerer.
Hvornår skal du bruge dsh-superagent, og hvornår noget andet?
- Brug dsh-superagentat lære af et seriøst, dokumenteret design, at køre et indesluttet eksperiment på et lavrisikodepot eller at låne dets ideer: en router, der aldrig kører kode, billetter med et angivet omfang, observationstilstand før autotilstand.
- Brug en enkelt interaktiv kodningsagentnår du arbejder en opgave ad gangen og vil styre trin for trin. Super-agenten er bygget til den modsatte situation.
- Brug AgentGrid.ionår outputtet er et dokument, en rapport eller en app, som flere personer og agenter skal gennemgå, redigere og udgive, uanset hvilken agent der har produceret det.
Ofte stillede spørgsmål
Hvad er DeepSeek Super-Agent?
Det er en forskningsprototype ved navn dsh-superagent, frigivet af DeepSeek’s Harness-team den 31. oktober 2026 under MIT-licensen. Det er en proaktiv kodningsagent for et GitHub-lager. En langvarig routersession tager anmodninger og tildeler hver accepteret en til sin egen arbejdersession, som besvarer i den oprindelige samtale, normalt med en pull-anmodning.
Er DeepSeek Super-Agent et officielt DeepSeek-produkt?
Nej. README kalder det en forskningsprototype kun til reference og ikke et officielt DeepSeek-produkt og siger, at du skal gennemgå og tilpasse det, før du bruger det i dit eget miljø. Den er heller ikke identisk med den interne version eller med den implementering designartiklen beskriver.
Hvordan adskiller en superagent sig fra en underagent?
En underagent tilføjer et lag under arbejdsagenten. En Super-agent tilføjer et lag over sig. I dette design sidder routeren over mange arbejdere, taler med folk og sender opgaver, mens hver arbejder håndterer en opgave isoleret. Navnet handler om position, ikke et krav om større intelligens.
Har den brug for Feishu eller kun GitHub?
GitHub alene er nok. Feishu er en valgfri anden kilde, og dokumentationen siger, at en Feishu-opsætningsfejl kun deaktiverer Feishu-kilden.
Er det sikkert at køre på et firmalager?
Ikke som det er. Dokumenterne siger, at arbejdere kører med fuld adgang som operatørens OS-bruger, og at wrapper-kontiene ikke er en isolationsgrænse. De anbefaler en dedikeret OS-konto, en dedikeret agentkonto på GitHub, en kort tilladt liste og observationstilstand, mens du lærer, hvordan agenten opfører sig.
Er det hurtigere end en enkelt kodningsagentsession?
I forfatternes egen simulerede test afsluttede routerdesignet de langsomste opgaver på 15,7 minutter mod 29,5 minutter for en enkelt session med et subagent-værktøj ved at bruge flere tokens. Testen brugte simuleret kodningsarbejde og fem kørsler pr. design, så den viser planlægningsfordele, ikke kodekvalitet.

Figma
Adobe XD


