Aliran kerja ejen pertama anda bermula dengan satu prompt dan beberapa alatan. Ia menjawab soalan. Ia menyemak status pesanan. Ia berfungsi, jadi anda melancarkannya.

Kemudian produk berkembang. Pasukan Jualan meminta pengemas kini CRM yang menyelaraskan nota mesyuarat. Pasukan Sokongan memerlukan aliran kerja bayaran balik yang melibatkan tiga sistem dalaman. Pasukan Kejuruteraan menambah tindakan pelayar untuk mengisi borang vendor. Setiap permintaan kelihatan kecil. Setiap satunya mendapat fail prompt sendiri, bebenang Slack sendiri, dan "pembaikan pantas" sendiri. Enam bulan kemudian, ejen anda bukan lagi satu sistem. Ia menjadi timbunan prompt yang disalin secara berselerak, peraturan perniagaan yang tersembunyi, dan keputusan yang dibuat dalam bebenang sembang lama yang tidak dapat ditemui oleh sesiapa pun. Itulah yang dipanggil prompt sprawl. Ia menjadikan produk AI anda sukar untuk diuji, sukar untuk disemak, dan mustahil untuk dikembalikan ke versi sebelumnya dengan yakin.

Penyelesaiannya ialah daftar kemahiran ejen AI (AI agent skill registry).

Apa Sebenarnya Sebuah Kemahiran

Kemahiran bukanlah sekadar prompt yang disimpan dalam folder. Ia adalah pakej berversi dan boleh diuji yang menentukan apa yang dilakukan oleh ejen, alatan mana yang boleh dipanggilnya, dan apa yang tidak boleh dilakukannya sama sekali. Anggaplah ia sebagai kontrak antara pasukan anda dan mesin. Apabila ejen memuatkan kemahiran, ia sepatutnya tahu dengan tepat di mana sempadannya dan bagaimana rupa kejayaan tersebut.

Tanpa struktur ini, setiap prompt menjadi sistem pengeluaran kecil yang tidak diisytiharkan. Ia membawa kebenaran tersembunyi, peraturan perniagaan yang tertanam, dan impak kos yang tidak dijejak oleh sesiapa pun. Ia terpesong daripada produk sebenar kerana pelan hala tuju produk telah berubah manakala prompt tersebut ketinggalan. Yang paling teruk, ia disalin. Seseorang melakukan fork untuk demo, atau menampalnya ke dalam mikroservis baharu, dan kini anda mempunyai dua sumber kebenaran yang semakin menyimpang tanpa diketahui.

Mengapa Prompt Sahaja Tidak Mencukupi

Prompt kelihatan seperti teks, jadi pasukan melayannya seperti konfigurasi. Hakikatnya, ia lebih dekat dengan kod daripada apa yang diakui oleh sesiapa pun. Prompt pengeluaran biasanya menyandikan logik tentang turutan, pemformatan, pengendalian ralat, dan kawalan akses. Apabila logik tersebut hanya wujud dalam bahasa tabii, anda akan menghadapi kekaburan. Adakah ejen mempunyai kebenaran untuk mengemas kini CRM, atau adakah prompt tersebut sekadar mencadangkannya? Jika API pengebilan tergendala, adakah prompt tersebut tahu cara untuk gagal dengan selamat, atau adakah ia berhalusinasi dengan mesej kejayaan?

Kos adalah pembunuh senyap yang lain. Prompt yang meminta ejen untuk "berfikir langkah demi langkah dan mencari secara meluas" boleh menghabiskan banyak token pada setiap pelaksanaan. Apabila prompt tersebut disalin ke dalam aliran sokongan trafik tinggi, bil inferens bulanan anda akan meningkat dua kali ganda dan tiada sesiapa pun tahu mengapa.

Terpesong (drift) berlaku apabila perniagaan berubah tetapi teks tidak berubah. Polisi bayaran balik anda kini memerlukan kelulusan pengurus melebihi ambang tertentu. Jika peraturan itu berada di dalam prompt dan bukannya dalam lapisan polisi, anda perlu mencari melalui setiap penggunaan (deployment) untuk mencari salinan yang perlu dikemas kini. Jika terlepas satu pun, anda akan mempunyai ejen yang memberikan wang yang sepatutnya tidak diberikan.

