Merancang, menyempurnakan, dan memelihara agent skills di Perplexity

Produk agen frontier Perplexity didasarkan pada landasan pengetahuan dan keahlian domain yang dikemas dalam modular Agent Skills. Kami memelihara perpustakaan Skill yang dikurasi secara cermat di seluruh lingkungan teknis kami. Skill ini mencakup banyak utilitas serbaguna yang mendukung Perplexity Computer; kapabilitas khusus vertikal di bidang seperti keuangan, hukum, dan kesehatan; serta ekor panjang modul yang sangat besar untuk memenuhi kebutuhan pengguna. Beberapa Skill jarang dipanggil tetapi sangat penting ketika dipanggil. Untuk memastikan pengalaman pengguna yang sangat baik secara konsisten, tim Agen Perplexity memprioritaskan kualitas Skill sama seperti kualitas kode.

Intuisi dan praktik terbaik yang diperlukan untuk mengembangkan Skill berkualitas tinggi sangat berbeda dari yang diperlukan untuk membangun perangkat lunak tradisional. Tim Agen meninjau banyak pull request dari para insinyur luar biasa yang mengembangkan Skill dalam rangka pekerjaan mereka. Hasilnya hampir selalu berupa banyak komentar dan saran untuk revisi. Ini karena banyak pola yang berguna untuk menulis kode menjadi antipola dalam pembuatan Skill.

Misalnya, jika Anda mengambil beberapa aforisme dari PEP20 – The Zen of Python, akan segera menjadi jelas bahwa menulis kode Python yang baik tidak sama dengan menulis Skill yang baik. Dari 20 baris kebijakan tersebut, setidaknya separuhnya sepenuhnya salah atau secara aktif menyesatkan saat menulis Skill. Berikut adalah lima di antaranya:

Lima kontras antara Zen of Python dan panduan artikel untuk menulis Skill.

Panduan ini adalah dokumen yang digunakan oleh para insinyur di Perplexity saat mengembangkan dan meninjau Skill. Kami juga merilis panduan ini ke publik agar penemuan dan pembelajaran kami dapat bermanfaat bagi komunitas yang lebih luas. Baik Anda seorang insinyur yang merancang Skill produksi dalam pekerjaan sehari-hari, pengguna Computer yang ingin mengembangkan Skill Anda sendiri di bidang yang paling Anda kuasai, atau keduanya, panduan ini cocok untuk Anda.

Apa itu Skill?

Saat Anda menulis Skill, Anda tidak sedang menulis perangkat lunak biasa (meskipun Skill sekarang menjadi bagian dari mesin logis utama untuk sistem agen). Sebaliknya, Anda sedang membangun konteks untuk model dan lingkungannya. Sebuah Skill memiliki batasan yang berbeda dan prinsip desain yang berbeda. Jika Anda menulis Skill seperti Anda menulis kode, Anda akan gagal.

Sebuah Skill memiliki setidaknya empat hal, terutama dalam konteks bagaimana kami membangunnya di Perplexity.

Sebuah Skill adalah Direktori

Sebuah Skill bukan hanya satu file SKILL.md. Dalam banyak kasus, sebuah Skill mencakup beberapa file. Di bawah direktori yang dinamai sesuai Skill Anda, Anda mungkin memiliki:

SKILL.md: frontmatter dan instruksi

scripts/: kode yang dijalankan agen, bukan yang diciptakan kembali

references/: dokumen berat, dimuat secara kondisional

assets/: templat, skema, dan data

config.json: penyiapan pengguna saat pertama kali dijalankan

Pola hub-and-spoke ini memungkinkan Anda menjaga Skill tetap fokus dan rapat, dan seseorang dapat menggunakan struktur folder dengan cara yang sangat kreatif. Terkadang, Skill yang sangat rumit mendapatkan manfaat dari beberapa tingkat hierarki untuk membantu model menavigasi dengan lebih baik. Misalkan sebuah Skill memerlukan pengetahuan di 300 topik, yang dapat dikelompokkan ke dalam 20 area subjek. Memilih topik yang tepat secara andal di antara 300 topik merupakan tantangan yang belum terpecahkan bahkan untuk model frontier terbaik saat ini. Ini adalah masalah pilihan yang jauh lebih mudah bagi model untuk fokus pada satu dari 20 area, daripada di antara 15 topik dalam area tersebut.

