DeepSeek Super-Agent: Hva det er, hvordan det fungerer og hva som fortsatt mangler19 min read

Åpne tre kodeagenter samtidig, og du kan føle problemet. En venter på en avgjørelse, en ferdig for tjue minutter siden, og du har allerede glemt hvilken som har auth fix. DeepSeeks Harness-team satte et nummer på det: etter deres erfaring kan en person bare følge tre til fem aktive agentøkter om gangen. Etter det punktet er ikke modellen lenger flaskehalsen. Du er.

31. oktober 2026 publiserte teamet en designartikkel for det de kaller en Super-agent og åpnet en prototype kalt dsh-superagent. Det er en proaktiv kodeagent for ett GitHub-lager. Én langvarig ruterøkt snakker med folk og deler ut arbeid, og hver akseptert forespørsel får sin egen arbeiderøkt som ender i en pull-forespørsel eller et spørsmål. Depotet passerte 12 000 stjerner på omtrent to dager. Dens README er rett og slett at dette er forskningskode og ikke et offisielt DeepSeek-produkt.

Denne veiledningen er for ingeniører og teamledere som ønsker å vite hva prototypen gjør, hvordan ruter- og arbeiderdesignet fungerer, hva benchmark-tallene gjør og ikke beviser, og hva du bør sjekke før du peker den mot et ekte depot.

En merknad før detaljene. En arbeiders svar på «fiks denne feilen» er en pull-forespørsel, og GitHub er et fint hjem for det. Resten av det agenter produserer rundt koden er vanskeligere å plassere: oppskriften på grunnårsaken, testsammendraget, sammenligningstabellen en anmelder ba om.AgentGrid.ioer et delt arbeidsområde der folk og AI-agenter oppretter, redigerer og deler dokumenter, apper og filer, med én liveversjon, attribusjon og historikk. Vi kommer tilbake til der det passer mot slutten.

Hva er DeepSeek Super-Agent?

To ting dukket opp sammen. Den første er en lang designartikkel, «Exploring Super-agent Design: Towards a More Autonomous Agent System». Harness-teamet skrev den på kinesisk og la ut en maskinoversatt engelsk versjon på X 1. november. Den har blitt sett mer enn 2,2 millioner ganger. Den andre er koden:deepseek-ai/dsh-superagent-prototype, utgitt under MIT-lisensen.

Utforsking av superagentdesign: Mot et mer autonomt agentsystem

https://t.co/gwwIHtyCRQ

– DeepSeek-sele (@DeepSeekHarness)1. november 2026

Det er ikke en ny modell. dsh-superagent er en pakke forDeepSeek Sele, DeepSeeks åpen kildekode-agentsele, som selskapet beskriver som i offentlig forhåndsvisning over hele verden. Bunten ser på ett GitHub-lager, og hvis du slår det på, chatter Feishu. Når noen på en tillatt liste ber agenten om arbeid, åpner den et arbeidselement, kjører det i sin egen økt og katalog og svarer i den opprinnelige samtalen. Et nettpanel viser bare hva som trenger en person.

Navnet er lettere enn det høres ut. Cui Tianyi, fra DeepSeeks produktavdeling og en av artikkelens siste anmeldere, forklarte i et Zhihu-innlegg at «super» er ment som i hevet versus skrift. En superagent legger til et lag over agenten som gjør jobben, det motsatte av en underagent, som legger et under seg. Det er ikke et krav om overlegen intelligens.

README åpner med en advarsel verdt å lese i sin helhet: «Research prototype for reference only, not a official DeepSeek product.» Den legger til at mye av konstruksjonen ble gjort av kodeagenter, at koden kan inneholde feil, og at noen design i artikkelen er retninger for fremtidig arbeid og ikke er implementert.

Nok et DeepSeek-fall: dsh-superagent

Et agentrammeverk som fungerer gjennom en repos GitHub-problemer og PR-er med mange agenter parallelt, designet for å ta så lite menneskelig oppmerksomhet som mulig og samtidig levere så mye verdi som mulig.

pic.twitter.com/XR73mIvA0V

– Leandro von Werra (@lvwerra)31. oktober 2026

Hvorfor sier DeepSeek at flaskehalsen er menneskelig oppmerksomhet?

