งานวิจัยผ่า Agent Skills: มันได้ผลเพราะ "ขั้นตอน" ไม่ใช่ "ความรู้" — และพังทันทีที่คลังสกิลโตเกิน 100 ตัว

ตั้งแต่ Agent Skills กลายเป็นวิธีมาตรฐานในการอัปเกรด agent โดยไม่ต้องเทรนโมเดลใหม่ คำถามที่แทบไม่มีใครตอบด้วยข้อมูลคือ “มันได้ผลเพราะอะไรกันแน่” งานวิจัยส่วนใหญ่วัดแค่ว่า success rate ขยับขึ้นหรือไม่ แล้วจบ

เปเปอร์ “Demystifying Agent Skills: Why They Work—Until They Don’t” (arXiv:2608.14036) เข้ามาตอบคำถามนี้แบบมีตัวเลข ทีมผู้เขียน — Zhiyuan Jiang, Fangrui Huang, Hanwen Xing, Xander Wu, Yipeng Gao, Rui Cao, Mengdi Wang, Shilong Liu และ Yijiang Li จาก Princeton, UC San Diego และสถาบันอื่น — ทำการทดลองแบบมีตัวควบคุมข้ามหลาย benchmark หลาย agent harness และหลายโมเดล แล้ว normalize บันทึกการทดลอง 8,135 รอบ พร้อมทำ paired trajectory analysis เชิงคุณภาพควบคู่กันไป

(หมายเหตุความสด: เปเปอร์ขึ้น arXiv เมื่อ 14 ส.ค. 2026 แต่เพิ่งถูกพูดถึงในวงกว้างช่วง 22 ส.ค. เราเขียนถึงในฐานะงานที่พลาดไป ไม่ใช่ของใหม่วันนี้)

ข้อค้นพบหลัก: สกิลคือ “สมอ” ไม่ใช่ “สารานุกรม”

ตัวเลขที่ควรจำไว้ที่สุดคือคู่นี้:

กลไกที่ทำให้สกิลช่วยได้	สัดส่วนของเคส
Procedural anchoring — ยึด trajectory ที่เดิมสะเปะสะปะให้เดินตามขั้นตอนที่นิ่ง	65.7%
Explicit knowledge injection — เติมข้อเท็จจริงที่โมเดลไม่มี	4.5%

นี่คือหลักฐานเชิงปริมาณสำหรับสิ่งที่คนเขียนสกิลจำนวนมากรู้สึกมานาน: สกิลไม่ได้ทำให้โมเดลฉลาดขึ้น มันทำให้โมเดลนิ่งขึ้น เปเปอร์สรุปตรง ๆ ว่าสกิล “stabilize action rather than inject missing facts” — ทำให้การกระทำเสถียร ไม่ใช่ยัดข้อเท็จจริงที่ขาด

สิ่งที่สกิลทำจริง ๆ คือเรียงลำดับให้ว่าต้องตั้งค่าสภาพแวดล้อมยังไง เรียกเครื่องมือตัวไหนก่อนหลัง และตรวจงานตอนจบด้วยอะไร ซึ่งเป็นงานที่โมเดล “รู้” อยู่แล้วแต่มักทำหลุดเมื่อ context ยาวหรือมีทางเลือกเยอะ

เมื่อเทียบกับแนวทาง Workflow Memory ในการเปรียบเทียบแบบจับคู่ สกิลทำได้ดีกว่า 6.06 คะแนน

ทีมยังยุบข้อสังเกตทั้งหมดเป็น taxonomy ที่ใช้งานได้จริง: 3 หมวดใหญ่ กับ 12 โหมดการใช้สกิล โดยเก็บ label ที่ผ่านเกณฑ์ 238 จาก 240 record ที่ทำ open coding

คอขวดตัวจริงไม่ใช่ตัวสกิล แต่คือการหาสกิลให้เจอ

ส่วนที่ผมคิดว่ากระทบการออกแบบระบบมากที่สุดคือข้อนี้ เปเปอร์แยก “retrieval” ออกมาเป็นปัญหาคนละเรื่องกับ “คุณภาพของสกิล” แล้ววัดมันตรง ๆ:

เมื่อคลังสกิลโตจาก 5 ตัว เป็น 100 ตัว ความแม่นของการหยิบไปใช้จริง (actual-use precision) ร่วงจาก 29.6% เหลือ 3.3%

อ่านตัวเลขนี้อีกรอบ — ที่คลัง 100 ตัว สกิลที่ agent หยิบมาใช้จริง ผิดประมาณ 97 ครั้งจาก 100 นี่ไม่ใช่การเสื่อมแบบค่อยเป็นค่อยไป แต่คือการล่มของกลไกค้นหา

มีข้อสังเกตที่ขัดสัญชาตญาณตามมาด้วย: เมื่อใส่ distractor ที่ชวนสับสน เข้าไป ความสามารถในการระบุสกิลที่ถูกต้องแบบ offline แย่ลงจริง แต่ success rate ปลายทางกลับนิ่ง ทีมสรุปว่าการเรียกสกิลให้ตรง ground truth นั้น “neither sufficient nor necessary” — ไม่ใช่เงื่อนไขจำเป็นและไม่ใช่เงื่อนไขเพียงพอ

แปลเป็นภาษาวิศวกร: การวัดว่าระบบ retrieval ของคุณหยิบสกิล “ถูกตัว” ไหม เป็นตัวชี้วัดที่หลอกได้ บางทีสกิลผิดตัวก็พาไปถึงคำตอบได้ และบางทีสกิลถูกตัวก็ไม่ช่วย

แล้วมันพังตอนไหน

เปเปอร์ระบุสามเงื่อนไขที่ทำให้สกิลกลายเป็นภาระแทนที่จะเป็นตัวช่วย:

1. Brittle assumptions — สกิลเขียนโดยสมมติสภาพแวดล้อมหรือเวอร์ชันเครื่องมือแบบตายตัว พอสภาพจริงต่างไปนิดเดียวก็พัง
2. Incompatible contexts — สกิลถูกหยิบมาใช้กับงานที่หน้าตาคล้ายแต่คนละประเภท
3. Insufficient adaptation — agent ทำตามขั้นตอนแบบเครื่องจักรโดยไม่ปรับให้เข้ากับสถานการณ์ตรงหน้า

ในบทสรุปของ the-decoder ที่รายงานงานชิ้นนี้เมื่อ 22 ส.ค. ระบุว่ากรณีการใช้สกิลผิดที่ผิดทางแบบนี้เกิดขึ้นราว 10% ของเคสที่ทดสอบ ซึ่งหมายความว่าในระบบจริง สกิลไม่ได้มีแค่สถานะ “ช่วย” กับ “ไม่ช่วย” แต่มีสถานะที่สาม — “ทำให้แย่ลง” ที่ต้องนับต้นทุนด้วย

มุมมอง AI Curator

ผมคิดว่าเปเปอร์นี้ควรถูกอ่านคู่กับ roadmap ใหม่ของ MCP ที่ออกวันเดียวกัน เพราะทั้งสองชิ้นชนปัญหาเดียวกันจากคนละฝั่ง — ฝั่งหนึ่งบอกว่าเซิร์ฟเวอร์ที่มี tool เป็นร้อยทำให้การเลือกเครื่องมือแย่ลง อีกฝั่งวัดออกมาเป็นตัวเลขว่าคลังสกิล 100 ตัวทำให้ precision เหลือ 3.3% นี่คืออาการเดียวกันของโรคเดียวกัน: การให้ตัวเลือกกับโมเดลมากเกินไป

สิ่งที่ผมอยากให้ทีมไทยเอาไปใช้ทันทีมีสามข้อ

ข้อแรก — หยุดเขียนสกิลเป็นเอกสารความรู้ ผมเห็นทีมจำนวนมากเขียน SKILL.md เป็นบทความอธิบายว่า API ตัวนี้คืออะไร ประวัติเป็นมายังไง ซึ่งตัวเลข 4.5% บอกว่านั่นแทบไม่ช่วยเลย โมเดลรุ่นปัจจุบันรู้เรื่องพวกนี้อยู่แล้ว สิ่งที่มันต้องการคือ ลำดับขั้นที่บอกว่าทำอะไรก่อนหลัง ตรวจอะไรตอนจบ และห้ามทำอะไร — สกิลที่ดีหน้าตาเหมือน checklist ของพยาบาลห้องผ่าตัด ไม่ใช่บทความ Wikipedia

ข้อสอง — จำนวนสกิลคือหนี้ ไม่ใช่ทรัพย์สิน ทีมที่ภูมิใจว่ามีคลังสกิล 80 ตัวอาจกำลังอยู่ในเขตที่ retrieval ล่มไปแล้วโดยไม่รู้ตัว วิธีตรวจง่าย ๆ คือ log ว่าสกิลตัวไหนถูกหยิบใช้จริงในหนึ่งเดือนที่ผ่านมา แล้วเก็บเฉพาะตัวที่ถูกใช้ ที่เหลือย้ายไป repo แยกและโหลดเฉพาะตามโดเมนงาน — วิธีคิดเดียวกับ progressive discovery ที่ MCP กำลังจะทำ

ข้อสาม — เปลี่ยนวิธีวัด ถ้าตัวเลข “หยิบสกิลถูกตัวกี่ %” ไม่สัมพันธ์กับความสำเร็จปลายทาง ก็อย่าเอามันเป็น KPI สิ่งที่ควรวัดคือ task success กับต้นทุนโทเคนต่อ task และควรวัดแบบ A/B ระหว่างเปิดสกิลกับปิดสกิล เพราะข้อค้นพบเรื่อง 10% ที่แย่ลงแปลว่าค่าเฉลี่ยที่ดีขึ้นอาจซ่อนกลุ่มงานที่สกิลกำลังทำร้ายอยู่

และมีข้อสังเกตเชิงระบบนิเวศที่ควรพูด: ตอนนี้กระแส “skill marketplace” กำลังมาแรง ทั้งฝั่ง Claude, ฝั่ง Ollama และผู้เล่นรายอื่น โมเดลธุรกิจของ marketplace คือ ยิ่งมีของเยอะยิ่งดี แต่งานวิจัยชิ้นนี้ชี้ว่าสำหรับผู้ใช้ปลายทาง ยิ่งเยอะยิ่งแย่ ถ้าไม่มีชั้น retrieval ที่ดีพอ ใครก็ตามที่แก้โจทย์ “หาสกิลที่ใช่ให้เจอในคลังหมื่นตัว” ได้จริง จะเป็นคนที่ถือของมีค่ากว่าคนที่มีสกิลเยอะที่สุด — และตอนนี้ยังไม่มีใครแก้ได้

แหล่งข่าว

• Demystifying Agent Skills: Why They Work—Until They Don’t — arXiv:2608.14036, ส่งเมื่อ 14 ส.ค. 2026
• Paper page บน Hugging Face — พร้อมกราฟ retrieval precision
• Study explains why AI agents benefit from ‘skills’ and when they fail — The Decoder, 22 ส.ค. 2026