Ajan modeli

Ajan nedir?

Bir ajan; bir persona, bir beceri kümesi ve üzerinde çalışacağı bir adaptöre sahip adlandırılmış bir aktördür. Ajanlar da insanlarla aynı anlamda Principal’dir: mesaj yazar, bilet sahibi olur, inceleme bırakır ve aynı kadroda görünür. İşi yapan şey onlardır.

Her ajan tam olarak bir çalışma alanına aittir. Bu katı bir değişmezdir — agent.workspaceId boş olamaz, ajanın satırlarının düştüğü veritabanı dosyasını ajanın kendi çalışma alanı seçer ve çalışma alanı olmayan bir ajan oluşturmak reddedilir.

Bir ajan aynı zamanda bir dizindir. Tanımı, çalışma alanının veri dizini altındaki agents/<slug>/AGENTS.md dosyasında yaşar ve sahip olduğu beceriler agents/<slug>/.agents/skills içine sembolik bağlanır. Veritabanı satırı ile dosya birlikte yazılır. Tohumlama idempotenttir: ajan satırı zaten varsa, diskteki dosyalar ve beceri bağlantıları yine de yeniden yazılır. Üretimdeki çağıran, her sunucu başlatması değil, çalışma alanı oluşturmadır.

Ajanın taşıdıkları

Öznitelik	Ne yapar
`name`	Kısa, slug benzeri tanımlayıcı (`architect`, `qa`). `@mentions` da buna göre çözümlenir
`title`	İnsan tarafından okunabilir görev unvanı
`persona`	Serbest metin kişilik ve davranış talimatları; isteme bir bölüm olarak enjekte edilir
`systemPrompt`	İsteğe bağlı ek talimatlar; bir “Agent instructions” bölümü olarak enjekte edilir — bir araya getirilen istemin geri kalanının yerini almazlar
`skills`	Büyük/küçük harf duyarsız beceri adları kümesi; diskte beceri bağlantıları olarak yansıtılır
`adapterId`	Ajanın hangi runner’a gönderim yaptığı. Null olması yerleşik döngüye geri düşer
`modelId`	O adaptör içindeki model
`effort`	Seçilen modelin kendi sözcük dağarcığından alınan akıl yürütme düzeyi
`contextSize`	Bağlam penceresi geçersiz kılması
`silenceTimeoutMinutes`	Sessizlik gözcüsü için ajan başına geçersiz kılma (1–240)
`reportsTo`	Üst ajan kimliği — organizasyon şemasının çizdiği bağlılık zinciri

Bunların tümünü Ayarlar → Çalışma alanı → Ajanlar altından düzenlersiniz. Yeni ajan, ardından doldurduğunuz adsız bir ajan oluşturur.

Beceriler

Beceriler, ajan varlığı üzerindeki büyük/küçük harf duyarsız adlardır. Onlarla iki ayrı şey olur:

Adlar, bir araya getirilen istemde bir “Skills” başlığı altında listelenir. Varlığın kümesinin tek başına yaptığı budur — ona bağlı, beceri başına bir istem kütüphanesi yoktur.
Adı geçen her becerinin dizini (çalışma alanındaki skills/<slug>/SKILL.md) ajanın kendi klasörüne bağlanır. Yerleşik harness üzerinde, bağlı becerilerin frontmatter’ı sistem istemine otomatik yüklenir ve ajan gövdeyi istediğinde okur; bir konuşmada /skill:<name> yazmak, o gövdeyi tur için bir direktif olarak yükler.

Dışarıdan alınan beceriler, alma ile yazma arasında hataya kapalı bir tedarik zinciri taramasından geçer — hiçbir beceri içeriği bir karar olmadan diske ya da bir isteme ulaşmaz. Dışarısı, kendinizin beceri kaynağı olarak kaydettiği GitHub depolarıdır: özenle seçilmiş bir mağaza yoktur, bu yüzden deponun kendi üst verisi (açıklaması, yıldızları, becerinin adı) güvenilmez görüntüleme verisidir ve tek güvenlik sinyali tarama kararıdır. Bir kurulum, becerinin tüm dizinini alır, skills-lock.json içinde geldiği commit’e sabitler ve sonraki bir güncelleme herhangi bir şeyi değiştirmeden önce kapıdan yeniden geçer. Nasıl yapılacağı becerileri kurma ve yönetme sayfasındadır.

Depoya özel beceriler

