DeepSeek Super-Agent: mikä se on, miten se toimii ja mitä vielä puuttuu18 min read
Reading Time: 9 minutesAvaa kolme koodausagenttia kerralla ja voit tuntea ongelman. Yksi odottaa päätöstä, toinen valmistui kaksikymmentä minuuttia sitten, ja olet jo unohtanut, kummalla on todennuskorjaus. DeepSeek:n valjaattiimi asetti sille numeron: sen kokemuksen mukaan henkilö voi seurata vain kolmesta viiteen aktiivisen agentin istuntoa kerrallaan. Sen jälkeen malli ei ole enää pullonkaula. Olet.
Tiimi julkaisi 31. lokakuuta 2026 suunnitteluartikkelin superagentiksi kutsutusta aiheesta ja avoimen lähdekoodin prototyypin nimeltä dsh-superagent. Se on ennakoiva koodausagentti yhdelle GitHub-tietovarastolle. Yksi pitkäikäinen reititinistunto puhuu ihmisille ja jakaa töitä, ja jokainen hyväksytty pyyntö saa oman työntekijäistunnon, joka päättyy vetopyyntöön tai kysymykseen. Arkisto ylitti 12 000 tähteä noin kahdessa päivässä. Sen README kertoo suoraan, että tämä on tutkimuskoodi eikä virallinen DeepSeek-tuote.
Tämä opas on tarkoitettu insinööreille ja tiimin johtajille, jotka haluavat tietää, mitä prototyyppi tekee, kuinka reitittimen ja työntekijän suunnittelu toimii, mitä vertailuluvut tekevät ja eivät todista ja mitä on tarkistettava ennen sen osoittamista oikeaan arkistoon.
Yksi huomautus ennen yksityiskohtia. Työntekijän vastaus ”korjaa tämä virhe” on vetopyyntö, ja GitHub on hyvä koti sille. Loput, mitä agentit tuottavat koodin ympärille, on vaikeampi sijoittaa: perussyyn kirjoittaminen, testin yhteenveto, arvioijan pyytämä vertailutaulukko.AgentGrid.ioon jaettu työtila, jossa ihmiset ja tekoälyagentit luovat, muokkaavat ja jakavat asiakirjoja, sovelluksia ja tiedostoja yhdellä live-versiolla, ansioksilla ja historialla. Palaamme siihen, mihin se sopii lähellä loppua.
Mikä on DeepSeek Super-Agent?
Kaksi asiaa ilmestyi yhdessä. Ensimmäinen on pitkä suunnitteluartikkeli ”Exploring Super-agent Design: Towards a More autonomous Agent System”. Harness-tiimi kirjoitti sen kiinaksi ja julkaisi konekäännetyn englanninkielisen version X:llä 1. marraskuuta. Se on nähty yli 2,2 miljoonaa kertaa. Toinen on koodi:deepseek-ai/dsh-superagent-prototyyppi, julkaistu MIT-lisenssillä.
Superagenttisuunnittelun tutkiminen: Kohti autonomisempaa agenttijärjestelmää
– DeepSeek-valjaat (@DeepSeekHarness)1. marraskuuta 2026
Se ei ole uusi malli. dsh-superagent on pakettiDeepSeek johtosarja, DeepSeek:n avoimen lähdekoodin agenttivaljaat, joita yritys kuvailee julkiseksi esikatseluksi maailmanlaajuisesti. Paketti tarkkailee yhtä GitHub-tietovarastoa ja, jos kytket sen päälle, Feishu chattaa. Kun joku sallittujen luettelossa olevista kysyy agentilta työtä, se avaa työkohteen, ajaa sen omassa istunnossaan ja hakemistossaan ja vastaa alkuperäisessä keskustelussa. Verkkopaneeli näyttää vain sen, mitä henkilö tarvitsee.
Nimi on helpompi kuin miltä se kuulostaa. Cui Tianyi, DeepSeek:n tuoteosastolta ja yksi artikkelin viimeisistä arvioijista, selitti Zhihu-viestissä, että ”super” tarkoittaa yläindeksiä alaindeksiä vastaan. Superagentti lisää kerroksen työn tekevän agentin yläpuolelle, päinvastoin kuin aliagentti, joka lisää kerroksen sen alle. Se ei ole väite korkeammasta älykkyydestä.
README alkaa varoituksella, joka kannattaa lukea kokonaan: ”Tutki prototyyppiä vain viitteeksi, ei virallinen DeepSeek-tuote.” Se lisää, että suuren osan suunnittelusta tekivät koodausagentit, että koodi saattaa sisältää virheitä ja että jotkin artikkelin mallit ovat ohjeita tulevaa työtä varten, eikä niitä ole otettu käyttöön.
| Yhdellä silmäyksellä | dsh-superagent-prototyyppi |
|---|---|
| Mikä se on | Ennakoiva koodausagentti yhdelle GitHub-tietovarastoon, pakattuna DeepSeek-johtosarjana |
| Tila | Tutkimusprototyyppi, ”ei tuotantovalmis ohjelmisto” README:n mukaan |
| Lisenssi | MIT |
| Kieli | TypeScript |
| Kuuntelee | GitHub-ongelmat, vetopyynnöt, kommentit ja CI. Feishu-chatit ovat valinnaisia |
| Luotu | 31. lokakuuta 2026. Yli 12 000 tähteä ja 1 200 haarukkaa 2. marraskuuta mennessä |
| Kuinka määrittää se | Pyydä koodausagenttia lukemaan SETUP.md ja määrittämään se kanssasi |
Toinen DeepSeek-pisara: dsh-superagent
Agenttikehys, joka käsittelee repon GitHub-ongelmat ja PR:t useiden agenttien kanssa rinnakkain, ja joka on suunniteltu viemään mahdollisimman vähän ihmisten huomiota ja tuottamaan mahdollisimman paljon arvoa.
– Leandro von Werra (@lvwerra)31. lokakuuta 2026
Miksi DeepSeek sanoo, että pullonkaula on ihmisen huomio?
Artikkeli alkaa yksinkertaisesta havainnosta. Kuluneen vuoden aikana koodausagentit ovat kehittyneet tarpeeksi hyviksi, jotta malli rajoittaa yksittäistä tehtävää. Mutta kun suoritat useita tehtäviä kerralla, raja siirtyy sinulle. Jokainen istunto on eristetty, joten voit vaihtaa niiden välillä käsin ja seurata, mitä kukin tietää. CLI:n, MCP:n tai chat-liittimen kiinnittäminen yhteen paikalliseen istuntoon antaa sen kuulla uusista tapahtumista, mutta se silti estää pitkiä komentoja, sekoittaa eri tehtävien konteksteja ja pysähtyy, kun kannettava tietokone nukkuu.
DeepSeek:n vastaus on lopettaa istunnon käsitteleminen hallitsemanasi yksikkönä. Siinä luetellaan neljä ominaisuutta, jotka superagentilla tulisi olla:
- Jatkuva.Puhut sille siellä, missä jo työskentelet, kuten chatissa tai GitHub-kommenteissa, ja se käyttäytyy kuin yksi agentti. Jos kysyt suunnitelmaa A chatissa ja vaihdat suunnitelmaan B vetopyynnön kommentissa, se seuraa.
- Tuottava.Se suorittaa useita monimutkaisia tehtäviä rinnakkain ja ottaa seuraavan ohjeen ennen kuin viimeinen päättyy.
- Ennakoiva.Se seuraa tapahtumia, toimii sen mukaan, mikä kannattaa käsitellä ja pysyy muuten hiljaa.
- Pysyvä.Se pysyy verkossa ja toipuu vioista ilman, että käynnistät sen uudelleen.
Kirjoittajat väittävät, ettei yksikään ReAct-silmukka voi toimittaa kaikkia neljää, joten ominaisuuksien on tultava mallia ympäröivästä arkkitehtuurista. Tämä on artikkelin todellinen aihe, ja alla oleva visuaalinen selitys, jonka Hesam jakaa, on nopea tapa nähdä koko suunnittelu yhdeltä sivulta.
tässä on visuaalinen selitys DeepSeek:n artikkelista Super-Agentista:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP
– ℏεsam (@Hesamation)1. marraskuuta 2026
Miten reitittimen ja työntekijän suunnittelu toimii?
Ajattele hyvää suunnittelupäällikköä, joka ei koskaan kirjoita koodia standupissa. Thereititinon yksi pitkäikäinen istunto, joka vastaanottaa jokaisen viestin jokaiselta kanavalta. Se ei suorita tehtäviä. Se päättää, mitä viesti pyytää, antaa työntekijälle uuden työn ja kirjoittaa jokaisen vastauksen asianosaisille. Artikkelissa sanotaan, että se voi toimia ilman kuorityökalua ollenkaan ja että kevyempi, nopeampi malli riittää yleensä siihen.
Atyöntekijäon erillinen istunto, jossa on erillinen konteksti ja täydellinen työkalusarja, joka on omistettu yhteen tehtävään. Työntekijät eivät koskaan puhu ihmisten kanssa suoraan. Ne ilmoittavat tilan reitittimelle, joka pitää vastaukset yhdellä äänellä. Prototyypissä jokainen lippu saa oman istunnon ja oman hakemistonsa, tyypillisesti git-työpuun, ja työntekijöiden määrä on rajoitettu. Oletusarvo on kolme kerrallaan, säädettävissä 1–16, ja yksi ylimääräinen paikka pidetään vapaana, jotta henkilön viesti pääsee aina perille.
Kaksi yksityiskohtaa tekevät tästä enemmän kuin tehtäväjonon.
Jatkotoimet ohittavat reitittimen.Kun työntekijä omistaa vetopyynnön tai chat-ketjun, hän tilaa sen. Myöhemmät kommentit menevät suoraan siihen ilman ylimääräistä mallipuhelua reitittimessä. Jos kommentti osoittautuu jostain muusta, työntekijä luovuttaa sen takaisin.
Purskeet kerätään.Yhden mallin aikana saapuvat triggerit nostavat jonon ja ruiskutetaan yhdessä seuraavaan kutsuun. Kirjoittajat mittasivat vaikutuksen, ja katsomme alla olevia lukuja.

