Lägen

Vad ett läge är

Ett läge är en egenskap hos en yta och lagras som en kolumn på ytans rad. Varje samtal inuti en yta delar det, trådar inräknade – en tråd ärver sin ytas läge precis som alla andra samtal. Samma agent kan därför vara i olika lägen i olika ytor samtidigt, och att växla en ytas läge ändrar vad som händer på nästa tur utan att röra agenten.

Det finns exakt fyra: chat, review, plan, orchestrate. Själva enumen bär ingen policy. Allt ett läge garanterar deklareras en gång, i en kapacitetsprofil, som varje upprätthållandelager projicerar från:

Verktygsyta – vilka verktyg som alls finns i det läget, uttryckt som en högsta godkännandenivå, en tillåtelselista, en neklista och en uppsättning avvisade effektklasser.
Obligatoriskt utdataverb – vad körningen måste anropa för att ha levererat något.
Nekade effektklasser – vad åtgärdsräckena avvisar rakt av.
Worktree-läge – om worktreen får skrivas i. Det upprätthålls genom att de muterande verktygen tas bort från ytan, och det är det som gör att det håller på varje värd. Där värden har en OS-sandlåda formar samma läge dessutom filsystemets skrivregler – ett skrivskyddat läge monterar worktreen skrivskyddad – men det är en andra kopia av garantin, inte den som gör jobbet.
Systempromptblock – en genererad kapacitetsinledning härledd från den faktiskt materialiserade verktygslistan, plus handskriven vägledning.

Varje upprätthållandelager projicerar från den enda profilen, så verktygsytan, räckena, worktree-läget och prompten kan inte gå isär.

De fyra lägena

Chatt – visas som “Agent”

Standardläget och det enda läget utan extra begränsningar: hela verktygsytan upp till utförandenivån, en skrivbar worktree, inga nekade effektklasser och inget slutförandekontrakt. Använd det för implementation, buggfixar, frågor om kodbasen och allt ad hoc.

Notera etiketten: i composern visas läget som “Agent”, inte “Chatt”.

Plan – skrivskyddat, en leverans

Planläget gör worktreen skrivskyddad och tar bort skrivverktygen från ytan helt och hållet, så begränsningen är strukturell i stället för påbjuden. Agenten läser, söker och researchar och levererar exakt en sak: ett submit_plan-anrop som bär en typad beroendegraf – ett mål plus noder med nycklar, titlar, beskrivningar och de nodnycklar som var och en är beroende av.

Planen visas som en kompakt rad i samtalet och öppnar Plan Studio i en flik bredvid. Att godkänna den kompilerar grafen till en orkestrering, kör det genererade arbetet och ställer tillbaka ytan där planen skapades till agentläge.

Om en körning i planläge avslutas utan att någonsin anropa submit_plan, injicerar loopen först en puff som säger att planen inte finns förrän det anropet lyckas. Puffen tillåter uttryckligen en ärlig utgång av typen “här behövs ingen plan”, eftersom planläget är en inställning på ytan och en enkel fråga som ställs i det inte bör tvinga fram en falsk plan.

Det finns en andra, separat väg ut: exit_plan_mode. Det är en hård godkännandegrind, inte ett utdataverb – en agent som anropar det i stället för submit_plan har inte levererat något. Det första anropet öppnar ett varaktigt plan_exit-godkännande och returnerar pending, och ytan förblir skrivskyddad; upprepade anrop stannar i pending i stället för att öppna en andra grind. Först när godkännandet har beviljats växlar ett efterföljande anrop ytan till chatt. En avvisning låter agenten öppna en ny begäran om en reviderad plan.

För att själv lämna planläget växlar du dropdown-menyn i composern (eller Shift+Tab). exit_plan_mode avgörs med MCP-verktyget decide_approval. Rader för “agentgodkännande” i inkorgen är något annat: bekräftelseprompter per tur från en körande agent.

Granskning – skrivskyddat, inget kontrakt

Granskningsläget är till för PR-granskning. Det gör worktreen skrivskyddad, kapar verktygsytan nedanför utförandenivån och tillämpar en kurerad tillåtelselista med gransknings-, ärende- och kommunikationsverktyg. En yta som öppnas för en pull request skapas automatiskt i granskningsläge.

Agentens utdata är strukturerade fynd – granskningsnoder – och, när en granskning finaliseras, ett utfall. En nod bär en typ (bug, suggestion, recommendation, question eller ticket), en prioritet från P0 (blockerar release) till P3 (trevligt att ha), en självskattad konfidens, ett valfritt ankare (fil plus ett radintervall; anteckningar som gäller hela repot har inget) och en livscykelstatus som går från open till consensusReady när en kollega – aldrig författaren – bekräftar den. Ett fynd vars prioritet eller konfidens saknas eller ligger utanför intervallet släpps vid läggränsen i stället för att förorena utfallet.

