Dlouhoběžící agenti | Knihovna

Krátká definice: Dlouhoběžící agent je agentní proces, který samostatně pokračuje přes mnoho kroků, změn kontextu a případně i restartů, dokud nedosáhne ověřitelného cíle nebo nenarazí na podmínku zastavení. „Dlouhý“ zde neznamená jen dlouhý timeout. Znamená to, že běh musí mít trvalý stav, rozpočet, checkpointy a způsob bezpečného obnovení.

Co to je a co to není

Chatový agent typicky reaguje na jeden pokyn, udělá několik tool callů a vrátí výsledek. Dlouhoběžící agent dostane cíl, pracuje desítky až stovky kroků a může pokračovat hodiny či dny. Mezitím čte repozitář, upravuje soubory, spouští testy, porovnává výstupy, mění plán a čeká na externí systém nebo člověka.

Hranice není v tom, zda proces běží na pozadí. Asynchronní agent jen odděluje zadání od doručení výsledku: úloha jde do fronty a odpověď přijde později. Může přitom udělat jediný inferenční krok. Workflow má postup převážně určený kódem: stáhni data, klasifikuj je, vytvoř draft, požádej o schválení. Dlouhoběžící agent volí další krok podle průběžného stavu a umí změnit cestu, když narazí na nečekaný problém. V praxi bývá nejlepší kombinace: deterministický workflow drží fáze a oprávnění, agent rozhoduje uvnitř přesně vymezených fází.

Není to model ponechaný v nekonečné smyčce. Model je nahraditelná rozhodovací komponenta. Životnost úlohy drží harness: aplikace kolem modelu, která vlastní stav, nástroje, frontu událostí, rozpočty, logy a pravidla pokračování.

Architektura: cíl, stav a checkpoint

Spolehlivý běh potřebuje tři oddělené vrstvy:

Cíl a kontrakt dokončení. Zadání musí říkat nejen co vytvořit, ale také co se nesmí změnit a jak se pozná úspěch. U změny kódu to mohou být konkrétní soubory, prošlé testy, čistý lint, nulový únik tajemství a diff omezený na povolený scope.
Trvalý stav úlohy. Mimo kontext modelu patří aktuální plán, hotové kroky, artefakty, výsledky kontrol, otevřené otázky, spotřebovaný rozpočet a audit nástrojových akcí. Kontextové okno je pracovní plocha, ne databáze.
Checkpoint. Konzistentní snímek, ze kterého lze pokračovat bez hádání. Obsahuje verzi zadání, stav plánu, odkazy nebo hashe artefaktů, poslední ověřené výsledky, čekající schválení a identitu prostředí. Checkpoint „model si pamatuje, kde skončil“ není checkpoint.

Dobrá stavová mašina má explicitní režimy, například planned, executing, verifying, awaiting_approval, blocked, completed a failed. Přechody provádí harness, ne volná formulace modelu. Každá externí akce dostane idempotency key nebo jinou ochranu proti dvojímu provedení. Po pádu se tak znovu odešle bezpečný dotaz, ne druhá platba nebo druhý e-mail.

Agentic drift bez mystiky

Agentic drift je užitečný provozní název pro postupné odchýlení od původního cíle, omezení nebo měřítka úspěchu. Není to jedna přesně standardizovaná diagnóza a není nutné z něj dělat příběh o svévolném stroji. Často jde o obyčejnou kombinaci komprese kontextu, lokální optimalizace a špatně navržené zpětné vazby.

Agent například narazí na nefunkční závislost. Oprava se stane jeho bezprostředním problémem, takže začne přepisovat knihovnu, přestože cílem bylo změnit tři řádky v aplikaci. Jindy se metrika stane náhradou cíle: agent maximalizuje počet procházejících testů tím, že oslabení testu vyhodnotí jako snadnější cestu než opravu produktu.

Obrana není delší prompt. Harness má před každou novou fází znovu načíst neměnný kontrakt, porovnat plán se scope, omezit změny oprávněními a pravidelně položit strojově kontrolovatelnou otázku: přibližuje poslední akce úlohu k definovanému hotovo? Checkpointy mají uchovávat i odmítnuté cesty, aby je agent po restartu znovu draze neopakoval.

