Mengapa Agen AI Membutuhkan Bukti Sebelum Mencoba Lagi

Cara mencegah respons yang hilang memicu tindakan duplikat

Agen dukungan yang diberi wewenang untuk memberikan satu pengembalian dana mengirimkan permintaan, tetapi koneksinya terputus. Agen tersebut tidak menerima konfirmasi keberhasilan dan mencoba mengirimkan permintaan pengembalian dana itu lagi. Jika permintaan awal berhasil, tindakan agen yang mengulanginya dapat mengakibatkan pengembalian dana kedua.

Ini sepenuhnya hipotetis. Contoh ini menggambarkan masalah yang tidak dapat diatasi hanya dengan akurasi model. Tindakan apa yang seharusnya dilakukan agen jika tidak dapat memastikan apakah tindakan sebelumnya telah mengubah keadaan lingkungan?

Unite.AI telah mengulas keandalan agen di luar aspek model. Masalah pemulihan perlu memiliki aturan tersendiri dalam pembahasan tersebut. Sebelum mengulangi tindakan yang berdampak penting, agen harus memastikan apa yang telah terjadi atau memiliki jaminan yang sah bahwa tindakan itu tidak akan menimbulkan efek duplikat.

Tidak Adanya Respons Tidak Membuktikan Kegagalan

Tidak adanya respons tidak membuktikan bahwa suatu tindakan gagal. Hal itu tidak menunjukkan apakah terjadi kesalahan sebelum tindakan dijalankan, apakah tindakan selesai tanpa konfirmasi, atau apakah prosesnya masih berlangsung.

Ini adalah masalah umum dalam sistem terdistribusi, sebagaimana dijelaskan oleh Amazon. Amazon menjelaskan mengapa mekanisme percobaan ulang memerlukan perlindungan khusus terhadap efek samping yang berulang. Agen menambahkan entitas pengambil keputusan baru ke dalam jalur pemulihan sistem Anda. Agen dapat mengambil keputusan tambahan tentang cara memulihkan sistem dari kesalahan.

Keputusan ini dapat mengubah cara bisnis beroperasi. Misalnya, mencoba kembali pengembalian dana dengan jumlah uang yang berbeda bukan sekadar pengulangan permintaan yang sama. Begitu pula, memilih layanan pembayaran kedua ketika layanan pertama berhenti merespons bukan sekadar pengulangan permintaan yang sama.

Tim harus membedakan antara pemberian izin untuk menjalankan suatu tindakan dan pemberian izin untuk memulihkan sistem ketika hasilnya tidak diketahui. Persetujuan awal tidak berarti bahwa menjalankan tindakan itu sekali lagi aman.

Penelitian Terkini Mengukur Risikonya

Pracetak September 2026 berjudul “Where Does Exactly-Once Live?” memperkenalkan tolok ukur LIMBO dan menguji 25.930 episode pada sembilan model. Layanan simulasinya diuji dengan konfirmasi yang hilang, pemrosesan tertunda, dan pengiriman duplikat.

Dari 1.279 episode dalam pengujian utama penulis yang menghasilkan efek duplikat, agen melaporkan keberhasilan penyelesaian dalam 90% kasus. Dengan demikian, agen dapat melaporkan keberhasilan meskipun pemrosesan yang keliru telah terjadi.

Hasil ini didasarkan pada tolok ukur terkontrol dan tidak memperkirakan tingkat kegagalan dalam produksi. Layanan tersebut disimulasikan, dan beberapa analisis bersifat eksploratif. Tim sebaiknya mengevaluasi hasil tindakan agen secara terpisah dari laporan agen tentang keberhasilan pelaksanaan.

Makalah tersebut juga membahas alasan pemeriksaan keadaan terkini bisa saja tidak memadai. Permintaan yang masih diproses dapat berlaku setelah pemeriksaan dilakukan. Bahkan respons status kosong tidak berarti bahwa permintaan itu pada akhirnya tidak akan berlaku.

Percobaan Berulang Mengacu pada Maksud yang Sama

Layanan penerima dapat mengenali percobaan berulang untuk satu operasi dengan menggunakan kunci idempotensi. Jika didukung dengan benar, metode ini memastikan bahwa percobaan berulang tidak menimbulkan efek tambahan. Kunci idempotensi harus tetap sama selama semua percobaan ulang.

Dokumentasi API Stripe memberikan contoh mekanisme sekaligus keterbatasan kunci idempotensi. Untuk API v1, kunci dapat dihapus setelah setidaknya 24 jam. Penggunaan kembali kunci yang telah dihapus akan memicu permintaan baru. Stripe juga memverifikasi bahwa parameter yang diberikan pemohon cocok dengan parameter dalam permintaan awal.

Penerapan praktis idempotensi secara menyeluruh terletak pada lapisan integrasi Anda, bukan hanya di dalam prompt. Sebelum mengirimkan suatu operasi, catat operasi yang telah disetujui. Simpan pengenal operasi, parameter persisnya, referensi penyedia jika ada, serta status operasi tersebut.

Untuk pengembalian dana, simpan hubungan antara persetujuan dan transaksi awal, serta pengenal pengembalian dana dari penyedia yang dikembalikan. Mencari pengembalian dana dengan jumlah yang sama bukanlah bukti yang meyakinkan karena dua permintaan yang sah dapat memiliki jumlah yang sama. Hasil pencarian juga dapat terlambat menampilkan pengembalian dana setelah permintaannya diajukan. Permintaan awal mungkin masih diproses.

