เวิร์กโฟลว์ของเอเจนต์ตัวแรกของคุณเริ่มต้นด้วยพรอมต์เพียงหนึ่งเดียวและเครื่องมือไม่กี่อย่าง มันตอบคำถาม ตรวจสอบสถานะคำสั่งซื้อ มันใช้งานได้ดี คุณจึงปล่อยมันออกสู่ตลาด

จากนั้นผลิตภัณฑ์ก็เติบโตขึ้น ฝ่ายขายต้องการตัวอัปเดต CRM ที่ซิงค์บันทึกการประชุม ฝ่ายสนับสนุนต้องการเวิร์กโฟลว์การคืนเงินที่ต้องเชื่อมต่อกับระบบภายในถึงสามระบบ ฝ่ายวิศวกรรมเพิ่มการทำงานผ่านเบราว์เซอร์เพื่อกรอกแบบฟอร์มของผู้ขาย แต่ละคำขออาจดูเหมือนเป็นเรื่องเล็กน้อย แต่ละคำขอต่างก็มีไฟล์พรอมต์ของตัวเอง มีเธรด Slack ของตัวเอง และมี "การแก้ไขด่วน" ของตัวเอง หกเดือนต่อมา เอเจนต์ของคุณไม่ได้เป็นระบบเดียวอีกต่อไป แต่มันกลายเป็นกองพรอมต์ที่ถูกคัดลอกมาอย่างกระจัดกระจาย กฎทางธุรกิจที่ซ่อนอยู่ และการตัดสินใจที่เกิดขึ้นในเธรดแชทเก่าๆ ที่ไม่มีใครหาเจอ นี่คือสิ่งที่เรียกว่า prompt sprawl (การแพร่กระจายของพรอมต์) ซึ่งทำให้ผลิตภัณฑ์ AI ของคุณทดสอบยาก ตรวจสอบยาก และไม่สามารถย้อนกลับ (roll back) ได้อย่างมั่นใจ

วิธีแก้ไขคือการใช้ AI agent skill registry

Skill คืออะไรกันแน่

Skill ไม่ใช่แค่พรอมต์ที่บันทึกไว้ในโฟลเดอร์ แต่มันคือแพ็กเกจที่มีการระบุเวอร์ชันและสามารถทดสอบได้ ซึ่งกำหนดว่าเอเจนต์ต้องทำอะไร เรียกใช้เครื่องมือใดได้บ้าง และสิ่งใดที่ห้ามทำโดยเด็ดขาด ให้คิดซะว่ามันคือสัญญา (contract) ระหว่างทีมของคุณกับเครื่องจักร เมื่อเอเจนต์โหลด Skill ขึ้นมาใช้งาน มันควรจะรู้ขอบเขตของตัวเองอย่างชัดเจนและรู้ว่าผลลัพธ์ที่ประสบความสำเร็จนั้นเป็นอย่างไร

หากไม่มีโครงสร้างนี้ พรอมต์ทุกตัวจะกลายเป็นระบบโปรดักชันขนาดจิ๋วที่ไม่ได้ประกาศไว้ มันจะพ่วงเอาสิทธิ์การเข้าถึงที่ซ่อนอยู่ กฎทางธุรกิจที่ฝังอยู่ และผลกระทบด้านค่าใช้จ่ายที่ไม่มีใครติดตาม มันจะเริ่มหลุดออกจากตัวผลิตภัณฑ์จริง เพราะโรดแมปของผลิตภัณฑ์เดินหน้าไปไกลแล้วแต่พรอมต์ยังอยู่ที่เดิม และที่แย่ที่สุดคือมันถูกคัดลอก ใครบางคนอาจจะ fork มันไปใช้เพื่อทำเดโม หรือคัดลอกไปวางใน microservice ใหม่ และตอนนี้คุณก็มี "แหล่งความจริง" (sources of truth) สองแหล่งที่เริ่มแตกต่างกันไปโดยที่คุณไม่รู้ตัว

ทำไมการใช้แค่พรอมต์ถึงไปไม่รอด