Artikkelen tar utgangspunkt i en enkel observasjon. I løpet av det siste året har kodeagenter blitt gode nok til at en enkelt oppgave er begrenset av modellen. Men når du kjører flere oppgaver samtidig, flyttes grensen til deg. Hver økt er isolert, så du bytter mellom dem for hånd og holder styr på hva hver enkelt kan. Ved å bolte en CLI, MCP eller en chat-kontakt på én lokal økt kan den høre om nye hendelser, men den blokkerer fortsatt lange kommandoer, blander kontekster fra forskjellige oppgaver og stopper når den bærbare datamaskinen sover.

DeepSeek sitt svar er å slutte å behandle økten som enheten du administrerer. Den viser fire egenskaper en superagent bør ha:

• Kontinuerlig.Du snakker med den der du allerede jobber, for eksempel chat eller GitHub-kommentarer, og den oppfører seg som én agent. Hvis du ber om plan A i chat og bytter til plan B i en pull request-kommentar, følger den.
• Produktiv.Den kjører flere komplekse oppgaver parallelt og tar neste instruksjon før den siste er ferdig.
• Proaktiv.Den ser på hendelser, handler på det som er verdt å håndtere og forblir stille ellers.
• Vedvarende.Den forblir online og gjenoppretter seg etter feil uten at du starter den på nytt.

Forfatterne hevder at ingen enkelt ReAct-sløyfe kan levere alle fire, så kvalitetene må komme fra arkitekturen rundt modellen. Det er det egentlige temaet for artikkelen, og den visuelle forklaringen nedenfor, delt av Hesam, er en rask måte å se hele designet på én side.

her er en visuell forklaring av DeepSeek sin artikkel om Super-Agent:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP

– ℏεsam (@Hesamation)1. november 2026

Hvordan fungerer ruteren og arbeiderdesignet?

Tenk på en god ingeniørsjef som aldri skriver kode under standup. Denruterer en langvarig økt som mottar hver melding fra hver kanal. Den kjører ikke oppgaver. Den bestemmer hva en melding ber om, gir nytt arbeid til en arbeider, og skriver hvert svar til de involverte. Artikkelen sier at den kan kjøre uten skallverktøy i det hele tatt, og at en lettere, raskere modell vanligvis er nok for det.

Aarbeiderer en egen økt med en isolert kontekst og et komplett sett med verktøy, dedikert til én oppgave. Arbeidere snakker aldri direkte med folk. De rapporterer status til ruteren, som holder svar på én stemme. I prototypen får hver billett sin egen økt og sin egen katalog, vanligvis et git-arbeidstre, og antall arbeidere er begrenset. Standard er tre om gangen, justerbar fra 1 til 16, med en ekstra plass som holdes ledig slik at en persons melding alltid kan komme frem.

To detaljer gjør dette til mer enn en oppgavekø.

Oppfølginger hopper over ruteren.Når en arbeider eier en pull-forespørsel eller en chattråd, abonnerer den på den tråden. Senere kommentarer går rett til den, uten ekstra modellanrop på ruteren. Hvis en kommentar viser seg å handle om noe annet, gir arbeideren den tilbake.

Bursts blir batched.Triggere som ankommer i løpet av en modell skru opp køen og injiseres sammen i neste samtale. Forfatterne målte effekten, og vi ser på tallene nedenfor.

Nok et kontrastpunkt. Artikkelen skiller dette fra et agentteam. I et agentteam deler en lead én kompleks oppgave i trinn og koordinerer rollene som jobber med den, noe som er en tung resonneringsbelastning. Super-agent-ruteren sender kun uavhengige oppgaver og sporer hvordan de forholder seg på et høyt nivå. Det bryter ikke ned selve verket.

Hva gjør den når ingen spør?

Det er her prosjektets filosofi blir praktisk. Det første dokumentet i depotet sier prinsippet på én linje: ta så lite menneskelig oppmerksomhet som mulig, og gi så mye verdi som mulig. Hver melding agenten sender koster en kollegas oppmerksomhet, så den snakker bare når en person må handle eller kan bruke et resultat, og den handler bare når den blir spurt eller når en regel laget skrev tillater det.

Porten som håndhever dette er ren kode, ikke en modell. Den sjekker hvem som spør mot lagets tillatte liste og registrerer hvor sterk forespørselen er:

