Modlar

Mod nedir

Bir mod bir alanın özelliğidir ve alan satırındaki tek bir sütunda saklanır. Bir alanın içindeki her konuşma, thread’ler dahil, bu özelliği paylaşır — bir thread de tıpkı diğer konuşmalar gibi ait olduğu alanın modunu devralır. Bu sayede aynı ajan aynı anda farklı alanlarda farklı modlarda bulunabilir ve bir alanın modunu değiştirmek, ajana dokunmadan bir sonraki turda ne olacağını değiştirir.

Tam olarak dört mod vardır: chat, review, plan, orchestrate. Enum’un kendisi hiçbir politika taşımaz. Bir modun garanti ettiği her şey tek bir yerde, her denetim katmanının kendisinden türettiği bir yetenek profilinde tanımlanır:

Araç yüzeyi — o modda hangi araçların var olduğu; bir üst onay kademesi, bir izin listesi, bir ret listesi ve bir reddedilen etki sınıfları kümesiyle ifade edilir.
Zorunlu çıktı fiili — bir çalıştırmanın bir şey teslim etmiş sayılması için neyi çağırması gerektiği.
Reddedilen etki sınıfları — eylem koruyucusunun doğrudan reddettikleri.
Worktree duruşu — worktree’ye yazılıp yazılamayacağı. Bu, değişiklik yapan araçların yüzeyden çıkarılmasıyla uygulanır; garantinin her ana makinede geçerli olmasını sağlayan da budur. Ana makinede bir işletim sistemi sandbox’ı varsa aynı duruş dosya sistemi yazma kurallarını da şekillendirir — salt okunur bir mod worktree’yi salt okunur bağlar — ama bu, garantinin ikinci bir kopyasıdır, işi yapan şey değil.
Sistem istemi bloğu — gerçekte somutlaşan araç listesinden türetilen üretilmiş bir yetenek önsözü ve elle yazılmış yönlendirme.

Her denetim katmanı o tek profilden türetir; bu yüzden araç yüzeyi, koruyucu, worktree duruşu ve istem birbiriyle çelişemez.

Dört mod

Sohbet — “Ajan” olarak gösterilir

Varsayılan moddur ve ek kısıtı olmayan tek moddur: yürütme kademesine kadar tam araç yüzeyi, yazılabilir bir worktree, reddedilen etki sınıfı yok ve tamamlanma sözleşmesi yok. Uygulama, hata düzeltme, kod tabanıyla ilgili sorular ve her türlü doğaçlama iş için kullanın.

Etikete dikkat edin: ileti alanında bu mod “Sohbet” değil, “Ajan” olarak gösterilir.

Plan — salt okunur, tek teslimat

Plan modu worktree’yi salt okunur yapar ve yazma araçlarını yüzeyden tamamen çıkarır; böylece kısıtlama talimatla değil yapısal olarak uygulanır. Ajan okur, arar ve araştırır ve tam olarak tek bir şey teslim eder: tipli bir bağımlılık grafiği taşıyan bir submit_plan çağrısı — bir hedef ile anahtarları, başlıkları, açıklamaları ve her birinin bağlı olduğu düğüm anahtarlarını içeren düğümler.

Plan, konuşmada kompakt bir satır olarak görünür ve yanındaki bir sekmede Plan Studio’yu açar. Onaylamak, grafiği bir orkestrasyona derler, üretilen işi çalıştırır ve planı yazan alanı yeniden ajan moduna döndürür.

Bir plan modu çalıştırması hiç submit_plan çağırmadan sona ererse, döngü önce planın o çağrı başarılı olana kadar var olmadığını söyleyen bir dürtme iletisi enjekte eder. Bu dürtme, dürüst bir “burada plana gerek yok” çıkışına açıkça izin verir; çünkü plan modu bir alan ayarıdır ve içinde sorulan sıradan bir soru uydurma bir planı zorlamamalıdır.