Utfallet är Ship, Hold eller Block, och det görs bara mer allvarligt av axelresultaten som vävs in i det: en grindad axel som misslyckades tvingar fram block och en grindad axel som inte kunde köras tvingar fram minst hold. Frånvaro av bevis gör aldrig en grind grön.

Till skillnad från plan- och orkestreringslägena har granskning inget slutförandekontrakt. Fynd samlas genom add_review_node och publiceras av finalize_review, och båda får med rätta anropas noll gånger – en pipelineagent som kör i granskningsläge kan vara där för att slutföra ett ärende i stället.

Orkestrering – skrivskyddat, föreslår ett team

Orkestreringsläget förvandlar ett mål till en plan för hela teamet. Precis som planläget är det skrivskyddat och kan inte skriva filer; ovanpå forskningsytan har det ett enda privilegierat verb, propose_orchestration, som avger ett strukturerat förslag: roller, ett träd av underärenden, ett syntessteg och en budget. Prompten namnger bara verktygen på ytan, så modellen slösar inte turer på att berätta om anställningar eller ärendearbete som den inte kan anropa.

Inget i förslaget körs förrän du godkänner det. Vid godkännande anställer en deterministisk materialiserare agenterna, skapar ärendena och ett projekt och kör en genererad pipeline. Godkännande är förbehållet operatören: det finns inget MCP-verktyg för det, så en agent kan föreslå men aldrig godkänna sin egen plan. Agentinitierade omförslag begränsas av en nedkylningsperiod på två minuter, så på varandra följande omplaneringar avvisas och uppmanas att slås samman. Se Orkestrering.

Två regler värda att känna till

Ett läges eget utdataverb kan aldrig nekas. submit_plan och propose_orchestration är låsta i verktygsytan och förhandsgodkända förbi både verktygsfiltret, godkännandegrinden och åtgärdsräckena, så autonomivredet per yta kan inte tysta ett läges leverans. Harnessens ask_user är låst av samma skäl: det är sättet en körning når operatören, så att grinda det skulle låsa en körning som behöver fråga något. Det ligger på läsnivå, så varje skrivskyddat läge behåller det, och det är undantaget från godkännandeomslaget – en prompt framför en prompt misslyckas stängt när ingen godkännare är ansluten, vilket skulle neka en agent själva akten att fråga.

Skrivskyddade lägen nekar inte nätverksåtkomst eller hemligheter. Effektklasserna som granskning, plan och orkestrering avvisar är de som förändrar världen: filradering, skrivningar utanför worktreen, commits, pushar, skapande och publicering av PR:er, skrivningar vid leverantörssynkronisering, paketinstallationer, processstart, mutation av arbetsytan och styrning av stationer. Utgående nätverkstrafik och åtkomst till hemligheter ligger kvar på sina standardvärden med avsikt – research är hela poängen med ett skrivskyddat läge.

Att välja och byta läge

Lägesmenyn i composern erbjuder tre alternativ: Agent (chatt), Plan och Orkestrera. review är inte valbart av användaren – det sätts av systemet när en PR-granskningsyta skapas och av pipelinesteg.

En pipelinenod som öppnar en yta kan låsa ytans läge med nyckeln extras['mode'] (chat, review eller plan). Nyckeln kräver exakt matchning: varje annan stavning – inklusive orchestrate – ignoreras tyst och ytan får bodyns standardvärde (review i bodyn som skapar ytan). Ett agentsteg ansluter till en yta som det inte skapade och ändrar inte dess behörigheter.

Själva upplösningen är enkel. Dispatcharen läser ytans mode-kolumn; en dispatch utan yta – en engångskörning, ett CLI-anrop eller ett yt-id från en annan arbetsyta, som helt enkelt inte finns i den här arbetsytans databasfil – löses upp till chat. Ett lägesbyte gäller från nästa tur.

Var garantin faktiskt håller

Ett läges verktygsyta byggs och upprätthålls av den inbyggda harnessen. Det är den enda transporten som kan göra ett verktyg osynligt i stället för bara nekat, grinda varje anrop innan det körs och observera ett slutförandekontrakt.

På transporten Claude Code skickas ett läge som inte är chatt vidare som --permission-mode plan. Claude följer det av konvention; dess egna läs-, skriv- och redigeringsverktyg körs osedda och dess shellkommandon kontrolleras bara av en hook som läser kommandoraden. För den transporten är läget vägledning, inte en gräns från Control Center – se Agentmodellen.

Tillåtelselistorna begränsar verktyg på skrivnivå och uppåt. Den inbyggda harnessens läsnivå når fortfarande verktyg som ingen lista namnger; på Claude Code nekas ett verktyg som tillåtelselistan utelämnar, oavsett om servern har det eller inte.

Relaterade koncept

Livscykel för agentdispatch: var läget löses upp och projiceras
Agentmodellen: vilka transporter som kan upprätthålla ett läge
Räcken: effektklasspolicyn som ett läges förinställning matar in i
Orkestrering: vad ett godkänt orkestreringsförslag gör
Använd planläge: den praktiska genomgången