DeepSeek Super-Agent: Mi ez, hogyan működik, és mi hiányzik még26 min read

Nyisson meg egyszerre három kódoló ügynököt, és érezheti a problémát. Az egyik döntésre vár, a másik húsz perce befejezte, és már elfelejtette, melyiknek van a hitelesítési javítása. A DeepSeek Harness csapata számot adott rá: tapasztalatai szerint egy személy egyszerre csak három-öt aktív ágens munkamenetet tud követni. Ezen a ponton túl a modell már nem a szűk keresztmetszet. Az vagy.

2026. október 31-én a csapat közzétett egy tervezési cikket az általa szuperügynöknek nevezett, nyílt forráskódú dsh-superagent prototípusról. Ez egy proaktív kódoló ügynök egy GitHub adattárhoz. Egy hosszú élettartamú útválasztó munkamenet beszél az emberekkel és osztja ki a munkát, és minden elfogadott kérés megkapja a saját munkamenetét, amely lehívási kéréssel vagy kérdéssel végződik. A tárház körülbelül két nap alatt 12 000 csillagot ért el. A README kimondja, hogy ez kutatási kód, és nem hivatalos DeepSeek termék.

Ez az útmutató azoknak a mérnököknek és csapatvezetőknek szól, akik tudni szeretnék, mit csinál a prototípus, hogyan működik a router és a dolgozó tervezése, mit tesznek és mit nem bizonyítanak a benchmark számok, és mit kell ellenőrizni, mielőtt egy valódi adattárra irányítaná.

Egy megjegyzés a részletek előtt. A dolgozók válasza a „hiba kijavítására” egy lehívási kérés, és a GitHub erre megfelelő otthon. A többit, amit az ágensek a kód köré produkálnak, nehezebb elhelyezni: a kiváltó ok feljegyzését, a teszt összefoglalóját, az összehasonlító táblázatot, amelyet a bíráló kért.AgentGrid.ioegy megosztott munkaterület, ahol az emberek és az AI-ügynökök dokumentumokat, alkalmazásokat és fájlokat hozhatnak létre, szerkeszthetnek és oszthatnak meg egyetlen élő verzióval, hozzárendeléssel és előzményekkel. A végéhez közeledve visszatérünk oda, ahová illik.

Mi az a DeepSeek Super-Agent?

Két dolog együtt jelent meg. Az első egy hosszú tervezési cikk, „Exploring Super-agent Design: Towards a More Autonomous Agent System”. A Harness csapata kínaiul írta, és egy gépi fordítású angol verziót is közzétett X-en november 1-jén. Több mint 2,2 millió alkalommal látták. A második a kód:deepseek-ai/dsh-superagent-prototípus, amelyet az MIT licence alapján adtak ki.

A szuperügynök-tervezés felfedezése: Egy autonómabb ügynökrendszer felé

https://t.co/gwwIHtyCRQ

– DeepSeek kábelköteg (@DeepSeekHarness)2026. november 1

Ez nem egy új modell. A dsh-superagent egy csomag ehhezDeepSeek kábelköteg, DeepSeek nyílt forráskódú ügynökkötege, amelyet a vállalat világszerte nyilvános előnézetként ír le. A csomag egy GitHub adattárat figyel, és ha bekapcsolja, a Feishu cseveg. Ha valaki az engedélyezett listán az ügynöktől munkát kér, az megnyit egy munkaelemet, lefuttatja azt a saját munkamenetében és könyvtárában, és az eredeti beszélgetésben válaszol. A webpanel csak azt mutatja, amire egy személynek szüksége van.

A név könnyebb, mint amilyennek hangzik. Cui Tianyi, a DeepSeek termékosztályának munkatársa és a cikk egyik utolsó értékelője egy Zhihu-bejegyzésben kifejtette, hogy a „szuper” kifejezés a felső és alsó indexet jelenti. A szuper-ügynök egy réteget ad a munkát végző ügynök fölé, az ellentéte az alárendelt ügynöknek, amely hozzáad egy réteget alatta. Ez nem a felsőbbrendű intelligencia állítása.

A README egy figyelmeztetéssel kezdődik, amelyet érdemes teljes egészében elolvasni: „Csak referenciaként kutassa a prototípust, nem hivatalos DeepSeek termékként.” Hozzáteszi, hogy a tervezés nagy részét kódoló ügynökök végezték, a kód hibákat tartalmazhat, és a cikkben szereplő egyes tervek a jövőbeli munkához irányulnak, és nincsenek implementálva.

