Designing, refining, and maintaining agent skills at Perplexity

Perplexity’nin öncü ajan ürünleri, modüler Agent Skills (Ajan Yetenekleri) içinde paketlenmiş bir bilgi birikimi ve alan uzmanlığı temelinde yükselmektedir. Teknik ortamlarımızda özenle küratörlüğü yapılmış bir Skill kitaplığı bulunduruyoruz. Bu Skill'ler, Perplexity Computer'ı çalıştıran genel amaçlı araçların birçoğunu; finans, hukuk ve sağlık gibi dikey odaklı yetenekleri ve kullanıcı ihtiyaçlarını karşılamaya yönelik çok uzun kuyruklu modülleri içerir. Bazı Skill'ler nadiren çağrılır ancak çağrıldıklarında kritik önem taşır. Tutarlı bir şekilde mükemmel bir kullanıcı deneyimi sağlamak için Perplexity'nin Agents ekibi, en az kod kalitesi kadar Skill kalitesine de öncelik verir.

Yüksek kaliteli bir Skill geliştirmek için gereken sezgiler ve en iyi uygulamalar, geleneksel yazılım oluşturmak için gerekenlerden önemli ölçüde farklıdır. Agents ekibi, çalışmaları sırasında Skill geliştiren mükemmel mühendislerden gelen pek çok çekme isteğini (pull request) inceler. Sonuç neredeyse her zaman çok sayıda yorum ve düzeltme önerisidir. Bunun nedeni, kod yazmak için yararlı olan birçok kalıbın Skill oluşturmada anti-kalıba dönüşmesidir.

Örneğin, PEP20 – Python'un Zen'i felsefesinden bazı özdeyişleri ele alırsanız, iyi Python kodu yazmanın iyi Skill'ler yazmaya benzemediği hızla anlaşılır. 20 satırlık bilgelikten en az yarısı, Skill yazarken tamamen yanlıştır veya aktif olarak yanıltıcıdır. İşte bunlardan beşi:

Python’ın Zen’i ile makalede Skills yazımı için verilen yönergeler arasındaki beş karşıtlık.

Bu kılavuz, Perplexity genelindeki mühendislerin Skill'ler geliştirirken ve incelerken kullandığı belgedir. Ayrıca bu kılavuzu kamuoyuna sunuyoruz, böylece keşiflerimiz ve öğrendiklerimiz daha geniş topluluğa fayda sağlayabilir. İster günlük işlerinizde prodüksiyon ortamına yönelik Skill'ler tasarlayan bir mühendis olun, ister en iyi bildiğiniz bir alanda kendi Skill'inizi geliştirmek isteyen bir Computer kullanıcısı olun, ister her ikisi de; bu kılavuz sizin içindir.

Skill Nedir?