Sebagai salah satu contoh bagaimana hierarki multilevel memberikan nilai, tim kami menerapkan tiga tingkat penelusuran topikal dalam Skill yang mendukung kapabilitas pajak penghasilan AS Computer pada musim pajak lalu. Hierarki ini sangatlah penting mengingat kompleksitas hukum pajak: dalam pengujian awal kami, menyajikan model dengan satu folder yang berisi semua 1.945 bagian Kode Pendapatan Internal AS menghasilkan performa yang lebih buruk daripada tidak memuat Skill sama sekali. Mengorganisasikan informasi ke dalam subdivisi logis sangat penting untuk memastikan operasi pembacaan berpresisi tinggi.

Namun hierarki ini tidak datang secara gratis. Peningkatan tingkat hierarki memerlukan peningkatan tingkat kurasi di seluruh arsitektur informasi untuk mengelola indirection yang dihasilkan. Kami merancang panduan referensi cepat, utilitas pencarian kustom, dan alat lainnya untuk mendukung model dalam menemukan informasi dengan indirection minimum. Dalam kasus ini, melakukan kerja keras kurasi pada akhirnya menghasilkan hasil akhir yang positif: sebuah Skill yang memungkinkan model melakukan tugas terkait pajak dengan jauh lebih cakap daripada menggunakan alat umum saja.

Perbesar

Sebuah Skill adalah Format

Sebuah Skill adalah format. File akar inti SKILL.md harus memiliki nama dan deskripsi. Selain itu, Skill harus dipetakan secara tepat ke nama direktori tempat Skill tersebut berada. Nama harus berupa karakter huruf kecil semua, tidak menggunakan spasi, dan dapat menggunakan tanda hubung. Deskripsi adalah pemicu perutean. Ini adalah titik kegagalan yang umum: deskripsi bukanlah dokumentasi internal untuk apa yang dilakukan Skill. Deskripsi ini setara dengan instruksi untuk model mengenai kapan harus memuat Skill. Jadi, Anda akan sering melihat “Load when,” bukan “This Skill does.” Ini penting karena cara sebagian besar implementasi menyuntikkan deskripsi ke dalam konteks model.

Di dalam frontmatter, terdapat juga “depends:”, yang memungkinkan Anda membuat dependensi Skill hierarkis, dan “metadata:”, yang digunakan untuk ulasan dan evaluasi. Sistem agen yang berbeda bahkan dapat menentukan bidang frontmatter mereka sendiri, untuk digunakan dengan cara yang khusus untuk sistem tersebut. Sebagai alternatif, metadata khusus Skill dapat dikemas dalam file konfigurasi JSON atau YAML tambahan. Ini diinginkan saat membangun sistem agen yang perlu memfasilitasi berbagai jenis perilaku waktu proses per Skill tanpa mencemari konteks model dengan detail kecil. Terakhir, perilaku serupa dapat diperoleh melalui penghilangan frontmatter Skill saat dibaca. Computer menggunakan metodologi ini, yang memungkinkan konfigurasi dipertahankan dalam file akar SKILL.md. Perhatian yang cermat terhadap detail diperlukan dalam logika penguraian, dan seseorang mungkin ingin menerapkan penghilangan bersyarat jika ada bidang tertentu yang berguna untuk dimiliki dalam konteks model.

Sebuah Skill Bersifat Dapat Dipanggil

Sebuah Skill dapat dipanggil. Agen memuat Skill pada waktu proses. Yang penting, Skill tidak selalu digabungkan ke dalam konteks. Secara default, sebagian besar sistem agen membuka Skill secara progresif berdasarkan kebutuhan spesifik.

Ada setidaknya tiga tingkat biaya konteks dalam cara kami menerapkan Skill di Computer. Berikut adalah prosesnya:

Computer memanggil load_skill(name="...")

Computer menyalin direktori Skill ke dalam kotak pasir eksekusi terisolasi

Computer secara rekursif memuat otomatis dependensi di tag “depends:”

