Az ügynökindítás életciklusa

Mi az indítás

Az indítás egy ügynök egyetlen futtatása, egy beszélgetésben, egy adapteren. Minden, ami vele kapcsolatos, a cc_server-en történik: a kliens elküld egy üzenetet, majd figyeli, ahogy az események visszaáramlanak. Egyetlen kliensben sincs indítási útvonal.

Az ügynököket hat okból ébresztjük fel; ezeket a futtatás ébresztési kontextusként hordozza, hogy az ügynök tudja, miért van ébren:

Az ébresztés oka	Kiváltó esemény
userMessage	Valaki üzenetet küldött egy térben, vagy megemlítette az ügynököt
assignment	Hozzárendeltek egy jegyet az ügynökhöz
pipelineStep	Egy pipeline-lépés indította el
childCompleted	Egy gyermekjegy elkészült
followUp	Ütemezett utókövetési szívverés
recovery	A helyreállítási útvonal egy hiba után újraindította

Az ébresztési kontextus hordozza az okhoz tartozó azonosítókat — jegy, tér, üzenet, pipeline-futtatás —, és ezek bekerülnek az ügynök környezetébe és promptjába.

A prompt összeállítása

A prompt rétegekben épül fel, mindegyik egy címkézett szakasz:

• Identitás — az ügynök saját azonosítója, neve és munkaterület-azonosítója, valamint egy explicit utasítás, hogy pontosan ezeket a UUID-kat adja át a munkaterület-hatókörű eszközöknek. A munkaterület az ügynök eredendő tulajdonsága, ezért mindig jelen van.
• Eszközkatalógus és erőforrás-protokollok, majd a munkaterület elrendezése.
• Rendszerprompt-felülírás, ha az ügynöknek van ilyen, majd a persona (szerepkör szerint paraméterezve) és a csapatösszefoglaló.
• Készségek — az ügynökhöz rendelt nevek.
• Végrehajtási szerződés és eljárás az aktuális módhoz.
• Ébresztési kontextus és említési kontextus: ki hívta az ügynököt, és milyen névsor veszi körül.
• Módblokk — a mód képességprofiljából és annak materializált eszközlistájából generálódik, így egy prompt soha nem nevezhet meg olyan eszközt, amellyel a futtatás valójában nem rendelkezik.
• Memóriakontextus — a feladathoz előkeresett tények.
• Beszélgetési kontextus — a tér közelmúltbeli előzményei, szó szerinti ablakként 50 000 karakterre korlátozva, függetlenül az ügynök beállított kontextusméretétől. A régebbi előzmények nem csonkulnak le: az ügynök igény szerint előkeresi őket a get_messages segítségével, és a szemantikailag releváns régebbi üzenetek továbbra is előkerülnek.

Slash-parancsok a nyers felhasználói szövegből kerülnek feldolgozásra

A rétegzett prompt egy kontextusblokkal kezdődik, ezért nem perjellel indul. A parancsok a felhasználó üzenetéből szó szerint kerülnek feldolgozásra, majd kivágódnak a rétegzett prompt végéből, így minden kontextusréteg megmarad.

A parancsok kezelése két helyen történik. A /todo és a /compact a beviteli mezőben kerül elfogásra, és szándékosan soha nem perzisztálódnak üzenetként, illetve nem kerülnek elküldésre az ügynöknek — a /compact perzisztálása egy körrel hátrébb tolná a tömörítési határt, és beszennyezné az átiratot. A /plan mindkét helyen kezelve van: a beviteli mező átállítja a tér módját, ettől lesz összhangban az eszközfelszín, a korlát-előbeállítás és a prompt ebben a körben és minden utána következő körben. A /goal, a /loop és a /skill:<name> magában a futtatásban kerül kezelésre, és csak a beépített harness esetén — a /goal és a /loop költségkerettel autonóm munkát indít, a skill: előtaggal ellátott nevet pedig készségként keressük ki, amelynek SKILL.md törzse lesz a kör utasítása. A névtér az, ami szétválasztja a két szókincset: ha a csupasz nevet készségek ellenében oldanánk fel, akkor egy plan vagy compact nevű készséget tartósan elfedne a beépített parancs. A csupasz, nem beépített név továbbra is feloldódik, azoknak az üzeneteknek a kedvéért, amelyek a névtér megjelenése előtt íródtak. Egy ismeretlen név egyszerűen sima szövegként megy tovább.

Worktree-k létrehozása

Mielőtt bármi elindulna, a beszélgetés saját munkagyökeret kap, amely alatt repónként egy elszigetelt, copy-on-write worktree található. Alapértelmezés szerint ez a munkaterülethez kapcsolt összes repó; egy PR-tér — vagy egy explicit kijelöléssel létrehozott tér — csak az engedélyezett listán szereplőket hozza létre, és egy PR-átnézési beszélgetés az egyetlen repóját a pull request head refjére rögzíti, míg a többi az alapértelmezett ágán marad. A forrás-munkapéldány soha nem módosul, és a tér törlésekor a teljes beszélgetéskönyvtár felszabadul.

