Módok

Mi a mód

A mód egy tér tulajdonsága, amelyet a tér sorában egyetlen oszlop tárol. A téren belül minden beszélgetés osztozik rajta, az üzenetszálakkal együtt — a szál ugyanúgy örökli a tere módját, mint bármely más beszélgetés. Ugyanaz az ügynök ezért egyidejűleg különböző módokban lehet különböző terekben, és a tér módjának átváltása a következő körtől kezdve megváltoztatja, hogy mi történik, anélkül hogy az ügynökhöz hozzányúlna.

Pontosan négy van belőlük: chat, review, plan, orchestrate. Maga az enum nem hordoz szabályzatot. Minden, amit egy mód garantál, egyszer van deklarálva, egy képességprofilban, amelyből minden érvényesítési réteg kivetít:

Eszközfelület — egyáltalán mely eszközök léteznek abban a módban, maximális jóváhagyási szintként, engedélyezési listaként, tiltólistaként és a megtagadott hatásfajták halmazaként kifejezve.
Kötelező kimeneti ige — mit kell a futtatásnak meghívnia ahhoz, hogy bármit is leszállítottnak lehessen tekinteni.
Megtagadott hatásfajták — amit a műveletőr azonnal elutasít.
Worktree-állapot — írható-e a worktree. Ez úgy érvényesül, hogy a módosító eszközöket kivonja a felületből, és ez az, amitől minden hoszton fennáll. Ahol a hoszton van operációs rendszer szintű homokozó, ugyanez az állapot alakítja ki a fájlrendszer írási szabályait is — egy csak olvasható mód csak olvashatóként csatolja a worktree-t —, de ez a garancia második példánya, nem az, amelyik a munkát végzi.
Rendszerprompt-blokk — a ténylegesen materializált eszközlistából származtatott generált képességbevezető, valamint kézzel írt útmutatás.

Minden érvényesítési réteg ebből az egyetlen profilból vetít ki, így az eszközfelület, a műveletőr, a worktree-állapot és a prompt nem mondhat ellent egymásnak.

A négy mód

Csevegés — „Ügynök” néven jelenik meg

Az alapértelmezett, és az egyetlen mód, amelyhez nem tartozik külön megkötés: a teljes eszközfelület a végrehajtási szintig, írható worktree, nincsenek megtagadott hatásfajták, és nincs teljesítési szerződés. Használja implementáláshoz, hibajavításhoz, a kódbázissal kapcsolatos kérdésekhez és bármi ad hoc feladathoz.

Figyelje meg a címkét: az üzenetszerkesztőben a mód „Ügynök” néven jelenik meg, nem pedig „Csevegés” néven.

Terv — csak olvasható, egyetlen leszállítandó

A terv mód csak olvashatóvá teszi a worktree-t, és az íróeszközöket teljesen kivonja a felületből, így a korlátozás strukturális, nem pedig előírt. Az ügynök olvas, keres és kutat, és pontosan egy dolgot szállít le: egy submit_plan hívást, amely típusos függőségi gráfot hordoz — egy célt, valamint kulcsokkal, címekkel és leírásokkal ellátott csomópontokat, és mindegyiknél azoknak a csomópontoknak a kulcsait, amelyektől függ.

A terv egy tömör sorban jelenik meg a beszélgetésben, és mellette egy lapon megnyitja a Plan Studiót. Jóváhagyása orchestrációvá fordítja a gráfot, lefuttatja a generált munkát, és a tervet készítő teret visszaváltja ügynökmódba.

Ha egy terv módban futó futtatás úgy ér véget, hogy soha nem hívta meg a submit_plan-t, a ciklus először beszúr egy ösztönzést, amely szerint a terv addig nem létezik, amíg ez a hívás nem sikerül. Az ösztönzés kifejezetten engedélyezi az őszinte „itt nincs szükség tervre” kimenetet, mivel a terv mód egy tér beállítása, és egy benne feltett egyszerű kérdésnek nem szabad hamis tervet kikényszerítenie.

