Orkestrasi Agen AI: Kegagalan, Persetujuan, dan Percobaan Ulang

Memiliki beberapa agen yang mengerjakan proyek yang sama terdengar sangat efisien. Satu agen merencanakan pekerjaan, agen lain menangani desain, dan agen ketiga menulis kode. Semuanya berjalan lancar sampai tiba-tiba tidak. Dan kegagalan terjadi lebih sering daripada yang Anda harapkan.

Mencegah kegagalan ini memerlukan rekayasa alur kerja yang cermat. Jadi, mari kita uraikan apa yang membuat alur kerja terorkestrasi tidak andal dan pelajari praktik terbaik orkestrasi untuk keandalan di lingkungan produksi.

Orkestrasi agen AI mengoordinasikan beberapa agen AI, model, dan alat untuk menyelesaikan tugas multilangkah. Namun, seseorang — atau sesuatu — tetap perlu memutuskan agen mana yang berjalan lebih dulu, informasi apa yang diterimanya, dan apa yang terjadi setelah agen tersebut selesai. Inilah peran orkestrator — agen AI yang bertindak sebagai manajer atau lapisan eksekusi yang dikendalikan perangkat lunak.

Secara sederhana, lapisan orkestrasi memecah tujuan menjadi tugas-tugas yang lebih kecil, melacak dependensi, mendelegasikan eksekusi ke agen yang tepat, mengelola konteks bersama, dan menyatukan output.

Diagram mesin eksekusi orkestrasi: tujuan dan rencana, perutean ke agen, eksekusi alat secara terisolasi, hasil terstruktur, status alur kerja persisten, serta langkah validasi dan keputusan yang mencoba ulang, mengembalikan, menjeda, menunggu, atau melanjutkan ke tugas berikutnya.

Mari kita lihat apa yang terjadi setelah Anda memberikan tugas kepada orkestrator.

Ambil contoh dari lokakarya Computer Perplexity: membangun dasbor intelijen akun menggunakan informasi dari Salesforce, Snowflake, email, kalender, dan berita terbaru.

Pahami tujuan dan rencanakan pekerjaan. Orkestrator memulai dari hasil yang diminta dan menguraikannya menjadi tugas-tugas dengan dependensi eksplisit. Dalam contoh dasbor kita, hal itu mencakup pengumpulan informasi dari berbagai sumber dan mengubahnya menjadi hasil akhir yang siap digunakan. Perencana menentukan langkah mana yang bergantung pada langkah lain dan mana yang dapat berjalan secara independen.
Rutekan tugas ke agen yang sesuai. Orkestrator mengidentifikasi tugas yang dependensinya sudah terpenuhi dan mendelegasikan pekerjaan ke agen atau model khusus. Tugas yang bergantung pada tugas lain menunggu prasyaratnya selesai. Perplexity Computer menggunakan beberapa model frontier, merutekan bagian-bagian alur kerja yang berbeda ke sistem yang sesuai untuk tugas tersebut. Hal ini juga memungkinkan pekerjaan independen berjalan secara paralel.
Eksekusi panggilan alat di dalam lingkungan yang terkendali. Agen berinteraksi dengan lingkungannya melalui alat, seperti pencarian web, API, aplikasi yang terhubung, operasi file, atau eksekusi kode. Lapisan eksekusi menjalankan tindakan ini dan mengembalikan hasilnya ke agen.
Teruskan hasil dan konteks antar-agen. Setelah agen menyelesaikan tugasnya, agen hilir berikutnya memerlukan output yang relevan untuk melanjutkan. Catatan serah terima dapat berisi ID tugas, referensi output, versi skema, dan metadata sumber. Orkestrator mengoordinasikan serah terima ini sambil mempertahankan konteks yang diperlukan untuk langkah-langkah selanjutnya. Yang penting, agen tidak perlu membawa seluruh riwayat pekerjaan setiap agen lain di jendela konteksnya sendiri.
Catat status eksekusi secara terpisah dari konteks agen. Saat agen memulai, menyelesaikan, atau gagal menjalankan tugas, mesin eksekusi memperbarui catatan alur kerja persisten dengan status tugas, upaya eksekusi, referensi output, dan pekerjaan yang tersisa. Catatan ini memungkinkan orkestrator melacak progres dan melanjutkan setelah gangguan tanpa bergantung pada LLM untuk merekonstruksi alur kerja dari riwayat percakapan.
Validasi hasil dan putuskan langkah selanjutnya. Saat sebuah tugas selesai, lapisan orkestrasi memeriksa apakah outputnya memenuhi kontrak yang diharapkan dan apakah dependensi tugas berikutnya sudah terpenuhi. Jika ditemukan masalah, alur kerja dapat kembali ke langkah sebelumnya untuk diperbaiki atau dijeda. Jika tidak, alur kerja terus berjalan hingga selesai.

