Debugging Agen AI: Dasbor Anda Tahu Biayanya, Bukan Penyebabnya

Debugging agen AI dimulai di titik tempat dasbor observabilitas Anda berakhir. Ketika agen pengode AI merusak sesuatu dan proses berjalan sudah selesai, dasbor dapat memberi tahu Anda berapa biaya proses tersebut (token, dolar, latensi), tetapi dasbor akan bungkam terhadap satu-satunya pertanyaan yang sebenarnya Anda miliki: mengapa agen tersebut mengubah file itu? Artefak yang menjawab pertanyaan itu adalah rekaman jejak yang dapat Anda buka, baca, dan putar ulang, karena rekaman tersebut mengembalikan proses berjalan itu kepada Anda, bukan menggambarkannya dari luar.

Peristiwa ini berhenti menjadi sesuatu yang langka begitu para agen mulai melakukan pekerjaan nyata. Seorang agen akan menyisir seluruh repositori, mengedit beberapa file, menjalankan pemeriksaan, dan melaporkan keberhasilan, semuanya di antara dua prompt yang Anda ketik dengan selisih beberapa menit. Jika salah satu edit itu keliru, Anda mengetahuinya belakangan: setelah terminal ditutup, setelah scrollback hilang, setelah proses yang seharusnya bisa menjelaskan dirinya sendiri berhenti. Apa yang terjadi selanjutnya sepenuhnya bergantung pada apa yang Anda simpan. Jika yang Anda simpan adalah dasbor biaya, Anda akan melakukan arkeologi. Jika yang Anda simpan adalah rekaman, Anda akan membaca.

Kegagalan yang tidak dapat Anda reproduksi.

Beginilah bentuknya. Kamu kembali ke repo dan sebuah file yang tidak pernah kamu minta siapa pun untuk menyentuhnya telah ditulis ulang, dihapus, atau dikosongkan dari fungsi yang menjadi sandaran semua hal lainnya. Kamu bertanya kepada agen apa yang terjadi; sesinya sudah ditutup, dan bahkan jika transkripnya masih ada, penjelasan agen tentang jalannya proses itu sendiri hanyalah rekonstruksi, bukan rekaman. Jadi kamu melakukan hal yang wajar dan menjalankannya lagi, dan kamu mendapatkan proses yang berbeda. Pemanggilan alat yang berbeda, edit yang berbeda, mungkin tidak ada kegagalan sama sekali, karena lintasan aslinya bergantung pada sampling, pada kondisi repo, dan pada waktu. Proses yang perlu kamu periksa itu sudah tidak ada lagi.

Ini lebih buruk daripada tidak dapat direproduksi. Ini tidak dapat direproduksi dan ditandai sebagai sukses. Sebuah run keluar dengan kode 0 ketika agen keluar dengan kode 0, bahkan jika sebuah pemeriksaan di dalam run tersebut keluar dengan kode 1: pipeline bisa tetap hijau sementara langkah verifikasi di dalam run itu gagal, dan kode keluar yang secara alamiah Anda percayai tidak memberi tahu apa pun.

Tidak masalah model mana yang dipilih router untuk proses tersebut (GLM 5.3 Flash atau apa pun): begitu prosesnya berakhir, penalarannya ikut hilang. Bukti hanya ada selama proses itu berlangsung: prompt, panggilan alat, keluaran, diff. Jika tidak ada yang merekamnya, "mengapa ia mengubah file itu" tidak memiliki jawaban. Yang ada hanyalah teori.

Inilah mode kegagalan yang membedakan agen AI penulis kode dari semua alat yang ada sebelum mereka: kerusakan dan penjelasan terjadi di tempat yang sama, dan tempat itu tutup.

Apa yang diukur oleh dasbor, dan apa yang dilewatinya?

Naluri setelah kinerja yang buruk adalah membuka dasbor observabilitas, dan dasbor itu akan benar-benar baik dalam tugasnya. Tugasnya adalah lalu lintas: token per hari, biaya per model, latensi, tingkat kesalahan. Untuk perencanaan kapasitas dan penagihan, itu memang instrumen yang tepat, dan jika Anda menjalankan agen di produksi, Anda seharusnya membukanya.

