Moduri

Ce este un mod

Un mod este o proprietate a unui spațiu, stocată ca o singură coloană pe rândul spațiului. Fiecare conversație din interiorul unui spațiu îl împărtășește, inclusiv firele — un fir moștenește modul spațiului său ca orice altă conversație. Același agent poate așadar să fie în moduri diferite în spații diferite în același timp, iar schimbarea modului unui spațiu schimbă ce se întâmplă la următorul tur fără să atingă agentul.

Există exact patru: chat, review, plan, orchestrate. Enumerarea în sine nu poartă nicio politică. Tot ce garantează un mod este declarat o singură dată, într-un profil de capabilități, din care proiectează fiecare strat de aplicare:

Suprafața de instrumente — ce instrumente există de fapt în acel mod, exprimate ca un nivel maxim de aprobare, o listă de permisiuni, o listă de interdicții și un set de clase de efecte refuzate.
Verb de ieșire obligatoriu — ce trebuie să apeleze rularea ca să fi livrat ceva.
Clase de efecte interzise — ce refuză categoric garda de acțiuni.
Postura worktree-ului — dacă worktree-ul poate fi scris. Aceasta este aplicată prin eliminarea din suprafață a instrumentelor care modifică starea, ceea ce face ca ea să se respecte pe orice gazdă. Acolo unde gazda are un sandbox la nivel de sistem de operare, aceeași postură decupează și regulile de scriere în sistemul de fișiere — un mod doar pentru citire montează worktree-ul doar pentru citire — dar aceea este o a doua copie a garanției, nu cea care face treaba.
Bloc de prompt de sistem — un preambul de capabilități generat, derivat din lista reală de instrumente materializate, plus îndrumări scrise manual.

Fiecare strat de aplicare proiectează din acel singur profil, așa că suprafața de instrumente, garda, postura worktree-ului și promptul nu se pot contrazice.

Cele patru moduri

Chat — afișat ca „Agent”

Modul implicit și singurul fără constrângeri suplimentare: suprafața completă de instrumente până la nivelul de execuție, un worktree care poate fi scris, nicio clasă de efecte interzisă și niciun contract de finalizare. Folosește-l pentru implementare, corectarea erorilor, întrebări despre baza de cod și orice lucru ad hoc.

Reține eticheta: în zona de compunere, modul este afișat ca „Agent”, nu „Chat”.

Plan — doar pentru citire, un singur livrabil

Modul plan face worktree-ul doar pentru citire și elimină complet din suprafață instrumentele de scriere, așa că restricția este structurală, nu enunțată. Agentul citește, caută și cercetează și livrează exact un singur lucru: un apel submit_plan care poartă un graf de dependențe tipizat — un obiectiv plus noduri cu chei, titluri, descrieri și cheile nodurilor de care depinde fiecare.

Planul se afișează ca un rând compact în conversație și deschide Plan Studio într-o filă alături. Aprobarea lui compilează graful într-o orchestrare, rulează munca generată și readuce spațiul de autorat în modul agent.

Dacă o rulare în modul plan se încheie fără să apeleze vreodată submit_plan, bucla injectează mai întâi un îndemn care spune că planul nu există până când acel apel nu reușește. Îndemnul autorizează explicit o ieșire onestă de tipul „aici nu este nevoie de niciun plan”, pentru că modul plan este o setare a spațiului, iar o simplă întrebare adresată în el nu ar trebui să impună un plan fals.

Există o a doua cale de ieșire, separată: exit_plan_mode. Este o poartă strictă de aprobare, nu un verb de ieșire — un agent care o apelează în loc de submit_plan nu a livrat nimic. Primul apel deschide o aprobare durabilă plan_exit și returnează pending, iar spațiul rămâne doar pentru citire; apelurile repetate rămân pending în loc să deschidă o a doua poartă. Abia după ce aprobarea este acordată, un apel ulterior readuce spațiul pe chat. O respingere îi permite agentului să deschidă o cerere nouă pentru un plan revizuit.

Ca să ieși singur din modul plan, schimbă lista derulantă din zona de compunere (sau Shift+Tab). exit_plan_mode se decide cu instrumentul MCP decide_approval. Rândurile „aprobare agent” din Inbox sunt altceva: solicitări de confirmare pentru fiecare tur, venite de la un agent care rulează.

Revizuire — doar pentru citire, fără contract

Modul revizuire este pentru revizuirea PR-urilor. Face worktree-ul doar pentru citire, plafonează suprafața de instrumente sub nivelul de execuție și aplică o listă de permisiuni atent selectată, cu instrumente de revizuire, de tichete și de comunicare. Un spațiu deschis pentru un pull request este creat automat în modul revizuire.

Rezultatul agentului constă în constatări structurate — noduri de revizuire — și, când o revizuire este finalizată, un verdict. Un nod poartă un tip (bug, suggestion, recommendation, question sau ticket), o prioritate de la P0 (blochează lansarea) la P3 (ar fi bine să existe), un nivel de încredere autoevaluat, o ancoră opțională (un fișier plus un interval de linii; notițele valabile pentru tot depozitul nu au niciuna) și o stare de ciclu de viață care trece de la open la consensusReady odată ce un coleg — niciodată autorul — o confirmă. O constatare a cărei prioritate sau încredere lipsește ori este în afara intervalului este eliminată la granița de citire, în loc să polueze verdictul.

Verdictul este ship, hold sau block și este făcut doar mai sever de rezultatele pe axe incluse în el: o axă cu poartă care a eșuat forțează block, iar o axă cu poartă care nu a putut rula forțează cel puțin hold. Absența dovezilor nu face niciodată o poartă verde.

