Komut satırı (CLI) nedir, ajanlar onu neden bu kadar iyi kullanır?

Komut satırı arayüzü, bilgisayara ne yapacağını söylemenin en eski yolu; bugün ise yapay zekâ ajanlarının iş bitirmesinin en önemli yollarından biri hâline geldi. Kodlama ajanları testleri koşturur, logları okur ve değişiklikleri terminal üzerinden commit eder; operasyon ajanları bulut hesaplarını aynı yolla sorgular. Bu yazıda CLI'ın ne olduğunu, ajanlara neden bu kadar iyi uyduğunu ve bir ajanın sizin adınıza komut yazmasına izin verdiğinizde nelerin ters gidebileceğini anlatıyoruz.

CLI nedir

CLI, metinle yönetilen bir programdır. Adını yazarsınız, ne istediğinizi anlatan argümanlar eklersiniz, program da size metinle yanıt verir. Tıklanacak bir pencere ya da ekranda saklı bir durum yoktur: istek de yanıt da karakter satırlarından ibarettir.

Burada üç kavram sık karıştırılır. Terminal, metni gösteren penceredir. Kabuk (bash, zsh, PowerShell), bu pencerenin içinde yazdıklarınızı okuyan, joker karakterleri ve değişkenleri açan, başka programları başlatan programdır. CLI ise o başka programların her biridir: git, curl, grep, bir paket yöneticisi ya da bir bulut sağlayıcısının komut satırı aracı. "Ajan CLI kullanıyor" dendiğinde genellikle kastedilen, ajanın bir kabuğa komut satırı gönderip dönen çıktıyı okuyabilmesidir.

$ git log --oneline -n 3 -- src/billing
a41c2e9 Handle missing invoice address
7be0d13 Round tax per line, not per invoice
f09a6c1 Add credit note export

Bir komutun anatomisi

Her komut satırı aşağı yukarı aynı dilbilgisine uyar ve her parçası ajana işe yarar bir şey söyler.

Hepsini birbirine bağlayan şey borudur (pipe). grep -r "TODO" src | wc -l bir programın çıktısını sonrakine aktarır; böylece küçük araçlar, kimsenin ayrıca program yazmadığı soruların yanıtına dönüşür. Komut satırının bu kadar çok grafik aracı geride bırakmasının asıl nedeni bu birleştirilebilirliktir.

Ajanlar CLI ile neden iyi çalışır

Bir dil modeli metin okur ve metin yazar. CLI metin alır ve metin döndürür. Cazibenin büyük kısmını bu uyum açıklar, ama daha somut nedenler de var.

• Kendini tanıtma. Neredeyse her araç --help çağrısına yanıt verir. Tanımadığı bir komutla karşılaşan ajan, kimse önceden şema yazmadan kullanım bilgisini okuyup yeniden deneyebilir.
• Tanıdıklık. git, curl ve grep gibi yaygın araçlar açık dokümantasyonda ve kodda çok sık geçer; modeller bu araçların olağan bayraklarını ve hata mesajlarını zaten bilir.
• Net bir başarı sinyali. Çıkış kodu, döngüye kontrol edilecek tartışmasız bir sonuç verir; bir ekran görüntüsünün "doğru görünüp görünmediğine" karar vermekten çok daha güvenilirdir.
• Birleştirme. Borular, yönlendirmeler ve küçük betikler sayesinde ajan, birinin yeni bir özellik eklemesini beklemeden tam ihtiyaç duyduğu sorguyu kurabilir.
• İstendiğinde yapılandırılmış çıktı. Modern CLI'ların çoğu --json ya da bir biçim bayrağı sunar; serbest metin, ajanın tahmin yürütmeden ayrıştırabileceği veriye dönüşür.
• Yeni bir şey inşa etmeye gerek yok. Bir sistemin zaten CLI'ı varsa ajan onu bugün kullanabilir. Özel bir araç entegrasyonu ya da protokol sunucusu ise yazılması ve bakımı gereken ek koddur.

"Ajana bir kabuk verelim, yeter" fikrinin bu kadar çekici olmasının nedeni bu son madde. Ekipler artık aynı iş için CLI'ı bir MCP sunucusuyla ya da paketlenmiş bir beceriyle karşılaştırıyor. Bu seçimi MCP, beceri ya da CLI karşılaştırmasında ele alıyoruz; bir CLI'ı beceriye dönüştürmek yazısı ise bir CLI'ı ajanın izleyebileceği talimatlarla nasıl saracağınızı gösteriyor.

