Bugün Harness Engineering hakkında uzun bir yazı okudum — on binlerce kelime, neredeyse kesinlikle yapay zeka tarafından yazılmış. İlk tepkim "vay canına, ne güçlü bir konsept" olmadı. Soru "Bu insanların eski terimler için yeni terimler uydurmaktan başka bir fikri var mı?" idi. Yapay zeka dünyasındaki bu kalıptan hep rahatsız olmuştur — mevcut kavramların sürekli yeniden icat edilmesi. Hızlı mühendislikten bağlam mühendisliğine, şimdi de mühendisliği kullanmaya geçelim. Her birkaç ayda biri yeni bir terim uyduruyor, 10.000 kelimelik bir makale yazıyor, birkaç büyük şirket vaka çalışması ekliyor ve tüm topluluk coşmaya başlıyor. Ama içeriğe gerçekten bakarsanız, her seferinde aynı şey oluyor: Modelinizin çalıştığı ortamı tasarlayın — aldığı bilgiler, hangi araçları kullanabileceği, hataların nasıl ele geçirildiği, oturumlar arasında hafızanın nasıl yönetildiği. Bu, ChatGPT'nin çıktığı günden beri varlığını sürdürüyor. Sadece biri — herhangi bir nedenle — ona yeni bir isim vermeye karar verdiği için yeni bir disiplin haline gelmez. Bununla birlikte, şikayetler bir yana, makalede bahsedilen araştırmalar ve vaka çalışmaları gerçekten değerli — özellikle de nasıl yapılır sglang ile inşa ettiklerimle büyük ölçüde örtüştüğü için. Bu yüzden bunu aslında yaptığım hatalardan bahsetmek için bir fırsat olarak kullanmak istiyorum. Önce biraz arka plan. SGLang topluluğunda en yaygın talepler Nasıl yapılır sorularıdır — DeepSeek-V3'ü 8 GPU'da nasıl dağıtılır, gateway işçi adresine ulaşamazsa ne yapılacağı, GLM-5 INT4 ile resmi FP8 arasındaki farkın önemli olup olmadığı. Bu sorular son derece geniş bir teknik alanı kapsıyor ve topluluk giderek daha hızlı büyüdükçe, yanıtlara yetişemeyiz. Bu yüzden otomatik olarak cevap vermek için çoklu ajan sistemi inşa etmeye başladım. İlk fikir elbette en saf olanıydı — tek bir her şeyi bilen Ajan inşa etmek, SGLang'ın tüm belgelerini, kodlarını ve yemek kitaplarını içine sığdırmak ve her şeyi cevaplamasına izin vermek. Bu işe yaramadı. Bunun nedenini açıklamak için mühendislik teorisini kullanmaya gerek yok — bağlam penceresi RAM değildir. Ne kadar çok şey yaparsanız, modelin dikkati o kadar dağılır ve cevaplar o kadar kötüleştiriler. Bir Ajan, kuantlaşma, PD ayrıştırma, difüzyon servisi ve donanım uyumluluğunu aynı anda anlamaya çalışırsa, bunların hiçbirini derinlemesine anlayamaz. Sonunda bulduğumuz tasarım çok katmanlı bir alt alan uzmanı mimarisi. SGLang'ın dokümantasyonu zaten doğal işlevsel sınırlara sahip — gelişmiş özellikler, platformlar, desteklenen modeller — ve yemek kitapları modellere göre düzenlenmiş. Her alt alanı bağımsız bir uzman ajana dönüştürdük; soruları almaktan, alt sorulara ayırmaktan, doğru ajanları etkinleştirmek için Uzman Yönlendirme Tablosu'na danışmaktan, paralel çözmekten ve ardından cevapları sentezlemekle sorumlu olan bir Uzman Tartışma Yöneticisi bulunduk. Geriye dönüp baktığımızda, bu tasarım kostüm mühendisliği topluluğunun savunduğu desenlerle neredeyse mükemmel şekilde eşleşiyor. Ama onu inşa ederken, bu desenlerin isimleri olduğunu hiç bilmiyordum. Ve buna gerek yoktu. 1. Aşamalı açıklama — tüm belgeleri tek bir ajana aktarmadık. Her alan uzmanı yalnızca kendi alan bilgisini yükler ve Müdür, soru türüne göre kimi aktive edeceğine karar verir. İçgüdülerim, bu tasarımın daha güçlü bir modeli değiştirmekten çok daha fazla gelişme sağladığı yönünde. Bu kararı vermek için bunun "ilerici açıklama" dendiğini bilmenize gerek yok. Sadece "her şeyi içeri sok" yaklaşımını bir kez denemen ve başarısız olmasını izlemen yeterli. 2. Doğruluk kaynağı olarak depo — tüm iş akışı nasıl yapılır repo'da yaşar. Tüm uzman temsilciler, bilgilerini depo içindeki markdown dosyalarından alır ve dış belgelere veya sözlü anlaşmalara bağımlı olmaz. Başlarda, her şeyi kapsayan büyük bir sglang-maintain.md yazma isteği duyduk. Çabucak bunun işe yaramadığını öğrendik. OpenAI'nin Codex ekibi de aynı hatayı yaptı — tek bir büyük AGENTS.md denediler ve tahmin edilebilir şekillerde çürümesini izlediler. Bu mayına kendiniz basmak için bloglarını okumanız gerekmez. Bu, klasik yazılım mühendisliği problemi olan "monolitik belgeler her zaman bayatlanır," ama bir ajan bağlamında sonuçlar daha kötü — bayat dokümantasyon sadece okunmaz, aynı zamanda ajanı aktif olarak yanıltır. 3. Yapılandırılmış yönlendirme — Uzman Yönlendirme Tablosu, soru türlerini ajanlara açıkça eşler. GLM-5 INT4 hakkında bir soru, hem Cookbook Alan Uzmanını hem de Kuantizasyon Alanı Uzmanını aynı anda etkinleştirir. Müdür tahmin etmiyor; yapılandırılmış bir endeksi takip eder. Kostyum mühendisliği kitlesi buna "mekanize kısıtlamalar" diyor. Ben buna normal mühendislik diyorum. Harness mühendisliğinin arkasındaki fikirlerin kötü olduğunu söylemiyorum. Alıntılanan araştırma sağlam, SWE-agent'ın ACI kavramı gerçekten bilinmeye değer ve Anthropic'in çift ajan mimarisi (başlatıcı ajan + kodlama ajanı) uzun ufuk görevleri yapan herkes için değerli referans materyali. Beni sıkıyan şey, sürekli yeni terimler ortaya atmak — yerleşik mühendislik sağduyusunu yeni bir disiplin olarak paketlemek, sonra "bu kelimeyi bilmiyorsan geride kalırsın" gibi üretim kaygısı. Prompt mühendisliği, bağlam mühendisliği, harness mühendisliği — bunlar aynı şeyin farklı yönleridir. Gelecek ay muhtemelen biri iskelet mühendisliği veya orkestrasyon mühendisliği yazacak, aynı SWE-ajanı makalesine atıfta bulunan uzun bir makale daha yazacak ve topluluk yeni bir amplifikasyon döngüsü başlatacak. Nasıl yapılır diye öğrendiklerimi yeni bir kelime dağarcığı olmadan da ifade edebilirim:...