Orijinal Başlık: "Üç Eyalet Altı Kuruluşsanalı: Neden "Sanal Şirket" Tarzı Çoklu Ajan Yapısı Mühendislik Açısından Başarısız Olur"

AI Topluluğunda geniş çapta yayılan bir mimari düşünce yapısı, birçok ekibin yanlış yola girmesine neden oluyor.

Önce Sonuç

Eğer birden fazla AI Ajanını sırasıyla "Ürün Müdürü", "Mimar" ve "Test Mühendisi" olarak adlandırmayı ve onları belgel eri iletmesi, görevleri işbirliğiyle tamamlaması için firma departmanları gibi davranmasını düşünüyorsanız, lütfen durun.

Bu model, görünüşte sezgisel görünse de, mantık olarak oldukça mantıklı görünse de, mühendislik açısından temel bir eksikliğe sahiptir. Daha da önemlisi, Anthropic, OpenAI, Google gibi üç firma kendi Ajan sistemlerini oluştururken, hiçbiri bu modeli benimsemedi.

Bu bir tesadüf değil.

"Üç Eyalet Altı Kuruluş" Tarzı Mimarlık Nedir

Bu metafor, toplulukta yaygın olarak benimsenen çoklu Ajan tasarım düşünce yapısını ifade eder ve farklı çerçevelerde ve makalelerde farklı adlarla anılır: rol tabanlı ajanlar, sanal takım, CrewAI tarzı bölünmüş ekip, MetaGPT tarzı organizasyon — bu makalede hepsi "Üç Eyalet Altı Kuruluş" olarak adlandırılacaktır.

Temel model şudur: Karmaşık bir görevi birkaç işlev halinde parçalara ayırın, her Ajan bir rol üstlensin — PM gereksinimlerden sorumlu, Tech Lead mimariden sorumlu, Dev uygulamadan sorumlu, QA testten sorumlu. Görev, Ajanlar arasında dolaşır, bir montaj hattı gibi.

Bu model şekil olarak çok güzeldir. İnsanların "bölünmüş işbirliği"ne olan doğal eğilimlerini karşılarken, "AI takımı" kavramını somut ve açıklanabilir hale getirir. CrewAI gibi çerçeveler zaten bu nedenle birçok kullanıcı çekmiştir.

Sorun şu ki, bu, insanların engeline değil, AI'ın engeline çözüm getirir.

Bu Benzetmenin Temelden Neden Yanlış Olduğu

İnsanlar, bölünmüş işbirliğe ihtiyaç duyar, çünkü:

· Bireyin dikkati sınırlıdır, tüm bilgileri aynı anda işleyemez

· İnsanların uzmanlık engelleri vardır, geçiş maliyetleri yüksektir

· Bireyler arasında iş birliği için bir arayüze ihtiyaç duyar

Ancak, LLM'nin özellikleri tamamen farklıdır:

· Aynı model hem PRD yazabilir hem de kod yazabilir, "meslek sınırları" yoktur

· Modelin darboğazı dikkat genişliği değil, çıkarım derinliği ve bilgi bütünlüğü

· Modeller arasında bilgi kaybını telafi etmek için "kültür" ve "anlayış" yoktur

Ajana "ürün yöneticisi" etiketi yapıştırmak, onu daha profesyonel hale getirmez—ancak onu sınırlarını aşmaktan alıkoyar. "Test mühendisi" rolüne sıkışmış bir Ajan, mimari düzeyde bir sorun gördüğünde doğrudan atlayabilir çünkü "sorumluluk alanıma girmiyor". En değerli çıkarım genellikle sınırlarda gerçekleşir, ancak üç arşın altı taneme modeli bu olasılığı sistem düzeyinde kapatır.

Rol yapma yapay sınırlar oluşturur. Bu ilk sorundur.

İkinci Sorun: Bilgi Akışı Sırasında Bilgi Kaybı

Üç arşın altı taneme modelinde, Ajan A bir belge üretir ve Ajan B'ye iletir.

Bu süreç, sonuca değil, çıkarım sürecine dayanır.

