Çatının içinde: bir dil modelini ajana dönüştüren çalışma ortamı

İki ekibe aynı dil modelini verin ve ikisinden de bir ajan kurmasını isteyin. Biri işleri bitiren, gerektiğinde duran ve okunabilir bir kayıt bırakan bir şey elde eder. Diğerinin ajanı döngüye girer, hedefini unutur ve ara sıra ürkütücü bir şey yapar. Model aynıdır; fark, etrafındaki her şeydedir. O çevre yazılımına ajan çatısı (harness) denir. Bu yazıda çatının neleri içerdiğini ve neden en az model kadar dikkati hak ettiğini anlatıyoruz.

İşe yarar bir tanım

Ajan çatısı, modelin ürettiği metni eyleme dönüştüren çalışma ortamıdır. Modelin ne göreceğine, hangi araçları çağırabileceğine, bir aracı çağırdığında ne olacağına, çalıştırmanın ne zaman duracağına ve neyin kayda geçeceğine o karar verir. Kısaca: model önerir, çatı karar verir.

Bir çatının altı görevi vardır.

1. Döngüyü çalıştırmak: bağlamı modele göndermek, yanıtı okumak, araç çağrılarını yürütmek, sonuçları geri beslemek, tekrarlamak.
2. Araçları sunmak: araçları modele tanıtmak, gönderdiği argümanları doğrulamak, aracı çalıştırıp çıktıyı döndürmek.
3. Bağlamı kurmak: her model çağrısına hangi talimatların, geçmişin, dokümanların ve bellek kayıtlarının gireceğini seçmek.
4. İzinleri uygulamak: istenen her eylemi serbest bırakmak, reddetmek ya da bir insanın kararına bekletmek.
5. Limitleri uygulamak: süre, adım, araç çağrısı, harcama ve çıktı boyutu.
6. Kayıt tutmak: her isteği, kararı, araç çalıştırmasını ve sonucu sırasıyla.

Terminaldeki kodlama ajanları, masaüstü asistanları, tarayıcı ajanları ve kurumsal iş akışı ürünleri, kimse bu adı kullanmasa da bir çatı içerir. Yapay zekâ ajanı tanımı ajanı dışarıdan anlatır; bu yazı içerideki mekanizmayla ilgili.

Kodda döngü

Özüne indirildiğinde her çatı aşağı yukarı şunu çalıştırır:

context = build_context(goal, instructions, memory)
while True:
    reply = model.generate(context)
    if reply.is_final:
        return finish(reply)              # önce kabul ölçütlerini kontrol et
    for call in reply.tool_calls:
        verdict = policy.check(call)      # izin ver, insana beklet ya da reddet
        if verdict.allowed:
            result = tools.run(call, timeout=verdict.timeout)
        else:
            result = verdict.explanation
        trail.record(call, verdict, result)
        context.append(call, result)
    if limits.exceeded(trail):
        return stop("limit aşıldı", trail)

Mühendisliğin çoğu yardımcı fonksiyonların içinde saklıdır. finish, nihai bir yanıtı kabul etmeden önce neyi kontrol ediyor? Bir araç hata verdiğinde model ne görüyor: yığın izi mi, kısa bir hata mesajı mı, yoksa hiçbir şey mi? Reddedilen bir çağrı, modelin üzerinde çalışabileceği bir açıklama olarak mı geri dönüyor, yoksa çalıştırma çöküyor mu? Hataları açıkça geri besleyen bir çatı modelin toparlanmasına izin verir. Onları yutan bir çatı ise bir limit durdurana kadar aynı bozuk çağrıyı tekrarlayan ajanlar üretir.

Araçlar: ajanın elleri

Bir araç modele bir ad, bir açıklama ve bir parametre şeması olarak ulaşır. Açıklama fiilen istemin (prompt) bir parçasıdır: belirsiz açıklamalar belirsiz araç kullanımı doğurur; açıklamaları örtüşen iki araç ise aralarında aşağı yukarı rastgele seçim yapan bir ajan üretir.

İyi çatılar her görev için araç listesini kısa tutar, bir şey çalıştırmadan önce argümanları doğrular, tek bir dev sonucun bağlamı doldurmaması için çıktıyı sınırlar ve kırpar, hataları modelin üzerine eylem yapabileceği bir biçimde döndürür. Araçlar çatıya gömülü olabilir, kabuk komutu olarak çalışabilir (bkz. CLI nedir) ya da MCP gibi bir protokol üzerinden harici sunuculardan gelebilir. Araç nereden gelirse gelsin onu çalıştıran çatıdır; dolayısıyla kullanımının denetlendiği yer de çatıdır.

Bağlam: model her turda ne görür

Model, çağrılar arasında hiçbir şey saklamaz. Çatı her turda girdiyi yeniden kurar: sistem talimatları, hedef, araç tanımları, o ana kadarki konuşma, araç sonuçları, getirilen dokümanlar ve saklanan bellek kayıtları. Uzun görevler bağlam penceresine sığmaz; bu yüzden çatı sıkıştırma yapmak zorundadır, genellikle eski adımları özetleyerek ya da hacimli araç çıktılarını atarak.

Bunun iyi gidip gitmeyeceğini iki ayrıntı belirler. Birincisi, özetler kanıta giden işaretçileri korumalıdır: dosyayı ve sayfayı vermeden "sözleşme kendiliğinden yenileniyor" diyen bir özet, bir bulguyu sessizce bir iddiaya dönüştürmüştür. İkincisi, bir araçtan gelen metin (bir web sayfası, bir e-posta, bir dosya) talimat olarak değil, veri olarak işaretlenmelidir. Çatı bu ikisini karıştırırsa bir dokümanın içindeki tek bir cümle ajanı yönlendirebilir. İstem enjeksiyonu (prompt injection) denen bu saldırı, büyük ölçüde modelin değil çatının sorunudur.