Van egy második, külön kivezető út is: az exit_plan_mode. Ez kemény jóváhagyási kapu, nem kimeneti ige — az az ügynök, amelyik ezt hívja meg a submit_plan helyett, semmit nem szállított le. Az első hívás megnyit egy tartós plan_exit jóváhagyást, és pending értékkel tér vissza, a tér pedig csak olvasható marad; az ismételt hívások pending állapotban maradnak, és nem nyitnak második kaput. Csak a jóváhagyás megadása után váltja át egy későbbi hívás a teret csevegésre. Elutasítás esetén az ügynök új kérést nyithat egy módosított tervhez.

Ha saját maga szeretne kilépni a terv módból, váltson az üzenetszerkesztő legördülő menüjében (vagy nyomjon Shift+Tab-ot). Az exit_plan_mode-ról a decide_approval MCP-eszköz dönt. A Beérkezett „ügynök jóváhagyása” sorai más dolgot jelentenek: egy futó ügynök körönkénti megerősítést kérő promptjai.

Átnézés — csak olvasható, szerződés nélkül

Az átnézés mód a PR-átnézéshez való. Csak olvashatóvá teszi a worktree-t, a végrehajtási szint alá szorítja az eszközfelületet, és egy válogatott engedélyezési listát alkalmaz az átnézési, jegykezelési és kommunikációs eszközökre. Egy pull requesthez megnyitott tér automatikusan átnézés módban jön létre.

Az ügynök kimenete strukturált megállapítások — átnézési csomópontok —, és amikor egy átnézés lezárul, egy ítélet. Egy csomópont hordoz egy fajtát (bug, suggestion, recommendation, question vagy ticket), egy prioritást P0-tól (blokkolja a kiadást) P3-ig (hasznos, de nem kötelező), egy önértékelt bizonyosságot, egy opcionális horgonyt (fájl és egy sorintervallum; a tároló szintű megjegyzéseknek nincs) és egy életciklus-állapotot, amely open állapotból consensusReady állapotba lép, amint egy társ — soha nem a szerző — megerősíti. Az a megállapítás, amelynek a prioritása vagy a bizonyossága hiányzik, vagy tartományon kívül esik, az olvasási határon kiesik, és nem szennyezi az ítéletet.

Az ítélet ship, hold vagy block, és a belefoglalt, tengelyenkénti eredmények csak szigorúbbá tehetik: egy megbukott kapuzott tengely block-ot kényszerít ki, egy lefutni képtelen kapuzott tengely pedig legalább hold-ot. A bizonyíték hiánya soha nem zöldít ki egy kaput.

A tervvel és az orchestrálással ellentétben az átnézés nem jár teljesítési szerződéssel. A megállapítások az add_review_node hívásain keresztül gyűlnek, és a finalize_review teszi közzé őket, és mindkettőt jogszerűen meg lehet hívni nullaszor is — előfordulhat, hogy egy átnézés módban futó pipeline-ügynök valójában egy jegy teljesítése miatt van ott.

Orchestrálás — csak olvasható, csapatot javasol

Az orchestrálás mód egyetlen célból egész csapatra szóló tervet készít. A terv módhoz hasonlóan csak olvasható, és nem tud fájlokat írni; a kutatási felület tetején egyetlen kiváltságos igéje van, a propose_orchestration, amely strukturált javaslatot bocsát ki: szerepköröket, alticket-fát, egy szintézislépést és egy költségkeretet. A prompt csak a felületen lévő eszközöket nevezi meg, így a modell nem pazarol köröket arra, hogy olyan toborzásról vagy jegymunkáról meséljen, amelyeket nem tud meghívni.

A javaslatban semmi sem fut le, amíg Ön jóvá nem hagyja. Jóváhagyáskor egy determinisztikus materializáló felveszi az ügynököket, létrehozza a jegyeket és egy projektet, majd lefuttat egy generált pipeline-t. A jóváhagyás kizárólag kezelői hatáskör: nincs hozzá MCP-eszköz, így egy ügynök javasolhat, de a saját tervét soha nem hagyhatja jóvá. Az ügynök által kezdeményezett újbóli javaslatokat egy kétperces várakozási idő korlátozza, ezért az egymást követő újratervezések elutasításra kerülnek, és összevonásra szólítják fel őket. Lásd: Orchestráció.

Két szabály, amit érdemes tudni