Anatomi Kemahiran Pengeluaran

Jika anda ingin mengelakkan kekacauan ini, layan setiap kemahiran seperti artifak perisian. Kemahiran pengeluaran yang berguna merangkumi lebih daripada sekadar teks. Ia memerlukan:

  • Nama dan tujuan. Bukan "prompt_v3_final," tetapi "process_standard_refund" dengan keterangan matlamat perniagaan yang jelas.
  • Skema input dan konteks yang diperlukan. Takrifkan medan tepat yang diharapkan oleh kemahiran tersebut. Adakah ia memerlukan ID pengguna, sejarah perbualan, atau pengenal pasti penyewa (tenant identifier)? Pemilihan jenis data yang kuat (strong typing) di sini dapat menghalang ejen daripada membuat andaian.
  • Kebenaran alatan dan had keselamatan. Senaraikan secara eksplisit alatan mana yang boleh dipanggil oleh kemahiran tersebut. Tetapkan pagar keselamatan (guardrails) pada cubaan semula (retries), had perbelanjaan, dan had kadar (rate caps). Jika kemahiran tersebut tidak sepatutnya menyentuh API pemadaman pengguna, nyatakannya dalam kod, bukan sekadar dalam prosa.
  • Kriteria kejayaan dan kes ujian. Sebuah kemahiran tidak "berfungsi" hanya kerana ia berjalan. Takrifkan apa yang mesti terkandung dalam output. Untuk kemahiran bayaran balik, kejayaan mungkin bermaksud rekod transaksi yang disahkan, pengesahan e-mel dihantar, dan entri log audit dicipta.
  • Sejarah versi dan status pemilik. Seseorang perlu memiliki ini. Log perubahan (changelog) harus menjelaskan mengapa v2.3 wujud dan apa yang rosak dalam v2.2.

Asingkan Lapisan Anda

Kesilapan terbesar yang dilakukan oleh pasukan adalah memasukkan segalanya ke dalam satu prompt. Mereka mencampurkan panduan mesra, dokumentasi alatan, polisi keselamatan, dan pengendalian ralat ke dalam satu dinding teks. Itu tidak boleh diselenggara.

Pecahkannya:

  • Arahan adalah panduan untuk ejen. Ia menjelaskan nada, format, dan pendekatan umum.
  • Peraturan Alatan memberitahu ejen alatan mana yang wujud dan fungsinya. Ini adalah proses penemuan, bukan pemberian kebenaran.
  • Polisi dikuatkuasakan oleh kod, bukan sekadar harapan. Jika bayaran balik melebihi $500 memerlukan semakan kedua, semakan tersebut terletak dalam fungsi pengesahan yang dijalankan sebelum alatan tersebut dipanggil.
  • Evals adalah ujian yang membuktikan kemahiran tersebut masih berfungsi selepas sebarang perubahan.

Sebagai contoh, jangan tulis, "Sila jangan sesekali mendedahkan nombor kad kredit penuh pelanggan." Sebaliknya, bina pemformat data yang memadam maklumat PAN sebelum ejen melihatnya. Polisi harus berada dalam kod kerana kod tidak boleh dipujuk untuk mengabaikan tugasnya oleh input pengguna yang licik.

Berhenti Menghalakan Produksi ke "Latest"

Tiada apa yang lebih merosakkan petang Jumaat selain daripada kemas kini prompt secara senyap. Jika ejen produksi anda sentiasa menarik versi "latest" bagi sesuatu kemahiran, maka setiap penggabungan (merge) ke main adalah potensi insiden langsung. Anda memerlukan alias seperti dev, staging, dan prod. Promosikan versi yang diketahui dan telah diuji melalui peringkat-peringkat ini. Apabila prod menghala ke v2.1.4, anda boleh memantau ia berjalan, mengukur tingkah lakunya, dan tidur dengan nyenyak. Jika sesuatu berlaku, anda hanya perlu mengalihkan semula alias tersebut. Anda tidak mahu melakukan penyahpepijatan (debug) bahasa tabii pada tengah malam di bawah tekanan.