Den observasjonsmodusen er den delen jeg liker best. Agenten starter med å registrere hva den ville ha gjort, slik at teamet kan lese disse postene på Eval-fanen og utvide tillatelsene bare når de ser riktig ut. Meldinger, kommentarer og siterte dokumenter behandles som innspill til et vedtak. De kan ikke endre hva agenten har lov til å gjøre.

Designartikkelen viser hvordan proaktivt arbeid ser ut i praksis. I den interne brukergruppen DeepSeek Harness konfigurerte teamet en policy for «reproduser og fiks i stillhet». Når noen rapporterer et problem eller diskuterer en foreslått endring, prøver agenten å reprodusere den og finne en løsning i bakgrunnen, og den leverer et resultat først etter at den har bekreftet problemet og funnet en enkel løsning. Ellers forblir det stille. Artikkelen gir også en sløv regel for chattekanaler som forfatterne sier de har verifisert: begrense hvert svar til 100 ord. På GitHub, derimot, skal pull-forespørsler være tette, med problembakgrunnen, endringsbeskrivelsen og verifiseringsresultatene.

Som standard starter hver GitHub-melding agenten legger ut med linjen «Dette er av en automatisert agent, ikke et menneske». Lag kan redigere det, sammen med resten av ledetekstene.

Holder benchmark-tallene?

Artikkelen inneholder et lite eksperiment, og forfatterne er nøye med å kalle det kun veiledende. Fire design kjørte side om side på en strøm av gruppechat- og CI-meldinger: omtrent 300 meldinger per kjøring, rundt 20 av dem ekte arbeidsforespørsler, fem kjøringer hver. Kodearbeid ble simulert av et verktøy som rett og slett bruker tid, så testen måler planlegging og koordinering, ikke kvaliteten på noens kode.

Les tabellen to ganger, for overskriften er ikke hele historien. Ruterdesignet kuttet fullføringstiden for p95 til omtrent halvparten av en enkelt økt, men den brukte omtrent to til fire ganger de cache-leste tokenene. Og den mest interessante raden er den andre: Fjerning av gjennomgangssnarveien gjorde ikke at oppgavene ble fullført raskere eller tregere, det fikk bare ruteren til å ta omtrent 30 prosent flere beslutninger og brenne 37 prosent flere tokens.

Min lesning er at det virkelige funnet sitter i radene for én økt. Med en nøytral melding kalte modellen aldri en subagent i noen av de fem kjøringene. Den gjorde jobben selv, nye meldinger avbrøt den hele tiden, og de tregeste oppgavene tok 29,5 minutter. Med en oppfordring som fortalte den om å delegere, delegerte den i fire av fem kjøringer, og i den gjenværende kjøringen bedømte modellen arbeidet som «lite» og gjorde det selv. En enkelt økt avhenger av modellens humør. En ruter som ikke har lov til å kjøre kode kan ikke gjøre den feilen.

En egen stresstest på ruteren alene økte ankomstraten for beslutningsverdige hendelser fra ca. 1 til ca. 40 per minutt. Gjennomsnittlig batch vokste fra 1,0 til 2,8 hendelser, tiden per forespørsel steg bare fra 2,5 til 3,9 sekunder, og den amortiserte tiden per beslutning falt fra 6,4 til 1,6 sekunder. Jo flere hendelser hoper seg opp, jo billigere blir hver enkelt, opp til en grense som forfatterne sier avhenger av kontekstlengde og hvor mange hendelser en modell kan håndtere nøyaktig i en sving.

DeepSeek har nettopp åpnet sin Super-agent-prototype. Én ruterøkt snakker med folk og deler ut arbeid, og isolerte arbeidere kjører oppgaver parallelt med GitHub-hendelser. I deres egen test falt p95-gjennomføringstiden fra 29,5 til 15,7 minutter sammenlignet med en enkelt økt med subagenter.

Hvalen åpner igjen.pic.twitter.com/mS4sRbHmyx

– Chubby (@kimmonismus)1. november 2026

Dette er selvrapporterte resultater på syntetisk arbeid. De viser at planleggingsideen er god. De viser ikke at prototypen fikser feilene dine raskere.

Hva sier folk nær prosjektet om grensene?

