Memanfaatkan Rekayasa: Lapisan Eksekusi yang Sebenarnya Dibutuhkan oleh Agen AI

Mitchell Hashimoto membangun HashiCorp dan ikut menciptakan Terraform. Pada bulan Februari 2026, dia menerbitkan sebuah posting blog yang menjelaskan kebiasaan yang dia kembangkan saat bekerja dengan agen AI: setiap kali agen melakukan kesalahan, dia merekayasa perbaikan permanen ke dalam lingkungan agen. Dia menyebutnya "merekayasa tali kekang." Dalam beberapa minggu, OpenAI dan Anthropic menerbitkan artikel-artikel rekayasa yang mengembangkan ide tersebut. Istilah Rekayasa Harness telah tiba.

Istilah ini beresonansi karena menyebutkan masalah yang dihadapi setiap insinyur yang membangun agen AI. Rekayasa yang cepat memberi Anda hasil satu putaran yang lebih baik. Rekayasa konteks mengelola apa yang dilihat oleh model. Namun, keduanya tidak membahas apa yang terjadi ketika agen berjalan secara otonom selama berjam-jam, membuat ratusan keputusan tanpa pengawasan. Itulah celah yang diisi oleh Harness Engineering - dan hampir selalu bergantung pada pencarian hibrida (pencarian hibrida teks lengkap dan semantik) agar dapat bekerja.

Apa itu Rekayasa Harness?

Harness Engineering adalah disiplin ilmu yang merancang lingkungan eksekusi di sekitar agen AI otonom. Hal ini mendefinisikan alat mana yang dapat dipanggil oleh agen, di mana ia mendapatkan informasi, bagaimana ia memvalidasi keputusannya sendiri, dan kapan ia harus berhenti.

Untuk memahami mengapa hal ini penting, pertimbangkan tiga lapisan pengembangan agen AI:

Lapisan	Apa yang Dioptimalkan	Cakupan	Contoh
Rekayasa yang Cepat	Apa yang Anda katakan kepada model	Pertukaran tunggal	Contoh beberapa bidikan, permintaan berantai
Rekayasa Konteks	Apa yang dapat dilihat oleh model	Jendela konteks	Pengambilan dokumen, kompresi riwayat
Rekayasa Pemanfaatan	Dunia tempat agen beroperasi	Eksekusi otonom selama beberapa jam	Alat bantu, logika validasi, batasan arsitektural

Prompt Engineering mengoptimalkan kualitas satu pertukaran - frasa, struktur, contoh. Satu percakapan, satu keluaran.

Context Engineering mengelola berapa banyak informasi yang dapat dilihat oleh model sekaligus - dokumen mana yang akan diambil, cara mengompresi riwayat, apa yang cocok di jendela konteks dan apa yang akan dibuang.

Rekayasa Pemanfaatan membangun dunia tempat agen beroperasi. Alat, sumber pengetahuan, logika validasi, batasan arsitektural - semua hal yang menentukan apakah agen dapat bekerja dengan andal dalam ratusan keputusan tanpa pengawasan manusia.

Tiga lapisan pengembangan agen AI: Prompt Engineering mengoptimalkan apa yang Anda katakan, Context Engineering mengelola apa yang dilihat oleh model, dan Harness Engineering mendesain lingkungan eksekusi

Dua lapisan pertama membentuk kualitas dari satu giliran. Lapisan ketiga membentuk apakah agen dapat beroperasi selama berjam-jam tanpa Anda awasi.

Ini bukanlah pendekatan yang bersaing. Mereka adalah sebuah perkembangan. Seiring dengan meningkatnya kemampuan agen, tim yang sama bergerak melalui ketiganya - sering kali dalam satu proyek.

Bagaimana OpenAI Menggunakan Rekayasa Harness untuk Membangun Basis Kode Berjuta-Juta Baris dan Pelajaran yang Mereka Petik

OpenAI menjalankan eksperimen internal yang menempatkan Harness Engineering secara konkret. Mereka menjelaskannya dalam posting blog teknik mereka, "Harness Engineering: Memanfaatkan Codex di Dunia yang Mengutamakan Agen". Tim yang terdiri dari tiga orang memulai dengan repositori kosong pada akhir Agustus 2025. Selama lima bulan, mereka tidak menulis kode sendiri - setiap baris dibuat oleh Codex, agen pengkodean bertenaga AI milik OpenAI. Hasilnya: satu juta baris kode produksi dan 1.500 pull request yang digabungkan.

Bagian yang menarik bukanlah hasilnya. Melainkan empat masalah yang mereka hadapi dan solusi lapisan harness yang mereka bangun.

