Ajanınızın bağlamında her tool'a ihtiyacı yok

DynoTable'ın AI ajanı 38 tool'a erişebiliyor. Hepsini aynı anda nadiren görüyor. Modelin anında aldığı ile arayıp bulması gereken arasındaki çizgiyi nereye çektiğimiz, tüm tool setindeki en sonuç doğuran karar çıktı — ve çizgi, ilk koyduğumuz yerin hiç yakınında olmadı.

Model küçük bir setle başlasın ve gerisini arasın diye bir keşif mekanizması kurduk. Sonra ucuz modellerin onu nasıl kullandığını izledik ve 38 tool'un 27'sini her zaman görünür çekirdeğe geri taşıdık. Mekanizma hayatta kaldı. Kimin ona ihtiyacı olduğuna dair teorimiz kalmadı.

Aramaya gideceğine güvenilemeyecek modeller için bir tool yüzeyi kurarken öğrendiklerimiz şunlar.

Modelin hiç çağırmadığı bir tool bile size maliyet yazar

Açtığınız her tool; adı, açıklaması ve tam girdi şeması olarak, kullanıcı daha hiçbir şey yazmadan isteğin içine serileştirilir. Bunlardan 38 tanesi bedava değil.

Token'lar faturanın küçük yarısı. Asıl maliyet seçim isabeti: bir model ne kadar çok neredeyse-birebir seçenek tararsa, o kadar sık yanlışını seçer. Kataloğumuz bilerek neredeyse-birebir seçeneklerle dolu. Tool'larımızdan beşi iki kez var — openTable ve proposeOpenTable, openWorkbench ve proposeOpenWorkbench, ve devamı. Her çift aynı işi yapar; biri hemen yapar, diğeri kullanıcının önce tıkladığı bir çip üretir. Bu ayrım güvenliği için taşıyıcıdır ve düz bir isim listesinde neredeyse görünmezdir.

'ün kendi istemci rehberi tam da bu noktayla başlıyor: her tool tanımını baştan yüklemek token harcar, gecikme ekler ve modelin performansını düşürür. Buna katılmak kolay. İşin ilginçleştiği yer, hangi tool'ların koltuğunu kaybedeceğine karar vermek.

Bir arama tool'u kurduk. Taban model onu çağırmadı.

Mekanizma iki katmanlı. Bir tool kümesi ilk adımdan itibaren etkin. Gerisi, model searchTools(query) çağrısını yapana kadar görünmez; bu çağrı kataloğu adlar, açıklamalar ve anahtar kelimeler üzerinden puanlar, eşleşmeleri döndürür ve onları modelin sonraki adımlarda çağırmasına izin verilen tool kümesine ekler.

Sonra onu taban modelimize karşı çalıştırdık. Bu ajanı bir sınır modeline göre ayarlamıyoruz — kendi Bedrock kimlik bilgilerinizle çalışıyor, dolayısıyla insanlar ucuz modeller seçiyor ve biz de en ucuzuna göre optimize ediyoruz. Ekli bir dosya sorulduğunda o model, onun yerine açık sekme listesini eşelemeye gitti. Arama tool'unu neredeyse hiç çağırmadı. Doğrudan görünür olmayan hiçbir şey onun için var değildi.

Bu sonuç, apaçık tasarımı öldürüyor. Keşif, bir tool'a giden tek yolsa, o tool'a ihtiyaç duyan her istek modelin arayıp bulmayı seçmesine bağlı kalır — ve yardıma en çok ihtiyacı olan modeller, yardım isteme olasılığı en düşük olanlar.

Böylece bölünme "küçük çekirdek, büyük kuyruk" olmaktan çıktı ve tool'la değil istekle ilgili bir soruya dönüştü: kullanıcının ifadesi tool'un adını anıyor mu? Keşfedilebilir tuttuğumuz 11 tool, yanıtın evet olduğu tool'lar. "Bunu CSV'ye dışa aktar" bir modele export aratır. "Bana geçen ayın siparişlerini göster" ona bir filtre kurma tool'u aratmaz, dolayısıyla o satır içinde kalır. İndeks istatistikleri, kayıtlı spec'ler, ilişki introspeksiyonu ve hazırlanan değişiklik yüzeyleri; kullanıcının istediğinde adıyla sorduğu, asla örtük olarak istemediği şeyler.

Satır içinde 27 tool, önceden savunacağımız bir sayı değil. Fiilen yayınladığımız modelle temastan sağ çıkan sayı bu.

Keşfi sessizce işe yaramaz kılacak olan yarış durumu

Keşfin, yanlış yapması kolay, fark edilmesi zor bir zamanlama kısıtı var.

Arama tool'u eşleşmeleri döndürdüğünde, o adların modelin bir sonraki adımı hazırlanmadan önce izinli kümeye katılması gerekir. Bunu yapmak için apaçık yer, bir adım tamamlandığında tetiklenen hook. O hook'un bazı SDK sürümlerinde bir sonraki adımın hazırlığından sonra tetiklendiği belgelenmiş — yani değişiklik bir adım geç iner.

Hata biçimi kötü. Model arar. İhtiyaç duyduğu tool'u adıyla veren doğru bir sonuç alır. O tool'u hemen bir sonraki adımda çağırır ve kendisine tool'un var olmadığı söylenir. Aralıklı, hangi SDK sürümünü çözdüğünüze bağlı ve bozuk bir koşum takımı gibi değil, aptal bir model gibi okunuyor.

Çözüm, izinli kümeyi arama tool'unun kendi yürütmesi içinde değiştirmek; o yürütmenin döngü ilerlemeden önce tamamlanması garanti. Bu, bir ifadenin nerede durduğuna dair tek satırlık bir fark ve çalışan bir keşif mekanizması ile, zamanın bir kısmında kimsenin doğru atfedemeyeceği nedenlerle başarısız olan bir mekanizma arasındaki fark.

