Pipeline agentů

Agenti care běží jako agentní smyčka (Anthropic SDK). Úkoly jsou datově řízené: dispatch je stejný pro všechny typy, liší se jen playbook.

Životní cyklus úkolu

1. Vznik úkolu. Úkol založí operátor v adminu, nebo ho vytvoří scheduler z pravidelného plánu, případně z funkční kontroly (type: func_check).
2. Fronta. Schválený úkol si vezme agent worker (lease z fronty jobs).
3. Playbook. Podle type úkolu se vybere playbook: systémový prompt, jestli je potřeba SSH, kolik kroků a jaký model. Playbook dostane zadání a konfiguraci.
4. Nástroje. Agent plní úkol pomocí nástrojů (HTTP, SSL, SSH, WP-CLI, kontrola schránky).
5. Výsledek. Agent zavolá submit_report se strukturovaným výsledkem (nálezy, závažnost). Zapíše se do úkolu a do work_log.
6. Reakce. Když funkční kontrola selže, care otevře incident (kind: flow) a upozorní tým. Při dalším úspěšném běhu se incident uzavře.

Dohled a schvalování

Úkoly, které zasahují do serveru, běží často pod dohledem (supervised). Když agent chce spustit mutační příkaz (něco, co mění stav), care ho nechá schválit operátorem (job se pozastaví a čeká na vstup). Čistě čtecí příkazy běží samy. Nebezpečné příkazy jsou tvrdě blokované bez ohledu na dohled. Detail v nástrojích agentů.

Například příprava formuláře na testování (type: form_testready) je defaultně pod dohledem, protože upravuje soubory webu.

Pojistky proti visícím běhům (kontejner je při čekání vzhůru a účtuje se): úkol bez dohledu, který narazí na příkaz vyžadující schválení, ho rovnou zamítne (nečeká) a agent zvolí jiný postup nebo skončí. U úkolů pod dohledem má čekání na schválení časový limit. A každý úkol má tvrdý strop na celkovou dobu běhu; po jeho překročení terminálně selže.

Tokeny, caching a náklady

Agentní smyčka posílá na každém kroku stabilní prefix (system prompt playbooku a definice nástrojů) a rostoucí historii. Aby se šetřily tokeny, používá prompt caching: stabilní prefix i historie se cachují, takže další kroky je čtou z cache za zlomek ceny. U vícekrokových úkolů to výrazně snižuje spotřebu.

Každý úkol si ukládá spotřebu tokenů (vstup, výstup, cache read, cache write) a použitý model. Z toho se počítá cena. V adminu je vidět rozpad nákladů po webech, skupinách a typech úkolů.

Paměť agenta

Aby agent nezačínal každý běh od nuly, má trvalou paměť na třech úrovních: web, klient a skupina. Je to krátký markdown s provozními fakty (cesty k nástrojům jako wp-cli, kořen webu, zvláštnosti hostingu, opakující se problémy).

• Na začátku běhu se agentovi vloží do promptu blok „Co víš o tomhle webu z minulých běhů" (paměť webu + klienta + skupiny).
• Na konci může agent přes submit_report navrhnout aktualizaci paměti webu (zachová platná fakta, přidá nová). Paměť klienta a skupiny je kurátorská, edituje ji operátor v adminu.
• Paměť se do promptu vkládá jako tipy, ne příkazy — nikdy neobchází schvalovací bránu ani nezakládá důvěru, a nesmí obsahovat hesla. Operátor ji může kdykoliv opravit nebo smazat.