Computer kemudian menghapus frontmatter sehingga agen hanya melihat isi bodi dan file tambahan

Sistem agen yang berbeda dapat memilih untuk mengekspos konten Skill dengan cara yang berbeda. Sebagai contoh, beberapa sistem mungkin memilih untuk tidak mengekspos hierarki file sama sekali, menyerahkannya kepada model untuk menemukan hierarki melalui operasi sistem file. Sistem lain mungkin memilih untuk memberi model pemetaan dari seluruh pohon file hingga batas pemotongan dan/atau kedalaman tertentu. Untuk menjaga konteks tetap bersih, Computer menghilangkan hierarki file lengkap dari konteks pemanggilan; namun, ini dapat ditimpa per Skill.

Sebuah Skill Bersifat Progresif

Skill bersifat progresif. Di Computer, terdapat tiga tingkat biaya konteks yang berbeda, dan kami menanggung ketiga tingkat tersebut pada berbagai tahap:

Tiga tingkatan konteks Skill: indeks, muatan penuh Skill, dan berkas referensi runtime.

Computer membangun indeks Skill yang memiliki nama dan deskripsi untuk setiap Skill yang tersedia. Anggaran untuk ini adalah sekitar 100 token per Skill (lebih pendek bahkan lebih baik). Ini sangat ketat karena Anda membayar biaya ini di setiap sesi, untuk setiap pengguna. Ini disuntikkan ke dalam prompt sistem pada awal percakapan. Model memiliki akses ke sekumpulan nama dan deskripsi Skill sehingga dapat memutuskan apakah akan memanggil “load_skill()”. Ambang batas untuk masuk ke indeks ini sangat tinggi. Skill Anda harus sangat berguna, dan deskripsinya harus sangat padat dan ringkas karena semua orang menanggung biayanya sepanjang waktu.

Setelah sistem agen memuat Skill, terdapat bodi SKILL.md yang lengkap. Idealnya, teks bodi tidak melebihi 5.000 token. Bahkan saat itu, Anda ingin setiap kalimat berarti karena begitu Anda memuat Skill, sisa percakapan harus membayarnya sampai Anda mencapai batas kompaksi. Banyak utas memuat antara tiga dan lima Skill yang berbeda, melipatgandakan biaya ini. Skill dengan banyak materi tambahan yang tidak perlu hampir pasti akan menurunkan kualitas Skill lain serta kapabilitas agen secara keseluruhan. Singkatnya, jika Skill Anda dimuat dan tidak melakukan hal yang benar, itu adalah konteks yang terbuang sia-sia.

Tingkat progres terakhir adalah skrip atau kasus khusus, seperti subskill atau pemformatan. Di sinilah Anda ingin menempatkan logika bercabang bersyarat yang tidak terbatas. Agen hanya akan menggunakannya saat diperlukan, yang berarti ada ambang batas yang jauh lebih rendah untuk apa yang ingin Anda masukkan di sini.

Dalam indeks, setiap token itu penting. Bodi Skill yang dimuat lebih longgar, dan waktu proses adalah yang paling longgar. Ini bisa berupa 20.000 token atau nol token. Ini adalah tingkat di mana Anda mungkin berpikir untuk memperluas konteks model secara progresif.

Kapan Anda membutuhkan Skill?

Tim Agen sering kali diminta untuk memberikan pendapat tentang apakah sebuah Skill benar-benar diperlukan untuk domain atau kasus penggunaan tertentu. Sangat jarang kami memiliki jawaban pasti dari prinsip-prinsip dasar saja. Satu-satunya cara untuk benar-benar mengetahuinya adalah dengan memulai agen Anda tanpa Skill, menjalankan beberapa kueri andalan, dan kemudian mencari tahu apakah agen tersebut melakukan pekerjaannya dengan baik.

Saat Anda membutuhkan Skill

Ada banyak tugas yang ada dalam distribusi untuk model yang dilatih. Anda hanya perlu menerapkan Skill jika Anda ingin mengubah perilaku tersebut dengan cara tertentu yang tidak dapat Anda lakukan dengan, katakanlah, satu kalimat dalam prompt Anda. Jadi, Anda memerlukan Skill jika agen akan salah melakukannya tanpa konteks khusus, atau jika ada inkonsistensi atau non-deterministik yang Anda perlukan agar sangat konsisten di berbagai eksekusi.

