🔧 Apa itu Skill?
Dalam konteks agen AI, sebuah skill (juga disebut tool or function) adalah kapabilitas yang dipaketkan dan dapat digunakan ulang yang dapat dipanggil oleh LLM untuk berinteraksi dengan dunia di luar jendela konteksnya. Skills menjembatani kesenjangan antara pemahaman bahasa dan aksi dunia nyata.
Setiap skill memiliki empat komponen:
- Name — sebuah pengidentifikasi unik yang digunakan model untuk mereferensikan skill (mis.,
web_search) - Description — teks bahasa alami yang menjelaskan apa yang dilakukan skill dan kapan menggunakannya; LLM membaca ini untuk memutuskan kapan memanggil skill
- Skema input — definisi terstruktur dari argumen (JSON Schema); model mengisi ini berdasarkan tugas
- Implementation — kode aktual yang dijalankan: panggilan API, kueri database, perintah shell, atau operasi lain apa pun
Contoh: A get_weather skill memiliki deskripsi "Mengambil cuaca terkini untuk sebuah kota", menerima { "city": "string" } sebagai input, dan memanggil API cuaca. LLM tidak pernah melihat kunci API atau panggilan HTTP — ia hanya menerima hasilnya kembali sebagai teks.
⚙️ Cara Pemanggilan Tool Bekerja
Ketika agen memiliki akses ke skills, LLM tidak memanggilnya secara langsung — ia requests sebuah panggilan dengan menghasilkan output terstruktur. Runtime (kode aplikasi Anda) mengeksekusi panggilan aktual dan mengembalikan hasilnya. Berikut siklus lengkapnya:
- Registrasi Tool — Kode Anda mengirimkan model daftar skills yang tersedia dengan deskripsi dan skema mereka
- Penalaran model — LLM membaca tugas dan tools yang tersedia, memutuskan tool mana yang dipanggil dan dengan argumen apa
- Permintaan pemanggilan tool — Model mengeluarkan pesan "tool call" terstruktur (mis.,
{ "tool": "web_search", "args": { "query": "current Gemini models" } }) - Execution — Kode runtime Anda memanggil fungsi, API, atau layanan yang sebenarnya
- Injeksi hasil — Hasil ditambahkan kembali ke konteks percakapan
- Penalaran lanjutan — Model membaca hasil dan atau memanggil tool lain, menanyakan tindak lanjut, atau menghasilkan jawaban akhir
Loop ini dapat berulang berkali-kali dalam satu giliran. Tugas agen kompleks mungkin memanggil 10–20 tools berurutan sebelum menghasilkan respons akhir.
📊 Skills vs Plugins vs MCP Servers
Terminologi berkembang cepat. Berikut bagaimana konsep-konsep tersebut berelasi secara historis:
| Era | Name | Bagaimana cara kerjanya | Status |
|---|---|---|---|
| 2023 | ChatGPT Plugins | Ekstensi yang dapat dipasang pengguna dengan spesifikasi OpenAPI; ChatGPT memanggilnya melalui HTTP | Tidak lagi digunakan (digantikan oleh GPTs + tools) |
| 2023 | OpenAI Function Calling | Definisi JSON Schema tingkat API; model mengeluarkan pemanggilan fungsi terstruktur, kode Anda mengeksekusinya | Aktif — berganti nama menjadi "tool use" |
| 2023– | Tool Use / Skills | Sama seperti pemanggilan fungsi; Anthropic menciptakan istilah "tool use", yang lain menggunakan "skills" atau "functions" | Aktif — standar saat ini |
| 2024– | MCP Servers | Protokol terstandarisasi (Anthropic, Des 2024) untuk mengemas dan mendistribusikan server tool; setiap MCP client dapat terhubung ke MCP server manapun | Aktif — ekosistem yang berkembang |
Perbedaan kunci: Penggunaan tool tradisional didefinisikan secara inline dalam kode aplikasi Anda. MCP servers adalah proses mandiri yang mengekspos tools lewat protokol standar — membuatnya dapat digunakan ulang oleh berbagai klien AI (Claude Desktop, Cursor, VS Code, agen kustom). Baca lebih lanjut: Apa itu MCP.
🗂️ Kategori Tool & Tingkat Risiko
Tidak semua tool membawa risiko yang sama. Mengelompokkan menurut tingkat risiko membantu menentukan ruang aksi dan di mana menambahkan titik pemeriksaan human-in-the-loop:
| Category | Examples | Risk | Recommendation |
|---|---|---|---|
| Read-only | web_search, read_file, get_weather, list_dir | Low | Izinkan otonom; log semua panggilan |
| Tulis (lokal) | write_file, create_dir, edit_code | Medium | Batasi ke direktori workspace yang disandbox |
| Jaringan / Eksternal | send_email, post_to_slack, call_api | Sedang–Tinggi | Persetujuan HITL untuk pengiriman yang tidak dapat dibatalkan |
| OS / Shell | run_command, execute_script, install_package | High | Batasi ke lingkungan terkontainer; HITL diperlukan |
| Destructive | delete_file, drop_table, revoke_access | Critical | Selalu minta konfirmasi manusia eksplisit |
🏗️ Anatomi Skill yang Baik
Keputusan desain terpenting untuk sebuah skill adalah description. LLM membaca deskripsi untuk memutuskan tool mana yang dipanggil — deskripsi yang ditulis buruk menyebabkan pemilihan tool yang salah, pemanggilan yang terlewat, atau argumen yang ambigu.
Apa yang membuat deskripsi efektif
- Jelaskan secara eksplisit kapan menggunakannya — "Gunakan tool ini ketika pengguna menanyakan data waktu-nyata atau peristiwa terkini" lebih baik daripada "Mencari web"
- Nyatakan apa yang TIDAK dilakukan — "Tidak mengembalikan data historis lebih dari 30 hari"
- Deskripsikan format keluaran — "Mengembalikan array JSON hasil pencarian dengan field title, url, dan snippet"
- Jaga agar di bawah 200 kata — deskripsi yang lebih panjang dari ~200 token dapat membebani atensi model ketika banyak tools terdaftar
Prinsip desain skema
- Wajib vs opsional — Tandai field sebagai wajib hanya jika benar-benar perlu; field opsional dengan default mengurangi kesalahan model
- Gunakan enum untuk nilai terbatas —
"format": {"enum": ["json", "markdown", "text"]}mencegah nilai halusinasi - Prefer tools idempoten — Tools yang dapat dicoba ulang dengan aman (pembacaan, lookup) lebih aman daripada tindakan satu kali (mengirim, menghapus)
- Kembalikan data terstruktur — Respons JSON lebih mudah bagi model untuk menalar daripada blob teks tak terstruktur
💡 Contoh Dunia Nyata
| Nama skill | Apa yang dilakukannya | Argumen kunci | Risk |
|---|---|---|---|
web_search | Kueri mesin pencari dan kembalikan hasil teratas | query: string, num_results?: number | Low |
read_file | Baca file dari direktori workspace | path: string, offset?: number, limit?: number | Low |
write_file | Buat atau timpa file | path: string, content: string | Medium |
run_tests | Jalankan test suite proyek dan kembalikan hasil | filter?: string | Medium |
browser_screenshot | Navigasi ke URL dan kembalikan screenshot | url: string | Medium |
send_email | Kirim email ke satu atau lebih penerima | to: string[], subject: string, body: string | Tinggi — selalu HITL |
run_shell | Jalankan perintah shell arbitrer | command: string, cwd?: string | Tinggi — sandbox diperlukan |
✅ Praktik Terbaik
Izin minimal
Berikan setiap agen hanya tools yang dibutuhkannya untuk tugas spesifiknya. Agen yang menjawab FAQ tidak perlu write_file or send_email. Semakin kecil ruang aksi, semakin kecil radius dampak jika agen dimanipulasi. Lihat: Agen dengan kewenangan berlebih.
Audit semua panggilan tool
Log setiap panggilan tool dengan argumen dan hasilnya. Ini memungkinkan debug, atribusi biaya, dan deteksi perilaku anomali (mis., agen membaca ~/.ssh/ padahal seharusnya hanya mengakses direktori proyek). Platform AgentOps seperti LangSmith mempermudah ini.
Human-in-the-loop untuk aksi yang tidak dapat dibatalkan
Setiap tindakan yang sulit atau tidak mungkin untuk dibatalkan — mengirim pesan, menghapus data, melakukan pembelian — harus memerlukan konfirmasi manusia eksplisit sebelum eksekusi. Bangun titik pemeriksaan HITL ke dalam runtime agen Anda, bukan hanya prompt. Prompt bisa ditimpa; kode tidak bisa.
Waspadai peracunan tool
Jika Anda mengizinkan agen menginstal atau menemukan MCP servers secara dinamis, server berbahaya dapat mendaftarkan sebuah tool dengan deskripsi yang berisi instruksi tersembunyi. Selalu tinjau deskripsi tool sebelum menambahkannya ke registri agen Anda. Lihat: Peracunan Tool.
Tulis pengembalian error yang jelas
Ketika tool gagal, kembalikan error terstruktur dengan konteks yang cukup agar model dapat pulih atau ningkatkan — bukan stack trace exception mentah. Contoh: { "error": "rate_limited", "retry_after": 5 }. Error yang dideskripsikan dengan baik memungkinkan agen mencoba ulang, menggunakan tool cadangan, atau memberi tahu pengguna dengan baik.