Egy másik DeepSeek csepp: dsh-superagent

Ügynökkeretrendszer, amely a repo GitHub problémáin és PR-kon keresztül működik párhuzamosan sok ügynökkel, és úgy lett kialakítva, hogy a lehető legkevesebb emberi figyelmet fordítson a lehető legtöbb értékre.

pic.twitter.com/XR73mIvA0V

– Leandro von Werra (@lvwerra)2026. október 31

Miért mondja a DeepSeek, hogy a szűk keresztmetszet az emberi figyelem?

A cikk egy egyszerű megfigyeléssel indul. Az elmúlt év során a kódoló ügynökök elég jók lettek ahhoz, hogy egyetlen feladatot korlátozzon a modell. De ha több feladatot futtatsz egyszerre, a határ rád költözik. Minden munkamenet elszigetelt, így kézzel válthat közöttük, és nyomon követheti, hogy mindegyik mit tud. Ha egy CLI-t, MCP-et vagy csevegési csatlakozót egy helyi munkamenethez rögzít, akkor az új eseményekről hallhat, de továbbra is blokkolja a hosszú parancsokat, keveri a különböző feladatok kontextusait, és leáll, amikor a laptop alszik.

A DeepSeek válasza az, hogy ne kezelje a munkamenetet az Ön által kezelt egységként. Négy tulajdonságot sorol fel egy szuperügynöknek:

• Folyamatos.Ott beszél vele, ahol már dolgozik, például csevegésben vagy GitHub megjegyzésekben, és úgy viselkedik, mint egy ügynök. Ha a chatben kéred az A-tervet, és a lekérési kérés megjegyzésében váltasz át a B-tervre, az következik.
• Termékeny.Több összetett feladatot futtat párhuzamosan, és a következő utasítást az utolsó befejezése előtt veszi meg.
• Proaktív.Figyeli az eseményeket, cselekszik, amit érdemes kezelni, és egyébként csendben marad.
• Kitartó.Online marad, és a hibák után helyreáll anélkül, hogy újraindítaná.

A szerzők azzal érvelnek, hogy egyetlen ReAct hurok sem képes mind a négyet megvalósítani, ezért a tulajdonságoknak a modellt körülvevő architektúrából kell származniuk. Ez a cikk valódi témája, és az alábbi vizuális magyarázó, amelyet Hesam osztott meg, egy gyors módja annak, hogy a teljes dizájnt egy oldalon tekintse meg.

íme egy vizuális magyarázat a DeepSeek Super-Agentről szóló cikkéhez:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP

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

Hogyan működik a router és a dolgozó tervezése?

Gondolj egy jó mérnöki menedzserre, aki soha nem ír kódot standup közben. Arouteregy hosszú életű munkamenet, amely minden üzenetet fogad minden csatornáról. Nem futtat feladatokat. Eldönti, hogy mit kér az üzenet, új munkát ad át egy dolgozónak, és minden választ megír az érintetteknek. A cikk szerint shell eszköz nélkül is tud egyáltalán futni, és általában elég hozzá egy könnyebb, gyorsabb modell is.

Amunkásegy külön munkamenet egy elszigetelt kontextussal és egy teljes eszközkészlettel, egyetlen feladatra szentelve. A dolgozók soha nem beszélnek közvetlenül az emberekkel. Jelentik az állapotot az útválasztónak, amely egy hangon tartja a válaszokat. A prototípusban minden jegy saját munkamenetet és saját könyvtárat kap, jellemzően egy git-munkafát, és a dolgozók száma korlátozva van. Az alapértelmezett érték egyszerre három, 1-től 16-ig állítható, egy extra rés pedig szabadon marad, így a személy üzenete mindig eljut.

Két részlet teszi ezt többet, mint egy feladatsor.

A nyomon követések kihagyják az útválasztót.Ha egy dolgozó birtokol egy lehívási kérelmet vagy egy csevegési szálat, feliratkozik arra a szálra. A későbbi megjegyzések egyenesen erre vonatkoznak, a routernél nincs extra modellhívás. Ha kiderül, hogy egy megjegyzés valami másra vonatkozik, a dolgozó visszaadja azt.

