Agent Skills ที่ดีสร้างยังไง
จากบทความที่แล้วที่แนะนำให้รู้จักกับ Agent Skills กันไปแล้วนั้น ในบทความนี้เราจะพูดถึงแนวทางการสร้างสกิลที่ดีต้องเริ่มจากอะไร ทำยังไงบ้าง
ในการสร้าง Agent Skills หรือชุดแนวปฏิบัติและสกิลสำหรับ AI Agents สิ่งที่ผู้สร้างสกิลมักพลาดบ่อยที่สุดคือการปล่อยให้ LLM เจนสกิลขึ้นมาเองลอย ๆ โดยไม่มีบริบทเฉพาะทาง ผลลัพธ์ที่ได้จึงมีแต่แนวทางกว้าง ๆ แบบครอบจักรวาล (เช่น “จัดการ Error ให้เหมาะสม” หรือ “ปฏิบัติตามมาตรฐาน Security”) ซึ่งไม่ได้ช่วยให้เอไอเข้าใจงานจริงขององค์กรแม้แต่น้อย
การสร้างสกิลที่มีประสิทธิภาพต้อง เริ่มจากประสบการณ์จริง (Real Expertise) และผ่านการ ขัดเกลาด้วยการทดลองรันจริง (Real Execution) เพื่อให้ได้เวิร์กโฟลว์ที่ใช้งานได้จริงในโปรดักชัน
เริ่มต้นจาก "ความรู้และความเชี่ยวชาญจริง"
การดึงเอาบริบทและแนวปฏิบัติเฉพาะทางเข้ามาใส่ในสกิล สามารถทำได้ 2 แนวทางหลัก:
นำมาจากงานจริง (Extract from a Hands-on Task)
ย้อนกลับไปดูบทสนทนาและโจทย์ที่คุณเคยทำงานร่วมกับเอไอเอเจนต์จริง ๆ ดึงเอาส่วนที่ทำงานได้ดีและจุดที่เคยแก้ทางมาปรับเป็นสกิล โดยเน้นเก็บข้อมูลเหล่านี้:
ลำดับขั้นตอนที่ประสบความสำเร็จ: สเต็ปที่รันแล้วผ่านจริง
จุดที่เคยสั่งแก้ (Corrections): คำสั่งที่คุณเคยดักคอไว้ เช่น “อย่าใช้ไลบรารี X ให้ใช้ Y” หรือ “ระวัง เคส Z”
รูปแบบ Input/Output: หน้าตาของ Data ก่อนและหลังประมวลผล
บริบทเฉพาะของโปรเจกต์: กฎเกณฑ์ หรือข้อจำกัดที่เอไอไม่มีทางรู้ได้เองจากภายนอก
สังเคราะห์จากคลังข้อมูลที่มี (Synthesize from Project Artifacts)
แทนที่จะหาบทความกว้าง ๆ ในอินเทอร์เน็ต ให้ป้อนเอกสารภายในของทีมเข้าไปให้เอไอช่วยสังเคราะห์เป็นสกิล เช่น:
เอกสาร Runbooks, Internal Style Guides หรือขั้นตอนการทำงานภายใน
API Specifications, Database Schemas และโครงสร้างไฟล์ Config
ประวัติการ Code Review และประวัติแก้ Bug ใน Git (จุดนี้มักสะท้อนปัญหาสุดฮิตที่เกิดขึ้นบ่อย)
รายงานเหตุการณ์ระบบล่ม (Incident Reports) และวิธีแก้ไข
ปรับแต่งจากการทดลองใช้งานจริง
ร่างแรกของสกิลมักจะไม่สมบูรณ์แบบ ให้นำสกิลนั้นไปทดสอบรันกับโจทย์จริง แล้วนำผลลัพธ์ ทั้งเคสที่สำเร็จและล้มเหลว กลับมาปรับแก้สกิลเสมอ
Tip: ควรอ่าน Execution Traces (เส้นทางการคิดและการเรียกใช้เครื่องมือของเอไอ) ไม่ใช่อ่านแค่ผลลัพธ์สุดท้าย หากพบว่าเอไอเสียเวลาไปกับขั้นตอนที่ไม่จำเป็น สาเหตุหลักมักมาจาก คำสั่งกว้างเกินไป, มีคำสั่งที่ไม่เกี่ยวกับงานนั้นปนอยู่ หรือ มีตัวเลือกมากเกินไปโดยไม่มี Default ที่ชัดเจน
บริหาร Context Window อย่างคุ้มค่า
เมื่อสกิลถูกเปิดใช้งาน (Activation) ไฟล์ SKILL.md จะถูกโหลดเข้าไปใน Context Window ร่วมกับประวัติการคุยและเครื่องมืออื่น ๆ ทุก Token ในสกิลกำลังแย่งชิง Context กับข้อมูลส่วนอื่น
ใส่เฉพาะสิ่งที่เอไอไม่รู้ ตัดสิ่งที่รู้อยู่แล้วออกไม่จำเป็นต้องอธิบายว่า PDF คืออะไร หรือ HTTP ทำงานอย่างไร ให้พุ่งเป้าไปที่ ข้อกำหนดเฉพาะของโปรเจกต์ เท่านั้น
## Extract PDF text
ไฟล์ PDF คือรูปแบบไฟล์ยอดนิยมสำหรับการเก็บข้อความและรูปภาพ ในการอ่านข้อความ
ต้องใช้ไลบรารีภายนอก แนะนำให้ใช้ pdfplumber...
## Extract PDF text
ใช้ pdfplumber สำหรับดึงข้อความ หากเป็นเอกสารสแกน ให้ใช้ pdf2image ร่วมกับ pytesseract
```python
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
วางขอบเขตสกิลให้พอดี (Coherent Units)
การออกแบบสกิลเปรียบเสมือนการเขียนฟังก์ชันที่ดี คือต้องคุมให้กระบวนการทำงานจบในตัวเองและนำไปต่อยอดได้ลงตัว สกิลที่แคบเกินไปจะทำให้ระบบต้องโหลดหลายสกิลพร้อมกันจนคำสั่งตีกันเอง ส่วนสกิลที่ครอบจักรวาลเกินไป (เช่น รวบรวมตั้งแต่การ Query ไปจนถึงการบริหารจัดการ Database) จะทำให้เอไอเลือกเรียกใช้เฉพาะเจาะจงได้ยาก
Progressive Disclosure
เพื่อไม่ให้เปลือง Context Window ควรคุมไฟล์ SKILL.md ให้มีความยาวไม่เกิน 500 บรรทัด (ประมาณ 5,000 Tokens) ซึ่งเป็นส่วนคำสั่งหลักที่จำเป็นต้องใช้อยู่เสมอ หากมีเนื้อหาอ้างอิงหรือคู่มือฉบับเต็ม ให้แยกไปเก็บในโฟลเดอร์ references/ แล้วเขียนเงื่อนไขกำกับไว้ใน SKILL.md เพื่อให้เอไอโหลดเฉพาะเมื่อจำเป็นเท่านั้น เช่น “ให้อ่าน references/api-errors.md เมื่อ API คืนค่า Status Code ที่ไม่ใช่ 200″
ปรับระดับการควบคุมตามความเสี่ยง
งานแต่ละประเภทต้องการความเข้มงวดของคำสั่งไม่เท่ากัน ควรปรับความละเอียดให้เหมาะกับความเปราะบางของงาน:
เน้นยืดหยุ่นเมื่อมีหลายวิธีทำได้: อธิบาย “เหตุผล” ด้านหลังคำสั่ง เพื่อให้เอไอใช้ดุลยพินิจตามบริบทได้เอง เช่น งาน Code Review ที่เน้นบอกจุดที่ต้องระวัง
เน้นคำสั่งตายตัวเมื่อเปราะบางสูง: สั่งการเป็นขั้นตอนที่ห้ามข้ามหรือดัดแปลง เช่น งาน Database Migration
- เลือก Default ให้ชัดเจน: ไม่ควรเสนอตัวเลือกเครื่องมือยาวเหยียดให้เอไอตัดสินใจเองทั้งหมด ให้ระบุตัวเลือกหลักเป็นค่าเริ่มต้น แล้วแจ้งตัวเลือกสำรองไว้สั้นๆ เมื่อเจอเคสพิเศษ
| ประเภทงาน | ระดับความเข้มงวด | แนวทางการสั่งงาน |
| Code Review | ยืดหยุ่น (Flexible) | “ตรวจสอบ Query เพื่อป้องกัน SQL Injection และเช็ก Authentication ในทุก Endpoint” |
| DB Migration | เข้มงวด (Prescriptive) | “รัน python scripts/migrate.py --verify เท่านั้น ห้ามดัดแปลงคำสั่งหรือเพิ่ม Flag เอง” |
Effective Instruction Patterns
ข้อควรระวังเฉพาะทาง (Gotchas): ข้อมูลที่มีมูลค่าสูงสุดในสกิลคือเคสตกหลุมพรางที่เอไอไม่มีทางรู้เองได้หากไม่ระบุไว้ล่วงหน้า เช่น:
ตาราง
usersใช้ระบบ Soft Delete ดังนั้นทุก Query ต้องใส่WHERE deleted_at IS NULLเสมอEndpoint
/healthคืนค่า 200 ตราบใดที่ Web Server ยังทำงาน (แม้ DB จะล่ม) หากต้องการเช็กความพร้อมจริงให้ใช้/ready
Templates: เอไอเรียนรู้จากรูปแบบโครงสร้าง (Pattern Matching) ได้ดีกว่าการอ่านคำบรรยายร้อยแก้ว หากต้องการผลลัพธ์หน้าตาแบบไหน ให้ใส่ Template ตัวอย่างไว้ในสกิลทันที
Plan-Validate-Execute: งานที่มีความเสี่ยงสูงควรบังคับให้เอไอผ่านลูปตรวจสอบ 4 ขั้นตอน:
Plan: สร้างไฟล์แผนงานชั่วคราวขึ้นมาก่อน (เช่น
field_values.json)Validate: รัน Script ตรวจสอบแผนงานกับข้อมูลจริง
Fix: หากพบข้อผิดพลาด ให้ปรับแก้แผนจนกว่าจะผ่านการตรวจสอบ
Execute: ลงมือปฏิบัติงานจริงในขั้นตอนสุดท้าย
Conclusion
สกิลที่ดีไม่ได้เกิดจากการถมข้อมูลเข้าไปให้มากที่สุด แต่เกิดจากการคัดสรรเฉพาะสิ่งที่เอไอไม่รู้ การกำหนดค่าเริ่มต้นที่ชัดเจน และการวางระบบตรวจสอบความถูกต้อง เพื่อให้เอไอทำงานได้อย่างมีทิศทาง ปลอดภัย และประหยัดทรัพยากรมากที่สุด และสำหรับการตรวจสอบจะกล่าวต่อไปในบทความหน้า