B belgeyi alır, yeniden anlamlandırır, yeniden bağlam oluşturur. İlk niyet zayıflar, örtük varsayımlar kaybolur, her iletimde hata birikir. İş akışı ne kadar uzun olursa, nihai çıktı o kadar "yerinde doğru ancak bütünsel olarak kaymalı" hale gelir—her düğüm mantıklı görünse de, bütünün ilk hedefinden sapmış olur.

İnsan organizasyonları bu bilgi kaybını denemeler, kültür ve gayri resmi iletişim yoluyla telafi eder. Ajanlar arasında bu tür mekanizmalar yoktur.

İşte yaygın bir itiraz var: Üç tedarikçi tarafından sunulan çözüm (ilerleme.txt, spec dosyası, çalıştırma kılavuzu) aynı şekilde "dosya iletme" değil mi? Fark nerede?

Fark, kimin yazdığı, kime yazıldığı, nasıl güncellendiği'nde yatar.

Üç arşın altı taneme modelinde bilgi akışı, roller arasında tek yönlü bir devir içerir: A yazısı tamamlar ve B'ye teslim eder, B geri gitmez, A da B'nin belgeyi nasıl kullandığını bilmez. Bilgi sonuca sıkışmış, çıkarım süreci kaybolmuş, bayrak teslim noktası kırılmıştır.

Dış durum dosyası, aynı görev için artımlı günlük'tür: Yürütme ana gövdesi her bir kontrol noktasında aynı kayda eklemeyi sürdürür, sonraki oturum görevin tam geçmişini okur, önceki bir "meslektaşın" çıktısının sonucunu değil. Durumu yazan ve durumu okuyan aynı role sahiptir, sadece zaman farklıdır. Bilgi "sıkıştırılarak iletilen" değil, "sürekli birikim" iletilir.

Bu fark, çıkarım zincirinin oturumlar arasında sürekliliğini koruyup koruyamayacağını belirler.

Bir Agent ile "el değişim dosyası" arasında büyük miktarda jeton israf edilir, bu da gerçek çıkarsamada kullanılmak yerine. Aldığınız şey, bir şirket davranışını simüle eden bir sistem'dir, bir problem çözme sistemine değil.

Üç Şirketin Gerçekte Neler Yaptığı

Dikkat çekici olan, Anthropic, OpenAI, Google'ın kendi üretim seviyesi Agent sistemlerini inşa ettiğinde, mühendislik belgelerinde neredeyse hiç "rol yapma" veya "departman ayrımı" terimlerine rastlanmaz.

Anthropic: Bağlam Mühendisliği + Açık Durum Dosyası

Anthropic, "Bağlam Mühendisliği"'ni "Prompt Mühendisliği"e yükseltti: Sorun, bir prompt'ın nasıl iyi yazılacağı değil, en uygun davranışı üretebilecek hangi tür jeton yapılandırmasının olduğudur.

Claude Code ve Araştırma sistemlerini oluştururken, karşılaştıkları temel zorluk şuydu: Agent'ın ayrık oturumlarda çalışması gerekiyordu, her yeni oturum önceki olayları hatırlamaz. Onların kıyası "Vardiya Mühendisi" idi—her yeni vardiya mühendisi, önceki vardiyadaki işle ilgili hiçbir bilgiye sahip değildir.

Çözüm, Agent'ın farklı rolleri üstlenmesine izin vermek değil, aşağıdakilerdir:

· claude-progress.txt: Oturumlar arası bir iş günlüğü, Agent her oturum sonunda günceller, bir sonraki oturum başladığında okur

· Git geçmişi: Durum çengeli olarak, her artımlı değişikliği kaydeder

· Başlatıcı Ajan: Yalnızca ilk oturumda çalışır, ortamı kurar, özellik listesini genişletir, çalıştırılacak belgeyi hazırlar ve sonraki tüm oturumlar için kullanılır

Temel İnceleme: Çıkarsama zincirinin sürekliliği, modelin "hatırlamasına" değil, açık dışsal duruma dayanarak sağlanır.

