Antipola Alat dan Kesalahan

Sebagian besar kegagalan agen bukanlah kerusakan yang dramatis. Kegagalan tersebut berupa perutean keliru yang diam-diam: model memilih alat yang salah, atau alat gagal dengan pesan samar yang tidak dapat digunakan model untuk memulihkan diri. Agen kemudian berimprovisasi, mengarang, atau meninggalkan tugas secara diam-diam.

Pelajaran ini membedah tiga anti-pattern yang terus-menerus dirilis ke lingkungan produksi:

• Deskripsi alat yang minimal sehingga model harus menebak
• Terlalu banyak alat per agen, yang menurunkan keandalan pemilihan
• Status kesalahan generik yang menghalangi pemulihan cerdas

Masing-masing merupakan jawaban yang salah dan sering muncul dalam ujian. Pelajari cara mengenali dan memperbaikinya.

Kesalahpahaman yang umum: model merutekan berdasarkan nama alat. Tidak demikian. Deskripsi alat adalah mekanisme pemilihan utama. Nama hanyalah label; deskripsilah tempat model memutuskan apakah suatu alat sesuai dengan situasi.

Deskripsi minimal seperti "Looks up an order" hampir tidak memberi informasi kepada model. Ketika dua alat memiliki deskripsi yang tipis dan saling tumpang tindih, model melakukan perutean keliru — model memanggil lookup_order padahal yang diperlukan adalah get_customer, dan seluruh loop agen menjadi menyimpang.

Deskripsi alat yang baik memuat lima hal:

• Tujuan — apa yang dilakukannya dan kapan harus digunakan
• Nilai yang dikembalikan — bentuk data yang dihasilkan
• Format input beserta contoh — konkret, bukan abstrak
• Kasus khusus — hasil kosong, ambiguitas, beberapa kecocokan
• Batas penerapan — kapan alat tersebut TIDAK boleh digunakan

Poin terakhir itulah yang membedakan alat-alat yang tumpang tindih. Di bawah ini adalah versi lemah yang paling sering dirilis oleh tim.

Sekarang, inilah versi yang kuat. Perhatikan bagaimana deskripsi menyatakan format input beserta contoh, bentuk hasil, kasus hasil kosong, dan batas eksplisit yang mencegah benturan dengan get_customer.

Ini adalah perbaikan dengan dampak terbesar untuk perutean keliru: Anda mengubah deskripsi, bukan modelnya.

Anti-pattern kedua: memberikan kotak alat raksasa kepada satu agen. Keandalan pemilihan tidak konstan — keandalan tersebut menurun seiring bertambahnya jumlah alat.

• 4–5 alat per agen adalah rentang optimal
• 18+ alat menurunkan keandalan pemilihan secara terukur

Semakin banyak alat berarti semakin banyak kemungkinan deskripsi yang tumpang tindih, semakin luas ruang ambiguitas, dan semakin panjang daftar yang harus dipertimbangkan model pada setiap giliran. Cakupan luas bukan keunggulan di sini — melainkan beban.

Perbaikannya bersifat arsitektural: batasi alat sesuai peran, alih-alih memberikan setiap agen semua kemampuan. Dalam sistem multi-agen hub-dan-spoke, koordinator memecah pekerjaan dan mendelegasikannya kepada subagen — setiap subagen hanya mendapatkan beberapa alat yang diperlukan untuk tugasnya, mengikuti prinsip hak akses minimum.

Agen dukungan dengan 4 alat yang terfokus mengungguli generalis dengan 20 alat karena setiap alat tidak ambigu dalam kumpulan kecil yang dibatasi sesuai peran.

Ketika alur kerja benar-benar memerlukan banyak kemampuan, jawabannya bukan satu agen yang membengkak — melainkan dekomposisi. Pisahkan tanggung jawab di antara subagen yang dibatasi sesuai peran, lalu biarkan koordinator merutekan di antara mereka.