A sorozatfelvételek csoportosulnak.Az egyik modell során érkező triggerek felpörgetik a sort, és együtt kerülnek be a következő hívásba. A szerzők mérték a hatást, mi pedig az alábbi számokat nézzük.

Még egy kontraszt. A cikk megkülönbözteti ezt az ügynökcsapattól. Egy ügynökcsapatban a vezető lépésekre bont egy összetett feladatot, és összehangolja a rajta dolgozó szerepeket, ami komoly gondolkodási terhelést jelent. A Super-agent útválasztó csak független feladatokat küld el, és magas szinten követi nyomon azok kapcsolatát. Magát a művet nem bontja le.

Mit csinál, ha senki nem kérdez?

Itt válik gyakorlativá a projekt filozófiája. A tárhely első dokumentuma egy sorban megfogalmazza az elvet: vegyél minél kevesebb emberi figyelmet, és adj minél több értéket. Minden üzenet, amit az ügynök küldött, egy kolléga figyelmét megterheli, így csak akkor szólal meg, ha egy személynek cselekednie kell, vagy használhat egy eredményt, és csak akkor cselekszik, ha kérik, vagy ha a csapat által írt szabály ezt lehetővé teszi.

Az ezt kikényszerítő kapu sima kód, nem modell. Ellenőrzi, hogy ki kér a csapat engedélyezett listájából, és rögzíti, hogy mennyire erős a kérés:

Ezt a megfigyelési módot szeretem a legjobban. Az ügynök azzal kezdi, hogy rögzíti, hogy mit csinált volna, így a csapat csak akkor tudja elolvasni ezeket a rekordokat az Eval lapon, és csak akkor tudja kiterjeszteni az engedélyeket, ha jól néz ki. Az üzeneteket, megjegyzéseket és idézett dokumentumokat a döntés inputjaként kezeljük. Nem módosíthatják azt, amit az ügynök tehet.

A tervezési cikk bemutatja, hogyan néz ki a proaktív munka a gyakorlatban. A belső DeepSeek Harness felhasználói csoportban a csapat beállított egy „néma reprodukálás és javítás” házirendet. Amikor valaki bejelent egy problémát vagy megvitat egy javasolt változtatást, az ügynök megpróbálja reprodukálni azt, és a háttérben javítást találni, és csak azután ad eredményt, hogy megerősítette a problémát és megtalálta az egyszerű javítást. Különben csendben marad. A cikk egy tompa szabályt is ad a csevegőcsatornákra, amelyeket a szerzők szerint ellenőriztek: minden válasz legfeljebb 100 szót tartalmazhat. Ezzel szemben a GitHub esetében a lekérési kéréseknek sűrűnek kell lenniük, a probléma hátterével, a változtatás leírásával és az ellenőrzési eredményekkel.

Alapértelmezés szerint minden, az ügynök által elküldött GitHub üzenet a következő sorral kezdődik: „Ezt egy automatizált ügynök írta, nem ember”. A csapatok szerkeszthetik ezt, a többi értesítéssel együtt.

A benchmark számok megállják a helyüket?

A cikk egy kis kísérletet tartalmaz, és a szerzők ügyelnek arra, hogy csak tájékoztató jellegűnek nevezzék. Négy terv futott egymás mellett a csoportos csevegési és CI-üzenetek folyamában: futamonként körülbelül 300 üzenet, ebből körülbelül 20 valódi munkakérés, egyenként öt futtatás. A kódolási munkát egy olyan eszköz szimulálta, amely egyszerűen időigényes, így a teszt az ütemezést és a koordinációt méri, nem pedig a bárki kódjának minőségét.

Olvassa el kétszer a táblázatot, mert a cím nem a teljes történet. Az útválasztó kialakítása a p95 befejezési idejét körülbelül a felére csökkentette az egyetlen munkamenethez képest, de nagyjából kétszer-négyszer annyi gyorsítótár-olvasási tokent használt. A legérdekesebb sor pedig a második: az áthidaló parancsikon eltávolítása nem gyorsította vagy lassította a feladatok befejezését, csupán körülbelül 30 százalékkal több döntést hoz a routerből, és 37 százalékkal több tokent éget el.

