Agen AI otonom: cara melepas agen bekerja berjam-jam tanpa menghasilkan sampah

Apa itu agen AI otonom dan apa bedanya dengan permintaan biasa

Kerja biasa dengan agen berjalan langkah demi langkah: Anda menulis prompt, agen melakukan satu langkah, Anda melihat hasilnya lalu memutuskan apa yang dilakukan berikutnya. Agen AI otonom bekerja dalam siklus: Anda sekali saja mendeskripsikan bentuk kondisi akhirnya, lalu agen sendiri mengulang «kerjakan — periksa — perbaiki», sampai tujuan tercapai atau anggaran habis. Sejak dijalankan, Anda boleh meninggalkan komputer.

Kedengarannya sederhana, tetapi pengalaman pertama yang khas begini: agen menerima tugas di pagi hari, dan malamnya ternyata ia menghabiskan beberapa jam memperbaiki bug yang sudah diperbaiki, karena ia lupa apa yang dilakukannya satu jam sebelumnya. Tidak ada yang memberitahunya kapan harus berhenti dan kapan harus memanggil manusia. Di bawah ini cara merancang siklus yang mencegah hal itu.

Catatan penting: siklus tidak menggantikan harness. Harness membuat satu kali jalan menjadi andal, siklus membuat jalan-jalan itu berkelanjutan. Siklus di atas harness yang buruk hanya lebih cepat menghasilkan sampah.

Apakah tugas cocok untuk agen otonom

Pertanyaan pertama: apakah pekerjaan itu punya garis finis yang bisa diperiksa mesin. «Semua tes di direktori tests/payments lulus», «semua fitur dalam daftar berstatus passing», «metrik naik dibanding baseline» — cocok. «Buat kode lebih baik» atau «terus perbaiki pembayaran» — tidak: tujuan seperti itu tidak punya akhir, dan siklus akan berputar sampai anggaran habis.

Berguna untuk membedakan empat jenis siklus:

• Langkah demi langkah — Anda mengetik setiap prompt; ini kerja interaktif biasa.
• Berdasarkan tujuan — Anda menetapkan tujuan, lalu pemeriksaan independen atau anggaran yang menghentikan. Inilah agen otonom untuk berjam-jam.
• Berdasarkan waktu — dijalankan terjadwal (misalnya tinjauan pagi atas build CI yang gagal), dihentikan manual.
• Berdasarkan peristiwa — dipicu peristiwa eksternal (issue baru, deploy yang gagal), berhenti ketika peristiwa selesai diproses atau batas percobaan tercapai.

Kesalahan umum adalah mencampuradukkan siklus berdasarkan waktu dengan siklus berdasarkan tujuan: «setiap 10 menit lanjutkan mengerjakan pembayaran». Siklus terjadwal memulai instruksi dari nol setiap kali dan tidak tahu apa yang sudah dikerjakan. Jika tugas punya garis finis, Anda membutuhkan siklus berdasarkan tujuan dengan memori tentang kemajuan.

Langkah 1. Sandbox: di mana agen boleh merusak

Agen yang bekerja tanpa pengawasan cepat atau lambat akan melakukan sesuatu yang keliru: menghapus file, menulis ulang migrasi, menjalankan perintah berat. Maka pertanyaannya bukan «bagaimana membuatnya tidak pernah salah», melainkan «bagaimana membuat kesalahan tidak berharga».

• Salinan kerja terpisah. git worktree memberi agen direktori dan cabangnya sendiri di atas repositori yang sama. Cabang utama tidak tersentuh, beberapa agen tidak saling mengganggu, dan jalan yang gagal dihapus dengan satu perintah.
• Kontainer atau mesin virtual. Jika agen membutuhkan akses penuh ke perintah, jalankan ia di kontainer tanpa akses ke direktori home, kunci, dan basis data produksi.
• Data uji. Basis data lokal, sandbox sistem pembayaran, kunci palsu. Tidak ada satu pun rahasia produksi di lingkungan agen.

# cabang dan direktori sendiri untuk jalan otonom
git worktree add ../shop-agent -b agent/f03-refunds

# setelah jalan: lihat hasilnya atau buang
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

Langkah 2. Izin: minimum yang cukup untuk tugas