พรอมต์ดูเหมือนข้อความ ทีมงานจึงปฏิบัติกับมันเหมือนเป็นแค่การตั้งค่า (configuration) แต่ในความเป็นจริง พรอมต์มีความใกล้เคียงกับ code มากกว่าที่ใครจะยอมรับ พรอมต์ที่ใช้ในระดับโปรดักชันมักจะมีการเข้ารหัสตรรกะเกี่ยวกับการจัดลำดับ การจัดรูปแบบ การจัดการข้อผิดพลาด และการควบคุมการเข้าถึง เมื่อตรรกะเหล่านั้นอยู่ในรูปแบบภาษาธรรมชาติเพียงอย่างเดียว คุณจะเจอกับความคลุมเครือ เอเจนต์มีสิทธิ์อัปเดต CRM จริงๆ หรือพรอมต์แค่แนะนำให้ทำ? หาก billing API ล่ม พรอมต์รู้หรือไม่ว่าต้องจัดการความล้มเหลวอย่างไรให้ปลอดภัย หรือมันจะสร้างข้อความตอบกลับว่าสำเร็จขึ้นมาเอง (hallucinate)?

ค่าใช้จ่ายก็เป็นเพชฌฆาตเงียบอีกอย่างหนึ่ง พรอมต์ที่สั่งให้เอเจนต์ "think step by step and search extensively" สามารถเผาผลาญ token ในทุกๆ การทำงาน เมื่อพรอมต์นั้นถูกคัดลอกไปใช้ในเวิร์กโฟลว์การสนับสนุนที่มีทราฟฟิกสูง ค่าใช้จ่ายในการ inference รายเดือนของคุณจะเพิ่มขึ้นเป็นเท่าตัวโดยไม่มีใครรู้สาเหตุ

การหลุดจากกรอบ (Drift) เกิดขึ้นเมื่อธุรกิจเปลี่ยนไปแต่ข้อความไม่ได้เปลี่ยนตาม นโยบายการคืนเงินของคุณอาจกำหนดว่าต้องได้รับการอนุมัติจากผู้จัดการหากยอดเงินเกินเกณฑ์ที่กำหนด หากกฎนั้นฝังอยู่ในพรอมต์แทนที่จะอยู่ในชั้นของนโยบาย (policy layer) คุณจะต้องไล่หาตามการ deployment ทุกครั้งเพื่อหาสำเนาที่ต้องอัปเดต หากพลาดไปเพียงจุดเดียว คุณอาจมีเอเจนต์ที่จ่ายเงินออกไปทั้งที่ไม่ควรทำ

โครงสร้างของ Production Skill

หากคุณต้องการหลุดพ้นจากความวุ่นวายนี้ ให้ปฏิบัติกับทุก skill เหมือนเป็นซอฟต์แวร์อาร์ทิแฟกต์ (software artifact) หนึ่งชิ้น Production skill ที่มีประโยชน์ต้องมีมากกว่าแค่ข้อความ ซึ่งประกอบด้วย:

  • Name and purpose. ไม่ใช่ "prompt_v3_final" แต่ควรเป็น "process_standard_refund" พร้อมคำอธิบายเป้าหมายทางธุรกิจที่ชัดเจน
  • Input schema and required context. กำหนดฟิลด์ที่ skill ต้องการอย่างชัดเจน เช่น ต้องใช้ user ID, ประวัติการสนทนา หรือ tenant identifier หรือไม่? การใช้ Strong typing ในส่วนนี้จะช่วยป้องกันไม่ให้เอเจนต์คาดเดาเอาเอง
  • Tool permissions and safety limits. ระบุให้ชัดเจนว่า skill สามารถเรียกใช้เครื่องมือใดได้บ้าง กำหนด guardrails สำหรับการลองใหม่ (retries), ขีดจำกัดการใช้จ่าย และ rate caps หาก skill ไม่ควรแตะต้อง user deletion API ให้ระบุไว้ใน code ไม่ใช่แค่ในคำบรรยาย
  • Success criteria and test cases. Skill ไม่ได้ "ทำงานได้" เพียงเพราะมันรันผ่าน แต่ต้องกำหนดว่าผลลัพธ์ต้องประกอบด้วยอะไรบ้าง สำหรับ skill การคืนเงิน ความสำเร็จอาจหมายถึงการมีบันทึกธุรกรรมที่ตรวจสอบแล้ว, การส่งอีเมลยืนยัน และการสร้างบันทึกใน audit log
  • Version history and owner status. ต้องมีผู้ดูแลสิ่งนี้ โดยควรมี changelog ที่อธิบายว่าทำไมถึงมี v2.3 และมีอะไรที่เสียไปใน v2.2

แยกเลเยอร์ของคุณออกจากกัน