Azt olvasom, hogy az igazi lelet az egymenetes sorokban található. Semleges prompt esetén a modell soha nem hívott alágenst az öt futtatás egyikében sem. A munkát maga végezte, az új üzenetek folyamatosan megzavarták, a leglassabb feladatok pedig 29,5 percet vettek igénybe. A delegálásra felszólító felszólítással ötből négyben delegált, a fennmaradó futásban pedig a modell „kicsinek” ítélte a munkát, és maga végezte el. Egyetlen munkamenet a modell hangulatától függ. Az a router, amelyik nem futtathat kódot, nem követheti el ezt a hibát.

Egy különálló stresszteszt az útválasztón önmagában körülbelül 1-ről körülbelül 40 percre emelte a döntésre érdemes események érkezési arányát. Az átlagos köteg 1,0-ról 2,8-ra nőtt, a kérésenkénti idő csak 2,5-ről 3,9 másodpercre nőtt, a döntésenkénti amortizált idő pedig 6,4-ről 1,6 másodpercre csökkent. Minél több esemény halmozódik fel, annál olcsóbb lesz mindegyik, ami a szerzők szerint egy határig függ a kontextus hosszától és attól, hogy egy modell hány eseményt tud pontosan kezelni egy körben.

A DeepSeek most nyílt forráskódú Super-agent prototípusát. Egy útválasztó munkamenet beszél az emberekkel és osztja ki a munkát, az elszigetelt dolgozók pedig párhuzamosan hajtanak végre feladatokat a GitHub eseményeken. Saját tesztjükben a p95 befejezési ideje 29,5 percről 15,7 percre csökkent, összehasonlítva az egyetlen, segédanyagokkal végzett kezeléssel.

A bálna ismét nyílt forráskódú.pic.twitter.com/mS4sRbHmyx

– Pufók (@kimmonismus)2026. november 1

Ezek a szintetikus munkák saját bevallású eredményei. Azt mutatják, hogy az ütemezési ötlet megalapozott. Nem azt mutatják, hogy a prototípus gyorsabban javítja a hibákat.

Mit mondanak a projekthez közel állók a korlátairól?

Nem sokkal a megjelenés után Cui Tianyi, a DeepSeek termékosztályának munkatársa és a tervezési cikk egyik utolsó értékelője megírta, hogyan látja a dizájnt. Keretezése hasznos, mert szerény. A központi kompromisszumot a feladatok közötti folytonosságnak nevezi a feladat átviteli sebességével szemben.

A limiteken a felülvizsgálat közvetlen. A prototípus a javasolt tervnek csak egy részét valósítja meg. Áttekintése szerint a DeepSeek Harness nem rendelkezett beépített hosszú távú memóriával a munkamenetek során. A rendszert pedig csak a vállalaton belüli kis, megbízható környezetben validálták. A cikk saját nyílt problémákkal foglalkozó szakasza felsorolja az útválasztó méretezését, a hónapokig tartó memóriát, a munkamenetek nélküli munkát, az ügynökök közötti kontextushatárokat, valamint azt, hogy az elszigetelt ügynökök hogyan beszéljenek egymással, valamint a biztonsággal.

Mit kell ellenőrizni, mielőtt elindítaná?

A dokumentáció őszintébb, mint a legtöbb bevezetési poszt, és érdemes követelményként kezelni a figyelmeztetéseit.