CLI'lar ajanı nerede zorlar

CLI'lar klavye başındaki insanlar için tasarlandı ve bu tasarımın bazı alışkanlıkları ajanın aleyhine işler.

• Etkileşimli istemler. Proceed? [y/N] gibi bir onay sorusu, bir sayfalayıcı ya da giriş istemi hiç gelmeyecek bir girdiyi bekler ve çalıştırma takılı kalır. Etkileşimsiz bayrakları tercih edin, her komuta bir zaman aşımı koyun.
• Fazla çıktı. Ayrıntılı bir derleme logu ajanın bağlamını doldurup hedefi görüş alanının dışına itebilir. Modele ulaşan kısmı sınırlayın; logun tamamını ajanın içinde arama yapabileceği bir dosyada tutun.
• Yanıltıcı çıkış kodları. grep hiçbir şey bulamadığında sıfırdan farklı bir kodla çıkar; bu bir hata değildir. Bazı araçlar ise önemli bir uyarı bastıktan sonra sıfırla çıkar.
• Tırnaklama ve platform farkları. bash'te çalışan bir komut PowerShell'de bozulabilir; adında boşluk olan bir dosya tek argümanı ikiye bölebilir.
• Sürümden sürüme değişen çıktı. İnsan için yazılmış metni ayrıştırmak kırılgandır; araç sunuyorsa yapılandırılmış bir biçim çok daha kararlıdır.

Ajana komut çalıştırtmanın riskleri

Kabuk, içine yazan kişiye çalıştığı hesabın tüm yetkisini verir. Onu bir ajana teslim etmek, o hesabın yapabildiği her şeyi, kimsenin istemediği şeyler dahil, ajanın da yapabilmesi demektir. Riskler birkaç grupta toplanır.

1. Yıkım. Dosya silmek, paylaşılan bir dalın üzerine zorla push etmek, bir tabloyu düşürmek, bulut kaynaklarını sonlandırmak. Tek bir yanlış yol ya da joker karakter yeter.
2. Verinin dışarı çıkması. Tek bir curl çağrısı bir dosyayı herhangi bir yere gönderebilir. Bir paketin kurulum betiği ya da ajanın kendi başına eklediği bir git uzak deposu da aynısını yapabilir.
3. Sırların açığa çıkması. Ortam değişkenlerini yazdırmak, bir .env dosyasını okumak ya da anahtar klasörünü listelemek, kimlik bilgilerini ajanın bağlamına ve loglarına kopyalar.
4. Enjekte edilen talimatlar. Ajan kendi yazmadığı metinleri okur: bir README, bir issue yorumu, bir web sayfası, bir log satırı. O metin "şu komutu çalıştır" diyorsa iyi korunmayan bir ajan buna uyabilir.
5. Tedarik zinciri. Adı yanlış yazılmış bir paketi kurmak ya da indirilen bir betiği doğrudan kabuğa aktarmak, başkasının kodunu sizin yetkilerinizle çalıştırır.
6. Harcama. Bulut ve SaaS komut satırı araçları, çalıştırma bittikten çok sonra da para yakmaya devam eden kaynaklar oluşturabilir.

Ön ek üzerinden kurulan izin listesi yaygın ama aldatıcı bir güvencedir. git ile başlayan her şeye izin vermek git push --force komutuna da izin vermek demektir; bazı git seçenekleri keyfi programlar bile başlatabilir. ls komutuna izin vermek ise birleşik komutlar parça parça ayrıştırılıp değerlendirilmiyorsa ls; rm -rf build satırını da geçirir.

Gerçekten işe yarayan korumalar

Tek bir kontrol yetmez; işe yarayanlar üst üste biner.