Masalah 1: Tidak Ada Pemahaman yang Sama tentang Basis Kode

Lapisan abstraksi apa yang harus digunakan oleh agen? Apa konvensi penamaan yang digunakan? Di mana letak diskusi arsitektur minggu lalu? Tanpa jawaban, agen menebak-nebak - dan menebak dengan salah - berulang kali.

Naluri pertama adalah satu file AGENTS.md yang berisi setiap konvensi, aturan, dan keputusan historis. Ini gagal karena empat alasan. Konteksnya langka, dan file instruksi yang membengkak memenuhi tugas yang sebenarnya. Ketika semua hal ditandai penting, tidak ada yang penting. Dokumentasi membusuk - aturan dari minggu kedua menjadi salah pada minggu kedelapan. Dan dokumen yang datar tidak dapat diverifikasi secara mekanis.

Perbaikannya: susutkan AGENTS.md menjadi 100 baris. Bukan aturan - sebuah peta. Peta ini menunjuk ke direktori docs/ yang terstruktur yang berisi keputusan desain, rencana eksekusi, spesifikasi produk, dan dokumen referensi. Linter dan CI memverifikasi bahwa tautan silang tetap utuh. Agen menavigasi ke apa yang dibutuhkannya.

Prinsip yang mendasari: jika sesuatu tidak ada dalam konteks pada saat runtime, maka hal tersebut tidak ada untuk agen.

Masalah 2: QA Manusia Tidak Dapat Mengimbangi Output Agen

Tim memasang Protokol Chrome DevTools ke dalam Codex. Agen dapat mengambil tangkapan layar jalur UI, mengamati kejadian saat proses berjalan, dan meminta log dengan LogQL dan metrik dengan PromQL. Mereka menetapkan ambang batas konkret: layanan harus dimulai dalam waktu kurang dari 800 milidetik sebelum sebuah tugas dianggap selesai. Tugas-tugas Codex berjalan selama lebih dari enam jam secara beruntun - biasanya saat para insinyur tidur.

Masalah 3: Pergeseran Arsitektur Tanpa Batasan

Tanpa pagar pembatas, agen mereproduksi pola apa pun yang ditemukannya dalam repo - termasuk pola yang buruk.

Perbaikannya: arsitektur berlapis yang ketat dengan arah ketergantungan tunggal yang ditegakkan - Jenis → Konfigurasi → Repo → Layanan → Runtime → UI. Linters khusus menegakkan aturan-aturan ini secara mekanis, dengan pesan kesalahan yang menyertakan instruksi perbaikan sebaris.

Arsitektur berlapis yang ketat dengan validasi ketergantungan satu arah: Tipe di bagian dasar, UI di bagian atas, linter kustom menerapkan aturan dengan saran perbaikan sebaris

Dalam tim manusia, kendala ini biasanya muncul ketika perusahaan berkembang menjadi ratusan insinyur. Untuk agen pengkodean, ini adalah prasyarat sejak hari pertama. Semakin cepat seorang agen bergerak tanpa kendala, semakin buruk penyimpangan arsitekturnya.

Masalah 4: Hutang Teknis yang Tidak Terdengar

Solusinya: menyandikan prinsip-prinsip inti proyek ke dalam repositori, kemudian menjalankan tugas-tugas Codex latar belakang sesuai jadwal untuk memindai penyimpangan dan mengirimkan PR refactoring. Sebagian besar digabungkan secara otomatis dalam satu menit - pembayaran kecil yang terus menerus daripada perhitungan berkala.

Mengapa Agen AI Tidak Dapat Menilai Pekerjaan Mereka Sendiri

Eksperimen OpenAI membuktikan bahwa Harness Engineering berhasil. Tetapi penelitian terpisah mengungkap mode kegagalan di dalamnya: agen secara sistematis buruk dalam mengevaluasi hasil kerja mereka sendiri.

Masalahnya muncul dalam dua bentuk.

Kecemasan konteks. Ketika jendela konteks terisi, agen mulai menyelesaikan tugas sebelum waktunya - bukan karena pekerjaannya sudah selesai, tetapi karena mereka merasakan batas waktu yang semakin dekat. Cognition, tim di balik agen pengkodean AI Devin, mendokumentasikan perilaku ini ketika membangun kembali Devin untuk Claude Sonnet 4.5: model menjadi sadar akan jendela konteksnya sendiri dan mulai mengambil jalan pintas sebelum benar-benar kehabisan ruang.