Bir depo, kendi becerilerini alışılmış yerlerin herhangi birinde (.agents/skills/, .claude/skills/, .opencode/skills/) getirebilir. Bir alan, bağlı her depoyu repos/<name>/ altında yan yana checkout eder, ancak bir ajan aynı anda tek bir depoda çalışır — bu yüzden yalnızca o deponun becerilerini taşır ve depo değiştiğinde bunlar da değişir.

Hangi deponun etkin olduğu, ajanın dokunduğu dosyalardan çıkarılır: repos/<name>/ altında bir dosya yazmak o depoyu etkin yapar, oysa depolar arasında yalnızca okuma yapmak yapmaz; böylece bir sembolü kardeş bir servise kadar izlemek, küme bir görevin altından hiçbir zaman değişmez. Tek depolu bir alanda yanıt ilk turdan önce bilinir.

Bu kapsamlandırma bir bağlam bütçesi kararıdır. Beceri dizini her turda istemde durur, gövdeler durmaz; bu yüzden her deponun becerilerini birden listelemek sürekli token harcar — ve iş başka bir serviste olduğunda bir servisin testing becerisi aktif olarak yanıltır. Aynı gerekçe, bir ajanın dizininin tek bir depo taşımasının ama yazı alanının bu şekilde kapsamlandırılmamasının nedenidir: bir beceriyi kendiniz adlandırmak tek bir açık eylemdir, bu yüzden /skill:<repo>:<name> alandaki her depoya ulaşır.

Depo becerileri yalnızca yerleşik harness için değil, her adaptör için yüklenir. Etkin deponun becerileri ajanın çalışma dizinine — Claude Code’un zaten taradığı yola — somutlaştırılır; aynı dizin, yerleşik harness’ın okuduğu AGENTS.md içine de işlenir. Bir deponun becerileri, tüm bunlar olmadan önce kurulu bir becerinin geçtiği hataya kapalı taramadan geçer — checkout edilmiş bir depo klonlanmış içeriktir ve frontmatter’ı bir isteme ulaşır.

İzinler

Bir ajanın kendine ait izin bayrakları yoktur. Commit oluşturup oluşturamayacağına, push edip edemeyeceğine, pull request açıp açamayacağına, bir takip sistemine yazıp yazamayacağına ya da ağa erişip erişemeyeceğine eylem korumaları karar verir — çalışma alanı, ajan veya alan kapsamında izin ver, önce sor ya da reddet — ve onu hangi adaptör çalıştırırsa çalıştırsın aynı kurallar geçerlidir.

Bir çalıştırmaya neyin verildiği bu kurallarla değişmez. Bir GitHub çalışma ağacındaki çalıştırma her zaman salt okunur bir GitHub belirteci alır ve bir push, gerçekleştiği anda sorulur: ajanın git yapılandırması her GitHub push’unu Control Center üzerinden gönderir; Control Center da onu iletmeden önce Uzak depoya push et kuralını uygular.

Bunun nasıl işlediği, dosya sistemi düzeyinde neyin uygulandığı ve neyin uygulanmadığı dâhil, Sandbox ve güvenlik sayfasındadır.

Neyin uygulanabileceğine adaptör karar verir

Bir ajan üzerindeki en sonuç doğuran tek alan adaptörüdür, çünkü adaptörün taşıma katmanı, Control Center’ın politikasının ne kadarının gerçekten uygulanabilir olduğunu belirler.

Taşıma katmanı	Adaptörler	Control Center’ın uyguladıkları
Yerleşik harness	Control Center (built-in)	Her şey. Araç yüzeyi moddan inşa edilir, bu yüzden izin verilmeyen bir araç yalnızca reddedilmekle kalmaz, görünmez olur; her çağrı onay kapısından ve eylem korumalarından geçer; tamamlama sözleşmesi dürtükleyebilir ve ardından teslimatı olmadan biten bir çalıştırmayı başarısız kılabilir
Claude CLI	Claude Code	Kendisine sunulan `mcp__*` araçları ve bir hook’un çalışmadan önce eylem politikasına gönderdiği `Bash` komutları. Claude’un kendi okuma, yazma ve düzenleme araçları kendi sürecinde yaşar ve görünmeden çalışır — ve `--dangerously-skip-permissions` ile başlatılır, çünkü etkileşimsiz `claude -p` aksi hâlde kendi isteminde sonsuza dek takılır

Somut olarak, alt ajanları, çalıştırma ortasında yönlendirmeyi, duraklatma ve sürdürmeyi (ve dolayısıyla devralmayı) ve yapısal mod uygulamasını yalnızca yerleşik harness destekler. Claude Code bunların hiçbirini almaz.