A copy-on-write az egyetlen implementáció mindenhol, ahol a rift elérhető, a csomagolt natív komponensre támaszkodva. Egy olyan fájlrendszer, amely nem tud reflinket — vagy egy másik köteten lévő adatkönyvtár, mint a repó —, inkább meghiúsítja a létrehozást, mintsem visszaesne egy tartalékra. Windows alatt a git worktree a háttérrendszer, ahol nincs mit építeni copy-on-write háttérrendszerként, és más hosztokon ez nem csendes degradáció. Egy hiányzó rift egy olyan platformon, amely szállítja, törött telepítést jelent — a szerver inkább megtagadja az indulást, mintsem csendben visszaesne egy tartalékra, mert a csendes visszaesés örökre egy lassabb útvonal mögé rejti a hibát.

Identitás és hitelesítő adatok

Futtatásonként két identitás oldódik fel, mielőtt bármilyen folyamat elindulna.

Git szerzőség. Az ügynök által készített commitok szerzője az ügynök — <Name> (agent) <agentId@agents.control-center.local> a GIT_AUTHOR_* és a GIT_COMMITTER_* változókban egyaránt —, soha nem embernek adva ki magát. A helyi rész az ügynök UUID-ja, nem a nevének slugja. A kérő ember egy Co-Authored-By: utótaggal jelenik meg jóváíróként, amelyet a környezet hordoz, és a rendszerprompt előír. Egy explicit, hívó által beállított identitás mindig felülírja mindkettőt.

Forge-identitás. A futtatás GitHub-hitelesítő adata soha nem lehet más, mint a brókeré — egy repóra szűkített App-telepítési token vagy annak környezeti PAT-tartaléka —, soha nem a kérő tag saját tárolt tokenje. Az actingUserId korlátozza a PAT-tartalékot, így az a tag, aki nem a szerver tulajdonosa, nem örökli a szerver elérését; ugyanakkor nem is illeszt személyes tokent az ügynök környezetére.

A modellszolgáltató hitelesítő adatai rögzített sorrendben oldódnak fel, és a sorrend számít:

1. adapterenkénti környezeti felülírás,
2. a hívó környezete,
3. a szerver hitelesítőadat-tára (frissítve az OAuth-tokent, ha közel a lejárata),
4. a folyamat környezete.

Mivel az adapterenkénti felülírás az első, csendben felülírja az alkalmazásban csatlakoztatott szolgáltatói fiókot. Ha egy futtatás rossz fiókra számláz, elsőként ezt a felülírást érdemes megnézni. A szolgáltatói hitelesítő adatok hoszt-szintűek — a telepítés minden munkaterülete között megosztottak.

A futtatás GitHub-tokenje a hitelesítőadat-brókertől származik: csak olvasásra jogosult, a worktree repójára korlátozott token. A push az ügynökfuttatási átjárón megy át, amely a továbbítás előtt megkérdezi a Küldés távoli tárolóra szabályt, jegykezelő kulcs pedig nem kerül injektálásra. Lásd: Homokozó és biztonság.

Indítás

A futtatás a worktree-jét használva munkakönyvtárként indul, és — a Claude Code esetében — egy generált MCP-konfigurációval, hogy az ügynök elérje a Control Center eszközfelszínét. Az ACP és a harness bash tisztított környezetet kap; a Claude Code a NoSandboxAdapter-en keresztül a hoszt környezetét örökli.

Az operációs rendszer homokozója csak ott veszi körül a futtatást, ahol a hosztnak van háttérrendszere

A cc_server induláskor egyszer felméri a hosztot, és ha van elérhető háttérrendszer, abba csomagolja az ügynökfolyamatokat — macOS-en Seatbelt, Linuxon és WSL2-n bubblewrap. Mindkét indítási varrat be van csomagolva, mert nem ugyanazt használják: a Claude Code CLI a homokozóporthoz fut be; az ACP-adapterek és a beépített harness bash eszköze a homokozókezelőn keresztül mennek. Ez az is, ami érvényesíti a futtatás védett útvonalait: a regisztrált repó-munkapéldányok írása minden módban tiltott a homokozón belül.

Ahol nincs háttérrendszer, a futtatás nincs homokozóba zárva, és semmi más nem változik ezt kompenzálandó. Ez mindig így van Windows alatt (nincs natív csomagolás — a microvm külön, próba alapján kapuzott útvonal a terminálokhoz és az állomásokhoz), valamint Linuxon vagy WSL2-n, ha a bwrap és a socat nincs a PATH-ban. A szerver a naplójának induló sorában megnevezi, melyik állapotban van, és a --sandbox off szándékosan kikapcsolja.

