Mendesain Sistem Agentic yang Tidak Runtuh di Produksi

Dari demo mengesankan ke agen produksi yang rapuh

Sistem agentic adalah aplikasi di mana LLM tidak sekadar menjawab prompt, tetapi memutuskan apa yang harus dilakukan selanjutnya: alat mana yang dipanggil, data apa yang diambil, langkah mana yang dijalankan, dan kapan ia “selesai.” Mereka menggabungkan model, sekumpulan alat (API, basis data, layanan), sebuah loop perencanaan/eksekusi, dan infrastruktur yang mengikat semuanya.

Dalam demo, ini terlihat magis: agen menyusun rencana, memanggil beberapa alat, dan mengembalikan hasil yang sempurna. Jalur bahagia singkat, latensi rendah, dan tak ada yang gagal bersamaan.

Mengapa demo berhasil dan produksi rusak

Dalam beban nyata, agen yang sama tertekan dengan cara yang tidak pernah dilihat demo:

• API timeout, mengembalikan data parsial, atau berubah kontrak.
• Banyak permintaan berlomba pada sumber daya bersama dan merusak state.
• Percakapan jangka panjang membengkakkan memori dan melewati batas konteks.
• Kesalahan model halus menumpuk pada banyak panggilan alat.

Hasilnya: perilaku fluktuatif yang sulit direproduksi, korupsi data senyap, dan alur pengguna yang kadang menggantung atau berputar selamanya.

Dampak bisnis nyata

Agen yang fluktuatif bukan hanya mengurangi “kesenangan.” Mereka:

• Memicu insiden dan panggilan on-call.
• Menghasilkan jawaban salah yang masuk ke sistem downstream.
• Mengikis kepercayaan pengguna: orang diam-diam berhenti mengandalkan fitur.
• Membengkakkan tagihan cloud melalui retry dan loop tak terkendali.

Fokus panduan ini

Artikel ini tentang pola rekayasa, bukan “prompt yang lebih baik.” Kita akan membahas state machine, kontrak alat eksplisit, strategi retry dan penanganan kegagalan, kontrol memori dan konkurensi, serta pola observabilitas yang membuat sistem agentic dapat diprediksi di bawah beban—bukan sekadar mengesankan di atas panggung.

Mengapa sebagian besar arsitektur agen gagal saat skala

Sebagian besar sistem agen tampak baik dalam demo jalur bahagia tunggal. Mereka gagal ketika trafik, alat, dan kasus tepi datang bersama.

Perilaku rapuh: loop, stall, kerja parsial, error senyap

Orkestrasi naif mengasumsikan model akan “melakukan yang benar” dalam satu atau dua panggilan. Dalam penggunaan nyata, Anda melihat pola berulang:

• Loop: agen terus merencanakan ulang atau memanggil alat yang sama karena tak pernah mengenali penyelesaian atau kegagalan.
• Stall: agen menunggu alat atau subtugas tanpa timeout, meninggalkan sesi pengguna menggantung.
• Kerja parsial: agen menyelesaikan setengah alur kerja (mis. menyusun draf email tetapi tidak mengirimnya, membuat rencana tetapi tidak mengeksekusi langkahnya).
• Error senyap: alat gagal atau skema tidak cocok, tetapi agen dengan percaya diri mengembalikan jawaban yang tampak masuk akal dengan data yang hilang atau salah.

Tanpa state eksplisit dan kondisi akhir, perilaku ini tak terelakkan.

Non-determinisme tersembunyi dan ketidakandalan alat

Sampling LLM, variabilitas latensi, dan timing alat menciptakan non-determinisme tersembunyi. Input yang sama bisa menempuh cabang berbeda, memanggil alat berbeda, atau menafsirkan hasil alat secara berbeda.

Dalam skala, isu alat mendominasi:

• Timeout dan flakiness dari API dan basis data upstream
• Drift skema antara kontrak alat dan apa yang sebenarnya dikembalikan layanan
• Format error yang tidak konsisten yang tak pernah diajarkan pada agen

Setiap hal ini berubah menjadi loop palsu, retry, atau jawaban akhir yang salah.

Konkurensi memperbesar kasus tepi dan ketidaksesuaian produk

Apa yang jarang rusak pada 10 RPS akan rusak terus-menerus pada 1.000 RPS. Konkurensi memperlihatkan:

• Kondisi race pada state bersama atau cache
• Limit rate yang habis menyebabkan kegagalan alat berantai
• Kawanan retry yang dipicu oleh gangguan satu dependensi

Tim produk sering mengharapkan alur kerja deterministik, SLA jelas, dan auditabilitas. Agen, jika dibiarkan tanpa batasan, menawarkan perilaku probabilistik dan kerja upaya-terbaik dengan jaminan lemah.

Ketika arsitektur mengabaikan ketidaksesuaian ini—menganggap agen seperti layanan tradisional alih-alih perencana stokastik—sistem berperilaku tidak terduga tepat ketika reliabilitas paling bermakna.

Prinsip desain untuk sistem agentic yang siap produksi

Agen siap produksi kurang soal “prompt pintar” dan lebih soal desain sistem yang disiplin. Cara berguna memikirkan mereka adalah sebagai mesin kecil yang dapat diprediksi yang kadang memanggil LLM, bukan blob LLM misterius yang kadang menyentuh sistem Anda.

Apa yang membuat agen siap produksi?

Empat properti paling penting:

• Keamanan: agen harus menghormati batas akses data, efek samping, dan janji pada pengguna. Itu berarti izin eksplisit, penjagaan alat, dan penanganan keluaran yang tidak tepercaya dengan hati‑hati.
• Dapat diprediksi: diberi input dan state yang sama, agen harus berperilaku dalam rentang yang sempit dan dapat diperkirakan. Anda harus bisa menjelaskan apa yang bisa dan tidak bisa dilakukannya.
• Dapat di-debug: ketika sesuatu salah, Anda dapat melacak jalurnya: state mana, keputusan mana, alat mana, panggilan model mana. Tidak ada loop tersembunyi, tidak ada “pemikiran” opak tanpa struktur.
• Toleran perubahan: Anda bisa meng-upgrade model, alat, atau strategi tanpa menulis ulang seluruh sistem.

Properti ini tidak didapat dari prompt semata. Mereka didapat dari struktur.

Utamakan workflow eksplisit daripada loop bebas

Pola default banyak tim adalah: “while not done, call the model, let it think, maybe call a tool, repeat”. Ini mudah prototipe dan sulit dioperasikan.

Pola yang lebih aman adalah merepresentasikan agen sebagai workflow eksplisit:

• Definisikan himpunan state terbatas (mis. COLLECTING_INPUT, PLANNING, EXECUTING_STEP, WAITING_ON_HUMAN, DONE).
• Definisikan transisi yang diizinkan antara state.
• Gunakan LLM terutama untuk keputusan lokal: memilih state berikutnya, memilih alat, atau mengisi parameter.

Ini mengubah agen menjadi state machine di mana setiap langkah dapat diperiksa, diuji, dan direplay. Loop bebas terasa fleksibel, tetapi workflow eksplisitlah yang membuat insiden dapat di-debug dan perilaku dapat diaudit.

Pecah “god agent” menjadi keterampilan modular

Agen monolitik yang “melakukan segalanya” menggoda, tetapi mereka menciptakan keterkaitan erat antara tanggung jawab yang tidak berhubungan: perencanaan, pengambilan, logika bisnis, orkestrasi UI, dan lain-lain.

Sebaliknya, susun agen kecil dan berdomain sempit atau skill:

• Seorang perencana yang memecah tugas.
• Seorang eksekutor yang menjalankan langkah konkret.
• Spesialis untuk setiap domain (penagihan, dukungan, analitik, dll.).

Setiap skill bisa punya state machine, alat, dan aturan keamanan sendiri. Logika komposisi menjadi workflow tingkat tinggi, bukan prompt yang terus membesar di dalam satu agen.

Modularitas ini menjaga setiap agen cukup sederhana untuk dipahami dan memungkinkan Anda mengembangkan satu kapabilitas tanpa mendestabilisasi sisanya.

Pisahkan kebijakan, state, dan alat

Model mental berguna adalah membagi agen ke tiga lapis:

1. Kebijakan keputusan (prompt LLM + model)
   Mengenkapsulasi bagaimana agen memilih aksi berikutnya, diinterpretasikan di bawah batasan ketat. Anda harus bisa mengganti model, menyesuaikan temperatur, atau menyempurnakan prompt tanpa meraba-rubah wiring sistem.

2. State machine / engine workflow
   Memiliki di mana Anda berada dalam proses, transisi yang mungkin, dan bagaimana mem-persist kemajuan. Kebijakan menyarankan langkah; state machine memvalidasi dan menerapkannya.

3. Lapisan tooling
   Mengimplementasikan apa yang benar-benar dapat terjadi di dunia: API, basis data, antrean, layanan eksternal. Alat membuka kontrak yang sempit dan bertipe baik serta menegakkan otorisasi, rate limit, dan validasi input.

Dengan pemisahan ini, Anda menghindari jebakan menyembunyikan logika bisnis dalam prompt atau deskripsi alat. LLM menjadi komponen keputusan di dalam cangkang yang deterministik dan jelas, bukan cangkang itu sendiri.

Rancang untuk kecil dan jelas

Sistem agentic yang paling andal bukanlah demo paling mengesankan—melainkan yang perilakunya bisa Anda jelaskan di papan tulis.

Konkret:

• Jaga setiap agen fokus pada satu pekerjaan dan satu metrik keberhasilan utama.
• Enkode workflow dan transisi state secara eksplisit daripada dalam prosa.
• Biarkan LLM memilih antara opsi yang telah didefinisikan dengan baik, bukan menciptakan prosedur lengkap dari awal.

Bias terhadap agen yang kecil, dapat disusun, dan terstruktur inilah yang memungkinkan sistem tumbuh cakupannya tanpa runtuh oleh kompleksitas sendiri.

Memodelkan alur agen sebagai state machine eksplisit

Sebagian besar implementasi agen dimulai sebagai loop "think, act, observe" yang dibungkus panggilan LLM. Itu baik untuk demo, tetapi cepat menjadi opak dan rapuh. Pendekatan yang lebih baik adalah memperlakukan agen sebagai state machine eksplisit: himpunan terbatas state, dengan transisi yang didefinisikan dipicu oleh event.

Mewakili alur agen sebagai state dan transisi

Alih-alih membiarkan model secara implisit memutuskan langkah berikutnya, definisikan diagram state kecil:

• PLAN – menginterpretasikan permintaan pengguna, memecahnya menjadi langkah, memilih alat.
• CALL_TOOL – eksekusi satu panggilan alat (atau batch) dengan input ter­validasi.
• VERIFY – periksa output alat terhadap invarian sederhana atau cek model tambahan.
• RECOVER – tangani error: retry, fallback, atau eskalasi.
• DONE – kembalikan jawaban akhir dan tutup workflow.
• FAILED – error terminal dengan alasan dan konteks yang jelas.

Transisi antara state ini dipicu oleh event bertipe seperti UserRequestReceived, ToolCallSucceeded, ToolValidationFailed, TimeoutExceeded, atau HumanOverride. Setiap event, ditambah state saat ini, menentukan state dan aksi berikutnya.

Ini membuat retry dan timeout mudah: Anda menempelkan kebijakan ke state individual (mis. CALL_TOOL boleh retry 3 kali dengan exponential backoff, PLAN mungkin tidak retry sama sekali) alih-alih menyebarkan logika retry di seluruh basis kode.

Eksternalkan state untuk ketahanan dan skala

Persist state saat ini dan konteks minimal di penyimpanan eksternal (database, antrean, atau engine workflow). Agen lalu menjadi fungsi murni:

next_state, actions = transition(current_state, event, context)

Ini memungkinkan:

• Ketahanan – jika worker mati di tengah run, worker lain bisa melanjutkan dari state yang terakhir dipersist.
• Skala horizontal – worker stateless mengonsumsi event, memperbarui state, dan memancarkan event selanjutnya.
• Replay dan kompensasi – Anda dapat merekonstruksi run, menjalankannya kembali dari state mana pun, atau menjalankan aksi kompensasi ketika flow harus di-rollback.

Manfaat untuk penalaran dan audit

Dengan state machine, setiap langkah perilaku agen eksplisit: state mana yang ditempati, event apa yang terjadi, transisi mana yang menyala, dan efek samping apa yang dihasilkan. Kejelasan itu mempercepat debugging, menyederhanakan investigasi insiden, dan menciptakan jejak audit alami untuk tinjauan kepatuhan. Anda bisa membuktikan, dari log dan riwayat state, bahwa aksi berisiko hanya diambil dari state tertentu dan di bawah kondisi yang terdefinisi.

Mendesain kontrak alat yang andal untuk agen

Agen berperilaku jauh lebih dapat diprediksi ketika alat terlihat kurang seperti “API yang tersembunyi dalam prosa” dan lebih seperti antarmuka yang dirancang dengan eksplisit dan jaminan.

Definisikan kontrak, bukan hanya prompt

Setiap alat harus memiliki kontrak yang mencakup:

• Skema input: field wajib, tipe, enum, constraint, default.
• Skema output: payload sukses, field nullable, dan arti “tidak ada hasil”.
• Model error: error bertipe (mis. InvalidInput, NotFound, RateLimited, TransientFailure) dengan semantik jelas.
• SLA: ekspektasi latensi, target ketersediaan, dan rate limit.

Ekspos kontrak ini ke model sebagai dokumentasi terstruktur, bukan dinding teks. Perencana agen harus tahu error mana yang boleh di-retry, mana yang butuh intervensi pengguna, dan mana yang harus menghentikan workflow.

JSON ketat, validasi ketat

Perlakukan I/O alat seperti API produksi lainnya:

• Gunakan skema JSON ketat (mis. OpenAPI, JSON Schema) untuk input dan output.
• Validasi sebelum panggilan (untuk menangkap kesalahan model) dan setelah (untuk menangkap regresi alat).
• Perbaiki otomatis isu minor (mis. koersi tipe) tapi log untuk tuning nanti.

Ini membiarkan Anda menyederhanakan prompt: alih‑alih instruksi panjang, andalkan panduan berbasis skema. Batasan yang jelas mengurangi argumen yang dihalusinasi dan urutan alat yang tidak masuk akal.

Versi dan kompatibilitas

Alat berevolusi; agen sebaiknya tidak rusak setiap kali begitu.

• Versikan kontrak alat (v1, v1.1, v2) dan pin agen ke versi.
• Hapus field secara bertahap; pertahankan field lama dapat dibaca untuk sementara.
• Tambah field secara backward‑compatible; hindari mengubah semantik secara diam-diam.

Logika perencanaan kemudian aman mencampur agen dan alat pada level kematangan berbeda.

Menangani kegagalan dan mode terdegradasi

Rancang kontrak dengan kegagalan parsial dalam pikiran:

• Izinkan hasil parsial dengan detail error per‑item.
• Definisikan respons terdegradasi (mis. data cached, perkiraan, atau usang) alih-alih kegagalan keras.
• Tandai field mana yang "best effort" versus yang "harus ada".

Agen dapat beradaptasi: melanjutkan workflow dengan fitur berkurang, meminta konfirmasi pengguna, atau beralih ke alat fallback.

Batasan keamanan dan otorisasi

Kontrak alat adalah tempat alami untuk mengenkode batas keamanan:

• Skop apa yang boleh dibaca atau dimodifikasi alat.
• Memerlukan parameter eksplisit untuk aksi sensitif (mis. confirm: true).
• Bedakan operasi scope‑user dari scope‑sistem.

Gabungkan ini dengan pemeriksaan sisi server; jangan mengandalkan model saja untuk “berperilaku”.

Mengapa kontrak bagus menyederhanakan agen

Ketika alat memiliki kontrak jelas, tervalidasi, dan versi, prompt bisa lebih singkat, logika orkestrasi menjadi lebih sederhana, dan debugging jauh lebih mudah. Anda memindahkan kompleksitas dari instruksi berbahasa alami yang rapuh ke skema dan kebijakan deterministik, mengurangi pemanggilan alat yang dihalusinasi dan efek samping tak terduga.

Retry, idempotensi, dan pola penanganan kegagalan

Sistem agentic andal mengasumsikan segala sesuatu pada akhirnya akan gagal: model, alat, jaringan, bahkan lapisan koordinasi Anda sendiri. Tujuannya bukan menghindari kegagalan, tetapi membuatnya murah dan aman.

Idempotensi: fondasi untuk retry yang aman

Idempotensi berarti: mengulangi permintaan yang sama memiliki efek eksternal yang sama seperti melakukannya sekali. Ini krusial untuk agen LLM, yang sering mengeluarkan ulang panggilan alat setelah kegagalan parsial atau respons ambigu.

Buat alat idempoten dengan desain:

• Request ID: setiap panggilan alat menyertakan request_id stabil. Alat menyimpan ini dan mengembalikan hasil yang sama jika melihat ID lagi.
• Upsert daripada insert: gunakan semantik "create-or-update" yang di‑key oleh business key alami atau sintetis, bukan ID auto-increment.
• Checksum dan versi: lampirkan hash konten atau nomor versi sehingga alat dapat mendeteksi duplikat, tulis usang, atau konflik.

Strategi retry yang tidak meledakkan biaya

Gunakan retry terstruktur untuk kegagalan transient (timeout, rate limit, 5xx): exponential backoff, jitter untuk menghindari kawanan herds, dan maks percobaan yang tegas. Log setiap upaya dengan correlation ID sehingga Anda dapat menelusuri perilaku agen.

Untuk kegagalan permanen (4xx, error validasi, pelanggaran aturan bisnis), jangan retry. Surface error terstruktur ke kebijakan agen sehingga agen dapat merencanakan ulang, menanyakan pengguna, atau memilih alat lain.

Circuit breaker dan fallback

Implementasikan circuit breaker pada lapisan agen dan alat: setelah kegagalan berulang, blok sementara pemanggilan ke alat itu dan gagal cepat. Padukan ini dengan fallback yang terdefinisi: mode terdegradasi, data cache, atau alat alternatif.

Hindari retry buta dari loop agen. Tanpa alat idempoten dan kelas kegagalan yang jelas, Anda hanya menggandakan efek samping, latensi, dan biaya.

Mengelola memori, state, dan konsistensi data untuk agen

Agen andal dimulai dengan pemikiran jelas tentang apa itu state dan di mana ia berada.

State jangka pendek vs memori jangka panjang

Perlakukan agen seperti layanan yang menangani sebuah permintaan:

• State jangka pendek: semua yang diperlukan untuk menyelesaikan tugas atau subtugas saat ini. Ini mencakup goal aktif, langkah saat ini, output alat, keputusan parsial, dan variabel kontrol (sisa retry, cabang yang dipilih, dll.). Harus dibatasi dengan ketat dan dapat dibuang setelah workflow selesai.
• Memori jangka panjang: informasi yang harus bertahan lintas run dan sesi: profil pengguna, preferensi, keputusan sebelumnya, riwayat proyek, dan shortcut yang dipelajari.

Mencampur keduanya menyebabkan kebingungan dan bug. Mis. memasukkan hasil alat sementara ke “memori” membuat agen menggunakan konteks usang di percakapan masa depan.

Di mana menyimpan state

Ada tiga opsi utama:

1. Dalam konteks (hanya prompt) – sederhana, latensi rendah, tetapi terbatas dan tidak tahan lama. Terbaik untuk state jangka pendek dalam satu run.
2. Penyimpanan eksternal – database, cache, atau vector store. Gunakan ini untuk memori jangka panjang dan state yang harus tahan restart atau mengoordinasikan worker.
3. Hibrida – simpan state otoritatif secara eksternal; muat hanya yang diperlukan ke konteks untuk langkah berikutnya.