Egy mód saját kimeneti igéjét soha nem lehet megtagadni. A submit_plan és a propose_orchestration be van ékelve az eszközfelületbe, és előzetesen jóvá van hagyva úgy, hogy megelőzi egyaránt az eszközszűrőt, a jóváhagyási kaput és a műveletőrt, így a térenkénti autonómiacsúszka nem hallgattathatja el egy mód leszállítandóját. A harness ask_user eszköze ugyanezen okból van beékelve: ez az, ahogyan egy futtatás eléri a kezelőt, így a kapuzása holtpontra vinné azt a futtatást, amelynek kérdeznie kell valamit. Olvasási szintű, ezért minden csak olvasható mód megtartja, és mentesül a jóváhagyási burkoló alól — egy prompt egy másik prompt előtt zárt állapotban hibázik, ha nincs csatlakoztatva jóváhagyó, ami megvonná az ügynöktől a kérés aktusát.

A csak olvasható módok nem tagadják meg a hálózati hozzáférést vagy a titkokat. Azok a hatásfajták, amelyeket az átnézés, a terv és az orchestrálás megtagad, azok, amelyek megváltoztatják a világot: fájltörlés, a worktree-n kívüli írás, commitok, pushek, PR létrehozása és közzététele, külső követőbe történő szinkronírás, csomagtelepítés, folyamatindítás, munkaterület-módosítás és elszigetelt környezet vezérlése. A hálózati kimenő forgalom és a titkokhoz való hozzáférés szándékosan az alapértelmezésükön marad — a kutatás egy csak olvasható mód teljes lényege.

A mód kiválasztása és megváltoztatása

Az üzenetszerkesztő módválasztója három lehetőséget kínál: Ügynök (csevegés), Terv és Orchestrálás. A review nem választható ki a felhasználó által — azt a rendszer állítja be, amikor egy PR-átnézési tér létrejön, valamint a pipeline-lépések.

Egy pipeline-csomópont, amely teret nyit, rögzítheti az adott szoba módját egy extras['mode'] kulccsal (chat, review vagy plan). A kulcs pontos egyezést vár: minden más írásmódot — az orchestrate-et is beleértve — csendben figyelmen kívül hagy, és a szoba a törzs alapértelmezését kapja (review a térlétrehozó törzsön). Egy ügynöklépés olyan szobába lép be, amelyet nem ő hozott létre, és nem állítja át annak jogosultságait.

Maga a feloldás egyszerű. A dispatcher a tér mode oszlopát olvassa; egy tér nélküli indítás — egyszeri futtatás, CLI-hívás, vagy egy másik munkaterületről származó tér-azonosító, amely egyszerűen nincs benne ennek a munkaterületnek az adatbázisfájljában — chat értékre oldódik fel. A mód megváltoztatása a következő körtől lép életbe.

Hol áll fenn valójában a garancia

Egy mód eszközfelületét a beépített harness építi fel és érvényesíti. Ez az egyetlen transzport, amely egy eszközt láthatatlanná tud tenni a puszta megtagadás helyett, minden hívást meg tud kapuzni a lefutása előtt, és meg tud figyelni egy teljesítési szerződést.

A Claude Code transzporton egy nem csevegés mód --permission-mode plan formában kerül átadásra. A Claude ezt konvenció szerint betartja; a saját olvasó-, író- és szerkesztőeszközei láthatatlanul futnak, a shellparancsait pedig csak egy hook ellenőrzi, amely a parancssort olvassa. Ennél a transzportnál a mód útmutatás, nem a Control Center határa — lásd: Az ügynökmodell.

Az engedélyezési listák az írási szintű és annál magasabb szintű eszközöket korlátozzák. A beépített harness olvasási szintje továbbra is eléri azokat az eszközöket, amelyeket egyetlen lista sem nevez meg; a Claude Code-on egy, az engedélyezési listából kimaradt eszköz elutasításra kerül, akár rendelkezik vele a szerver, akár nem.

Kapcsolódó fogalmak

Ügynökindítás életciklusa: ahol a mód feloldódik és kivetítődik
Az ügynökmodell: mely transzportok tudnak módot érvényesíteni
Korlátok: a hatásfajta-szabályzat, amelyet egy mód készlete táplál
Orchestráció: mit tesz egy jóváhagyott orchestrálási javaslat
Tervmód használata: a gyakorlati végigvezetés