Goose CLI varsayılan olarak tool çağrılarını otomatik onaylıyor; Amp onayları kendi terminaline hapsediyor

İki kodlama ajanı CLI'sını, Goose ve Amp'ı, birden fazla ajan çalıştıran tek bir araca bağlayan bir geliştirici, en büyük dersin ajan protokolleriyle ilgisi olmadığını söylüyor — asıl konu onay varsayılanlarıydı. dev.to'da yayımlanan bir yazıya göre Goose, açık bir mod belirtilmeden başlatıldığında tool çağrıları için kendine izin veriyor; yani izinler konusunda sessiz kalan bir sarmalayıcı, insan onayı olmadan komut çalıştıran bir ajana kavuşuyor.

Aksi söylenmedikçe Goose tool'ları çalıştırıyor

Yazıda, Goose'un varsayılan modunun tool çağrılarının otomatik onayını etkinleştirdiği açıklanıyor. Bu yüzden agent'ı bir mod belirtmeden başlatan herhangi bir sarmalayıcı, onu çalıştıran kişinin ne varsaydığına bakmaksızın tamamen otonom yürütmeye ulaşıyor. Bu boşluğu kapatmak için yazar artık çalıştırıcısındaki her süreç için modu kendisi belirliyor ve kullanıcının Goose yapılandırmasında ne olduğuna güvenmiyor. Bu eşlemede default, accept-edits ve auto adlı modların hepsi Goose'un onay moduna yönlendiriliyor; böylece her tool çağrısı önce bir insana soruluyor. Otomatik onay yalnızca açıkça bypass olarak adlandırılan moda ayrılıyor ve süreç bazlı bu geçersiz kılma, kullanıcının kendi Goose ayarlarına dokunmuyor.

Dosya okuyamayan bir salt-sohbet modu

Yazıdaki ikinci sürpriz Goose'un salt-sohbet moduyla ilgili: Bu mod salt-okunur tool'lar dahil tüm tool'ları kapatıyor. Ona bir "plan" modu eşlerseniz sonuç, konuşabilen ama sözde planladığı dosyaları açamayan bir ajandır — çoğu insanın bir planlama modundan beklediğinin tam tersi.

Amp yalnızca kendi terminaline yanıt veriyor

Amp çok farklı davranıyor. Yazının belirttiğine göre Amp'ın akış çıktısı, harici bir sürecin bir onay istemine yanıt vermesi için belgelenmiş bir mekanizma sunmuyor; dolayısıyla onaylar Amp'ın çalıştığı terminale hapsoluyor. Bu, orkestratörler için yapısal bir sorun: Ajanı çalışırken izleyebiliyorlar ama dışarıdan bir tool çağrısına evet ya da hayır diyemiyorlar. Amp'ın plan ve don't-ask modları salt-okunur olanlar dahil her tool'u reddediyor ve yalnızca bypass modu otomatik onayı açıyor. Sonuç olarak bir sarmalayıcı, hiçbir şey yapmayan bir ajansız ya da her şeyi gözetimsiz yapan bir ajansız arasında seçim yapmak zorunda; etkileşimli onay için bir orta yol yok.

Önce boş dizin, sonra entegrasyon

Yazarın herhangi bir agent CLI'sı için yeni rutini şöyle: Onu bir şeye bağlamadan önce boş bir dizinde bir kez başlatın ve ilk kez tool çağırmak istediğinde ne yaptığına bakın. İki ajan iki çok farklı yanıt üretmiş ve her iki durumda da davranış bariz bir yerde belgelenmemiş. Bu bulgular, yazarın birden fazla kodlama ajanını çalıştırmak için geliştirdiği Styx adlı araç üzerindeki çalışmadan çıkmış.

Neden önemli

Ajan CLI'ları giderek artan biçimde insanlar değil, başka yazılımlar tarafından — orkestratörler, sarmalayıcılar, CI işleri, zamanlanmış görevler — başlatılıyor. Bu kurulumlarda varsayılan onay davranışı fiilen güvenlik sınırıdır: Çağıran taraf açıkça bir mod sabitlemezse, komutların incelemesiz çalışıp çalışmayacağına ajanın fabrika varsayılanı karar verir. Kendine izin veren bir ajan, bir prompt enjeksiyonu ya da yanlış yorumlanmış bir talimatla birleştiğinde gözetimsiz kod yürütmeye dönüşür. Pratik çıkarım Goose ve Amp'ın çok ötesine genellenebilir: İzinleri ampirik olarak, süreç bazında, ilk günden itibaren doğrulayın — çünkü "önce sorar" ile "önce davranır" arasındaki fark nadiren belgelerin ilk sayfasında görünür.