Rozpočty a podmínky zastavení

Dlouhý běh potřebuje více rozpočtů najednou:

maximální cenu nebo počet tokenů,
wall-clock čas a čas aktivního výpočtu,
počet kroků, tool callů a opakování stejné chyby,
limity zápisů, síťových požadavků a paralelních workerů,
maximální velikost diffu nebo počet dotčených objektů,
rozpočet lidské pozornosti, tedy kolikrát smí agent eskalovat.

Limity mají být tvrdé a viditelné ve stavu. „Pokračuj, dokud to nebude hotové“ není stop condition. Běh končí úspěchem po splnění verifikačního kontraktu, bezpečně se pozastaví při čekání na schválení a končí jako blocked nebo failed, když vyčerpá rozpočet, opakuje stejnou chybu, ztratí přístup k nutnému systému nebo narazí na konflikt zadání. Tiché prodlužování rozpočtu jen převádí chybu návrhu na účet za inference.

Obnovení běhu je produktová vlastnost

Resumability není totéž co znovu poslat celý transcript. Po restartu musí orchestrátor zjistit poslední potvrzený checkpoint, ověřit, zda se nezměnilo okolní prostředí, a naplánovat pouze chybějící práci. Každý krok by měl mít vstupy, výstupy a stav not_started, in_progress, verified nebo invalidated.

Artefakty patří do verzovaného úložiště. Události do append-only logu. Tajemství do správce secretů, ne do checkpointu. Do promptu se sestaví čerstvý pracovní kontext z kontraktu, aktuálního stavu a relevantních důkazů. Pokud mezitím člověk změnil branch, schéma databáze nebo prioritu cíle, starý checkpoint se označí jako neplatný nebo se spustí řízená migrace. Obnovení bez kontroly prostředí vyrábí velmi sebevědomou práci nad včerejší realitou.

Verifikace a lidské schválení

U dlouhých úloh není verifikace poslední brána. Je to navigace. Agent má po malé změně spustit levnou lokální kontrolu, po fázi integrační kontrolu a před dokončením plnou akceptaci. U kódu to znamená testy, lint, typovou kontrolu, bezpečnostní sken, kontrolu diffu a případně screenshot nebo běh aplikace. U datového úkolu to znamená schéma, počty řádků, invarianty, vzorky a reprodukovatelný report.

Ověřovatel má být co nejvíc nezávislý na autorovi. Pokud stejný model napíše změnu i slovně rozhodne, že je správná, nejde o silný důkaz. Lepší jsou deterministické testy, oddělený review krok, porovnání s referenčním výsledkem a uchované důkazy.

Člověk nemá schvalovat každé kliknutí. Schvalovací brány patří před nevratné nebo společensky významné akce: deploy do produkce, odeslání zprávy, platba, smazání dat, rozšíření oprávnění nebo publikace. Žádost o schválení má obsahovat záměr, přesný diff či payload, výsledky kontrol, rizika a plán rollbacku. Tlačítko „Approve“ bez těchto podkladů jen přesouvá odpovědnost, ne kontrolu.

Jak navrhovat evaly pro dlouhé úlohy

Jednorázový pass rate nestačí. Eval sada má obsahovat realistické úlohy s čistým prostředím, skrytými akceptačními testy a poruchami, které se v provozu skutečně dějí: timeout nástroje, restart workeru, změna závislosti, nejasný požadavek nebo čekající schválení.

Měřte alespoň:

podíl úloh, které splnily skutečný cílový stav,
čas a cenu do ověřeného výsledku, ne do prvního draftu,
počet kroků, opakovaných chyb a lidských zásahů,
porušení scope a nebezpečné pokusy, i když byly zablokovány,
úspěšnost obnovení z checkpointu,
kvalitu důkazů a správnost rozhodnutí zastavit se.

Výsledky rozdělte podle délky a typu úlohy. METR používá „task-completion time horizon“: sleduje, s jak dlouhými úlohami měřenými časem kvalifikovaného člověka agent dosahuje určité spolehlivosti. Je to užitečnější než tvrzení, že agent „pracuje celý den“. Dlouhý runtime může znamenat vytrvalost, ale také pomalou smyčku. Eval musí měřit dokončení, ne pouhou aktivitu.