Disiplin ini juga memaksa pasukan anda untuk memikirkan tentang keserasian ke belakang (backwards compatibility). Bolehkah v2.2 mengendalikan bentuk input yang sama seperti v2.1? Jika tidak, promosi akan gagal di peringkat staging, dan anda dapat mengesannya sebelum pelanggan melakukannya.

Keselamatan Bermula di Dalam Pakej

Satu repositori yang penuh dengan prompt yang tidak diaudit adalah satu kerentanan yang menanti masa untuk berlaku. Anda perlu mengimbas kemahiran anda untuk risiko yang sama seperti yang anda imbas dalam kod.

Cari rahsia yang dikodkan secara keras (hardcoded) atau kunci API yang tersembunyi dalam templat prompt. Periksa webhook luaran atau arahan shell yang mengekstrak data secara haram. Perhatikan percubaan untuk mengatasi polisi sistem, seperti prompt yang mengandungi "ignore previous instructions" atau meminta ejen mendedahkan konfigurasinya sendiri. Ini bukan sekadar teori. Ia adalah corak biasa dalam serangan suntikan prompt (prompt-injection), dan ia berbahaya kerana ia sering disertakan bersama teks salinan yang tidak disemak oleh sesiapa.

Jalankan pakej kemahiran anda melalui analisis statik. Jika fail kemahiran mengandungi URL yang tidak berada dalam senarai putih (allowlist), gagalkan binaan tersebut. Jika ia merujuk kepada alatan yang tidak ada dalam manifes yang diluluskan, tolaknya.

Jika Anda Tidak Boleh Mengujinya, Anda Tidak Boleh Mempercayainya

Repositori tanpa penilaian (evaluations) hanyalah sekadar folder prompt. Setiap kemahiran memerlukan set ujian yang menguji laluan utama (happy path), kes hujung (edge cases), dan mod kegagalan. Untuk kemahiran berisiko tinggi, anda memerlukan lebih daripada sekadar ujian fungsian. Anda perlu menguji sempadan kebenaran untuk memastikan ejen tidak dapat melihat data pengguna lain. Anda memerlukan semakan tingkah laku penolakan untuk mengesahkan ia berkata "tidak" apabila polisi menyekat sesuatu tindakan. Anda memerlukan ujian rintangan suntikan prompt untuk mengesahkan bahawa input adversarial tidak memintas perlindungan tahap kod anda.

Namakan ujian anda secara eksplisit. Ujian yang dinamakan "refund_skill_rejects_negative_amount" memberitahu jurutera seterusnya dengan tepat tingkah laku mana yang dilindungi. Apabila ujian gagal semasa promosi versi, anda mempunyai bukti kukuh bahawa binaan calon tersebut tidak selamat.

Matlamat Sebenar Adalah Kawalan

Penggunaan semula itu bagus, tetapi kawalanlah yang memastikan anda terus bekerja. Repositori kemahiran membolehkan pasukan anda menyatakan dengan pasti: ini adalah aliran kerja yang diluluskan. Ini adalah versi yang berjalan dalam produksi. Ini adalah alatan yang boleh digunakannya. Ini adalah cara tepat untuk kita melakukan pengunduran (rollback).

Kejelasan itu mengubah anda daripada sekadar menghantar demo yang hebat kepada mengendalikan perisian yang boleh dipercayai. Demo memukau pihak berkepentingan selama sepuluh minit. Perisian yang boleh dipercayai berjalan pada pukul tiga pagi, mengendalikan pengecualian dengan lancar, dan tidak mengubah tingkah laku hanya kerana seseorang menggabungkan permintaan tarik (pull request) pada petang Selasa.

Bina repositori anda. Versikan kemahiran anda. Kuasakan polisi anda dalam kod. Uji seolah-olah jadual tidur anda bergantung kepadanya. Diri anda di masa hadapan akan berterima kasih.