Ingat aturan multi-agen: subagen tidak mewarisi riwayat percakapan koordinator. Jadi, ketika mendelegasikan, teruskan semua konteks yang diperlukan secara eksplisit dalam prompt subagen. Pemisahan yang rapi membuat kumpulan alat setiap agen tetap kecil DAN menjaga konteksnya tetap terfokus.

Anti-pattern ketiga terdapat pada jalur kesalahan. Alat yang gagal dengan "Operation failed" atau hanya isError: true tidak memberi model apa pun untuk ditindaklanjuti. Model tidak dapat membedakan gangguan jaringan sementara dari kesalahan validasi atau hasil kosong — sehingga model mengulangi percobaan secara membabi buta, menyerah, atau mengarang jawaban.

Status kesalahan generik menghalangi perutean cerdas. Kesalahan terstruktur memungkinkannya.

Kesalahan yang dapat dipulihkan memiliki struktur. Konvensi MCP menggabungkan kolom yang diperlukan model untuk memutuskan tindakan berikutnya:

• isError: true beserta errorCategory: sementara / validasi / bisnis / izin
• isRetryable — apakah model harus mencoba lagi?
• message, attempted_query, dan partial_results

Dengan semua ini, model merutekan secara cerdas: mencoba lagi kesalahan sementara, memperbaiki kesalahan validasi, mengeskalasikan penolakan izin, atau menampilkan hasil parsial alih-alih tidak menampilkan apa pun.

Satu pembedaan terselubung yang sering diuji: FAILURE akses (alat tidak dapat berjalan — batas waktu habis, tidak ada izin) tidak sama dengan hasil EMPTY yang valid (kueri berjalan baik tetapi tidak menemukan apa pun).

Menyatukan keduanya sebagai kesalahan umum akan menghambat pemulihan. Kegagalan mungkin layak dicoba lagi; hasil kosong berarti "tidak ada kecocokan" dan harus dilaporkan sebagai fakta, bukan dicoba ulang tanpa henti. lookup_order Anda sebelumnya sudah benar: tidak ada kecocokan menghasilkan hasil kosong, bukan kesalahan.

Satukan semuanya menjadi strategi propagasi kesalahan:

• Pulihkan kegagalan sementara secara lokal di subagen — coba lagi setelah batas waktu habis, jangan teruskan ke tingkat atas
• Eskalasikan kegagalan yang tidak dapat dipulihkan dengan konteks terstruktur: jenis kegagalan, kueri yang dicoba, hasil sebagian, dan alternatif
• Jangan pernah menekan kesalahan secara diam-diam, dan jangan pernah membatalkan seluruh alur kerja hanya karena satu subagen gagal

Koordinator kemudian dapat menghindari satu cabang yang gagal dan tetap menggabungkan jawaban yang berguna — hal yang justru tidak mungkin dilakukan jika menggunakan kesalahan umum.

Sekarang Anda dapat mengenali dan memperbaiki antipola alat dan kesalahan yang muncul sebagai jawaban keliru dalam ujian:

• Deskripsi minimal menyebabkan salah pengarahan. Perbaikan: deskripsi adalah mekanisme pemilihan — nyatakan tujuan, nilai yang dikembalikan, format masukan beserta contoh, kasus tepi, dan batas penerapan.
• Terlalu banyak alat menurunkan kualitas pemilihan. Perbaikan: 4–5 alat per agen adalah jumlah optimal, 18+ menurunkan keandalan — batasi alat sesuai peran dan bagi ke beberapa subagen dengan hak akses minimum.
• Kesalahan umum menghambat pemulihan. Perbaikan: gunakan kesalahan terstruktur dengan errorCategory (sementara/validasi/bisnis/izin), isRetryable, kueri_yang_dicoba, dan hasil_sebagian — bedakan kegagalan akses dari hasil kosong yang valid, pulihkan kegagalan sementara secara lokal, eskalasikan sisanya dengan konteks, dan jangan pernah menekan atau membatalkan seluruh alur kerja secara diam-diam.