Banyak komponen yang bekerja di balik orkestrasi agen AI yang tampak sederhana. Cara Anda mengatur koordinasi agen menentukan seberapa besar kendali Anda atas eksekusi. Dan tentu saja, semua koordinasi itu menambah overhead. Jadi, orkestrasi tidak selalu sepadan.

Pertimbangkan orkestrasi multiagen jika bagian-bagian tugas yang berbeda memerlukan keahlian yang berbeda, pekerjaan independen dapat berjalan secara paralel, atau Anda tidak dapat menentukan langkah berikutnya sejak awal.

Jadi, orkestrasi bermanfaat dalam tiga skenario:

Tugas memerlukan spesialisasi yang berbeda. Proyek pemrograman, misalnya, dapat memperoleh manfaat dari agen perencanaan, desain, pengembangan, dan peninjauan yang terpisah.
Tugas independen dapat berjalan secara paralel. Alih-alih meminta satu agen menyelesaikan semuanya secara berurutan, beberapa agen dapat bekerja secara bersamaan dan mengembalikan hasilnya ke orkestrator.
Masalahnya bersifat terbuka. Agen mungkin perlu menjelajahi berbagai pendekatan, mengambil keputusan, dan berkolaborasi alih-alih mengikuti urutan yang telah ditentukan.

Di luar itu, orkestrasi hanyalah tren yang mahal. Lebih banyak agen juga berarti lebih banyak koordinasi dan berpotensi meningkatkan biaya token.

“Saya biasanya memulai dengan opsi paling sederhana lalu mengembangkannya dari sana. Jika kita sudah tahu langkah-langkahnya dan langkah-langkah itu dapat diulang, kemungkinan besar itu adalah alur kerja. Saya hanya melihat alasan untuk menggunakan beberapa agen jika masing-masing memiliki tanggung jawab, izin, atau pengguna yang berbeda,” kata Josh Spilker, kepala pemasaran pencarian di AirOps.

Meski begitu, timbang manfaatnya dengan tambahan panggilan model, serah terima, latensi, dan titik kegagalan.

Ada tiga cara umum untuk menyusun koordinasi agen — orkestrasi terpusat, terdesentralisasi, dan hierarkis. Memilih arsitektur yang tepat bermuara pada satu pertanyaan: Siapa yang mengendalikan pekerjaan, dan bagaimana agen berkoordinasi satu sama lain?

Dalam orkestrasi terpusat, satu orkestrator mengelola prosesnya. Orkestrator memecah tugas, mendelegasikan pekerjaan ke agen spesialis, melacak progres mereka, dan menyatukan hasilnya.

Diagram orkestrasi terpusat: satu orkestrator menerima permintaan pengguna dan mendelegasikannya ke agen riset, analisis, dan desain, masing-masing menggunakan alatnya sendiri, yang hasilnya digabungkan menjadi dasbor akhir.

Komprominya: Koordinasi terpusat memudahkan pelacakan eksekusi dan penerapan aturan umum di satu titik kendali. Namun, orkestrator dapat menjadi hambatan, dan kegagalannya dapat mengganggu seluruh alur kerja kecuali sistem mendukung pemulihan.

Dalam orkestrasi terdesentralisasi, agen berkoordinasi secara lebih langsung alih-alih mengandalkan satu manajer untuk membuat setiap keputusan. Agen dapat bertukar pesan, membaca status bersama, dan secara mandiri menentukan langkah berikutnya.

Diagram orkestrasi terdesentralisasi: agen riset, analisis, desain, dan peninjauan berkomunikasi langsung satu sama lain serta dengan status dan alat bersama untuk menghasilkan dasbor akhir.

Komprominya: Agen dapat beroperasi tanpa menunggu perencana pusat, sehingga pendekatan ini berguna untuk pekerjaan eksploratif dan kontribusi independen. Namun, koordinasi menjadi lebih sulit saat agen berbeda pendapat, memperbarui informasi bersama, atau perlu mencapai hasil yang konsisten.

Orkestrasi hierarkis memperluas pendekatan manajer ke beberapa tingkat. Orkestrator tingkat atas mendelegasikan tanggung jawab ke orkestrator bawahan, yang mengoordinasikan kelompok agen spesialisnya masing-masing.

Bayangkan alur kerja perusahaan yang melibatkan tim penjualan, keuangan, dan hukum. Orkestrator tingkat atas dapat mendelegasikan setiap alur kerja proyek ke koordinator khusus domain. Koordinator tersebut kemudian akan mengelola agen spesialisnya sendiri dan melaporkan hasil gabungan.