ความผิดพลาดที่ใหญ่ที่สุดที่ทีมมักจะทำคือการยัดทุกอย่างลงในพรอมต์เดียว พวกเขาผสมผสานทั้งคำแนะนำที่เป็นมิตร, เอกสารประกอบเครื่องมือ, นโยบายความปลอดภัย และการจัดการข้อผิดพลาดเข้าด้วยกันจนกลายเป็นข้อความพืดใหญ่ ซึ่งมันไม่สามารถบำรุงรักษาได้เลย

แยกมันออกมา:

  • คำแนะนำ (Instructions) คือแนวทางสำหรับ Agent โดยจะอธิบายถึงโทน รูปแบบ และแนวทางทั่วไป
  • กฎการใช้เครื่องมือ (Tool Rules) จะบอก Agent ว่ามีเครื่องมือใดบ้างและแต่ละอย่างทำอะไรได้บ้าง นี่คือการสำรวจ ไม่ใช่การขออนุญาต
  • นโยบาย (Policy) จะถูกบังคับใช้ด้วยโค้ด ไม่ใช่ด้วยความหวัง หากการคืนเงินที่เกิน 500 ดอลลาร์ต้องมีการตรวจสอบซ้ำ นโยบายนั้นต้องอยู่ในฟังก์ชันการตรวจสอบ (validation function) ที่ทำงานก่อนที่จะมีการเรียกใช้เครื่องมือ
  • การประเมินผล (Evals) คือการทดสอบที่พิสูจน์ว่าทักษะยังคงทำงานได้ตามปกติหลังจากการเปลี่ยนแปลงใดๆ

ตัวอย่างเช่น อย่าเขียนว่า "กรุณาอย่าเปิดเผยหมายเลขบัตรเครดิตเต็มของลูกค้า" แต่ควรสร้างตัวจัดรูปแบบข้อมูล (data formatter) ที่ทำการปกปิดหมายเลข PAN ก่อนที่ Agent จะมองเห็น นโยบายควรอยู่ในรูปแบบของโค้ด เพราะโค้ดไม่สามารถถูกโน้มน้าวให้ละทิ้งหน้าที่ได้ด้วยการป้อนข้อมูลที่ชาญฉลาดของผู้ใช้

หยุดชี้ Production ไปที่เวอร์ชัน "Latest"

ไม่มีอะไรจะทำลายเย็นวันศุกร์ได้เท่ากับการอัปเดต Prompt แบบเงียบๆ อีกแล้ว หาก Agent ในระบบ Production ของคุณดึงเวอร์ชัน "latest" ของ Skill มาใช้เสมอ ทุกการ merge เข้าสู่ main ก็คือความเสี่ยงที่จะเกิดเหตุการณ์ขัดข้องในระบบจริง คุณจำเป็นต้องมี Alias เช่น dev, staging และ prod เพื่อเลื่อนระดับเวอร์ชันที่ผ่านการทดสอบแล้วผ่านขั้นตอนเหล่านี้ เมื่อ prod ชี้ไปที่ v2.1.4 คุณจะสามารถเฝ้าดูการทำงาน วัดผลพฤติกรรม และนอนหลับได้อย่างสนิทใจ หากมีอะไรผิดพลาด คุณก็แค่ย้าย Alias กลับไป คุณไม่จำเป็นต้องมานั่ง debug ภาษาธรรมชาติตอนเที่ยงคืนภายใต้ความกดดัน

วินัยนี้ยังบังคับให้ทีมของคุณต้องคำนึงถึงความเข้ากันได้ย้อนหลัง (backwards compatibility) ด้วย เช่น v2.2 สามารถรองรับรูปแบบ input แบบเดียวกับ v2.1 ได้หรือไม่? หากไม่ได้ การเลื่อนระดับจะล้มเหลวในขั้นตอน staging และคุณจะตรวจพบปัญหาก่อนที่ลูกค้าจะเจอ

ความปลอดภัยเริ่มต้นจากภายใน Package

Registry ที่เต็มไปด้วย Prompt ที่ไม่ผ่านการตรวจสอบคือช่องโหว่ที่รอวันเกิดปัญหา คุณต้องสแกน Skill ของคุณเพื่อหาความเสี่ยงแบบเดียวกับที่คุณสแกนในโค้ด