İkinci ve ayrı bir çıkış yolu daha vardır: exit_plan_mode. Bu bir çıktı fiili değil, katı bir onay kapısıdır — submit_plan yerine onu çağıran bir ajan hiçbir şey teslim etmemiştir. İlk çağrı kalıcı bir plan_exit onayı açar ve pending döndürür, alan salt okunur kalır; yinelenen çağrılar ikinci bir kapı açmak yerine pending olarak kalır. Ancak onay verildikten sonra sonraki bir çağrı alanı sohbete döndürür. Bir ret, ajanın revize edilmiş bir plan için yeni bir istek açmasına izin verir.

Plan modundan kendiniz çıkmak için ileti alanındaki açılır menüyü (veya Shift+Tab) kullanın. exit_plan_mode kararı decide_approval MCP aracıyla verilir. Gelen kutusundaki “ajan onayı” satırları başka bir şeydir: çalışan bir ajanın tur bazlı onay istemleri.

İnceleme — salt okunur, sözleşme yok

İnceleme modu PR incelemesi içindir. Worktree’yi salt okunur yapar, araç yüzeyini yürütme kademesinin altında sınırlar ve inceleme, biletleme ve iletişim araçlarından oluşan özenle seçilmiş bir izin listesi uygular. Bir pull request için açılan alan otomatik olarak inceleme modunda oluşturulur.

Ajanın çıktısı yapılandırılmış bulgulardır — inceleme düğümleri — ve bir inceleme kesinleştirildiğinde bir karar. Bir düğüm; bir tür (bug, suggestion, recommendation, question veya ticket), P0’dan (sürümü engeller) P3’e (olsa iyi olur) kadar bir öncelik, kendi değerlendirdiği bir güven düzeyi, isteğe bağlı bir çapa (dosya artı bir satır aralığı; depo geneli notların çapası yoktur) ve bir akran — asla yazar — onayladığında open durumundan consensusReady durumuna geçen bir yaşam döngüsü durumu taşır. Önceliği veya güven düzeyi eksik ya da aralık dışı olan bir bulgu, kararı kirletmek yerine okuma sınırında düşürülür.

Karar ship, hold veya block’tur ve yalnızca içine katılan eksen bazlı sonuçlarla daha ağır hale gelir: kapı denetimli bir eksen başarısız olursa block, çalıştırılamayan kapı denetimli bir eksen ise en az hold zorunlu olur. Kanıt yokluğu hiçbir kapıyı yeşile çevirmez.

Plan ve orkestrasyondan farklı olarak inceleme tamamlanma sözleşmesi taşımaz. Bulgular add_review_node ile birikir ve finalize_review ile yayımlanır; her ikisi de meşru biçimde sıfır kez çağrılabilir — inceleme modunda çalışan bir pipeline ajanı bunun yerine bir bileti tamamlamak için orada olabilir.

Orkestrasyon — salt okunur, bir ekip önerir

Orkestrasyon modu tek bir hedefi tüm ekip için bir plana dönüştürür. Plan modu gibi salt okunurdur ve dosya yazamaz; araştırma yüzeyinin üzerine, yapılandırılmış bir öneri üreten tek bir ayrıcalıklı fiile sahiptir: propose_orchestration. Bu öneri; rolleri, bir alt bilet ağacını, bir sentez adımını ve bir bütçeyi içerir. İstem yalnızca yüzeydeki araçları adlandırır; böylece model, çağıramadığı işe alım veya bilet işlerini anlatarak tur harcamaz.

Önerideki hiçbir şey siz onaylayana kadar yürütülmez. Onay verildiğinde deterministik bir somutlaştırıcı ajanları işe alır, biletleri ve bir projeyi oluşturur ve üretilmiş bir pipeline çalıştırır. Onaylama yalnızca operatöre aittir: bunun için bir MCP aracı yoktur; dolayısıyla bir ajan öneri sunabilir ama kendi planını asla onaylayamaz. Ajan tarafından başlatılan yeniden öneriler iki dakikalık bir bekleme süresiyle sınırlanır; art arda gelen yeniden planlama istekleri reddedilir ve birleştirilmeleri söylenir. Bkz. Orkestrasyon.

Bilinmeye değer iki kural

