ບົດຄວາມ
ເຊົາໂຍນ 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 ແລະ core Schema ເປັນ MUST ເທົ່ານັ້ນ, ສ່ວນຂອບເຂດທີ່ເຫຼືອໃຫ້ຍົກໃຫ້ SHOULD ແລະ MAY; ແລ້ວປ່ອຍໃຫ້ຈຸດທີ່ມີຄວາມສ່ຽງສູງເປັນໜ້າທີ່ຂອງການກວດສອບໂດຍມະນຸດ.
ເປັນຫຍັງຕ້ອງແມ່ນ RFC 2119?#
ເວລາຂຽນ System Prompt, Agent Skill ຫຼື Workflow Rule, ຄຳເວົ້າທີ່ກຳກວມເຊັ່ນ "ກະລຸນາໃສ່ໃຈ", "ທາງທີ່ດີຄວນ", "ພະຍາຍາມເຮັດໃຫ້ໄດ້" ບໍ່ມີພະລັງໃນການບັງຄັບຂອບເຂດສຳລັບໂມເດວເລີຍ. ການປ່ຽນມາໃຊ້ລະດັບຄຳກິລິຍາທີ່ຊັດເຈນ ຈະຊ່ວຍບັງຄັບໃຫ້ຂີດເສັ້ນແບ່ງການຕັດສິນໃຈໄດ້ຢ່າງເດັດຂາດ.
MUST / REQUIRED: ຂໍ້ບັງຄັບເດັດຂາດ, ຫ້າມປະນີປະນອມ#
- ຄວາມໝາຍ: ຫ້າມຂ້າມຢ່າງເດັດຂາດ, ບໍ່ມີຂໍ້ຍົກເວັ້ນໃດໆ.
- ກໍລະນີທີ່ເໝາະສົມ: Data validation, security check, ຂໍ້ກຳນົດ Schema output, ການສະກັດກັ້ນຈຸດສ່ຽງສູງ.
- ຕົວຢ່າງ: "ກ່ອນທີ່ຈະ call ໃບແຈ້ງໜີ້ API,
MUST ກວດສອບກ່ອນວ່າມີລະຫັດພະນັກງານຫຼືບໍ່; ຖ້າຄ່າທີ່ຕອບກັບມາຫວ່າງເປົ່າ, MUST ຢຸດການເຮັດວຽກທັນທີ."
SHOULD / RECOMMENDED: ແນະນຳຢ່າງເຂັ້ມງວດ, ແຕ່ອະນຸຍາດໃຫ້ປັບປ່ຽນໄດ້ຕາມເຫດຜົນ#
- ຄວາມໝາຍ: ຕ້ອງປະຕິບັດຕາມ ຍົກເວັ້ນແຕ່ຈະມີເຫດຜົນດ້ານ Context ທີ່ໜັກແໜ້ນພຽງພໍ; ຖ້າຫາກມີການປ່ຽນແປງ, Agent ຈະຕ້ອງອະທິບາຍເຫດຜົນການ Reasoning ມານຳ.
- ກໍລະນີທີ່ເໝາະສົມ: ການເລືອກ algorithm strategy, ຄວາມມັກໃນການຈັດໝວດໝູ່, retry logic.
- ຕົວຢ່າງ: "ສຳລັບ Ticket ປະເພດສອບຖາມຂອງລູກຄ້າ,
SHOULD ມອບໝາຍໃຫ້ customer support ດ່ານໜ້າກ່ອນເປັນອັນດັບທຳອິດ; ແຕ່ຖ້າກ່ຽວຂ້ອງກັບຂໍ້ຂັດແຍ່ງເລື່ອງທຸລະກຳການເງິນ, ອະນຸຍາດໃຫ້ສົ່ງຕໍ່ໃຫ້ທີມກວດສອບບັນຊີການເງິນໄດ້."
MAY / OPTIONAL: ທາງເລືອກເສີມ, ຕັດສິນໃຈໄດ້ຢ່າງອິດສະຫຼະ#
- ຄວາມໝາຍ: ໂມເດວສາມາດຕັດສິນໃຈເອງໄດ້ວ່າຈະເຮັດຫຼືບໍ່ ໂດຍອີງຕາມ Context resource ຫຼື token budget ໃນຂະນະນັ້ນ.
- ກໍລະນີທີ່ເໝາະສົມ: ຄຳອະທິບາຍເພີ່ມເຕີມ, ຂໍ້ສະເໜີແນະເພື່ອຄິດໄລ່ຕໍ່ຍອດ, ຮູບແບບ log ທີ່ເປັນທາງເລືອກ.
- ຕົວຢ່າງ: "ຕອນສ້າງບົດສະຫຼຸບການດຳເນີນງານ,
MAY ແນບ Ticket ID ຂອງກໍລະນີທີ່ຄ້າຍຄືກັນໃນອະດີດ 1～2 ອັນມາພ້ອມ."
ຫຼັກການ 3 ຂໍ້ໃນການນຳໃຊ້ຕົວຈິງ#
1. ຢ່າຂຽນ MUST ຈົນເຕັມໄປໝົດ, ເປີດພື້ນທີ່ໃຫ້ Reasoning ແດ່#
ການຂຽນທຸກກົດເກນເປັນ MUST ທັງໝົດ ຄືກັນກັບການໃຊ້ LLM ເປັນ Deterministic Compiler, ເຊິ່ງມັກຈະພາໃຫ້ເກີດກົດເກນຂັດແຍ້ງກັນເອງ ຫຼື ເກີດ logic deadlock ຫຼັງຈາກ Context ບວມໃຫຍ່ຂຶ້ນ. ໃຫ້ກຳນົດສະເພາະ "compliance, security, core Schema" ເປັນ MUST ເທົ່ານັ້ນ, ສ່ວນຂອບເຂດອື່ນໆໃຫ້ປ່ອຍໃຫ້ເປັນໜ້າທີ່ຂອງ SHOULD.
2. ໃຊ້ຮ່ວມກັບໂຄງສ້າງ Markdown block#
ແຍກ Prompt ອອກເປັນ 4 block ລຸ່ມນີ້ ເພື່ອໃຫ້ 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 ຈະຊ່ວຍໃຫ້ Agent ຂອງທ່ານປ່ຽນຜ່ານຈາກພຽງແຕ່ Demo ຂອງຫຼິ້ນ ໄປສູ່ລະດັບໃຊ້ງານຈິງແບບ Production-Ready ໄດ້ຢ່າງແທ້ຈິງ.