• Yalıtım. Ajanın kabuğunu bir konteynerde, bir sanal makinede ya da yalnızca tek bir çalışma klasörüne erişen ayrı bir hesapta çalıştırın; ev klasörünüzde değil.
• Önce salt okuma. Yalnızca inceleme yapan komutlarla başlayın; erişimi gerçek çalıştırmaları izledikten sonra genişletin. Bkz. ajanlara salt okumayla başlayın.
• Kesin izin listeleri. Belirli komutları ve alt komutları onaylayın, birleşik satırları ayrıştırın, sınıflandıramadığınız her şeyi reddedin.
• Sonuçlardan önce duraklama. Silme, push, dağıtım, gönderme, kurulum ve dışa aktarma; komutun özetini değil tam satırını gören bir insanı beklemeli.
• Her girişim için ayrı onay. Bir push'a evet demek, oturumun geri kalanındaki her push'a evet demek olmamalı.
• Sırlar referansla. Kimlik bilgilerini mümkün olduğunca ajanın ortamının dışında tutun; dalgın bir env çağrısı hiçbir şey göstermesin.
• Limitler ve kayıt. Zaman aşımları, çıktı sınırları ve komut sayısı için bir tavan koyun; her komutu çıkış koduyla birlikte kaydedin.

Politika olarak yazıldığında şu kadar sade olabilir:

izin   git status, git diff, git log          salt okuma, onay yok
izin   npm test                              yalnız depo içinde, 10 dk zaman aşımı
sor    git commit, git push                  önce komutun tamamını göster
sor    paket deposu dışındaki her ağ çağrısı
yasak  çalışma klasörü dışında rm
yasak  .env dosyaları, ~/.ssh, ~/.aws okuma

Böyle bir politikayı uygulayan program modelin değil, ajan çatısının bir parçasıdır. Modelden yıkıcı komutlardan kaçınması kibarca istenebilir; onları gerçekten reddedebilen tek şey çatıdır.

GoCux komut çalıştıran işi nasıl ele alır

GoCux, web çalışma alanının yanında bir müşteri CLI'ı da sunar. Yerel araçlar ve onlara bağlı izinler, kendi makinenizde bu CLI tarafından yönetilir. İşin kendisi yine bir iş emridir: bir hedef, bir kapsam ve kabul ölçütleri; üstüne çalışma süresi ve araç çağrısı sınırları. Araç çağrısı sınırını sıfıra çekerseniz iş hiç araç çağırmaz.

Bir adım; bir şeyi yok etmek, dışarıya bir şey göndermek ya da veri dışa aktarmak gibi sonuç doğuran eylem sınıflarından birine girdiğinde iş durur ve ekipten birinin kararını bekler. Yıkıcı adımlar, imzalı bir karar gelene kadar engelli kalır. Bekletilen çağrı ajanın istediği hâliyle birebir gösterilir; onaylayan kişi gerçek isteği görür. Karar yalnızca o tek girişim için geçerlidir ve adım çalışacağı anda yeniden kontrol edilir. Her adım iş emrinin kaydına düşer. İş emrini Görev sayfasında, onay kapısını ve denetim izini yönetişim sayfasında, aynı kuralların koda nasıl uygulandığını yazılım geliştirme sayfasında bulabilirsiniz.

Bir ajana kabuk vermeden önce

• Ajan, tek bir çalışma klasörüne erişen yalıtılmış bir ortamda mı çalışıyor?
• İzin verilen her komut tek tek listelenmiş mi; birleşik satırlar parça parça ayrıştırılıp değerlendiriliyor mu?
• Yıkıcı, dışarıya giden ve kurulum yapan komutlar, komutun tamamını gören bir insan için duruyor mu?
• Bir onay, oturumun geri kalanını değil yalnızca tek bir girişimi mi kapsıyor?
• Kimlik bilgileri ajanın ortamından ve çıktısından uzak tutuluyor mu?
• Her komutun bir zaman aşımı var mı; uzun çıktı sınırlanıp bir dosyaya kaydediliyor mu?
• Hangi komutların hangi sırayla ve hangi çıkış kodlarıyla çalıştığını sonradan okuyabiliyor musunuz?
• Ajanın dosyalardan, issue'lardan ve web sayfalarından okuduğu metin talimat olarak değil, veri olarak mı ele alınıyor?

Hepsine evet diyebiliyorsanız kabuk, bir ajana verebileceğiniz en yetenekli araçlardan biridir. Diyemiyorsanız daha dar bir komut setiyle başlayın ve kayıtlar güveninizi kazandıkça genişletin.