Makin lama agen bekerja sendirian, makin sempit izinnya harus. Di Claude Code izin diatur di settings.json (daftar allow dan deny untuk alat dan perintah): izinkan secara eksplisit apa yang dibutuhkan tugas — menjalankan tes, linter, mengubah file di salinan kerja — dan larang yang berbahaya: push ke cabang utama, pekerjaan dengan rahasia, perintah jaringan jika tidak diperlukan.

Mode di mana agen menjalankan semuanya tanpa konfirmasi hanya boleh dipakai di sandbox terisolasi, di mana skenario terburuknya adalah kontainer yang dibuang. Di mesin kerja dengan akses ke kunci dan repositori Anda, jangan lakukan itu.

Larangan yang tidak boleh dilanggar harus didukung mekanisme, bukan teks. Kalimat «jangan sentuh migrations/» di instruksi hanyalah harapan; hook yang memblokir perubahan di direktori itu, atau izin sistem berkas, adalah jaminan.

Langkah 3. Tujuan, verifikasi, berhenti — tiga baris sebelum peluncuran

Siklus kerja paling sederhana bertumpu pada tiga hal, dan sebaiknya dicatat sebelum jalan dimulai, bukan di tengah jalan:

1. Tujuan — seperti apa kondisi akhirnya.
2. Verifikasi — cara yang bisa diperiksa mesin untuk tahu bahwa tujuan tercapai: perintah yang mengembalikan sukses atau gagal.
3. Kondisi berhenti — batas percobaan, waktu, atau biaya; setelah itu siklus berhenti, meskipun tujuan belum tercapai.

Praktisnya, simpan ini di file metodologi terpisah yang hanya diedit manusia. Contoh untuk backend pembayaran:

# program.md — metodologi jalan otonom

## Tujuan
Semua fitur dari .agent/feature_list.json berstatus passing.

## Metrik
Jumlah fitur di passing. Naik secara monoton. Regresi = rollback segera.

## Batasan
- Satu fitur dikerjakan pada satu waktu.
- Jangan ubah migrations/ dan infra/.
- Jangan ubah dependensi tanpa dicatat di jurnal.

## Urutan kerja
1. Ambil fitur pertama yang belum passing.
2. Terapkan, jalankan pytest dan linter.
3. Hijau — commit dan catat di .agent/progress.md. Merah — perbaiki.

## Berhenti dan eskalasi
- 3 percobaan gagal untuk satu fitur — tandai blocked, lanjut ke berikutnya.
- Semua sisa berstatus blocked — berhenti dan tulis laporan.
- Tugas yang menyangkut uang klien, hak akses, atau penghapusan data — tidak dikerjakan, tetapi dieskalasikan.

Langkah 4. Siklus cek-perbaiki dengan memori di disk

Jendela konteks tidak bertahan dalam kerja panjang: ia penuh, dipadatkan, sesi dimulai ulang. Karena itu kemajuan harus hidup di file, bukan di «kepala» agen: daftar tugas dengan status, jurnal tentang apa yang sudah dikerjakan dan apa yang tidak berhasil, serta riwayat git.

Model yang baik adalah «ratchet yang hanya bergerak maju», seperti pada proyek autoresearch Andrej Karpathy, di mana agen semalaman menjalankan ratusan eksperimen ML. Setiap iterasi: baca metodologi, ajukan hipotesis, ubah kode, jalankan eksperimen dengan anggaran waktu tetap, bandingkan dengan baseline. Membaik — commit; tidak membaik — rollback. Hasilnya dicatat di jurnal, lalu hipotesis berikutnya.

Dari skema ini ada dua keputusan yang layak diambil:

• Anggaran tetap per percobaan. Percobaan menjadi bisa dibandingkan, dan satu hipotesis yang gagal tidak memakan seluruh malam.
• Di cabang utama hanya perbaikan. Semua yang tidak berhasil dibatalkan, bukan dibiarkan berdampingan. git log menjadi jurnal kerja yang terverifikasi dan mudah dibaca di pagi hari.

Di sana juga terlihat pemisahan peran per file: infrastruktur dan penilaian tidak diubah siapa pun, kode eksperimen hanya diubah agen, metodologi hanya diubah manusia. Agen tidak bisa «memperbaiki» hasil dengan mengutak-atik cara pengukurannya.

Langkah 5. Siapa yang memutuskan selesai: penilai terpisah

