Agen AI Jarang Mogok. Mereka Gagal Diam-Diam, dan Riset Menjelaskan Alasannya

Agen model bahasa besar kini menjawab tiket dukungan, mengakses basis data, dan merencanakan perjalanan. Saat mengalami masalah, biasanya mereka memberikan jawaban dengan penuh keyakinan disertai kode sukses. Sejumlah penelitian yang terus bertambah menjelaskan mengapa kegagalan ini sulit diketahui dan bagaimana tim rekayasa mulai belajar mengukurnya.

Kegagalan yang Tampak Seperti Keberhasilan

Perangkat lunak tradisional cenderung gagal secara mencolok. Sebuah fungsi memunculkan pengecualian, server mengembalikan kode kesalahan, dan dasbor pemantauan berubah merah. Agen AI berperilaku berbeda. Agen bekerja dalam sebuah siklus: model bahasa membaca perintah, memutuskan untuk memanggil alat seperti API pencarian atau basis data, membaca hasilnya, lalu memutuskan tindakan berikutnya. Setiap langkah bisa bermasalah, sementara semua permintaan jaringan dalam rangkaian itu tetap berhasil.

Perhatikan kasus yang umum terjadi. Sebuah alat cuaca mengalami kegagalan dan mengembalikan teks “layanan tidak tersedia” di dalam respons yang selebihnya tampak normal. Model membaca teks tersebut, lalu menyampaikan permintaan maaf dengan sopan atau, yang lebih buruk, menyusun prakiraan yang masuk akal berdasarkan data pelatihannya. Pengguna menerima jawaban yang lancar. Log server menunjukkan permintaan berhasil dengan latensi normal. Tidak ada catatan dalam sistem pemantauan konvensional yang menunjukkan bahwa terjadi masalah.

Penyedia model menjelaskan kesenjangan yang sama dalam dokumentasi mereka. Panduan Gemini API dari Google menyebutkan bahwa model “tidak menjalankan fungsi itu sendiri”. Model hanya mengusulkan nama fungsi dan argumennya, sedangkan aplikasi pengembang yang menjalankan pemanggilan tersebut. Karena itu, aplikasi adalah satu-satunya bagian sistem yang melihat hasil sebenarnya. Panduan rekayasa Anthropic tentang pembuatan agen menyampaikan hal terkait: agen memerlukan “fakta acuan” dari lingkungan pada setiap langkah, misalnya hasil dari alat, untuk menilai kemajuannya sendiri. Ketika sebuah alat melaporkan kegagalan sebagai teks biasa, fakta acuan itu keliru dan agen tidak punya cara untuk menyadarinya.

Ini bukan jenis masalah baru, melainkan versi yang lebih tajam dari masalah lama. Pada 2015, para insinyur Google yang dipimpin D. Sculley menguraikan “utang teknis tersembunyi” dalam sistem pembelajaran mesin. Mereka berpendapat bahwa sebagian besar risiko dalam sistem ML produksi berada di luar kode model, yakni pada dependensi data, konfigurasi, dan kode perekat. Agen menambahkan lapisan baru ke dalam daftar tersebut. Perintah dan deskripsi alat merupakan konfigurasi yang dapat mengubah perilaku sistem tanpa mengubah kodenya.

Perubahan Kecil, Dampak Besar

Seberapa besar pengaruh perubahan kecil pada perintah? Dalam makalah yang dipresentasikan di ICLR 2024, Melanie Sclar dari University of Washington dan rekan-rekannya hanya mengubah format perintah few-shot: pemisah, spasi, dan penggunaan huruf kapital. Maknanya tetap sama. Namun, kinerja pada tugas yang sama masih bervariasi hingga 76 poin akurasi pada LLaMA-2-13B. Sensitivitas ini tidak hilang meskipun model diperbesar, jumlah contoh ditambah, atau penyetelan instruksi dilakukan.

Para penulis menyarankan agar rentang kinerja pada berbagai format perintah yang masuk akal dilaporkan, alih-alih hanya satu angka. Bagi tim rekayasa, pelajaran praktisnya lebih sederhana. Perubahan pada perintah adalah perubahan kode. Perubahan itu perlu memiliki riwayat versi dan harus diuji sebelum diterapkan kepada pengguna.