Aturan bagus: LLM adalah fungsi stateless atas objek state eksplisit. Persist objek itu di luar model dan regenerasi prompt darinya.

Hindari anti‑pola “log sebagai memori”

Pola kegagalan umum adalah menggunakan log percakapan, trace, atau prompt mentah sebagai memori de facto.

Masalah:

• Pengambilan menjadi ad hoc dan rapuh.
• Fakta penting terkubur dalam teks panjang.
• Banyak run dapat saling bertentangan tanpa aturan "last write wins" yang jelas.

Sebagai gantinya, definisikan skema memori terstruktur: user_profile, project, task_history, dll. Turunkan log dari state, bukan sebaliknya.

Konsistensi dengan data dan alat bersama

Saat banyak alat atau agen memperbarui entitas yang sama (mis. record CRM atau status tugas), Anda perlu kontrol konsistensi dasar:

• Gunakan sumber kebenaran tunggal untuk entitas kunci (mis. order, tiket, dokumen).
• Utamakan kontrak alat idempoten: alat harus menangani retry dengan aman menggunakan ID stabil dan semantik “upsert”.
• Terapkan konkurensi optimistik (nomor versi, timestamp) saat agen mungkin bersaing memperbarui record yang sama.

Untuk operasi bernilai tinggi, catat log keputusan terpisah dari log percakapan: apa yang diubah, mengapa, dan berdasarkan input mana.

Snapshot dan eksekusi yang dapat dilanjutkan

Agar tahan crash, deploy, dan rate limiting, workflow harus dapat dilanjutkan:

• Setelah setiap langkah signifikan, persist snapshot state: langkah saat ini, input, hasil alat, dan aksi yang tertunda.
• Buat setiap transisi di state machine dapat di‑replay dari snapshot.
• Saat kegagalan atau restart, muat snapshot terakhir dan lanjutkan alih-alih memulai dari awal.

Ini juga memungkinkan debugging time travel: Anda dapat memeriksa dan menjalankan kembali state persis yang menyebabkan keputusan buruk.

Privasi, retensi, dan memori minimal

Memori adalah liabilitas sebesar aset. Untuk agen produksi:

• Modelkan secara eksplisit apa yang tidak boleh disimpan (mis. secret, dokumen mentah, PII sensitif). Gunakan redaksi atau hashing bila perlu.
• Definisikan kebijakan retensi per jenis memori (level sesi, 30 hari, hold hukum, dll.).
• Beri pengguna kontrol melihat dan menghapus memori jangka panjang mereka.
• Hindari menyimpan prompt penuh atau input alat saat ringkasan terstruktur yang lebih kecil cukup.

Perlakukan memori sebagai surface produk: dirancang, diberi versi, dan diatur—bukan hanya dump teks yang terus bertambah yang dilampirkan pada agen.

Konkurensi, rate limit, dan backpressure dalam sistem agen

Agen terlihat sekuensial di papan tulis tetapi berperilaku seperti sistem terdistribusi di bawah beban nyata. Begitu Anda punya banyak pengguna bersamaan, alat, dan job background, Anda akan bergelut dengan kondisi race, kerja duplikat, dan masalah urutan.

Bahaya konkurensi dalam workflow agen

Mode kegagalan umum:

• Race condition: dua eksekusi agen memperbarui tiket, keranjang, atau dokumen yang sama secara bersamaan, saling menimpa.
• Kerja duplikat: retry atau worker yang salah konfigurasi memproses tugas yang sama dua kali (mis. menagih pembayaran ganda).
• Efek tak berurutan: panggilan alat selesai dalam urutan tak terduga, sehingga hasil lama menimpa state baru.

Anda mitigasi ini dengan kontrak alat idempoten, state workflow eksplisit, dan locking optimistik atau pesimistis di layer data.

Antrean vs alur sinkron

Alur request–response sinkron sederhana tetapi rapuh: setiap dependensi harus hidup, dalam batas rate, dan cepat. Begitu agen mem‑fan‑out ke banyak alat atau subtugas paralel, pindahkan langkah panjang atau ber‑efek samping ke belakang antrean.

Orkestrasi berbasis antrean memungkinkan Anda:

• Mengontrol konkurensi dengan worker pool
• Memusatkan retry dan deduplikasi
• Mengisolasi alat lambat atau rewel dari latensi yang dirasakan pengguna

Rate limit dan backpressure

Agen biasanya menyentuh tiga kelas limit:

• Model: token per menit, request per menit, ukuran konteks
• Alat: layanan internal dengan QPS atau batas CPU
• API upstream: kuota pihak ketiga dan batas keras

Anda perlu lapisan rate-limit eksplisit dengan throttle per-pengguna, per-tenant, dan global. Gunakan token bucket atau leaky bucket untuk menegakkan kebijakan, dan expose tipe error jelas (mis. RATE_LIMIT_SOFT, RATE_LIMIT_HARD) agar agen bisa mundur dengan anggun.