Aynı zamanda, "model yetenekleri varsayımını" sıkıştırmak, Harness üzerinde tehlikeli olduğunu fark ettiler. Sonnet 4.5'in "bağlam anksiyetesi" vardı - bağlam sınırına hızla yaklaşıldığında önceden tamamlama yapardı, bu yüzden Harness'a bir bağlam sıfırlama eklendi.

Ancak Opus 4.5'te bu davranış kayboldu, sıfırlama sabit bir ağırlığa dönüştü. Bu, Harness'ın modelin gelişimine paralel olarak evrileceğini gösteriyor, herhangi bir "kalıcı çözüm" sadece mevcut aşama için bir mühendislik uzlaşmasıdır.

Çoklu Ajanlı Araştırma sistemlerinde, Anthropic'in mimarisi yönetici-çalışan'dır: bir baş ajan görevleri parçalar, alt ajancıları koordine eder, alt ajancılar farklı yönleri aynı anda keşfeder, sonuçlar baş ajanın bütünleşmesi için geri akar.

Seyahat harcaması miktarının kendisinin %80'ini açıkladığını keşfettiler - Çoklu Ajanın değeri "işbölümü" değil, daha büyük bir arama alanını kapsayan daha fazla token kullanımıdır.

Burada karıştırılabilecek bir nokta var: Anthropic'in alt ajancısı aynı zamanda "işbölümü" gibi görünüyor, ancak temel farklıdır. Three Lines of Defense işlevsel işbölümüdür - farklı roller farklı işleri üstlenir, PM yapar, Dev'e iletir, Dev yapar, QA'ya iletir, her rol yalnızca üretim hattının bir bölümünü işler.

Anthropic'in alt ajancısı işlevsel eşzamandır - aynı nitelikteki çoklu ajan farklı yönlere aynı anda arama yapar, "bir sonraki çubuğu" yoktur, sonuçlar hepsi tek bir yöneticiye geri döner. İlki bayrak yarışıdır, ikincisi aynı anda ağ atıp balık yakalamaktır.

OpenAI: Sıkıştırma + Yetenekler + Yapılandırılmış Spec Dosyası

OpenAI'nın uzun süreli görev ilkesi daha doğrudan: Görev başlangıcında süreklilik için planlama yapın.

Onların Codex deneyinde, mühendis, ajan için bir spec dosyası verdi (hedefi dondurarak, ajanın "etkileyici ancak yanlış yönlü bir şey yapmasını" önler), aşama bazlı plan üretmesini sağladı ve ardından ajanın nasıl çalışacağını anlatan bir runbook dosyası kullandı. Bu runbook aynı zamanda paylaşılan bellek ve denetim günlüğüdür.

Sonuç: GPT-5.3-Codex yaklaşık 25 saat boyunca kesintisiz çalışarak, tam bir tasarım aracı oluşturdu ve sürekliliği korudu.

Sunucu taraflı sıkıştırma, varsayılan ilkel olarak, acil durum yedeklemesi değildir. Çok adımlı görevlerde, previous_response_id, modelin aynı iş parçacığında çalışmaya devam etmesini sağlar, bağlamı her seferinde yeniden oluşturmadan.

Ayrıca Skills kavramını da tanıttılar - yeniden kullanılabilir, sürümlü talimat kümesi, konteynere bağlanır ve ajanın belirli bir görevi yerine getirirken kararlı işletme standartlarına sahip olmasını sağlar. Bu bir "rol" değil, araçlar ve işletme prosedürleridir, temelde farklı şeylerdir.

Google: 1M Bağlam + Bağlam Odaklı Geliştirme

Google'ın yaklaşımı, pencereyi genişletmektir: Gemini'nin 1M belirteç bağlamı açık bir farklılaştırma stratejisidir. Mantıkları şudur: Önceki RAG dilimleri, eski mesajları atma gibi zorunlu olarak kullandıkları teknikler, yeterince büyük bir pencerede "doğrudan içeriye yerleştirilebilir".

Ancak kendi de yetersiz olduğunu kabul etmektedir. Google, Gemini CLI'da Conductor genişlemesini tanıttı ve temel fikir ve Anthropic ile aynıdır: Projelerin niyetini sohbet penceresinden çıkarıp, kalıcılaştırılmış Markdown dosyalarına kod deposuna koymak. Felsefesi şudur: "Kararsız sohbet kayıtlarına bağlı olmamak, resmi spec ve plan dosyalarına bağlı olmak."