Két rés akkor is megmarad a homokozóban, ha az be van kapcsolva. A harness folyamaton belüli fájleszközei (read, write, edit, apply patch, search, find, search_files) a szerverfolyamaton belül futnak, így semmilyen profil nem korlátozza őket — a korlátjukat az eszközök saját útvonalkorlátozása és a korlátok adják. A Claude Code pedig --dangerously-skip-permissions kapcsolóval indul, így a saját fájlhívásait nem kapuzza a Control Center, a shellparancsait pedig csak egy hook, amely a parancssort olvassa; a körülöttük lévő határ az operációs rendszer homokozója.

A fennmaradó korlátok minden hoszton érvényesek, homokozóval vagy anélkül: a futtatás saját worktree-je (copy-on-write ott, ahol a rift elérhető; Windowson git worktree), az indításonként brókerezett, a lebontáskor visszavont, csak olvasásra jogosult kódhosting-token, az ügynökfuttatási átjárón a push-szabályon átengedett pushok, az egységes műveleti korlátok (fail-closed — egy prompt döntés, amelyhez nincs csatlakoztatva jóváhagyó, elutasításra kerül) és a beszélgetés módja által engedett eszközfelszín. Az ACP és a harness bash továbbra is tisztítja a környezetet; a Claude Code a NoSandboxAdapter-en keresztül a hoszt környezetét örökli.

Streamelés

A futtatás egy típusos eseménysorozatot streamel vissza, amelyet a streamfeldolgozó üzenetdeltákként perzisztál, átiratszegmensekké fűz össze, és üzenetküldési eseményekké alakít:

Esemény	Mit hordoz
thinking	Gondolkodási kimenet, beágyazva megjelenítve
text	Látható kimenet
toolCall	Egy eszközhívás, annak azonosítójával és strukturált argumentumaival
toolResult	A hozzá tartozó eredmény, megjelölve, ha hibázott, vagy ha részleges stream
usage	Tokenek száma és költség egy mérési ablakra
error	Egy hiba, az adapter strukturált kódjával, ha az jelentett ilyet
sandboxViolation	Az operációs rendszer megtagadott egy rendszerhívást. Csak ott kerül kibocsátásra, ahol egy homokozó ténylegesen körülveszi a folyamatot — lásd a fenti megjegyzést
debug	Futásidejű diagnosztika (indítási jelölők, korlát-döntések, szerződésemlékeztetők)
done	A futtatás befejeződött

Mi korlátoz egy futtatást

Szándékosan nincs sehol körplafon. Egy kemény iterációszám megölne legitim, hosszú munkákat (migrációk, fan-out takarítás), és semmit nem kapna el korábban, mint az alábbi őrök. Egy futtatás akkor ér véget, amikor:

• a modell magától megáll;
• egy ember leállítja, vagy átveszi a beszélgetést (ez a beépített harness-t a következő tiszta körhatárán szünetelteti — egy Claude Code futtatás, amelynek nincs biztonságos határa, inkább leállításra kerül);
• a csendfigyelő riaszt. Ha a küszöbértékig nincs kimenet, a munkamenet silentRun hibával lezárul. Az alapérték 15 perc, amely a nagyrészt olvasásra épülő módokban (átnézési és tervmód) 10 percre csökken; az ügynök 1 és 240 perc között felülírhatja. A csendfigyelő akkor élesedik, amikor egy gyermekfolyamat jelenti a PID-jét, így lefedi a Claude Code CLI-t — nem fedi le viszont a beépített harness-t, amely semmit nem indít;
• egy költségkorlát életbe lép — de csak az autonóm parancsoknál.

A végzetes hurok elleni őr nem lezáró: három egymás utáni azonos eszközhívás esetén a hurok más irányba tereli az ügynököt, hogy változtasson a megközelítésén.

Egy normál körnek nincs költségkorlátja

A munkameneten belüli költségőr csak a /goal és a /loop esetében van bekötve; minden más futtatás egyáltalán nem ad át költségkeretet. Ezeknél a parancsoknál egy felügyelet nélküli szegmens alapértelmezés szerint 500 centet (5,00 dollárt) emészthet fel, 80%-nál egy szelíd tereléssel, amely arra kéri az ügynököt, hogy a kemény leállás előtt fejezze be tisztán a munkát, a szegmenseken átnyúló tartós célkeret pedig 5000 cent (50,00 dollár). Egy explicit /goal --budget értéket soha nem lépheti túl egy teljes szegmens.

Összevetve: egy közönséges interaktív kör a beépített harness-en nem rendelkezik körplafonnal, költségkorláttal és csendfigyelővel sem. Akkor ér véget, amikor a modell megáll, vagy amikor te leállítod. Ez szándékos kompromisszum — az alternatívák mind megölnék a legitim, hosszú munkát —, azt viszont jelenti, hogy egy felügyelet nélküli interaktív futtatást semmi más nem korlátoz, csak a modell saját megítélése.