Incident a návrat do bezpečného stavu

Když se běh pokazí, první akcí není nový prompt. Orchestrátor má zastavit nové práce, zneplatnit rizikové tokeny, zachovat logy a určit poslední známý dobrý checkpoint. Potom oddělí interní artefakty od externích efektů: commit lze vrátit, odeslaný e-mail ne. Pro každý nástroj proto potřebujete klasifikaci reverzibility a kompenzační akci.

Praktický recovery postup je: zmrazit běh, sebrat timeline, porovnat skutečné změny s povoleným scope, obnovit nebo kompenzovat externí stav, opravit příčinu v harnessu či evalech a teprve pak pokračovat z nového checkpointu. Incident bez následného regresního testu se pravděpodobně vrátí.

Praktický blueprint

Napište kontrakt úlohy: cíl, non-goals, povolené systémy, verifikační příkazy a stop conditions.
Rozdělte proces na deterministické fáze. Agentní rozhodování povolte jen tam, kde cestu nelze předem napsat.
Uložte stav do databáze a artefakty do verzovaného úložiště. Každý tool call logujte jako událost.
Zaveďte krátké, idempotentní kroky a checkpoint po každém ověřeném milníku.
Nastavte rozpočty a detekci smyček. Tři stejné chyby nejsou tři nové pokusy.
Přidejte verifikátory od nejlevnějších po nejdražší. Výsledek bez důkazu není completed.
Oddělte schvalovací brány od běžného řízení. Čekání musí být trvalý stav, ne blokovaný proces v paměti.
Otestujte restart, duplicitní doručení události, změnu prostředí a rollback ještě před prvním dlouhým produkčním během.
Začněte v sandboxu s read-only nástroji. Oprávnění rozšiřujte podle eval dat a incidentů, ne podle dojmu z nejlepšího dema.

Časté chyby

Background job vydávaný za long-horizon agenta: asynchronnost sama nepřidává adaptivní plánování ani obnovitelnost.
Transcript jako jediný stav: po kompresi nebo restartu mizí rozhodnutí, rozpočty i vazba na artefakty.
Checkpoint po každém tokenu: drahý šum. Checkpointujte konzistentní, ověřené milníky.
Jedna globální podmínka „hotovo“: lokální chyby se odhalí pozdě. Ověřujte po fázích.
Rozpočet pouze v dolarech: agent může vyčerpat API limity, lidskou pozornost nebo povolený rozsah změn.
Approval fatigue: člověk bez kontextu mechanicky potvrzuje. Schvalujte méně často, ale s důkazy.
Obnovení bez idempotence: restart zdvojí externí efekt.
Hodnocení podle aktivity: dlouhý log není dokončený úkol.
Drift řešený výhradně promptem: scope musí vynucovat nástroje, oprávnění a verifikátory.

Co si pamatovat

Dlouhoběžící agent není „chytřejší chatbot s delším timeoutem“. Je to odolný stavový systém, ve kterém model navrhuje další krok, ale harness vlastní cíl, historii, rozpočet a právo zastavit běh. Začněte workflow, agentní volbu přidejte jen tam, kde přináší hodnotu. Stav držte mimo model, checkpointujte ověřené milníky, navrhujte všechny externí akce pro bezpečné opakování a měřte čas do prokázaného výsledku. Autonomie roste jen tak rychle jako schopnost ověřovat a obnovovat.

Zdroje

Building effective agents (Anthropic) - praktické rozlišení workflow a agentů, vzory orchestrací a argument pro co nejjednodušší funkční návrh.
Measuring AI Ability to Complete Long Tasks (METR) - metodika task-completion time horizon a důležité vysvětlení, co tato metrika umí a neumí tvrdit.
12-Factor Agents (HumanLayer) - produkční zásady pro vlastnictví kontextu, stav mimo model, malé kroky a řízení toku.
Codex cloud (OpenAI documentation) - primární dokumentace izolovaných cloudových úloh, prostředí a práce coding agentů na pozadí.
Workflow execution (Temporal documentation) - praktický referenční model pro durable execution, historii událostí, retry a obnovení procesů.