Struktur ini dapat membantu saat alur kerja terlalu luas untuk dikelola secara efektif oleh satu orkestrator.

Diagram orkestrasi hierarkis: orkestrator tingkat atas mendelegasikan ke orkestrator penjualan, keuangan, dan hukum, masing-masing mengelola dua agen spesialis, yang pekerjaannya digabungkan menjadi output terkonsolidasi.

Komprominya: Hierarki memungkinkan tim membagi tanggung jawab koordinasi dan berpotensi menangani kegagalan di dalam cabang masing-masing. Namun, hierarki menambah serah terima, manajemen status yang lebih kompleks, dan overhead operasional yang lebih besar. Pemulihan lokal juga bergantung pada cara checkpoint dan status eksekusi diimplementasikan.

Perbandingan arsitektur-arsitektur ini:

Kriteria	Terpusat	Terdesentralisasi	Hierarkis
Kepemilikan eksekusi	Satu orkestrator mengendalikan delegasi	Agen berkoordinasi melalui sesama agen atau status bersama	Tanggung jawab didistribusikan ke berbagai tingkat orkestrasi
Konsistensi status	Lebih mudah dikoordinasikan melalui satu titik kendali	Memerlukan sinkronisasi eksplisit dan penanganan konflik	Memerlukan koordinasi di dalam dan antarcabang
Isolasi kegagalan	Pengendali pusat dapat menjadi dependensi kritis	Masing-masing agen dapat gagal secara independen, tetapi infrastruktur bersama tetap krusial	Kegagalan dapat dibatasi di dalam cabang jika dirancang untuk pemulihan
Penegakan kebijakan	Kontrol umum dapat ditegakkan secara terpusat	Kebijakan harus ditegakkan secara konsisten di semua peserta	Kontrol dapat diterapkan di tingkat global dan domain
Kompleksitas operasional	Umumnya lebih rendah	Kompleksitas koordinasi lebih tinggi	Kompleksitas lebih tinggi akibat beberapa lapisan orkestrasi

Ada satu perbedaan lagi yang perlu dipahami. Arsitektur menentukan siapa yang mengoordinasikan agen. Pola eksekusi menentukan bagaimana tugas-tugas mereka berjalan.

Berikut tiga pola eksekusi:

Alur kerja berurutan: Agen bekerja dalam urutan yang telah ditentukan, dengan hasil dari satu agen menjadi input bagi agen lainnya.
Eksekusi paralel: Agen-agen independen bekerja secara bersamaan.
Eksekusi berbasis serah terima: Kendali berpindah di antara agen spesialis seiring berjalannya tugas. Ini berguna ketika agen lain lebih siap menangani langkah berikutnya, meskipun setiap serah terima harus mempertahankan informasi yang diperlukan untuk melanjutkan.

Pola-pola ini tidak saling eksklusif, dan tidak memiliki padanan satu-satu dengan arsitektur orkestrasi. Tujuannya adalah memilih struktur paling sederhana yang mendukung dependensi alur kerja Anda, kebutuhan koordinasi, dan overhead operasional yang dapat diterima.

Apa pun bisa salah dalam orkestrasi, mulai dari kelalaian sederhana hingga hambatan yang rumit. Terkadang, sebuah agen bahkan tampak menjalankan tugasnya dengan benar sementara alur kerja secara keseluruhan gagal. Berdasarkan pengalaman para praktisi, kami telah merangkum beberapa kesalahan umum di balik alur kerja terorkestrasi yang tidak andal — waspadai hal-hal berikut:

Serah terima agen yang kehilangan informasi. Orkestrator meneruskan ringkasan rencana kepada agen spesialis, tetapi ringkasan tersebut menghilangkan batasan, dependensi, atau detail implementasi.
Eksekusi fan-in yang prematur. Agen hilir mulai menggabungkan hasil sebelum semua tugas hulu selesai.
Pembaruan status bersama yang nondeterministik. Agen-agen paralel menulis ke kunci status yang sama tanpa semantik penggabungan yang jelas. Bergantung pada cara framework menangani pembaruan, hal ini dapat mengakibatkan penulisan yang hilang, data duplikat, output yang bergantung pada urutan, atau perubahan yang saling bertentangan.
Divergensi checkpoint dan efek samping. Sebuah tugas menjalankan operasi eksternal, tetapi keberhasilan eksekusinya tidak dicatat secara persisten sebelum worker gagal. Saat pemulihan, orkestrator melihat tugas yang belum selesai dan menjalankannya ulang.
Race condition saat melanjutkan setelah persetujuan manusia. Menjeda dan melanjutkan eksekusi menimbulkan masalah sinkronisasinya sendiri.
Loop delegasi dan amplifikasi percobaan ulang. Agen berulang kali saling melempar pekerjaan karena tanggung jawab mereka tumpang tindih, dependensinya melingkar, atau kondisi penyelesaiannya ambigu.
Kontrol tingkat instruksi yang disalahartikan sebagai keamanan eksekusi. Orkestrator mungkin memberi tahu agen untuk tidak mengakses sumber daya tertentu atau melakukan tindakan sensitif, tetapi instruksi model tidak menegakkan izin sistem operasi, pembatasan jaringan, atau batas otorisasi. Penelitian rekayasa keamanan Perplexity menyoroti mengapa agen dapat melintasi batas keamanan saat mengejar tujuan yang sah, bahkan tanpa instruksi berbahaya

