Saat menjalankan beberapa proyek dengan Claude Code, jumlah subagen terus bertambah.
Setiap kali dibutuhkan, saya membuat satu, sampai akhirnya menjadi 22.
Bulan lalu saya menguranginya menjadi 17.
Namun saat menghentikannya, saya tidak mencatat alasan penghentian.
Tiga bulan kemudian, saat membuka folder arsip, saya tidak bisa tahu mengapa itu dihentikan.
Dari lima, hanya satu yang alasannya tertulis.
Padahal saya satu-satunya orang yang membuatnya.
Mengapa sampai menjadi 22
Saat menambah, alasannya selalu jelas. Karena perlu, maka dibuat.
Masalahnya ada di sisi sebaliknya. Saat menghentikan, pikiran "siapa tahu nanti dipakai" terus mengganjal.
Karena tidak yakin bahwa itu tidak berguna, saya membiarkannya saja. Begitulah jumlahnya menjadi 22.
Jika dilihat sekarang, penyebab bertambahnya hanya satu.
Tidak ada gerbang untuk menilai, "ini seharusnya bukan agen, melainkan tool."
Jika itu pekerjaan berulang dengan prosedur tetap dan tidak membutuhkan penilaian konteks, itu bukan agen.
Cukup dibuat sebagai skill atau skrip. Tidak memakai token, reproduksibilitasnya 100%, dan tidak terlupakan meski sesi berganti.
Tanpa gerbang ini, semuanya menjadi agen.
Lima yang dihentikan
Setelah ditelusuri mundur, penanganannya terbagi menjadi empat jenis. Pembedaan ini penting.
Satu seharusnya sejak awal bukan agen.
Itu menangani penulisan konten, tetapi prosedurnya sepenuhnya tetap.
Saya menggantinya dengan dua skill lalu menghentikannya. Ini saya tetapkan sebagai dilarang dipulihkan.
Kalau tidak, suatu hari seseorang akan membuatnya lagi.
Tiga lainnya perannya tumpang tindih dengan yang lain.
Pemeriksaan keamanan tumpang tindih dengan audit kode, pemantauan cron dengan health check, dan perencanaan dengan eksekusi.
Semuanya berada di area yang sama dengan izin yang sama.
Dari sini saya mendapat satu kriteria.
Jika dua agen tumpang tindih di area yang sama dan dengan izin yang sama,
biaya mempertahankan pemisahan (beban pengelolaan, keterlambatan keputusan delegasi) melebihi manfaatnya.
Perasaan "keduanya memang diperlukan" cukup lama menghambat,
padahal yang seharusnya ditanyakan bukan apakah diperlukan, melainkan apakah layak dipisahkan.
Satu lagi memang tidak dipakai siapa pun.
Traffic fungsi tersebut 0 selama 70 hari.
Ini saya perlakukan sebagai dorman, bukan dihapus. Jika layanan dimulai lagi, akan dipulihkan apa adanya.
Hal yang dipelajari saat menulis angka
Saat menuliskan 22 → 17 di dokumen, saya menyadari satu hal.
Angka ini bukan jumlah file. Ini jumlah agen yang sedang dioperasikan.
Ada satu definisi yang berada di luar direktori, jadi jika hanya menghitung file, hasilnya 21 dan 16.
Karena itu, di bagian paling awal dokumen saya menuliskan dulu apa yang dihitung oleh angka ini.
Lalu saya sertakan hasil verifikasi dengan git ls-tree.
Kalau tidak, nanti seseorang akan menghitung file lalu berhenti di "ini tidak cocok."
Saat menulis angka, ternyata definisi dan metode verifikasinya harus ditulis bersama.
Hal yang diputuskan untuk dijaga saat menghentikan
Dari pengalaman pahit kali ini, muncul empat aturan.
-
Saat menghentikan, tulis alasannya di file. Jika tidak ditulis, tiga bulan kemudian harus ditelusuri mundur. Itu benar-benar terjadi.
-
Jangan hapus, pindahkan dengan rename. Isinya terjaga 100%, sehingga bisa dipulihkan persis seperti aslinya.
-
Nyatakan item yang dilarang dipulihkan. Jika tidak ditulis, suatu hari seseorang akan menghidupkannya lagi.
-
Masukkan "hapus peran duplikat di tempat penyerap" ke prosedur pemulihan. Jika ini dilewatkan, saat dihidupkan kembali keduanya akan melakukan pekerjaan yang sama.
Hal-hal yang turut dirapikan
Sekalian, saya menggabungkan aturan selama 4 tahun dan mempublikasikannya. Saya tuliskan beberapa saja.
Dilarang diam-diam melakukan bypass
Ini adalah aturan agar agen melapor ketika menemui batasan, bukan menerobosnya.
Jika pemblokirannya sah, hanya langkah itu yang ditunda dan sisanya tetap dilanjutkan.
Bahkan jika pemblokiran tampak seperti salah penilaian, agen tidak boleh melakukan bypass sendiri. Ia merangkum dasar alasannya, mengajukannya, lalu meminta konfirmasi.
Dan jika pemblokiran tersebut mengungkap cacat pada aturan itu sendiri, memperbaiki cacat tersebut juga termasuk bagian dari respons.
Sebenarnya aturan ini sendiri lahir seperti itu. Saya membuatnya setelah mengalami pemblokiran.
Jangan menulis FAIL sebagai PASS
Meski sebuah pekerjaan ditutup berdasarkan instruksi, status terukur tetap ditulis apa adanya dan kondisi untuk membuka ulang ditinggalkan.
Laporan menggunakan angka terukur Before/After, dan sisa pekerjaan serta risiko ditulis sebelum pencapaian.
Pada dasarnya agen mendapat tekanan untuk melaporkan keberhasilan. Jika tidak dicegah dengan aturan, ia akan terus begitu.
Mendefinisikan otonomi dengan ambang kuantitatif
Alih-alih dikotomi "boleh/tidak boleh memperbaiki", saya menetapkan dengan angka cakupan yang boleh diperbaiki sendiri oleh agen analitis.
-
Hanya 1 file
-
Kurang dari 5 baris
-
Bukan file tingkat atas
-
Di bawah ambang skor dampak
Harus memenuhi semuanya (AND), dan jika satu saja terkena, harus dieskalasikan.
Dan klausul terakhir adalah intinya — jika ambigu, minta delegasi. Nilai default harus konservatif agar aturan tidak runtuh.
Memisahkan penilaian dan eksekusi
Verifikasi dan investigasi di-fan-out secara paralel ke subagen read-only,
sementara eksekusi file dan DB ditangani secara serial di pusat oleh orkestrator.
Karena jika beberapa agen mengubah file bersama secara bersamaan, pasti akan rusak.
Ada harganya. Pada pekerjaan berskala besar, serial terpusat menjadi bottleneck.
Ini adalah hasil keputusan bahwa meski tahu akan lebih lambat, itu tetap lebih baik daripada konflik.
Repositori
https://github.com/YoungChulMoon/claude-agent-harness
Isinya beberapa file Markdown. Tidak ada yang perlu diinstal.
Letakkan template di bawah .claude/agents/ dan isi hanya bagian yang diperlukan.
Ini bukan satu jawaban benar, melainkan cara yang bekerja selama 4 tahun di lingkungan ini.
Bisa saja tidak cocok tergantung ukuran tim atau karakter proyek.
Ada banyak cerita tentang menambah, tetapi jarang ada cerita tentang mengurangi.
Semoga ini bisa menjadi referensi bagi yang agennya juga sedang membengkak dengan cara serupa.
Belum ada komentar.