Perbaikan yang mereka lakukan adalah murni rekayasa harness. Mereka mengaktifkan beta konteks 1M-token tetapi membatasi penggunaan aktual pada 200 ribu token - mengelabui model agar percaya bahwa ia memiliki landasan pacu yang cukup. Kegelisahan pun lenyap. Tidak ada perubahan model yang diperlukan; hanya lingkungan yang lebih cerdas.

Mitigasi umum yang paling umum adalah pemadatan: meringkas riwayat dan membiarkan agen yang sama melanjutkan dengan konteks yang dikompresi. Hal ini menjaga kesinambungan tetapi tidak menghilangkan perilaku yang mendasarinya. Alternatif lainnya adalah pengaturan ulang konteks: hapus jendela, buat instance baru, dan serahkan status melalui artefak terstruktur. Hal ini akan menghilangkan pemicu kecemasan sepenuhnya, tetapi menuntut dokumen handoff yang lengkap - kesenjangan dalam artefak berarti kesenjangan dalam pemahaman agen baru.

Bias evaluasi diri. Ketika agen menilai hasil kerja mereka sendiri, mereka memberi nilai yang tinggi. Bahkan pada tugas-tugas dengan kriteria lulus/gagal yang objektif, agen menemukan masalah, berbicara sendiri bahwa itu tidak serius, dan menyetujui pekerjaan yang seharusnya gagal.

Perbaikannya meminjam dari GAN (Generative Adversarial Networks): pisahkan generator dari evaluator sepenuhnya. Dalam GAN, dua jaringan saraf bersaing - satu menghasilkan, satu menilai - dan ketegangan permusuhan itu memaksa peningkatan kualitas. Dinamika yang sama berlaku untuk sistem multi-agen.

Anthropic menguji hal ini dengan memanfaatkan tiga agen - Perencana, Pembangkit, Pengevaluasi - melawan agen tunggal yang bertugas membangun mesin game retro 2D. Mereka menjelaskan eksperimen lengkapnya dalam "Harness Design for Long-Running Application Development" (Anthropic, 2026). Perencana memperluas perintah singkat menjadi spesifikasi produk lengkap, dengan sengaja membiarkan detail implementasi tidak ditentukan - spesifikasi yang berlebihan di awal mengalir ke kesalahan hilir. Generator mengimplementasikan fitur dalam sprint, tetapi sebelum menulis kode, ia menandatangani kontrak sprint dengan Evaluator: definisi bersama tentang "selesai." Evaluator menggunakan Playwright (kerangka kerja otomatisasi peramban sumber terbuka dari Microsoft) untuk mengklik aplikasi layaknya pengguna sungguhan, menguji UI, API, dan perilaku basis data. Jika ada yang gagal, maka sprint gagal.

Agen tunggal menghasilkan game yang secara teknis diluncurkan, tetapi koneksi entitas-ke-runtime terputus di tingkat kode - hanya dapat ditemukan dengan membaca sumbernya. Harness tiga agen menghasilkan game yang dapat dimainkan dengan pembuatan level yang dibantu oleh AI, animasi sprite, dan efek suara.

Perbandingan agen tunggal versus harness tiga agen: agen tunggal berjalan 20 menit dengan biaya sembilan dolar dengan fungsionalitas inti yang rusak, sedangkan harness penuh berjalan 6 jam dengan biaya dua ratus dolar yang menghasilkan game yang berfungsi penuh dengan fitur-fitur yang dibantu oleh AI

Arsitektur tiga agen menghabiskan biaya sekitar 20x lipat lebih banyak. Outputnya berubah dari tidak dapat digunakan menjadi dapat digunakan. Itulah perdagangan inti yang dilakukan Harness Engineering: biaya tambahan struktural yang ditukar dengan keandalan.

Masalah Pengambilan di Dalam Setiap Agen Harness

Kedua pola - sistem docs/ terstruktur dan siklus sprint Generator/Evaluator - memiliki ketergantungan yang sama: agen harus menemukan informasi yang tepat dari basis pengetahuan yang hidup dan terus berkembang saat dibutuhkan.

Hal ini lebih sulit daripada yang terlihat. Ambil contoh konkret: Generator menjalankan Sprint 3, mengimplementasikan otentikasi pengguna. Sebelum menulis kode, dibutuhkan dua jenis informasi.

Pertama, permintaan pencarian semantik: apa prinsip-prinsip desain produk ini seputar sesi pengguna? Dokumen yang relevan mungkin menggunakan "manajemen sesi" atau "kontrol akses" - bukan "otentikasi pengguna". Tanpa pemahaman semantik, pencarian akan meleset.

Kedua, kueri pencocokan tepat: dokumen mana yang mereferensikan fungsi validateToken? Nama fungsi adalah sebuah string arbitrer tanpa makna semantik. Temu kembali berbasis penyematan tidak dapat menemukannya dengan andal. Hanya pencocokan kata kunci yang dapat digunakan.

