Tool Calling: Merancang Alat yang Dipakai Agent dengan Benar
Saat agent berperilaku buruk, naluri pertama adalah menulis ulang prompt. Menurut pengalaman kami, prompt jadi penyebab mungkin sepertiga kali; sisanya, alat dirancang untuk sebuah program, bukan untuk pembaca yang harus menyimpulkan dari nama dan deskripsi apa fungsi itu melakukan.
Alat adalah seluruh kemampuan agent memengaruhi dunia, dan definisinya secara harfiah bagian dari konteks model. Merancangnya dengan baik lebih murah dan jauh lebih tahan lama daripada menyetel prompt, karena alat yang baik membatasi perilaku alih-alih memintanya.
Tujuh aturan yang mencegah sebagian besar panggilan buruk#
- Satu alat, satu tugas. `search_orders` dan `refund_order` mengalahkan `manage_order` bermode.
- Tipe, bukan prosa. Enum, rentang, dan format melakukan apa yang tak pernah dilakukan deskripsi.
- Nama yang mengatakan apa yang terjadi. `send_email_to_customer` jelas; `notify` tidak.
- Galat sebagai instruksi: apa yang salah dan apa langkah berikutnya, dalam satu kalimat.
- Hasil kosong juga hasil. Tidak-ditemukan yang eksplisit lebih baik daripada exception.
- Kunci idempotensi pada apa pun yang berefek samping.
- Kembalian kecil. Pangkas ke kolom yang dibutuhkan; 40 KB JSON membeli kebingungan.
Sebelum dan sesudah#
| Desain lemah | Kenapa gagal | Lebih baik |
|---|---|---|
| `query(sql)` | Kuasa tanpa batas, tak bisa diaudit | `get_orders_by_customer(customer_id, limit)` |
| `date: string` | Model mengarang format | `date: string, format YYYY-MM-DD` |
| `HTTP 500` | Tak menyiratkan tindakan | `Layanan pesanan tak tersedia. Minta pengguna mencoba nanti.` |
| Mengembalikan seluruh catatan | Memenuhi konteks, mengencerkan perhatian | Mengembalikan enam kolom bernama |
| `update_status(id, status)` | Status apa pun, catatan apa pun | `cancel_order(id)` dengan cek izin |
Deskripsi itu prompt#
Kolom deskripsi bukan dokumentasi untuk rekan kerja; itu teks yang dibaca model saat memutuskan. Katakan kapan memakai alat dan kapan tidak, sebutkan satu prasyarat yang penting, dan beri satu contoh argumen. Tiga kalimat mengalahkan tiga paragraf.
Kalau dua alat bisa sama-sama melayani permintaan yang sama, agent kadang memilih salah. Gabungkan atau perjelas batasnya di kedua deskripsi.
Selalu validasi sebelum eksekusi#
Jangan pernah meneruskan keluaran model ke panggilan sistem tanpa pemeriksaan. Validasi argumen terhadap skema, selesaikan pengenal terhadap catatan yang boleh dilihat pengguna ini, dan tolak yang tak cocok alih-alih memaksakannya. Penolakan dengan pesan jelas adalah hasil yang baik.
Pertanyaan yang sering diajukan
Berapa banyak alat yang terlalu banyak?
Di atas sekitar sepuluh dalam satu lingkar, akurasi pemilihan menurun dan deskripsi memenuhi konteks. Kelompokkan di balik router sempit atau pecah ke agent terspesialisasi.
Haruskah alat mengembalikan respons API mentah?
Tidak. Kembalikan bentuk kecil dan stabil dengan kolom yang benar-benar dibutuhkan.
Bagaimana mencegah agent mengarang argumen?
Dengan membatasi: enum alih-alih teks bebas, format eksplisit, dan pengenal yang harus terselesaikan. Lalu validasi dan tolak dengan jelas.
tool callingfunction calling agentdesain alatjson schema alatgalat alat llm