Vielä yksi kontrasti. Artikkeli erottaa tämän agenttitiimistä. Agenttitiimissä liidi jakaa yhden monimutkaisen tehtävän vaiheisiin ja koordinoi siinä toimivat roolit, mikä on raskas päättelykuorma. Super-agent-reititin lähettää vain itsenäisiä tehtäviä ja seuraa niiden välistä yhteyttä korkealla tasolla. Se ei hajoa itse teosta.
Mitä se tekee kun kukaan ei kysy?
Tässä projektin filosofia tulee käytännönläheiseksi. Arkiston ensimmäinen asiakirja kertoo periaatteen yhdellä rivillä: ota mahdollisimman vähän ihmisen huomiota ja anna mahdollisimman paljon arvoa. Jokainen agentin lähettämä viesti maksaa kollegan huomion, joten se puhuu vain silloin, kun henkilön on toimittava tai hän voi käyttää tulosta, ja se toimii vain pyydettäessä tai kun tiimin kirjoittama sääntö sallii sen.
Tätä pakottava portti on pelkkä koodi, ei malli. Se tarkistaa, kuka kysyy joukkueen sallittujen luettelosta ja kirjaa, kuinka vahva pyyntö on:
| Vahvuus | Esimerkkejä asiakirjoista | Mitä tapahtuu |
|---|---|---|
| Selkeä | Sallittujen luettelossa oleva henkilö mainitsee agentin tai seuraa viestiketjua, jolla on jo lippu | Välittäjä hyväksyy työn kaikissa tiloissa |
| Päätelty | Botti lähteen robottiluettelossa tai listaamattoman henkilön seuranta. Osoittamaton viesti, jonka joukkue päätti vastaanottaa | Arvioitu joukkueen kirjallisten sääntöjen mukaan. Oletustarkkailutilassa se tallennetaan vain ”hyväksyisi” |
| Ei hyväksytty | Mikä tahansa muu botti, mikä tahansa sisäänpääsytaulukko huomioimatta | Pudotettu ennen kuin mitään mallia kutsutaan |
Tuo tarkkailutila on osa, josta pidän eniten. Agentti aloittaa kirjaamalla, mitä se olisi tehnyt, joten tiimi voi lukea ne tietueet Eval-välilehdeltä ja laajentaa käyttöoikeuksiaan vain, kun ne näyttävät oikealta. Viestit, kommentit ja lainatut asiakirjat käsitellään päätöksenteon syötteinä. He eivät voi muuttaa sitä, mitä agentti saa tehdä.
Suunnitteluartikkeli näyttää, miltä ennakoiva työ näyttää käytännössä. Sisäisessä DeepSeek Harness -käyttäjäryhmässä tiimi määritti ”äänetön toista ja korjaa” -käytännön. Kun joku ilmoittaa ongelmasta tai keskustelee ehdotetusta muutoksesta, agentti yrittää toistaa sen ja löytää taustalla korjauksen, ja se antaa tuloksen vasta, kun se on vahvistanut ongelman ja löytänyt yksinkertaisen korjauksen. Muuten pysyy hiljaisena. Artikkelissa annetaan myös tylsä sääntö chat-kanaville, jotka kirjoittajat sanovat vahvistaneensa: kunkin vastauksen enimmäispituus on 100 sanaa. GitHub:ssä sitä vastoin vetopyyntöjen tulee olla tiheitä, ja niissä on oltava ongelman tausta, muutoksen kuvaus ja vahvistustulokset.
Oletuksena jokainen agentin lähettämä GitHub-sanoma alkaa rivillä ”Tämä on automatisoidun agentin, ei ihmisen” kirjoittama. Tiimit voivat muokata sitä muiden kehotteiden kanssa.
Pysyvätkö vertailuluvut?
Artikkeli sisältää pienen kokeilun, ja kirjoittajat ovat varovaisia kutsumaan sitä vain suuntaa-antavaksi. Neljä mallia kulki rinnakkain ryhmäkeskustelu- ja CI-viestien virrassa: noin 300 viestiä ajoa kohti, joista noin 20 oli todellisia työpyyntöjä, viisi ajoa kussakin. Koodaustyötä simuloitiin työkalulla, joka yksinkertaisesti kuluttaa aikaa, joten testi mittaa ajoitusta ja koordinaatiota, ei kenenkään koodin laatua.
| Suunnittelu | Tehtävän suorittamisaika, p50 / p95 (min) | Välimuistin lukutunnukset ajoa kohden |
|---|---|---|
| Superagentti | 12.4 / 15.7 | 23,2 milj |
| Superagentti ilman läpikulkua | 12.6 / 15.5 | 31,8 milj |
| Yksi istunto subagent-työkalulla, neutraali kehote | 20.4 / 29.5 | 6,1 milj |
| Yksi istunto aliagenttityökalulla, delegointikehote | 13,8 / 29,0 | 10,8 milj |
Lue taulukko kahdesti, koska otsikko ei ole koko tarina. Reitittimen suunnittelu lyhensi p95:n valmistumisajan noin puoleen yhden istunnon ajasta, mutta se käytti noin kahdesta neljään kertaa enemmän välimuistin lukutunnisteita. Ja mielenkiintoisin rivi on toinen: läpimenopikakuvakkeen poistaminen ei saanut tehtävät valmiiksi nopeammin tai hitaammin, se vain sai reitittimen tekemään noin 30 prosenttia enemmän päätöksiä ja polttamaan 37 prosenttia enemmän tokeneita.
Olen lukenut, että todellinen löytö on yhden istunnon riveillä. Neutraalilla kehotteella malli ei koskaan kutsunut aliagenttia missään viidestä ajosta. Se teki työn itse, uudet viestit keskeyttivät sen ja hitaimmat tehtävät kestivät 29,5 minuuttia. Kehotteen, joka käski delegoida, se delegoi neljässä viidestä ajossa, ja lopulla malli arvioi työn ”pieneksi” ja teki sen itse. Yksittäinen istunto riippuu mallin mielialasta. Reititin, jolla ei ole lupaa suorittaa koodia, ei voi tehdä tätä virhettä.
Pelkästään reitittimen erillinen stressitesti nosti päätöksen arvoisten tapahtumien saapumisasteen noin yhdestä noin 40:een minuutissa. Keskimääräinen erä kasvoi 1,0:sta 2,8:aan tapahtumaan, pyyntökohtainen aika nousi vain 2,5 sekunnista 3,9 sekuntiin ja poistoaika päätöstä kohti laski 6,4:stä 1,6 sekuntiin. Mitä enemmän tapahtumia kasaantuu, sitä halvemmaksi kukin niistä tulee, tekijöiden mukaan tiettyyn rajaan asti, joka riippuu kontekstin pituudesta ja siitä, kuinka monta tapahtumaa malli pystyy käsittelemään tarkasti yhdessä vuorossa.
DeepSeek julkaisi juuri avoimen lähdekoodin Super-agent-prototyyppinsä. Yksi reititinistunto puhuu ihmisille ja jakaa töitä, ja yksittäiset työntekijät suorittavat tehtäviä rinnakkain GitHub-tapahtumien kanssa. Heidän omassa testissään p95:n valmistumisaika putosi 29,5 minuutista 15,7 minuuttiin verrattuna yksittäiseen istuntoon, jossa käytettiin aliaineita.
Valas avoimen lähdekoodin jälleen.pic.twitter.com/mS4sRbHmyx
– Pullea (@kimmonismus)1. marraskuuta 2026
Nämä ovat itse ilmoittamia tuloksia synteettisestä työstä. Ne osoittavat, että aikatauluidea on hyvä. Ne eivät osoita, että prototyyppi korjaa virheet nopeammin.
Mitä projektin läheiset sanovat sen rajoista?
Pian julkaisun jälkeen Cui Tianyi DeepSeek:n tuoteosastolta ja yksi suunnitteluartikkelin viimeisistä arvioijista kirjoitti, miten hän näkee suunnittelun. Hänen kehystyksensä on hyödyllinen, koska se on vaatimaton. Hän nimeää keskeisen kompromissin jatkuvuuden tehtävien välillä vs. tehtävien läpikulkukyky.
Limiteissä tarkastelu on suora. Prototyyppi toteuttaa vain osan ehdotetusta suunnitelmasta. Hänen tarkastelunsa mukaan DeepSeek-valjaissa ei ollut sisäänrakennettua pitkäaikaista muistia istuntojen aikana. Ja järjestelmä on validoitu vain pienessä, luotettavassa ympäristössä yrityksen sisällä. Artikkelin omassa avoimet ongelmat -osiossa luetellaan reitittimen skaalaus, kuukausien muisti, työskentely ilman istuntoja, agenttien väliset kontekstirajat ja kuinka eristyneiden agenttien tulisi keskustella toistensa kanssa sekä tietoturva.
Mitä kannattaa tarkistaa ennen käyttöä?
Dokumentaatio on rehellisempi kuin useimmat laukaisuviestit, ja sen varoitukset kannattaa käsitellä vaatimuksina.
- Työntekijöillä on laaja pääsy.Molemmat käyttöoikeudet, reitittimelle ja työntekijöille, toimivat
danger-full-accessoperaattorin käyttöjärjestelmän käyttäjänä. Tilin kääreet valitsevat, mitä GitHub-tunnistetietoja agentti käyttää, mutta asiakirjat sanovat, että ne ovat oletusarvoja eivätkä suojausrajoja, koska työntekijä voi silti ajaa ohjelmaa absoluuttista polkua pitkin tai lukea kotihakemistoasi. Suositus on omistettu käyttöjärjestelmätili, jolla on vain agentin kirjautumistiedot. - Epäluotettava syöttö on avoin turvakysymys.Artikkeli varoittaa, että jos nopea injektio tai palvelimen tunkeutuminen vaarantaa pilviagenttisilmukan, jokainen yhdistetty laite voidaan tavoittaa ja että mallin kontekstiin tulevat tunnistetiedot voivat vuotaa.
- Ihmiset sulautuvat oletuksena.Agentti ei koskaan ota käyttöön automaattista yhdistämistä omalla tilillään. Automaattinen yhdistäminen vaatii toisen tilin CLI:n, joka on nimetty Toimitusvaatimukset-kehotteessa, ja oletusohjeet sallivat sen vain pienille, hyväksytyille vetopyynnöille, jotka ovat alle 200 muutettua riviä.
- Se on rakennettu yhden arkiston ympärille.Jokainen kokoonpano tarkkailee yhtä GitHub-tietovarastoa, ja Feishu, Kiinassa yleinen työpaikan chat-työkalu, on toinen ensiluokkainen lähde.
- Tarvitset DeepSeek-valjaat ja mallintoimittajan.Asennusluettelossa on Node.js 22.19 tai uudempi, pnpm, git 2.32 tai uudempi, tmux, Python 3.8 tai uudempi ja GitHub CLI 2.48 tai uudempi. Mallintoimittajan määrittäminen on käyttäjän vaihe.
- Melu on hinta.Filosofiadokumentti sanoo, ettei agenttia saa käyttää volyymin tuottamiseen. Joukkovetopyynnöt ja lähetysviestit maksavat tiimillesi enemmän kuin antavat.
Kuinka kokeilisit sitä vaarantamatta päävarastoasi?
Asennus sisältää monia vaiheita, joten projekti pyytää sinua antamaan koodausagentin tehdä sen kanssasi. README:n mukaan agentti kysyy yhden lyhyen kysymyksen kerrallaan, näyttää kerran koko suunnitelman ja sitten asentaa ja määrittää kaiken. Varovainen ensimmäinen juoksu näyttää tältä:
- Valitse hävitettävä varastoja erillinen koneen käyttäjä tai käyttöjärjestelmätili. Älä käytä omaa kirjautumistasi.
- Luo agentille erillinen GitHub-tili.Kaikki, mitä se kirjoittaa, näkyy tällä nimellä.
- Avaa arkisto koodausagentissasi ja liitä alla oleva kehote.Vastaa sen kysymyksiin yksi kerrallaan.
- Pidä sallittujen luettelo itselläsija jätä hyväksymistila tarkkailutilaan.
- Pyydä jotain pientä.Kommentoi sallitulta tililtä
@<agent login> <request>asiasta. Lipun pitäisi ilmestyä paneelin yleiskatsaukseen noin minuutin kuluessa. - Lue Eval-välilehteä viikon ajan.Laajenna luetteloa tai vaihda automaattiseen käyttöön vain, kun ”hyväksyisi”-tietueet näyttävät oikealta.
Projektin filosofiadokumentti antaa operaattoreille neljä toistamisen arvoista sääntöä: aloita kapeasti, viritä vähemmän kohinaa, älä käytä agenttia volyymin tuottamiseen ja omista se, mitä se sanoo omassa nimessäsi.
Mihin agentin muun työn pitäisi mennä?
Oletetaan, että työntekijä viettää tunnin hitaaseen integrointitestiin. Vetopyyntö on korjaus. Mutta sen takana oleva tutkimus, mitkä testit epäonnistuivat, mitkä hypoteesit sulkivat pois, mitä ajoitustaulukko osoitti, ei kuulu PR-kuvaukseen, ja se on juuri se, mitä arvioija haluaa haastaa. Jos se elää vain chat-vastauksessa, seuraava agentti tai joukkuetoveri aloittaa alusta.
AgentGrid.ioon rakennettu tätä kanavanvaihtoa varten. Ihmiset ja tekoälyagentit työskentelevät samojen reaaliaikaisten asiakirjojen, sovellusten ja tiedostojen parissa yhdellä vakaalla osoitteella, hallituksella ja versiohistorialla. AgentGrid.io:n dokumentit kuvaavat komentokykyisen agentin yhdistämisen suorittamallanpx @animaapp/cli@latest login. Ihminen hyväksyy agentin nimen, tiimin ja sen, mitä se voi tehdä: lukea, kirjoittaa, jakaa tai julkaista. Sen jälkeen agentin muutokset näkyvät historiassa omalla nimellä. Prototyypissä ei ole sisäänrakennettua AgentGrid.io-integraatiota, joten pidä tätä mallina, jota kokeillaan sen työntekijöiden kanssa, ei dokumentoituna ominaisuutena.
Käytännössä työntekijä kirjoittaa tutkimuksensa Markdown-tiedostoksi, arvioija kommentoi taulukon riviä, toinen avustaja tiukentaa yhteenvetoa ja vetopyyntö linkittää yhteen nykyiseen versioon kolmen liitetyn kopion sijaan.
Katso oppaastamme, jos haluat toisen otoksen useista saman agentin jakavista ihmisistäGrok Bot Team Botit. Ja jos mietit, mitä isännöidyn agentin alla kulkee, oppaammeClaude Managed Agentstarkastellaan Anthropic:n versiota samoista aivoista ja käsien jakautumisesta, jota DeepSeek:n artikkeli lainaa.
Milloin sinun pitäisi käyttää dsh-superagent ja milloin jotain muuta?
- Käytä dsh-superagentoppia vakavasta, dokumentoidusta suunnitelmasta, suorittaa sisäinen kokeilu alhaisen riskin arkistossa tai lainata sen ideoita: reititin, joka ei koskaan suorita koodia, liput ilmoitetulla laajuudella, tarkkailutila ennen automaattista tilaa.
- Käytä yhtä interaktiivista koodausagenttiakun työskentelet yhtä tehtävää kerrallaan ja haluat ohjata askel askeleelta. Superagentti on rakennettu päinvastaiseen tilanteeseen.
- Käytä AgentGrid.io:takun tulos on dokumentti, raportti tai sovellus, joka useiden ihmisten ja agenttien on tarkistettava, muokattava ja julkaistava, riippumatta siitä, kumpi agentti sen on tuottanut.
Usein kysytyt kysymykset
Mikä on DeepSeek Super-Agent?
Se on dsh-superagent-niminen tutkimusprototyyppi, jonka DeepSeek:n valjaattiimi julkaisi 31. lokakuuta 2026 MIT-lisenssillä. Se on ennakoiva koodausagentti yhdelle GitHub-varastolle. Pitkäikäinen reititinistunto ottaa vastaan pyynnöt ja määrittää jokaisen hyväksytyn omalle työistuntolleen, joka vastaa alkuperäisessä keskustelussa, yleensä vetopyynnöllä.
Onko DeepSeek Super-Agent virallinen DeepSeek-tuote?
Ei. README kutsuu sitä tutkimusprototyypiksi vain viitteeksi, ei viralliseksi DeepSeek-tuotteeksi, ja kehottaa tarkistamaan ja mukauttamaan sitä ennen kuin käytät sitä omassa ympäristössäsi. Se ei myöskään ole identtinen sisäisen version tai suunnitteluartikkelissa kuvatun toteutuksen kanssa.
Miten superagentti eroaa aliagentista?
Ala-agentti lisää kerroksen työaineen alle. Superagentti lisää kerroksen sen yläpuolelle. Tässä mallissa reititin istuu useiden työntekijöiden yläpuolella, puhuu ihmisille ja lähettää tehtäviä, kun taas jokainen työntekijä hoitaa yhden tehtävän erillään. Nimi kertoo asemasta, ei vaatimusta suuremmasta älykkyydestä.
Tarvitseeko se Feishu vai vain GitHub?
Pelkkä GitHub riittää. Feishu on valinnainen toinen lähde, ja ohjeiden mukaan Feishu-asennusvirhe poistaa käytöstä vain Feishu-lähteen.
Onko turvallista käyttää yrityksen tietovarastoa?
Ei sellaisenaan. Asiakirjat sanovat, että työntekijät käyttävät täydet käyttöoikeudet operaattorin käyttöjärjestelmän käyttäjinä ja että kääretilit eivät ole eristysraja. He suosittelevat omaa käyttöjärjestelmätiliä, omistettua agenttitiliä GitHub:ssä, lyhyttä sallittujen luetteloa ja tarkkailutilaa samalla, kun opit agentin käyttäytymistä.
Onko se nopeampi kuin yksi koodausagentin istunto?
Tekijöiden omassa simuloidussa testissä reitittimen suunnittelu suoritti hitaimmat tehtävät 15,7 minuutissa verrattuna 29,5 minuuttiin yhdellä istunnolla aliagenttityökalulla käyttämällä enemmän tokeneita. Testissä käytettiin simuloitua koodaustyötä ja viisi ajoa suunnittelua kohden, joten se näyttää ajoitusedut, ei koodin laatua.

Figma
Adobe XD