Kedua kueri ini terjadi secara bersamaan. Mereka tidak dapat dipisahkan menjadi langkah-langkah yang berurutan.

Pencarian vektor murni gagal pada pencocokan yang tepat. BM25 tradisional gagal pada kueri semantik dan tidak dapat memprediksi kosakata mana yang akan digunakan oleh sebuah dokumen. Sebelum Milvus 2.5, satu-satunya pilihan adalah dua sistem pencarian paralel - indeks vektor dan indeks teks lengkap - yang berjalan secara bersamaan pada waktu kueri dengan logika penggabungan hasil khusus. Untuk repositori docs/ yang hidup dengan pembaruan yang terus menerus, kedua indeks harus tetap sinkron: setiap perubahan dokumen memicu pengindeksan ulang di dua tempat, dengan risiko ketidakkonsistenan yang konstan.

Bagaimana Milvus 2.6 Memecahkan Pengambilan Agen dengan Satu Jalur Hibrida

Milvus adalah basis data vektor sumber terbuka yang dirancang untuk beban kerja AI. Sparse-BM25 dari Milvus 2.6 meruntuhkan masalah pengambilan dua jalur pipa menjadi satu sistem.

Pada saat menelan, Milvus menghasilkan dua representasi secara bersamaan: embedding padat untuk pengambilan semantik dan vektor jarang yang dikodekan TF untuk penilaian BM25. Statistik IDF global diperbarui secara otomatis saat dokumen ditambahkan atau dihapus - tidak ada pemicu pengindeksan ulang secara manual. Pada waktu kueri, input bahasa alami menghasilkan kedua jenis vektor kueri secara internal. Reciprocal Rank Fusion (RRF ) menggabungkan hasil pemeringkatan, dan pemanggil menerima satu set hasil terpadu.

Sebelum dan sesudah: dua sistem terpisah dengan sinkronisasi manual, hasil yang terfragmentasi, dan logika fusi khusus versus Milvus 2.6 pipeline tunggal dengan penyematan yang padat, Sparse BM25, fusi RRF, dan pemeliharaan IDF otomatis yang menghasilkan hasil yang disatukan

Satu antarmuka. Satu indeks untuk dipertahankan.

Pada tolok ukur BEIR - rangkaian evaluasi standar yang mencakup 18 dataset pengambilan heterogen - Milvus mencapai throughput 3-4x lebih tinggi daripada Elasticsearch pada pengambilan yang setara, dengan peningkatan hingga 7x QPS pada beban kerja tertentu. Untuk skenario sprint, satu kueri menemukan prinsip desain sesi (jalur semantik) dan setiap dokumen yang menyebutkan validateToken (jalur yang tepat). Repositori docs/ diperbarui secara terus menerus; pemeliharaan BM25 IDF berarti dokumen yang baru ditulis berpartisipasi dalam penilaian kueri berikutnya tanpa pembangunan ulang batch.

Ini adalah lapisan pengambilan yang dibuat untuk kelas masalah seperti ini. Ketika agen memanfaatkan kebutuhan untuk mencari basis pengetahuan yang hidup - dokumentasi kode, keputusan desain, riwayat sprint - pencarian hibrida jalur tunggal bukanlah hal yang baik untuk dimiliki. Itulah yang membuat harness lainnya berfungsi.

Komponen Harness Terbaik Dirancang untuk Dihapus

Setiap komponen dalam harness mengkodekan asumsi tentang keterbatasan model. Penguraian sprint diperlukan saat model kehilangan koherensi pada tugas yang panjang. Pengaturan ulang konteks diperlukan ketika model mengalami kecemasan di dekat batas jendela. Agen evaluator menjadi penting ketika bias evaluasi diri tidak dapat dikelola.

Asumsi-asumsi ini berakhir. Trik konteks-jendela kognisi mungkin menjadi tidak diperlukan saat model mengembangkan stamina konteks panjang yang asli. Ketika model terus berkembang, komponen lain akan menjadi overhead yang tidak perlu yang memperlambat agen tanpa menambah keandalan.

Harness Engineering bukanlah arsitektur yang tetap. Ini adalah sistem yang dikalibrasi ulang dengan setiap rilis model baru. Pertanyaan pertama setelah peningkatan besar bukanlah "apa yang bisa saya tambahkan?" Melainkan "apa yang bisa saya hapus?"