Gemini 3 ayrıca Düşünce İmzaları mekanizmasını tanıttı: Uzun oturumda akıl yürütme zincirinin kritik düğümlerini kaydederek, "akıl yürütme kayması" adı verilen uzun bağlamda mantıksal tutarsızlık sorununu önler.

Gerçek Mimarlık Prensipleri Nedir

Üç şirketin mühendislik uygulamalarından, birkaç ortak ilke çıkarılabilir:

Akıl yürütme zinciri kesilemez, yalnızca çatallanabilir ve sonra birleştirilebilir. Birden fazla Ajanın doğru kullanımı bir akış hattı değil, tam bir niyeti olan ana ajanın, alt çağrıların belirli bir alt sorunu derinlemesine araştırması için kullanılmasıdır, sonuç ana ajanın yanına döner, bir sonraki ajanın yanına iletilmez.

Açık dış durum, modele güvenmeme. progress.txt, Git geçmişi, spec dosyası, veritabanı - biçim önemli değil, ilke şudur: Akıl yürütme zincirinin kritik düğümleri kalıcı depolamaya dışsal hale getirilmelidir ve modelin bağlam penceresinde "hatırlamasına" güvenmemelidir.

Birden fazla Ajanın değeri paralel kapsama sağlamak, iş bölümü değil. Anthropic Research sisteminin sonucu çok açıktır: Performans artışı esas olarak "daha fazla jeton harcamaktan" gelir, "daha iyi iş bölümünden" değil. Birden fazla Ajan, aynı anda birden fazla bağımsız yönde keşfetmeyi gerektiren geniş bir ilk tür görevler için uygundur. Sürekli akıl yürütme, derin bağımlılık gerektiren bağlamlar için uygun değildir.

Doğrulama Ajanı reddeden kişi, bayrak devralan değil. Kalite kontrolü için birden fazla Ajan kullanmanız gerekiyorsa, doğru tasarım, bir Ajanın başka bir Ajanın sorunlarını özel olarak aramasını sağlamaktır, "iş sonuçlarını iletme" değil. Karşıtı sınama, akış hattı iletimi değildir.

Araçlar araçtır, rol değil. Bir Ajanı neyle donattığınız (bash, dosya okuma/yazma, arama, kod yürütme) onun ne yapabileceğini belirler; rol etiketi yalnızca ne yapmaya istekli olduğunu sınırlar.

Üç Kısımdan Altı Bölüm Neden Popüler Oldu?

Çünkü açıklaması kolaydı.

「Bu ajan PM, şu ise QA」 — Bu cümle herkes tarafından anlaşılabilir. Bu, insanların yapay zeka sistemlerine açıklanabilirlik arzusunu karşılarken, yönetimin de "AI'nın bir ekip gibi çalıştığı" hayalini gerçekleştiriyor.

Bu ayrıca iyi bir şekilde göstermek içindir. Bir akış diyagramıyla çizilir, birimleri vardır, oklar vardır, geçişler vardır, son derece açıktır.

Ancak iyi açıklanabilirlik ve iyi gösterim, mühendislik açısından geçerlilikle ilgili değildir.

Daha derin bir neden şudur: Bu modele uygun olan çoğu ekip, genellikle "çoklu Ajanlar arasında bağlamın iletilmesindeki kaybı" gerçekten deneyimlememiştir. Görevleri yeterince karmaşık olmayabilir veya sorun diğer faktörler tarafından gizlenmiş olabilir. Görev karmaşıklığı arttığında, sistem garip "yerel olarak doğru, bütünsel olarak yanlış" hatalar vermeye başladığında, sorun ortaya çıkar.

Uygulama Önerileri

En iyi çoklu Ajan sistemleri, bir şirket gibi değil, daha çok aynı düşünen kişinin birden fazla taslağına benzer. Aynı beyin, farklı boyutlarda akıl yürütme yapar ve en sonunda tutarlı bir sonuca birleştirir.