มองหาความลับที่ถูก hardcoded ไว้ หรือ API keys ที่ซ่อนอยู่ใน prompt templates ตรวจสอบ Webhooks ภายนอก หรือคำสั่ง shell ที่อาจขโมยข้อมูลออกไป เฝ้าระวังความพยายามในการข้ามผ่านนโยบายระบบ เช่น Prompt ที่มีข้อความ "ignore previous instructions" หรือการสั่งให้ Agent เปิดเผยการตั้งค่าของตัวเอง สิ่งเหล่านี้ไม่ใช่แค่ทฤษฎี แต่มันคือรูปแบบทั่วไปของการโจมตีแบบ prompt-injection และมันอันตรายเพราะมักจะแฝงมากับข้อความที่ถูกคัดลอกมาโดยไม่มีใครตรวจสอบ

รัน skill packages ของคุณผ่าน static analysis หากไฟล์ skill มี URL ที่ไม่อยู่ใน allowlist ให้สั่ง fail the build หากมีการอ้างอิงถึง tool ที่ไม่อยู่ใน manifest ที่ได้รับอนุมัติ ให้ปฏิเสธการทำงานนั้น

หากคุณทดสอบไม่ได้ คุณก็เชื่อถือมันไม่ได้

Registry ที่ไม่มีการประเมินผล (evaluations) ก็เป็นเพียงโฟลเดอร์เก็บ prompt เท่านั้น แต่ละ skill จำเป็นต้องมีชุดทดสอบที่ครอบคลุมทั้ง happy path, edge cases และ failure modes สำหรับ skill ที่มีความเสี่ยงสูง คุณต้องการมากกว่าแค่ functional tests คุณต้องตรวจสอบขอบเขตของสิทธิ์ (permission boundaries) เพื่อให้แน่ใจว่า Agent ไม่สามารถเห็นข้อมูลของผู้ใช้รายอื่นได้ คุณต้องตรวจสอบพฤติกรรมการปฏิเสธ (refusal behavior) เพื่อยืนยันว่ามันจะตอบปฏิเสธเมื่อนโยบายสั่งระงับการกระทำนั้นๆ และคุณต้องมีการทดสอบความต้านทานต่อ prompt-injection เพื่อยืนยันว่า input ที่เป็นอันตรายจะไม่สามารถข้ามผ่านการป้องกันในระดับโค้ดของคุณได้

ตั้งชื่อการทดสอบของคุณให้ชัดเจน เช่น การทดสอบที่ชื่อว่า "refund_skill_rejects_negative_amount" จะบอกวิศวกรคนถัดไปได้อย่างชัดเจนว่าพฤติกรรมใดที่กำลังได้รับการคุ้มครองอยู่ เมื่อการทดสอบล้มเหลวระหว่างการเลื่อนระดับเวอร์ชัน คุณจะมีหลักฐานที่ชัดเจนว่า build นั้นไม่ปลอดภัย

เป้าหมายที่แท้จริงคือการควบคุม

การนำกลับมาใช้ใหม่ (Reuse) นั้นดี แต่การควบคุม (Control) ต่างหากที่จะทำให้คุณยังคงมีงานทำ Skill registry ช่วยให้ทีมของคุณสามารถยืนยันได้อย่างมั่นใจว่า: นี่คือ workflow ที่ได้รับอนุมัติ นี่คือเวอร์ชันที่รันอยู่ใน production นี่คือเครื่องมือที่มันสามารถใช้ได้ และนี่คือวิธีการ rollback ที่ถูกต้อง

ความชัดเจนนั้นจะเปลี่ยนคุณจากการส่งมอบ demo ที่ดูฉลาด ไปสู่การดำเนินงานด้วยซอฟต์แวร์ที่เชื่อถือได้ Demo อาจทำให้ผู้มีส่วนได้ส่วนเสียประทับใจได้เพียงสิบนาที แต่ซอฟต์แวร์ที่เชื่อถือได้จะทำงานได้ตอนตีสาม จัดการกับ exception ได้อย่างราบรื่น และไม่เปลี่ยนพฤติกรรมเพียงเพราะมีใครบางคน merge a pull request ในบ่ายวันอังคาร

สร้าง registry ของคุณ กำหนดเวอร์ชันให้ skill ของคุณ บังคับใช้นโยบายผ่านโค้ด และทดสอบให้หนักเหมือนว่าตารางการนอนของคุณขึ้นอยู่กับมัน แล้วตัวคุณในอนาคตจะขอบคุณตัวเอง