Przejdź do głównej zawartości

Tryby

Tryb jest właściwością przestrzeni, przechowywaną jako jedna kolumna w wierszu przestrzeni. Współdzieli go każda rozmowa w przestrzeni, łącznie z wątkami — wątek dziedziczy tryb swojej przestrzeni tak jak każda inna rozmowa. Ten sam agent może więc jednocześnie znajdować się w różnych trybach w różnych przestrzeniach, a zmiana trybu przestrzeni zmienia to, co dzieje się w następnej turze, bez dotykania agenta.

Są dokładnie cztery: chat, review, plan, orchestrate. Sam enum nie niesie żadnej polityki. Wszystko, co gwarantuje tryb, jest deklarowane raz, w profilu możliwości, z którego rzutuje każda warstwa egzekwowania:

  1. Powierzchnia narzędzi — które narzędzia w danym trybie w ogóle istnieją, wyrażone jako maksymalny poziom zatwierdzania, lista dozwolonych, lista zabronionych oraz zbiór odrzucanych klas efektów.
  2. Wymagany czasownik wyjściowy — co uruchomienie musi wywołać, aby cokolwiek dostarczyć.
  3. Zabronione klasy efektów — to, czego strażnik akcji odmawia bezwarunkowo.
  4. Postura drzewa roboczego — czy drzewo robocze można zapisywać. Egzekwuje się ją przez usunięcie narzędzi mutujących z powierzchni i właśnie to sprawia, że obowiązuje na każdym hoście. Tam, gdzie host ma sandbox systemu operacyjnego, ta sama postura wyznacza też reguły zapisu do systemu plików — tryb tylko do odczytu montuje drzewo robocze jako tylko do odczytu — ale to druga kopia gwarancji, a nie ta, która wykonuje pracę.
  5. Blok promptu systemowego — generowany wstęp o możliwościach, wyprowadzony z faktycznej, zmaterializowanej listy narzędzi, plus ręcznie napisane wskazówki.

Każda warstwa egzekwowania rzutuje z tego jednego profilu, więc powierzchnia narzędzi, strażnik, postura drzewa roboczego i prompt nie mogą być ze sobą sprzeczne.

Tryb domyślny i jedyny bez dodatkowych ograniczeń: pełna powierzchnia narzędzi aż do poziomu wykonywania, zapisywalne drzewo robocze, brak zabronionych klas efektów i brak kontraktu wykonania. Używaj go do implementacji, poprawek błędów, pytań o bazę kodu i wszystkiego, co doraźne.

Zwróć uwagę na etykietę: w polu tworzenia wiadomości tryb jest wyświetlany jako „Agent”, a nie „Czat”.

Tryb planu czyni drzewo robocze tylko do odczytu i całkowicie usuwa narzędzia zapisu z powierzchni, więc ograniczenie jest strukturalne, a nie tylko wyrażone instrukcją. Agent czyta, przeszukuje i bada, a dostarcza dokładnie jedną rzecz: wywołanie submit_plan niosące typowany graf zależności — cel plus węzły z kluczami, tytułami, opisami i kluczami węzłów, od których każdy zależy.

Plan renderuje się jako zwarty wiersz w rozmowie i otwiera Plan Studio w karcie obok. Jego zatwierdzenie kompiluje graf do orkiestracji, wykonuje wygenerowaną pracę i przełącza przestrzeń, w której powstał plan, z powrotem na tryb agenta.

Jeśli uruchomienie w trybie planu zakończy się, nigdy nie wywołując submit_plan, pętla najpierw wstrzykuje nakierowanie mówiące, że plan nie istnieje, dopóki to wywołanie się nie powiedzie. Nakierowanie wyraźnie upoważnia do uczciwego wyjścia „tu plan nie jest potrzebny”, ponieważ tryb planu jest ustawieniem przestrzeni, a zwykłe pytanie zadane w nim nie powinno wymuszać fałszywego planu.