Bu prensipten yola çıkarak:

«Kaç ajan gerekiyor?» demeyin, «Bu görevin bilgi bağımlılık yapısı nedir?» diye sorun.

Eğer görev sürekli akıl yürütmeyi gerektiriyorsa ve bağlam önemli ise (örneğin karmaşık bir özellik taslağı yazmak), genellikle tek Ajan + iyi bir bağlam mühendisliği, çoklu Ajanlardan daha iyidir.

Eğer görev aynı anda birçok bağımsız yöne keşif yapmayı gerektiriyorsa (örneğin 10 farklı rakip ürünün farklı modüllerini aynı anda incelemek), çoklu Ajanlar paralel olarak mantıklıdır — her bir alt-ajanın görevi birbirinden bağımsızdır, bilgi kaybı maliyeti en düşüktür. Bu tam olarak Antropik Araştırma sistem tokenleri miktarının %80 performans farkının açıklaması: İyileştirmeleri sağlayan şey iş bölümü değil, daha büyük keşif kapsamıdır.

Eğer görev birden fazla oturumu kapsıyorsa, dış durum dosyası gereklidir. Etkili bir durum dosyası dört tür bilgi içermelidir:

· Görev Amaçları (sabit, oturum başında okunur, kayma engeller)

· Tamamlanan Adımlar (eklenen, üzerine yazılmayan, tüm geçmişi koruyan)

· Mevcut Durum (Yansıma, En Son Gelişmeleri Yansıtır)

· Bilinen Tuzaklar (Tekrarlanmayacak Şekilde Eklemeler Yaparak)

Bu dört bilgi türü ayrı ayrı korunur, bir araya getirildiğinde "sonraki siz"in ihtiyaç duyduğu tam bağlamdır.

Eğer doğrulama aşaması eklemek istiyorsanız, doğrulama Ajanının tek görevinin sorunları bulmak olduğundan emin olun, bu sürecin bir sonrakine devredilmesi gereken bir görev olmadığını unutmayın. Mücadeleci Doğrulama, bir akış hattı iletimi değildir.

Son olarak: Model yetenekleri hızla gelişiyor, bugün harness içinde gereken geçici çözüm, altı ay sonra taşınabilir bir hale dönüşebilir. Anthropic bu noktayı doğruladı—Sonnet 4.5'in bağlam kaygısı, Opus 4.5'te kayboldu ve onun için tasarlanan bağlam sıfırlama hemen hemen gereksiz hale geldi. Mimarının Evrilebilirliğini Korumak, "Mükemmel Mimarlık" Seçmekten Daha Önemlidir.

Üç Kontrol Altında ve Altı Bakım Bölümü, insanın iyi hissetmesine neden olan ancak mühendislik açısından yüksek maliyetli bir yanılsamadır. Gerçek maliyeti doğrudan bir başarısızlık değil, sistemizin karmaşıklık arttıkça, tanımlanması zor bir şekilde bozulmasıdır—her düğüm "çalışıyor gibi görünür", ancak bütün olarak kaymaktadır.

Sorunu fark ettiğinizde, akış hattı çoktan uzun bir hale gelmiş olacaktır.

Referans Dökümanlar:

Anthropic Mühendislik Blogu (Etkili Ajanlar Oluşturma, Etkili Bağlam Mühendisliği, Çoklu Ajan Araştırma Sistemi, Uzun Süre Çalışan Ajanlar İçin Etkili Kemerler, Yönetilen Ajanlar); OpenAI Geliştirici Blogu (Codex ile Uzun Süreli Görevler Çalıştırma, Kabuk + Beceriler + Sıkıştırma); Google Geliştirici Blogu (Verimli Bağlam Farkındalığına Sahip Çoklu Ajan Çerçevesi Mimarisi, Gemini CLI için Bağlam Odaklı Gelişme için Orkestra)

Orjinal Makale Bağlantısı

BlockBeats Resmi Topluluğuna Katılın:

Telegram Abonelik Grubu: https://t.me/theblockbeats

Telegram Sohbet Grubu: https://t.me/BlockBeats_App

Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia