Životní cyklus odeslání agenta

Co je odeslání

Odeslání je jeden běh jednoho agenta, v jedné konverzaci, na jednom adaptéru. Celé se to odehrává na cc_server: klient pošle zprávu a pak sleduje, jak se události streamují zpátky. V žádném klientovi cesta odeslání není.

Agenti se probouzejí ze šesti důvodů. Běh je nese jako kontext probuzení, aby agent věděl, proč je vzhůru:

Důvod probuzení	Spouštěč
userMessage	Někdo poslal zprávu v prostoru, nebo agenta zmínil
assignment	Agentovi byl přiřazen ticket
pipelineStep	Odeslal ho krok pipeline
childCompleted	Dokončil se dceřiný ticket
followUp	Naplánovaný kontrolní tep
recovery	Cesta obnovy ho po selhání odeslala znovu

Kontext probuzení nese id, která k důvodu patří: ticket, prostor, zprávu a běh pipeline. Vloží se do prostředí agenta i do promptu.

Skládání promptu

Prompt se skládá po vrstvách. Každá vrstva je pojmenovaná sekce:

• Identita: vlastní id agenta, jméno a id pracovního prostoru, s výslovným pokynem předat nástrojům vázaným na pracovní prostor přesně tahle UUID. Pracovní prostor k agentovi patří, takže je v promptu vždy.
• Katalog nástrojů a protokoly zdrojů, potom rozložení pracovního prostoru.
• Přepsání systémového promptu, pokud ho agent má, potom persona (podle role) a týmové zadání.
• Skilly: názvy, které agent nese.
• Kontrakt provedení a postup pro aktuální režim.
• Kontext probuzení a kontext zmínky: kdo agenta přivolal a sestava kolem něj.
• Blok režimu vzniká z profilu schopností režimu a z materializovaného seznamu jeho nástrojů, takže prompt nikdy nejmenuje nástroj, který běh ve skutečnosti nemá.
• Kontext paměti: fakta stažená k úkolu.
• Kontext konverzace: nedávná historie prostoru, nanejvýš 50 000 znaků doslovného okna, bez ohledu na nastavenou velikost kontextu agenta. Starší historie se neořezává. Agent si ji na požádání načte přes get_messages a sémanticky blízké starší zprávy se pořád objeví.

Příkazy s lomítkem se čtou ze surového textu uživatele

Vrstvený prompt začíná blokem kontextu, takže nezačíná lomítkem. Příkazy se vezmou doslova ze zprávy uživatele a pak se vystřihnou z konce vrstveného promptu, aby každá vrstva kontextu zůstala.

Příkazy se dělí na dvě místa. /todo a /compact zachytí pole zprávy a záměrně se nikdy neuloží jako zprávy ani nepošlou agentovi. Uložit /compact by posunulo řez kompakce o tah zpátky a zašpinilo přepis. /plan se řeší na obou stranách: pole zprávy přepne režim prostoru, a právě tím se pro tenhle tah i pro každý další sejde sada nástrojů, předvolba guardů a prompt. /goal, /loop a /skill:<name> se řeší uvnitř běhu a jen na vestavěném harnessu. /goal a /loop spustí autonomní práci s rozpočtem nákladů a jméno s předponou skill: se najde jako skill, jehož tělo SKILL.md se stane pokynem tahu. Jmenný prostor drží oba slovníky od sebe. Když se holé jméno rozlišovalo proti skillům, skill jménem plan nebo compact zůstal natrvalo ve stínu vestavěného příkazu. Holé jméno, které vestavěné není, se pořád rozliší, kvůli zprávám napsaným před vznikem jmenného prostoru. Nerozpoznané jméno projde jako obyčejný text.

Příprava worktree

Než se cokoli spustí, dostane konverzace vlastní pracovní kořen a pod ním izolovaný copy-on-write worktree na každý repozitář. Ve výchozím stavu je to každý repozitář navázaný na pracovní prostor. Prostor pull requestu, nebo prostor založený s výslovným výběrem, připraví jen repozitáře ze seznamu povolených. Konverzace revize PR připne svůj jediný repozitář na head ref pull requestu a ostatní nechá na výchozí větvi. Zdrojový checkout se nikdy nemění a celý adresář konverzace se při smazání prostoru uvolní.

Copy-on-write je jediná implementace všude, kde se dodává rift, a stojí na přibalené nativní knihovně. Souborový systém, který neumí reflink, nebo datový adresář na jiném svazku než repozitář, přípravu shodí. Náhradní cesta není. git worktree je backend na Windows, kde copy-on-write backend není z čeho sestavit, a na ostatních hostitelích to není tiché zhoršení. Chybějící rift na platformě, která ho dodává, znamená rozbitou instalaci. Server odmítne naběhnout, místo aby potichu ustoupil: tichý ústup by poruchu schoval za pomalejší cestu natrvalo.

Identita a pověření

Na každý běh se před startem jakéhokoli procesu vyřeší dvě identity.

Autorství v Gitu. Commit, který agent udělá, je autorovaný jako agent: <Name> (agent) <agentId@agents.control-center.local> v GIT_AUTHOR_* i v GIT_COMMITTER_*. Za člověka se nikdy nevydává. Místní část adresy je UUID agenta, ne slug jména. Žádající člověk je v traileru Co-Authored-By:, který jede v prostředí a je přikázaný v systémovém promptu. Identita, kterou volající nastaví výslovně, vyhraje nad oběma.

Identita ve forgi. Pověření GitHubu pro běh je vždy jen od brokeru: token instalace App vázaný na repozitář, nebo záložní PAT z prostředí. Nikdy uložený token žádajícího člena. actingUserId ohraničí záložní PAT, aby člen, který není vlastníkem serveru, nezdědil dosah serveru. Osobní token do prostředí agenta nepřekryje.

Pověření poskytovatele modelu se řeší v pevném pořadí a na pořadí záleží:

1. přepsání prostředí u adaptéru,
2. prostředí volajícího,
3. úložiště pověření na serveru (token OAuth se obnoví, když se blíží konec platnosti),
4. prostředí procesu.

Přepsání u adaptéru je první, takže potichu přebije účet poskytovatele připojený v aplikaci. Když běh účtuje špatný účet, podívej se nejdřív tam. Pověření poskytovatelů platí pro celého hostitele a sdílí je každý pracovní prostor na instalaci.

Token GitHub běhu jde z brokeru pověření: je jen pro čtení a vázaný na repozitář worktree. Push jde přes bránu běhů agentů, která se před předáním dál zeptá pravidla Odeslat na remote, a žádný klíč k ticketům se nevkládá. Viz Sandbox a zabezpečení.

Spuštění

Běh se spustí s worktree jako pracovním adresářem a u Claude Code ještě s vygenerovanou konfigurací MCP, aby agent dosáhl na sadu nástrojů Control Center. ACP a bash harnessu dostanou očištěné prostředí. Claude Code přes NoSandboxAdapter dědí prostředí hostitele.

Sandbox operačního systému obalí běh jen tam, kde má hostitel backend

cc_server hostitele při startu jednou osondá. Když je backend k dispozici, obalí v něm procesy agentů: Seatbelt na macOS, bubblewrap na Linuxu a na WSL2. Obalí se obě cesty odeslání, protože nesdílejí jednu. CLI Claude Code jde přes port sandboxu. Adaptéry ACP a nástroj bash vestavěného harnessu jdou přes správce sandboxu. Tou samou cestou se uplatní chráněné cesty běhu: tvoje registrované checkouty repozitářů mají uvnitř sandboxu zákaz zápisu, v každém režimu.

Kde backend není, běh není v sandboxu a nic jiného to nenahrazuje. To platí vždy na Windows (nativní obal není; microvm je samostatná cesta braná sondou, pro terminály a stanice) a na Linuxu nebo WSL2 bez bwrap a socat na PATH. Server na řádku startovacího logu řekne, ve kterém stavu je. --sandbox off sandbox vypne schválně.