• A dolgozók széles hozzáféréssel rendelkeznek.Mindkét előzetes engedély, az útválasztó és a dolgozók számára, futdanger-full-accessmint a kezelő operációs rendszer felhasználója. A fiók-burkolók kiválasztják, hogy az ügynök mely GitHub hitelesítő adatokat használja, de a dokumentumok szerint ezek alapértelmezések, és nem biztonsági határok, mivel a dolgozó továbbra is futtathat egy programot abszolút elérési úton, vagy olvashatja a kezdőkönyvtárat. Az ajánlás egy dedikált operációs rendszer-fiók, amely csak az ügynök hitelesítő adatait tartalmazza.
• A nem megbízható bevitel a nyitott biztonsági kérdés.A cikk arra figyelmeztet, hogy ha egy azonnali befecskendezés vagy szerverbehatolás veszélyezteti a felhőügynökhurkot, minden csatlakoztatott eszköz elérhető, és a modell környezetébe belépő hitelesítő adatok kiszivároghatnak.
• Az emberek alapértelmezés szerint egyesülnek.Az ügynök soha nem engedélyezi az automatikus egyesítést a saját fiókjában. Az automatikus egyesítéshez szükség van egy második fiók CLI-jére, amelyet a Kézbesítési követelmények mezőben kell megnevezni, és az alapértelmezett utasítások csak kis, jóváhagyott lekérési kérelmek esetén teszik lehetővé 200 módosított sor alatt.
• Egy tároló köré épül fel.Mindegyik beállítás egyetlen GitHub adattárat figyel, és a másik első osztályú forrás a Feishu, egy Kínában elterjedt munkahelyi csevegőeszköz.
• Szüksége van a DeepSeek kábelkötegre és egy modellszolgáltatóra.A telepítés listája a Node.js 22.19 vagy újabb, a pnpm, a git 2.32 vagy újabb, a tmux, a Python 3.8 vagy újabb és a GitHub CLI 2.48 vagy újabb. A modellszolgáltató konfigurálása egy kezelői lépés.
• A zaj költség.A filozófiai dokumentum azt mondja, hogy ne használjuk az ügynököt mennyiség előállítására. A tömeges lekérések és a sugárzott üzenetek többe kerülnek a csapatnak, mint amennyit adnak.

Hogyan próbálnád ki anélkül, hogy kockáztatnád a fő tárhelyedet?

A beállítás sok lépésből áll, ezért a projekt arra kéri, hogy engedje meg egy kódoló ügynöknek, hogy ezt Önnel együtt végezze el. A README szerint az ügynök egyszerre egy rövid kérdést tesz fel, egyszer megmutatja a teljes tervet, majd mindent telepít és konfigurál. Egy óvatos első futás így néz ki:

1. Válasszon kidobható tárolótés egy dedikált gépfelhasználó vagy operációs rendszer fiók. Ne használja saját bejelentkezési adatait.
2. Hozzon létre egy külön GitHub-fiókot az ügynök számára.Minden, amit ír, ezen a néven jelenik meg.
3. Nyissa meg a tárolót a kódoló ügynökben, és illessze be az alábbi promptot.Egyenként válaszoljon a kérdéseire.
4. Tartsa meg magának az engedélyezett listátés hagyja az elfogadási módot megfigyelés alatt.
5. Kérj valami apróságot.Egy engedélyezett fiókból írjon megjegyzést@<agent login> <request>egy kérdésben. Egy jegynek körülbelül egy percen belül meg kell jelennie a panel Áttekintésében.
6. Olvassa el az Eval lapot egy hétig.Csak akkor bővítse ki a listát, vagy váltson automatikusra, ha az „elfogadná” rekordok megfelelőnek tűnnek.

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

A projekt filozófiai dokumentuma négy szabályt ad az üzemeltetőknek, amelyeket érdemes megismételni: kezdje szűken, hangoljon kisebb zajra, ne használja az ügynököt a hangerő előállítására, és birtokolja, amit az Ön nevében ír.

Hová kerüljön az ügynök többi munkája?

Tegyük fel, hogy egy dolgozó egy órát tölt egy gyenge integrációs teszttel. A lehívási kérelem a megoldás. De a mögötte lévő nyomozás, mely tesztek kudarcot vallottak, mely hipotéziseket zárta ki, mit mutatott az időzítési táblázat, nem tartozik a PR-leírásba, és pont ezt akarja a bíráló megtámadni. Ha ez csak a chat-válaszban él, a következő ügynök vagy csapattárs a nulláról kezdi.

AgentGrid.ioerre az átadásra készült. Az emberek és az AI-ügynökök ugyanazokon az élő dokumentumokon, alkalmazásokon és fájlokon dolgoznak, egyetlen stabil címmel, ellenőrzött hozzáféréssel és verzióelőzményekkel. Az AgentGrid.io dokumentumai leírják egy parancsképes ügynök csatlakoztatását futtatássalnpx @animaapp/cli@latest login. Egy ember jóváhagyja az ügynök nevét, csapatát és azt, hogy mit tehet: olvas, ír, oszt meg vagy tesz közzé. Ezt követően az ügynök változásai a saját neve alatt jelennek meg az előzményekben. A prototípus nem rendelkezik beépített AgentGrid.io integrációval, ezért kezelje ezt mintaként, amelyet a dolgozókkal próbálhat ki, nem dokumentált szolgáltatásként.