Tetapi pertanyaan Anda tidak bersifat agregat. Pertanyaan tersebut bersifat tunggal dan kausal: mengapa proses ini mengubah berkas ini? Agregasi melewati tepat granularitas yang menjawabnya. Jika dirata-ratakan di seluruh proses, proses yang Anda pedulikan adalah noise; di dalam proses itu, panggilan alat yang Anda pedulikan kembali menjadi noise.

Dasbor menggambarkan sebuah run dari luar: bahwa itu terjadi, berapa beratnya, berapa biayanya. Ia tidak bisa menyerahkan run itu kepadamu, dan "mengapa" bukanlah properti dari deskripsi tersebut. Itu adalah properti dari urutannya.

• Berapa biaya proses tersebut? — Dasbor biaya menjawabnya vs Jejak yang direkam menjawabnya

• Mengapa agen mengubah file tersebut? — Dasbor Biaya Tidak ada jawaban vs Jejak terekam Suntingan, secara berurutan, dengan diff-nya

• Pemeriksaan mana yang gagal di dalam run hijau? — Dasbor Biaya Tidak ada jawaban vs Jejak terekam Pemeriksaan, dengan kode keluarnya

• Bisakah saya menjalankan kegagalan yang sama persis lagi? — Dasbor biaya: Tidak vs Jejak terekam: Ya, luring, tanpa biaya

Lapisan yang menjawabnya terletak di bawahnya: log permintaan yang tercatat, ditangkap saat proses berlangsung, dengan setiap prompt yang dikirim, setiap panggilan alat yang dikeluarkan, setiap respons yang kembali, secara berurutan. Bukan ringkasan dari proses tersebut. Proses itu sendiri.

Membaca satu run sebagai linimasa

Dengan rekaman, debugging tidak lagi seperti arkeologi, melainkan seperti membaca. Arkeologi adalah yang Anda lakukan tanpa rekaman: git reflog, entri stash, riwayat shell, ingatan Anda sendiri tentang apa yang Anda minta sebelumnya hari itu. Membaca adalah yang Anda lakukan dengan rekaman: buka timeline dan gulir.

Lini masa memaparkan jalannya proses sesuai urutan kejadian: perintah yang memulainya, setiap panggilan alat, setiap suntingan berkas beserta diff-nya, setiap pemeriksaan, setiap kode keluar. Snapshot sistem berkas diambil sekali per giliran, bukan sekali per panggilan alat — itu cukup untuk melihat kondisi repositori di setiap langkah percakapan tanpa tenggelam dalam kebisingan per panggilan. Yang menjadikan ini debugging, bukan sekadar penelusuran, adalah kedekatan: suntingan dan pemeriksaan yang menangkapnya berada berdampingan, berurutan, tanpa ada apa pun di antara keduanya untuk berspekulasi. “Mengapa” sebagian besar adalah sifat dari kedekatan.

Contoh konkret, yang terbaca dari rekaman perbaikan: 14 kejadian, termasuk perubahan berkas yang dicetak sebagai +1 -3 dan pemeriksaan yang gagal dengan status keluar 1. Pengeditan, lalu pemeriksaan yang gagal karenanya, berdekatan dalam catatan. Itulah seluruh perbedaan antara merekonstruksi sebuah eksekusi dari fragmen-fragmen dan membacanya. Hal ini paling penting bagi agen pengodean di terminal, yang ruang kerjanya adalah terminal yang tertutup begitu pekerjaan selesai: linimasa adalah scrollback yang bertahan.

Terekam atau disimpulkan: apa yang diketahui jejak dibandingkan dengan apa yang ditemukannya

Linimasa memberi tahu apa yang terjadi secara berurutan. Grafik kausal memberi tahu apa yang menyebabkan apa, dan di celah antara keduanya itulah kepercayaan harus dibangun.

Graf menghubungkan peristiwa-peristiwa: edit ini, lalu pemeriksaan yang gagal ini. Sebagian dari sisi-sisi tersebut adalah fakta terekam: panggilan alat yang menghasilkan diff memang ada di dalam jejak. Sisi-sisi lainnya disimpulkan: kesimpulan graf bahwa pemeriksaan gagal karena diff tersebut. orca graph memberi label pada setiap sisi sebagai terekam atau disimpulkan, dan menyebutkan aturan yang digunakannya untuk keduanya, sehingga Anda selalu tahu apakah Anda sedang melihat sesuatu yang dilakukan oleh run atau sesuatu yang alat simpulkan tentang run tersebut.