Bisa jadi pengetahuan Anda bersifat tahan lama tetapi tidak ada dalam data pelatihan. Mungkin ada batas waktu atau alur kerja khusus perusahaan, atau bisa juga masalah selera. Misalnya, kami memiliki beberapa Skill terkait desain di Computer yang ditulis oleh Henry Modisett (kepala desain kami). Alasan setiap token ada dalam Skill tersebut adalah karena Henry memiliki selera yang sangat baik dalam hal mendesain situs web dan PDF. Henry menentukan font mana yang harus digunakan dan font mana yang tidak boleh digunakan, bagaimana font tersebut terasa, dan masalah penilaian lain yang tidak dapat dipelajari model dari data pelatihan saja.

Saat Anda tidak memerlukan Skill

Kami melihat banyak Skill di mana para insinyur telah menulis serangkaian perintah git yang perlu dieksekusi secara berurutan. Itu tidak perlu karena model sudah tahu cara melakukannya, yang berarti itu membuat dokumentasi yang bagus tetapi Skill yang buruk.

Kami melihat contoh di mana Skill merekapitulasi instruksi dari prompt sistem. Anda tidak memerlukan Skill untuk itu. Pengetahuan yang relevan untuk sebagian besar permintaan harus disertakan dalam konteks global, bukan dalam Skill yang dimuat secara kondisional

Jika ada sesuatu yang berubah lebih cepat daripada yang dapat Anda pertahankan, Anda tidak memerlukan Skill. Misalnya, jika Anda mengakses beberapa titik akhir MCP jarak jauh dan alat-alatnya atau versi alat tersebut sering berubah, Anda sebaiknya tidak menyuntikkannya ke dalam Skill. Jika Anda melakukannya, Anda hanya akan berakhir dengan penyimpangan dan model akan membuat kesalahan.

Setiap Skill adalah pajak

Berikut adalah ujian berguna yang dapat Anda terapkan pada setiap kalimat di Skill Anda: “Apakah agen akan salah memahami ini tanpa instruksi ini?” Jika kalimat tersebut tidak perlu ada di sana, kalimat tersebut tidak boleh ada di sana karena setiap orang menanggung biaya ini setiap saat. Saat Anda memutuskan apakah akan menambahkan Skill atau tidak, ingatlah pajak ini di mana setiap sesi dan setiap pengguna memerlukan biaya token.

Kutipan terkenal berikut, yang terdengar jauh lebih baik dalam bahasa Prancis, secara kasar diterjemahkan menjadi “Saya hanya membuat surat ini lebih panjang karena saya tidak punya waktu untuk membuatnya lebih pendek.”

« 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

Sama seperti Pascal, Anda perlu menginvestasikan waktu di setiap Skill. Sangat sulit menulis Skill yang singkat. Jika Skill Anda mudah ditulis, itu mungkin terlalu panjang atau seharusnya tidak ada. Skill yang baik adalah sesingkat mungkin.

Jika Anda mendapati diri Anda mencoba membuat satu kali pembuatan Skill dan mengunggah PR dalam lima waktu menit, hasilnya hampir pasti akan di bawah standar. Faktanya, penelitian awal telah menunjukkan bahwa jika Anda menggunakan LLM untuk menulis Skill, LLM tersebut mungkin tidak akan mendapat manfaat darinya: “Skill yang dibuat sendiri tidak memberikan manfaat rata-rata, menunjukkan bahwa model tidak dapat secara andal mengarang pengetahuan prosedural yang mereka peroleh dari konsumsi.”

Cara membangun Skill

Dengan kata lain, Anda perlu menyuntikkan pendapat Anda ke dalam setiap Skill yang Anda tulis. Ikuti langkah-langkah ini.

Langkah 0: Tulis Evaluasi

Tulis beberapa evaluasi terlebih dahulu. Anda dapat mencari kasus evaluasi dari:

Kueri pengguna nyata: sampel dari produksi atau kelompok tepercaya Anda

Kegagalan yang diketahui: Agen gagal karena Skill tersebut tidak ada

