Artikel
Stop Lempar SOP Mentah-Mentah ke AI Agent: Kendalikan Perilaku Agent Secara Presisi dengan RFC 2119 (MUST/SHOULD/MAY)
Kalau SOP manusia langsung dijejalkan ke LLM, Agent sering kali sekali jalan sukses, tapi tiga kali ambyar. Artikel ini menunjukkan cara menulis ulang System Prompt dan Agent Skill memakai MUST, SHOULD, MAY dari RFC 2119 untuk membedakan batasan mutlak, rekomendasi kuat, dan diskresi bebas—lengkap dengan tiga prinsip implementasinya.
· 3 menit baca
Banyak tim yang tersandung di lubang yang sama saat mulai mengimplementasikan Agent: langsung menjejalkan seluruh dokumen "SOP manusia" dari Word/Notion ke LLM, lalu berharap ia bisa menyelesaikannya secara otomatis. Hasilnya sering kali mirip beli lotre: sekali jalan sukses, tiga kali ambyar.
Masalahnya bukan karena modelnya kurang pintar, melainkan karena SOP manusia sarat dengan "Tacit Knowledge" (pengetahuan implisit). Otak manusia secara otomatis paham bahwa "kalau nominalnya di bawah 500, tidak perlu approval", atau "kalau langkah ini error, bisa di-skip dulu". Namun bagi LLM, teks non-terstruktur tidak memiliki batasan hierarki yang tegas—ia hanya bisa berimprovisasi semaunya.
Untuk membuat perilaku Agent menjadi deterministik, langkah pertama bukanlah berganti ke model yang lebih besar, melainkan mengadopsi standar klasik dari spesifikasi protokol jaringan: tingkatan semantik RFC 2119.
Kesimpulan di awal: Hanya tandai kepatuhan (compliance), keamanan (security), dan Schema inti sebagai MUST; serahkan batasan sisanya ke SHOULD dan MAY; lalu alihkan titik-titik berisiko tinggi ke review manual manusia.
Mengapa Harus RFC 2119?#
Saat menulis System Prompt, Agent Skill, atau Workflow Rule, kata-kata ambigu seperti "harap perhatikan", "sebaiknya", atau "sebisa mungkin" sama sekali tidak memiliki daya ikat bagi model. Menggantinya dengan tingkatan kata kerja yang eksplisit akan memaksa batasan pengambilan keputusan ditarik secara tegas.
MUST / REQUIRED: Batasan Mutlak, Nol Kompromi#
- Semantik: Sama sekali tidak boleh dilewati, tidak ada pengecualian.
- Skenario Penggunaan: Validasi data, pemeriksaan keamanan, spesifikasi output Schema, pencegahan risiko tinggi.
- Contoh: "Sebelum memanggil invoice API,
MUST memvalidasi terlebih dahulu apakah ID karyawan valid; jika return-nya kosong, MUST segera menghentikan eksekusi."
SHOULD / RECOMMENDED: Rekomendasi Kuat, tetapi Mengizinkan Deviasi Rasional#
- Semantik: Wajib dipatuhi kecuali ada alasan Context yang sangat kuat; jika menyimpang, Agent harus menjelaskan dasar reasoning di baliknya.
- Skenario Penggunaan: Pemilihan strategi algoritma, preferensi klasifikasi, logika retry.
- Contoh: "Untuk Ticket tipe konsultasi pelanggan,
SHOULD memprioritaskan penugasan ke customer service lini pertama; namun jika terkait sengketa transaksi keuangan, diizinkan untuk dialihkan ke tim audit finansial."
MAY / OPTIONAL: Opsional Bebas, Diskresi Penuh#
- Semantik: Model bebas memutuskan apakah perlu mengeksekusinya berdasarkan sumber daya Context atau alokasi budget token saat ini.
- Skenario Penggunaan: Penjelasan tambahan, saran eksplorasi lanjutan, format logging opsional.
- Contoh: "Saat membuat ringkasan penanganan,
MAY melampirkan 1～2 referensi Ticket ID historis dari kasus serupa."
Tiga Prinsip Implementasi Praktis#
1. Jangan Penuhi Prompt dengan MUST, Beri Ruang untuk Reasoning#
Menulis semua aturan sebagai MUST sama saja dengan memperlakukan LLM seperti Deterministic Compiler. Ini rawan memicu konflik antar-aturan atau logic deadlock akibat Context yang membengkak. Cukup tandai "kepatuhan, keamanan, Schema inti" sebagai MUST, dan serahkan batasan lainnya kepada SHOULD.
2. Kombinasikan dengan Blok Markdown yang Terstruktur#
Pecah Prompt ke dalam empat blok di bawah ini agar cakupan (Scope) intensitas semantiknya terlihat jelas dalam sekali lihat:
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. Kaitkan Titik Berisiko Tinggi dengan Human-in-the-loop#
Ketika kondisi menyentuh batas MUST yang krusial (misalnya transaksi tunggal > $5,000, atau perubahan hak akses Admin), satu-satunya perilaku MUST bagi Agent adalah "pause pipeline, lalu tunggu approval manual dari manusia", bukan malah mengambil keputusan sendiri menggantikan manusia.
Kesimpulan: Dari Mainan Demo Menuju Production-Ready#
Posisikan Agent layaknya lini perakitan industri, bukan "superman serabutan" tunggal yang bisa segalanya. Lewat kontrak perilaku yang dibangun dengan RFC 2119, barulah Agent Anda bisa benar-benar bertransformasi dari sekadar mainan Demo menjadi sistem tingkat produksi yang Production-Ready.