Perbedaan itu ditegakkan, bukan sekadar aspirasi: edge-edge hasil inferensi tidak pernah ditulis kembali ke dalam trace. Trace tetap menjadi catatan setia atas apa yang terjadi; inferensi hanyalah tampilan di atasnya yang dapat Anda periksa, pertanyakan, dan sanggah. Hal ini menjadi paling penting ketika lebih dari satu agen terlibat. Ketika agen refaktor dan agen penulis tes menyentuh file yang sama, "agen mana yang menyebabkan ini" justru pertanyaan yang atribusi multi-agen hadir untuk menjawab. Sebuah edge yang diam-diam menaikkan statusnya dari inferensi menjadi fakta adalah cara Anda berakhir dengan men-debug sebuah cerita, bukan sebuah run.

Mereproduksinya sesering yang Anda suka secara gratis

Membaca menjelaskan. Memutar ulang membuktikan. Setelah Anda memiliki hipotesis (pemeriksaan gagal karena edit menghapus panggilan reset), Anda ingin menjalankannya lagi dan menyaksikannya terjadi. Menjalankan ulang agen langsung memberi Anda lintasan baru dan tagihan baru.

Memutar ulang rekaman memberi Anda proses yang sama: pemutaran ulang berjalan dengan jaringan diblokir, sehingga tidak memakan biaya token dan tidak memiliki variasi. Peristiwa yang sama, setiap kali, secara offline. Itulah properti yang mengubah debugging agen dari perjudian menjadi rekayasa: kegagalan telah menjadi deterministik, dan kegagalan deterministik bisa diperbaiki.

Alat ini juga bukan kotak hitam. OrcaReplay adalah sumber terbuka di bawah lisensi Apache-2.0 dan format trace-nya berlisensi CC BY 4.0, sehingga siapa pun dapat mengimplementasikannya ulang: rekaman Anda tidak disandera oleh format kepemilikan, termasuk rekaman kami. Dan alat ini benar-benar diuji, bukan sekadar didemokan: ada 1393 pengujian pada Node 20 dan Node 22. Anda dapat membaca kode sumbernya, memeriksa formatnya, dan menjalankan sendiri rangkaian pengujiannya sebelum Anda mempercayakannya untuk menangani proses-proses tim Anda.

Intisarinya

Dasbor adalah tagihan. Jejak yang terekam adalah prosesnya. Jika rencana Anda untuk men-debug agen AI berakhir pada dasbor biaya, Anda tidak memiliki rencana debugging: Anda memiliki sistem penagihan. Dasbor akan selalu dapat memberi tahu Anda berapa biaya sebuah proses, dan tidak akan pernah dapat memberi tahu Anda mengapa agen tersebut menghapus file Anda, karena "mengapa" berada dalam urutan, dan urutan itu hanya ada jika Anda menyimpannya.

Seluruh metode ini terdiri dari empat langkah:

• Catat larinya.

• Baca linimasa.

Periksa sisi-sisi graf.

• Putar ulang yang membuat Anda takut, gratis, sesering yang Anda suka.

Catatan sumber: Setiap angka dalam artikel ini dilaporkan oleh vendor, dari produk kami sendiri dan dari repositori OrcaReplay beserta dokumentasinya: perilaku kode keluar dari sebuah run, perbaikan terekam 14-peristiwa dengan diff +1 -3 dan pemeriksaan exit-1-nya, pelabelan tepi pada grafik orca, irama snapshot sekali per giliran, putar ulang offline dengan jaringan diblokir, dan rangkaian 1393 pengujian pada Node 20 dan Node 22. Tidak ada pengukuran pihak ketiga yang dikutip di artikel ini. Rangkaian 1393 pengujian adalah satu-satunya klaim yang dapat Anda verifikasi sendiri, dengan mengkloning repositori dan menjalankannya. Semua item terakhir diperiksa pada 2026-09-04.