DeepSeek otevřel agenta pro celý tým. Tvrdým limitem už není model, ale lidská pozornost

DeepSeek otevřel agenta pro celý tým. Tvrdým limitem už není model, ale lidská pozornost

Když dnes někdo nasadí AI agenta na práci, většinou to vypadá takhle: otevře okno, zadá úkol, čeká. Druhý úkol znamená druhé okno, třetí třetí. DeepSeek teď zveřejnil prototyp, který tuhle hranici posouvá, a k němu popis, proč ho postavil právě takhle.

Kód je na GitHubu od soboty 31. října pod licencí MIT, která dovoluje kód používat a upravovat i komerčně. Popis architektury vyšel v neděli. Za dva dny si repozitář připsal přes 10 tisíc hvězd, což je u firemního prototypu nezvyklé číslo.

Prototyp se jmenuje dsh-superagent a je to doplněk pro DeepSeek Harness, běhové prostředí pro agenty od stejné firmy, které je zatím ve veřejném preview. Sám DeepSeek v popisu uvádí, že jde o výzkumný prototyp, ne o oficiální produkt, a že velkou část vývoje odvedli coding agenti.

Úzké místo není model, ale počet oken

Autoři problém pojmenovali přesně. Běžný agent má jako základní jednotku práce jednu session, tedy jedno vlákno konverzace. Vlákna jsou od sebe izolovaná. Kdo jich pustí víc, musí mezi nimi přepínat a pamatovat si, co je v kterém. Podle zkušenosti týmu DeepSeek udrží člověk najednou tři až pět aktivních vláken. Jeden úkol tedy limituje schopnost modelu, ale několik úkolů najednou limituje pozornost člověka.

Jejich řešení má dvě patra. Router je jedno dlouho běžící vlákno, které mluví s lidmi a drží souvislý kontext. Workeři dostanou každý svůj úkol, vlastní vlákno a vlastní složku na disku. Nová zpráva k rozdělanému úkolu jde rovnou workerovi, který ho má na starosti, a router se do ní nemíchá. Router řeší jen začátky nových úkolů a koordinaci mezi nimi.

Filtr, který pustí model jen k tomu, co má smysl

Agent poslouchá jeden repozitář na GitHubu a volitelně firemní chat Feishu. Většina zpráv v takovém provozu nic nepotřebuje: lidé si povídají, doplňují detaily, ruší zadání, přicházejí hlášení z testů. Kdyby každou zprávu posuzoval velký model, bylo by to drahé a pomalé.

Proto má filtr dvě úrovně. První je programová a běží bez modelu: hlídá zdroj, skupinu a seznam povolených lidí a botů. Každý zdroj má jeden ze tří režimů: reagovat jen na výslovnou žádost, brát zprávy jako kandidáty, nebo je ignorovat. Druhá úroveň je jazyková a teprve ta pustí model na zprávy, které prošly. Většina šumu zmizí dřív, než se model vůbec spustí.

Agent začne dřív, než ví, že to bude potřeba

Zajímavý je i takzvaný spekulativní běh. Agent může začít pracovat na pozadí, ještě než je jasné, že výsledek někdo použije. Když se hodí, doručí ho. Když ne, zahodí ho a nikomu nic nepošle.

Ve své interní vývojářské skupině mají nastavené pravidlo „potichu reprodukuj a oprav“. Když někdo nahlásí problém nebo navrhne změnu, agent ho nejdřív zkusí zreprodukovat a najít opravu. Ozve se, až když problém potvrdí a má jednoduché řešení. Do té doby mlčí.

Co naměřili a co to znamená

Autoři změřili čtyři uspořádání na stejné zátěži: proud zpráv ze skupinového chatu a z průběžného testování. Každý běh měl kolem 300 zpráv, z toho zhruba 20 skutečných požadavků na práci. Programátorskou práci simuloval nástroj, který jen spotřebovává čas, takže test měří plánování a koordinaci, ne kvalitu kódu. Každé uspořádání běželo pětkrát.

• Router a workeři: medián 12,4 minuty, p95 15,7 minuty
• Stejný systém bez přímého doručování zpráv workerům: 12,6 a 15,5 minuty
• Jedna session s neutrálním zadáním: 20,4 a 29,5 minuty
• Jedna session s pokynem delegovat na podagenty: 13,8 a 29,0 minuty

p95 je doba, do které doběhne 95 procent úkolů, takže popisuje i pomalejší případy. Rozdíl proti jedné session je osm minut v mediánu a skoro čtrnáct minut v p95. Systém za to ale zaplatil vyšším počtem tokenů: 23,2 milionu přečtených z cache proti 6,1 milionu u jedné session, zhruba 3,8krát víc. Token je jednotka textu, se kterou model počítá. Autoři to říkají otevřeně: kratší a stabilnější časy kupují za víc výpočtu.

Jeden router zvládne víc, než čekali

Druhý experiment se ptal, jak velkou zátěž udrží jediný router. Když počet událostí, které potřebují rozhodnutí, rostl zhruba z 1 na 40 za minutu, průměrná dávka narostla z 1,0 na 2,8. Čas na jeden požadavek stoupl z 2,5 na 3,9 sekundy, tedy pomaleji než dávka. Průměrný čas na jedno rozhodnutí tak klesl z 6,4 na 1,6 sekundy. Jinými slovy: čím víc práce najednou přichází, tím lépe se stíhá, protože se zprávy sloučí do jedné dávky.

Kde to zatím skřípe

Nejužitečnější část materiálu je ta, kde si autoři přiznávají limity. U kódu uvádějí, že jde o výzkumný prototyp, který může obsahovat chyby a který je potřeba před nasazením projít. V dokumentaci varují, že obaly a složky kolem workerů nejsou bezpečnostní hranice, protože worker může spustit program i přes absolutní cestu.

V článku jdou dál. Událostmi řízený návrh vystavuje agenta víc nedůvěryhodnému vstupu. Když běží smyčka agenta v cloudu a na koncových zařízeních leží soukromé repozitáře a přihlašovací údaje, útok na cloud nebo podstrčený pokyn v textu může znamenat převzetí všech připojených zařízení. Automatické sloučení pull requestu proto agent ve výchozím nastavení nezapíná sám, protože GitHub připíše sloučení účtu, který ho zapnul. Když tým povolí jiný účet, platí podmínky: požadavek založený daným úkolem, potřebná schválení a do 200 změněných řádků.

Co si z toho vzít

Prototyp není produkt a čísla pocházejí z umělé zátěže, ne z ostrého provozu. Přesto z materiálu jde vyčíst tři otázky, které se hodí položit u každého nasazení agenta.

• Kolik pozornosti si agent vezme. Každá zpráva, dotaz a oznámení stojí člověka pozornost. Agent, který hlásí každý krok, spotřebuje víc, než udělá.
• Kdy smí jednat bez ptaní. Rozhoduje pravidlo, které tým napsal, ne improvizace modelu. DeepSeek proto doporučuje začít se seznamem povolených lidí a s režimem, kdy agent jen zaznamenává, co by udělal.
• Kdo schvaluje výsledek. U kódu je to pull request, ne přímý zápis do hlavní větve.

DeepSeek tím hlavně ukázal, že další zrychlení nemusí brzdit model, ale počet oken, která jsme schopni sledovat. Kdo staví agenta pro tým, měl by ho měřit tímhle metrem, ne délkou seznamu funkcí.