Dvě skuliny zůstanou i tam, kde sandbox běží. Souborové nástroje harnessu v procesu (read, write, edit, apply patch, search, find, search_files) běží uvnitř procesu serveru, takže je neváže žádný profil. Drží je jen vlastní omezení cest nástrojů a guardraily. Claude Code se navíc spouští s --dangerously-skip-permissions, takže jeho volání souborů Control Center nehlídá a jeho příkazy shellu hlídá jen hook, který čte příkazový řádek. Kolem nich je hranicí sandbox operačního systému.

Ostatní hranice platí na každém hostiteli, se sandboxem i bez něj: vlastní worktree běhu (copy-on-write tam, kde se dodává rift; git worktree na Windows), token forge jen pro čtení, který broker přidělí při spuštění a odebere při úklidu, pushe, které musí projít pravidlem pro push v bráně běhů agentů, sjednocené guardraily akcí (při selhání se zavře: rozhodnutí prompt bez připojeného schvalovatele se zamítne) a sada nástrojů, kterou režim konverzace dovolí. ACP a bash harnessu prostředí pořád čistí. Claude Code přes NoSandboxAdapter dědí prostředí hostitele.

Streamování

Běh streamuje zpět typovanou řadu událostí. Procesor streamu je ukládá jako přírůstky zpráv, skládá do segmentů přepisu a mění na události zpráv:

Událost	Co nese
thinking	Výstup uvažování, vykreslený v řádku
text	Viditelný výstup
toolCall	Vyvolání nástroje, s jeho id a strukturovanými argumenty
toolResult	Odpovídající výsledek, označený, když skončil chybou nebo je to neúplný proud
usage	Počty tokenů a cena za měřicí okno
error	Chyba, se strukturovaným kódem adaptéru, když ho nahlásil
sandboxViolation	Operační systém zamítl systémové volání. Vysílá se jen tam, kde sandbox proces opravdu obaluje. Viz poznámka výše
debug	Diagnostika za běhu (značky spuštění, rozhodnutí guardů, postrčení kontraktu)
done	Běh skončil

Co běh ohraničuje

Záměrně nikde není strop tahů. Pevný počet iterací zabíjí legitimní dlouhou práci (migrace, úklid po rozvětvení) a nechytí nic, co guardy níže chytí dřív. Běh skončí, když:

• se model zastaví sám;
• ho zastaví člověk, nebo převezme konverzaci (to pozastaví vestavěný harness na další čisté hranici tahu; běh Claude Code, který bezpečnou hranici nemá, se místo toho zastaví);
• spustí hlídač ticha. Žádný výstup po dobu prahu a relace skončí selháním silentRun. Výchozí hodnota je 15 minut, v režimech, které hlavně čtou (revize a plán), klesá na 10. Agent ji může přepsat v rozmezí 1 až 240 minut. Hlídač se aktivuje, když dceřiný proces nahlásí své PID, takže pokrývá CLI Claude Code, ne vestavěný harness, který nic nespouští;
• narazí se na strop nákladů, ale jen u autonomních příkazů.

Ochrana před zacyklením běh neukončuje: tři stejná volání nástroje za sebou a smyčka agenta nasměruje, aby změnil postup.

Běžný tah nemá strop nákladů

Hlídač nákladů uvnitř relace je zapojený jen u /goal a /loop. Každý jiný běh nepředává žádný rozpočet. U těchto příkazů může jeden bezobslužný segment ve výchozím stavu spotřebovat 500 centů ($5.00). Při 80 % přijde měkké nasměrování, ať agent čistě skončí, než přijde tvrdé zastavení, a trvalý rozpočet cíle je 5000 centů ($50.00) přes všechny segmenty. Celý segment nikdy nepřestřelí výslovné /goal --budget.

Běžný interaktivní tah na vestavěném harnessu tak nemá strop tahů, strop nákladů ani hlídače ticha. Skončí, když se model zastaví, nebo když ho zastavíš. Je to záměrný kompromis: každá alternativa zabíjí legitimní dlouhou práci. Bezobslužný interaktivní běh tak neohraničuje nic než vlastní úsudek modelu.

