LangChain 160 milyon dolar topladı. Üç yıllık geliştirme. Milyar dolarlık değerleme. Test platformları LangSmith gerçekten sofistike: yörünge değerlendirmeleri, izlemeden veri setine işlem hatları, LLM-as-judge, regresyon paketleri, araçlar için birim test çerçeveleri. Parçalara sahipler. Hakkını vermek gerek.
Ama parçalar bir pratik değildir.
LangChain size test araçları verir. Neyi, hangi sırayla test edeceğinizi veya ne zaman bitirdiğinizi asla söylemez.
Sırayla şunu söyleyen, görüş bildiren bir iş akışı yok:
- bu hata oldu
- şimdi bir beceri (skill) yaz
- şimdi deterministik kodu yaz
- şimdi birim testleri yaz
- şimdi LLM değerlendirmeleri yaz
- şimdi bir çözümleyici tetikleyicisi ekle
- şimdi çözümleyiciyi değerlendir
- şimdi kopyaları denetle
- şimdi duman testi yap
- şimdi doğru dosyala
Bu döngü mevcut değil. Bunu kendiniz dağınık ilkellerden icat etmek zorundasınız. Yapay zeka kullanıcılarının büyük bir kısmı hala ajanlarını hiç test etmiyor çünkü seçtikleri çerçeve muhtemelen onlara egzersiz programı olmayan bir spor salonu üyeliği verdi.
Çoğu AI ajan "güvenilirliği" hissiyata dayalıdır. İstem ayarlamaları. Daha büyük sistem mesajları. "Lütfen halüsinasyon görme" büyüleri. Sohbet karmaşıklaştığı an bunlar bozulur. Bunu çözmek için yüz milyonlarca dolar toplayan çerçeveler size izleme panoları ve birim test yardımcıları verdi ve "iyi şanslar" dedi.
Ajanım bu hafta iki kez hata yaptı. Bu hataların hiçbiri tekrarlanmamalı. Kibarca sorduğum için değil. Her hatayı kalıcı bir yapısal düzeltmeye dönüştürdüğüm için: her gün, sonsuza kadar çalışan testleri olan bir beceri.
Ben bu uygulamaya "skillify" diyorum. Bir kez kullandığınızda, ajanlarınız aynı hataları yapmaya devam etmez. İşte nasıl çalıştığı.
Hata 1: Zaten Veritabanında Olan Seyahat
OpenClaw'uma neredeyse on yıl önceki, takvim geçmişinde bir yerde gömülü eski bir iş seyahatini sordum. Basit soru. Bir saniye sürmeli.
Bunun yerine ajan şunu yaptı:
- Canlı takvim API'sini çağırdı → engellendi (çok eski).
- E-posta aramayı denedi → gürültülü sonuçlar, kesin bir şey yok.
- Takvim API'sini farklı parametrelerle tekrar denedi → hala engellendi.
- Beş dakika sonra yerel bilgi tabanımda aradı ve anında buldu.
Cevap tüm bu süre boyunca kendi verilerimde duruyordu. 2013'ten 2026'ya kadar 3.146 takvim dosyası. Zaten indekslenmiş. Zaten yerel. Bir grep uzaklığında.
Ajan sadece önce oraya bakmadı.
Bahsettiğim çerçevede (thin harness, fat skills), yargı gerektiren iş ile hassasiyet gerektiren iş arasında önemli bir ayrım var. Ben bunlara latent ve deterministik diyorum. Takvim grep'i deterministiktir. Aynı girdi, aynı çıktı, her zaman. Modele gerek yok. Ama ajan yine de latent alanda yaptı, muhakeme başlattı, API çağrıları yaptı, sonuçları yorumladı; oysa üç satırlık bir komut dosyası anında cevabı döndürecekti.
Hata bu. Yanlış cevap değil. Yanlış taraf.
Düzeltme: calendar-recall (Adım 1 + 2)
Thin harness / fat skills'te bir beceri (skill), modele bir göreve nasıl yaklaşılacağını öğreten bir işaretleme prosedürüdür. Ne yapılacağını değil (neyi kullanıcı sağlar). Beceri süreci sağlar. Bunu bir metot çağrısı gibi düşünün: aynı prosedür, ne aktardığınıza bağlı olarak radikal biçimde farklı çıktılar.
İşte bu hatadan çıkan beceri:
isim: calendar-recall açıklama: "Beyin-öncelikli geçmiş takvim araması. Gelecekte olmayan veya son 48 saat içinde olmayan herhangi bir etkinlik için canlı API'den ÖNCE her zaman bunu kullan."
Ve içindeki katı kural:
Canlı takvim API'leri yalnızca GELECEKTEKİ veya SON 48 SAAT İÇİNDEKİ etkinlikler İÇİNDİR. Geçmişle ilgili her şey önce yerel bilgi tabanı üzerinden gider.
Bunu işe yaratan şey şu: deterministik komut dosyasını ajanın kendisi yazdı. Beceri dosyası (latent alanda yaşayan işaretleme), ajana sorunu nasıl çözeceğini söyledi. Ajan beceriyi okudu, takvim aramasının deterministik bir iş olduğunu anladı ve bunu halletmek için bir komut dosyası oluşturdu:
$ node scripts/calendar-recall.mjs search "Singapur"
2 eşleşen gün bulundu: ── 2016-05-07 ── Singapur'a Uçuş, Mandarin Oriental girişi ── 2016-05-08 ── Fullerton Hotel'de yatırımcılarla öğle yemeği
100 milisaniyenin altında çalışan kod (çoğu Bun başlangıcı; gerçek grep milisaniyenin altında). Sıfır LLM çağrısı. Sıfır ağ. Sadece yerel dosyalar.
Tüm mimariyi çalıştıran döngü şudur: latent alan deterministik aracı oluşturur, sonra deterministik araç latent alanı kısıtlar. Ajan, calendar-recall.mjs'yi yazmak için yargıyı (latent) kullandı. Şimdi beceri, ajana takvim verileri hakkında akıl yürütmek yerine bu komut dosyasını çalıştırmasını zorluyor. Modelin zekası, modelin aptal olmasını engelleyen kısıtlamayı yarattı.
Eski hata yolu yapısal olarak ulaşılamaz hale gelir. Beceri "önce yerel ara" der. Komut dosyası aramayı yapar. Ajan bu konuda zeki olma veya tekrar hata yapma şansı bulamaz.
Hata 2: "28 Dakika" (Yine Adım 1 + 2)
Aynı gün. Ajan diyor ki: "Bir sonraki toplantınız 28 dakika sonra."
Gerçek: 88 dakika sonra. Ajan kafasında UTC→PT saat dilimi matematiği yapmıştı ve tam bir saat yanılıyordu.
Mesele şu ki, bunu çıktı olarak veren bir komut dosyası zaten vardı (context-now.mjs):
{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "Uygulama Operasyonları Sprint Planlaması", "minutesUntil": 88 }] }
Yaklaşık 50 milisaniyede çalışan kod. Sıfır belirsizlik. Ajan sadece onu çalıştırmadı.
Öncekiyle aynı şekil: latent alanda yapılan deterministik iş (zaman damgalarını çıkarma). Model, komut dosyasında cevap varken zihinsel matematik yapıyordu.
Düzeltme: context-now, beceri:
isim: context-now açıklama: "HER ZAMAN AÇIK disiplin: HERHANGİ bir zamana duyarlı iddiada bulunmadan ÖNCE context-now.mjs'yi çalıştır. Asla kafanda UTC→PT dönüşümü yapma."
İşte bu basit becerilerle ve beceriler olmadan öncesi/sonrası:
Skillify: Aklınızı kurtaracak desen
İki hata. Aynı şekil. Ajan doğru araca sahipti ve disiplin yerine zekiliği seçti. Yanlış şey yanlış makine alanında oldu.
Normal bir AI kurulumunda, AI özür diler, daha iyisini yapacağına söz verir ve iki hafta sonra aynı şey farklı bir sorgu veya farklı bir saat dilimiyle tekrar olur. Ajanın hatayla ilgili hafızası yok, hata için testi yok, tekrarlanmasını engelleyen hiçbir şey yok.
Skillify düzeltmedir. Her hata bir beceri haline gelir. Her becerinin testleri vardır. Hata yapısal olarak tekrarlanamaz hale gelir.
İşte bir hata terfi ettiğinde kullandığım 10 maddelik kontrol listesi:
□ 1. SKILL.md — sözleşme (isim, tetikleyiciler, kurallar) □ 2. Deterministik kod — scripts/*.mjs (kodun yapabileceği için LLM yok) □ 3. Birim testleri — vitest □ 4. Entegrasyon testleri — canlı uç noktalar □ 5. LLM değerlendirmeleri — kalite + doğruluk □ 6. Çözümleyici tetikleyicisi — AGENTS.md'de giriş □ 7. Çözümleyici değerlendirmesi — tetikleyicinin gerçekten yönlendirdiğini doğrula □ 8. Çözülebilirliği kontrol et + DRY denetimi □ 9. Uçtan uca duman testi □ 10. Beyin dosyalama kuralları
On testin tamamını geçmeyen bir özellik bir beceri değildir. Sadece bugün çalışan koddur.
Yukarıdaki iki hata zaten 1. ve 2. adımları yürüdü: SKILL.md'yi yaz (sözleşme), ardından deterministik kodu yaz (ajanın oluşturduğu ve sonra kullandığı komut dosyası). Ancak kalan sekiz adımı anlatmadan önce, skillify'ın günlük kullanımda nasıl göründüğünü göstermek istiyorum, çünkü bu sadece bir hataya tepki değil. Bir fiil haline geldi.
Bir fiil olarak Skillify
Benim için, OpenClaw'umu (ve GBrain'imi) inşa ederken, kontrol listesi bir hata tepki protokolü olarak başladı. Sonra her şeyi inşa etme şeklim haline geldi.
İşte gerçek iş akışımın nasıl göründüğü. Ajanımla doğal dilde konuşuyorum. Sohbet içinde birlikte bir şey inşa ediyoruz. Deniyorum. Çalışıyor. Sonra tek bir kelime söylüyorum:
Garry:
vay be çalıştı. bunu bir webhook becerisi olarak hatırlayıp skillify edebilir misin, bir dahaki sefere biraz webhook yapmamız gerekirse? bunu doğru yapmak neden bu kadar zordu? neyse şimdi iyi. DRY da yap
Bu bir OAuth webhook entegrasyonuydu. Çalışması için bir saat harcadık. Sonra "skillify et" geçici oturumu, testleri, bir çözümleyici girişi ve dokümantasyonu olan kalıcı bir beceriye dönüştürdü. Bir dahaki sefere bir webhook'a ihtiyacım olduğunda, beceri var. Ajan onu okuyor. O saatten kazanılan zor bilgi kalıcı.
Bir tane daha. Konteynerimizin belirli görevler için başsız bir tarayıcıya ve diğerleri için masaüstümde başlıklı bir tarayıcıya ihtiyacı olduğunu keşfettik:
Garry:
harika! yani aslında bunu, openclaw'da başsız bir tarayıcıya ihtiyaç duyan her şey için bir beceri olarak hatırlamalıyız! ayrıca başlıklı bir tarayıcıya ihtiyacımız olursa kullanıcıdan gstack browser çalıştırmasını istememiz ve bize bir çift-ajan kodu vermemiz gerektiğini de bilmeliyiz. skillify et!
Tek bir mesaj. Ajan, karar ağacı, deterministik komut dosyaları, testler ile skills/browser/SKILL.md'yi yazar. Artık bir tarayıcıya ihtiyaç duyan her gelecek oturum otomatik olarak doğru araca yönlendirilir.
Ya da bu. Ajanın bana çalışıp çalışmadıklarını kontrol etmeden ngrok bağlantıları göndermeye devam ettiğini fark ettim:
Garry:
bana bir link gönderdiğinde, uç noktanın açık olduğundan ve tünelin çalıştığından emin olmak için linki kendin curl'laman gerektiğini söyleyen bir beceri yapabilir miyiz? skillify et!
Ya da neredeyse bir toplantıma mal olan takvim çifte rezervasyonu:
Garry:
İşte yazmanı istediğim düzenli bir beceri. Takvim kontrol becerisi. Yarın saat 11'de çifte rezervasyonum var. Bu tür şeyleri kontrol etmek için bir beceri yap, onu deterministik yap.
Tek bir cümle. Kod, beceri, testler, çözümleyici girişi, erişilebilirlik denetimi. Tek nefeste 10 adımlık kontrol listesinin tamamı. OpenClaw'um bunu biliyor, yapıyor ve artık bu bir alışkanlık. Bunu düzinelerce kez yaptım. Onsuz yaşayamazdım.
Desen her zaman aynı: sohbette prototip oluştur, çalıştığını gör, "skillify" de ve prototip kalıcı altyapı haline gelsin. Spesifikasyon yazmam. Bilet açmam. Ajanımla konuşurum, sorunu birlikte çözeriz ve sonra çözüm, ajanın ben olmadan sonsuza kadar kullanabileceği bir beceri haline gelir.
160 milyon dolarlık çerçeve finansmanının kaçırdığı şey bu. Test ilkelleri değil. Değerlendirme araçları değil. İş akışı. Bir insanın "bu işe yaradı, şimdi onu kalıcı yap" dediği ve sistemin "kalıcı"nın tam olarak ne anlama geldiğini bildiği an: SKILL.md, deterministik kod, birim testleri, entegrasyon testleri, LLM değerlendirmeleri, çözümleyici tetikleyicisi, çözümleyici değerlendirmesi, DRY denetimi, duman testi, beyin dosyalama. On adım. Tek kelime.
İşte kalan sekiz adımın pratikte nasıl göründüğü.
Adım 3: Birim testleri
Klasik vitest. Belirleyici işlevler, belirleyici iddialar. calendar-recall.mjs, parseEventLine, eventMatchesKeyword, searchKeyword, formatJson gibi saf işlevler dışa aktarır. Her biri, sabit verilere karşı test edilir: geçici bir dizinde sentetik takvim dosyaları, bilinen girdiler, bilinen çıktılar.
Yakaladıkları hata türü: parseEventLine, konum alanında Unicode karakterleri olan etkinlikleri sessizce düşürür. dateFromPath, artık yıl tarihleri için null döndürür. formatJson, yalnızca bir kişi olduğunda katılımcılar dizisini atlar. Küçük, sıkıcı, kritik. Komut dosyası yanlış çıktı üretirse, beceri yanlış cevaplar üretir ve ajan bana güvenle yanlış şeyi söyler.
context-now için birim testleri, saat dilimi biçimlendirmesini, sessiz saat algılamasını ve DST sınırları boyunca minutesUntil hesaplamasını doğrular. Bir test, bir DST geçişinden 3 dakika önce bir zaman besler ve çıktının 60 dakika atlamadığını doğrular. Bu, "28 dakika" hatasına neden olan tam hatadır. Artık yapısal olarak imkansız.
5 pakette 179 birim testim var. 2 saniyenin altında çalışıyorlar.
Adım 4: Entegrasyon testleri
Bunlar canlı uç noktalara ve gerçek verilere çarpar. calendar-recall.mjs, yalnızca test sabitlerinde değil, gerçek beyin deposunda etkinlikleri buluyor mu? Takvim önbelleği eski veya eksik olduğunda context-now.mjs geçerli JSON üretiyor mu? Entegrasyon testleri, sabit veriler çok temiz olduğu için birim testlerinin kaçırdığı hataları yakalar. Gerçek verilerde bozuk etkinlik satırları, eksik saat dilimi alanları, Windows satır sonları olan takvim dosyaları, gece yarısını aşan etkinlikler bulunur.
Kural: komut dosyasının gerçek verilerde doğru şeyi yapıp yapmadığını manuel olarak kontrol ederken bulursanız, bu kontrol bir entegrasyon testi olmalıdır.
Adım 5: LLM değerlendirmeleri
İşte burası ilginçleşiyor. Bazı çıktılar değerlendirmek için yargı gerektirir. "Bu takvim özeti kullanışlı mı?" bir komut dosyasının yanıtlayabileceği bir evet/hayır sorusu değildir. Bu yüzden LLM-as-judge kullanıyorum: bir modelin başka bir modelin çıktısını bir rubriğe karşı değerlendirmesi.
context-now için günde 35 değerlendirme çalışır. Bunlardan biri ajana "hey, uçağım yaklaşık 45 dakika sonra kalkıyor, SFO'ya yetişebilecek miyim?" gibi bir mesaj besler ve ajanın cevaplamadan önce context-now.mjs'yi çalıştırıp çalıştırmadığını veya matematiği kafasında yapmaya çalışıp çalışmadığını kontrol eder. Ajan yemi yutar ve zamanı kendisi hesaplarsa, değerlendirme başarısız olur.
Başka bir değerlendirme, ajana bir UTC zaman damgası verir ve "bu benim için saat kaç?" diye sorar. Doğru davranış, komut dosyasını çalıştırmak ve sonucu alıntılamaktır. Yanlış davranış, dönüşümü zihinsel olarak yapmaktır. Değerlendirme hem yanlış cevabı HEM DE yanlış süreci yakalar, çünkü zihinsel matematik bu sefer doğru olsa bile, bir dahaki sefere yanlış olacaktır.
Bulduğum en dürüst değerlendirme buluşsal yöntemi: konuşma geçmişinizde "sıçtım" veya "ne" dediğiniz anları arayın. Bunlar kaçırdığınız test senaryolarıdır.
Adım 6: Çözümleyici tetikleyicisi
Bir çözümleyici (resolver), bağlam için bir yönlendirme tablosudur: X türünde bir görev göründüğünde, Y becerisini yükle. Çözümleyiciler hakkında ayrıntılı olarak burada yazdım. Her becerinin, ajana hangi becerilerin mevcut olduğunu ve ne zaman kullanılacağını öğreten dosya olan AGENTS.md'de bir tetikleyici girişine ihtiyacı vardır.
Çözümleyici tetikleyicileri, bir işaretleme tablosundaki satırlardan ibarettir:
Bu adımın yakaladığı hata: yeni bir beceri yazarsınız ancak onu çözümleyiciye eklemeyi unutursunuz. Beceri var. Yetenek var. Sistem ona ulaşamaz. Bu, kadroda bir cerrah bulundurmak ama onu hastane rehberine listelememek gibidir. Beceriye hiç sahip olmamaktan daha kötüdür, çünkü sistemin bunu hallettiğini düşünürsünüz.
Adım 7: Çözümleyici değerlendirmesi
Bu, çoğu insanın tamamen kaçırdığı katmandır. Bir çözümleyici tetikleyicisi "bu ifade bu beceriye yönlendirilmeli" der. Bir çözümleyici değerlendirmesi, bunun gerçekten olup olmadığını test eder.
Çözümleyici değerlendirme paketim şöyle 50'den fazla test senaryosuna sahiptir:
{ intent: 'imzalarımı kontrol et', expectedSkill: 'yönetici-asistanı' }, { intent: 'Pedro Franceschi kim', expectedSkill: 'beyin-operasyonları' }, { intent: 'bu makaleyi kaydet', expectedSkill: 'fikir-alma' }, { intent: 'toplantım saat kaçta', expectedSkill: 'context-now' }, { intent: '2016 seyahatimi bul', expectedSkill: 'calendar-recall' },
İki başarısızlık modu. Yanlış negatif: beceri ateşlenmeli ama ateşlenmez, çünkü tetikleyici açıklaması yanlış veya eksiktir. Yanlış pozitif: yanlış beceri ateşlenir, çünkü iki tetikleyici örtüşür. "Yarın takvimimde ne var" calendar-check'e yönlendirmeli, calendar-recall'a veya google-calendar'a değil. Üç beceri, üç farklı zaman alanı, herhangi biriyle makul ölçüde eşleşebilecek bir ifade. Çözümleyici değerlendirmesi, bir kullanıcı buna çarpmadan önce belirsizliği yakalar.
Bu değerlendirmeleri hem belirleyici yapısal testler (AGENTS.md tablosu doğru eşlemeyi içeriyor mu?) hem de LLM yönlendirme testleri (bu niyet verildiğinde, model gerçekten doğru beceriyi seçiyor mu?) olarak çalıştırıyorum. Her iki katman da önemlidir. Tablo doğru olabilir ve tetikleyici açıklaması belirsiz olduğu için model yine de yanlış yönlendirebilir.
Adım 8: Çözülebilirliği kontrol et + DRY denetimi
Bir aylık inşaattan sonra, 40'tan fazla becerim vardı. Bazıları belirli olaylara yanıt olarak oluşturuldu, diğerleri cron çalıştıran alt ajanlar tarafından doğdu. Çözümleyici tablosunu koruyan yoktu. Beceriler doğuyor ama kaydedilmiyordu.
Bu yüzden check-resolvable'ı inşa ettim. Tüm zinciri yürüyen bir meta-test: AGENTS.md çözümleyici → SKILL.md → komut dosyası/cron. Yararlı iş yapan ancak çözümleyiciden yolu olmayan bir komut dosyası varsa, ulaşılamaz durumdadır. LLM onu kullanmayı asla bilemez.
İlk çalıştırmada 40+ beceriden 6'sının ulaşılamaz olduğu bulundu. Sistemin yeteneklerinin yüzde on beşi karanlıktı.
- Uçuşlar hakkında sorarak kimsenin çağıramadığı bir uçuş takipçisi.
- Yalnızca cronda çalışan ancak manuel olarak tetiklenemeyen bir içerik fikri oluşturucu.
- Beceriler dizininde var olan ancak çözümleyicide hiç listelenmeyen bir alıntı düzeltici.
Bir saat içinde düzeltildi. AGENTS.md'ye tetikleyici girişleri eklendi. Artık check-resolvable, gbrain doctor'ın bir parçası olarak haftalık çalışıyor. Üç şeyi kontrol ediyor:
- SKILL.md'si olan her beceri dizininin çözümleyicide karşılık gelen bir girişi vardır.
- Bir beceri tarafından başvurulan her komut dosyası gerçekten çağrılabilir (dosya mevcut, doğru işlevleri dışa aktarır).
- Hiçbir iki beceri, belirsiz yönlendirmeye neden olacak örtüşen tetikleyici açıklamalarına sahip değildir.
DRY denetimi onunla birlikte çalışır. Dikkatli olmazsanız, aşağı yukarı aynı şeyi yapan on beş beceriniz olur ve çözümleyici zarın gösterdiğini seçer. calendar-recall için:
Aynı alanda dört beceri. Sıfır örtüşme. Her birinin kendi şeridi var. Bu matris bu yazı için çizilmiş bir diyagram değil. SKILL.md'nin içinde yaşıyor ve denetim komut dosyası onu ayrıştırıyor. Başka birinin şeridine basan altıncı bir takvim becerisi inşa edin ve beceri gönderilmeden önce denetim başarısız olur.
Adım 9: Uçtan uca duman testi
Tam boru hattı, uçtan uca.
- Ajana "Singapur'a ne zaman gittim?" diye sorun ve calendar-recall.mjs'yi çalıştırdığını, doğru cevabı aldığını ve doğru biçimlendirdiğini doğrulayın.
- "Bir sonraki toplantım saat kaçta?" diye sorun ve zihinsel matematik yapmak yerine context-now.mjs'yi çalıştırdığını doğrulayın.
Duman testleri son savunma hattıdır. Diğer her şey geçebilir ve parçalar bağlanmazsa sistem yine de başarısız olabilir. Beceri doğru olabilir, komut dosyası doğru olabilir, çözümleyici doğru olabilir ve ajan yine de tüm bunları görmezden gelip doğaçlama yapmayı seçebilir. Duman testi bunu yakalar.
Adım 10: Beyin dosyalama kuralları
Bilgi tabanına yazan her beceri, şeylerin nereye gideceğini bilmelidir. Bir kişi people/'ye gider. Bir şirket companies/'ye gider. Bir politika analizi civic/'ye gider. Beyin yazan 13 beceriden 10'unun, çözümleyiciye danışmak yerine her biri kendi yollarını sabit kodladığı için yanlış dizine dosyaladığını yakaladım.
Dosyalama kuralları belgesi, yaygın yanlış dosyalama desenlerini kataloglar. Kaynaklar vs. orijinaller. Kişiler vs. şirketler (birisi bir şirket OLDUĞUNDA). Beceri, herhangi bir sayfa oluşturmadan önce kuralları okur. O zamandan beri sıfır yanlış dosyalama.
GBrain: Skillify'ın yaşadığı yer ve bunu GBrain Skill Pack'imden benimsemelisiniz
Skillify deseni, OpenClaw'a veya herhangi bir özel koşuma özgü değildir. GBrain'in içine inşa edilmiştir. GBrain, hangi koşumu kullanırsanız kullanın onun altında oturan, açık kaynaklı bilgi motorudur. Beyin deponuzu yönetir, değerlendirmelerinizi çalıştırır ve becerileri dayanıklı kılan kalite kapılarını uygular.
Bir GBrain SkillPack, OpenClaw/Hermes Agent'tan yapmasını isteyerek herhangi bir ajan kurulumuna yükleyebileceğiniz, becerilerin, çözümleyici tetikleyicilerinin, belirleyici komut dosyalarının ve testlerin taşınabilir bir paketidir. OpenClaw/Hermes Agent'ım için yazdığım becerilerin ve yeteneklerin SİZİN OpenClaw'unuza otomatik olarak eklenebilmesi - 10 adımlı skillify çıktısının tamamı da dahil, OpenClaw/Hermes Agent'ınıza bırakabileceğiniz ve sadece çalışan bir paket halinde - işte böyledir.
Daha önceki skillify kontrol listesi bir öneri değildir. gbrain doctor'ın gerçekten kontrol ettiği şeydir.
gbrain doctor --fix, DRY ihlallerini otomatik olarak onarır, yinelenen blokları kural referanslarıyla değiştirir, tümü git çalışma ağacı kontrolleriyle korunur, böylece hiçbir şey ezilmez.
Hermes Agent'ın tek başına neden yeterli olmadığı
Nous Research'ten Hermes Agent gerçekten harika bir şey yapar: ajanın öğrendiklerine dayanarak kendisinin beceriler oluşturmasını, düzeltmesini ve silmesini sağlayan bir skill_manage aracına sahiptir. Ajan karmaşık bir görevi tamamladığında veya bir hatadan kurtulduğunda, bir beceri önerir ve onu diske yazar. Bu, ajanın kendi başına kazandığı prosedürel bellektir. Aşamalı ifşa (önce bir beceri dizini yükle, yalnızca seçildiğinde tam SKILL.md'yi çek). Sınırlı bellek (MEMORY.md 2.200 karakterle sınırlıdır). Koşullu aktivasyon (gerekli araçlar mevcut olmadığında beceriler otomatik olarak gizlenir). Akıllı tasarım.
Ancak Hermes, becerilerini test etmez. Belirleyici kodda birim testleri yok. Yönlendirmeyi doğrulamak için çözümleyici değerlendirmeleri yok. Karanlık becerileri bulmak için check-resolvable yok. Kopyaları yakalamak için DRY denetimi yok. Bir şey kaydığında kırmızıya dönen günlük sağlık kontrolü yok.
Test edilmemiş herhangi bir beceri sisteminde biriktiğini gözlemlediğim başarısızlık modları:
- Ajan Pazartesi deploy-k8s oluşturur. Perşembe günü farklı bir konuşmadan kubernetes-deploy oluşturur. Her ikisi de var. Her ikisi de benzer ifadelerle tetiklenir. Belirsiz yönlendirme ve yanlış olan yanlış zamanda ateşlenene kadar kimse fark etmez.
- Beceri yazıldığında mükemmel çalışır. Altı hafta sonra yukarı akış API'si şekil değiştirir. Beceri, bir insan fark edene kadar sessizce çöp döndürür.
- Otonom olarak oluşturulmuş bir beceri, asla eşleşmeyen zayıf bir tetikleyiciye sahiptir. Bir yetim haline gelir, dizin belirteçlerini yer, asla çalışmaz, yavaşça çürür.
Bu, yazılım mühendisliğinin 2005'te çözdüğü "testler olmadan, herhangi bir kod tabanı çürür" sorunudur. Ajan becerileri farklı değildir. Hermes oluşturmayı güzelce halleder. GBrain doğrulamayı halleder. İkisine de ihtiyacınız var.
Büyük fikir
Sağlıklı bir yazılım mühendisliği ekibinde, her hata bir test alır. Bu test sonsuza kadar yaşar. Hata yapısal olarak tekrarlanamaz hale gelir. AI ajanları da aynı şekilde çalışmalıdır.
Her hata bir beceri haline gelir. Her becerinin değerlendirmeleri vardır. Her değerlendirme günlük çalışır. Ajanın muhakemesi kalıcı olarak iyileşir, yalnızca geçerli oturum için değil, yalnızca bağlam penceresi tutulduğu sürece değil.
Seyahat hatası bir daha olmayacak. Saat dilimi hatası bir daha olmayacak. Ve bir sonraki hata ortaya çıktığında (ve ortaya çıkacak, çünkü bu entropiye ve zevke karşı bir rakip oyun), o da skillify edilecek.
Bir yıl sonra birlikte çalıştığım ajan, önceki yıl yaptığı her hatayla şekillenecek. Bu olması güzel bir şey değil. Bütün tez bu.
Okyanusu kaynatın. Ajanınıza bir şey yaptırın, sonra onu skillify edin. Bunu her gün yapın ve size istediğiniz her şeyi yapan kahrolası bir akıllı OpenClaw'unuz olsun.
Ya da sadece GBrain'i yükleyebilir, zaten yazdığım tüm kodu kullanabilir ve Iron Man'deki kendi Jarvis'inize daha erken geçebilirsiniz.
--
Claude Code'de hızlanmak için GStack github.com/garrytan/gstack
OpenClaw/Hermes Agent'da Iron Man'den kendi Jarvis'inizi oluşturmak için GBrain github.com/garrytan/gbrain
