Az ügynökmodell

Mi az ügynök?

Az ügynök egy nevesített szereplő, aki personával, készségkészlettel és egy adapterrel rendelkezik, amelyen fut. Az ügynökök ugyanolyan jogalanyok, mint az emberek: üzeneteket írnak, jegyeket birtokolnak, átnézéseket hagynak hátra, és ugyanazon a névsoron jelennek meg. Ők azok, amelyek a munkát végzik.

Minden ügynök pontosan egy munkaterülethez tartozik. Ez kemény invariáns — az agent.workspaceId nem null, az ügynök saját munkaterülete az, ami kiválasztja azt az adatbázisfájlt, amelybe a sorai kerülnek, a munkaterület nélküli ügynök létrehozása pedig elutasításra kerül.

Az ügynök egyben egy könyvtár is. A definíciója a munkaterület adatkönyvtára alatt az agents/<slug>/AGENTS.md helyen él, a birtokolt készségek pedig az agents/<slug>/.agents/skills alá vannak szimbolikus hivatkozásként bekötve. Az adatbázissor és a fájl együtt íródik. A kezdeti feltöltés idempotens: ha az ügynöksor már létezik, a lemezen lévő fájlok és készséghivatkozások akkor is újraíródnak. Az éles hívó a munkaterület létrehozása, nem minden szerverindítás.

Mit hordoz egy ügynök

Attribútum	Mit tesz
`name`	Rövid, slugra emlékeztető azonosító (`architect`, `qa`). Ez az is, amire az `@említések` feloldódnak
`title`	Ember számára olvasható munkakör
`persona`	Szabad szöveges személyiség- és viselkedésutasítások, promptszakaszként beillesztve
`systemPrompt`	Opcionális kiegészítő utasítások, „Ügynökutasítások” szakaszként beillesztve — nem helyettesítik az összeállított prompt többi részét
`skills`	Kis-nagybetűt nem megkülönböztető készségnevek halmaza, amelyek készséghivatkozásokként tükröződnek a lemezen
`adapterId`	Melyik futtatóra küldi az ügynök a munkát. A null a beépített ciklusra esik vissza
`modelId`	Melyik modell az adott adapteren belül
`effort`	Érvelési szint, a kiválasztott modell saját szókészletéből
`contextSize`	A kontextusablak felülbírálása
`silenceTimeoutMinutes`	Ügynökönkénti felülbírálás (1–240) a csendfigyelő watchdoghoz
`reportsTo`	A szülő ügynök azonosítója — a jelentési lánc, amelyet a szervezeti ábra megrajzol

Ezeket mind a Beállítások → Munkaterület → Ügynökök helyen szerkeszted. Az Új ügynök egy névtelen ügynököt hoz létre, amelyet utána kitöltesz.

Készségek

A készségek kis-nagybetűt nem megkülönböztető nevek az ügynökentitáson. Két külön dolog történik velük:

A nevek az összeállított promptban egy „Készségek” címsor alatt szerepelnek. Az entitás halmaza önmagában ennyit tesz — nincs mögötte készségenkénti prompttár, amelyre épülne.
Minden megnevezett készség könyvtára (a munkaterületen skills/<slug>/SKILL.md) az ügynök saját mappájába van bekötve. A beépített harnessen a bekötött készségek frontmatterje automatikusan betöltődik a rendszerpromptba, és az ügynök a törzset igény szerint olvassa; ha egy beszélgetésben beírod, hogy /skill:<name>, az adott körre vonatkozó utasításként tölti be azt a törzset.

A kívülről lekért készségek a lekérés és az írás között egy hiba esetén elutasító ellátásilánc-vizsgálaton esnek át — ítélet nélkül egyetlen készségtartalom sem kerül lemezre vagy promptba. A „kívül” azok a GitHub-repók, amelyeket te magad regisztrálsz készségforrásként: nincs gondozott tár, így a repó saját metaadatai (a leírása, a csillagai, a készség neve) nem megbízható megjelenítési adatok, és az egyetlen biztonsági jelzés a vizsgálat ítélete. A telepítés lekéri a készség teljes könyvtárát, a skills-lock.json-ban ahhoz a commithoz rögzíti, amelyből származik, egy későbbi frissítés pedig bármi lecserélése előtt újra átmegy a kapun. Az útmutató itt található: készségek telepítése és kezelése.

Repóhoz kötött készségek