Uprostřed běhu se zpráva běžícímu agentovi zařadí do fronty jako korekce a na další hranici tahu se odebere, takže běh postrčíš, aniž bys ho ukončil. Korekce, pozastavení, podagenti a kontrakt dokončení patří vestavěnému harnessu. Claude Code z nich nemá nic.

Jak se běh zaznamenává

Každé odeslání zapíše AgentRunLog: čas začátku a konce, shrnutí, počty tokenů a odhadovanou cenu (včetně ceny sečtené z podagentů), adaptér a model, id procesu a cestu k logu, konverzaci a případný ticket nebo běh pipeline, ke kterému patří, plus dvě klasifikační pole, na kterých leží většina pravdy.

• Stav je hrubý: pending, running, completed, error.
• Živost je jemnější údaj: alive, productive, completed, blocked, empty, looping, failed, stalled, dead.
• Rodina chyb seskupuje selhání tak, aby se s nimi dalo pracovat: transientUpstream, sandboxInfrastructure, budgetExceeded, processLost, silentRun, unknown.

completed neznamená „doručeno“

Když běh skončí bez toho, co měl režim dodat (běh v režimu plánu, který nikdy nezavolal submit_plan, nebo běh orchestrace, který nikdy nic nenavrhl), stav zůstane completed, protože proces skončil čistě. Poctivý signál je v živosti (empty), v rodině chyb (silentRun) a ve shrnutí, které řekne přesně, co nevzniklo. Shrnutí je chráněné: finalizace ho nepřepíše posledním tlacháním modelu.

Je to schválně. Přepnutí stavu by pohnulo automaty ticketů a pipeline, které s chybějícím artefaktem nemají co dělat. Samotné „status: completed“ taky nikdy nestačí, abys z něj usoudil, že běh uspěl. Přečti shrnutí.

Uzavření běhu publikuje AgentRunCompleted a na té události visí hodně: souhrn nákladů pipeline, obnovení kroku pipeline, který na běh čekal, dokončení podkladového ticketu, namapování orchestrace na koncový stav, rozhodnutí supervizora cíle, jestli pokračovat, nebo zastavit, role kontrolora a vyhodnocení rozpočtu po běhu. Seznam přítomnosti jde vlastní cestou: sleduje nedávné záznamy běhů, ne tuhle událost. Oznámení „Agent dokončil“ v tom výčtu není: událost se spustí ve chvíli, kdy skončí proud procesu, tedy ještě před zápisem odpovědi. Oznámením je proto MessageReceived daného tahu, publikované až po uložení zprávy.

Rozpočty až potom

Vynucení rozpočtu je reakce, ne brána. Když běh skončí, vyhodnocovač porovná útratu agenta od začátku měsíce s jeho účinným stropem (navázaná politika rozpočtu, pokud nějaká je, jinak vlastní měsíční číslo agenta; nula znamená bez omezení). Překročení měkkého prahu zapíše varovný incident. Vyčerpání rozpočtu zapíše tvrdý incident a na organizačním schématu přepne stav životního cyklu agenta na paused. Odeslání od toho agenta práci pořád bere. Spouštěč pipeline BudgetThresholdCrossed může ze stejné události rozjet navazující práci.

Linie opakování

Každý záznam běhu může nést linii opakování: id nadřazeného běhu, počítadlo pokusů a shrnutí pokračování. Strom běhů konverzace ukáže číslo pokusu, když není nula. Zopakování z chatu je nové odeslání s čerstvým záznamem běhu.

Související koncepty

• Model agentů: co adaptér vynutit umí a co ne
• Režimy: odkud se bere sada nástrojů a kontrakt dokončení
• Guardraily: politika tříd efektů, kterou projde každé hlídané volání
• Sandbox a zabezpečení: celý příběh izolace
• Multiplayer: korekce, převzetí a ovládání autonomie
• Doménové události: co spouští AgentRunCompleted