Bir Skill yazdığınızda, sıradan eski bir yazılım yazmıyorsunuz (Skill'ler artık ajan sistemlerinin ana mantıksal motorlarının bir parçası olsa bile). Aksine, modeller ve bunların ortamları için bağlam inşa ediyorsunuz. Bir Skill'in farklı kısıtlamaları ve farklı tasarım ilkeleri vardır. Bir Skill'i tıpkı kod yazar gibi yazarsanız başarısız olursunuz.

Bir Skill en az dört şeydir, özellikle de bunları Perplexity'de nasıl inşa ettiğimiz bağlamında.

Bir Skill Bir Dizindir

Bir Skill yalnızca tek bir SKILL.md dosyası değildir. Çoğu durumda bir Skill birkaç dosya içerir. Skill'inizin adını taşıyan dizinin altında şunlara sahip olabilirsiniz:

SKILL.md: ön bilgi (frontmatter) ve yönergeler

scripts/: ajanın yeniden icat etmek yerine çalıştırdığı kod

references/: koşullu olarak yüklenen ağır belgeler

assets/: şablonlar, şemalar ve veriler

config.json: ilk çalıştırmada kullanıcı kurulumu

Bu merkez-ve-uç (hub-and-spoke) modeli, Skill'leri çok odaklı ve derli toplu tutmanıza olanak tanır ve klasör yapısı çok yaratıcı bir şekilde kullanılabilir. Bazen özellikle karmaşık Skill'ler, modelin daha iyi gezinmesine yardımcı olmak için çok düzeyli hiyerarşilerden yararlanır. Varsayalım ki bir Skill, 20 konu alanında gruplandırılabilecek 300 konu genelinde bilgi gerektiriyor. 300 konu arasından doğru konuyu güvenilir bir şekilde seçmek, günümüzün en iyi öncü modelleri için bile çözülmemiş bir zorluktur. Bir model için bu alan içindeki 15 konu arasından seçim yapmak yerine, 20 alandan birine odaklanmak çok daha kolay bir seçim problemidir.

Çok düzeyli hiyerarşinin nasıl değer sağladığına dair bir örnek olarak ekibimiz, geçtiğimiz vergi sezonunda Computer'ın ABD gelir vergisi yeteneklerine güç sağlayan Skill'ler içinde üç düzeyli konu iç içe geçmesi kullandı. Vergi yasalarının karmaşıklığı göz önüne alındığında bu hiyerarşi kesinlikle vazgeçilmezdi: İlk testlerimizde, modele ABD İç Gelir Kanunu'nun (Internal Revenue Code) 1,945 bölümünün tamamını içeren tek bir klasör sunmak, Skill'i hiç yüklememekten daha kötü bir performansla sonuçlandı. Bilgileri mantıksal alt bölümlere ayırmak, yüksek hassasiyetli okuma işlemlerini garanti etmek için vazgeçilmezdi.

Yine de bu hiyerarşi bedelsiz gelmedi. Artan hiyerarşi düzeyleri, ortaya çıkan dolaylılığı yönetmek için bilgi mimarisi genelinde artan düzeyde küratörlük gerektirir. Modelin asgari dolaylılıkla bilgi bulmasını desteklemek için hızlı başvuru kılavuzları, özel arama araçları ve başka araçlar geliştirdik. Bu durumda, zorlu küratörlük çalışmasını yapmak nihayetinde olumlu bir sonuç doğurdu: modellerin vergiyle ilgili görevleri, yalnızca genel araçları kullanmaya kıyasla çok daha yetenekli bir şekilde gerçekleştirmesini sağlayan bir Skill.

Büyüt

Bir Skill Bir Biçimdir

Bir Skill bir biçimdir. Temel kök SKILL.md dosyası hem bir ad hem de bir açıklama içermelidir. Dahası, Skill, Skill'in bulunduğu dizin adı ile tam olarak eşleşmelidir. Ad, tamamen küçük harf karakterlerden oluşmalı, boşluk içermemeli ve kısa çizgiler kullanabilmelidir. Açıklama, yönlendirme tetikleyicisidir. Bu yaygın bir hata noktasıdır: açıklama, Skill'in ne yaptığına dair dahili bir belge değildir. Model için Skill'in ne zaman yükleneceğine dair yönergeler anlamına gelir. Bu nedenle, "Bu Skill şunu yapar" yerine sıklıkla "Şu duruma yüklü" ibaresini görürsünüz. Bu önemlidir çünkü çoğu uygulamanın açıklamayı model bağlamına enjekte etme biçiminden kaynaklanmaktadır.

Ön bilginin (frontmatter) içinde, hiyerarşik Skill bağımlılıkları oluşturmanıza olanak tanıyan “depends:” ve incelemeler ile değerlendirmeler için kullanılan “metadata:” de bulunur. Farklı ajan sistemleri bile, bu sistemlere özgü bir şekilde kullanılmak üzere kendi ön bilgi alanlarını tanımlayabilir. Alternatif olarak, Skill'e özel meta veriler yardımcı bir JSON veya YAML yapılandırma dosyasında paketlenebilir. Bu, modelin bağlamını ayrıntılarla kirletmeden her Skill başına farklı çalışma zamanı davranışı türlerini kolaylaştırması gereken ajan sistemleri oluştururken tercih edilir. Son olarak, okuma sırasında Skill ön bilgisi soyularak benzer bir davranış elde edilebilir. Computer, yapılandırmanın kök SKILL.md dosyasında korunmasına izin veren bu metodolojiyi kullanır. Ayrıştırma mantığında ayrıntılara dikkat edilmesi gerekir ve model bağlamında olması yararlı olan belirli alanlar varsa koşıllu soyma işlemi uygulamak isteyebilirsiniz.

Bir Skill Çağrılabilirdir

Bir Skill çağrılabilirdir. Ajan, çalışma zamanında bir Skill yükler. Önemli olarak, Skill'ler her zaman bağlama dahil edilmez. Varsayılan olarak, çoğu ajan sistemi Skill'leri belirli bir ihtiyaç doğrultusunda kademeli olarak açar.

Skill'leri Computer'da uygulama biçimimizde en az üç düzeyde bağlam maliyeti vardır. Süreç şöyledir:

Computer load_skill(name="...") çağrısı yapar

Computer, Skill dizinini izole edilmiş yürütme korumalı alanına kopyalar

Computer, “depends:” etiketindeki bağımlılıkları yinelemeli olarak otomatik yükler

Computer daha sonra ön bilgiyi soyar ve ajan böylece yalnızca gövdeyi ve ek dosyaları görür

Farklı ajan sistemleri, Skill içeriğini farklı şekillerde sunmayı seçebilir. Örnek olarak, bazı sistemler dosya hiyerarşisini hiç sunmamayı seçerek hiyerarşiyi dosya sistemi işlemleri aracılığıyla keşfetmeyi modele bırakabilir. Diğer sistemler ise modele belirli bir kesme ve/veya derinlik sınırına kadar tüm dosya ağacının bir haritasını vermeyi seçebilir. Bağlamı temiz tutmak için Computer, tam dosya hiyerarşilerini çağrı bağlamından çıkarır; ancak bu, Skill temelinde geçersiz kılınabilir.

Bir Skill Kademelidir

Skill'ler kademelidir. Computer'da bağlam maliyetlerinin üç farklı katmanı vardır ve biz çeşitli aşamalarda her üçüne de katlanırız:

Skill bağlamının üç düzeyi: indeks, tam Skill yüklemesi ve çalışma zamanı başvuru dosyaları.

Computer, mevcut her Skill için adı ve açıklamayı içeren bir Skill indeksi oluşturur. Bunun için bütçe Skill başına yaklaşık 100 tokendir (daha kısa olması daha de iyidir). Bu kadar dardır çünkü bu maliyeti her oturumda, her kullanıcı için ödüyorsunuz. Bu, konuşmanın en başında sistem istemine enjekte edilir. Model, “load_skill()” çağrısı yapıp yapmamaya karar verebilmesi için bir dizi adlandırılmış Skill'e ve açıklamaya erişebilir. Bu indekse girme çıtası son derece yüksektir. Skill'inizin çok yararlı olması gerekir ve açıklamanın son derece yoğun ve kısa olması gerekir çünkü herkes maliyeti her zaman ödemektedir.

Ajan sistemi Skill'i yükledikten sonra tam SKILL.md gövdesi gelir. İdeal olarak gövde metni 5.000 tokeni geçmez. Öyle bile olsa, her cümlenin önem taşımasını istersiniz çünkü bir kez bir Skill yüklediğinizde, sıkıştırma sınırına ulaşana kadar konuşmanın geri kalanı bunu ödemek zorundadır. Birçok konu (thread) üç ila beş farklı Skill arasında yükleme yapar ve bu maliyeti katlar. Çok fazla gereksiz bilgi içeren Skill'ler neredeyse kesinlikle diğer Skill'lerin yanı sıra genel ajan yeteneklerini de düşürecektir. Kısacası, Skill'iniz yükleniyorsa ve doğru şeyi yapmıyorsa, bu boşa harcanmış bağlamdır.

İlerlemenin son düzeyi betikler (scripts) veya alt yetenekler ya da biçimlendirme gibi özel durumlardır. Burası sınırsız koşullu dallara ayrılmış mantığı koymak istediğiniz yerdir. Ajan bunu yalnızca ihtiyaç duyduğunda kullanacaktır; bu, buraya koymak istediğiniz şeyler için çok daha düşük bir çıta olduğu anlamına gelir.

İndekste her token önemlidir. Yüklenen Skill gövdesi daha rahattır ve çalışma zamanı en rahatıdır. Bu 20.000 token veya sıfır token olabilir. Bu, modelin bağlamını kademeli bir şekilde genişletmeyi düşünebileceğiniz düzeydir.

Ne Zaman Bir Skill'e İhtiyacınız Olur?

Agents ekibine sık sık belirli bir alan veya kullanım durumu için gerçekten bir Skill'e gerek olup olmadığı konusunda fikir sorulur. Yalnızca ilk ilkelerden yola çıkarak kesin bir yanıtımız çok nadiren olur. Bunu gerçekten anlamanın tek yolu, ajanınızla Skill olmadan başlamak, birkaç kahraman sorgusu (hero query) çalıştırmak ve ardından ajanın iyi bir iş çıkarıp çıkarmadığını anlamaktır.

Bir Skill'e İhtiyacınız Olduğunda

Eğitilmiş modeller için dağılım içinde olan birçok görev vardır. Bu davranışınızı isteminizdeki örneğin tek bir cümleyle yapamayacağınız belirli bir şekilde değiştirmek istiyorsanız yalnızca bir Skill uygulamanız gerekir. Dolayısıyla, ajan özel bağlam olmadan bunu yanlış yapacaksa veya çalıştırımlar arasında son derece tutarlı olmasını sağlamanız gereken bazı tutarsızlıklar ya da belirleyici olmama durumları varsa bir Skill'e ihtiyacınız vardır.

Bilginiz kalıcı olabilir ancak eğitim verilerinde olmayabilir. Sınırlar veya kurumsal özel iş akışları olabilir ya da bir zevk meselesi olabilir. Örneğin, Computer'da tasarım ekibimizin başı olan Henry Modisett tarafından yazılmış tasarımla ilgili çeşitli Skill'lerimiz var. Bu Skill'lerde her tokenin var olmasının nedeni, Henry'nin web siteleri ve PDF'ler tasarlamak söz konusu olduğunda çok iyi bir zevke sahip olmasıdır. Henry hangi yazı tiplerinin kullanılacağını ve kullanılmayacağını, bu yazı tiplerinin nasıl hissettirdiğini ve modelin yalnızca eğitim verilerinden öğrenemeyeceği diğer yargı meselesi konuları belirtir.

Bir Skill'e İhtiyacınız Olmadığında

Mühendislerin sırayla yürütülmesi gereken bir dizi git komutu yazdığı birçok Skill görüyoruz. Bu gereksizdir çünkü model bunu nasıl yapacağını zaten bilir; bu da harika bir belgelendirme ama zayıf bir Skill ortaya çıkardığı anlamına gelir.

Skill'lerin sistem istemindeki yönergeleri yeniden özetlediği örnekler görüyoruz. Bunun için bir Skill'e ihtiyacınız yoktur. İsteklerin çoğunluğuyla ilgili bilgi, koşullu olarak yüklenen bir Skill'de değil, küresel bağlamda yer almalıdır

Bakımını yapabileceğinizden daha hızlı değişen bir şey varsa, bir Skill'e ihtiyacınız yoktur. Örneğin, uzak bir MCP uç noktasına vuruyorsanız ve araçları veya bu araçların sürümleri sık sık değişiyorsa, bunları bir Skill'e enjekte etmemelisiniz. Eğer yaparsanız, sonuçta sapma (drift) yaşarsınız ve model hatalar yapar.

Her Skill Bir Vergidir

Skill'inizdeki her cümleye uygulayabileceğiniz yararlı bir test şöyledir: “Ajan bu yönerge olmadan bunu yanlış yapar mıydı?” Cümlenin orada olması gerekmiyorsa, orada olmayı göze alamaz çünkü herkes bu maliyeti her seferinde ödemektedir. Bir Skill ekleyip eklememeye karar verirken, her oturumun ve her kullanıcının token maliyeti yarattığı bu vergiyi unutmayın.

Fransızca'da çok daha iyi kulağa gelen aşağıdaki ünlü söz, kabaca şu anlama gelir: “Bu mektubu yalnızca daha kısa tutacak zamanım olmadığından uzun yazdım.”

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

Pascal gibi siz de her Skill'e zaman yatırım yapmalısınız. Kısa bir Skill yazmak zordur. Skill'inizi yazmak kolaysa, muhtemelen çok uzundur veya hiç var olmamalıdır. İyi bir Skill olabildiğince kısadır.

Kendinizi tek atışta (one-shot) Skill üretmeye çalışırken ve beş dakikada PR'lar açarken bulursanız, sonuçlar neredeyse kesinlikle beklentinin altında olacaktır. Aslında erken dönem araştırmalar, Skill yazmak için LLM'ler kullanıyorsanız LLM'in bundan muhtemelen fayda görmeyeceğini göstermiştir: “Kendi ürettiği Skill'ler ortalama olarak hiçbir fayda sağlamaz; bu da modellerin tüketmekten fayda sağladıkları usule ilişkin bilgileri güvenilir bir şekilde yazamayacağını gösterir.”

Bir Skill Nasıl İnşa Edilir

Başka bir deyişle, yazdığınız herhangi bir Skill'e kendi görüşünüzü enjekte etmeniz gerekir. Şu adımları izleyin.

Adım 0: Değerlendirmeleri (Evals) Yazın

Önce bazı değerlendirmeleri (evals) yazın. Değerlendirme vakalarını şuradan temin edebilirsiniz:

Gerçek kullanıcı sorguları: prodüksiyondan veya fikir havuzunuzdan (brain trust) örneklem alın

Bilinen hatalar: Skill var olmadığı için ajan başarısız oldu

Komşu karışıklığı: Alan sınırınıza yakın ancak başka bir Skill'e yönlendiriyor

En azından, Skill'in gerektiğinde yüklendiğini test ettiğinizden emin olmalısınız. İdeal olarak, bunlardan bazılarını (belki de bir prodüksiyon ortamından) örnekleyebilirsiniz. Bilinen hata durumlarını da düşünebilirsiniz: belki de Skill'i yazmaya koyulmanızın tüm nedeni fark ettiğiniz belirli bir hatadır ya da yeniden yapılandırma (refactoring) yapıyorsunuzdur ve tek bir Skill tarafından kapsanan iki yakın alan arasında bazı kafa karışıklıkları vardır.

Benzer olumsuz ve olumlu örneklerle başlayın. Olumsuz örnekler son derece güçlüdür ve olumlu örneklerden daha önemli olabilir.

Adım 1: Açıklama

Bu, Skill'deki en zor satırdır. Belgelendirme değil, bir yönlendirme tetikleyicisidir. Adı ve açıklamayı doğru almak için Skill'in içeriğiyle ilgilenmezsiniz. Yalnızca Skill'in doğru noktalarda yüklenip enjekte edilip edilmediğiyle ve bir numaralı hata modu olan hedef dışı yan etkilerden arınmış olup olmadığıyla ilgilenirsiniz. Ekstra bir Skill eklediğiniz her seferinde, diğer tüm Skill'leri biraz daha kötü duruma getirme riski alırsınız, bu nedenle regresyonu en aza indirdiğinizden emin olmanız gerekir.

Yine, kötü bir açıklama Skill'in ne yaptığını veya neden yararlı olduğunu açıklar. İyi bir açıklama ajanın Skill'i ne zaman yüklemesi gerektiğini söyler. Örneğin, çekme isteklerini izlemek için bir şeyiniz olduğunu varsayalım. Skill'in ne yaptığını yazmayın. Mühendisler hayal kırıklığına uğradıklarında ve PR'larının çalışmasını istediklerinde söyledikleri şeyleri yazın; örneğin “babysit”, “watch CI” veya “make sure this lands” gibi.

İşte hızlı bir kontrol listesi:

"Load when..." ile başlar

50 kelime veya daha azını hedefleyin

İdeal olarak gerçek sorgulardan yola çıkararak kullanıcının niyetini tanımlar

İş akışını özetlemez

Gerçek sorgular 80-20 kuralında kapsayabileceğiniz şeylerdir. Genellikle iki veya üç örnek iyi sonuç verir. Tam olarak ve yalnızca ihtiyacınız olan kadarını eklemek kolay değildir.

Adım 2: Gövdeyi Yazın

Ardından, Skill'in içeriğini yazın. Bunun Adım 0 veya Adım 1 olmadığını unutmayın.

İş akışlarını bir LLM'e iletmek, iş akışlarını bir meslektaşınıza veya hatta çalışma zamanı sisteminize iletmekten tamamen farklıdır. Bir mühendis yeni bir yazılım aracını öğrenirken belgeleri okuması, deneyimli birinden rehberlik alması ve aracı nasıl kullanacağını öğrenmesi gerekebilir. Bu arada, en az bir yıldır var olan hemen hemen her yazılım aracı için adından bahsetmeniz yeterlidir ve LLM ihtiyacı olan tüm bilgilere sahip olur.

Gövdeyi yazarken bariz şeyleri atlayın. Birçok mühendis, birinin çalıştırması gereken her komutu listeleyen readme.md dosyaları yazma konusunda bolca deneyime sahiptir. Bir Skill yazarken buna geri dönmek kolaydır çünkü belgelendirme yazıyormuş gibi hissedersiniz, ancak bunu yaparsanız Skill'iniz çöp olur. Bu yüzden bir dizi komut yazmayın.

Örneğin, şunu yazmanıza gerek yoktur: “git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

Bunun yerine şunu yazın: “Commit'i temiz bir dala (branch) cherry-pick ile alın. Niyeti koruyarak çakışmaları çözün. Temiz bir şekilde birleştirilemiyorsa, nedenini açıklayın.”

Model, işler sarpa sardığında özellikle birincinin aşırı kuralcı komut dizilerine kıyasla ikincisiyle çok daha iyi bir iş çıkaracaktır. Katı kuralcı olmayın veya kırılgan olan aşırı kuralcılığa kaçmayın; bunun yerine birden fazla yaklaşımın işe yarayabileceği durumlarda esnek olun. Yine, insanlar için iyi olan belgeler çoğunlukla modeller için kötü belgelerdir.

Sonra tuzaklara (gotchas) veya olumsuz örneklere odaklanın. Bunlar son derece yüksek sinyalli içeriklerdir çünkü genellikle modele ne yapılmaması gerektiği konusunda rehberlik ederler. Ajan her takıldığında bir satır eklerseniz, çalıştırarak öğrenirsiniz ve tuzaklar organik olarak büyüyecektir.

Son olarak, koşullu olan veya içerik açısından son derece ağır olan herhangi bir bölüm varsa, bunu merkez olan SKILL.md'den çıkarın ve kollardan birine yerleştirin. Ardından dalacağımız, kademeli olarak yüklenebilecek yardımcı bir dosyaya koyun.

Adım 3: Hiyerarşiyi Kullanın

Bir betiğiniz, referanslarınız olduğunda veya belirli bir aracı kullandığınızda Skill hiyerarşisinden yararlanın:

Bir Skill içinde betikler, başvuru kaynakları, varlıklar ve yapılandırma için önerilen kullanım alanları.

Ana Skill'den koşullu olan veya dallanan herhangi bir şey için bunu bir klasöre ayırın. Ayrıca, özellikle karmaşık Skill'ler için çok düzeyli hiyerarşinin kullanılabileceğini unutmayın. Bunlar için işlevselliğin monolitik olarak mı yoksa bir Skill koleksiyonu olarak mı (muhtemelen depends: tabanlı yükleme ilişkileriyle) uygulanması gerektiği konusunda dikkatli bir şekilde düşünmeniz gerekecektir.

Adım 4: İlerleyin (Iterate)

Ardından bir dalda (branch) bir dizi yineleme yapın. Skill olmadan ana dalda başlayın, bazı yinelemeler yapın, kahraman sorgu kümenizi oluşturun ve bir dizi eval çalıştırın. Skill kodunuzu inceleyen herkes, bir değerlendirme kümesiyle tamamlanmış tek bir değişiklik kümesi gönderdiğiniz için size teşekkür edecektir. Ardışık artımlı değişiklikleri incelemek (yeni bir tuzak hariç) çok zordur, bu yüzden bunu en aza indirmeye çalışın.

Muhtemelen birçok küçük kelime değişikliği yapacaksınız. Açıklamalardaki küçük kelime değişikliklerinin yönlendirme üzerinde aşırı bir etkisi olabilir (diğer Skill'ler üzerindeki yayılma etkileri dahil), bu nedenle tüm bu çalışmaları Adım 5'ten önce yapın.

Adım 5: Yayınlayın (Ship)

Yayınlayın.

Bir Skill Nasıl Bakım Altına Alınır

Artık bir Skill yazdığınıza göre, bakımını yapmanız gerekir.

Tuzaklar Çarkı (The Gotchas Flywheel)

Bu noktadan sonra tuzak listesiniz büyümeye veya çok fazla değişmeye meyillidir. Örneğin değerlendirilmemiş (un-evaled) PR'lar yapan mühendislerin açıklamayı değiştirdiğini sıklıkla görüyoruz. Skill'iniz birleştirildikten sonra açıklamayı değiştiriyorsanız, yanlış yoldasınız demektir. Skill'inizi yönlendirip yönlendirmeyeceğine karar veren şeyde değişiklikler yapıyorsanız, değişiklikleri destekleyen bazı eval'ler yazmanız gerekir.

Skill'ler çoğunlukla eklemelidir (append-mostly). Tuzaklar bölümü zaman içinde en çok değeri biriktirir:

Ajan bir şeyde başarısız olur → Bir tuzak ekleyin

Ajan Skill'i hedef dışı yükler → Açıklamayı daraltın ve olumsuz eval'ler ekleyin

Ajan Skill'i gerektiğinde yüklemez → Anahtar kelimeler ve olumlu eval'ler ekleyin

Sistem istemi değişir → Çatışma veya yineleme olup olmadığını kontrol edin

Dahili testlerde veya prodüksiyonda tek bir hata durumunu fark edip bir tuzak eklemek kolaydır. Bu olumsuz bir örnektir, bu nedenle açık yönlendirmeyi gerçekten değiştirmez, ancak modele şunu bildirir: “Hey, bilinen şöyle bir hata var.”

%80-20'den %99,9 veya %99,99 başarı oranına doğru ilerlerken, bu tuzak listesini büyütmek kolaydır. Bu olumsuz örnekleri gördükçe, çoğunlukla tuzak bölümüne ekleme yapmalısınız. Daha uzun yönergeler eklememeli veya açıklamayı değiştirmemelisiniz.

Değerlendirme Süitleri (Eval Suites)

Perplexity'de farklı şeyleri kontrol etmek için birçok eval süiti çalıştırıyoruz. Skill yüklemenin hassasiyetini, geri çağrımını (recall) ve yasaklı kontrollerini denetleyen Skill yükleme ve Skill dosya okumaları vardır. Ajan, Skill'inizi yapması gerektiğinde yönlendirecek mi? Bunlar, yeni Skill'lerin mevcut sınırları bozmadığından emin olur.

Ayrıca uygun kademeli yüklemeyi kontrol edebilen eval'ler de vardır. Ajan Skill'i yükleyebilir, ancak aksesuar dosyayı veya dosyaları okuyor mu? Örneğin, finans sorguları için bir finans Skill'iniz varsa, özel FORMATTING.md dosyasını okuyor mu?

Ayrıca alanlar dahilinde uçtan uca görev tamamlama testleri yapan Skill eval'leri de vardır. Tam ajan döngüsünü çalıştırıyoruz ve iyi tanımlanmış kriterlerden oluşan bir değerlendirme ölçütüne (rubric) göre sonuçları derecelendirmek için bir LLM hakimi kullanıyoruz.

Son olarak, bu eval'leri farklı modellerle çalıştırmak önemlidir. Computer en az üç farklı düzenleme (orchestration) modeli ailesini destekler: GPT, Claude Opus ve Claude Sonnet. Farklı bir davranış elde etmediğinizden emin olmak için Skill yüklemenizi ve alan Skill'lerini bu farklı ajan düzenleyicilerine karşı çalıştırmak istersiniz. Sonnet ve GPT, Skill'ler söz konusu olduğunda oldukça farklı davranır.

Son düşünceler ve çıkarımlar

Ne kadar çok Skill inşa ederseniz, bunları inşa etmede o kadar iyi olursunuz. Günlük olarak yaptığınız görevleri otomatikleştiremiyor veya daha tekrarlanabilir hale getirmeye çalışmıyorsanız, Skill'leri kullanarak derhal başlayın.

Skill inşa etme eylemi, daha fazla Skill inşa etmede sizi daha iyi hale getirir, ayrıca iş süreçlerini otomatikleştirmede son derece iyidirler. Standup'ınızdan önce, her sprint'in sonunda her hafta yaptığınız bir şeyi veya bir mühendis olarak günlük, haftalık ve hatta üç aylık bazda yaptığınız herhangi bir şeyi tanımlayabiliyorsanız, zamanınızı geri satın almak için bir Skill yazmalısınız.

Postmortem'leri otomatikleştirebilir misiniz? Çekme isteklerini inceleyebilir misiniz? Yapabileceğiniz herhangi bir görev için en azından ilk geçişin bir Agent Skill olmasını sağlayabilirsiniz. Size önemli ölçüde zaman kazandıracaktır.

Bununla birlikte, bir Skill'in kolay olmadığını ve hatta her zaman gerekli olmadığını unutmayın. Az çoktur. Birkaç diğer çıkarım:

Skill'den önce eval'leri yazın. Bitişik ancak farklı Skill'ler için olumsuz örnekler ve yasaklı yüklemeler ekleyin.

Açıklama zor kısmı oluşturur. "Load when..." (her kelime dikkat maliyeti doğurur).

Tuzaklar son derece yüksek değerli içeriklerdir. İnce başlayın, ajan başarısız oldukça büyütün.

Yeni bir Skill ekleyerek önceden var olan diğer Skill'leri bozmanın, ona dokunmamış olsanız bile kolay olduğunu unutmayın (uzaktan etkiye dikkat edin).

Bir Skill yazarken ve bakımını yaparken her zaman mevcut tüm araçları kullanın. Daha fazla bilgi edinmek istiyorsanız, Agent Skills web sitesinde bolca iyi örnek vardır ve hem dahili depomuz hem de kamusal ekosistem iyi tasarlanmış Skill'lerin birçok örneğini barındırmaktadır.

Alıntı

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}