Spre deosebire de plan și orchestrare, revizuirea nu poartă niciun contract de finalizare. Constatările se acumulează prin add_review_node și sunt publicate prin finalize_review, iar ambele pot fi apelate, în mod legitim, de zero ori — un agent de pipeline care rulează în modul revizuire poate fi acolo tocmai ca să ducă la capăt un tichet.

Orchestrare — doar pentru citire, propune o echipă

Modul orchestrare transformă un singur obiectiv într-un plan pentru o echipă întreagă. Ca și modul plan, este doar pentru citire și nu poate scrie fișiere; peste suprafața de cercetare are un singur verb privilegiat, propose_orchestration, care emite o propunere structurată: roluri, un arbore de subtichete, un pas de sinteză și un buget. Promptul numește doar instrumentele aflate pe suprafață, așa că modelul nu își consumă tururile povestind despre angajări sau muncă de tichete pe care nu le poate apela.

Nimic din propunere nu se execută până când nu o aprobi. La aprobare, un materializator determinist angajează agenții, creează tichetele și un proiect și rulează un pipeline generat. Aprobarea este exclusiv a operatorului: nu există niciun instrument MCP pentru ea, așa că un agent poate propune, dar nu-și poate aproba niciodată propriul plan. Reproplerile inițiate de agent sunt limitate ca frecvență printr-o perioadă de răcire de două minute, așa că replanificările consecutive sunt refuzate și li se spune să le grupeze. Vezi Orchestrare.

Două reguli care merită știute

Verb-ul de ieșire al unui mod nu poate fi refuzat niciodată. submit_plan și propose_orchestration sunt fixate în suprafața de instrumente și preaprobate dincolo de filtrul de instrumente, de poarta de aprobare și de garda de acțiuni deopotrivă, așa că setarea de autonomie proprie spațiului nu poate reduce la tăcere livrabilul unui mod. Instrumentul ask_user al harness-ului este fixat din același motiv: el este modalitatea prin care o rulare ajunge la operator, așa că blocarea lui ar duce la un interblocaj al unei rulări care trebuie să întrebe ceva. Este de nivel de citire, așa că fiecare mod doar pentru citire îl păstrează, și este scutit de învelișul de aprobare — un prompt în fața unui prompt eșuează în siguranță atunci când nu este conectat niciun aprobator, ceea ce i-ar refuza unui agent însuși actul de a întreba.

Modurile doar pentru citire nu interzic accesul la rețea sau la secrete. Clasele de efecte pe care le refuză revizuirea, planul și orchestrarea sunt cele care schimbă lumea: ștergerea fișierelor, scrierile în afara worktree-ului, commit-urile, push-urile, crearea și publicarea de PR-uri, scrierile de sincronizare către furnizori, instalarea de pachete, pornirea de procese, modificarea structurii spațiului de lucru și controlul mediilor izolate. Ieșirea în rețea și accesul la secrete rămân intenționat la valorile lor implicite — cercetarea este însuși scopul unui mod doar pentru citire.

Alegerea și schimbarea unui mod

Lista derulantă de moduri din zona de compunere oferă trei opțiuni: Agent (chat), Plan și Orchestrează. review nu poate fi selectat de utilizator — este setat de sistem când se creează un spațiu de revizuire PR și de pașii de pipeline.

Un nod de pipeline care deschide un spațiu poate fixa modul acelei camere printr-o cheie extras['mode'] (chat, review sau plan). Cheia se potrivește exact: orice altă scriere — inclusiv orchestrate — este ignorată în tăcere, iar camera primește valoarea implicită a corpului (review în corpul create-space). Un pas de agent se alătură unei camere pe care nu a creat-o și nu îi schimbă permisiunile.

Rezolvarea în sine este simplă. Dispecerul citește coloana mode a spațiului; o trimitere fără spațiu — o execuție punctuală, o invocare din CLI sau un id de spațiu din alt spațiu de lucru, care pur și simplu nu se află în fișierul bazei de date al acestui spațiu de lucru — se rezolvă la chat. Schimbarea modului intră în vigoare de la următorul tur.

Unde se susține de fapt garanția

Suprafața de instrumente a unui mod este construită și aplicată de harness-ul integrat. Este singurul transport care poate face un instrument invizibil, nu doar refuzat, care poate pune o poartă în fața fiecărui apel înainte ca acesta să ruleze și care poate observa un contract de finalizare.

Pe transportul Claude Code, un mod care nu este chat este transmis ca --permission-mode plan. Claude respectă acest lucru prin convenție; propriile sale instrumente de citire, scriere și editare rulează fără să fie văzute, iar comenzile sale de shell sunt verificate doar de un hook care citește linia de comandă. Pentru acel transport, modul este o îndrumare, nu o graniță a Control Center — vezi Modelul agenților.

Listele de permisiuni restricționează instrumentele de nivel de scriere și peste. Nivelul de citire al harness-ului integrat ajunge totuși la instrumente pe care nu le numește nicio listă; pe Claude Code, un instrument omis de lista de permisiuni este refuzat indiferent dacă serverul îl are sau nu.

Concepte conexe

Ciclul de viață al trimiterii agenților: unde este rezolvat și proiectat modul
Modelul agenților: ce transporturi pot aplica un mod
Guardrail-uri: politica claselor de efecte în care se varsă presetarea unui mod
Orchestrare: ce face o propunere de orchestrare aprobată
Folosește modul plan: ghidul practic pas cu pas