Egy repó saját készségeket is szállíthat, bármelyik szokásos helyen (.agents/skills/, .claude/skills/, .opencode/skills/). Egy tér minden csatolt repót egymás mellé készít el a repos/<name>/ alatt, az ügynök viszont egyszerre egy repóban dolgozik — így csak az adott repó készségeit hordozza, és ezek cserélődnek, amikor továbbáll.

Az, hogy melyik repó az aktív, abból következik, hogy az ügynök mely fájlokat érinti: ha egy fájlt a repos/<name>/ alá ír, az lesz az aktív repó, pusztán a repókon átnyúló olvasás viszont nem, így egy szimbólum utáni nyomozás egy testvérszolgáltatásban soha nem cseréli ki a készletet a feladat alatt. Egyetlen repóból álló téren a válasz már az első kör előtt ismert.

A hatókör szűkítése kontextusköltségvetési döntés. A készségindex minden körben a promptban van, a törzsek viszont nem, ezért ha egyszerre listáznád az összes repó készségeit, az folyamatosan tokenekbe kerülne — egy szolgáltatás testing készsége pedig kifejezetten félrevezet, amikor a munka egy másikban van. Ugyanez az érv indokolja, hogy az ügynök indexe egy repót hordoz, a beviteli mező viszont nincs így leszűkítve: egy készség saját kezű megnevezése egyetlen explicit művelet, így a /skill:<repo>:<name> a tér bármely repóját eléri.

A repókészségek minden adapterhez betöltődnek, nem csak a beépített harnesshez. Az aktív repó készségei az ügynök munkakönyvtárába materializálódnak, ami az az útvonal, amelyet a Claude Code már beolvas; ugyanez az index kerül bele abba az AGENTS.md-be, amelyet a beépített harness olvas. Egy repó készségei ugyanazon a hiba esetén elutasító vizsgálaton esnek át, mint egy telepített készség, mindezek előtt — egy checkoutolt repó klónozott tartalom, és a frontmatterje promptba kerül.

Jogosultságok

Az ügynöknek nincsenek saját jogosultságjelzői. Hogy létrehozhat-e commitot, pusholhat-e, nyithat-e pull requestet, írhat-e követőbe vagy elérheti-e a hálózatot, azt a műveleti korlátok döntik el — engedélyezés, előbb kérdezzen vagy tiltás, munkaterület, ügynök vagy tér hatókörében —, és ugyanazok a szabályok érvényesek, bármelyik adapter futtatja is.

Az, hogy egy futás mit kap kézhez, ezektől a szabályoktól nem változik. Egy GitHub-worktree-ben zajló futás mindig csak olvasásra jogosult GitHub-tokent kap, a pushról pedig akkor születik döntés, amikor megtörténik: az ügynök git-konfigurációja minden GitHub-pusht a Control Centeren keresztül küld, amely a továbbítás előtt alkalmazza a Küldés távoli tárolóra szabályt.

Hogy ez hogyan működik, és mi érvényesül, illetve mi nem a fájlrendszer szintjén, azt lásd a Homokozó és biztonság oldalon.

Az adapter dönti el, mi érvényesíthető

Egy ügynök messze legkövetkezményesebb mezője az adaptere, mert az adapter átvitele határozza meg, hogy a Control Center szabályzatából valójában mennyi érvényesíthető.

Átvitel	Adapterek	Mit érvényesít a Control Center
Beépített harness	Control Center (built-in)	Mindent. Az eszközfelület a módból épül fel, így egy nem engedélyezett eszköz láthatatlan, nem csupán megtagadott; minden hívás átmegy a jóváhagyási kapun és a műveleti korlátokon; a befejezési szerződés ösztökélni tudja, majd meg is buktathatja azt a futást, amely a szállítandója nélkül ér véget
Claude CLI	Claude Code	A kiszolgált `mcp__*` eszközöket, valamint a `Bash` parancsait, amelyeket egy hook futás előtt elküld a műveleti szabályzatnak. A Claude saját olvasó, író és szerkesztő eszközei a saját folyamatában élnek és láthatatlanul futnak — ráadásul `--dangerously-skip-permissions` kapcsolóval indul, mert a nem interaktív `claude -p` különben örökre a saját promptjánál akadna el

