Ajan gönderim yaşam döngüsü

Gönderim nedir

Bir gönderim, bir ajanın tek bir konuşmada, tek bir adaptör üzerinde yaptığı tek bir çalıştırmadır. Onunla ilgili her şey cc_server üzerinde gerçekleşir: istemci bir mesaj gönderir, ardından olayların geri akışını izler. Hiçbir istemcide gönderim yolu yoktur.

Ajanlar altı nedenden dolayı uyandırılır; çalıştırma bunları uyandırma bağlamı olarak taşır, böylece ajan neden uyanık olduğunu bilir:

Uyandırma nedeni	Tetikleyici
userMessage	Birisi bir alana mesaj gönderdi veya ajanı andı
assignment	Ajana bir bilet atandı
pipelineStep	Bir pipeline adımı onu gönderdi
childCompleted	Bir alt bilet tamamlandı
followUp	Zamanlanmış bir takip kalp atışı
recovery	Kurtarma yolu bir başarısızlıktan sonra yeniden gönderdi

Uyandırma bağlamı, nedene eşlik eden ID’leri taşır — bilet, alan, mesaj, pipeline çalıştırması — ve bunlar ajanın ortamına ve istemine enjekte edilir.

İstem birleştirme

İstem katmanlar hâlinde kurulur; her katman etiketli bir bölümdür:

• Kimlik — ajanın kendi ID’si, adı ve çalışma alanı ID’si; bu UUID’lerin tam olarak çalışma alanına özel araçlara geçirilmesi için açık bir talimatla birlikte. Çalışma alanı ajana özgüdür, bu yüzden her zaman bulunur.
• Araç kataloğu ve kaynak protokolleri, ardından çalışma alanı düzeni.
• Varsa sistem istemi geçersiz kılması, ardından persona (role göre parametrelenir) ve ekip brifingi.
• Beceriler — ajandaki adlar.
• Geçerli mod için yürütme sözleşmesi ve yordamı.
• Uyandırma bağlamı ve anma bağlamı: ajanı kimin çağırdığı ve çevresindeki kadro.
• Mod bloğu — modun yetenek profilinden ve somutlaşmış araç listesinden üretilir, böylece bir istem çalıştırmanın gerçekte sahip olmadığı bir aracı asla adlandıramaz.
• Bellek bağlamı — görev için getirilen olgular.
• Konuşma bağlamı — son alan geçmişi; ajanın yapılandırılmış bağlam boyutundan bağımsız olarak birebir pencere 50.000 karakterle sınırlanır. Daha eski geçmiş atılıp yok edilmez: ajan onu get_messages ile talep üzerine getirir ve anlamsal olarak ilgili eski mesajlar yine de ortaya çıkar.

Slash komutları ham kullanıcı metninden ayrıştırılır

Katmanlı istem bir bağlam bloğuyla başlar, bu yüzden eğik çizgiyle başlamaz. Komutlar kullanıcının mesajından birebir ayrıştırılır ve ardından katmanlı istemin kuyruğundan çıkarılır; böylece her bağlam katmanı korunur.

Komutlar iki yere dağılmıştır. /todo ve /compact yazı alanında yakalanır ve kasıtlı olarak hiçbir zaman mesaj olarak kalıcılaştırılmaz ya da ajana gönderilmez — /compact kalıcılaştırılsaydı sıkıştırma kesimini bir tur geriye iter ve transkripti kirletirdi. /plan her ikisinde de ele alınır: yazı alanı alanın modunu değiştirir; araç yüzeyinin, koruma ön ayarının ve istemin bu turda ve sonraki her turda uyuşmasını sağlayan şey budur. /goal, /loop ve /skill:<name> ise çalıştırmanın kendi içinde ve yalnızca yerleşik harness üzerinde ele alınır — /goal ve /loop bir maliyet bütçesiyle özerk iş başlatır ve skill: önekli bir ad, SKILL.md gövdesi turun yönergesi hâline gelen bir beceri olarak aranır. İki sözlüğü ayrı tutan şey ad alanıdır: çıplak bir adı becerilere göre çözmek, plan veya compact adlı bir becerinin yerleşik komut tarafından kalıcı olarak gölgelenmesi anlamına geliyordu. Yerleşik olmayan çıplak bir ad, ad alanı var olmadan önce yazılmış mesajlar için yine de çözülür. Tanınmayan bir ad ise düz metin olarak geçip gider.