Futtatás közben a futó ügynöknek küldött üzenet irányításként sorba áll, és a következő körhatáron ürül ki, így anélkül terelheted a futtatást, hogy megölnéd. Az irányítás, a szüneteltetés, az alügynökök és a befejezési szerződés a beépített harness funkciói; a Claude Code egyikkel sem rendelkezik.

Hogyan rögzül egy futtatás

Minden indítás ír egy AgentRunLog-ot: kezdési és befejezési idő, összefoglaló, tokenek száma és becsült költség (beleértve az alügynököktől összesített költséget), adapter és modell, folyamatazonosító és naplóútvonal, a beszélgetés, valamint minden jegy vagy pipeline-futtatás, amelyhez tartozik, továbbá két osztályozási mező, amelyek az igazság nagy részét hordozzák.

• Az állapot durva: pending, running, completed, error.
• Az elevenség a finomabb kép: alive, productive, completed, blocked, empty, looping, failed, stalled, dead.
• A hibatípus hasznosan csoportosítja a hibákat: transientUpstream, sandboxInfrastructure, budgetExceeded, processLost, silentRun, unknown.

A completed nem jelent „leszállított” állapotot

Amikor egy futtatás a módja által megkövetelt eredmény nélkül ér véget — egy tervmódú futtatás, amely soha nem hívta meg a submit_plan-t, egy orchestrációs futtatás, amely soha nem terjesztett elő javaslatot —, az állapot completed marad, mert a folyamat tisztán kilépett. Az őszinte jelzést az elevenség (empty), a hibatípus (silentRun) és egy összefoglaló hordozza, amely pontosan megmondja, mi nem készült el. Ez az összefoglaló védett: a lezárás nem írja felül a modell utolsó fecsegésével.

Ez szándékos. Az állapot átbillentése olyan jegy- és pipeline-állapotgépeket mozgatna meg, amelyeknek semmi közük a hiányzó artefaktumhoz. Az is következik ebből, hogy a „status: completed” önmagában soha nem elég annak megállapításához, hogy egy futtatás sikeres volt — olvasd el az összefoglalót.

A futtatás lezárása közzéteszi az AgentRunCompleted eseményt, amelyre sok minden épül: a pipeline-költségek összesítése, egy futtatásra váró pipeline-lépés folytatása, a mögöttes jegy lezárása, egy orchestráció terminális állapotra képezése, a célfelügyelő folytatás-vagy-leállás döntése, az ellenőrző szerepkör és a futtatás utáni költségkeret-kiértékelés. A jelenléti névsor külön következik, a közelmúltbeli futtatási naplók figyelésével, nem az esemény alapján. Az „ügynök befejezte” értesítés nem szerepel ezen a listán: az esemény akkor sül el, amikor a folyamat adatfolyama véget ér, még a válasz kiírása előtt, ezért az értesítés a kör MessageReceived eseménye, amely az üzenet tárolása után jelenik meg.

Költségkeretek, utólag

A költségkeret érvényesítése reakció, nem kapu. Amikor egy futtatás befejeződik, a kiértékelő összehasonlítja az ügynök hónap eleje óta tartó költését annak tényleges felső korlátjával (egy csatolt költségkeret-szabályzattal, ha van ilyen, egyébként az ügynök saját havi értékével; a nulla korlátlant jelent). A lágy küszöb átlépése figyelmeztető incidenst rögzít; a költségkeret kimerítése kemény incidenst rögzít, és a szervezeti ábrán az ügynök életciklus-állapotát paused-ra billenti. Az indítás továbbra is elfogad munkát attól az ügynöktől. Egy BudgetThresholdCrossed pipeline-eseményindító ugyanabból az eseményből utókövetési munkát indíthat.

Újrapróbálkozások leszármazási vonala

Minden futtatási napló hordozhat újrapróbálkozási leszármazást — egy szülő futtatásazonosítót, egy kísérletszámlálót és egy folytatási összefoglalót. A beszélgetés futtatásfája akkor jeleníti meg a kísérlet számát, ha az nem nulla. Egy „próbáld újra” a csevegésből egy új indítás, friss futtatási naplóval.

Kapcsolódó fogalmak

• Az ügynökmodell: mit tud és mit nem tud érvényesíteni az adapter
• Módok: honnan származik az eszközfelszín és a befejezési szerződés
• Korlátok: az effektosztály-szabályzat, amelyen minden kapuzott hívás átmegy
• Homokozó és biztonság: az elszigetelés teljes története
• Többszereplős mód: irányítás, átvétel és az autonómiaszabályzó
• Domainesemények: mit indít el az AgentRunCompleted