Rett etter utgivelsen skrev Cui Tianyi, fra DeepSeeks produktavdeling og en av de siste anmelderne av designartikkelen, hvordan han ser på designet. Innrammingen hans er nyttig fordi den er beskjeden. Han kaller den sentrale avveiningen som kontinuitet på tvers av oppgaver kontra oppgavegjennomstrømning.

På limits er anmeldelsen direkte. Prototypen implementerer bare en del av det foreslåtte designet. Fra gjennomgangen hans hadde DeepSeek Harness ingen innebygd langtidsminne på tvers av økter. Og systemet er kun validert i et lite, pålitelig miljø i selskapet. Artikkelens egen seksjon med åpne problemer viser skalering av ruteren, minne over måneder, arbeid uten økter, kontekstgrenser mellom agenter og hvordan isolerte agenter skal snakke med hverandre, og sikkerhet.

Hva bør du sjekke før du kjører den?

Dokumentasjonen er mer ærlig enn de fleste lanseringsinnlegg, og det er verdt å behandle advarslene som krav.

• Arbeidere har bred tilgang.Begge forhåndsinnstillingene for tillatelser, for ruteren og for arbeiderne, kjører meddanger-full-accesssom operatørens OS-bruker. Kontoinnpakningene velger hvilken GitHub-legitimasjon agenten bruker, men dokumentene sier at de er standarder og ikke en sikkerhetsgrense, fordi en arbeider fortsatt kan kjøre et program med absolutt bane eller lese hjemmekatalogen din. Anbefalingen er en dedikert OS-konto som kun inneholder agentens legitimasjon.
• Uklarerte inndata er det åpne sikkerhetsspørsmålet.Artikkelen advarer om at hvis en umiddelbar injeksjon eller serverinntrengning kompromitterer skyagentsløyfen, kan hver tilkoblet enhet nås, og at legitimasjon som kommer inn i modellens kontekst kan lekke.
• Mennesker smelter sammen som standard.Agenten aktiverer aldri automatisk sammenslåing under sin egen konto. Automatisk sammenslåing trenger en annen kontos CLI navngitt i forespørselen om leveringskrav, og standardinstruksjonene tillater det bare for små, godkjente pull-forespørsler under 200 endrede linjer.
• Den er bygget rundt ett depot.Hvert oppsett ser på et enkelt GitHub-depot, og Feishu, et chat-verktøy som er vanlig i Kina, er den andre førsteklasses kilden.
• Du trenger DeepSeek-sele og en modellleverandør.Oppsett 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. Konfigurering av en modellleverandør er et operatørtrinn.
• Støy er en kostnad.Filosofidokumentet sier at man ikke skal bruke agenten til å produsere volum. Masse pull-forespørsler og kringkastingsmeldinger koster teamet ditt mer enn de gir.

Hvordan ville du prøve det uten å risikere hovedlageret ditt?

Oppsett har mange trinn, så prosjektet ber deg om å la en kodeagent gjøre det med deg. I følge README stiller agenten ett kort spørsmål om gangen, viser hele planen én gang, og installerer og konfigurerer deretter alt. Et forsiktig første løp ser slik ut:

1. Velg et engangslagerog en dedikert maskinbruker eller OS-konto. Ikke bruk din egen pålogging.
2. Opprett en separat GitHub-konto for agenten.Alt den skriver vises under det navnet.
3. Åpne depotet i kodeagenten din og lim inn ledeteksten nedenfor.Svar på spørsmålene ett om gangen.
4. Hold den tillatte listen for deg selvog la akseptmodus stå på observere.
5. Be om noe lite.Kommenter fra en tillatt konto@<agent login> <request>på en sak. En billett skal vises på panelets Oversikt innen omtrent et minutt.
6. Les Eval-fanen i en uke.Utvid listen eller bytt til auto bare når «ville godta»-postene ser riktige ut.

Read SETUP.md in this repository and set up dsh-superagent with me.

Prosjektets filosofidokument gir operatører fire regler som er verdt å gjenta: begynn smalt, still inn for mindre støy, ikke bruk agenten til å produsere volum, og eie det som står i ditt navn.

Hvor skal resten av agentens arbeid gå?

Anta at en arbeider bruker en time på en ustabil integreringstest. Pullforespørselen er løsningen. Men etterforskningen bak, hvilke tester som mislyktes, hvilke hypoteser den utelukket, hva tidstabellen viste, hører ikke hjemme i en PR-beskrivelse, og det er nettopp det anmelderen ønsker å utfordre. Hvis det bare lever i et chat-svar, starter neste agent eller lagkamerat fra bunnen av.

