AI
AI Agent di Produksi: Pelajaran Setahun Workflow Agentic
Mei 202610 menit baca
Foto oleh Google DeepMind
Foto oleh Google DeepMind
Saya memakai tool coding agentic setiap hari — Claude Code mengerjakan porsi berarti dari refactoring dan scripting infrastruktur saya — dan saya sudah merilis fitur berbentuk agent ke dalam produk. Jarak antara demo agent dan agent di produksi lebih lebar dari jarak mana pun di software yang pernah saya kerjakan. Demonya satu akhir pekan; versi produksinya berbulan-bulan desain tool, guardrail, dan eval.
Tulisan ini adalah file pelajaran yang terus saya perbarui: apa yang benar-benar rusak, apa yang benar-benar membantu, dan urutan ke mana usaha Anda sebaiknya dialirkan. Sebagian besar bermuara pada saran di artikel riset building-effective-agents milik Anthropic, yang saya anggap bacaan wajib — tetapi di sini sudah disaring lewat luka produksi saya sendiri.
Anthropic menarik garisnya dengan presisi: workflow mengorkestrasi panggilan LLM lewat jalur kode yang sudah ditentukan, sementara agent membiarkan model mengarahkan proses dan penggunaan tool-nya sendiri secara dinamis. Kegagalan produksi paling umum yang saya lihat adalah memilih yang kedua saat tugasnya menginginkan yang pertama. Kalau tugas Anda punya urutan yang diketahui — ambil invoice, ekstrak field, validasi, kirim ke ERP — tulis urutannya dalam kode dan taruh LLM di dalam langkah-langkahnya, bukan sebagai komandannya.
Wilayah agent sejati adalah saat trajektori tidak bisa dispesifikasikan di muka: debugging, riset terbuka, perubahan kode lintas banyak file. Tes jujur yang saya pakai: bisakah saya menggambar flowchart-nya? Kalau bisa, itu workflow, dan versi deterministiknya akan lebih murah, lebih cepat, dan jauh lebih mudah di-debug. Mulai sederhana dan tambahkan otonomi hanya saat sistem yang lebih sederhana terbukti kalah performa.
Agent persis sebaik tool-nya. Tim engineering Anthropic memperlakukan antarmuka agent-komputer dengan ketelitian yang sama seperti antarmuka manusia, dan setelah setahun menulis tool saya setuju dengan setiap katanya. Aturan-aturan yang terbukti membayar sewa:
Lebih sedikit tool, berbentuk tugas
Jangan bungkus setiap endpoint API. Satu tool schedule_meeting yang menangani ketersediaan secara internal mengalahkan list_users plus list_events plus create_event — tiga tool berarti tiga peluang salah merangkainya.
Deskripsi adalah prompt
Tulis setiap deskripsi seolah meng-onboard rekan kerja baru, dan nyatakan kapan tool dipanggil, bukan hanya apa fungsinya. Perbaikan kecil pada redaksi menghasilkan perubahan perilaku yang terukur — perlakukan deskripsi sebagai artefak yang bisa dituning dan dievaluasi.
Buat kesalahan sulit diekspresikan
Wajibkan path absolut, pakai enum alih-alih string bebas, validasi agresif, dan kembalikan pesan error yang bisa ditindaklanjuti. Agent mengulang sesuai apa kata error-nya; 400 yang kabur menghasilkan loop.
Kembalikan konteks ramping dan bermakna
Agent punya anggaran konteks. Kembalikan nama alih-alih ID kriptik, paginasi hasil besar, dan filter di sisi server. Setiap token sampah yang Anda kembalikan adalah kapasitas penalaran yang Anda rampas.
// Tool descriptions are prompts. Say WHEN to call it, not just what it does.
{
"name": "search_orders",
"description": "Search customer orders by status, date range, or customer email.
Call this whenever the user asks about a specific order, a refund,
or delivery status. Do NOT answer order questions from memory.",
"input_schema": {
"type": "object",
"properties": {
"query": { "type": "string", "description": "Free-text search, e.g. an order ID or email" },
"status": { "type": "string", "enum": ["pending", "paid", "shipped", "refunded"] }
},
"required": ["query"]
}
}Menyuruh model berhati-hati bukanlah guardrail. Lapisan-lapisan yang benar-benar menyelamatkan saya, berurutan prioritas:
Heuristik desain di bawah keempatnya: urutkan setiap aksi berdasarkan reversibilitas. Aksi yang bisa dibalik boleh otonom; aksi yang sulit dibalik diberi gerbang. Ini juga alasan tool khusus mengalahkan tool bash generik untuk operasi sensitif — tool send_email mudah dicegat dan dikonfirmasi, sementara perintah shell yang kebetulan memanggil curl itu buram bagi harness Anda.
Agent tanpa suite eval adalah sistem yang kualitasnya Anda ketahui dari pengguna. Sebelum fitur agent apa pun rilis, saya ingin tiga lapisan terpasang:
Panduan penulisan tool Anthropic mendorong loop ini lebih jauh: pakai agent-nya sendiri untuk menganalisis transkrip gagalnya dan mengusulkan perbaikan tool. Hasilnya memalukan saking bagusnya — agent jago menemukan di mana tool membingungkannya, dan perbaikannya sering hanya satu kalimat di deskripsi.
Proses panjang, multi-langkah, non-deterministik — orang infrastruktur punya kata untuk ini, dan kata itu bukan kecerdasan. Agent produksi butuh apa yang dibutuhkan setiap queue worker: timeout, retry dengan idempotency key supaya langkah yang diulang tidak mengirim email dua kali, checkpoint supaya run 20 langkah bisa lanjut dari langkah 14, dan penanganan dead-letter untuk tugas yang terus gagal.
Di stack saya itu berarti run agent adalah job dalam queue dengan state di PostgreSQL, trace dikirim ke Loki, dan belanja token per run digrafikkan di Grafana bersebelahan dengan grafik CPU. Model adalah bagian paling tidak terobservasi dari sistem, dan justru karena itu segala sesuatu di sekitarnya harus paling terobservasi.
Tim yang sukses dengan agent bukan yang prompt-nya paling pintar — melainkan yang paling disiplin merekayasa segala hal di sekitar model: tool yang membosankan, guardrail berlapis, eval di CI, dan observabilitas kelas ops. Bangun sistem yang tepat untuk kebutuhan Anda, mulai dari yang paling sederhana yang bekerja, dan dapatkan setiap tingkat otonomi dengan bukti.
Sumber dan bacaan lanjutan