Perhatikan betapa berbedanya kegagalan-kegagalan ini. Transisi penjadwal yang prematur atau penulisan eksternal yang ambigu sama-sama dapat menghasilkan hasil yang salah, tetapi keduanya berasal dari bagian siklus hidup eksekusi yang berbeda. Itulah sebabnya orkestrasi yang andal membutuhkan lebih dari sekadar memperbaiki prompt atau menambahkan percobaan ulang.

Tujuan yang samar dan definisi selesai yang tidak jelas sering kali menghasilkan output agen yang mengecewakan. Solusinya adalah kontrak prompt (lingkup kerja untuk agen): sepakati tujuan, batasan, format output, dan kondisi kegagalan sebelum eksekusi dimulai.

Misalnya, berikut cara Anda dapat menetapkan kontrak untuk agen yang bertugas memperbaiki tes integrasi yang gagal secara sporadis:

Tujuan: Mengidentifikasi dan memperbaiki penyebab tes integrasi API checkout yang flaky.
Input: Kode sumber tes, log kegagalan CI, commit terbaru, dan kode aplikasi yang relevan.
Batasan: Jangan menonaktifkan tes, melonggarkan asersi, atau mengubah perilaku aplikasi yang tidak terkait.
Output yang diharapkan: Patch kode, penjelasan akar penyebab, dan hasil eksekusi tes.
Kriteria penerimaan: Tes yang sebelumnya gagal lulus dalam 10 kali eksekusi berturut-turut, dan rangkaian tes regresi yang relevan lulus.
Kondisi kegagalan: Akar penyebab tidak dapat dipastikan, perbaikan menimbulkan regresi, atau lingkungan tes yang diperlukan tidak tersedia.

Namun, ada satu bagian penting lainnya: kapan agen harus berhenti?

Agen tidak boleh terus beriterasi tanpa batas hanya karena belum menghasilkan hasil yang memuaskan. Tentukan apa yang dianggap sebagai penyelesaian yang berhasil, kapan harus mengembalikan tugas yang baru selesai sebagian, dan kapan harus berhenti karena suatu persyaratan tidak dapat dipenuhi. Tetapkan kedalaman delegasi maksimum dan batas iterasi atau anggaran eksekusi agar tugas yang belum terselesaikan tidak menjadi loop tanpa akhir.

Kembali ke contoh CI kita. Anda dapat menetapkan kondisi berhenti berikut:

Berhasil: Perbaikan lulus dalam 10 kali eksekusi tes berturut-turut dan rangkaian tes regresi yang relevan.
Batas iterasi: Agen dapat mencoba paling banyak dua kandidat perbaikan.
Anggaran eksekusi: Agen harus berhenti setelah 60 menit, meskipun masalahnya belum terselesaikan.
Batas delegasi: Agen dapat mendelegasikan pekerjaan ke satu agen spesialis, tanpa delegasi lebih lanjut ke subagen.
Penyelesaian sebagian: Jika kedua percobaan gagal atau batas waktu habis, agen mengembalikan temuannya, perubahan yang telah dicoba, dan hasil tes.
Eksekusi terblokir: Jika lingkungan tes tidak tersedia, agen berhenti dan melaporkan hambatannya alih-alih mengklaim berhasil.

Terkadang developer memberikan terlalu banyak tanggung jawab kepada orkestrator, dan alih-alih mengoordinasikan agen spesialis, orkestrator mulai menulis kode, melakukan debugging, atau melakukan peninjauan mendetail sendiri. Hal ini menciptakan bottleneck: orkestrator menghabiskan anggaran konteksnya untuk detail implementasi, menunda delegasi, dan mengaburkan tanggung jawab atas hasilnya.

