Orijinal Yazar: Taylor Pearson
Çeviren: Peggy
Editör Notu: Bir AI Ajanı bir seferlik Birleşik Soruşturma ve vibe coding'den daha karmaşık bir iş akışı aşamasına geçtiğinde, gerçekten önemli olan soru artık "modelin görevi tamamlayıp tamamlayamayacağı" değil, "AI yeteneğini yeniden kullanılabilir, birikimli iş akışı varlıklarına dönüştürebilme" meselesidir.
Bu makale, Garry Tan'ın GBrain'inden yola çıkarak, Codex, Claude Code, Hermes gibi Ajan Araçlarını kullanan birçok kişinin giderek yaklaştığı beş temel biçimi özetler: Parametrelendirilebilir Yetenekler, Hafif Yürütme Çerçevesi İnce Kemer, Yönlendirmeyi üstlenen Çözümleyiciler, Model Kararını ve belirlenmiş kodun yürütme katmanını ayırmak, ve Uzun vadeli bağlam biriktirmek için Hafıza.
Bu modüller bir araya geldiğinde, işaret edilen şey yeni bir "süreç yeteneği"dir: Deneyimi sürece dönüştürmek, görevi parametre olarak soyutlamak, sabit kuralları koda devretmek, hükmü ve sentezi modele bırakmak, ve ardından bellek katmanı aracılığıyla sürekli birikmesini sağlamak. Bir seferlik üretilen uygulamalara veya ipuçlarına kıyasla, bu tür bir sistem daha zor kopyalanabilir ve bireysel, küçük ekip ve şirketlerin AI çağında uzun vadeli rekabet avantajı elde etmesi daha olasıdır.
Aşağıda orijinal metin bulunmaktadır:
Garry Tan'ın GBrain'i üzerine biraz zaman harcadım. Teknik olmayan bir geçmişe sahip ve risk sermayesi sektöründe çalışmayan biri olarak, gördüğüm bazı genel yapı biçimlerini özetlemek ve gerçekten ilginç bulduğum noktaları analiz etmek istedim.
Birçok insanın yavaş yavaş aynı temel yapıya yaklaştığını düşünüyorum. Bunlar genellikle 5 farklı biçimde özetlenebilir ve Codex, Claude Code, Hermes, OpenClaw gibi zeka ajanı tarzı AI araçlarının kullanım yöntemlerinin doğal bir evrim yönünü temsil eder.
İlgili okuma: "İnce Kemer, Şişman Yetenek: 100 Kat AI Verimliliğinin Gerçek Kaynağı"
Yetenekler neredeyse herkesin en doğal başlangıç noktasıdır. Kimse hatırlatma yapmasa bile, kullanıcı bunu içgüdüsel olarak oluşturacaktır, çünkü şekli çok tanıdıktır. Başlangıçta bunu bir SOP olarak anladım, yani belirli bir görevi tamamlamak için standart işlem akışı. Kullanıcı "ne yapılacağını" sağlar, Yetenek "nasıl yapılacağını" sağlar.
Tan'ın anlayışına göre, Skill daha çok bir "method çağrısı" gibi. Programlamada, method çağrısı belirli bir program akışını parametrelerle çağırmayı ifade eder. Aynı kod parçası her zaman çalışır, değişen şey ise parametrelerdir: hangi veri, hangi sorun, hangi hedef. Örneğin, aynı process_invoice fonksiyonu, sistemdeki her faturayı işleyebilir, sadece ilk yazıldığı faturayla sınırlı kalmaz.
Skill de benzer bir yapıya sahiptir. /investigate adındaki bir Skill, yedi sabit adım içerebilir, bu yedi adım değişmez. Değişen şey ise parametrelerdir: TARGET (araştırılacak hedef kim ya da ne), QUESTION (ne hakkında bilgi edinmek istiyorsunuz), DATASET (bilgiyi nereden alacaksınız). Bu bir tıbbi alandaki ihbarcı örneğine işaret ederse, bir araştırma analisti gibi davranır; SEC beyanname belgesine işaret ederse, hukuk soruşturmacısı gibi davranır. Aynı belge, aynı yedi adım, farkı dış dünya sağlar.
Bu, geleneksel SOP'tan farklıdır. Çoğu SOP genellikle belirli bir pozisyon veya görev için yazılır, örneğin "alışveriş faturasını işleme". Her kullanım senaryosu için özel bir iş akışı vardır. Ancak Skill'lerin soyutlama seviyesi daha yüksektir, aynı iş akışı bir tür sorunu çözebilir. İyi tasarlanmış bir Skill, onlarca SOP'un işini yapabilir çünkü spesifik olay bilgisi dökümandan çıkarılır ve parametrelere taşınır. Gerçek kullanıma gelindiğinde, bazı Skill'ler daha çok SOP'a yakındır, bazıları ise daha çok method çağrısına yakındır.
Opus, GPT-5.5 gibi modeller, temel zekidir; Claude Code, Codex CLI, Hermes, OpenClaw gibi Harness'lar ise modele gerçekten "eller ve ayaklar" kazandıran yürütme çerçeveleridir. Bunlar döngüsel yürütme, dosya okuma/yazma, bağlam yönetimi, güvenlik kısıtlamalarını yürütme gibi işlemlerden sorumludur. Temel kodları genellikle sadece 200 satırdan oluşur.
Garry, çoğu insanın yaptığı gibi sürekli olarak Harness'e daha fazla şey eklemeye çalışmanın bir hatası olduğunu belirtti, kendim de öyleyim. Sonunda 100'den fazla araç tanımı ve bir sürü MCP sunucusu biriktirdim. Sonuç olarak, bağlam penceresi, mevcut görev için gerekli olmayan araç tanımlarıyla dolmuş durumda. Model hangi aracı kullanması gerektiğini karıştırmaya başlar, gecikmeler artar, doğruluk azalır ve sonunda "bağlam bozulması" olarak adlandırılan durum oluşur.
Metin bozulmasını ele almanın bir yolu, bir yönlendirme tablosu oluşturmaktır. Çözücünün görevi, "yeni gelen X türündeki görevi"nin "hangi beceriyi çağırması gerektiğini" net bir şekilde eşlemektir. 5 beceriye sahip olduğunuzda Çözücü'ye ihtiyacınız yoktur; ancak 100 beceriye sahip olduğunuzda, çeşitli açıklamalar belirsiz hale gelir ve modelin doğru zamanda doğru beceriyi çağıramaması kolaylaşır. Çözücü, belirsiz desen eşleştirmenin yerine net bir kural kullanır.
Tan, dosyalar için bir Çözücü'ye benzer bir mekanizma çalıştırdı: Hangi becerinin çıktısının dosya sistemine hangi konuma düşmesi gerektiğini belirlemek için bağımsız bir yönlendirme tablosu. Bu, aynı "Denetim-Yönlendirme" yapısı, başka bir soruna uygulanmıştır. Bu şekilde, çıktı istikrarlı bir şekilde doğru klasöre girer ve modelin geçici tahmin ettiği konum yerine yerleştirilir.
Skillify, başka bir eşleşen fikriydi: Bu, tek kullanımlık bir yeteneği uzun vadeli kullanıma uygun bir altyapıya dönüştürmek için bir döngü setiydi. Tan'ın açıkladığı 10 adımlı süreç şunları içerir: Sözleşme tanımı, belirlenmiş kodun kullanılacağı yerler, birim testleri, entegrasyon testleri, LLM olarak hakem değerlendirmesi, Çözücü girişi, denetim betiği, hangi becerilerin çağrı yolu olmadığını kontrol etme ve uçtan uca duman testi. Test kriteri çok basittir: Eğer modelden aynı soruyu iki kez sormak zorunda kalırsanız, o bir başarısızlıktır.
Hangi işlerin LLM'ye, hangilerinin belirleyici sistemlere verilmesi gerektiğini dikkatlice ayırt etmek önemlidir. LLM, değerlendirme, sentez, desen tanıma ve anlam dışı şeyleri anlama konularında iyidir; ancak aritmetiği, kombinasyon optimizasyonu konularında iyi değildir ve her zaman aynı cevabı vermesi gereken herhangi bir görevi işlemek için uygun değildir. LLM temelde olasılığa dayalıdır ve bir belirlilik çözümü sorunu çözebilecekse, LLM kullanılmamalıdır.
Çoğu teknik olmayan kişi, genellikle belirleyici katmanın değerini hafife alır. Herkesin varsayılan tepkisi, her şeyi modelle atmak olabilir. Ancak bir iş belirleyici şekilde tamamlanabilecekse, neredeyse her zaman bu şekilde yapılmalıdır. Ve bir programcı olmanıza gerek yok çünkü model sizin için kod yazabilir. Gerçekten eğitilmesi gereken şey, kendinize her zaman şu soruyu sormanızdır: Bu, kodun kararlı ve düşük maliyetli bir şekilde başa çıkabileceği bir şey mi? Cevap evetse, o kod parçasını modelin yazmasına izin verin.
Sistemin kullanışlı olabilmesi için, belirli bir hafızaya sahip olması gerekir. En doğru şeklinin ne olduğundan emin değilim ve şu anda birçok insan farklı yöntemlerle inşa ediyor: Vektör gömme, anlamsal benzerlik, bilgi grafiği, karma depolama vb. Tan'ın yaklaşımı benimkiyle aynıdır: sadece bir markdown dosyası klasörü.
Yapısı şudur: Her kişi için bir sayfa, her şirket için bir sayfa, her kavram için bir sayfa. Her sayfanın üst kısmında "Mevcut Güvenilir Sonuç" bulunur, yani sürekli olarak yeniden yazılan ve güncellenen kapsamlı bir değerlendirme; alt kısımda ise yalnızca eklemeli, üstünü örtmeyen bir zaman çizelgesi bulunur.
Markdown'u seçmek birkaç sonuç getirecektir. İlk olarak, dosya kendisi sistemin ana kaydıdır, bir tür dışa aktarma sonucu değil. Bu dosyayı VS Code'da açabilir, el ile düzeltebilirsiniz, Agent bu değişiklikleri otomatik olarak okur. İkinci olarak, works_at, invested_in, founded, attended, advises gibi tipize ilişkiler, her yazılışta düzenli ifadeler aracılığıyla otomatik olarak çıkarılacaktır, bu nedenle bilgi grafiği token tüketmeden kendi kendine bağlanabilecektir. Bu belirli şema, onun işi için çok uygundur, ancak diğerleri için kendi mesleği ve iş senaryolarına göre özelleştirme gerektirebilir.
Ayrıca, arka planda bir sinyal algılayıcı bulunmaktadır. Bir kişiye bir kez atıfta bulunulduğunda, bir yer tutucu sayfası oluşturulur; aynı kişi birkaç kaynakta üç kez atıfta bulunulursa, web bilgisi tamamlama tetiklenir; bir toplantı sona erdiğinde, tam döngü çalıştırılır. Geceleyin "rüya döngüsü", konuşmaları tarar, eski tarihli varlık bilgilerini tamamlar ve geçersiz bağlantıları düzeltir. Temel katmandır metin, üzerindeki her şey ucuz ve bir araya getirilebilir.
Elbette altta daha fazla ayrıntı bulunmaktadır, ancak bunların çoğu en önemli ana hatlardır ve genellikle evrenseldirler.
Şu anda benim de yaklaşık yarısını oluşturduğum bu tür bir mimariye sahibim. Daha önce gerçek bir Çözücü'ye ihtiyaç duyulacak büyüklüğe ulaşmadım, ancak şimdi bu aşamaya geldim, bu nedenle sistemimi model bağımsız hale getirdim ve bir Çözücü içine yerleştirdim. Şu anda henüz oluşturmadığım temel parçalar, arka planda otomatik olarak çalışan sinyal algılayıcı ve gece boyunca rüya döngüsüdür, yani otomatik bilgi tamamlama ve düzenleme mekanizması, bunları eklemeyi düşündüğüm bir sonraki adımdır.
Şüphelerim var, farklı oluşturucuların benzer bir yapıya doğru yaklaştıklarını görmek, zaten başlı başına bir sinyaldir: Bu şekil çoğu insan için uygun olmayabilir, ancak genel olarak büyük olasılıkla yararlıdır. Belirli uygulama detayları önemli farklılıklar gösterebilirken, bu genel yapıya doğru giden yol, giderek daha fazla insan tarafından bağımsız olarak keşfedilmektedir.
Son zamanlarda kendime sorduğum soru şudur: AI ile sürdürülebilir bir rekabet avantajı nasıl oluşturulabilir?
Herkes vibe-coded uygulamaları ve bir kerede alınan yönergeleri çok heyecan verici buluyor, bu kesinlikle harika. Kendim de başlangıçta böyle oynamaya başladım ve bu şekilde bağımlı hale geldim. Ancak bir kerede alınan yönergelerle oluşturulabilecek her şey, denge token maliyeti olan ve yani oluşturulması gereken token maliyetine, yani birkaç sente kadar düşecektir.
Örneğin, birisi MyFitnessPal'ı kopyaladı, yarı fiyatına satışa çıkardı ve 1 milyon dolar kazandı, bu tabii ki harika. Ancak çok geçmeden bir başkası onu tekrar kopyalayacak ve daha düşük bir fiyatla satışa çıkaracak. Bu döngü sürekli devam edecek ve kar marjı tamamen sıkışacak.
Gerçekten sürdürülebilir olan şey, belirli bir "süreç gücü"dür. Hamilton Helmer'ın "7 Powers" çerçevesine göre, yukarıdaki mimari tarafından ima edilen budur, yani süreç gücü.
"7 Powers", bir işletmenin pazar ortalamasının üzerinde uzun vadeli kar marjını sürdürebilmesinin nedeninin, yedi yapısal güçten birine sahip olmasından kaynaklandığını öne sürüyor. Bu güçlere kök salmayan herhangi bir üstünlük, sonunda rekabet tarafından aşındırılacaktır.
KOBİ'ler ve erken aşama şirketler için, Helmer'ın yedi gücünden beşi zaten kapalıdır. Ölçek ekonomisi ölçek gerektirir; ağ etkisi ve dönüşüm maliyeti oluşturulabilir, ancak büyük bir kullanıcı tabanı biriktirmek gereklidir; tekelleşme kaynakları genellikle patent veya benzeri varlıkları içerir, ki bu çoğu şirketin sahip olamayacağı bir şeydir; marka genellikle on yıl süren birikim gerektirir, kısa yoldan gidilemez.
Geride kalan iki tür, ters konumlandırma ve süreç yeteneğidir.
Ters konumlandırma, mevcut devasa bir şirketin taklit edemeyeceği bir iş modelini ifade eder, çünkü taklit ettiğinde kendi mevcut işini zarara uğratır. Bu fırsat bazen mevcuttur, ancak her zaman elde edilebilir değildir.
Dolayısıyla, en gerçekçi yol süreç yeteneğinden başka bir şey bırakmamaktadır. Ve iyi tasarlanmış bir yapay zeka sistemi, tam da süreç yeteneği üretebilen bir araçtır.
Bu, yüksek kaliteli SOP'lar oluşturmak veya özel yazılım geliştirmekle özünde aynı tür çalışmadır: Süreçler kodlanmış, durumlar parametrelendirilmiş, altta yatan belirli sistem hızlı ve güvenilir bir şekilde çalışırken, bellek katmanı sürekli geçmişten öğrendikleri devralır. Bu, "ürünleştirilmiş hizmeti" daha da genişletir: Belirli bir hizmeti veya ürünü daha düşük maliyetle veya daha yüksek kalitede sunabilirsiniz çünkü tüm iş yapısı yapılandırılmıştır.
Böyle bir sistem kuran bir muhasebeciyi hayal edin. Bellek katmanı bir dosya ve her müşteri için bir markdown dosyasına sahiptir, içinde mevcut güvenilir sonuçlar bulunur, örneğin varlık yapısı, yıllık vergi durumu, devam eden denetim ve kararlar, toplantılar ve değişikliklerin kaydedildiği bir zaman çizelgesi.
Belirli becerileri vardır, örneğin /yıl-sonu-analizi, /üç-aylık-tahmin, /denetim-hazırlığı. Aynı süreç farklı müşteriler için parametrelendirilmiş bir şekilde yürütülebilir.
Ayrıca, bir belirlenme katmanı vardır, vergi tabloları, amortisman tabloları, IRS belgeleri, müşteri geçmiş vergi tabloları vb. içerir.
Ek olarak, bir tür günlük düzenleme veya rüya döngüsü mekanizmasını ekleyin. Örneğin, sistem gece boyunca otomatik olarak fark edebilir ki bir ortağın K-1 tahsili, stratejide bir değişiklik olmaksızın %40 düştü; veya bir müşterinin ev ofisi indirimi yapısı, başka bir müşteriye taşınabilir, yapı yeniden kullanılabilir, ancak kimlik ve gizlilik yine de aynı kalır.
Bu şekilde, daha az prim alabilir, her yıl daha fazla müşteriye hizmet edebilir ve rakipler zor kopyalayabilir çünkü bu yapı sadece başarısından sonra değil, başlangıçtan itibaren sürekli birikmiştir.
Dışarıdan bakıldığında, bu araç sadece bir markdown klasörü gibi görünmektedir. Ancak her dosyadaki her satırın arkasında, bilinçli testler, kurulum ve üzerinde çalışma yoluyla elde edilen birçok şey bulunmaktadır. Gerçek rekabeti sınırlayan şey, dosyanın kendisi değil, bu dosyaların taşıdığı işlem yeteneğidir.
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