Çalışma ağacı hazırlığı

Herhangi bir şey çalışmadan önce konuşma kendi çalışma kökünü alır; altında her depo için yalıtılmış, kopyala-üzerine-yaz bir çalışma ağacı bulunur. Varsayılan olarak bu, çalışma alanına bağlı her depodur; bir PR alanı — ya da açık bir seçimle oluşturulmuş bir alan — yalnızca izin listesindekileri hazırlar ve bir PR inceleme konuşması tek deposunu pull request’in head ref’ine sabitlerken diğerleri varsayılan dallarında kalır. Kaynak checkout asla değiştirilmez ve alan silindiğinde konuşma dizininin tamamı geri alınır.

rift’in geldiği her yerde tek uygulama kopyala-üzerine-yazdır ve paketle gelen yerel ikiliyle desteklenir. Reflink yapamayan bir dosya sistemi — ya da depodan farklı bir birimdeki veri dizini — geri düşmek yerine hazırlığı başarısız kılar. git worktree, kopyala-üzerine-yaz arka ucunun derlenemediği Windows’ta kullanılan arka uçtur ve diğer ana makinelerde sessiz bir gerileme değildir. rift’in geldiği bir platformda rift’in eksik olması bozuk bir kurulumdur — sunucu sessizce geri düşmek yerine önyüklemeyi reddeder, çünkü sessiz bir geri düşüş bozukluğu sonsuza dek daha yavaş bir yolun arkasında saklar.

Kimlik ve kimlik bilgileri

Her çalıştırmada, herhangi bir süreç başlatılmadan önce iki kimlik çözülür.

Git yazarlığı. Bir ajanın yaptığı commit’ler ajan olarak yazılır — hem GIT_AUTHOR_* hem de GIT_COMMITTER_* içinde <Name> (agent) <agentId@agents.control-center.local> — ve asla bir insan taklit edilmez. Yerel kısım ajanın UUID’sidir, ad slug’ı değil. İsteği yapan insan, ortamda taşınan ve sistem isteminde belirtilen bir Co-Authored-By: satırıyla anılır. Çağıranın açıkça belirlediği bir kimlik her ikisini de her zaman yener.

Forge kimliği. Çalıştırmanın GitHub kimlik bilgisi her zaman yalnızca aracının olur — depo kapsamlı bir App kurulum belirteci ya da bunun ortam PAT yedeği — ve asla isteği yapan üyenin kendi sakladığı belirteç olmaz. actingUserId PAT yedeğini sınırlar; böylece sunucu sahibi olmayan bir üye sunucunun erişim alanını devralmaz. Ajan ortamına kişisel bir belirteç katmanlanmaz.

Model sağlayıcısı kimlik bilgileri sabit bir sırayla çözülür ve sıra önemlidir:

1. adaptör başına bir ortam geçersiz kılması,
2. çağıranın ortamı,
3. sunucunun kimlik bilgisi deposu (bir OAuth belirtecinin süresi dolmak üzereyse yenilenir),
4. süreç ortamı.

Adaptör başına geçersiz kılma ilk sırada geldiği için uygulamada bağlı bir sağlayıcı hesabını sessizce yener. Bir çalıştırma yanlış hesaba faturalandırılıyorsa ilk bakılacak yer bu geçersiz kılmadır. Sağlayıcı kimlik bilgileri ana makine genelindedir — kurulumdaki her çalışma alanı arasında paylaşılır.

Çalıştırmanın GitHub belirteci kimlik bilgisi aracısından gelir: çalışma ağacının deposuyla sınırlı, salt okunur bir belirteç. Bir push, iletmeden önce Uzak depoya push et kuralına soran ajan çalıştırma ağ geçidinden geçer ve hiçbir biletleme anahtarı enjekte edilmez. Bkz. Sandbox ve güvenlik.

Başlatma

Çalıştırma, çalışma dizini olarak kendi çalışma ağacıyla ve — Claude Code için — ajanın Control Center’ın araç yüzeyine erişebilmesi amacıyla üretilen bir MCP yapılandırmasıyla başlatılır. ACP ve harness bash arındırılmış bir ortam alır; NoSandboxAdapter üzerinden çalışan Claude Code ise ana makinenin ortamını devralır.

İşletim sistemi sandbox’ı bir çalıştırmayı yalnızca ana makinede arka uç olduğunda sarar

cc_server ana makineyi açılışta bir kez yoklar ve bir arka uç varsa ajan süreçlerini onun içine sarar — macOS’ta Seatbelt, Linux ve WSL2’de bubblewrap. Her iki gönderim dikişi de sarılır, çünkü tek bir tanesini paylaşmazlar: Claude Code CLI sandbox portundan geçer; ACP adaptörleri ve yerleşik harness’ın bash aracı sandbox yöneticisinden geçer. Çalıştırmanın korumalı yollarını uygulayan da budur: kayıtlı depo checkout’larınız sandbox içinde her modda yazmaya kapalıdır.

Arka uç olmadığında çalıştırma sandbox içinde değildir ve bunu telafi etmek için başka hiçbir şey değişmez. Bu, Windows’ta her zaman böyledir (yerel sarma yok — microvm, terminaller ve rig’ler için ayrı, yoklamayla kapılanmış bir yoldur) ve PATH üzerinde bwrap ile socat bulunmayan Linux veya WSL2’de de böyledir. Sunucu hangi durumda olduğunu başlangıç günlük satırında belirtir ve --sandbox off bilinçli bir çıkıştır.

Sandbox açık olsa bile iki boşluk ondan sağ çıkar. Harness’ın süreç içi dosya araçları (read, write, edit, apply patch, search, find, search_files) sunucu süreci içinde çalışır, bu yüzden onları hiçbir profil kısıtlamaz — sınırları, araçların kendi yol hapsinin ve korumaların toplamıdır. Ayrıca Claude Code --dangerously-skip-permissions ile başlatılır, yani kendi dosya çağrıları Control Center tarafından kapılanmaz, kabuk komutlarını ise yalnızca komut satırını okuyan bir hook denetler; onların etrafındaki sınır işletim sistemi sandbox’ıdır.

Geri kalan sınırlar her ana makinede geçerlidir, sandbox olsun olmasın: çalıştırmanın kendi çalışma ağacı (rift’in geldiği yerde kopyala-üzerine-yaz; Windows’ta git worktree), her başlatmada aracılık edilen ve kapatmada iptal edilen salt okunur bir forge belirteci, ajan çalıştırma ağ geçidinde push kuralından geçmesi gereken push’lar, birleşik eylem korumaları (başarısız durumda kapalı — onaylayıcı bağlı değilken prompt kararı reddedilir) ve konuşmanın modunun izin verdiği araç yüzeyi. ACP ve harness bash ortamı hâlâ arındırır; NoSandboxAdapter üzerinden Claude Code ana makinenin ortamını devralır.

Akış

Çalıştırma, tipli bir olay dizisini geri akıtır; akış işlemcisi bunları mesaj farkları olarak kalıcılaştırır, transkript segmentlerine katlar ve mesajlaşma olaylarına dönüştürür:

Olay	Taşıdığı bilgi
thinking	Satır içi gösterilen akıl yürütme çıktısı
text	Görünür çıktı
toolCall	Bir araç çağrısı; ID’si ve yapılandırılmış bağımsız değişkenleriyle
toolResult	Eşleşen sonuç; hata verdiğinde veya kısmi bir akış olduğunda işaretlenir
usage	Bir ölçüm penceresi için token sayıları ve maliyet
error	Bir hata; adaptör yapılandırılmış bir kod bildirdiyse o kodla birlikte
sandboxViolation	İşletim sistemi bir sistem çağrısını reddetti. Yalnızca bir sandbox süreci gerçekten sarıyorsa yayılır — yukarıdaki nota bakın
debug	Çalışma zamanı tanılamaları (başlatma işaretleri, koruma kararları, sözleşme dürtmeleri)
done	Çalıştırma bitti

Bir çalıştırmayı ne sınırlar

Kasıtlı olarak hiçbir yerde tur tavanı yoktur. Katı bir yineleme sayısı meşru uzun işleri (geçişler, yayılım temizliği) öldürür ve aşağıdaki korumaların daha erken yakaladığı hiçbir şeyi yakalamaz. Bir çalıştırma şu durumlarda biter:

• model kendi kendine durduğunda;
• bir insan onu durdurduğunda ya da konuşmayı devraldığında (bu, yerleşik harness’ı bir sonraki temiz tur sınırında duraklatır — güvenli sınırı olmayan bir Claude Code çalıştırması ise bunun yerine durdurulur);
• sessizlik gözcüsü tetiklendiğinde. Eşik boyunca çıktı olmazsa oturum bir silentRun hatasıyla sonlandırılır. Varsayılan 15 dakikadır ve ağırlıklı olarak okuma yapılan modlarda (inceleme ve plan) 10’a düşer; bir ajan bunu 1 ile 240 dakika arasında geçersiz kılabilir. Gözcü, bir alt süreç PID’sini bildirdiğinde kurulur, böylece Claude Code CLI’yı kapsar — hiçbir şey başlatmayan yerleşik harness’ı kapsamaz;
• bir maliyet sınırı devreye girdiğinde — ama yalnızca özerk komutlar için.

Kısır döngü koruması bir sonlandırıcı değildir: arka arkaya üç özdeş araç çağrısı olduğunda döngü ajanı yaklaşımını değiştirmeye yönlendirir.

Normal bir turun maliyet sınırı yoktur

Oturum içi maliyet koruması yalnızca /goal ve /loop için bağlanmıştır; diğer her çalıştırma hiçbir bütçe geçirmez. Bu komutlarda, gözetimsiz tek bir segment varsayılan olarak 500 sent ($5.00) yakabilir; %80’de ajanı katı duruştan önce işi temiz biçimde toparlamaya çağıran yumuşak bir yönlendirme ve segmentler boyunca kalıcı 5000 sent ($50.00) hedef bütçesi vardır. Açıkça verilen bir /goal --budget hiçbir zaman bir segmentin tamamı kadar aşılmaz.

Bir araya getirildiğinde, yerleşik harness üzerindeki sıradan etkileşimli bir turun tur tavanı, maliyet sınırı ve sessizlik gözcüsü yoktur. Model durduğunda ya da siz durdurduğunuzda biter. Bu bilinçli bir tercihtir — alternatiflerin hepsi meşru uzun işleri öldürür — ama gözetimsiz etkileşimli bir çalıştırmanın modelin kendi muhakemesinden başka hiçbir şeyle sınırlanmadığı anlamına da gelir.

Çalıştırma sırasında, çalışan bir ajana gönderilen mesaj yönlendirme olarak kuyruğa alınır ve bir sonraki tur sınırında boşaltılır; böylece bir çalıştırmayı öldürmeden dürtükleyebilirsiniz. Yönlendirme, duraklatma, alt ajanlar ve tamamlama sözleşmesi yerleşik harness’ın özellikleridir; Claude Code’da bunların hiçbiri yoktur.

Çalıştırma nasıl kaydedilir

Her gönderim bir AgentRunLog yazar: başlangıç ve bitiş zamanı, özet, token sayıları ve tahmini maliyet (alt ajanlardan toplanan maliyet dâhil), adaptör ve model, süreç ID’si ve günlük yolu, konuşma ile ait olduğu bilet veya pipeline çalıştırması; ayrıca gerçeğin çoğunu taşıyan iki sınıflandırma alanı.