Yukarıdaki matris, Control Center’ın neleri görüp kapıdan geçirebildiğiyle ilgilidir. Onun altında, cc_server, Claude Code CLI’yi var olduğu yerde ana makinenin işletim sistemi sandbox’ına sarar — macOS’ta Seatbelt, Linux ve WSL2’de bubblewrap — böylece görülmeyen bir rm ya da görülmeyen bir yazma yine de işletim sistemi tarafından sınırlanır. Windows’ta hiçbir arka uç yoktur ve bwrap ile socat olmayan Linux veya WSL2’de sonda hiçbir şey bildirmez; bu yüzden oralarda bu çalıştırmalar ortam arındırmaya, aracılı kimlik bilgilerine, Control Center’ın görebildiği çağrılardaki korumalara ve konuşmanın kendi worktree’sine geri düşer (rift’in geldiği yerde copy-on-write; Windows’ta git worktree).

Sandbox bir kapı değildir. Bir sürecin nerede okuyabileceğini, yazabileceğini ve bağlanabileceğini sınırlar — salt okunur bir mod ona ulaşır, salt okunur bağlama noktaları olarak — ama bir çağrıyı kesemez, bir onay isteği çıkaramaz ya da sonrasında CLI’nin ne denediğini söyleyemez. Bu ve hemen yukarıda adı geçen dört yetenek, hâlâ yerleşik harness’ın sahip olup diğerlerinin olmadığı şeydir. Bkz. Sandbox ve güvenlik.

Adaptörü olmayan bir ajan Control Center (built-in) seçeneğine geri düşer — sunucunun içindeki döngü, yani kurulacak bir CLI yoktur — ve çalıştırma günlüğü cc-harness kaydeder. Tohumlanan her ajan adaptörsüz ve modelsiz oluşturulur; bu yüzden yeni bir çalışma alanının beş ajanı da, siz ajan başına bir adaptör ve model belirleyene kadar orada, Anthropic’in varsayılan modeli üzerinde çalışır. İlk kurulumdaki “varsayılan adaptör” seçimi, sunucunun hiç okumadığı bir istemci tarafı tercihtir ve hâlihazırda oluşturulmuş ajanlara geriye dönük uygulanmaz.

Ajanlar nereden gelir

Çalışma alanıyla birlikte tohumlanır. Her çalışma alanı — yalnızca ilki değil — kendisine bağlı bir CEO ile dört uzman (qa, architect, engineer, librarian) alır; bunlar çalışma alanı oluşturulurken arka planda idempotent biçimde oluşturulur. Bkz. Çalışma alanları ve yalıtım.
Elle eklenir Ayarlar → Çalışma alanı → Ajanlar altından. Bir ajandan iş arkadaşı işe almasını istemek bir satır oluşturmaz; o ekranı kullanın.

Canlı durum

Bir ajanın saklanan bir durum sütunu yoktur. Canlı durumu, her okunduğunda en son çalıştırma günlüklerinden türetilir:

Durum	Anlamı
`neverRun`	Hiç çalıştırma günlüğü yoktur
`running`	En az bir çalıştırma şu anda sürüyor
`failed`	En son çalıştırma hata verdi ya da canlılığı başarısız veya ölü
`blocked`	En son çalıştırmanın canlılığı engellendi, durakladı veya döngüde
`idle`	Diğer her şey — ajan daha önce çalıştı ve uçuşta hiçbir şeyi yok

İki durum daha, queued ve succeeded, konuşma çalıştırma ağacındaki tek tek çalıştırmalar için vardır; kadro bunları hiç üretmez, çünkü bitmiş bir çalıştırmanın yeşil olması çalıştırmayla ilgili bir olgudur, ajanla değil.

Varlık listesi, canlı çalıştırma olaylarından sunucu tarafında sentezlenen paralel ve daha kaba bir tablo gösterir — düşünüyor, çalışıyor, onay için engellendi, bitti — ajanların insanların yanında görünmesini sağlayan da budur. Bkz. Çok oyunculu ve varlık.

İlgili kavramlar

Ajan gönderim yaşam döngüsü: bir ajan gerçekten çalıştırıldığında ne olur
Modlar: bir ajanın araç yüzeyini şekillendiren konuşma başına ayar
Çok oyunculu ve varlık: ajanların Principal oluşu, varlık ve otonomi kadranı
Sandbox ve güvenlik: bugün bir çalıştırmayı neyin sınırladığı
Ajan yapılandırması: tam alan listesi