Async-RBench menguji cara agen AI mengelola subagen yang bekerja tidak serentak

Sebuah makalah pracetak di arXiv memperkenalkan Async-RBench, tolok ukur (benchmark) untuk menilai cara agen berbasis model bahasa besar menangani pekerjaan yang berjalan tidak serentak. Penulisnya, Detao Zeng dan tujuh rekan, melaporkan bahwa sembilan agen yang diuji menunjukkan kinerja terbatas. Kelemahan paling menonjol muncul saat agen menghadapi laporan ganda dan kegagalan subagen.

Apa itu eksekusi asinkron

Menurut abstrak, agen model bahasa besar (LLM) kian sering bekerja secara asinkron. Artinya, agen utama terus bekerja selagi subagen masih berjalan. Subagen adalah agen pembantu yang diberi bagian tugas. Akibatnya, keadaan tugas bisa sudah berubah ketika hasil subagen akhirnya tiba.

Bayangkan seorang koordinator proyek yang menyerahkan beberapa pekerjaan ke anggota tim, lalu terus mengerjakan bagiannya sendiri. Ketika laporan anggota tim masuk, koordinator harus menimbang pekerjaan mana yang perlu diperbarui, mana yang dipertahankan, dan pemeriksaan mana yang harus diulang. Ia juga harus menghindari perubahan yang dilarang. Perumpamaan ini dari kami untuk memudahkan penjelasan, bukan dari makalah.

Para peneliti menyebut dua kesulitan pengukuran. Pertama, keberhasilan tugas akhir saja tidak menunjukkan apakah hasil subagen ditangani dengan benar. Kedua, kedatangan hasil yang terjadi secara alami sulit direproduksi, hal yang menyulitkan pengujian berulang dalam kondisi yang sama.

Rancangan tolok ukur

Async-RBench memuat 200 tugas yang dapat dijalankan (executable tasks) dan mencakup delapan skenario. Abstrak tidak merinci jenis tugas atau isi kedelapan skenario itu, sehingga kami tidak menguraikannya lebih jauh.

Pengendali skenario (scenario controller) mengatur kapan hasil subagen disampaikan. Pengaturan itu berdasarkan kondisi keadaan tugas yang ditetapkan lebih dulu. Mekanisme ini tampaknya dirancang untuk menjawab masalah reproduksi yang disebut sebelumnya.

Penilaian bertumpu pada Event Response Contract (ERC), yakni kontrak yang menetapkan hal-hal yang harus diubah, dipertahankan, dihindari, dan diverifikasi ulang pada setiap tanggapan. Metrik yang diperkenalkan, Dynamic Replanning Score (DRS), memberi bobot setara pada proses tanggapan dan hasil akhirnya. DRS dilaporkan terpisah dari keberhasilan tugas.

Temuan utama

Penulis menguji sembilan agen dan mendapati skor DRS berkisar 19,2 hingga 45,1. Abstrak tidak menyebut skala maksimum skor ini. Skor terendah muncul pada laporan ganda (duplicate reports) dan kegagalan subagen. Abstrak juga tidak menyebut nama model atau agen yang diuji.

Dalam protokol eksekusi mereka, kesembilan agen memperoleh keberhasilan tugas lebih rendah pada pengiriman asinkron dibandingkan pengiriman sekaligus (batched), yaitu ketika semua hasil disampaikan bersamaan. Rata-ratanya 26,0% untuk asinkron dan 29,7% untuk pengiriman sekaligus.

Penulis juga mencoba satu cara tambahan pada tiga agen: meminta agen utama menyusun ulang rencananya setiap kali satu hasil masuk. Cara ini hanya menaikkan DRS sebesar 2,6 hingga 3,5 poin. Menurut penulis, temuan ini menunjukkan sulitnya eksekusi asinkron yang andal. Mereka juga menilai cara agen menangani hasil yang masuk perlu dinilai berdampingan dengan keberhasilan tugas ujung ke ujung.

Catatan kritis

Makalah ini baru berstatus pracetak versi pertama di arXiv, diajukan pada 23 Oktober 2026, dan belum ditelaah sejawat. Angka-angkanya adalah klaim penulis yang belum diverifikasi pihak independen. Kami juga hanya membaca abstrak dan halaman metadata, bukan seluruh 25 halaman makalah.

Beberapa hal penting belum terjawab dari bahan yang ada. Di antaranya identitas kesembilan agen, komposisi tiap skenario, serta cara ERC disusun dan divalidasi. Selisih keberhasilan 26,0% dan 29,7% juga dinyatakan berlaku dalam protokol eksekusi penulis. Karena itu, angka tersebut belum tentu mencerminkan perilaku agen di lingkungan produksi.

Kaitan dan langkah berikutnya

Abstrak menggambarkan agen yang menjalankan subagen sambil terus bekerja sebagai pola yang makin umum. Makalah ini tidak menyebut produk komersial tertentu, sehingga kami tidak mengaitkannya dengan produk mana pun. Argumen penulis relevan bagi pengembang: menilai keberhasilan akhir tugas saja bisa menutupi kesalahan penanganan hasil di tengah jalan.

Penulis menyatakan kode tersedia melalui tautan di halaman arXiv. Pembaca teknis dapat memeriksa tolok ukur ini langsung. Ujian berikutnya adalah apakah hasilnya bertahan pada replikasi atau telaah sejawat.