Ketika tidak ada manusia dalam lingkaran, penilaian diri agen menjadi satu-satunya rem — dan rem itu tidak bekerja. Agen yang baru menulis kode cenderung menganggapnya benar: ia melihat alasannya sendiri dan «tahu», apa yang dimaksudnya.

Aturan pemisahan generator dan penilai:

• Yang menilai bukan sesi yang mengerjakan. Di Claude Code, subagen cocok untuk ini: masing-masing punya konteksnya sendiri.
• Penilai mendapat konteks yang bersih: persyaratan, diff, dan hasil jalannya pemeriksaan — dan tidak ada penalaran pelaksana.
• Jika memungkinkan, penilai adalah model lain, atau setidaknya prompt lain dengan peran lain.
• Vonis dijatuhkan berdasarkan rubrik, dan setiap butir menunjuk bukti: baris tes, keluaran perintah, lokasi di diff.

Pemeriksaan mesin tetap yang utama. Penilai dibutuhkan untuk hal-hal yang tidak ditangkap tes: persyaratan dipahami keliru, tes disesuaikan dengan kode, atau perubahan melampaui lingkup tugas.

Kriteria berhenti: kapan agen harus menyerah

Siklus tanpa kondisi berhenti pasti akan berputar — hanya soal waktu. Kumpulan minimalnya:

Periksa kemajuan berdasarkan isinya, bukan jumlah percobaan: «sudah 40 iterasi» tidak berarti apa-apa, «jumlah fitur hijau naik dari 5 ke 9» berarti sesuatu. Jika tugas macet, serahkan ke manusia, jangan jalankan siklus sekali lagi.

Risiko agen otonom yang tidak langsung terlihat

Risiko yang jelas — berkas terhapus dan build rusak — sudah ditangani sandbox dan izin. Yang lebih berbahaya adalah biaya senyap yang menumpuk selama berminggu-minggu:

• Utang verifikasi. «Kelihatannya normal» menggantikan «terkonfirmasi mesin». Penangkalnya hanya kondisi berhenti yang bisa diperiksa mesin, tanpa pengecualian.
• Pengikisan pemahaman. Anda makin sedikit mengenal kode sendiri. Penangkalnya: wajib membaca diff; kecepatan siklus tidak boleh melampaui kecepatan membaca Anda.
• Kapitulasi kognitif. Anda berhenti punya pendapat tentang hasil dan menerima semuanya. Berguna untuk jujur menghitung kasus «nanti saya lihat», yang ternyata tidak pernah dilihat.
• Membengkaknya konteks. Jalan panjang menumpuk riwayat, dan setiap langkah berikutnya makin mahal dan makin buruk. Pemadatan konteks dan memori eksternal dibutuhkan sejak siklus pertama, bukan setelah semuanya sudah kacau.

Cara menjalankan siklus otonom pertama dalam satu malam

Jangan mulai dengan «agen akan mencari dan mengerjakan tugas sendiri». Otonomi tumbuh bertahap: pertama satu tugas dengan tujuan dan kondisi berhenti, lalu satu otomatisasi terjadwal, lalu pelaksana dan pemeriksa dipisah di salinan kerja terisolasi, dan baru setelah itu siklus yang mencari pekerjaan sendiri dan berjalan paralel.

1. Temukan tugas yang Anda kerjakan manual minimal dua kali seminggu dan punya garis finis yang bisa diperiksa.
2. Tulis tujuan, verifikasi, dan kondisi berhenti — tiga baris.
3. Buat worktree terpisah dan atur izin: tes dan pengeditan file diizinkan, push dan rahasia tidak.
4. Buat file kemajuan dan minta agen memperbaruinya setelah setiap iterasi.
5. Pisahkan peran: pelaksana menulis, pemeriksa di konteks terpisah menilai diff.
6. Tetapkan batas total dan periksa hasil pertama setelah satu jam, bukan di pagi hari.

Ringkasan

Agen AI otonom sekuat batas-batas yang mengelilinginya: sandbox tempat kesalahan tidak berharga, izin minimum, tujuan yang bisa diperiksa mesin, memori di disk, penilai terpisah, dan kondisi berhenti yang keras dengan eskalasi ke manusia. Tanpa itu, jalan panjang bukan penghematan waktu, melainkan pembersihan kekacauan yang ditunda. Cara merangkai siklus semacam ini pada proyek contoh — dari program.md sampai penilai independen — dibahas praktis dalam kursus harness engineering.