Kebingungan tetangga: Dekat dengan batas domain Anda tetapi merute ke Skill lain

Paling tidak, Anda harus memastikan bahwa Anda menguji apakah Skill tersebut dimuat saat diperlukan. Idealnya, Anda mengambil beberapa sampel ini, mungkin dari lingkungan produksi. Anda juga dapat mempertimbangkan kasus kesalahan yang diketahui: mungkin seluruh alasan Anda mulai menulis Skill adalah karena kegagalan tertentu yang Anda perhatikan atau mungkin Anda melakukan refactoring dan ada kebingungan di dua domain dekat yang dicakup oleh satu Skill.

Mulai dengan contoh negatif dan positif yang serupa. Contoh negatif sangat kuat dan dapat lebih penting daripada contoh positif.

Langkah 1: Deskripsi

Ini adalah baris paling sulit dalam Skill. Ini adalah pemicu perutean, bukan dokumentasi. Untuk mendapatkan nama dan deskripsi yang benar, Anda tidak peduli dengan isi Skill. Anda hanya peduli apakah Skill dimuat dan disuntikkan pada titik yang tepat dan bebas dari efek samping di luar target, yang merupakan mode kegagalan nomor satu. Setiap kali Anda menambahkan Skill tambahan, Anda berisiko membuat setiap Skill lainnya sedikit lebih buruk, jadi Anda harus memastikan bahwa Anda meminimalkan regresi.

Sekali lagi, deskripsi yang buruk menjelaskan apa yang dilakukan Skill atau mengapa itu berguna. Deskripsi yang baik menyatakan kapan agen harus memuat Skill tersebut. Misalnya, katakanlah Anda memiliki sesuatu untuk memantau pull request. Jangan menulis apa yang dilakukan Skill. Tulis apa yang dikatakan para insinyur ketika mereka frustrasi dan mereka ingin Anda memastikan bahwa PR mereka berfungsi, seperti “mengasuh” atau “menonton CI” atau “pastikan ini mendarat.”

Berikut adalah daftar periksa cepat:

Dimulai dengan "Muat ketika..."

Targetkan 50 kata atau kurang

Menjelaskan niat pengguna, idealnya dari kueri nyata

Tidak merangkum alur kerja

Kueri nyata adalah apa yang dapat Anda cakup dalam aturan 80-20. Biasanya, dua atau tiga contoh bekerja dengan baik. Tidak mudah untuk menambahkan secara tepat dan hanya sebanyak yang Anda butuhkan.

Langkah 2: Tulis Bodi

Selanjutnya, tulis konten Skill itu sendiri. Perhatikan bahwa ini bukan Langkah 0 atau Langkah 1.

Mengkomunikasikan alur kerja ke LLM sepenuhnya berbeda dengan mengkomunikasikan alur kerja ke rekan kerja, atau bahkan ke sistem waktu proses Anda. Saat mempelajari alat perangkat lunak baru, seorang insinyur mungkin perlu membaca dokumentasi, mendapatkan panduan dari seseorang yang berpengalaman, dan mempelajari cara menggunakan alat tersebut. Sementara itu, untuk hampir semua alat perangkat lunak yang telah ada setidaknya selama setahun, Anda hanya perlu menyebutkan namanya dan LLM memiliki semua informasi yang dibutuhkannya.

Saat Anda menulis bodi, lewati hal-hal yang sudah jelas. Banyak insinyur memiliki banyak pengalaman menulis file readme.md yang mencantumkan setiap perintah yang perlu dijalankan seseorang. Sangat mudah untuk kembali ke hal itu ketika Anda menulis Skill karena terasa seperti Anda sedang menulis dokumentasi, tetapi jika Anda melakukan itu, Skill Anda akan menjadi sampah. Jadi, jangan menulis serangkaian perintah.

Misalnya, Anda tidak perlu menulis, “git log # temukan commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

Sebagai gantinya, tulis, “Cherry-pick commit ke cabang yang bersih. Selesaikan konflik dengan mempertahankan niat. Jika tidak dapat mendarat dengan bersih, jelaskan alasannya.”