Konkrétan: csak a beépített harness támogatja az alügynököket, a futás közbeni irányítást, a szüneteltetést és a folytatást (és így az átvételt), valamint a mód strukturális érvényesítését. A Claude Code ezek egyikét sem kapja meg.

A fenti mátrix arról szól, mit tud a Control Center látni és szabályozni. Alatta a cc_server a Claude Code CLI-t a gazdagép operációs rendszerének homokozójába csomagolja, ahol van ilyen — Seatbelt macOS-en, bubblewrap Linuxon és WSL2-n —, így egy nem látott rm vagy egy nem látott írás is az operációs rendszer korlátai közé esik. Windowson egyáltalán nincs háttérrendszer, Linuxon vagy WSL2-n pedig bwrap és socat nélkül a próba egyet sem jelez, így ott ezek a futások a környezet tisztítására, a közvetített hitelesítő adatokra, a Control Center által látható hívásokra vonatkozó korlátokra és a beszélgetés saját worktree-jére esnek vissza (copy-on-write ott, ahol a rift elérhető; Windowson git worktree).

Ami viszont a homokozó nem: egy kapu. Behatárolja, hogy egy folyamat hol olvashat, írhat és kapcsolódhat — egy csak olvasható mód el is jut hozzá, csak olvasható bind mountok formájában —, de nem tud elfogni egy hívást, jóváhagyást kérni, vagy utólag megmondani, mit próbált a CLI. Ez, valamint a fentebb nevezett négy képesség az, amije a beépített harnessnek van, a többieknek pedig nincs. Lásd: Homokozó és biztonság.

Egy adapter nélküli ügynök a Control Center (built-in) adapterre esik vissza — ez a szerveren belüli ciklus, így nincs telepítendő CLI —, a futásnaplója pedig a cc-harness értéket rögzíti. Minden előre létrehozott ügynök adapter és modell nélkül jön létre, így egy friss munkaterület öt ügynöke mind ott fut, az Anthropic alapértelmezett modelljén, amíg ügynökönként be nem állítasz egy adaptert és modellt. A bevezető „alapértelmezett adapter” választása egy kliensoldali beállítás, amelyet a szerver soha nem olvas, és nem alkalmazódik visszamenőlegesen a már létrehozott ügynökökre.

Honnan származnak az ügynökök

A munkaterülettel együtt jönnek létre. Minden munkaterület — nem csak az első — kap egy CEO-t és négy specialistát (qa, architect, engineer, librarian), akik a CEO-nak jelentenek, és akik a munkaterület létrehozásakor idempotensen, a háttérben jönnek létre. Lásd: Munkaterületek és elszigetelés.
Kézzel adva hozzá a Beállítások → Munkaterület → Ügynökök helyen. Ha egy ügynöktől azt kéred, hogy vegyen fel egy kollégát, az nem hoz létre sort; használd azt a képernyőt.

Élő állapot

Az ügynöknek nincs tárolt állapotoszlopa. Élő állapota minden beolvasáskor a legutóbbi futásnaplóiból vezethető le:

Állapot	Jelentés
`neverRun`	Nincs futásnapló
`running`	Legalább egy futás éppen folyamatban van
`failed`	A legutóbbi futás hibát adott, vagy az életjelzése sikertelen vagy halott
`blocked`	A legutóbbi futás életjelzése blokkolt, elakadt vagy hurkolódik
`idle`	Minden más — az ügynök már futott, és nincs folyamatban lévő munkája

Két további állapot, a queued és a succeeded, az egyes futásokhoz létezik a beszélgetés futásfájában; a névsor soha nem állítja elő őket, mert az, hogy egy befejezett futás zöld, a futásról szóló tény, nem az ügynökről.

A jelenléti névsor egy párhuzamos, durvább képet mutat, amelyet a szerver állít össze az élő futáseseményekből — gondolkodik, fut, jóváhagyásra várva blokkolva, kész —, és ez az, amitől az ügynökök az emberek mellé kerülnek. Lásd: Többszereplős mód.

Kapcsolódó fogalmak

Ügynökindítás életciklusa: mi történik, amikor egy ügynök ténylegesen elindul
Módok: a beszélgetésenkénti beállítás, amely alakítja az ügynök eszközfelületét
Többszereplős mód: az ügynökök mint jogalanyok, a jelenlét és az autonómiaszabályzó
Homokozó és biztonság: mi korlátozza ma a futásokat
Ügynökkonfiguráció-referencia: a teljes mezőlista