Jadi, biarkan orkestrator menjalankan tugasnya dan tegakkan serah terima dengan merujuk pada artefak konkret: tugas awal, input yang relevan, artefak output, status eksekusi, dan masalah apa pun yang belum terselesaikan.

Perhatikan contoh ini: status: completed merujuk pada pekerjaan yang ditugaskan kepada agen, bukan keseluruhan alur kerja. Karena tes masih pending, orkestrator tidak boleh menyetujui hasil akhir.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

Riwayat percakapan agen bukanlah catatan yang andal tentang kemajuan alur kerja. Saat jendela konteksnya penuh, pemadatan otomatis dapat menghilangkan detail penting. Dan jika worker mengalami crash, agen berikutnya perlu tahu langkah mana yang benar-benar telah diselesaikan.

Misalnya, jika agen coding menghasilkan patch lalu mengalami crash, worker berikutnya harus mengambil artefak yang tersimpan dan melanjutkan dari status alur kerja yang tercatat. Namun, jika agen tersebut juga memicu eksekusi CI eksternal, orkestrator harus merekonsiliasi eksekusi tersebut secara terpisah sebelum mengulangi tindakan

Jadi, pisahkan status eksekusi dari konteks kerja agen. Simpan status tugas, percobaan eksekusi, langkah yang telah selesai, dan referensi artefak di penyimpanan persisten. Sementara itu, muat hanya instruksi, input, dan hasil yang relevan dengan tugas agen saat ini, alih-alih menjejalkan seluruh riwayat eksekusi ke dalam jendela konteksnya.

Misalkan agen CI Anda memicu eksekusi tes, tetapi permintaan API mengalami timeout. Apakah eksekusi tes gagal dimulai, atau layanan CI telah memasukkannya ke antrean lalu kehilangan responsnya?

Timeout tidak selalu berarti operasi gagal. Karena itu, Anda perlu membedakan jenis error sebelum memutuskan langkah berikutnya:

Error sementara (429, 503): Coba ulang dengan exponential backoff terbatas dan jitter, dengan mematuhi Retry-After jika tersedia.
Error validasi atau izin (400, 403): Hentikan atau perbaiki masalah yang mendasarinya alih-alih mengulangi permintaan yang sama.
Hasil yang ambigu (timeout setelah kemungkinan terjadi penulisan): Periksa apakah operasi berhasil sebelum mencobanya lagi.

Catatan: Bahkan error yang dapat dicoba ulang pun memerlukan batas. Tetapkan timeout untuk setiap panggilan alat, batasi jumlah percobaan ulang dan total waktu percobaan ulang, serta tegakkan tenggat waktu alur kerja secara keseluruhan agar agen bertingkat tidak terus memulai ulang operasi yang sama. Jika sebuah dependensi berulang kali gagal, gunakan circuit breaker untuk menghentikan permintaan sementara.

Untuk operasi dengan efek samping eksternal, tetapkan kunci idempotensi yang stabil untuk setiap tindakan logis dan gunakan kembali kunci tersebut di setiap percobaan ulang. Jika API mendukung deduplikasi sisi server, API dapat mengenali permintaan berulang tanpa melakukan tindakan dua kali. Jika tidak, kueri sistem eksternal menggunakan ID korelasi atau referensi otoritatif lainnya.

Jika Anda tidak dapat memastikan apa yang terjadi, hentikan dan lakukan eskalasi.

Contoh logika percobaan ulang untuk agen CI kita, dinyatakan dalam pseudocode:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

Catatan kode: Contoh ini mengasumsikan bahwa API CI mendukung pencarian eksekusi berdasarkan ID permintaan. Nilai request_id hanya mencegah duplikasi jika penyedia secara eksplisit menjamin idempotensi. bounded_retry() adalah pseudocode ilustratif. Di lingkungan produksi, percobaan ulang harus dibatasi oleh anggaran percobaan ulang per operasi (jumlah percobaan maksimum atau waktu yang telah berlalu) sekaligus tenggat waktu alur kerja secara keseluruhan.

Untuk alur kerja yang lebih panjang yang mencakup beberapa layanan, pertimbangkan pola Saga untuk mengoordinasikan tindakan kompensasi ketika langkah-langkah selanjutnya gagal. Ingatlah bahwa kompensasi tidak selalu berarti rollback total. Anda dapat membatalkan pembaruan database, tetapi Anda tidak dapat menarik kembali email yang sudah terkirim.

Ada dua hal yang perlu diseimbangkan di sini: seberapa besar kemampuan model yang dibutuhkan setiap tugas dan berapa banyak tugas yang dapat Anda jalankan secara bersamaan. Jika salah satunya keliru, Anda berisiko membuat agen saling berebut kuota API bersama atau hanya mengandalkan model penalaran yang mahal.

