HarnessDev: LLM Membangun Infrastruktur Mereka Sendiri
ByteDance dan sekelompok universitas meluncurkan HarnessDev, sebuah kerangka kerja yang memungkinkan model bahasa besar (LLM) menulis "sistem operasi agen" mereka sendiri, yang disebut Agent Harnesses. Tim tersebut memberikan LLM sebuah starter kit sederhana dan membiarkannya melengkapi sisanya, menunjukkan bagaimana AI dapat membangun lapisan kontrol yang menjalankan loop penggunaan alat, langkah verifikasi, dan penanganan kesalahan secara mandiri—tanpa perlu manusia mengetik setiap barisnya.
Mengapa harness yang dibangun sendiri itu penting
Agen AI telah berevolusi dari asisten perintah tunggal menjadi pekerja multi-langkah yang memanggil API, melakukan kueri basis data, dan menyatukan hasil. Hingga saat ini, pengembang merancang kode orkestrasi secara manual untuk memberi tahu model kapan harus memanggil alat pencarian, cara menyimpan status perantara, dan cara memverifikasi jawaban akhir. HarnessDev membalikkan model tersebut: sebuah seed harness menyediakan perancah (scaffolding) yang cukup—fungsi dasar untuk looping, pemilihan alat, dan pelacakan status—lalu LLM mengembangkannya menjadi runtime yang memiliki fitur lengkap.
Dalam tolok ukur (benchmark) makalah tersebut, model tersebut menghasilkan 18 harness yang berbeda, menambahkan lebih dari 17.000 baris kode ke seed aslinya. Setiap harness mengelola siklus hidup tugas secara penuh: menjalankan loop, memilih alat yang tepat, menjaga konteks, melacak status, memverifikasi hasil, dan pulih dari kesalahan.
Biaya tersembunyi yang terungkap dalam studi tersebut
Angka-angkanya terlihat mengesankan, tetapi penulis memperingatkan bahwa implementasi mentah tidak sama dengan penggunaan praktis.
- Komponen yang tidak digunakan – Sebagian besar kode yang dihasilkan tidak pernah dijalankan selama eksekusi tugas yang sebenarnya. LLM menulis fungsi yang tidak pernah dipanggil oleh agen, sehingga memperbesar basis kode tanpa memberikan nilai tambah.
- Keterikatan model (Model lock-in) – Harness cenderung disesuaikan dengan LLM spesifik yang membuatnya. Ketika harness yang sama diberikan ke model yang berbeda, kinerjanya turun secara nyata, menunjukkan bahwa logika kontrol yang dihasilkan secara otomatis menyertakan keunikan spesifik model tersebut.
- Celah verifikasi – Satu harness pengujian melaporkan tingkat keberhasilan sebesar 99% (99 dari 100 kali jalan) tetapi hanya benar sebanyak 48% dari waktu tersebut. Tanpa verifikasi yang kuat, seorang agen dapat menyajikan jawaban yang salah dengan penuh percaya diri.
- Overhead token – Penggunaan token—sebagai proksi untuk biaya komputasi—bervariasi secara drastis. Satu harness membutuhkan token tujuh kali lipat lebih banyak daripada yang lain untuk mencapai hasil yang sama, sehingga menimbulkan kekhawatiran tentang skalabilitas dalam pengaturan produksi.
Temuan ini menyoroti perlunya desain yang disiplin, bahkan ketika kode dihasilkan oleh LLM.
Apa yang harus diperhatikan oleh pengembang
- Anggap desain harness sebagai arsitektur – Jangan mengandalkan model untuk "langsung bekerja." Tentukan modul yang jelas untuk kontrol loop, pemilihan alat, penanganan status, dan verifikasi sebelum membiarkan LLM mengisinya.
- Bangun verifikasi yang kuat – Masukkan pemeriksaan eksplisit yang membandingkan klaim agen dengan kebenaran dasar (ground truth) atau model sekunder. Akurasi 48% dalam studi tersebut meskipun tingkat keberhasilan yang dilaporkan sendiri adalah 99% menunjukkan bahwa verifikasi tidak boleh menjadi pemikiran belakangan.
- Perhatikan anggaran token – Harness yang lebih rumit dapat membengkakkan jumlah token. Lakukan profiling pada berbagai varian harness sejak dini untuk menghindari lonjakan biaya tersembunyi.
- Uji di berbagai model – Jalankan harness yang sama dengan beberapa backend LLM. Jika kinerja menurun tajam, Anda mungkin memerlukan desain yang lebih agnostik terhadap model atau harness terpisah untuk setiap model.
Intinya: HarnessDev membuktikan bahwa LLM dapat menyusun kode kontrol yang menyerupai sistem operasi mereka sendiri.