• Durum kabadır: pending, running, completed, error.
• Canlılık daha ince okumadır: alive, productive, completed, blocked, empty, looping, failed, stalled, dead.
• Hata ailesi hataları işe yarar biçimde gruplar: transientUpstream, sandboxInfrastructure, budgetExceeded, processLost, silentRun, unknown.

completed “teslim edildi” anlamına gelmez

Bir çalıştırma, modunun gerektirdiği teslimatı üretmeden bittiğinde — submit_plan’i hiç çağırmayan bir plan modu çalıştırması, hiç öneri sunmayan bir orkestrasyon çalıştırması — durum completed kalır, çünkü süreç temiz biçimde sonlanmıştır. Dürüst sinyal canlılığa (empty), hata ailesine (silentRun) ve tam olarak neyin üretilmediğini söyleyen bir özete biner. Bu özet korunur: sonlandırma onu modelin son gevezeliğiyle üzerine yazmaz.

Bu bilinçlidir. Durumu ters çevirmek, eksik çıktıyla hiç ilgisi olmayan bilet ve pipeline durum makinelerini hareket ettirirdi. Ayrıca “status: completed” ifadesi tek başına bir çalıştırmanın başarılı olduğu sonucuna varmak için asla yeterli değildir — özeti okuyun.

Çalıştırmayı kapatmak AgentRunCompleted olayını yayımlar ve ona çok şey bağlıdır: pipeline maliyet toplaması, çalıştırmayı bekleyen bir pipeline adımının sürdürülmesi, arkasındaki bileti tamamlama, bir orkestrasyonu son duruma eşleme, hedef gözetmeninin devam et ya da dur kararı, denetleyici rolü ve çalıştırma sonrası bütçe değerlendirmesi. Varlık listesi ise olayı değil, son çalıştırma günlüklerini izleyerek ayrıca güncellenir. “Ajan tamamlandı” bildirimi bu listede yer almaz: olay, süreç akışı sona erdiğinde, yanıt yazılmadan önce tetiklenir; bu yüzden bildirim, mesaj kalıcı olarak kaydedildikten sonra yayımlanan turun MessageReceived olayıdır.

Bütçeler, iş bittikten sonra

Bütçe uygulaması bir tepkidir, bir kapı değil. Bir çalıştırma tamamlandığında değerlendirici, ajanın ay başından bugüne harcamasını etkin üst sınırıyla karşılaştırır (varsa bağlı bir bütçe politikası, yoksa ajanın kendi aylık rakamı; sıfır sınırsız demektir). Yumuşak eşiğin aşılması bir uyarı olayı kaydeder; bütçenin tükenmesi katı bir olay kaydeder ve ajanın yaşam döngüsü durumunu organizasyon şemasında paused olarak değiştirir. Gönderim o ajandan hâlâ iş kabul eder. Bir BudgetThresholdCrossed pipeline tetikleyicisi aynı olaydan takip işi başlatabilir.

Yeniden deneme soyu

Her çalıştırma günlüğü yeniden deneme soyu taşıyabilir — bir üst çalıştırma ID’si, bir deneme sayacı ve bir devam özeti. Konuşma çalıştırma ağacı, deneme numarasını sıfırdan farklı olduğunda gösterir. Sohbetten bir “yeniden dene” isteği, yepyeni bir çalıştırma günlüğüyle yeni bir gönderimdir.

İlgili kavramlar

• Ajan modeli: adaptörün neleri uygulayıp neleri uygulayamadığı
• Modlar: araç yüzeyinin ve tamamlama sözleşmesinin nereden geldiği
• Korumalar: kapılanan her çağrının geçtiği etki sınıfı politikası
• Sandbox ve güvenlik: yalıtım hikâyesinin tamamı
• Çok oyunculu: yönlendirme, devralma ve özerklik kadranı
• Alan olayları: AgentRunCompleted olayının tetikledikleri