# Bagaimana Mereproduksi Kegagalan Agen Coding di Berbagai Versi Model? > Reproduksi kegagalan agen coding dengan merekam seluruh proses sebagai test fixture berversi, lalu jalankan prompt, commit repositori, kontrak alat, lingkungan, dan aturan berhenti yang sama pada ID model yang dipatok beberapa kali. Bandingkan peristiwa terstruktur dan status akhir repositori, bukan hanya teks asisten. # Bagaimana Mereproduksi Kegagalan Agen Coding di Berbagai Versi Model? Reproduksi yang berguna adalah eksperimen yang dapat dieksekusi, bukan transkrip yang disalin. Mulai dari status repositori yang gagal, bekukan semua input yang dapat dilihat agen, dan tentukan kondisi kegagalan yang dapat diperiksa mesin. Lalu putar ulang fixture pada versi model yang dipatok beberapa kali. Satu proses agen menggabungkan perilaku model dengan alat, file, hasil jaringan, orkestrasi, dan waktu. Jika salah satunya berubah, hasil yang berbeda tidak membuktikan bahwa model memperbaiki atau menyebabkan masalah. ## Definisikan kegagalan sebagai kondisi Tuliskan kondisi teramati terkecil yang membedakan kegagalan dari keberhasilan. Contoh baik adalah tes yang tetap merah, perubahan file tak terduga, perintah terlarang, migrasi yang hilang, atau patch yang dapat dikompilasi tetapi mengubah perilaku. Hindari kondisi seperti "jawabannya terlihat lebih buruk". Paket penerimaan dapat mencakup: * tes regresi asli lulus; * semua tes yang ada tetap lulus; * tidak ada file di luar allowlist yang berubah; * agen berhenti dalam jumlah panggilan model tertentu; * diff akhir tidak mengandung secret yang dihasilkan atau lockfile drift. ## Rekam seluruh envelope proses Prompt hanyalah satu input. Simpan hal berikut bersama fixture: | Lapisan | Yang harus dibekukan | Mengapa mengubah hasil | |---|---|---| | Repositori | Commit, submodule, patch kotor, file fixture belum dilacak | Agen bernalar dari status source yang tepat | | Instruksi | System prompt, aturan repositori, tugas pengguna | Perbedaan kata kecil mengubah rencana | | Model | Penyedia, ID model tetap, parameter | Alias dan default dapat bergeser | | Alat | Nama, JSON schema, izin, timeout | Kemampuan alat membentuk rencana | | Lingkungan | Container image, OS, arsitektur, lock dependensi | Perintah dan tes dapat berperilaku berbeda | | Data eksternal | Respons HTTP mock, jam, input acak | Layanan live menimbulkan drift | | Orkestrator | Batas loop, kebijakan retry, kompaksi konteks | Model yang sama bisa menerima riwayat berbeda | Redaksi secret, tetapi simpan apakah kredensial tersedia dan cakupannya. ## Rekam peristiwa terstruktur, bukan hanya prosa Simpan setiap request model, respons model, tool call, hasil alat, retry, dan keputusan berhenti sebagai peristiwa berurutan. Tambahkan hash konten untuk keluaran besar dan simpan artefak asli secara terpisah. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` Peristiwa terstruktur menunjukkan apakah model baru memilih alat berbeda, menafsirkan error yang sama dengan cara berbeda, atau menerima bukti berbeda. ## Patok versi dan hilangkan variasi live Gunakan ID model bertanggal atau tetap jika tersedia. Jangan bandingkan kegagalan historis dengan alias `latest`, karena alias mungkin sudah mengarah ke build lain. Jalankan dalam container atau mesin virtual bersih. Ganti pencarian live dan indeks paket yang berubah dengan respons rekaman atau snapshot internal. Bekukan jam untuk logika peka tanggal. Jika jaringan harus digunakan, rekam semua respons dan labeli tes sebagai terkendali sebagian. Seed acak membantu, tetapi tidak membekukan inference terdistribusi, waktu alat, atau perubahan sisi penyedia. ## Putar ulang matriks, bukan satu pasangan Satu proses per versi tidak dapat memisahkan regresi dari variasi sampling. Gunakan matriks kecil yang mempertahankan fixture: | Versi model | Pengulangan | Tingkat lulus | Median panggilan | Tanda kegagalan | |---|---:|---:|---:|---| | ID baseline dipatok | 5 | 4/5 | 9 | Tes edge case terlewat | | ID kandidat dipatok | 5 | 1/5 | 13 | File hasil generate diedit | | Kandidat dengan prompt lama | 5 | 1/5 | 12 | Tanda sama | Lima pengulangan berguna untuk pandangan awal. Perbesar sampel untuk kegagalan intermiten atau berdampak tinggi. Pertahankan temperature dan kontrol sampling sama kecuali parameter itu yang diuji. ## Bandingkan keputusan dan status repositori Bandingkan empat lapisan secara terpisah: * peristiwa model dan alat yang dinormalisasi; * perintah dan exit code; * pohon file dan patch akhir; * hasil tes penerimaan dan penggunaan resource. Jangan menuntut penalaran bahasa alami identik. Dua versi dapat mengambil jalur berbeda dan menghasilkan patch benar yang setara. Sebaliknya, prosa serupa dapat menyembunyikan perintah atau perubahan file yang berbeda secara material. ## Minimalkan fixture setelah reproduksi Setelah kegagalan berulang, hapus file, alat, paragraf prompt, dan panggilan eksternal yang tidak terkait satu per satu. Fixture kecil berjalan lebih cepat dan memperlihatkan batas kausal. Simpan dua artefak: replay insiden penuh untuk audit dan tes regresi minimal untuk evaluasi berkelanjutan. Tambahkan kasus minimal ke gerbang peningkatan model. ## Gunakan adapter model yang portabel Gateway seperti Atlas Cloud dapat menempatkan beberapa model di balik satu client kompatibel OpenAI, tetapi kompatibilitas tidak membuat perilaku model identik. Simpan ID model, opsi penyedia, dan perbedaan format alat di adapter. Harness bersama harus menguasai fixture, log peristiwa, retry, dan kondisi. Struktur ini memungkinkan reproduksi yang sama berjalan lintas penyedia tanpa menulis ulang logika evaluasi. ## Kesimpulan Untuk mereproduksi kegagalan agen coding, bekukan envelope proses, putar ulang model yang dipatok beberapa kali, dan nilai hasil yang dapat dieksekusi. Jika insiden tepat tidak dapat direproduksi, labeli input yang tetap live dan perlakukan hasil sebagai studi perbandingan, bukan bukti regresi model. ## FAQ ### Apa yang harus direkam untuk mereproduksi kegagalan agen coding? Rekam commit dan patch yang belum di-commit, prompt dan instruksi sistem, ID model, parameter, skema dan hasil alat, image lingkungan, lockfile dependensi, kebijakan kredensial dan jaringan, serta kondisi keberhasilan yang tepat. ### Haruskah kegagalan diputar ulang dengan alias model latest? Tidak. Gunakan ID model yang tetap atau bertanggal. Alias latest dapat berubah selama pengujian dan membuat hasil tidak dapat dikaitkan dengan versi tertentu. ### Mengapa seed acak yang tetap tidak cukup? Seed tidak membekukan infrastruktur penyedia, waktu alat, hasil retrieval, atau revisi model. Seed hanyalah satu kontrol, bukan jaminan keluaran deterministik. ### Apa sinyal lulus atau gagal terbaik untuk agen coding? Utamakan kondisi yang dapat dieksekusi seperti tes, hasil lint, diff file yang diharapkan, pemeriksaan file terlarang, dan exit code perintah. Kemiripan teks biasanya terlalu lemah untuk tugas coding. ### Berapa kali pengulangan yang perlu dijalankan per versi model? Jalankan cukup banyak untuk membedakan regresi deterministik dari variasi sampling. Lima kali adalah titik awal yang berguna; kegagalan berdampak tinggi mungkin memerlukan dua puluh kali atau lebih. ### Bisakah harness yang sama membandingkan model dari penyedia berbeda? Bisa, jika request, kontrak alat, log peristiwa, dan kondisi keluaran dinormalisasi. Simpan opsi khusus penyedia di dalam adapter.