บทความ
หยุดโยน SOP ให้ AI Agent ตรง ๆ: ใช้ RFC 2119 (MUST/SHOULD/MAY) ควบคุมพฤติกรรม Agent ให้แม่นยำ
การยัด SOP ของมนุษย์เข้าไปใน LLM ตรง ๆ มักทำให้ Agent ทำงานผ่านรอบเดียว แต่พังไปสามรอบ บทความนี้จะสาธิตการใช้ MUST, SHOULD, MAY ของ RFC 2119 มาเขียน System Prompt และ Agent Skill ใหม่ เพื่อแบ่งขอบเขตระหว่างข้อบังคับเด็ดขาด, ข้อแนะนำอย่างยิ่ง และการตัดสินใจตามดุลยพินิจให้ชัดเจน พร้อม 3 หลักการในการนำไปใช้งานจริง
· อ่าน 1 นาที
หลุมพรางที่ทีมส่วนใหญ่สะดุดบ่อยที่สุดเวลาเอา Agent ไปใช้งานจริง คือการเอา "SOP ของมนุษย์" จาก Word/Notion ทั้งดุ้นไปยัดใส่ LLM แล้วคาดหวังว่ามันจะจัดการให้อัตโนมัติ ผลลัพธ์ที่ได้มักเหมือนซื้อหวย: รันผ่านครั้งเดียว แต่พังไปสามรอบ
ปัญหาไม่ได้อยู่ที่ความสามารถของโมเดลไม่พอ แต่อยู่ที่ SOP ของมนุษย์แฝง "ความรู้ฝังลึก (Tacit Knowledge)" ไว้อย่างมหาศาล สมองมนุษย์จะตัดสินใจได้เองอัตโนมัติว่า "ยอดเงินน้อยกว่า 500 บาทไม่ต้องขออนุมัติ" หรือ "ขั้นตอนนี้ถ้าเจอ error ให้ข้ามไปก่อนได้" แต่สำหรับ LLM แล้ว ข้อความที่ไม่มีโครงสร้างชัดเจนจะไม่มีขอบเขตความหนักเบาของกฎ มันจึงทำได้แค่ด้นสดไปตามเรื่อง
ถ้าอยากให้พฤติกรรมของ Agent มีความแน่นอน (deterministic) ก้าวแรกไม่ใช่การเปลี่ยนไปใช้โมเดลที่ใหญ่ขึ้น แต่เป็นการนำมาตรฐานคลาสสิกของข้อกำหนด network protocol อย่าง ระดับความหมายตาม RFC 2119 เข้ามาใช้
สรุปสั้น ๆ ก่อนเลย: กำหนดเฉพาะเรื่อง Compliance, Security และ Schema หลักให้เป็น MUST ส่วนขอบเขตที่เหลือปล่อยให้เป็น SHOULD และ MAY; แล้วส่งจุดที่มีความเสี่ยงสูงไปให้คนตรวจสอบ
ทำไมต้องเป็น RFC 2119?#
เวลาเขียน System Prompt, Agent Skill หรือ Workflow Rule คำที่คลุมเครืออย่าง "โปรดระวัง", "ควรจะ", "พยายามทำให้ได้" แทบไม่มีผลบังคับขอบเขตอะไรต่อโมเดลเลย การเปลี่ยนมาใช้ระดับของคำกริยาที่ชัดเจน จะช่วยบังคับเส้นแบ่งการตัดสินใจได้อย่างเด็ดขาด
MUST / REQUIRED: ข้อบังคับเด็ดขาด ห้ามประนีประนอม#
- ความหมาย: ห้ามข้ามโดยเด็ดขาด ไม่มีข้อยกเว้น
- เคสที่เหมาะสม: Data validation, การตรวจสอบความปลอดภัย, ข้อกำหนดของ Schema output, การสกัดกั้นเคสความเสี่ยงสูง
- ตัวอย่าง: "ก่อนเรียกใช้ API ใบแจ้งหนี้
MUST ตรวจสอบก่อนว่ารหัสพนักงานมีอยู่จริงหรือไม่ หากค่าที่ได้ว่างเปล่า MUST หยุดการทำงานทันที"
SHOULD / RECOMMENDED: แนะนำอย่างยิ่ง แต่ยอมให้เบี่ยงเบนได้อย่างสมเหตุสมผล#
- ความหมาย: ต้องปฏิบัติตามเสมอ เว้นแต่จะมีเหตุผลทาง Context ที่หนักแน่นเพียงพอ หากเบี่ยงเบนไป Agent จะต้องอธิบายเหตุผลของ Reasoning ประกอบด้วย
- เคสที่เหมาะสม: การเลือกกลยุทธ์อัลกอริทึม, ลำดับความสำคัญในการจัดหมวดหมู่, Retry logic
- ตัวอย่าง: "สำหรับ Ticket ประเภทการสอบถามของลูกค้า
SHOULD กำหนดสิทธิ์ให้ทีม support ด่านแรกก่อนเป็นลำดับแรก แต่หากเกี่ยวข้องกับข้อพิพาททางการเงิน อนุญาตให้ส่งต่อไปยังทีมตรวจสอบบัญชีได้"
MAY / OPTIONAL: ตัวเลือกเสริม ตัดสินใจได้ตามดุลยพินิจ#
- ความหมาย: โมเดลสามารถตัดสินใจเองได้ว่าจะทำหรือไม่ ขึ้นอยู่กับทรัพยากร Context ปัจจุบันหรือ token budget
- เคสที่เหมาะสม: คำอธิบายเพิ่มเติม, คำแนะนำเพื่อคิดต่อยอด, รูปแบบ log เสริม
- ตัวอย่าง: "เมื่อสร้างบทสรุปการดำเนินการ
MAY แนบ Ticket ID ย้อนหลังของเคสที่คล้ายกันจำนวน 1～2 เคสเพื่อใช้อ้างอิงได้"
3 หลักการในการนำไปใช้งานจริง#
1. อย่าใส่แต่ MUST จนเต็มพรืด เว้นที่ว่างให้ Reasoning บ้าง#
การเขียนทุกกฎให้เป็น MUST เหมือนกับการมอง LLM เป็น Deterministic Compiler ซึ่งมักทำให้เกิดปัญหากฎขัดแย้งกันเอง หรือเกิด deadlock ทางตรรกะเมื่อ Context บวม ให้กำหนดเฉพาะ "Compliance, Security, Core Schema" เป็น MUST เท่านั้น ส่วนขอบเขตอื่น ๆ ให้ส่งต่อเป็น SHOULD
2. จัดโครงสร้างควบคู่กับ Markdown Block#
แยก Prompt ออกเป็น 4 บล็อกด้านล่าง เพื่อให้ Scope ของระดับความเข้มงวดชัดเจนในพริบตาเดียว:
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. ผูก Human-in-the-loop เข้ากับจุดที่มีความเสี่ยงสูง#
เมื่อเงื่อนไขแตะขอบเขต MUST ที่สำคัญ (เช่น ยอดต่อรายการ > $5,000, การเปลี่ยนแปลงสิทธิ์ Admin) พฤติกรรมที่เป็น MUST เพียงอย่างเดียวของ Agent คือ "หยุด pipeline ไว้ชั่วคราว แล้วรอคนตรวจสอบมากด OK" ไม่ใช่การตัดสินใจแทนมนุษย์
สรุป: เปลี่ยนจากของเล่นระดับ Demo สู่ Production-Ready#
มอง Agent ให้เป็นสายการผลิตระดับโรงงานอุตสาหกรรม ไม่ใช่ "ยอดมนุษย์เบ๊สารพัดประโยชน์" ที่ทำได้ทุกอย่าง การใช้ RFC 2119 สร้างข้อตกลงเชิงพฤติกรรม (behavior contract) จะช่วยให้ Agent ของคุณเปลี่ยนผ่านจากแค่ของเล่นระดับ Demo ไปสู่ระดับ Production-Ready สำหรับใช้งานจริงได้อย่างแท้จริง