Backpressure adalah cara sistem melindungi diri di bawah stres. Strategi termasuk:

• Menjaga lalu lintas non-kritis terlebih dahulu
• Degradasi fitur (konteks lebih kecil, lebih sedikit panggilan alat)
• Menjeda antrean prioritas rendah sambil menjaga alur kritis bergerak

Pantau sinyal saturasi: kedalaman antrean, utilisasi worker, laju error model/alat, dan persentil latensi. Antrean naik bersamaan dengan latensi meningkat atau error 429/503 adalah peringatan dini bahwa agen melampaui lingkungan mereka.

Observability: tracing, metrik, dan log untuk perilaku agen

Anda tidak bisa membuat agen andal jika Anda tidak bisa menjawab dua pertanyaan dengan cepat: apa yang dilakukannya? dan mengapa ia melakukan itu? Observability untuk sistem agentic adalah membuat jawaban tersebut murah dan presisi.

Apa yang perlu terlihat

Rancang observability sehingga satu tugas memiliki trace yang menautkan:

• Setiap langkah agen dan transisi state
• Setiap panggilan alat dan respons
• Setiap pemanggilan model dan variasi prompt

Dalam trace itu, lampirkan log terstruktur untuk keputusan kunci (pilihan routing, revisi rencana, pemicu guardrail) dan metrik untuk volume dan kesehatan.

Trace yang berguna biasanya mencakup:

• Metadata tugas: tenant, pengguna, kanal, prioritas
• State agen: nama state saat ini, state berikutnya, jumlah retry
• I/O alat: input, output, latensi, error, status circuit-breaker
• Panggilan model: ID template prompt, nama model, jumlah token, latensi

Logging dan redaksi

Log prompt, input alat, dan output dalam bentuk terstruktur, tetapi jalankan dulu melalui lapisan redaksi:

• Mask PII dan secret
• Pangkas payload besar dengan hash untuk korelasi
• Tandai field dengan level sensitivitas untuk mengendalikan retensi dan akses

Simpan konten mentah di belakang feature flag di lingkungan non-produksi; produksi harus default ke tampilan ter‑redaksi.

Metrik yang benar-benar penting

Minimal, pantau:

• Tingkat sukses / gagal tugas per agen dan use case
• Rata-rata dan P95 jumlah langkah per tugas
• Latensi: end‑to‑end dan per alat / model
• Biaya per tugas (token, pengeluaran alat) dan per hasil sukses

Saat insiden terjadi, trace dan metrik yang baik memungkinkan Anda beralih dari “agen terasa rewel” ke pernyataan presisi seperti: “P95 tugas gagal di ToolSelection setelah 2 retry karena skema baru di billing_service,” memangkas diagnosis dari jam menjadi menit dan memberikan tuas konkret untuk menyetel perilaku.

Strategi pengujian dan evaluasi untuk sistem agentic

Menguji agen berarti menguji alat yang mereka panggil dan alur yang menghubungkan semuanya. Perlakukan ini seperti pengujian sistem terdistribusi, bukan sekadar utak‑atik prompt.

Unit test: kontrak alat, bukan prompt

Mulai dengan unit test di boundary alat:

• Validasi skema: field wajib, enum, range, dan invarian.
• Periksa idempoten dan semantik error (error apa, kode apa, retryability apa).
• Pastikan alat menangani input malformed dengan anggun dan mengembalikan kegagalan terstruktur.

Tes ini tidak pernah bergantung pada LLM. Anda memanggil alat langsung dengan input sintetis dan menegaskan output atau kontrak error tepatnya.

Integration test: alur dan perilaku multi‑langkah

Integration test menjalankan workflow agen end‑to‑end: LLM + alat + orkestrasi.

Modelkan ini sebagai tes berbasis skenario:

• Jalur bahagia untuk perjalanan pengguna kunci (booking, refund, eskalasi, dll.).
• Kasus tepi: data hilang, kegagalan alat parsial, timeout, rate limit.
• Interaksi lintas‑alat: ketika output alat A menjadi input alat B.

Tes ini menegaskan transisi state dan panggilan alat, bukan setiap token keluaran LLM. Periksa: alat mana yang dipanggil, dengan argumen apa, dalam urutan apa, dan state/hasil akhir apa yang dicapai agen.

Fixture deterministik untuk LLM dan alat

Agar tes repeatable, buat fixture untuk respons LLM dan output alat.

• Rekam respons LLM sekali (per prompt + model + konfigurasi) dan simpan sebagai fixture JSON.
• Mock sistem eksternal di balik alat sehingga tes tidak menyentuh layanan live.
• Gunakan seed eksplisit dan konfigurasi temperatur tetap dalam tes.

Polanya tipikal:

with mocked_llm(fixtures_dir="fixtures/llm"), mocked_tools():
    result = run_agent_scenario(input_case)
    assert result.state == "COMPLETED"

Suite regresi untuk prompt dan skema