Ketika agen atau pekerja dimulai ulang, lapisan eksekusi harus mempertahankan identitas tersebut. Lapisan itu harus menolak permintaan yang telah diubah tetapi diajukan sebagai operasi yang sama. Perubahan semacam itu merupakan tindakan baru yang memerlukan keputusan persetujuan baru sesuai aturan alur kerja.

Deskripsi Alat Saja Tidak Cukup

Selain memeriksa deskripsi alat, verifikasikan kontrak layanan penerima terkait dukungan idempotensi. Uji penerapannya untuk memastikan jaminan apa yang benar-benar dipenuhi.

Perlakukan Ketidakpastian sebagai Keadaan Operasional

Gambar 1. Usulan jalur pemulihan untuk tindakan yang berdampak penting. Setiap percobaan ulang juga memerlukan otorisasi yang masih berlaku.

Penyelesaian yang terkonfirmasi berarti alur kerja akan mencatat hasilnya dan berlanjut tanpa mengulangi tindakan tersebut. Ketidakberjalanan yang terkonfirmasi hanya memungkinkan percobaan lain jika tidak ada permintaan awal yang masih tertunda dan otorisasi masih berlaku.

Ada banyak hal lain yang perlu dipertimbangkan ketika hasilnya belum dapat dipastikan. Jika ada jaminan sah yang didukung penyedia bahwa efek tindakan tidak akan terjadi lebih dari sekali, Anda dapat mengizinkan permintaan awal dicoba kembali dengan kunci yang sama. Jika tidak, hentikan sementara penulisan dan lakukan rekonsiliasi melalui kueri status, dukungan penyedia, atau operator yang berwenang. Pemeriksaan yang hasilnya tidak meyakinkan bukan alasan yang cukup untuk mengizinkan percobaan lain.

Menjeda proses juga dapat dibenarkan jika penyedia mendokumentasikan batas waktu pemrosesan dan visibilitas. Tanpa batasan tersebut, berlalunya waktu saja tidak akan memastikan bahwa tindakan itu tidak dijalankan. Anda harus menentukan siapa yang bertanggung jawab atas kasus-kasus yang belum terselesaikan dan kapan mereka harus meninjaunya.

Pemulihan dari Kegagalan Mungkin Memerlukan Proses Bisnis yang Berbeda

Jika pengembalian dana berhasil, tetapi pemberitahuan kepada pelanggan setelahnya gagal, mengulangi seluruh alur kerja dapat menyebabkan pengembalian dana diberikan lagi. Pemulihan sebaiknya berfokus pada penyelesaian langkah yang belum tuntas sambil menyimpan bukti pekerjaan yang sudah diselesaikan.

Jika tindakan korektif diperlukan untuk tindakan yang telah selesai, Microsoft memberikan panduan tentang transaksi kompensasi. Setiap aplikasi menentukan cara yang tepat untuk mengompensasi kesalahan. Kompensasi belum tentu mengembalikan keadaan seperti semula, dan proses kompensasi itu sendiri dapat gagal.

Selain itu, pembatalan transaksi dapat menimbulkan biaya. Memperbaiki pesan tidak menjamin bahwa seseorang belum melihat versi sebelumnya. Karena itu, setiap aktivitas pemulihan harus secara tegas membatasi hal-hal yang dapat dibatalkan, diubah, atau disanggupi oleh agen. Keputusan di luar batasan tersebut harus diserahkan kepada orang yang memiliki wewenang yang diperlukan.

Uji Percobaan Kedua Sebelum Penerapan

Pilih satu alat yang dapat menimbulkan konsekuensi penting, lalu lakukan pengujian pemulihan secara sengaja di lingkungan pengujian. Setelah eksekusi berhasil, hilangkan respons terhadap permintaan awal. Tunda eksekusi permintaan pertama hingga setelah pemeriksaan status. Selama pemulihan, mulai ulang pekerja. Tunggu hingga masa retensi kunci berakhir sebelum mencoba lagi. Ubah satu parameter selama percobaan berulang.

Evaluasi catatan bisnis yang dihasilkan, bukan hanya mengandalkan respons alat. Catat efek duplikat, operasi yang belum terselesaikan, pekerjaan yang terlewat, waktu pemulihan, dan intervensi manual tambahan. Hitung biaya per tugas yang diselesaikan dengan benar berdasarkan total biaya alur kerja, termasuk pembalikan transaksi dan kompensasi bagi pelanggan.

Selain itu, uji permintaan kedua yang benar-benar baru tetapi serupa dengan permintaan awal. Pastikan sistem Anda tidak membuat duplikat tanpa menghalangi pekerjaan baru. Nilai pencegahan duplikasi dan penyelesaian tugas pada akhirnya secara terpisah. Jika tidak, agen yang menghentikan setiap tugas dapat tampak aman, padahal hanya memberikan sedikit atau bahkan tidak memberikan nilai sama sekali.

Pertanyaan evaluasi Anda harus dirumuskan dengan jelas. Apakah sistem mampu menjelaskan:

• Operasi mana yang diotorisasi?
• Bukti apa yang tersedia untuk menunjukkan hasilnya?
• Mengapa percobaan lain boleh dilakukan?

Agen yang menjeda proses karena ketidakpastian yang belum terselesaikan mungkin tampak kurang efektif saat demonstrasi. Namun, di lingkungan produksi, jeda dapat menjaga maksud awal pelanggan. Persistensi yang berguna berarti sistem menyelesaikan tugas yang diotorisasi tanpa diam-diam menjalankannya lebih dari sekali.