Catatan penulis: Artikel ini menjelaskan dalam 5 langkah cara merancang gerbang penerimaan Agent, sehingga agen yang berjalan lama punya titik akhir yang jelas, umpan balik yang andal, dan biaya yang terkendali.
Setelah Agent berjalan terus-menerus selama berjam-jam bahkan berhari-hari, hasil yang dikembalikan tampak lengkap, tetapi tidak ada yang berani langsung menggabungkannya. Inilah masalah yang dihadapi banyak tim pengembang. Artikel ini akan membahas metode 5 langkah untuk merancang gerbang penerimaan Agent, agar sebelum memulai tugas panjang, Anda bisa mendefinisikan “selesai” sebagai standar yang dapat diperiksa berulang kali oleh mesin.
Pada 27 Oktober 2026, salah satu pendiri CentOS, Gregory Kurtzer, mengumumkan proyek Ginux. Menurut laporan, dalam 11 hari ia terutama mengandalkan satu tugas Codex yang berjalan terus-menerus dan meninggalkan sekitar 139.000 baris kode, sehingga kernel mandiri ini bisa booting Rocky Linux 10 dan menjalankan systemd. Ketika ditanya lebih lanjut bagaimana ia mengembalikan Agent yang menyimpang ke jalur yang benar, jawabannya sederhana: perbanyak gerbangnya.
Ini bukan artikel lain yang berisi kumpulan trik penyusunan petunjuk. Artikel ini membahas struktur rekayasa yang benar-benar diandalkan tugas panjang: tujuan, gerbang, bukti, regresi, dan kondisi berhenti.
Nilai inti: Setelah membaca artikel ini, Anda akan dapat menulis satu set gerbang penerimaan Agent untuk proyek Anda sendiri dan menentukan bagian mana yang diserahkan ke mesin serta keputusan mana yang harus tetap di tangan manusia.
Poin Inti Gerbang Validasi Agent
Gerbang validasi Agent adalah sekumpulan checkpoint yang sudah ditentukan sebelumnya dan dapat dijalankan berulang kali. Ini memberi tahu Agent apakah hasil saat ini sudah memenuhi standar, sekaligus menunjukkan kepada manusia bukti mana yang layak diperiksa.
| Poin | Penjelasan | Nilai |
|---|---|---|
| Kriteria penerimaan ditetapkan lebih awal | Tuliskan tujuan akhir dan target tiap tahap sebelum memulai tugas panjang | Mengurangi kemungkinan Agent menganggap keberhasilan lokal sebagai penyelesaian menyeluruh |
| Gerbang dapat dijalankan | Ditentukan melalui perintah, skrip, CI, atau hasil eksekusi nyata | Agent dapat beriterasi sendiri tanpa menunggu manusia |
| Memeriksa perilaku sistem | Fokus pada performa program saat benar-benar dijalankan | Menemukan output keliru yang “terlihat meyakinkan” |
| Tanggung jawab berlapis manusia–Agent | Manusia menentukan arsitektur dan kriteria penerimaan; Agent melakukan implementasi dan regresi | Manusia tidak lagi menjadi bagian paling lambat dalam loop |
| Anggaran terkendali | Tetapkan lebih dulu jumlah kegagalan, penggunaan, dan kondisi jeda | Mencegah tugas panjang terus menghabiskan sumber daya ke arah yang salah |
Gerbang Validasi Agent dalam Studi Kasus Ginux
Kurtzer tidak menyerahkan tugas “menulis kernel” langsung kepada Agent. Ia memilih gerbang ketat berupa apakah program ruang pengguna Linux dapat berjalan dan apakah systemd dapat dijalankan. systemd bergantung pada banyak komponen sistem dan merupakan proses inti untuk boot serta menjalankan seluruh sistem, sehingga sangat cocok untuk menguji apakah kernel benar-benar bisa digunakan.
Proyek ini berjalan dalam dua loop yang saling melengkapi. Loop luar dipimpin manusia, mulai dari visi, arsitektur dan batasan, gerbang validasi, sampai meninjau perilaku aktual dan memutuskan perbaikan atau penerimaan; loop dalam dikerjakan Agent, yang berulang kali melakukan implementasi, build dan menjalankannya di QEMU, mengukur dan menganalisis kegagalan, merevisi, serta menjalankan uji regresi.
Kurtzer juga mengingatkan secara khusus bahwa banyak kegagalan menghasilkan output yang tampak sangat meyakinkan, padahal kenyataannya melanggar semantik, persyaratan isolasi, atau perilaku siklus hidup. Tanpa gerbang validasi, hasil akhirnya mudah menjadi kode yang tampak bisa berjalan tetapi strukturnya lemah.
Mengapa Gerbang Validasi Agent Harus Berjalan Otomatis
Lauren Tan, engineer di Cursor, juga memandang validasi sebagai keterampilan terpenting saat menggunakan Agent. Validasi yang ia maksud mencakup membuat Agent benar-benar menjalankan kode, mengambil trace CPU atau snapshot heap, membuka simulator iOS, dan mengoperasikan aplikasi seperti yang dilakukan pengguna.
Ia secara terbuka menyebut bahwa setiap bulan ia dapat menggabungkan 4000 PR ke lingkungan produksi. Bahkan jika setiap PR hanya diperiksa manusia selama 5 menit, totalnya tetap sekitar 333 jam. Jadi, pada skala ini sistem pemeriksaan harus dapat berjalan tanpa intervensi manusia. Kasus ekstrem ini menuai banyak kontroversi, tetapi ia menunjukkan prinsip yang juga berlaku bagi tim biasa: Agent dapat terus bekerja hanya jika mampu memeriksa outputnya sendiri; jika tidak, ia hanya bisa menyerahkan diff kepada Anda lalu berhenti.
Arsitektur dua loop pada gambar dapat langsung diterapkan ke proyek sehari-hari. Jika ingin memakai model berbeda untuk peran implementasi dan peninjauan, Anda dapat mengaksesnya melalui APIYI apiyi.com, lalu memasukkan pemanggilan model ke dalam loop internal.
Panduan Cepat Gerbang Penerimaan Agent: Metode Desain 5 Langkah
Berikut contoh dengan tugas yang umum: meminta Agent memigrasikan layanan REST versi lama ke framework baru, sambil menjaga agar klien yang ada tidak terdampak. Anda bisa mengganti item pemeriksaan dalam contoh dengan proses build, pengujian, dan deployment proyek Anda sendiri.
Langkah 1: Tentukan titik akhir tingkat sistem untuk gerbang penerimaan Agent
Tulis dulu satu kalimat yang bisa diamati, untuk menggambarkan apa yang seharusnya terjadi pada sistem saat tugas selesai. “Menyelesaikan migrasi layanan” terlalu kabur, sedangkan “menggunakan kumpulan permintaan replay yang sama, kode status dan field respons kunci layanan lama dan baru tetap konsisten” bisa diverifikasi.
Titik akhir yang baik biasanya berasal dari jalur penggunaan nyata. Titik akhir Ginux adalah Rocky Linux 10 berjalan hingga multi-user.target di systemd; titik akhir aplikasi web bisa berupa alur pengguna inti berjalan lancar; titik akhir tugas data bisa berupa hasil output yang konsisten dengan dataset acuan.
Langkah 2: Memecah gerbang penerimaan Agent menjadi lima lapis
Umpan balik dari satu tes akhir saja terlalu lambat, dan ketika Agent gagal pun akan sulit melacak akar masalahnya. Sebaiknya susun gerbang pemeriksaan menurut biaya eksekusi dari rendah ke tinggi, supaya pemeriksaan yang murah lebih dulu menahan kesalahan yang sudah jelas.
| Tingkat Gerbang | Isi Pemeriksaan | Contoh | Tindakan Setelah Gagal |
|---|---|---|---|
| L1 Batasan statis | Format, tipe, batas dependensi | Melarang impor silang antar modul | Agent langsung memperbaiki |
| L2 Perilaku unit | Logika fungsi dan modul | Tes unit inti | Agent melacak lalu memperbaiki |
| L3 Kontrak integrasi | Antarmuka, basis data, dependensi eksternal | Tes kontrak antarmuka | Agent membandingkan perbedaan lalu merevisi |
| L4 Operasi sistem | Perilaku nyata layanan secara utuh | Menjalankan layanan dan memutar ulang permintaan | Agent mengumpulkan log dan data performa |
| L5 Penerimaan manusia | Arsitektur, risiko, dan trade-off bisnis | Meninjau paket bukti dan memutuskan apakah digabungkan | Manusia memberi batasan baru atau menghentikan tugas |
Arsitektur Dune milik Lauren Tan adalah contoh ekstrem untuk L1. Ia merestrukturisasi proyek melalui lebih dari 600 PR, dan memakai CI untuk memverifikasi graf dependensi agar direktori main dan renderer di Electron tidak saling mengimpor, sekaligus melarang useEffect dan melarang penulisan komentar. Aturan-aturan ini belum tentu cocok untuk basis kode Anda, tetapi pendekatan menuliskan batasan tim sebagai pemeriksaan otomatis layak ditiru.
Langkah 3: Tulis gerbang penerimaan Agent sebagai kartu yang dapat dieksekusi
Setiap gerbang harus memiliki kartu singkat yang ditempatkan di dokumen proyek yang dapat dibaca Agent saat mulai. Setelah kartu ditulis dengan jelas, Agent tidak perlu menebak “apa yang dimaksud dengan lulus”, dan manusia juga dapat melacak bukti berdasarkan kartu tersebut.
| Bidang | Persyaratan pengisian | Contoh migrasi layanan |
|---|---|---|
| Nama gerbang | Beri nama berdasarkan perilaku | Konsistensi permintaan replay |
| Lingkungan eksekusi | Versi dan dependensi tetap | Lingkungan pengujian terisolasi, menggunakan snapshot data tetap |
| Titik masuk eksekusi | Sediakan satu perintah yang jelas | make gate-replay (contoh perintah) |
| Kriteria lulus | Gunakan hasil yang dapat dibandingkan | Kode status dan field kunci semuanya konsisten |
| Artefak bukti | Simpan file yang dapat diperiksa ulang | Laporan perbedaan, log layanan, catatan performa |
| Aturan perlindungan | Tandai konten yang tidak boleh diubah | Sampel penerimaan dan skrip penilaian hanya-baca |
| Strategi kegagalan | Jelaskan tindakan berikutnya | Jika kesalahan yang sama tidak teratasi selama 3 putaran berturut-turut, hentikan sementara |
Di antara semua ini, aturan perlindungan paling mudah diabaikan. Agent cenderung memilih jalur yang paling praktis saat itu; jika ia dapat mengubah sampel penerimaan atau melonggarkan skrip penilaian, hasil pengujian akan kehilangan makna. Sebaiknya letakkan bagian ini di direktori yang dilindungi dan periksa perubahan terkait di CI.
Langkah 4: Menjadikan checkpoint penerimaan Agent masuk ke dalam siklus regresi otomatis
Tuliskan loop internal ke dalam deskripsi tugas: selesaikan dulu satu perubahan kecil, jalankan checkpoint pada level saat ini, baca bukti kegagalan, lakukan revisi, lalu jalankan kembali checkpoint yang sebelumnya sudah lolos. Regresi di sini sangat penting, karena jika tidak, setelah Agent memperbaiki satu tempat, ia bisa diam-diam merusak tempat lain.
Di akhir setiap putaran, minta Agent mencatat isi perubahan, checkpoint yang dijalankan, hasil, dan masalah yang belum terselesaikan. Konteks tugas panjang akan terus bertambah; catatan ini membantu sesi berikutnya memulihkan status dengan cepat, sekaligus memudahkan manusia menilai apakah ia terus bergerak maju atau justru berputar di tempat.
Checkpoint penerimaan juga harus mencegah “lolos palsu”. Beberapa situasi berikut terutama sering terjadi saat tugas dijalankan dalam waktu lama:
| Jenis lolos palsu | Gejala khas | Garis pertahanan terkait |
|---|---|---|
| Tes diubah | Kasus uji yang gagal dihapus atau kriteria penilaian dilonggarkan | File penerimaan hanya-baca, CI memeriksa perubahan |
| Hanya menguji happy path | Permintaan normal lolos, skenario abnormal crash | Tambahkan injeksi kegagalan dan sampel batas |
| Mock menggantikan dependensi nyata | Mock semuanya hijau, lingkungan integrasi gagal | L4 wajib menjalankan layanan nyata |
| Output tampak benar tapi semantik salah | Log lengkap, perilaku siklus hidup salah | Bandingkan status, timing, dan efek samping |
| Keberhasilan lokal menutupi risiko | Satu metrik naik, stabilitas keseluruhan turun | Jalankan regresi penuh di setiap milestone |
Langkah 5: Menetapkan titik keputusan manusia dan kondisi berhenti untuk gerbang penerimaan Agent
Pekerjaan manusia harus difokuskan pada penilaian yang sulit digantikan oleh Agent. Kurtzer bertanggung jawab atas arsitektur, target kompatibilitas Linux, model operasi, interpretasi kegagalan, dan keputusan berhenti; ketika tidak puas dengan kode yang dihasilkan Agent, ia bahkan mematikan IDE, menahan keinginan untuk mengedit sendiri, lalu memberikan panduan baru.
Sebaiknya tetapkan setidaknya tiga jenis kondisi jeda: kegagalan berulang pada gerbang yang sama, Agent mencoba mengubah konten yang dilindungi, dan penggunaan tugas mendekati anggaran. Fokus tinjauan setelah jeda juga harus digeser ke depan ke paket bukti: lihat perilaku sistem dan risiko terlebih dahulu, baru putuskan apakah perlu membaca diff secara mendalam.
Saran memulai cepat: Pilih dulu satu milestone kecil yang bisa diselesaikan dalam sehari, lalu tulis hanya 3 sampai 5 kartu gerbang penerimaan. APIYI apiyi.com menyediakan pemanggilan API untuk model seri GPT, Claude, dan lainnya yang dibahas dalam artikel ini, serta kompatibel dengan format antarmuka OpenAI dan Anthropic. Alat yang ada biasanya hanya perlu menyesuaikan alamat endpoint dan kunci sesuai dokumentasi; model yang tersedia dapat dikonfirmasi di halaman harga APIYI.
Bagaimana gerbang penerimaan Agent mengubah biaya tugas panjang
Biaya tugas panjang tidak bisa hanya dilihat dari “berapa total token yang digunakan”. Laporan menyebutkan bahwa token yang dihitung di beranda Cursor setidaknya mencakup empat kategori: input biasa, output model, penulisan cache, dan pembacaan cache, dengan perbedaan harga yang besar. Komunitas pernah memakai penggunaan 1,5 triliun token yang sama untuk memperkirakan tagihan, dan hasil berbagai algoritme sangat berbeda; perbedaan utamanya berasal dari dasar penagihan dan proporsi cache.
| Item penagihan | Sumber utama dalam tugas panjang | Metode kontrol | Dasar harga |
|---|---|---|---|
| Input biasa | Instruksi tugas, log, potongan kode | Kirim hanya bukti yang terkait kegagalan | Mengacu pada data aktual di halaman harga APIYI |
| Output model | Kode, analisis, dan rencana revisi | Batasi cakupan output per putaran | Mengacu pada data aktual di halaman harga APIYI |
| Penulisan cache | Konteks stabil yang baru atau berubah | Jaga struktur aturan proyek tetap stabil | Mengacu pada data aktual di halaman harga APIYI |
| Pembacaan cache | Konteks yang digunakan ulang lintas putaran | Pantau tingkat cache hit, hindari sering mengubah prefiks | Mengacu pada data aktual di halaman harga APIYI |
Total biaya kasus publik dapat digunakan untuk memahami skala proyek, tetapi tidak bisa langsung dikonversi menjadi harga satuan. Biaya panggilan API Ginux dilaporkan sekitar 8.000 dolar AS, sedangkan eksperimen Nicholas Carlini yang membangun kompilator C dengan 16 agen Claude paralel menghabiskan sekitar 20.000 dolar AS. Model, cache, dan struktur tugas di balik angka-angka tersebut berbeda, sehingga proyek Anda tetap perlu dihitung secara terpisah.
Pendekatan yang lebih aman adalah menyelesaikan satu milestone penuh terlebih dahulu, mencatat penggunaan keempat jenis token dan jumlah kegagalan gerbang, lalu menghitung berdasarkan data terkini di halaman harga APIYI https://docs.apiyi.com/models. Anggaran yang diperoleh dengan cara ini berasal dari bentuk tugas Anda sendiri, sehingga lebih andal daripada langsung memakai harga satuan rata-rata milik orang lain.
Gambar di atas ingin menjelaskan bahwa gerbang itu sendiri juga mengonsumsi sumber daya, tetapi dapat memunculkan kegagalan lebih awal. Bagi tim biasa, tujuannya adalah menukar anggaran terbatas dengan tingkat keyakinan yang memadai, bukan mengejar verifikasi lengkap termahal untuk setiap perubahan.
FAQ Pertanyaan Umum tentang Gerbang Penerimaan Agent
Q1: Apa itu Gerbang Penerimaan Agent?
Ini adalah titik pemeriksaan eksekusi yang telah ditentukan sebelumnya, digunakan untuk menilai apakah hasil tahapan Agent sudah memenuhi standar. Satu gerbang yang lengkap mencakup lingkungan eksekusi, titik masuk eksekusi, kriteria kelulusan, produk bukti, dan strategi kegagalan.
Q2: Apa perbedaan antara Gerbang Penerimaan Agent dan CI biasa?
CI adalah media eksekusi yang umum, sedangkan gerbang penerimaan adalah desain kontrol tugas yang lebih lengkap. Selain menilai apakah kode dapat lulus pengujian, ia juga harus mendefinisikan perilaku sistem, bukti, cakupan regresi, titik keputusan manusia, dan kondisi jeda.
Q3: Kapan harus mendesain Gerbang Penerimaan Agent?
Ketika tugas memerlukan beberapa putaran revisi, melintasi beberapa modul, waktu eksekusi yang lama, atau output kesalahan yang sulit ditemukan secara kasat mata, maka harus dirancang lebih awal. Skrip kecil sekali pakai bisa disederhanakan, tetapi setidaknya harus ada satu cara verifikasi yang dapat dijalankan.
Q4: Jika sudah ada Gerbang Penerimaan Agent, apakah masih perlu Code Review manual?
Perlu. Gerbang otomatis cocok untuk menilai standar yang sudah diketahui, manusia tetap bertanggung jawab atas pemilihan arsitektur, pengambilan risiko, dan penerimaan akhir. Kurtzer juga menekankan bahwa pengalaman tetap sangat penting ketika menilai apakah hasil sudah lengkap dan apakah keberhasilan lokal membawa risiko tingkat sistem.
Q5: Bagaimana cara mengintegrasikan model melalui API untuk menjalankan alur ini?
1. Daftar di APIYI apiyi.com dan buat kunci API.
2. Lihat pusat dokumentasi `docs.apiyi.com`, pastikan alamat antarmuka dan cara pemanggilan.
3. Pilih format antarmuka OpenAI atau Anthropic sesuai alat untuk menyelesaikan konfigurasi.
4. Setelah memastikan model dan harga di `https://docs.apiyi.com/models`, mulai uji coba skala kecil.
Q6: Ketika anggaran terbatas, bagaimana menyederhanakan Gerbang Penerimaan Agent?
Prioritaskan mempertahankan gerbang L1 dan L2 yang berbiaya rendah agar berjalan di setiap putaran; L3 dan L4 dijalankan saat fitur selesai atau pada titik tonggak. Statistik Jellyfish terhadap 12 ribu pengembang menunjukkan bahwa pengguna tipikal menggunakan sekitar 51 juta token per bulan, dengan jarak yang sangat besar dari kasus ekstrem, sehingga frekuensi verifikasi harus ditentukan berdasarkan risiko tugas. Biaya model silakan merujuk pada data aktual di halaman harga APIYI.
Q7: Apa saja keterbatasan Gerbang Penerimaan Agent?
Gerbang hanya dapat mencakup risiko yang telah didefinisikan, dan semua tes hijau tidak berarti kode cocok untuk pemeliharaan jangka panjang. Ginux dapat menjalankan Rocky Linux 10, tetapi masih jauh dari kernel tingkat produksi; dukungan perangkat keras, stabilitas antarmuka, tinjauan keamanan, dan pemeliharaan komunitas tidak dapat dibuktikan dengan satu kali eksekusi. Kritik komunitas terhadap pola PR berfrekuensi tinggi juga mengingatkan kita untuk terus memperhatikan kemudahan pemeliharaan kode.
Poin-Poin Utama Gate Penerimaan Agent
- Definisikan tujuan akhir lebih dulu: jelaskan penyelesaian tugas lewat perilaku sistem yang bisa diamati, hindari target yang kabur.
- Gate harus berlapis: bergerak bertahap dari batasan statis menuju eksekusi nyata dan penerimaan manual.
- Bukti wajib disimpan: simpan log, laporan diff, dan catatan performa di setiap eksekusi.
- Penilaian tidak boleh diubah: sampel dan skrip penerimaan harus dilindungi agar Agent tidak mengambil jalan pintas.
- Regresi jadi rutinitas: setelah memperbaiki masalah baru, jalankan ulang gate terkait yang sudah lolos.
- Manusia memegang keputusan: arsitektur, risiko, kapan berhenti, dan penerimaan akhir ditentukan oleh penanggung jawab.
- Uji biaya lebih dulu: validasi dalam skala kecil lewat APIYI apiyi.com, lalu hitung anggaran berdasarkan halaman harga.
Ringkasan: Membangun Alur Kerja Otonom Mulai dari Gate Penerimaan Agent
Apakah sebuah Agent mampu bekerja otonom dalam waktu lama bergantung pada apakah ia punya tujuan yang jelas dan umpan balik yang andal. Saat merancang gate penerimaan Agent, ingat tiga hal berikut:
- Ubah “selesai” menjadi standar yang bisa dieksekusi: biarkan Agent menilai kemajuan berdasarkan hasil eksekusi.
- Serahkan verifikasi berfrekuensi tinggi ke mesin: gunakan gate berlapis, regresi otomatis, dan paket bukti untuk memperpendek siklus umpan balik.
- Sisakan keputusan kunci untuk manusia: penanggung jawab menentukan arah arsitektur, batas risiko, dan kapan harus berhenti.
Sebaiknya mulai dari tugas berskala menengah berikutnya: tulis kartu gate terlebih dahulu, baru jalankan Agent. Jika perlu menguji berbagai model, Anda bisa terhubung lewat APIYI apiyi.com menggunakan antarmuka yang kompatibel dengan format OpenAI dan Anthropic; cara konfigurasinya ada di pusat dokumentasi docs.apiyi.com, sedangkan harga model dan dasar penagihan mengikuti data aktual di https://docs.apiyi.com/models.
📚 Referensi
- InfoQ – Laporan proyek Ginux: Proses Codex membangun kernel yang kompatibel dengan Linux dan metode penerimaannya
- Tautan:
infoq.cn/article/OiyNEtFwV05opvsLTcvK -
Keterangan: Mencakup loop ganda HDAE, skala proyek, dan analisis keterbatasannya
-
InfoQ – Laporan tagihan token engineer Cursor: Alur kerja Agent intensitas tinggi dan kontroversi biaya
- Tautan:
infoq.cn/article/q9iebpvFozfy4bgCYUyE -
Keterangan: Mencakup loop verifikasi tertutup, arsitektur Dune, dan kritik komunitas
-
Laporan teknis Ginux: Laporan teknis proyek yang dirilis oleh Gregory Kurtzer
- Tautan:
zenodo.org/records/23682548 -
Keterangan: Cocok untuk memahami tujuan penelitian, metode, dan batasan hasil secara lebih mendalam
-
Repositori GitHub Ginux: Kode sumber proyek
- Tautan:
github.com/gmkurtzer/ginux -
Keterangan: Anda dapat melihat kode proyek dan informasi lisensi open source
-
Dokumentasi dan halaman harga APIYI: Penjelasan konfigurasi API dan harga model
- Tautan dokumentasi:
docs.apiyi.com - Tautan harga:
https://docs.apiyi.com/models - Keterangan: Model, harga, dan dasar penagihan mengikuti data aktual di halaman terkait
Penulis: Tim Teknis APIYI
Diskusi teknis: Silakan kunjungi APIYI di apiyi.com untuk berdiskusi dengan kami tentang praktik rekayasa Agent. Informasi integrasi lainnya dapat dilihat di pusat dokumentasi docs.apiyi.com.