Bir modun kendi çıktı fiili asla reddedilemez. submit_plan ve propose_orchestration, araç yüzeyine sabitlenir ve araç filtresini, onay kapısını ve eylem koruyucusunu aynı şekilde aşacak biçimde önceden onaylanır; böylece alan bazlı otonomi kadranı bir modun teslimatını susturamaz. Harness’in ask_user aracı da aynı nedenle sabitlenir: bir çalıştırmanın operatöre ulaşma yolu odur; dolayısıyla onu kapıdan geçirmek, bir şey sorması gereken bir çalıştırmayı kilitler. Okuma kademesindedir, bu yüzden her salt okunur mod onu korur ve onay sarmalayıcısından muaftır — bir istemin önüne konan istem, onaylayıcı bağlı değilken kapalı yönde başarısız olur; bu da ajandan sorma eylemini esirger.

Salt okunur modlar ağ erişimini veya sırları reddetmez. İnceleme, plan ve orkestrasyonun reddettiği etki sınıfları dünyayı değiştirenlerdir: dosya silme, worktree dışına yazma, commit’ler, push’lar, PR oluşturma ve yayımlama, harici takip sistemi eşitleme yazmaları, paket kurulumları, süreç başlatma, çalışma alanı mutasyonu ve enclosure denetimi. Ağ çıkışı ve sır erişimi bilinçli olarak varsayılanlarında kalır — araştırma, salt okunur bir modun tüm amacıdır.

Mod seçme ve değiştirme

İleti alanındaki mod açılır menüsü üç seçenek sunar: Ajan (sohbet), Plan ve Orkestrasyon. review kullanıcı tarafından seçilemez — bir PR inceleme alanı oluşturulduğunda sistem tarafından ve pipeline adımları tarafından ayarlanır.

Bir alanı açan bir pipeline düğümü, extras['mode'] anahtarıyla (chat, review veya plan) o odanın modunu sabitleyebilir. Anahtar tam eşleşmelidir: başka herhangi bir yazım — orchestrate dahil — sessizce yok sayılır ve oda gövdenin varsayılanını alır (create-space gövdesinde review). Bir ajan adımı, kendi oluşturmadığı bir odaya katılır ve odaya yeniden izin vermez.

Çözümlemenin kendisi basittir. Gönderici, alanın mode sütununu okur; alanı olmayan bir gönderim — tek seferlik bir çalıştırma, bir CLI çağrısı veya bu çalışma alanının veritabanı dosyasında zaten bulunmayan başka bir çalışma alanından gelen bir alan kimliği — chat olarak çözümlenir. Modu değiştirmek bir sonraki turdan itibaren geçerli olur.

Garantinin gerçekte geçerli olduğu yer

Bir modun araç yüzeyi yerleşik harness tarafından oluşturulur ve uygulanır. Bir aracı yalnızca reddetmek yerine görünmez kılabilen, her çağrıyı çalışmadan önce kapıdan geçirebilen ve bir tamamlanma sözleşmesini gözlemleyebilen tek taşıma katmanıdır.

Claude Code taşıma katmanında sohbet dışı bir mod --permission-mode plan olarak geçirilir. Claude bunu yalnızca bir gelenek olarak dikkate alır; kendi okuma, yazma ve düzenleme araçları görünmeden çalışır, shell komutlarını ise yalnızca komut satırını okuyan bir hook denetler. Bu taşıma katmanı için mod bir yönlendirmedir, bir Control Center sınırı değil — bkz. Ajan modeli.

İzin listeleri yazma kademesi ve üzerindeki araçları kısıtlar. Yerleşik harness’in okuma kademesi, hiçbir listenin adlandırmadığı araçlara yine de erişir; Claude Code’da ise izin listesinin dışarıda bıraktığı bir araç, sunucuda bulunsun ya da bulunmasın reddedilir.

İlgili kavramlar

Ajan gönderim yaşam döngüsü: modun nerede çözümlendiği ve yansıtıldığı
Ajan modeli: hangi taşıma katmanlarının bir modu uygulayabildiği
Korumalar: bir modun ön ayarının beslediği etki sınıfı politikası
Orkestrasyon: onaylanan bir orkestrasyon önerisinin ne yaptığı
Plan modunu kullanma: uygulamalı adım adım anlatım