İzinler: güvene karar verilen yer

Model her şeyi isteyebilir. İsteğin karşılanıp karşılanmayacağına çatı karar verir ve bir demoyu canlıya alınabilir bir sistemden en çok ayıran kısım budur. İşe yarayan izin tasarımlarının birkaç ortak özelliği vardır.

• Her araç ya da eylemin bir modu vardır: serbestçe çalış, onay için beklet ya da reddet.
• Onaylayan kişi, modelin çağrıyı nasıl anlattığını değil, argümanlarıyla birlikte çağrının kendisini görür.
• Bir onay tek bir girişimi kapsar ve yürütme anında yeniden kontrol edilir; verilmiş bir evet sonradan tekrar kullanılamaz.
• Kimlik bilgileri referans olarak çatıda kalır, modelin bağlamına hiç girmez.
• Bir aracı bağlamak ile bir görevin onu kullanmasına yetki vermek ayrı kararlardır.

Duraklamayı hak eden eylem türleri alandan alana pek değişmez: dışarıya bir şey göndermek, silmek, veri dışa aktarmak, tekrarlanan bir iş zamanlamak, canlı bir oturumda işlem yapmak, ajanın kendi talimatlarını değiştirmek ve işi başka bir ajana devretmek. Yedi eylem sınıfı yazısı her birini ayrı ayrı açıklıyor.

Limitler, durma ve toparlanma

Limitsiz bir ajan da eninde sonunda durur: ya hedefe ulaştığı için ya da dışarıdaki bir şey tükendiği için. Çatı, bunun birincisi olmasını sağlamalıdır. Çalışma süresi, araç çağrısı, adım ve harcama üzerindeki zorunlu limitler, kontrolden çıkan çalıştırmaları kısa ve açıklanabilir duruşlara çevirir. Özellikle harcama tavanı sonradan bir uyarı göndermekle yetinmemeli, işi durdurup nedenini söylemelidir; ayrıntılar ajan harcamasına tavan koyun yazısında.

Uzun işler dayanıklılık da ister. Süreç yarıda ölürse iyi bir çatı baştan başlayıp ikinci bir e-posta gibi yan etkileri tekrarlamak yerine kaydedilmiş bir durumdan devam eder. Dayanıklı yürütme mümkün değilse dürüst yanıt, gerçekmiş gibi görünen bir ilerleme değil, görünür bir rettir. Son olarak, yeni işi anında durduran tek bir durdurma kontrolü olmalı; yeniden başlatmak ise bilinçli ve kime ait olduğu kayda geçen bir eylem olarak ele alınmalıdır.

Çatı neden en az model kadar önemli

İlginin çoğunu model seçimi toplar; oysa bir değerlendiricinin gerçekten sorduğu soruların birçoğunu tek başına çatı yanıtlar.

Modeller de kuralların değişmesi gerekenden daha sık değişir. Onaylarınız, limitleriniz ve denetiminiz tek bir model için ayarlanmış istem cümlelerinde değil de çatıda yaşıyorsa, model değiştiğinde olduğu gibi kalır. Bu savı model değişikliğinden etkilenmeyen yönetişim yazısı ayrıntılı biçimde işliyor.

Şirket işleri için bir çatı olarak GoCux

GoCux bu sorumlulukları bir şirket çalışma alanına taşır. Her iş; hedefi, dokunabileceği kapsamı ve kabul ölçütleri olan bir iş emridir; buna çalışma süresi ve araç çağrısı sınırları eklenir. İş emri sırada, çalışıyor, karar bekliyor ve tamamlandı durumlarından geçer. Sonuç doğuran eylemler, ekipten biri karar verene kadar karar bekliyor durumunda kalır; bir ret de kayda geçer ve işi serbest bırakmaz. Kimlik bilgileri tarayıcıda değil, sunucu tarafında referans olarak tutulur. İş, günlük bir tavanın altında görünür krediler harcar; tek bir durdurma kontrolü yeni işi ve dışarıya etkisi olan her şeyi keser; her adım ekibin okuyabileceği tek bir ize eklenir. Model yönlendirmesi servisin içindeki bir sınırın arkasında gerçekleşir; sizin denetlediğiniz kısım, iş emrine yazdıklarınızdır. İş emrini Görev sayfasında, onay kapısını yönetişim sayfasında görebilirsiniz.

Herhangi bir çatıya sorulacak sorular

• Bu görevde ajan hangi araçları çağırabiliyor ve bu listeye kim karar verdi?
• Hangi eylemler bir insan için bekletiliyor; onaylayan kişi çağrının tam hâlini görüyor mu?
• Bir onay, tek bir girişimden sonra geçerliliğini yitiriyor mu?
• Kimlik bilgileri nerede saklanıyor; model onları herhangi bir anda okuyabilir mi?
• Araçlardan gelen metin talimatlardan nasıl ayrı tutuluyor?
• Hangi limitler zorunlu ve ajan birine takıldığında ne raporluyor?
• Süreç yeniden başlarsa yarım kalmış bir çalıştırmaya ne oluyor?
• Reddedilen ve geri çevrilen adımlar dahil, bir çalıştırmanın tüm izini okuyabiliyor musunuz?

Bu soruların yanıtları, bir ajanın canlı ortamda nasıl davranacağı hakkında size bir model karşılaştırmasının söyleyebileceğinden fazlasını söyler.