AgentGrid.ioer bygget for den overleveringen. Mennesker og AI-agenter jobber med de samme live-dokumentene, appene og filene, med én stabil adresse, kontrollert tilgang og en versjonshistorikk. AgentGrid.io sine dokumenter beskriver tilkobling av en kommando-kompatible agent ved å kjørenpx @animaapp/cli@latest login. Et menneske godkjenner agentens navn, team og hva det kan gjøre: lese, skrive, dele eller publisere. Etter det vises agentens endringer i historien under eget navn. Prototypen har ingen innebygd AgentGrid.io-integrasjon, så behandle dette som et mønster du kan prøve med arbeiderne, ikke en dokumentert funksjon.

I praksis skriver arbeideren sin undersøkelse som en Markdown-fil, anmelderen kommenterer en tabellrad, en annen assistent strammer inn sammendraget, og pull-forespørselen lenker til én gjeldende versjon i stedet for tre limte kopier.

For en annen versjon av flere personer som deler en agent, se vår guide tilGrok Bot Team Bots. Og hvis du lurer på hva som går under en vertsagent, vår guide tilClaude Managed Agentsser på Anthropic sin versjon av samme hjerne og hender splittet, som DeepSeek sin artikkel siterer.

Når bør du bruke dsh-superagent, og når noe annet?

• Bruk dsh-superagentå lære av et seriøst, dokumentert design, å kjøre et innesluttet eksperiment på et lavrisikodepot, eller å låne ideene: en ruter som aldri kjører kode, billetter med et angitt omfang, observasjonsmodus før automodus.
• Bruk en enkelt interaktiv kodeagentnår du jobber en oppgave om gangen og vil styre steg for steg. Super-agenten er bygget for den motsatte situasjonen.
• Bruk AgentGrid.ionår utdataene er et dokument, en rapport eller en app som flere personer og agenter trenger for å gjennomgå, redigere og publisere, uansett hvilken agent som har produsert det.

Ofte stilte spørsmål

Hva er DeepSeek Super-Agent?

Det er en forskningsprototype kalt dsh-superagent, utgitt av DeepSeeks Harness-team 31. oktober 2026 under MIT-lisensen. Det er en proaktiv kodeagent for ett GitHub-lager. En langvarig ruterøkt tar forespørsler og tildeler hver akseptert en til sin egen arbeiderøkt, som svarer i den opprinnelige samtalen, vanligvis med en pull-forespørsel.

Er DeepSeek Super-Agent et offisielt DeepSeek-produkt?

Nei. README kaller det en forskningsprototype kun for referanse og ikke et offisielt DeepSeek-produkt, og sier at du må vurdere og tilpasse det før du bruker det i ditt eget miljø. Den er heller ikke identisk med den interne versjonen eller med implementeringen designartikkelen beskriver.

Hvordan er en superagent forskjellig fra en underagent?

En underagent legger til et lag under arbeidsagenten. En superagent legger til et lag over seg. I dette designet sitter ruteren over mange arbeidere, snakker med folk og sender oppgaver, mens hver arbeider håndterer en oppgave isolert. Navnet handler om posisjon, ikke et krav om større intelligens.

Trenger den Feishu eller bare GitHub?

GitHub alene er nok. Feishu er en valgfri andre kilde, og dokumentasjonen sier at en Feishu-oppsettfeil deaktiverer bare Feishu-kilden.

Er det trygt å kjøre på et selskapslager?

Ikke som det er. Dokumentene sier at arbeidere kjører med full tilgang som operatørens OS-bruker og at wrapper-kontoene ikke er en isolasjonsgrense. De anbefaler en dedikert OS-konto, en dedikert agentkonto på GitHub, en kort tillatt liste og observasjonsmodus mens du lærer hvordan agenten oppfører seg.

Er det raskere enn en enkelt kodeagentøkt?

I forfatternes egen simulerte test fullførte ruterdesignet de tregeste oppgavene på 15,7 minutter mot 29,5 minutter for en enkelt økt med et subagentverktøy, ved å bruke flere tokens. Testen brukte simulert kodingsarbeid og fem kjøringer per design, så den viser planleggingsfordeler, ikke kodekvalitet.