Untuk pemilihan model, sesuaikan kemampuan model dan upaya penalaran dengan kompleksitas tugas — sederhana tetapi cukup sering diabaikan. Perhatikan bahwa Anda dapat mengonfigurasi aturan perutean dan mengevaluasi model sendiri, atau menggunakan platform orkestrasi yang menangani pemilihan model untuk Anda.

Misalnya, Effort Mode di Perplexity Computer memungkinkan Anda memilih seberapa besar upaya yang layak untuk suatu tugas tanpa harus memilih model secara manual. Pilih Light, Standard, High, atau Ultra, dan Perplexity akan secara otomatis memilih model pengorkestrasi beserta tingkat penalarannya. Orkestrator tersebut kemudian mendelegasikan subtugas ke agen pendukung, yang dapat menggunakan model dari berbagai penyedia.

Perplexity mengevaluasi konfigurasi model berdasarkan kualitas dan biaya, dengan mengutamakan opsi yang lebih murah yang memberikan hasil sebanding. Anda juga dapat menggunakan kontrol Custom jika ingin memilih model dan tingkat penalaran sendiri.

Untuk paralelisme, batasnya harus ditentukan oleh infrastruktur dan dependensi eksternal Anda. Validasi batas laju permintaan dan token dari API bersama, lalu lakukan uji beban pada alur kerja Anda dengan konkurensi yang terus ditingkatkan. Amati apakah throughput meningkat atau apakah permintaan mulai mengantre, melambat, atau mengembalikan error 429.

Agar konsumsi sumber daya tetap dapat diprediksi, tegakkan batas sumber daya dan kontrol penjadwalan:

Kendalikan konkurensi dan laju permintaan: Batasi panggilan yang sedang berjalan per layanan dan masukkan kelebihan pekerjaan ke antrean. Ingat bahwa batas konkurensi saja tidak akan menegakkan batas permintaan per menit atau token per menit.
Lacak anggaran token dan biaya: Perhitungkan penggunaan di seluruh alur kerja, termasuk subagen, dan berhenti meluncurkan pekerjaan baru ketika sisa anggaran tidak mencukupi.
Tegakkan tenggat waktu eksekusi: Tetapkan batas waktu tugas dan alur kerja, serta teruskan pembatalan ke agen yang sedang berjalan jika didukung.
Hormati dependensi: Mulai tugas hilir hanya ketika input yang diperlukannya sudah tersedia, alih-alih meluncurkan semua agen secara bersamaan.

Jangan pernah meminta model untuk memutuskan apakah tindakannya sendiri aman. Sebaliknya, berikan agen izin dengan hak akses minimum (least privilege) dan tegakkan aturan persetujuan berbasis risiko di kode aplikasi. Jika agen mengeksekusi kode, isolasi eksekusi tersebut dari lingkungan host Anda dan batasi akses ke file, jaringan, dan kredensial. Hal ini membatasi kerusakan jika agen membuat kesalahan atau mengeksekusi kode yang tidak aman.

“Saya skeptis terhadap sistem multiagen yang terlalu rumit, terutama ketika agen-agen saling meninjau dan menyetujui pekerjaan satu sama lain. Pada akhirnya, Anda bisa mendapati beberapa agen dengan yakin meneruskan kesalahan yang sama, tanpa ada yang benar-benar menangkapnya,” Spilker memperingatkan.

Diagram alur persetujuan: agen mengusulkan operasi beserta parameter, sumber daya target, dan versi status; manusia menyetujui atau menolaknya; operasi yang disetujui divalidasi ulang dan dijalankan di lingkungan terisolasi dengan akses terbatas ke file, jaringan, dan kredensial. Permintaan yang ditolak atau kedaluwarsa akan ditutup, dan permintaan yang berubah memerlukan persetujuan baru.

Untuk tindakan yang memerlukan persetujuan manusia, jeda eksekusi dan simpan operasi yang diusulkan secara persis:

parameternya
sumber daya targetnya
commit atau versi statusnya
keputusan peninjau

Selain itu, tentukan apa yang terjadi jika persetujuan ditolak, kedaluwarsa, atau memerlukan eskalasi. Hal ini penting untuk framework yang dapat dilanjutkan, karena melanjutkan node yang terinterupsi akan mengeksekusi ulang kode dari awal node tersebut. Efek samping apa pun sebelum interupsi dapat berjalan lagi.

Jadi, jika persetujuan ditolak atau kedaluwarsa, permintaan akan ditutup. Jika commit target, parameter, atau izin berubah sebelum eksekusi, batalkan persetujuan tersebut dan minta persetujuan baru.