Hal yang sama berlaku untuk deskripsi alat, yang dibaca model sebagai bagian dari perintahnya. Panduan Anthropic menyarankan agar definisi alat mendapat “perhatian rekayasa perintah yang sama besarnya” dengan perintah utama. Panduan itu menjelaskan tentang agen pemrograman yang terus membuat kesalahan saat menggunakan jalur berkas relatif. Setelah alat tersebut diubah agar mewajibkan jalur absolut, model menggunakannya tanpa kesalahan. Modelnya tidak berubah. Yang berubah hanya deskripsi yang dibacanya.

Satu Keberhasilan Tidak Banyak Membuktikan

Penelitian lain menelaah konsistensi. Tolok ukur τ-bench, yang diterbitkan oleh Shunyu Yao dan rekan-rekannya di Sierra serta dipresentasikan di ICLR 2025, menyimulasikan percakapan layanan pelanggan yang mengharuskan agen menggunakan alat dan mengikuti aturan bisnis. Para penulis memperkenalkan metrik bernama pass^k: probabilitas bahwa agen menyelesaikan tugas yang sama dengan benar dalam semua k percobaan.

Hasilnya cukup mengkhawatirkan. Agen GPT-4o menyelesaikan sekitar 61% tugas ritel dalam satu percobaan. Ketika harus berhasil menyelesaikan tugas yang sama delapan kali berturut-turut, angkanya turun menjadi sekitar 25%. Demo yang berhasil sekali tidak banyak memberi gambaran tentang perilaku sistem pada percobaan ke-1.000.

Titik Kegagalan Sistem Multi-Agen

Kini banyak tim merangkai beberapa agen, dengan satu agen menyusun rencana, agen lain melaksanakannya, dan agen ketiga memeriksa hasilnya. Sebuah studi tahun 2025 dari UC Berkeley, “Mengapa Sistem LLM Multi-Agen Gagal?”, menganalisis lebih dari 1.600 jejak eksekusi beranotasi dari tujuh kerangka kerja multi-agen populer. Para penulis yang dipimpin Mert Cemri menyusun taksonomi bernama MAST, yang mencakup 14 mode kegagalan dalam tiga kelompok: masalah desain sistem, ketidakselarasan antaragen, dan verifikasi tugas.

Temuan utama mereka adalah bahwa banyak kegagalan bersumber dari desain sistem, bukan hanya keterbatasan model yang mendasarinya. Agen mengabaikan peran yang diberikan, kehilangan jejak percakapan, atau menyatakan tugas selesai tanpa memeriksa hasilnya. Kegagalan ini tidak meninggalkan pesan kesalahan. Kegagalan tersebut hanya terlihat jika seseorang dapat membaca apa yang benar-benar dilakukan setiap agen. Ulasan Unite.AI tentang paradoks multi-agen mengemukakan hal terkait dari sudut pandang arsitektur: penambahan agen dapat memperbesar kesalahan sejak awal, bukannya menghilangkannya.

Membuat yang Tak Terlihat Menjadi Terlihat

Respons rekayasa ini mengambil pendekatan dari sistem terdistribusi, yang sejak lama melacak permintaan di berbagai layanan dengan teknik yang disebut tracing. Ketika diterapkan pada agen, setiap permintaan pengguna menjadi sebuah trace, dan setiap pemanggilan model atau alat menjadi sebuah “span” di dalamnya. Span mencatat masukan, keluaran, token yang digunakan, serta waktu yang dibutuhkan. OpenTelemetry, badan standar industri untuk bidang ini, sedang menyusun konvensi bersama untuk span AI generatif. Hingga 2026, konvensi tersebut masih berstatus dalam pengembangan, sehingga nama atributnya masih mungkin berubah.

Sejumlah proyek sumber terbuka, seperti Langfuse, Arize Phoenix, dan AcruxCore, telah menerapkan gagasan ini. Kode sumbernya tersedia untuk umum, sehingga tim dapat memeriksa cara penyimpanan trace dan menjalankan perangkat lunaknya di server sendiri. Proyek-proyek tersebut mencatat pemanggilan model dan alat sebagai span dalam satu trace, serta memungkinkan tim menyertakan skor kualitas. Pilihan alat tidak sepenting satu hal berikut: span alat harus mencatat hasil yang benar-benar dikembalikan oleh alat tersebut, bukan hanya apakah permintaan jaringan berhasil. Tanpa itu, kegagalan alat cuaca yang dijelaskan sebelumnya akan tetap tak terlihat.

