Refactoring Agen untuk Era Claude 4: Meninggalkan Sharding Rumit dan Mengimplementasikan Loop 3-Agen ke dalam Kode

Strategi Migrasi Data dari Legacy Sharding ke Loop 3-Agent

Micro-sharding yang didorong oleh LangChain atau AutoGPT versi lama telah gagal. Memecah langkah menjadi puluhan bagian mungkin membuat rantai logika terlihat canggih, namun kenyataannya, konteks terpotong di setiap pemanggilan (call) dan hanya meningkatkan non-determinisme. Saat menggunakan LLM dengan kemampuan penalaran yang meningkat pesat seperti Claude 3.5 atau model 4 yang akan segera hadir, Anda harus mengubah strategi. Jangan bergumul dengan node yang terfragmentasi. Sebaliknya, integrasikan ke dalam struktur manajemen status terpusat yang dikendalikan oleh Planner.

Untuk transisi arsitektur yang sukses, pertama-tama kelompokkan tugas-tugas mikro yang ada menjadi metode di dalam satu kelas dan enkapsulasi sebagai Tool Box. Kemudian, definisikan objek State tunggal yang dirujuk oleh semua agen. Objek ini wajib menyertakan field plan (rencana langkah demi langkah), history (log eksekusi alat), dan artifacts (data yang dihasilkan).

Manfaatkan fitur reducer dari LangGraph agar setiap agen memperbarui status bersama (shared state) ini setiap kali mereka menyelesaikan tugas. Memblokir pemutusan konteks secara fisik akan menghilangkan pengiriman token duplikat. Tim yang beralih ke struktur ini secara praktis telah memangkas biaya API lebih dari 30% seketika.

Implementasi Kode Tabel Penilaian Kuantitatif untuk Evaluator

Penilaian subjektif bahwa hasil keluaran agen "terlihat oke" adalah bom waktu di lingkungan produksi. Terapkan pola LLM-as-a-Judge, namun ini harus dipaksakan di level kode. Agen Evaluator harus memecah hasil keluaran dari Generator menjadi 4 indikator: akurasi, konsistensi, keterbacaan, dan efisiensi, lalu mengonversinya menjadi angka.

Gunakan pustaka Pydantic untuk memaksa hasil evaluasi mengikuti skema JSON tertentu.

• Deklarasikan kelas RubricScore dan tetapkan setiap indikator sebagai field integer antara 1~5.
• Cantumkan kondisi pemenuhan spesifik untuk setiap rentang skor di dalam prompt (misalnya: skor efisiensi 5 diberikan jika kompleksitas waktu mencapai $O(n)$ atau kurang).
• Jika skor rata-rata di bawah 4.0, jalankan Merge Block untuk menghentikan deployment secara otomatis di pipeline CI/CD dan mengirim sinyal pengerjaan ulang.

Membangun sistem verifikasi otomatis seperti ini mengurangi waktu verifikasi yang biasanya memakan waktu 5 jam oleh manusia menjadi kurang dari 10 menit. Penilaian mekanis mungkin terasa dingin, tetapi hal itu meningkatkan prediktabilitas sistem.

Optimalisasi Biaya Menggunakan Anthropic Prompt Caching

Begitu loop agen mulai berjalan, token akan menumpuk dengan kecepatan yang menakutkan. Mengirimkan instruksi sistem dan definisi alat berulang kali di setiap waktu sama saja dengan membuang uang ke jalan. Prompt caching dari Claude hanya mengenakan biaya sekitar 10% dari tarif normal untuk token yang di-cache. Untuk mendapatkan manfaat ini, Anda harus menggunakan strategi pencocokan awalan (prefix matching) dengan menyusun struktur prompt dari bagian statis ke bagian dinamis (Tools → System → Messages).

• Tempatkan instruksi dan definisi alat yang tidak berubah di posisi paling atas dan tetapkan breakpoint cache_control.
• Gunakan tag <system-reminder> di dalam pesan pengguna untuk menyisipkan informasi variabel. Ini dilakukan agar cache pada awalan di bagian atas tidak rusak.
• Tempatkan breakpoint tambahan secara strategis di setiap titik window look-back 20 blok saat percakapan mulai panjang.

Jika strategi caching dirancang dengan benar, Anda dapat memotong biaya pemanggilan API hingga 90%. Kecepatan respons juga akan meningkat secara signifikan. Ini adalah satu-satunya cara untuk menghemat uang dan waktu sekaligus.

Desain Circuit Breaker untuk Mencegah Infinite Loop

Jika Generator dan Evaluator saling bersikeras dan tidak mencapai kesepakatan, agen akan terjebak dalam deadlock. Ini bukan sekadar kesalahan biasa, melainkan bencana yang menyebabkan pembengkakan biaya. Untuk mencegahnya, diperlukan circuit breaker berlapis yang memantau jumlah eksekusi dan kemiripan respons. Terutama jika kemiripan kosinus (cosine similarity) antara respons sebelumnya dan sekarang adalah 0.95 atau lebih, itu adalah sinyal jelas bahwa agen sedang mengulang kata-kata yang sama dan terjebak dalam loop yang bodoh.

1. Masukkan counter pada loop utama yang membatasi jumlah maksimum giliran (Max-Turn Limit) sebanyak 15 kali per sesi.
2. Tetapkan batas anggaran per sesi (Budget Cap) dan pantau secara real-time di API gateway.
3. Jika pemutus arus (circuit breaker) aktif, segera ringkas jejak eksekusi (execution trace), kirim ke Slack, dan minta intervensi manusia (Human-in-the-loop).

Memberikan otoritas penuh kepada agen bukanlah tindakan berani, melainkan tidak bertanggung jawab. Lebih baik tidak mengoperasikan sistem agen jika tidak memiliki perangkat keselamatan.

Dasbor Observabilitas Khusus untuk Tim Agen

Proses kerja ketiga agen yang saling bercampur adalah sebuah kotak hitam (black box). Jika Anda tidak tahu di mana hambatan (bottleneck) terjadi, perbaikan tidak mungkin dilakukan. Pasang sistem pelacakan yang mengikuti standar OpenTelemetry untuk memvisualisasikan aliran pesan antar agen. Implementasikan checkpointing berbasis Redis sehingga jika sistem mati, Anda tidak perlu memulai dari awal, melainkan dapat melanjutkan dari titik keberhasilan terakhir.

Ekstrak nilai cache_read_input_tokens dari header respons API dan tampilkan di dasbor. Jika rasio cache hit rendah, itu bukti bahwa struktur prompt Anda salah. Selain itu, dengan menjadikan kecepatan konvergensi loop sebagai metrik, Anda dapat membuktikan hasil dari prompt engineering dengan angka. Menyimpan ID sesi dan versi artefak di PostgreSQL memungkinkan Anda untuk meninjau secara presisi di titik mana tim agen mengalami kesulitan di masa lalu. Agen yang tidak tercatat tidak akan pernah menjadi lebih cerdas.