Spilker juga tidak mendukung gagasan bahwa agen end-to-end yang sepenuhnya otonom adalah tujuan akhirnya. “Bagi saya, pendekatan yang lebih baik adalah membangun beberapa agen terfokus dengan tanggung jawab yang jelas, izin yang terdefinisi, dan peninjauan manusia di titik-titik yang tepat. Anda tetap mendapatkan efisiensi tanpa melepaskan kendali penuh,” pungkasnya.

Pernah mengalami agen melaporkan Success padahal sebenarnya gagal? Menjengkelkan, bahkan bisa membuat geram, dan perbaikannya tidak cepat karena pesan akhir agen belum tentu memberi tahu Anda di mana letak kesalahannya.

Untuk menyelidikinya, telusuri apa yang terjadi selama eksekusi dan verifikasi hasilnya secara independen. Jadi, mari luangkan waktu untuk mengisolasi dan menyelesaikan masalah ini.

Sebelum men-debug prompt agen, rekam seluruh jalur eksekusi. Anda memerlukan trace yang menghubungkan pemanggilan agen, panggilan alat, error, dan percobaan ulang dalam eksekusi alur kerja yang sama.

Konvensi semantik GenAI dari OpenTelemetry menyediakan cara standar untuk mendeskripsikan operasi-operasi ini. Misalnya, invoke_workflow mengidentifikasi eksekusi alur kerja, invoke_agent pemanggilan agen, dan execute_tool panggilan alat. Setiap operasi dapat direkam sebagai span beserta waktu, status, dan metadata yang relevan.

Langkah ini memberi Anda trace jalur eksekusi, sehingga Anda dapat mengidentifikasi di mana agen mengalami kendala.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

Contoh ilustratif trace eksekusi.

Gunakan pemeriksaan terprogram sedapat mungkin. Validasi output terhadap skema JSON, jalankan tes unit dan integrasi, periksa apakah artefak yang diperlukan ada, dan kueri sistem eksternal untuk memastikan tindakan benar-benar berhasil.

Untuk output yang memerlukan penilaian subjektif — sehingga tidak dapat dinilai melalui pemeriksaan terprogram — gunakan agen peninjau yang independen. Salah satu pendekatannya adalah loop pelaksana–peninjau–penyelesai, di mana satu agen menghasilkan artefak, peninjau dengan konteks baru mengidentifikasi masalah, dan penyelesai menanganinya sebelum validasi dijalankan kembali.

Anda tetap perlu memvalidasi temuan peninjau jika memungkinkan, dan jika Anda menggunakan penilai berbasis LLM untuk evaluasi berulang, kalibrasikan penilaian mereka dengan contoh yang telah ditinjau manusia.

Sejauh ini, Anda telah menelusuri apa yang dieksekusi oleh agen dan memeriksa apakah output mereka benar. Namun, apa yang terjadi ketika worker mengalami crash di tengah tugas atau API mengalami timeout setelah menerima permintaan? Yang mengejutkan, alur kerja Anda mungkin berperilaku sangat baik dalam kondisi normal, tetapi gagal saat pemulihan.

Untuk menguji hal ini, sengaja suntikkan kesalahan di lingkungan pengujian:

Simulasikan timeout API
Buat worker crash di antara penulisan eksternal dan checkpoint
Kembalikan output alat yang formatnya salah
Buat persetujuan kedaluwarsa

Setelah setiap pengujian, periksa jejak eksekusi untuk melihat langkah mana yang dijalankan, di mana alur kerja dilanjutkan, dan apakah ada tindakan yang diulang atau dilewati. Kemudian, tinjau hasil sebenarnya.

Misalnya, agen CI Anda mengirim permintaan untuk memulai proses pengujian, tetapi respons API mengalami timeout. Agen mencoba lagi, menerima respons berhasil, dan melaporkan Success. Semuanya tampak baik-baik saja sampai Anda memeriksa layanan CI dan mendapati bahwa dua proses pengujian telah dibuat, bukan satu.

Itulah sebabnya Anda harus memverifikasi status yang tercatat di alur kerja sekaligus perubahan aktual di sistem eksternal. Pengujian pemulihan seharusnya hanya lulus jika alur kerja mencapai status yang diharapkan tanpa efek samping yang tidak diinginkan.

Tambahkan kegagalan yang Anda temukan ke pengujian regresi agar perubahan di masa mendatang tidak memunculkannya kembali.

Pada akhirnya, keberhasilan berarti alur kerja lulus pemeriksaan yang diwajibkan, dan hasil eksternalnya telah diverifikasi.