Survei industri menunjukkan bahwa tracing kini sudah umum, tetapi pengujian belum mengimbanginya. Laporan Status Rekayasa Agen dari LangChain menyurvei 1.340 praktisi pada akhir 2025. Kualitas menjadi hambatan yang paling banyak disebut dalam penerapan agen ke lingkungan produksi, dengan 32% responden menyebutkannya. Sebanyak 89% organisasi melaporkan telah menerapkan suatu bentuk observabilitas untuk agen mereka, dan 62% memiliki tracing terperinci atas setiap langkah dan pemanggilan alat. Hanya 52,4% yang melakukan evaluasi luring pada kumpulan data uji, dan 37,3% mengevaluasi lalu lintas langsung. Sebagian besar tim dapat melihat apa yang dilakukan agen mereka. Lebih sedikit tim yang memeriksa apakah tindakan itu benar.

Menilai Jawaban dalam Skala Besar

Trace menunjukkan apa yang terjadi. Namun, trace tidak menunjukkan apakah jawabannya baik. Membaca setiap percakapan secara manual tidak dapat dilakukan dalam skala besar, sehingga tim semakin sering menggunakan model kedua sebagai penilai—pendekatan yang dikenal sebagai LLM sebagai penilai. Sebuah makalah NeurIPS 2023 karya Lianmin Zheng dan rekan-rekannya menemukan bahwa model canggih seperti GPT-4 sejalan dengan preferensi manusia dalam lebih dari 80% kasus, kira-kira sama dengan tingkat kesepakatan antarmanusia.

Makalah yang sama mendokumentasikan kelemahan metode ini. Model penilai cenderung memilih jawaban yang ditampilkan lebih dahulu, lebih menyukai jawaban yang lebih panjang, dan dapat mengunggulkan teks yang ditulisnya sendiri. Karena itu, skor dari model penilai hanyalah perkiraan. Skor tersebut berguna untuk penilaian dalam jumlah besar, tetapi perlu diperiksa menggunakan sejumlah kecil contoh yang diberi label oleh manusia, dengan urutan jawaban yang diacak.

Dari Praktik ke Kebijakan

Pekerjaan pengukuran ini juga mulai menjadi tuntutan tata kelola. Institut Standar dan Teknologi Nasional AS menerbitkan Kerangka Kerja Manajemen Risiko AI pada Januari 2023. Salah satu dari empat fungsi intinya, “Ukur”, meminta organisasi untuk mengukur, melacak, dan mendokumentasikan risiko AI dari waktu ke waktu. Untuk agen, trace dan skor evaluasi menjadi bukti yang diminta oleh fungsi tersebut.

Yang Dapat Dilakukan Tim Sekarang

Hal ini sejalan dengan argumen yang pernah disampaikan di platform ini bahwa keandalan adalah ujian sesungguhnya bagi AI agentik. Riset di atas menambahkan rincian pengukuran yang mendasari argumen tersebut: keandalan bukanlah sifat yang cukup diamati sekali saja, melainkan rentang yang harus terus diukur.

Riset ini mengarah pada sejumlah kebiasaan sederhana, dan penyedia model besar merekomendasikan banyak di antaranya. Panduan praktis OpenAI untuk membangun agen menyarankan tim untuk “menyiapkan evaluasi guna menetapkan tolok ukur kinerja” sebelum melakukan optimasi, serta menyerahkan kendali kepada manusia ketika agen melampaui jumlah upaya gagal yang telah ditetapkan atau menghadapi tindakan berisiko tinggi. Anthropic merekomendasikan “pengujian ekstensif di lingkungan sandbox” sebelum agen bertindak sendiri.

Dalam praktiknya, ada beberapa langkah konkret yang dapat dilakukan. Simpan prompt dan deskripsi alat dalam sistem kontrol versi, seperti kode. Uji setiap perubahan prompt terhadap kumpulan data tetap, dan perkirakan adanya rentang hasil, bukan hanya satu angka. Jalankan setiap kasus uji beberapa kali karena satu kali pengujian dapat menyamarkan ketidakkonsistenan. Catat keluaran alat di dalam trace agar alat yang gagal tidak dapat bersembunyi di balik kode keberhasilan. Perlakukan skor dari model penilai otomatis sebagai perkiraan, lalu periksa skor tersebut dengan melibatkan manusia.

Tak satu pun kebiasaan ini membutuhkan terobosan dalam kemampuan model. Yang dibutuhkan adalah memperlakukan agen AI sesuai hakikatnya: sebagai sistem probabilistik yang harus diukur, karena agen jarang mengumumkan kegagalannya sendiri.