A gyakorlatban a dolgozó Markdown fájlként írja meg a vizsgálatot, a lektor megjegyzést ír egy táblázatsorra, egy másik asszisztens megszigorítja az összefoglalót, és a lekérési kérelem három beillesztett másolat helyett egy aktuális verzióra hivatkozik.

Ha egy másik ügynököt szeretne megosztani több emberrel, tekintse meg útmutatónkatGrok Bot Team Bots. És ha kíváncsi arra, hogy mi rejtőzik egy fogadott ügynök alatt, tekintse meg útmutatónkatClaude Managed Agentsmegvizsgálja a Anthropic változatát, amely ugyanannak az agynak és a kezek kettévált, amelyet a DeepSeek cikk idéz.

Mikor érdemes használni a dsh-superagent-et, és mikor mást?

• Használja a dsh-superagent-ettanulni egy komoly, dokumentált tervezésből, lefuttatni egy zárt kísérletet egy alacsony kockázatú adattáron, vagy kölcsönözni annak ötletét: egy útválasztó, amely soha nem futtat kódot, jegyek megadott hatókörrel, megfigyelési mód az automatikus mód előtt.
• Használjon egyetlen interaktív kódoló ügynökötamikor egy-egy feladattal dolgozik, és lépésről lépésre szeretne irányítani. A szuperügynök az ellenkező helyzetre készült.
• Használja az AgentGrid.io-tamikor a kimenet egy dokumentum, jelentés vagy alkalmazás, amelyet több embernek és ügynöknek kell átnéznie, szerkesztenie és közzétennie, függetlenül attól, hogy melyik ügynök készítette.

Gyakran ismételt kérdések

Mi az a DeepSeek Super-Agent?

Ez egy dsh-superagent nevű kutatási prototípus, amelyet a DeepSeek Harness csapata adott ki 2026. október 31-én az MIT licence alapján. Ez egy proaktív kódoló ügynök egy GitHub adattárhoz. Egy hosszú élettartamú útválasztó munkamenet fogadja a kéréseket, és mindegyiket hozzárendeli a saját dolgozói munkamenetéhez, amely az eredeti beszélgetésben válaszol, általában lehívási kéréssel.

A DeepSeek Super-Agent hivatalos DeepSeek termék?

Nem. A README csak referenciaként szolgáló kutatási prototípusnak nevezi, nem pedig hivatalos DeepSeek terméknek, és azt mondja, hogy tekintse át és adaptálja, mielőtt saját környezetében használná. Nem azonos sem a belső verzióval, sem a tervezési cikkben leírt megvalósítással.

Miben különbözik a szuper-ügynök az al-ügynöktől?

Egy segédügynök hozzáad egy réteget a munkaágens alá. A szuperügynök egy réteget ad fölé. Ebben a kialakításban az útválasztó sok dolgozó felett ül, beszélget az emberekkel és küldi el a feladatokat, míg minden dolgozó egy feladatot elszigetelten kezel. A név a pozícióról szól, nem pedig a nagyobb intelligencia igényéről.

Feishu kell hozzá vagy csak a GitHub?

A GitHub önmagában elég. A Feishu egy opcionális második forrás, és a dokumentáció szerint a Feishu telepítési hiba csak a Feishu forrást tiltja le.

Biztonságos-e céges adattáron futtatni?

Nem úgy, ahogy van. A dokumentumok szerint a dolgozók teljes hozzáféréssel futnak az üzemeltető operációs rendszer-felhasználójaként, és hogy a wrapper fiókok nem jelentenek elkülönítési határt. Javasolnak egy dedikált operációs rendszer-fiókot, egy dedikált ügynökfiókot a GitHub-en, egy rövid engedélyezett listát és megfigyelési módot, miközben megtanulja, hogyan viselkedik az ügynök.

Gyorsabb, mint egyetlen kódoló ügynök munkamenet?

A szerzők saját szimulált tesztjében a router tervezése a leglassabb feladatokat 15,7 perc alatt végezte el, szemben az egyetlen munkamenet 29,5 percével egy segédeszközzel, több token használatával. A teszt szimulált kódolási munkát és tervezésenként öt futtatást használt, így az ütemezési előnyöket mutatja, nem a kód minőségét.