Model akan melakukan pekerjaannya dengan jauh lebih baik dengan cara yang kedua daripada rangkaian perintah yang terlalu direktif dari cara pertama, terutama ketika segala sesuatunya salah. Jangan mendikte secara berlebihan, atau terlalu direktif, yang rapuh, dan sebaliknya bersikaplah fleksibel di mana beberapa pendekatan dapat berhasil. Sekali lagi, dokumentasi yang baik untuk manusia paling sering adalah dokumentasi yang buruk untuk model.

Selanjutnya, fokuslah pada jebakan atau contoh negatif. Ini adalah konten bersinyal sangat tinggi karena sering kali memandu model dalam hal apa yang tidak boleh dilakukan. Jika Anda menambahkan baris setiap kali agen tersandung, Anda akan belajar dengan menjalankannya dan jebakan tersebut akan tumbuh secara organik.

Terakhir, jika ada bagian yang bersyarat atau sangat berat dalam konten, keluarkan dari SKILL.md, yang merupakan hub, dan masukkan ke salah satu spoke. Masukkan ke dalam file aksesori yang dapat dimuat secara progresif, yang akan kita bahas selanjutnya.

Langkah 3: Gunakan Hierarki

Manfaatkan hierarki Skill ketika Anda memiliki skrip, referensi, atau Anda menggunakan beberapa alat khusus:

Penggunaan yang disarankan untuk skrip, referensi, aset, dan konfigurasi dalam sebuah Skill.

Untuk apa pun yang bersifat bersyarat atau bercabang dari Skill utama, pecah menjadi sebuah folder. Ingatlah juga bahwa hierarki multilevel dapat digunakan untuk Skill yang sangat rumit. Untuk ini, Anda harus memikirkan dengan cermat apakah fungsionalitas harus diterapkan secara monolitik atau sebagai kumpulan Skill (mungkin dengan hubungan pemuatan berbasis depends:).

Langkah 4: Iterasi

Selanjutnya, lakukan banyak iterasi pada cabang. Mulai di cabang utama tanpa Skill, lakukan beberapa iterasi, bangun set kueri andalan Anda, dan jalankan banyak evaluasi. Siapa pun yang meninjau kode Skill Anda akan berterima kasih karena Anda telah mengirimkan satu set perubahan lengkap dengan set evaluasi. Meninjau perubahan inkremental berturut-turut (kecuali jebakan baru) sangatlah sulit, jadi cobalah untuk meminimalkannya.

Anda mungkin akan melakukan banyak perubahan kata kecil. Perubahan kata kecil dalam deskripsi dapat berdampak besar pada perutean (termasuk efek limpahan pada Skill lain), jadi lakukan semua pekerjaan itu sebelum Langkah 5.

Langkah 5: Kirim

Kirim.

Cara Memelihara Skill

Sekarang setelah Anda menulis Skill, Anda harus memeliharanya.

Flywheel Jebakan

Sejak saat ini, daftar jebakan Anda cenderung bertambah atau banyak berubah. Kami sering melihat insinyur yang membuat PR yang belum dievaluasi, misalnya, mengubah deskripsi. Jika Anda mengubah deskripsi setelah Skill Anda digabungkan, Anda berada di jalur yang salah. Jika Anda membuat perubahan pada hal yang memutuskan apakah akan merute Skill Anda, Anda perlu menulis beberapa evaluasi yang mendukung perubahan tersebut.

Skill pada dasarnya bersifat tambah-saja. Bagian jebakan mengakumulasikan nilai paling banyak dari waktu ke waktu:

Agen gagal pada sesuatu → Tambahkan jebakan

Agen memuat Skill di luar target → Perketat deskripsi dan tambahkan evaluasi negatif

Agen tidak memuat Skill saat seharusnya → Tambahkan kata kunci dan evaluasi positif

Perubahan prompt sistem → Periksa pertentangan atau duplikasi

Sangat mudah untuk melihat satu kasus kegagalan dalam pengujian internal atau dalam produksi dan menambahkan jebakan. Ini adalah contoh negatif sehingga tidak benar-benar mengubah panduan eksplisit, tetapi ini memberi tahu model, “Hei, ada kegagalan yang diketahui ini.”