Logika yang sama berlaku untuk pengambilan. Ketika model menangani konteks yang lebih panjang dengan lebih andal, strategi chunking dan waktu pengambilan akan bergeser. Informasi yang membutuhkan fragmentasi yang cermat hari ini mungkin dapat dicerna sebagai satu halaman penuh besok. Infrastruktur pencarian beradaptasi bersama model.

Setiap komponen dalam harness yang dibangun dengan baik menunggu untuk dibuat berlebihan oleh model yang lebih cerdas. Itu bukan masalah. Itulah tujuannya.

Memulai dengan Milvus

Jika Anda sedang membangun infrastruktur agen yang membutuhkan pengambilan hibrida - pencarian semantik dan kata kunci dalam satu pipeline - di sinilah tempat untuk memulai:

• Baca catatan rilis Milvus 2.6 untuk detail lengkap tentang Sparse-BM25, pemeliharaan IDF otomatis, dan tolok ukur kinerja.
• Bergabunglah dengan komunitas Milvus untuk mengajukan pertanyaan dan berbagi apa yang Anda bangun.
• Pesan sesi Jam Kantor Milvus gratis untuk membahas kasus penggunaan Anda dengan pakar database vektor.
• Jika Anda lebih suka melewatkan penyiapan infrastruktur, Zilliz Cloud (Milvus yang dikelola sepenuhnya) menawarkan tingkat gratis untuk memulai dengan kredit gratis $100 setelah pendaftaran dengan email kantor.
• Bintangi kami di GitHub: milvus-io/milvus - 43k+ bintang dan terus bertambah.

Pertanyaan yang Sering Diajukan

Apa itu harness engineering dan apa bedanya dengan prompt engineering?

Prompt engineering mengoptimalkan apa yang Anda katakan pada sebuah model dalam satu kali pertukaran - frasa, struktur, contoh. Harness Engineering membangun lingkungan eksekusi di sekitar agen AI otonom: alat yang dapat dipanggil, pengetahuan yang dapat diakses, logika validasi yang memeriksa pekerjaannya, dan batasan yang mencegah penyimpangan arsitektur. Rekayasa yang cepat membentuk satu giliran percakapan. Rekayasa Harness membentuk apakah agen dapat beroperasi dengan andal selama berjam-jam di ratusan keputusan tanpa pengawasan manusia.

Mengapa agen AI membutuhkan pencarian vektor dan BM25 secara bersamaan?

Agen harus menjawab dua pertanyaan pencarian yang berbeda secara fundamental secara bersamaan. Kueri semantik - apa prinsip desain kami seputar sesi pengguna? - membutuhkan penyematan vektor yang padat untuk mencocokkan konten yang terkait secara konseptual terlepas dari kosakata. Kueri pencocokan tepat - dokumen mana yang merujuk ke fungsi validateToken? - memerlukan penilaian kata kunci BM25, karena nama fungsi adalah string acak tanpa makna semantik. Sistem temu kembali yang hanya menangani satu mode saja akan melewatkan kueri jenis lainnya secara sistematis.

Bagaimana cara kerja Milvus Sparse-BM25 untuk pengambilan pengetahuan agen?

Pada saat menelan, Milvus menghasilkan embedding padat dan vektor jarang yang dikodekan TF untuk setiap dokumen secara bersamaan. Statistik IDF global diperbarui secara real time ketika basis pengetahuan berubah - tidak perlu pengindeksan ulang secara manual. Pada waktu kueri, kedua jenis vektor dihasilkan secara internal, Reciprocal Rank Fusion menggabungkan hasil peringkat, dan agen menerima satu set hasil terpadu. Seluruh pipeline berjalan melalui satu antarmuka dan satu indeks - sangat penting untuk basis pengetahuan yang terus diperbarui seperti repositori dokumentasi kode.

Kapan saya harus menambahkan agen evaluator ke agent harness saya?

Tambahkan Evaluator terpisah ketika kualitas keluaran Generator Anda tidak dapat diverifikasi dengan pengujian otomatis saja, atau ketika bias evaluasi mandiri telah menyebabkan cacat yang terlewatkan. Prinsip utama: Evaluator harus terpisah secara arsitektur dari Generator - konteks bersama memperkenalkan kembali bias yang sama yang ingin Anda hilangkan. Evaluator harus memiliki akses ke alat runtime (otomatisasi browser, panggilan API, kueri basis data) untuk menguji perilaku, bukan hanya meninjau kode. Penelitian Anthropic menemukan bahwa pemisahan yang terinspirasi oleh GAN ini mengubah kualitas keluaran dari "secara teknis berjalan tetapi rusak" menjadi "berfungsi penuh dengan fitur-fitur yang tidak pernah dicoba oleh agen tunggal."