Máš repozitář, ve kterém se hromadí issues, review komentáře a červené CI a nestíháš to? DeepSeek Superagent (repozitář dsh-superagent) je open-source prototyp agenta, který hlídá jeden GitHub repozitář, na pokyn si otevře samostatnou úlohu, pracuje v ní ve vlastním adresáři a odpoví tam, kde ses ptal – třeba pull requestem. Hlavní myšlenka: zabrat co nejméně lidské pozornosti a dát co nejvíc užitku. Tenhle článek ti ukáže, jak Superagent funguje, co z něj zatím reálně běží a jak ho nastavit, aby tým neotravoval.
Důležité hned na začátku: autoři ho sami označují za výzkumný prototyp, ne oficiální produkt DeepSeeku. Nezkoušeli jsme ho nasadit na ostrém repozitáři, vycházíme z oficiálního README, dokumentace a z toho, co o něm psala média. Co jsme neověřili, jasně říkáme.
V kostce: co je DeepSeek Superagent
Repozitář deepseek-ai/dsh-superagent-prototype vznikl 31. října 2026 pod licencí MIT, je napsaný v TypeScriptu a je to balíček (bundle) pro DeepSeek Harness. K 3. listopadu 2026 měl podle GitHub API přes 15 tisíc hvězdiček, takže zájem je obrovský. Zájem ale neznamená, že je to hotový nástroj do produkce.
Agent poslouchá GitHub (volitelně i chat Feishu). Když o práci požádá někdo, kdo na to má právo, vytvoří pracovní úlohu, spustí ji v samostatné relaci a výsledek pošle zpátky do původní konverzace. Webový panel ukazuje jen to, co potřebuje člověka. Kdo už zkoušel paralelní Claude Code s git worktrees, pozná podobnou logiku: každá úloha má vlastní adresář, aby se agenti nepraly o soubory.
Pro koho týmy, které už agenty v repozitáři používají a řeší, jak je nenechat zahltit lidi notifikacemi. Cena: kód je zdarma (MIT), platíš model a provoz. Ceny DeepSeek modelů najdeš v článku DeepSeek V4 Pro: levná alternativa ke Claude a ChatGPT.
Jak DeepSeek Superagent funguje: Router, Workery a tikety
Návrh stojí na dvou vrstvách. Router komunikuje s lidmi a rozděluje práci. Workery práci dělají, každý ve vlastní relaci. Podle anglického překladu a shrnutí DeepSeekova článku z 31. 10. 2026 na blogu CellCog (CellCog je firma, která staví vlastní AI zaměstnance, čti to tedy jako pohled účastníka trhu) autoři vycházejí z toho, že člověk sleduje nanejvýš tři až pět aktivních relací najednou, takže omezením není model, ale lidská pozornost.
V dokumentaci se opakuje několik pojmů:
- Source je zdroj událostí (GitHub, Feishu). Zahazuje zprávy samotného bota a pamatuje si, kde skončil, takže po restartu neopakuje staré události.
- Thread je vlákno událostí, například issue nebo pull request.
- Eval posoudí, jestli zpráva žádá o novou práci.
- Ticket je jednotka schválené práce. Vytváří ho jen Eval.
- Mandate říká, proč a v jakém rozsahu smí agent pracovat. Je neměnný; širší rozsah znamená nový ticket.
Každý ticket dostane relaci worker-<id> a vlastní adresář. Před první prací může běžet „prepare“ příkaz (typicky git worktree, má na to deset minut). Pull request patří k ticketu, když poslední část názvu větve odpovídá krátkému jménu ticketu. Při výpadku modelu nebo sítě (HTTP 408, 429, 5xx) se pokus opakuje třikrát se zvětšující pauzou.
Kdo smí agentovi zadat práci
Tady je nejzajímavější část pro každého, kdo se bojí, že mu agent začne psát všem. Podle dokumentace jedná agent jen na výslovnou žádost, nebo když to povoluje pravidlo, které napsal tým.
- Žádost se počítá, jen když oslovuje agenta přímo a přichází od člověka na seznamu povolených (nebo z prostoru, který tým pro žádosti otevřel).
- Dokud v seznamu není nikdo, žádná žádost se nezmění na ticket.
- Zprávy, komentáře ani citované dokumenty nemohou rozšířit oprávnění; seznamy a pravidla vynucuje hostitel, ne model.
- Boti smějí vytvořit nanejvýš „odvozeného kandidáta“, nikdy výslovnou žádost, a jen ti, které tým uvedl v seznamu botů.
Tohle je přesně ta vrstva, kterou při obraně proti prompt injection potřebuješ: text v issue je vstup, ne příkaz.
Režimy off, observe a auto: začni v observe
Práce, kterou nikdo nezadal, se řídí režimem přijímání:
| Režim | Co dělá |
|---|---|
off |
Nic odvozeného se nestane kandidátem. |
observe (výchozí) |
Kandidáti se posoudí, ale jen se zaznamená, že by agent práci přijal. Nic se neprovede. |
auto |
Kladné posouzení odvozeného kandidáta práci přijme. |
Výslovné žádosti fungují ve všech režimech. Doporučený postup z dokumentace: nechat běžet observe, projít zaznamenaná rozhodnutí a teprve potom přepnout na auto. Proaktivní práce navíc vyžaduje, aby odpovídalo aspoň jedno pravidlo, které tým napsal. Ve větším týmu se k téhle opatrnosti hodí i dohled druhé AI nad agenty.
Jak DeepSeek Superagent nastavit krok za krokem
Postup vychází z 006-deployment.md a README. Nečekej instalaci na jeden příkaz: setup je záměrně vedený tvým vlastním coding agentem.
1. Připrav prostředí
Potřebuješ Node.js 22.19+ nebo 24+, pnpm, git 2.32+, Python 3.8+ a tmux. Dále DeepSeek Harness s nastaveným poskytovatelem modelu a samostatný profil (v návodu superagent) oddělený od toho, ve kterém běžně pracuješ – plugin totiž mění PATH a nastavení gitu pro celý proces.
2. Nech agenta, ať tě provede
README doporučuje říct svému coding agentovi: „Read SETUP.md in this repository and set up dsh-superagent with me.“ Ptá se po jedné krátké otázce, jednou ukáže celý plán a pak vše nainstaluje.
3. Nastav zdroj GitHub
V nastavení zadáš repozitář (owner/name) a příkaz agentova GitHub CLI. Požadavky normálně chodí přes notifikace účtu agenta. Přepínače observeIssues, observePulls, observeComments a observeCi jsou ve výchozím stavu vypnuté; zapneš je, až když chceš, aby agent viděl vše. Nový komentář s označením agenta dorazí při dalším průzkumu (výchozí interval je minuta), ale dopsání zmínky do těla existujícího issue ne – napiš nový komentář.
4. Přidej povolené lidi
V sekci Policy přidej GitHub účty, které smějí zadávat práci. Začni krátkým seznamem. Dokumentace radí: začni úzce a rozšiřuj, až bude jasné, co by agent udělal.
5. Zkus první požadavek
Z povoleného účtu otevři issue nebo napiš komentář s @<login agenta> <žádost>. Během jednoho intervalu průzkumu se v přehledu má objevit ticket, agent žádost potvrdí a odpoví v původní konverzaci.
Slučování a pověření: kdo mergeuje
Prompt „Delivery requirements“ řídí auto-merge a hostitel žádnou vlastní logiku slučování nepřidává. Podle Help Net Security (2. 11. 2026) agent ve výchozím stavu auto-merge pod svým účtem nezapíná, protože GitHub připisuje merge tomu, kdo ho zapnul. Pokud prompt neurčí jiný účet, mergují lidé. Tím spíš si projdi, jak reviewovat AI generovaný kód, než PR schválíš.
Při instalaci navíc setup odstraní z prostředí proměnné s názvem obsahujícím KEY, PASSWORD, SECRET nebo TOKEN a pro github.com použije jen přihlašovací údaje agentova CLI. To je rozumný základ, ale rozhodně to nenahrazuje oddělený účet s minimálními právy.
Co ukazují testy DeepSeeku (a proč je číst opatrně)
Podle téhož shrnutí DeepSeekova článku vývojáři zkoušeli syntetický proud zhruba 300 zpráv z chatu a CI, z toho asi 20 skutečných žádostí o práci, pětkrát za setup. Kódování nahradil nástroj, který jen spotřebovává čas – test tedy měří plánování, ne kvalitu kódu.
- Superagent dokončil žádosti s mediánem 12,4 minuty a 95. percentilem 15,7 minuty.
- Jedna relace s nástrojem na subagenty a neutrálním promptem nedelegovala ani v jednom z pěti běhů; p95 bylo 29,5 minuty.
- Při zátěži kolem 40 spouštěčů za minutu klesl čas inference na jedno rozhodnutí Routeru z 6,4 na 1,6 sekundy.
DeepSeek výsledky sám nazývá předběžnými. Nejde o benchmark opravování chyb ani o srovnání s Claude Code či Codexem. Pro srovnání, jak vypadá delegování v jiném nástroji, se podívej na Codex Cloud.
Co o tom říká YouTube a X
Tady buď opatrný. K videím jsme se nedostali: YouTube po nás chtěl přihlášení kvůli kontrole botů, takže jsme neviděli ani transkripty. Víme jen, jak jsou videa nazvaná a popsaná ve výsledcích vyhledávání. Prozatím jde o názvy typu „Super-Agent Explained“ nebo návody k instalaci, většinou od nezávislých autorů. U jednoho z nich popis výslovně uvádí, že není spojený se společností DeepSeek – před instalací z cizího návodu proto vždy porovnej odkazy s oficiálním repozitářem deepseek-ai.
Na X jsme zachytili jen úvodní řádky příspěvků. Tón je převážně nadšený: „agent, který pracuje na tvých GitHub repozitářích“, „agent, který ví, kdy mlčet“, a Leandro von Werra z Hugging Face ho podle CellCog označil za „další DeepSeek drop“. Celá vlákna a diskusi jsme nečetli, takže tady nic nehodnotíme. Hodnotit dá smysl jen to, co je v README a dokumentaci.
Rizika a otevřené otázky
DeepSeek v návrhu sám přiznává nevyřešené věci: škálování za jednu relaci Routeru, to, jak mají lidé s agenty pracovat, když relace zmizí z obrazovky, hranice kontextu mezi instancemi a bezpečnost. U bezpečnosti je upřímný: kdyby někdo ovládl cloudovou smyčku, ohrožuje to všechny připojené stroje. Prototyp navíc nemá všechno, co návrh popisuje.
Praktické závěry:
- Nepouštěj ho na produkční repozitář s citlivým kódem jako první krok.
- Používej samostatný účet agenta s minimálními právy a bez práva mergovat.
- Dej mu málo povolených lidí a režim
observe. - Sleduj, jak často píše. Dokumentace chce hlasité agenty zkrátit a zpřísnit, ne vysvětlovat. Jak sledovat chování agenta, popisuje i článek o monitorování AI agentů v produkci.
Časté otázky
Je DeepSeek Superagent oficiální produkt DeepSeeku?
Ne. README říká, že jde o výzkumný prototyp pouze pro referenci, který není oficiálním produktem DeepSeeku, a kód může obsahovat chyby.
Kolik DeepSeek Superagent stojí?
Samotný kód je pod licencí MIT, tedy zdarma. Platíš za model poskytovatele, kterého nastavíš v DeepSeek Harness, a za provoz.
Může agent sám mergovat pull requesty?
Ve výchozím nastavení ne. Auto-merge řídí prompt Delivery requirements a agent ho pod svým účtem nezapíná. Pokud prompt neurčí jiný účet, mergují lidé.
Jak zabráním tomu, aby agent všem psal?
Začni s krátkým seznamem povolených lidí a v režimu observe, kdy se nová proaktivní práce jen zaznamenává. Teprve po kontrole zaznamenaných rozhodnutí zvaž auto.
Funguje to i s jinými modely než od DeepSeeku?
V dokumentaci je Superagent balíček pro DeepSeek Harness a používá model výchozí pro profil, pokud nastavení Eval nebo Execution neurčí jiný. Jaké modely konkrétně Harness podporuje, jsme neověřovali.
Co si z toho vzít
DeepSeek Superagent je zajímavý hlavně jako vzor, ne jako hotový nástroj: agent, který mlčí, dokud ho někdo nepožádá nebo nepovolí pravidlo, a každou práci dělá ve vlastním adresáři. Chceš-li si ho vyzkoušet, čti nejdřív filozofii a dokumentaci o oprávněních, spusť ho na zkušebním repozitáři a nech ho týden v režimu observe. Pokud se chceš o agentech učit víc, začni u Claude Code subagentů.
