2.465 halka açık listelenmiş yapay zeka ajanı "becerisi" (skill) üzerinde yapılan yeni bir denetim, yarısından fazlasının yayınlanan spesifikasyonları ihlal ettiğini ve %7,8'inin gerekli meta verilerden yoksun olduğu için bir ajan tarafından seçilemediğini ortaya koydu. Bu kusurlar, bu becerileri otomatik olarak keşfeden ve yükleyen her türlü sistemin güvenilirliğini tehdit ediyor.

Denetim neden önemli

Ajan-beceri kayıt defterleri (registries), geliştiricilerin yeniden kullanılabilir yetenekler —otonom bir ajanın talep üzerine çağırabileceği kod paketleri— yayınlamasına olanak tanır. Bir ajan kayıt defterini tarar, her becerinin YAML frontmatter kısmını (en az bir isim ve açıklama içermesi gereken küçük bir yapılandırılmış metin bloğu) okur ve becerinin hedefleriyle eşleşip eşleşmediğine karar verir. Eğer frontmatter eksikse veya hatalı biçimlendirilmişse, beceri ajanın menüsünden kaybolur. Otonom ajanların toplantılar planladığı, sunucuları sorun giderme işlemlerini yaptığı ve daha fazlasını yaptığı bir dünyada, bozuk bir beceri iş akışını bozar.

Rakamlar neyi ortaya koyuyor

  • Becerilerin %57,8'i en az bir spesifikasyon ihlali içeriyor.
  • %29,2'si, kayıt defteri slug'ı (URL tanımlayıcısı) ile eşleşmeyen bir isim listeliyor.
  • %18,1'i bozuk paket yolları veya ölü bağlantılar içeriyor.
  • %7,8'i (192 beceri) hiçbir YAML frontmatter içermiyor, bu da onları isimsiz ve açıklamasız bırakıyor.
  • %3,8'i yalnızca yazarın makinesinde bulunan mutlak dosya yollarını içeriyor.
  • %2,4'ü allowed-tools alanını yanlış kullanarak ajanlar tarafından okunamaz hale getiriyor.
  • %2,1'i API anahtarlarını ortam değişkenleri (environment variables) aracılığıyla ifşa ediyor; bu bir güvenlik riskidir.
  • %1,3'ü harici komut satırı araçlarını beyan etmeden çağırarak taşınabilirlik kuralını ihlal ediyor.

Taşınabilirlik sorunu en sık karşılaşılan durumdur. /home/USER/.local/bin/tool gibi mutlak bir yol, beceriyi yazan geliştirici için çalışırken diğer tüm kullanıcılar için başarısız olur ve statik kontrollerin asla yakalayamayacağı çalışma zamanı (runtime) hatalarına neden olur.

Daha derin bir inceleme: openclaw vakası

Denetim ayrıca openclaw deposunda (repository) bulunan 46 beceriyi de inceledi. Yanlış alarmları bastırmak için test betiği (script) geliştirildikten sonra, incelemeci 59 gerçek kusur ortaya çıkardı; bu durum, aşırı agresif linter'ların ters tepebileceğine dair bir hatırlatmadır. Bir araç çok fazla zararsız sorunu işaretlediğinde, geliştiriciler onu kullanmayı bırakır ve gerçek sorunlar gözden kaçar.

openclaw kusurlarından ikisi, depoda artık var olmayan dosyalara işaret ediyordu. Bakımcı (maintainer), eksik referansları geri yükleyen bir düzeltmeyi birleştirdi (merge); bu da tek bir pull request'in bozuk bir bağımlılık zincirini nasıl temizleyebileceğini gösteriyor.

Geliştirici tepkileri

Denetçi, orijinal beceri depolarında "issue"lar açtı. Bir rapor reddedildi; bakımcı, "bozuk" kavramının statik dosya incelemesine göre değil, gerçek çalışma zamanı davranışına göre değerlendirilmesi gerektiğini savundu. Denetçi, bozukluk tanımının katı bir şekilde becerinin pratikte nasıl çalıştığıyla uyumlu olması gerektiği konusunda hemfikir oldu. Başka bir sorun ise kabul edildi ve ilgili düzeltme şu an yayında.

Kimler kazanacak — veya kaybedecek

  • Ajanlar ve son kullanıcılar, kayıt defteri yalnızca uyumlu ve taşınabilir beceriler içerdiğinde daha sorunsuz ve öngörülebilir bir davranış deneyimi yaşarlar.
  • Beceri yazarları, yayınlanmadan önce hataları yakalayan daha net doğrulama kurallarına sahip olur ve böylece sorun ayıklama (issue triage) sürecindeki git-geller azalır.
  • Kayıt defteri operatörleri, daha sıkı doğrulama süreçleri (pipelines) oluşturmalı veya entegre etmelidir; bunlar olmadan ekosistemin güven kaybı riski vardır.

Gevşek doğrulama, üretim ortamındaki (production) ajanları bozabilecek "hızlı ve özensiz" gönderimleri teşvik ederek potansiyel olarak maliyetli kesintilere veya güvenlik açıklarına neden olabilir.

Karşı görüş: Tüm ihlaller ölümcül mü?

Bazıları belirli "hataların" zararsız olduğunu savunuyor. Eşleşmeyen bir isim, becerileri görüntülenen isim yerine slug üzerinden seçen bir ajanı etkilemeyebilir. API anahtarlarının ortamdan (environment) okunması, yerel geliştirme için bilinçli bir tasarım tercihi olabilir. Ancak denetimdeki yüzdeler, spesifikasyondan herhangi bir sapmayı ihlal olarak kabul ediyor; bu da bazı sorunların pratik etkisini olduğundan fazla gösterebilir.

Sırada ne var?

  • Gerçek taşınabilirlik hatalarını zararsız tuhaflıklardan ayıran gelişmiş linter'lar.
  • Gerekli frontmatter'dan yoksun olan veya mutlak yollar içeren gönderimleri reddeden kayıt defteri tarafındaki doğrulama kancaları (validation hooks).
  • Gizli kusurları üretim aşamasındaki ajanlara ulaşmadan önce ortaya çıkaran topluluk odaklı denetimler.
  • allowed-tools gibi belirsiz alanları netleştiren ve ortam değişkenlerinin kabul edilebilir kullanımını tanımlayan potansiyel spesifikasyon revizyonları.

Araç setlerinin bir sonraki dalgası, muhtemelen bu kontrolleri sürekli entegrasyon (continuous-integration) süreçlerine dahil ederek, uyumluluğu manuel bir sonradan düşünme eyleminden otomatik bir eşiğe dönüştürecektir.

Özet

Kamuoyuna açık listelenen yapay zeka ajanı becerilerinin çoğunluğu temel uyumluluk kontrollerinden geçemiyor ve azımsanmayacak bir kısmı hiç seçilemiyor bile. Bulgular; daha sıkı doğrulama, daha iyi linting araçları ve spesifikasyonlara bağlılığı yayınlamak için bir ön koşul olarak gören bir topluluk kültürüne duyulan açık ihtiyacı vurguluyor. Bu güvenlik önlemleri hayata geçirilene kadar, ajanlar kırılgan ve taşınamaz beceriler yüzünden tökezlemeye devam edecek.

Kaynak: https://dev.to/hyuga611/i-audited-2465-published-agent-skills-192-of-them-cannot-be-selected-the-way-the-spec-says-4k70