Setiap perubahan prompt atau skema harus memicu jalur regresi yang tidak bisa dinegosiasikan:

• Simpan korpus kurasi input plus state yang diharapkan, jejak alat, atau klasifikasi.
• Kunci ini sebagai golden file; diff menyoroti perubahan perilaku.
• Secara eksplisit setujui atau rollback setiap drift pada alur kritis.

Evolusi skema (menambah field, mengetatkan tipe) mendapat kasus regresi sendiri untuk menangkap agen atau alat yang masih menganggap kontrak lama.

Evaluasi offline sebelum rollout

Jangan pernah mengirim model baru, kebijakan, atau strategi routing langsung ke trafik produksi.

Sebaliknya:

• Jalankan ulang korpus regresi offline terhadap konfigurasi baru.
• Lakukan replay tes pada sampel interaksi historis.
• Hitung metrik otomatis (keberhasilan tugas, laju error alat, latensi, biaya) dan, bila perlu, rating manusia pada sampel.

Hanya setelah melewati gate offline varian baru layak masuk produksi, idealnya di balik feature flag dan rollout bertahap.

Manajemen data tes dan anonimisasi

Log agen sering berisi data sensitif pengguna. Pengujian harus menghormatinya.

• Bangun dataset tes dari input yang anonomisasi atau sintetis.
• Hapus atau hash identifier, PII teks bebas, dan secret sebelum menyimpan log atau fixture.
• Segmentasikan akses: insinyur bisa melihat trace perilaku, tetapi bukan secret pengguna mentah.

Kodifikasikan aturan ini sebagai bagian dari pipeline CI sehingga tidak ada artefak tes yang dihasilkan atau disimpan tanpa pemeriksaan anonimisasi.

Mengoperasikan, memonitor, dan mengembangkan agen di produksi

Mengoperasikan agen di produksi lebih mirip menjalankan sistem terdistribusi daripada mengirim model statis. Anda butuh kontrol untuk rollout, target reliabilitas yang jelas, dan manajemen perubahan yang disiplin.

Strategi rollout aman

Perkenalkan agen atau perilaku baru secara bertahap:

• Shadow mode: Jalankan agen berdampingan dengan sistem yang ada, log keputusannya, tetapi jangan biarkan mempengaruhi pengguna. Bandingkan output secara offline.
• Canaries: Ekspos sebagian kecil trafik (mis. 1–5%) ke versi agen baru. Pantau error, latensi, dan kualitas sebelum meningkatkan skala.
• A/B test: Untuk alur yang terlihat pengguna, bandingkan agen baru vs lama pada KPI bisnis, bukan hanya metrik model.

Dukung semua ini dengan feature flag dan kebijakan yang dikonfigurasi: aturan routing, alat yang diaktifkan, temperatur, setelan keamanan. Perubahan harus dapat dideploy lewat konfigurasi, bukan kode, dan segera dapat dibalik.

SLO dan workflow insiden

Tetapkan SLO yang mencerminkan kesehatan sistem dan nilai pengguna:

• Keandalan: tingkat keberhasilan tugas, panggilan alat, dan workflow end-to-end.
• Latensi: p50/p95 untuk jalur kritis.
• Kualitas: skor evaluasi otomatis, distribusi penilaian manusia, atau metrik keberhasilan tugas spesifik.

Kaitkan ini ke alert dan jalankan insiden seperti pada layanan produksi lainnya: kepemilikan jelas, runbook triase, dan langkah mitigasi standar (rollback flag, drain trafik, mode aman).

Perbaikan berkelanjutan dan kontrol perubahan

Gunakan log, trace, dan transkrip percakapan untuk menyempurnakan prompt, alat, dan kebijakan. Perlakukan setiap perubahan sebagai artefak bernomor versi dengan review, persetujuan, dan kemampuan rollback.

Hindari perubahan prompt atau alat diam‑diam. Tanpa kontrol perubahan, Anda tidak dapat mengaitkan regresi ke edit spesifik, dan respons insiden berubah menjadi menebak-nebak alih-alih rekayasa terstruktur.

Arsitektur referensi untuk sistem agentic yang andal

Sistem agentic siap produksi mendapat manfaat dari pemisahan tanggung jawab yang jelas. Tujuannya adalah menjaga agen pintar pada keputusan, tetapi bodi infrastruktur sederhana dan dapat diprediksi.

Komponen inti

1. Gateway / API edge
Titik masuk tunggal untuk klien (app, layanan, UI). Menangani:

• Autentikasi dan otorisasi (pengguna, layanan, tenant)
• Rate limit dan kuota
• Pembentukan permintaan (skema, batas ukuran, validasi dasar)

2. Orchestrator
Orchestrator adalah “batang otak”, bukan otak. Ia mengoordinasikan:

• Planner: menerjemahkan intent pengguna ke workflow atau state machine
• State orchestrator: mengeksekusi workflow itu, melacak state, menangani retry dan timeout
• Policy engine: menegakkan keamanan, kepatuhan, alat yang diizinkan, aturan PII, dan batas biaya