Istnieje drugie, osobne wyjście: exit_plan_mode. To twarda bramka zatwierdzania, a nie czasownik wyjściowy — agent, który wywoła ją zamiast submit_plan, niczego nie dostarczył. Pierwsze wywołanie otwiera trwałe zatwierdzenie plan_exit i zwraca pending, a przestrzeń pozostaje tylko do odczytu; kolejne wywołania pozostają pending, zamiast otwierać drugą bramkę. Dopiero gdy zatwierdzenie zostanie przyznane, następne wywołanie przełącza przestrzeń na czat. Odrzucenie pozwala agentowi otworzyć nowe żądanie zmienionego planu.

Aby samodzielnie opuścić tryb planu, przełącz listę rozwijaną w polu tworzenia wiadomości (albo użyj Shift+Tab). O exit_plan_mode decyduje narzędzie MCP decide_approval. Wiersze „zatwierdzenie agenta” w Skrzynce to coś innego: potwierdzenia wyświetlane przy każdej turze przez działającego agenta.

Tryb przeglądu służy do recenzowania PR-ów. Czyni drzewo robocze tylko do odczytu, ogranicza powierzchnię narzędzi poniżej poziomu wykonywania i stosuje starannie dobraną listę dozwolonych narzędzi do recenzji, zgłoszeń i komunikacji. Przestrzeń otwarta dla pull requesta jest automatycznie tworzona w trybie przeglądu.

Dane wyjściowe agenta to ustrukturyzowane ustalenia — węzły recenzji — oraz, gdy recenzja zostanie sfinalizowana, werdykt. Węzeł niesie rodzaj (bug, suggestion, recommendation, question lub ticket), priorytet od P0 (blokuje wydanie) do P3 (miłe widziane), samoocenianą pewność, opcjonalną kotwicę (plik wraz z zakresem wierszy; notatki obejmujące całe repozytorium jej nie mają) oraz status cyklu życia, który zmienia się z open na consensusReady, gdy potwierdzi go inny recenzent — nigdy sam autor. Ustalenie, któremu brakuje priorytetu lub pewności albo które ma je poza zakresem, jest odrzucane na granicy odczytu, zamiast zanieczyszczać werdykt.

Werdykt to Ship, Hold albo Block i jest wyłącznie zaostrzany przez wyniki poszczególnych osi, które się do niego wliczają: oś objęta bramką, która zawiodła, wymusza block, a oś objęta bramką, która nie mogła się uruchomić, wymusza co najmniej hold. Brak dowodów nigdy nie zamienia się w zieloną bramkę.

W odróżnieniu od planu i orkiestracji przegląd nie niesie żadnego kontraktu wykonania. Ustalenia gromadzą się przez add_review_node i są publikowane przez finalize_review, a oba można zgodnie z przeznaczeniem wywołać zero razy — agent potoku działający w trybie przeglądu może być tam po to, by ukończyć zgłoszenie.

Tryb orkiestracji zamienia jeden cel w plan całego zespołu. Podobnie jak tryb planu jest tylko do odczytu i nie może zapisywać plików; ponad powierzchnię badawczą ma jeden uprzywilejowany czasownik, propose_orchestration, który emituje ustrukturyzowaną propozycję: role, drzewo zgłoszeń podrzędnych, krok syntezy i budżet. Prompt wymienia wyłącznie narzędzia znajdujące się na powierzchni, więc model nie traci tur na opowiadanie o rekrutacji czy pracy nad zgłoszeniami, których nie może wywołać.

Nic z propozycji nie wykonuje się, dopóki jej nie zatwierdzisz. Po zatwierdzeniu deterministyczny materializator zatrudnia agentów, tworzy zgłoszenia i projekt oraz uruchamia wygenerowany potok. Zatwierdzanie należy wyłącznie do operatora: nie ma do niego narzędzia MCP, więc agent może coś zaproponować, ale nigdy nie zatwierdzi własnego planu. Ponowne propozycje inicjowane przez agenta są ograniczane dwuminutowym okresem oczekiwania, więc kolejne replanowania są odrzucane wraz z zaleceniem scalenia ich w jedno. Zobacz Orkiestracja.

