ဆောင်းပါးများ
SOP တွေကို AI Agent ထဲ တန်းမထည့်ပါနဲ့တော့- Agent ရဲ့ အပြုအမူကို တိတိကျကျ ထိန်းချုပ်ဖို့ RFC 2119 (MUST/SHOULD/MAY) ကို သုံးပါ
လူတွေသုံးတဲ့ SOP ကို LLM ထဲ တိုက်ရိုက်ထည့်ပေးလိုက်ရင် Agent က တစ်ခါလောက် အလုပ်ဖြစ်ပြီး သုံးခါလောက် error တက်လေ့ရှိပါတယ်။ ဒီဆောင်းပါးမှာတော့ System Prompt နဲ့ Agent Skill တွေကို RFC 2119 ရဲ့ MUST၊ SHOULD၊ MAY တွေနဲ့ ဘယ်လိုပြန်ရေးရမလဲဆိုတာကို လက်တွေ့ပြသထားပြီး၊ မဖြစ်မနေလိုက်နာရမယ့် စည်းကမ်း၊ ပြင်းပြင်းထန်ထန် အကြံပြုချက်နဲ့ ကိုယ်ပိုင်ဆုံးဖြတ်ခွင့်တွေကို ရှင်းရှင်းလင်းလင်း ခွဲခြားသတ်မှတ်ပေးမယ့် လက်တွေ့အသုံးချ မူသုံးချက်ကိုပါ ဖော်ပြပေးထားပါတယ်။
· 1 မိနစ် ဖတ်ရန်
အဖွဲ့အစည်းတော်တော်များများ Agent ကို လက်တွေ့အသုံးချဖို့ ကြိုးစားတဲ့အခါ အများဆုံးကြုံရတဲ့ ပြဿနာကတော့ Word/Notion ထဲက "လူသုံး SOP" တစ်ခုလုံးကို LLM ထဲ တိုက်ရိုက်ထည့်ပေးပြီး အကုန်လုံးကို အလိုအလျောက် ဖြေရှင်းပေးနိုင်လိမ့်မယ်လို့ မျှော်လင့်ထားကြတာပါပဲ။ ရလဒ်ကတော့ ထီထိုးရသလိုပါပဲ- တစ်ခါလောက် အဆင်ပြေပေမဲ့ သုံးခါလောက် အလွဲလွဲအချော်ချော် ဖြစ်သွားတတ်ပါတယ်။
ပြဿနာက model ရဲ့ စွမ်းဆောင်ရည် မလုံလောက်လို့ မဟုတ်ပါဘူး၊ လူသုံး SOP တွေမှာ မဖော်ပြထားတဲ့ "အတွင်းသိ အသိပညာ (Tacit Knowledge)" တွေ အများကြီးပါနေလို့ပါ။ လူ့ဦးနှောက်က "ပမာဏ 500 အောက်ဆိုရင် approve ယူစရာမလိုဘူး"၊ "ဒီအဆင့်မှာ error တက်ရင် ခဏကျော်သွားလို့ရတယ်" ဆိုတာကို အလိုအလျောက် သဘောပေါက်နားလည်နိုင်ပါတယ်။ ဒါပေမဲ့ LLM အတွက်တော့ unstructured စာသားတွေမှာ အနိမ့်အမြင့် အလေးအနက် ဘောင်မရှိတဲ့အတွက် သူစိတ်ကြိုက် ထင်ရာလုပ်ပါတော့တယ်။
Agent ရဲ့ လုပ်ဆောင်ချက်တွေကို တိကျသေချာမှုရှိစေဖို့ ပထမဆုံးခြေလှမ်းက ပိုကြီးတဲ့ model တွေ ပြောင်းသုံးဖို့ မဟုတ်ဘဲ၊ network protocol specifications တွေရဲ့ ဂန္ထဝင်စံနှုန်းဖြစ်တဲ့ RFC 2119 semantics အဆင့်ခွဲခြားမှု ကို စတင်အသုံးပြုဖို့ ဖြစ်ပါတယ်။
အနှစ်ချုပ်ကို အရင်ပြောရရင်- compliance၊ security နဲ့ core Schema တွေကိုပဲ MUST အဖြစ် သတ်မှတ်ပါ၊ ကျန်တဲ့ဘောင်တွေကိုတော့ SHOULD နဲ့ MAY ကို လွှဲပေးထားပြီး high-risk ဖြစ်တဲ့ အဆင့်တွေကိုတော့ လူကစစ်ဆေးတဲ့ပုံစံ (human review) လုပ်ခိုင်းပါ။
ဘာကြောင့် RFC 2119 ဖြစ်ရတာလဲ?#
System Prompt၊ Agent Skill ဒါမှမဟုတ် Workflow Rule တွေကို ရေးတဲ့အခါ ဝေဝါးနေတဲ့ "သတိပြုပါ"၊ "လုပ်နိုင်ရင် အကောင်းဆုံးဖြစ်မယ်"၊ "အတတ်နိုင်ဆုံး ကြိုးစားပါ" စတဲ့ စကားလုံးတွေဟာ model အတွက် ဘာဘောင်စည်းကမ်းမှ မရှိစေပါဘူး။ တိကျသတ်မှတ်ထားတဲ့ ကြိယာအဆင့်ဆင့်ကို ပြောင်းလဲအသုံးပြုခြင်းအားဖြင့် ဆုံးဖြတ်ချက်ချရမယ့် စည်းမျဉ်းစည်းကမ်းတွေကို ရှင်းရှင်းလင်းလင်း အတင်းအကျပ် သတ်မှတ်ပေးနိုင်ပါတယ်။
MUST / REQUIRED: လုံးဝအလျှော့မပေးရမယ့် စည်းကမ်းချက်#
- အဓိပ္ပာယ်သတ်မှတ်ချက်- လုံးဝကျော်သွားလို့ မရပါ၊ ခြွင်းချက်မရှိ လိုက်နာရပါမည်။
- အသုံးပြုရမည့် အခြေအနေများ- Data validation၊ security checks၊ Schema output စံနှုန်းများ၊ high-risk လုပ်ဆောင်ချက်များကို ကြားဖြတ်တားဆီးခြင်း။
- ဥပမာ- "Invoice API ကို မခေါ်ယူမီ ဝန်ထမ်းနံပါတ် ရှိ၊ မရှိ
MUST စစ်ဆေးရမည်။ အကယ်၍ empty ပြန်လာပါက execution ကို ချက်ချင်း MUST ရပ်တန့်ရမည်။"
SHOULD / RECOMMENDED: ပြင်းပြင်းထန်ထန် အကြံပြုထားသော်လည်း ခိုင်လုံသောအကြောင်းပြချက်ဖြင့် သွေဖည်ခွင့်ရှိသည်#
- အဓိပ္ပာယ်သတ်မှတ်ချက်- အလွန်ခိုင်လုံသော Context အကြောင်းပြချက် မရှိပါက မဖြစ်မနေ လိုက်နာရပါမည်။ သတ်မှတ်ချက်မှ သွေဖည်ပါက Agent သည် Reasoning အခြေခံကို ရှင်းပြပေးရပါမည်။
- အသုံးပြုရမည့် အခြေအနေများ- Algorithm ဗျူဟာ ရွေးချယ်မှု၊ အမျိုးအစားခွဲခြားခြင်း ဦးစားပေးမှုများ၊ retry logic များ။
- ဥပမာ- "Customer စုံစမ်းမေးမြန်းမှု Ticket များအတွက် first-line customer service သို့
SHOULD ဦးစားပေး assign လုပ်ရမည်။ သို့သော် ငွေကြေးဆိုင်ရာ အငြင်းပွားမှု ပါဝင်ပါက finance audit team သို့ ပြောင်းလဲ assign လုပ်ခွင့်ရှိသည်။"
MAY / OPTIONAL: မိမိစိတ်ကြိုက် ရွေးချယ်ခွင့်၊ အပြည့်အဝ ဆုံးဖြတ်ခွင့်#
- အဓိပ္ပာယ်သတ်မှတ်ချက်- Model သည် လက်ရှိ context အရင်းအမြစ်များ သို့မဟုတ် token budget အပေါ် မူတည်ပြီး လုပ်ဆောင်ခြင်း ရှိ၊ မရှိကို ကိုယ်တိုင် ဆုံးဖြတ်နိုင်သည်။
- အသုံးပြုရမည့် အခြေအနေများ- ဖြည့်စွက်ရှင်းပြချက်များ၊ ထပ်ဆင့်စဉ်းစားရန် အကြံပြုချက်များ၊ optional ဖြစ်သော log format များ။
- ဥပမာ- "အကျဉ်းချုပ် ထုတ်ပေးသည့်အခါ အလားတူဖြစ်ရပ်များ၏ သမိုင်းဝင် reference Ticket ID 1～2 ခုကို
MAY ထည့်သွင်းဖော်ပြနိုင်သည်။"
လက်တွေ့အသုံးချ မူသုံးချက်#
1. နေရာတိုင်း MUST တွေချည်း မသုံးဘဲ Reasoning အတွက် နေရာချန်ထားပါ#
စည်းမျဉ်းအားလုံးကို MUST အဖြစ် သတ်မှတ်လိုက်ခြင်းသည် LLM ကို Deterministic Compiler အဖြစ် အသုံးပြုသကဲ့သို့ ဖြစ်သွားစေပြီး၊ စည်းမျဉ်းများ အချင်းချင်း ပဋိပက္ခဖြစ်ခြင်း သို့မဟုတ် Context ဖောင်းပွလာပြီးနောက်ပိုင်း logic deadlocks များ ဖြစ်ပေါ်လာစေနိုင်ပါသည်။ "Compliance၊ security၊ core Schema" များကိုသာ MUST အဖြစ် သတ်မှတ်ပြီး ကျန်နယ်နိမိတ်များကို SHOULD သို့ လွှဲပြောင်းပေးပါ။
2. စနစ်ကျသော Markdown Block များဖြင့် တွဲဖက်အသုံးပြုပါ#
Semantic strength ၏ အတိုင်းအတာ (Scope) ကို တစ်ချက်ကြည့်ရုံဖြင့် ရှင်းရှင်းလင်းလင်း သိနိုင်စေရန်အတွက် Prompt ကို အောက်ပါ block လေးခုအဖြစ် ခွဲထုတ်ပါ-
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. High-Risk လုပ်ဆောင်ချက်များတွင် Human-in-the-loop ကို ချိတ်ဆက်ပါ#
အရေးကြီးသော MUST ဘောင်တစ်ခုခုနှင့် ငြိစွန်းလာသောအခါ (ဥပမာ- ငွေပမာဏ တစ်ကြိမ်တည်း > $5,000 ဖြစ်ခြင်း၊ Admin permission ပြောင်းလဲခြင်း) Agent ၏ တစ်ခုတည်းသော MUST လုပ်ဆောင်ချက်မှာ "Pipeline ကို ခေတ္တရပ်တန့်ပြီး လူကိုယ်တိုင် စစ်ဆေးအတည်ပြုရန် OK ကို စောင့်ဆိုင်းခြင်း" သာ ဖြစ်သင့်ပြီး လူသားနေရာတွင် ဝင်ရောက်ဆုံးဖြတ်ပေးခြင်း မဖြစ်စေရပါ။
နိဂုံး- Demo ကစားစရာအဆင့်မှသည် Production-Ready အဆင့်သို့#
Agent ကို အစစအရာရာ အကုန်လုပ်နိုင်တဲ့ "တစ်ဦးတည်း အစုံရ စူပါမန်း" လို သဘောမထားဘဲ စက်မှုလုပ်ငန်းသုံး production line တစ်ခုလို သဘောထားပါ။ RFC 2119 ကတစ်ဆင့် အပြုအမူဆိုင်ရာ contract တစ်ခုကို တည်ဆောက်မှသာ သင့်ရဲ့ Agent ဟာ Demo ကစားစရာအဆင့်ကနေ စစ်မှန်တဲ့ enterprise-grade Production-Ready အဆင့်ကို ရောက်ရှိနိုင်မှာ ဖြစ်ပါတယ်။