Saat Anda beralih dari 80-20 ke pencapaian tingkat keberhasilan 99,9% atau 99,99%, sangat mudah untuk memperbesar daftar jebakan ini. Saat Anda melihat contoh negatif ini, Anda harus menambahkan sebagian besar ke bagian jebakan. Anda seharusnya tidak menambahkan instruksi yang lebih panjang atau mengubah deskripsi.

Suite Evaluasi

Di Perplexity, kami menjalankan banyak suite evaluasi untuk memeriksa berbagai hal. Ada pemuatan Skill dan pembacaan file Skill, yang memeriksa presisi, perolehan, dan pemeriksaan terlarang dari pemuatan Skill itu sendiri. Apakah agen akan merute Skill Anda saat seharusnya? Ini memastikan Skill baru tidak merusak batas yang sudah ada.

Ada juga evaluasi yang dapat memeriksa pemuatan progresif yang tepat. Agen mungkin memuat Skill, tetapi apakah ia membaca file atau file aksesori? Misalnya, jika Anda memiliki Skill keuangan untuk kueri keuangan, apakah ia membaca file FORMATTING.md khusus?

Ada juga evaluasi untuk Skill yang menguji penyelesaian tugas end-to-end dalam domain. Kami menjalankan loop agen penuh dan menggunakan penilai LLM untuk menilai hasil berdasarkan rubrik kriteria yang didefinisikan dengan baik.

Terakhir, penting untuk menjalankan evaluasi ini terhadap model yang berbeda. Computer mendukung setidaknya tiga keluarga model orkestrasi yang berbeda: GPT, Claude Opus, dan Claude Sonnet. Anda ingin menjalankan pemuatan Skill dan Skill domain terhadap orkestrator agen yang berbeda ini untuk memastikan bahwa Anda tidak mendapatkan perilaku yang berbeda. Sonnet dan GPT berperilaku cukup berbeda dalam hal Skill.

Pemikiran akhir dan hal penting

Semakin banyak Skill yang Anda bangun, semakin mahir Anda dalam membangunnya. Jika Anda tidak mengotomatiskan atau mencoba membuat tugas yang Anda lakukan sehari-hari menjadi lebih dapat direproduksi menggunakan Skill, mulailah segera.

Tindakan membangun Skill membuat Anda lebih baik dalam membangun lebih banyak Skill, dan lagi, mereka sangat baik dalam mengotomatiskan proses bisnis. Jika Anda dapat mendeskripsikan sesuatu yang Anda lakukan setiap minggu sebelum standup Anda, di akhir setiap sprint, atau apa pun yang Anda lakukan sebagai insinyur setiap hari, setiap minggu, atau bahkan setiap triwulan, Anda harus menulis Skill untuk membeli kembali waktu Anda.

Bisakah Anda mengotomatiskan postmortem? Bisakah Anda meninjau pull request? Tugas apa pun yang dapat Anda lakukan, Anda setidaknya dapat membuat lulusan pertama menjadi Agent Skill. Ini akan menghemat waktu Anda secara signifikan.

Kendati demikian, ingatlah bahwa Skill tidak mudah atau bahkan selalu diperlukan. Lebih sedikit lebih baik. Beberapa hal penting lainnya:

Tulis evaluasi sebelum Skill. Sertakan contoh negatif dan pemuatan terlarang untuk Skill yang berdekatan tetapi berbeda.

Deskripsinya adalah bagian yang sulit. "Muat ketika..." (setiap kata memerlukan perhatian).

Jebakan adalah konten bernilai sangat tinggi. Mulai tipis, tumbuh saat agen gagal.

Ingatlah bahwa sangat mudah untuk merusak Skill pra-eksistensi lainnya dengan menambahkan Skill baru, meskipun Anda tidak menyentuhnya (waspadai tindakan pada jarak jauh).

Gunakan semua alat yang tersedia setiap kali Anda menulis dan memelihara Skill. Jika Anda ingin mempelajari lebih lanjut, situs web Agent Skills memiliki banyak contoh bagus, dan baik repositori internal kami maupun ekosistem publik berisi banyak contoh Skill yang dirancang dengan baik.

Sitasi

@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://www.perplexity.ai/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}