Üç arama, sonra dur

Arama, ajan turu başına 3 çağrıyla sınırlı. Dördüncüsü, çalışmak yerine şunu döndürür:

{"error": "search-budget-exhausted", "budgetCap": 3}

Sınır, belirli bir döngü yüzünden var: model arar, hayal ettiğini bulamaz, eşanlamlısıyla yeniden arar, onu da bulamaz ve veritabanına hiç dokunmadan tüm adım bütçesini arama tool'unun içinde yakar. Sınırlamak, daha fazla aramanın karşılığını vermeyi bıraktığı noktada bir karar dayatır — hâlihazırda bulunmuş tool'lardan birine bağlanmak ya da kullanıcıya sormak.

Bir model keşfetmediği bir tool'u çağırdığında dönen hata mesajı, ajandaki her doğrulayıcı için kullandığımız ilkeyi izler:

Tool 'startExport' not in active set. Call searchTools(query='startExport')
to discover it, or use one of: <inline tool names>

Kurtarma eylemini adıyla veren bir ret, fazladan bir adıma mal olur. Sadece hayır diyen bir ret, turun tamamına.

Tool başına tek satır, geri kalan her şey türetilmiş

Her tool tek bir düz listede bir kez bildirilir ve satır, tool'un tüm kimliğini taşır: adı ve açıklaması, aramanın eşleştiği anahtar kelimeler, satır içinde mi yoksa keşfedilebilir olarak mı başladığı, hangi katmanda çalıştığı ve MCP üzerinden nasıl açıldığı.

Bu katmanlar, görünürlük bölünmesi kadar önemli. 21 tool sessiz — kimseyi kesintiye uğratmadan çalışan okumalar. 16'sı yetkilendirme merdiveninin arkasında kapılı. Tam olarak biri hiçbirine ait değil, çünkü arama tool'u ajanın verinizde kullandığı bir yetenek değil; döngünün kendisinin bir parçası. MCP açılımı aynı satırdaki üçüncü eksen: salt okunur, hazırlama, tam ya da tamamen dışlanmış — ki üç tool öyle.

Bunu dürüst tutan kural şu: sistemdeki diğer her liste bu satırlardan türetilir — sessiz katman kümesi, MCP kapsam katmanları, yazma kapsamlı küme — ve hiçbiri elle bakım görmez. Elle tutulan bir sessiz listenin yanında elle tutulan bir MCP listesi, bir tool'un sohbette doğru şekilde kapılanıp harici bir istemciye sessizce açık kalmasının tam olarak yoludur.

Gelişini görmediğimiz kısıt, bildirim listesinin sıfır çalışma zamanı import'u içermesi gerektiği. Liste, masaüstü arayüzü ile arka uç arasında paylaşılıyor ve tek bir import, bir tool'un uygulaması üzerinden geçişli olarak yalnızca Node'da çalışan bir kripto bağımlılığına ulaşıyor. Bunu tarayıcı paketine çekin, uygulama modül yüklemede çöker. Ne tip denetleyici ne de birim testleri bunu yakalar — ikisi de import'u mutlu mesut çözer. Yakalayan şey, dosyayı metin olarak okuyup herhangi bir import ifadesinde başarısız olan bir test; sizi ilk kez kurtardığı ana kadar kaba geliyor.

Siz de bir tane kuruyorsanız neler aktarılabilir

Mimarinizi savunmadan önce tool'larınızı sayın. Doğru bölünme bir ölçümdür, bir ilke değil.
Keşfi en zayıf modelinize karşı test edin. Bir sınır modeli gerektiğinde arar; bu size kullanıcılarınızın seçtiği model hakkında hiçbir şey söylemez.
Görünürlüğe, kullanıcının kendi ifadesinin tool'un adını anıp anmadığına bakarak karar verin. Örtük olarak çağrılan tool'lar satır içine aittir; insanların adıyla istediği tool'lar bulunabilir.
Sıraya duyarlı bir şeyi bir adım hook'una koymadan önce, framework'ünüzdeki o hook'ların gerçekte ne zaman tetiklendiğini kontrol edin.
Meta-tool'lara sınır koyun. Gerçek duruma dokunmadan tekrar tekrar çağrılabilen her şey çağrılacaktır ve aramaya harcanan bir adım bütçesi, boşa giden bir turdur.
Keşfedilmemiş tool hatalarının, diğer her doğrulayıcı hatası gibi, kurtarma çağrısını adıyla vermesini sağlayın.
Her tool'u bir kez bildirin ve diğer her listeyi ondan türetin. Aynı tool'ların elle tutulan iki listesi eninde sonunda çelişir ve çelişki bir güvenlik sınırında ortaya çıkar.
Bir modül, derleyicinizin ifade edemediği taşıyıcı bir kısıt taşıyorsa, onu metin üzerinden dayatan o kaba testi yazın.

Bunlar nerede çalışıyor

Bunların tamamı DynoTable'ın tool kataloğu içinde yayınlanıyor — kendi kimlik bilgilerinizle şema farkındalıklı sorgulama ve yalnızca incelenebilir bir hazırlama alanına inen yazmalar. Aynı bildirimler, harici ajanların bağlandığı MCP sunucusunu sürüyor; orada her satırdaki açılım katmanı, harici bir istemciye verilen kapsama dönüşüyor. Bunu nasıl güvenli hâle getirdiğimiz — OAuth, onay, kimlik bilgisi yalıtımı — ayrı bir hikâye.

Ve hepsinin altındaki katman, bu tool'ların her birini ucuz bir modelin altından kalkabileceği hâle getiren doğrulayıcılar, kendi yazısının konusu.