LLM hidup di balik orchestrator, digunakan oleh planner dan oleh alat spesifik yang membutuhkan pemahaman bahasa.

3. Lapisan tooling dan penyimpanan
Logika bisnis tetap di microservice, antrean, dan sistem data yang ada. Alat adalah wrapper tipis di sekitar:

• Layanan internal HTTP/gRPC
• Database, vector store, cache
• API eksternal

Orchestrator memanggil alat lewat kontrak ketat, sementara sistem penyimpanan tetap sumber kebenaran.

Integrasi, kontrol, dan telemetri

Terapkan auth dan kuota di gateway; terapkan keamanan, akses data, dan kebijakan di orchestrator. Semua panggilan (LLM dan alat) memancarkan telemetri terstruktur ke pipeline yang mengisi:

• Trace untuk perilaku langkah demi langkah
• Metrik untuk SLO dan rate limit
• Audit log untuk keamanan dan kepatuhan
• Akuntansi biaya per pengguna, proyek, dan alat

Arsitektur sederhana (gateway → orchestrator tunggal → alat) lebih mudah dioperasikan; menambah planner terpisah, policy engine, dan model gateway meningkatkan fleksibilitas dengan harga koordinasi, latensi, dan kompleksitas operasional lebih tinggi.

Menyatukan semuanya dan langkah selanjutnya untuk tim Anda

Sekarang Anda punya bahan inti untuk agen yang berperilaku dapat diprediksi di bawah beban nyata: state machine eksplisit, kontrak alat jelas, retry disiplin, dan observabilitas mendalam. Langkah terakhir adalah mengubah ide‑ide itu menjadi praktik yang dapat diulang untuk tim Anda.

Pola inti, dalam satu gambaran

Pikirkan setiap agen sebagai workflow stateful:

• Sebuah state machine mendefinisikan langkah legal (plan → gather → act → summarize, dll.) dan transisi di antara mereka.
• Kontrak alat mendefinisikan apa yang tiap aksi bisa lakukan, dengan skema ketat, timeout, dan permukaan error.
• Retry dan idempotensi melindungi setiap interaksi eksternal sehingga replay aman dan efek samping tidak terduplikasi.
• Observability (trace, metrik, log) membuat setiap keputusan dan panggilan alat dapat dijelaskan dan di-debug.

Saat elemen-elemen ini selaras, Anda mendapat sistem yang menurun secara anggun alih‑alih runtuh di bawah kasus tepi.

Daftar periksa ringan untuk productionize agen

Sebelum mengirim prototipe agen ke pengguna nyata, pastikan:

• Workflow: State dan transisi eksplisit; tidak ada loop tersembunyi, tidak ada rantai alat tak berbatas.
• Kontrak: Setiap alat punya input/output bertipe, failure mode jelas, dan timeout.
• Keamanan: Guardrail pada input, output, dan aksi (rate limit, allowlist, kuota).
• Retry: Kebijakan didefinisikan per alat; kunci idempotensi ada untuk semua panggilan ber-efek samping.
• State: Memori dan state persistensi discoped, diberi versi, dan dapat dipulihkan.
• Observability: Anda bisa menjawab “apa yang terjadi?” untuk tiap sesi pengguna dalam satu trace.
• Pengujian: Anda punya tes berbasis skenario plus suite regresi untuk prompt, alat, dan kebijakan.

Jika ada item yang hilang, Anda masih dalam mode prototipe.

Bagaimana tim bisa membagi kepemilikan

Setup berkelanjutan biasanya memisahkan:

• Tim produk: Memegang perilaku agen, prompt, alat spesifik fitur mereka, dan dataset evaluasi.
• Tim platform / infra: Memegang framework state-machine, SDK alat bersama, logging dan tracing, penegakan kebijakan, dan infrastruktur evaluasi bersama.

Ini memungkinkan tim produk bergerak cepat sementara tim platform menegakkan reliabilitas, keamanan, dan kontrol biaya.

Ekstensi masa depan dan iterasi aman

Setelah fondasi stabil, Anda bisa mengeksplorasi:

• Kebijakan berbasis pembelajaran: menggunakan trace yang dicatat untuk meningkatkan routing, pemilihan alat, dan strategi fallback.
• Pembelajaran penguatan: mengoptimalkan hasil jangka panjang seperti penyelesaian tugas atau pendapatan, bukan hanya respons tunggal.
• Workflow yang menyetel diri: menyesuaikan temperatur, alat, atau sub‑flow secara otomatis berdasarkan performa yang diamati.

Kemajuan di sini harus incremental: perkenalkan komponen pembelajaran baru di balik feature flag, dengan evaluasi offline dan guardrail yang kuat.

Tema sepanjang tulisan ini sama: rancang untuk kegagalan, utamakan kejelasan daripada kepintaran, dan iterasi di tempat Anda dapat mengamati dan membalik perubahan dengan aman. Dengan kendala‑kendala itu, sistem agentic berhenti menjadi prototipe menakutkan dan menjadi infrastruktur yang dapat diandalkan organisasi Anda.