Własnego czasownika wyjściowego trybu nie można nigdy zabronić. submit_plan i propose_orchestration są przypięte do powierzchni narzędzi i wstępnie zatwierdzone z pominięciem filtra narzędzi, bramki zatwierdzania i strażnika akcji, więc suwak autonomii dla przestrzeni nie może uciszyć rezultatu trybu. ask_user harnessu jest przypięte z tego samego powodu: to właśnie sposób, w jaki uruchomienie dociera do operatora, więc objęcie go bramką zablokowałoby uruchomienie, które musi o coś zapytać. Należy do poziomu odczytu, więc każdy tryb tylko do odczytu je zachowuje, i jest wyłączone z otoczki zatwierdzania — prośba o zatwierdzenie przed pytaniem domyślnie odmawia, gdy nie ma podłączonego zatwierdzającego, co odmówiłoby agentowi samego aktu zapytania.

Tryby tylko do odczytu nie blokują dostępu do sieci ani do sekretów. Klasy efektów, których odmawiają przegląd, plan i orkiestracja, to te, które zmieniają świat: usuwanie plików, zapisy poza drzewem roboczym, commity, wypychanie zmian, tworzenie i publikowanie pull requestów, zapisy synchronizacji z zewnętrznymi systemami, instalacje pakietów, uruchamianie procesów, zmiana struktury obszaru roboczego i sterowanie rigiem. Ruch wychodzący do sieci i dostęp do sekretów celowo pozostają na wartościach domyślnych — badanie jest całym sensem trybu tylko do odczytu.

Lista rozwijana trybów w polu tworzenia wiadomości oferuje trzy opcje: Agent (czat), Plan i Orkiestracja. Trybu review nie można wybrać — ustawia go system przy tworzeniu przestrzeni recenzji PR-a oraz kroki potoku.

Węzeł potoku, który otwiera przestrzeń, może przypiąć tryb tej przestrzeni kluczem extras['mode'] (chat, review lub plan). Klucz wymaga dokładnego dopasowania: każda inna pisownia — także orchestrate — jest po cichu ignorowana, a przestrzeń otrzymuje domyślną wartość treści (review w treści create-space). Krok agenta dołącza do przestrzeni, której nie utworzył, i nie nadaje jej ponownie uprawnień.

Samo rozstrzyganie jest proste. Dyspozytor odczytuje kolumnę mode przestrzeni; wysłanie bez przestrzeni — jednorazowe uruchomienie, wywołanie z CLI albo identyfikator przestrzeni z innego obszaru roboczego, którego po prostu nie ma w pliku bazy danych tego obszaru roboczego — jest rozstrzygane jako chat. Zmiana trybu działa od następnej tury.

Powierzchnię narzędzi trybu buduje i egzekwuje wbudowany harness. To jedyny transport, który potrafi uczynić narzędzie niewidocznym, a nie tylko zabronionym, objąć bramką każde wywołanie, zanim zostanie wykonane, i obserwować kontrakt wykonania.

W transporcie Claude Code tryb inny niż czat jest przekazywany jako --permission-mode plan. Claude respektuje to na zasadzie konwencji; jego własne narzędzia odczytu, zapisu i edycji działają niewidocznie, a polecenia powłoki sprawdza tylko hook, który czyta wiersz poleceń. Dla tego transportu tryb jest wskazówką, a nie granicą Control Center — zobacz Model agentów.

Listy dozwolonych ograniczają narzędzia poziomu zapisu i wyższego. Poziom odczytu wbudowanego harnessu nadal sięga narzędzi, których nie wymienia żadna lista; w Claude Code narzędzie pominięte na liście dozwolonych jest odrzucane niezależnie od tego, czy serwer je ma.