Bu hafta bir config snippet'i dolaşıyor: Codex config.toml dosyanıza agents.max_concurrent_threads_per_session = 64 ekleyin ve tek bir oturumun düzinelerce alt ajana yayıldığını izleyin. Bunu başlatan paylaşım, varsayılan değerin 3 olduğunu ve OpenAI'ın 64'ü test ettiğini iddia ediyor. Ayar gerçek. İki sayı ise dokümantasyonda yok ve ilginç olan kısım aslında üst sınır değil. İlginç olan, bu sınırı yükselttiğinizde işin başına gelenler.
Bu yazı, Codex referansına göre ayarın gerçekte ne yaptığını ve tek bir oturum bir kişinin okuyabileceğinden fazla ajan çalıştırmaya başladığında sırasıyla bozulan üç şeyi ele alıyor.
Özet
agents.max_concurrent_threads_per_session, Codex'in aynı anda açık tuttuğu başlatılmış ajan thread'lerinin sayısını sınırlar; birincil thread bu sayıya dahil değildir. Referans bir varsayılan yayınlamıyor; anahtar ayarlanmadığında Codex'in bir varsayılan seçtiğini söylüyor. Alt ajanlar sonuç özetlerini ana thread'e döndürür, ana thread hepsini bekler ve tek seferde yanıt verir; dokümanlar alt ajanları okuma yoğun işler için önerirken paralel yazma yoğun iş akışlarının çakışmalara ve koordinasyon yüküne yol açtığı konusunda uyarıyor. Üst sınırı 64'e çıkarmak tam da bu iki noktayı zorluyor: paylaşılan dosyalar ve kimsenin denetleyemediği tek bir birleştirilmiş yanıt. Sharkly, Codex'i bir Runtime olarak çalıştırır ve paralelliği bir üst seviyeye taşır; burada her çalıştırma kendi worktree'sine, kendi loguna ve kendi gözden geçiricisine sahip bir Task'tır.
Ayarın yaptığı şey
config.toml dosyasının [agents] bölümündeki üç anahtar burada önemlidir. Aşağıdaki ifadeler yapılandırma referansından alınmıştır.
| Anahtar | Referansın söylediği |
|---|---|
agents.max_concurrent_threads_per_session |
"Aynı anda açık olabilecek başlatılmış ajan thread'lerinin maksimum sayısı; birincil thread hariç. Ayarlanmadığında Codex varsayılanı seçer." |
agents.max_threads |
"agents.max_concurrent_threads_per_session için eski takma ad." |
agents.enabled |
"Çok ajanlı araçları etkinleştirin veya devre dışı bırakın (varsayılan: true)." |
İlgili iki anahtar olan agents.default_subagent_model ve agents.default_subagent_reasoning_effort, bir başlatma çağrısı aksini belirtmediği sürece başlatılmış ajanların ne üzerinde çalışacağını belirler.
Yani snippet yazıldığı gibi çalışır:
[agents]
max_concurrent_threads_per_session = 64
Referansın söylemediği şey, varsayılanın ne olduğu ya da herhangi bir değerin test edilip edilmediğidir. "Varsayılan 3" ve "OpenAI 64'ü test etti" ifadelerini, dokümanlar aksini söyleyene kadar bir paylaşımdan gelen iddialar olarak değerlendirin, satıcıdan gelen bilgiler olarak değil.
Alt ajanlar kılavuzu, üst sınırı yükseltmenin iyi bir fikir olup olmadığını belirleyen iki cümleyi ekliyor. Sonuçlar hakkında: "Birçok ajan çalışırken Codex, istenen tüm sonuçlar hazır olana kadar bekler ve ardından birleştirilmiş bir yanıt döndürür." Uygunluk hakkında: alt ajanlar "keşif, testler, triyaj ve özetleme gibi okuma yoğun görevler" için uygundur ve kılavuz "paralel yazma yoğun iş akışlarında dikkatli olunmasını, çünkü ajanların aynı anda kod düzenlemesinin çakışmalara yol açabileceğini ve koordinasyon yükünü artırabileceğini" tavsiye eder.
Bunları birlikte okuduğunuzda başarısızlık sırası kendiliğinden ortaya çıkar.
İlk bozulan: paylaşılan çalışma dizini
Bir oturumdaki alt ajanlar, aksini ayarlamadığınız sürece oturumun çalışma dizinini paylaşır. Altmış dört ajan okuma yapıyorsa bu sorun değil. Dört ajan yazma yapıyorsa bu bir birleştirme sorunudur.
Başarısızlık dramatik değil. İki alt ajan aynı dosyayı düzenler, ikinci yazma kazanır ve birleştirilmiş özet her iki görevi de tamamlandı olarak bildirir. Bunu ya inceleme sırasında fark edersiniz, tabii bir incelemeniz varsa, ya da üretimde fark edersiniz, tabii incelemeniz yoksa. Dokümanların çakışmalar ve koordinasyon yükü konusundaki uyarısı tam da bunu anlatıyor.
Çözüm, her paralel ajan kurulumunun yakınsadığı çözümdür: her iş birimi için bir çalışma kopyası. Sharkly'de her Task çalıştırması izole bir dizin alır ve depo tabanlı işler her çalıştırma için ayrı bir git worktree kullanır; bu mekanizma izole worktree'lerde paralel ajanlar yazısında ele alınmıştır. Tek bir depoya karşı on Task, sıfır paylaşılan durum. Düzenlemeyi yapan Runtime yine Codex olabilir; izolasyon onun etrafında sağlanır.
İkinci bozulan: birleştirilmiş yanıt
Codex her alt ajanı bekler ve tek bir yanıt döndürür. Dört alt ajanda bu bir kolaylıktır. Altmış dörtte ise bu, altmış dört iş parçasını özetleyen, onları gönderen ajan tarafından yazılmış ve ara çıktıları gizlenmiş tek bir mesajdır.
Bu, inceleme için yanlış bir biçim. Bir gözden geçiricinin her iş biriminin neye dokunduğunu, neyi çalıştırdığını ve nerede durduğunu bilmesi ve her birini tek başına kabul edebilmesi veya reddedebilmesi gerekir. Özetlerin özeti kısmen kabul edilemez.
Sharkly, Ajanın nihai yanıtını Task üzerinde saklar ve her çalıştırma için tetikleyici, başlangıç ve bitiş, araç çağrıları, Runtime olayları ve hata ayrıntılarını içeren bir yürütme logu tutar. Yürütmeler, yorum zaman çizelgesinden ayrı olarak kendi sekmesinde yer alır. Altmış dört iş birimi, altmış dört loglu altmış dört Task'tır; her biri incelenebilir, her biri sonucunu bir kişinin bakacağı yere döndürür.
Üçüncü bozulan: döngüdeki insan
Üst sınır, bir alt ajanın bir kişiye ihtiyaç duyduğunda ne olacağı hakkında hiçbir şey söylemez. Tek bir oturum içinde, bloke olmuş bir alt ajan, birleştirilmiş bir bekleyiş içinde sessizleşmiş bir thread'dir. Ana thread sizin adınıza yanıt veremez ve altmış dört thread'den hangisinin durduğunu göremezsiniz.
Sharkly, Task durumunu ve Ajan çalışma durumunu ayrı tutar: Başlatılmış bir Task Çalışıyor, İnsan yanıtı bekleniyor, İnsan incelemesi bekleniyor veya Hata gösterebilir. Bekleme ve başarısızlık sinyalleri, sorumlu kişi için Inbox'ın Birincil bölümüne düşer ve Task üzerindeki bir yanıt, thread'i bağlam olarak alarak takip çalıştırmasını başlatır. Takılan ajan size söyler, inceleyemeyeceğiniz bir bekleyişin içinde asılı kalmaz.
Alt ajanlar mı, Task'lar mı? Bir karar ikilisi
İş okuma yoğunsa ve tek bir yanıtta yakınsıyorsa tek bir oturum içinde Codex alt ajanlarını kullanın: bir kod tabanını keşfedin, bir grup hatayı triyaj edin, bir belge kümesini özetleyin, bir test paketi çalıştırın. Kılavuzun onları önerdiği şey budur ve hiçbir şey yazma yapmıyorsa daha yüksek bir üst sınır ucuzdur.
İş birimleri kod yazdığında, farklı kişiler farklı parçaları inceleyeceğinde ya da bir kişinin çalıştırma ortasında yanıt vermesi gerekebileceğinde, her biri bir Computer üzerindeki bir Ajana atanmış ayrı Task'lar kullanın. Sharkly, Codex'in yerini almaz; Codex, her Task'ı yürüten Runtime'dır. Fark, paralelliğin nerede yaşadığıdır: tek bir oturumun birleştirilmiş bekleyişinde mi, yoksa bağlamın, ilerlemenin, engellerin, sonuçların ve insan incelemesinin talepten sürüme kadar görünür kaldığı bir board üzerinde mi.
Üst sınırı güvenli şekilde yükseltmek
max_concurrent_threads_per_session değerini gerçekten yükseltecekseniz, bunu Sharkly'nin Computer'lar için kendi eşzamanlılık dokümanlarının tarif ettiği şekilde yapın: mevcut kurulum mevcut iş yükünü güvenilir şekilde idare etmeye başladıktan sonra artırın, çünkü daha yüksek eşzamanlılık daha fazla CPU, bellek, disk, sağlayıcı kapasitesi ve depo bant genişliği tüketir. Sharkly'de bir Computer'ın kendi görev eşzamanlılık sınırı vardır ve geçici dizin kullanan Ajanlar varsayılan olarak bunun yarısını kullanır. Kapasite Computer, Ajanın eşzamanlılığı ve dizin kullanılabilirliğiyle sınırlıdır ve çevrimiçi bir Ajan bu kapasite dolduğunda hâlâ kuyruğa alınmış işe sahip olabilir.
Sağlayıcı kapasitesi, insanların unuttuğu şeydir. Tek bir API anahtarına karşı altmış dört thread, aynı anda bir hız sınırına çarpmanın altmış dört yoludur ve "kota tükendi" anlamına gelen bir 429, yeniden denemeyle düzelmez. Sharkly'nin başarısız çalıştırma logu, sağlayıcının orijinal yanıtını sade bir başlığın yanında tutar, böylece fark kimse yeniden denemeden önce görünür olur.
Sık sorulan sorular
agents.max_concurrent_threads_per_session için varsayılan değer nedir? Yapılandırma referansı bir tane belirtmiyor. Anahtar ayarlanmadığında Codex'in varsayılanı seçtiğini söylüyor. Sosyal medyada dolaşan sayılar referanstan gelmiyor.
Üst sınırı yükseltmek Codex'i daha hızlı yapar mı? Okuma yoğun yayılım için daha fazla thread daha erken tamamlanır. Yazma yoğun işler için dokümanlar eşzamanlı düzenlemelerin çakışmalara ve koordinasyon yüküne yol açtığı konusunda uyarıyor; bu da paralelliğin kazandırdığından daha fazla zaman maliyetine yol açar.
Codex alt ajanları ayrı git worktree'lerinde mi çalışır? Alt ajanlar kılavuzu çalıştıklarını söylemiyor. İzolasyonu kendiniz kurmadıysanız çalışma dizinini paylaştıklarını varsayarak planlayın.
Sharkly, Codex'i nasıl kullanır? Bir Runtime olarak. Codex çalıştıran bir Computer onu kullanılabilir olarak bildirir ve o Computer üzerindeki bir Ajana atanmış Task'lar bunun üzerinden yürütülür; her çalıştırma kendi izole dizininde ya da worktree'sinde gerçekleşir.
Bir Sharkly Task'ı içinde hâlâ alt ajanları kullanabilir miyim? Evet. Runtime'ın kendi başına yapabildiği her şey çalıştırma içinde hâlâ çalışır. Sharkly bunun etrafına Task'ı, izolasyonu, logu ve incelemeyi ekler.
Kısa özet
Ayar gerçek ve snippet çalışıyor. Yapmadığı şey ise altmış dört eşzamanlı düzenlemeyi güvenli kılmak, tek bir birleştirilmiş yanıtı incelenebilir kılmak ya da hangi thread'in sizi beklediğini söylemek. Sırasıyla bozulan üç şey bunlar. Alt ajanları okuma yoğun yayılım için saklayın ve yazma yoğun paralel işleri her çalıştırmanın kendi worktree'sine ve kendi gözden geçiricisine sahip olduğu bir board'a taşıyın. Üzerinde Codex olan bir Computer bağlayın, bir Ajan oluşturun ve ona sıkıcı bir şey atayın. Dokümanlar her kavramı daha derinlemesine ele alıyor: docs.sharkly.ai.
