Skip to main content
BlogAI

AI Agent di Produksi: Pelajaran Setahun Workflow Agentic

Desain tool, guardrail, dan loop eval: pelajaran tak glamor dari menjalankan AI agent di produksi dan memakai tool coding agentic setiap hari.

Matthews Wong

Software Engineer

Mei 202610 menit baca
AI Agent di Produksi: Pelajaran Setahun Workflow Agentic

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.

Pelajaran Satu: Kebanyakan Agent Seharusnya Workflow

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.

Pelajaran Dua: Desain Tool Adalah Sebagian Besar Pekerjaannya

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"]
  }
}

Pelajaran Tiga: Guardrail Itu Arsitektur, Bukan Prompt

Menyuruh model berhati-hati bukanlah guardrail. Lapisan-lapisan yang benar-benar menyelamatkan saya, berurutan prioritas:

  1. Tingkatan izin per tool. Tool read-only bebas berjalan; tool yang mengubah data lewat pemeriksaan policy; tool ireversibel — mengirim email, menghapus data, menyentuh uang — wajib konfirmasi manusia eksplisit di dalam loop.
  2. Kredensial ter-scope. User database milik agent dapat scope level baris, token API-nya dapat grant minimal, dan filesystem-nya adalah sandbox. Asumsikan model suatu saat akan melakukan hal terbodoh yang diizinkan.
  3. Batas anggaran per run: maksimum panggilan tool, maksimum token, maksimum menit wall-clock. Loop liar harus menabrak tembok yang Anda pilih, bukan tagihan yang Anda temukan.
  4. Logging trace penuh untuk setiap panggilan tool beserta input dan output. Saat agent berulah, trace adalah beda antara perbaikan dan angkat bahu.

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.

Pelajaran Empat: Tanpa Eval, Tanpa Agent

Agent tanpa suite eval adalah sistem yang kualitasnya Anda ketahui dari pengguna. Sebelum fitur agent apa pun rilis, saya ingin tiga lapisan terpasang:

  • Tes level tool: untuk state tertentu, apakah model memilih tool yang benar dengan argumen yang benar? Murah dijalankan, menangkap kebanyakan regresi dari perubahan prompt atau deskripsi.
  • Eval trajektori: 20 sampai 50 tugas realistis yang dinilai ujung ke ujung — selesai atau tidak, berapa langkah, berapa biayanya. Jalankan pada setiap perubahan prompt dan upgrade model.
  • Sampling produksi: irisan harian trace nyata yang ditinjau manusia atau LLM judge, karena pengguna nyata menemukan trajektori yang tak pernah dibayangkan test set Anda.

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.

Pelajaran Lima: Agent Adalah Masalah Ops Berkostum AI

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.

Checklist Pra-Peluncuran

  • Tes flowchart lulus: semua yang berurutan tetap dibangun sebagai workflow, bukan agent.
  • Tool berbentuk tugas, dengan deskripsi kapan-dipakai dan input yang dibatasi enum.
  • Tingkatan izin, kredensial ter-scope, dan batas anggaran per run ditegakkan dalam kode.
  • Eval level tool dan trajektori berjalan di CI; skor baseline dicatat sebelum setiap perubahan model atau prompt.
  • Setiap run meninggalkan trace lengkap berikut biaya, dan aksi ireversibel muncul di antrean review manusia.

Kesimpulan

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.

FAQ

Pertanyaan Umum

Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.

Bagaimana cara memutuskan apakah harus membangun workflow atau agent AI yang sesungguhnya?

Gunakan tes flowchart: jika Anda bisa menggambar urutan langkah-langkahnya di muka, bangun workflow deterministik dan taruh LLM di dalam langkah-langkahnya, bukan sebagai komandannya. Wilayah agent sejati hanya untuk tugas yang trajektorinya tidak bisa dispesifikasikan sebelumnya, seperti debugging terbuka atau perubahan kode lintas banyak file. Mulai dari sistem yang paling sederhana dan tambahkan otonomi hanya saat sistem yang lebih sederhana terbukti kalah performa.

Mengapa desain tool begitu krusial untuk agent di produksi?

Agent persis sebaik tool-nya. Tool yang berbentuk tugas dan menangani operasi terkait secara internal mengalahkan kumpulan wrapper API yang terlalu granular, karena lebih sedikit tool berarti lebih sedikit peluang merangkainya dengan salah. Deskripsi tool harus menyatakan kapan tool dipanggil, bukan hanya apa fungsinya, karena perbaikan kecil pada redaksi menghasilkan perubahan perilaku yang terukur dan harus diperlakukan sebagai artefak yang bisa dituning dan dievaluasi.

Guardrail apa yang benar-benar efektif di produksi, dan dalam urutan apa sebaiknya diterapkan?

Guardrail efektif membentuk arsitektur berlapis: tingkatan izin yang mewajibkan konfirmasi manusia untuk aksi ireversibel (mengirim email, menghapus data, menyentuh uang), kredensial ter-scope dengan grant minimal, batas anggaran per run untuk panggilan tool dan token, serta logging trace penuh untuk setiap panggilan tool beserta input dan output-nya. Prinsip desain yang mendasarinya adalah mengurutkan setiap aksi berdasarkan reversibilitas — aksi yang bisa dibalik boleh otonom, sementara aksi yang sulit dibalik diberi gerbang eksplisit.

Lapisan evaluasi apa yang harus ada sebelum fitur agent dirilis?

Tiga lapisan direkomendasikan: tes level tool yang memverifikasi model memilih tool yang benar dengan argumen yang tepat untuk state tertentu, eval trajektori yang mencakup 20–50 tugas realistis dinilai ujung ke ujung berdasarkan penyelesaian, jumlah langkah, dan biaya, serta sampling produksi harian dari trace nyata yang ditinjau manusia atau LLM judge. Teknik yang terbukti efektif adalah menggunakan agent itu sendiri untuk menganalisis transkrip gagalnya dan mengusulkan perbaikan deskripsi tool.

Mengapa artikel ini memperlakukan agent produksi sebagai masalah ops, bukan masalah AI?

Proses panjang, multi-langkah, dan non-deterministik membutuhkan primitif operasional yang sama seperti queue worker mana pun: timeout, retry dengan idempotency key, checkpoint agar run bisa dilanjutkan dari tengah urutan, dan penanganan dead-letter untuk tugas yang terus gagal. Di stack yang dipakai di artikel ini, run agent adalah job dalam queue dengan state di PostgreSQL, trace dikirim ke Loki, dan belanja token per run digrafikkan di Grafana — karena model adalah bagian paling tidak terobservasi dari sistem, segala sesuatu di sekitarnya harus paling terobservasi.