Agen yang terisolasi dapat menyelesaikan tugas masing-masing dengan benar, tetapi secara bersama-sama menghasilkan hasil yang tidak konsisten. Bayangkan agen penjualan mengambil ketentuan pelanggan pada pukul 10.00, agen harga menghitung penawaran menggunakan harga terbaru pada pukul 10.05, dan agen hukum memeriksa kontrak yang berubah pada pukul 10.07. Setiap agen bekerja dengan snapshot bisnis yang berbeda, sehingga output mereka mungkin saling bertentangan.

Masalah ini menjadi lebih nyata pada skala enterprise karena agen berinteraksi dengan banyak sistem yang diperbarui secara independen, beroperasi dengan izin yang berbeda, dan belum tentu berbagi konteks atau status eksekusi.

Tetapkan batas di beberapa tingkat: jumlah maksimum percobaan ulang panggilan alat, jumlah maksimum iterasi agen, kedalaman delegasi, dan tenggat waktu alur kerja secara keseluruhan. Klasifikasikan kegagalan sebelum mencoba ulang. Untuk respons 429 yang bersifat sementara, patuhi Retry-After jika disediakan. Jika tidak, gunakan exponential backoff terbatas dengan jitter.

Hentikan percobaan ulang permintaan yang tidak diubah setelah terjadi kesalahan validasi atau izin. Jika layanan downstream gagal berulang kali, circuit breaker dapat mencegah agen menghasilkan beban tambahan.

Mekanisme pemulihan bergantung pada runtime Anda. Dengan LangGraph, checkpointer persisten seperti PostgresSaver menyimpan status graf di bawah thread_id, sehingga eksekusi dapat dilanjutkan dari status yang telah disimpan. Dengan Temporal, worker lain dapat merekonstruksi alur kerja dengan memutar ulang riwayat peristiwanya. Selama pemutaran ulang, worker tersebut menggunakan kembali hasil aktivitas yang telah dicatat sebelumnya.

Jika aplikasi di-deploy ulang saat alur kerja masih berjalan, status tersimpan dan riwayat eksekusi mungkin tidak lagi kompatibel. Temporal mengatasi hal ini melalui Worker Versioning dan patching alur kerja. Untuk sistem berbasis checkpoint, rencanakan migrasi skema dan uji pemulihan terhadap status tersimpan yang sudah ada sebelum meluncurkan perubahan yang tidak kompatibel.

Jalankan tugas representatif yang sama beberapa kali dan bedakan pass@k (apakah setidaknya satu dari k percobaan berhasil) dari pass^k (apakah semua k percobaan berhasil)

Ukur hasil berdasarkan kategori tugas dan versi alur kerja, alih-alih mengandalkan satu tingkat keberhasilan agregat. Lacak keberhasilan pada percobaan pertama, konsistensi di seluruh eksekusi berulang, latensi p95, biaya per tugas yang selesai, dan proporsi yang memerlukan intervensi manusia. Laporkan ukuran sampel dan interval ketidakpastian untuk tingkat keberhasilan.

Apa itu orkestrasi agen AI?

Cara kerja orkestrasi agen AI: Di dalam mesin eksekusi

Kapan sebaiknya Anda menggunakan orkestrasi agen AI?

Arsitektur orkestrasi agen AI dan kompromi masing-masing

Orkestrasi terpusat

Orkestrasi terdesentralisasi

Orkestrasi hierarkis

Eksekusi berurutan, paralel, dan berbasis serah terima

Kegagalan umum dalam orkestrasi agen AI

7 praktik terbaik orkestrasi agen AI untuk keandalan produksi

1. Tetapkan kontrak tugas, kriteria penerimaan, dan kondisi berhenti yang eksplisit

2. Jaga orkestrator tetap ramping dan tegakkan serah terima yang terstruktur

3. Simpan status alur kerja secara persisten dan kendalikan pertumbuhan konteks

4. Rancang percobaan ulang yang sadar kegagalan dan eksekusi alat yang dapat dipulihkan

5. Rutekan dan paralelkan pekerjaan dengan anggaran sumber daya yang eksplisit

6. Tegakkan persetujuan dan isolasi eksekusi agen

7. Verifikasi output secara independen dan uji perilaku pemulihan

Telusuri alur kerja untuk mengidentifikasi letak kesalahan

Tinjau output secara independen

Suntikkan kegagalan untuk menguji pemulihan

FAQ orkestrasi agen AI

Mengapa agen AI yang terisolasi gagal pada skala enterprise?

Bagaimana cara mencegah loop percobaan ulang tanpa akhir pada agen AI?

Bagaimana cara melanjutkan alur kerja agen AI setelah crash?

Bagaimana cara menguji keandalan orkestrasi agen AI?