บทที่ 12 · เชื่อมกับโลก · Skills & a Lean Tool Surface
Skills & พื้นผิว Tool ที่เบา
ผู้ช่วยเริ่มทำงานซ้ำ ๆ ที่มีขั้นตอนยุ่บยั่บ (เช่น “บรีฟงานแล็บประจำเช้า”) และต้องรับมือ tool จำนวนมากขึ้น
บทนี้สองเรื่องคู่กัน: Skills — แพ็ก “วิธีทำ” เป็นก้อนพกพาได้ และ
การคุมพื้นผิว tool — กัน definitions และผลลัพธ์ออกจาก context เมื่อจำนวน tool โตขึ้น
พูดแบบเข้าใจง่าย
Skill คือโฟลเดอร์ที่มีไฟล์ SKILL.md — มีแค่ name + description กับเนื้อหาขั้นตอน และสคริปต์แนบ
โหลดแบบ progressive disclosure 3 ขั้น: ตอนว่างมีแค่ชื่อ+คำอธิบาย (ไม่กี่ร้อย token) →
โหลด body เมื่อ งานตรงกับมัน → สคริปต์แนบถูก “รัน” ไม่ใช่อ่านเข้า context
ภาพที่แยก Skill ออกจาก MCP tool: MCP ยื่น “ค้อน” (สิทธิ์เข้าถึงการกระทำ) ส่วน Skill สอน “วิธีตอกตะปู” (ลำดับขั้นที่ถูกต้อง)
และเพราะมันเป็นโฟลเดอร์ในตัว มันจึง พกพาได้ — ก๊อปไปโปรเจกต์อื่นได้เลย
ส่วน พื้นผิว tool ที่เบา: ทุก tool ที่เปิดไว้จะส่ง คำนิยามเต็ม (ชื่อ+คำอธิบาย+schema) เข้า context
ทุกเทิร์น ก่อนอ่านคำถามด้วยซ้ำ — ราว ~1K token ต่อตัว และ ผลลัพธ์ ที่เทอะทะก็ค้างในบทสนทนาแล้วถูกส่งซ้ำไปเรื่อย ๆ
ทางแก้ไม่ใช่ “ตัดฟีเจอร์” แต่คือ (1) ส่งแค่ชื่อ ดึง schema ตอนต้องใช้ และ (2) ให้โค้ดกรองผลใน sandbox ก่อน
(มีเคสจริงลดจาก ~150K เหลือ ~2K token)
ตัวเลขหลักของระบบเรา: เปิดใช้งาน 56 จาก 96 tool (ตรวจจากแค็ตตาล็อกจริง 2026-05-29)
ทุกเทิร์น คำนิยามของ 56 ตัวถูกส่งเข้า context ก่อนเริ่มงาน — นี่คือ “ภาษีต่อรอบ” ที่จ่ายไม่ว่าจะใช้ tool หรือไม่
(เอกสารสถาปัตยกรรมรุ่นก่อนอ้างเลข “41/85” ซึ่งเป็นการนับคนละระดับ — เลขมาตรฐานที่ยึดคือ 56/96)
เปรียบเทียบ: การ์ดขั้นตอนฉุกเฉินในกระเป๋าเบาะ vs สลักไว้บนแว่นทุกคน
การ์ดในกระเป๋าเบาะ = Skill: เห็นชื่อบนสันการ์ดได้ตลอด (idle) ดึงออกมาอ่านเฉพาะตอนฉุกเฉินจริง (โหลด body)
และหน้ากากออกซิเจนที่มันบอกให้ดึงคืออุปกรณ์ที่ใช้ ไม่ใช่ข้อความให้อ่านซ้ำ (สคริปต์ถูกรัน) · ส่งต่อให้คนเครื่องอื่นได้ (พกพา)
ส่วนการสลักขั้นตอนบนแว่นทุกคน = ฝังไว้ใน system prompt: ทุกคนอ่านทุกวินาทีไม่ว่าจะฉุกเฉินหรือไม่ และเอาออกไม่ได้
ในระบบของเรา — Skill แยก “วิธีทำ” ออกจาก “สิทธิ์เข้าถึง”
idleมีแค่ name+description (~370 tok)
→
triggerงานตรงคำ → โหลด body (ขั้นตอนเต็ม)
→
toolsการเขียนจริงไปผ่าน tool แยก (ค้อน)
→
scriptสคริปต์แนบถูก “รัน” ไม่อ่านเข้า context
ระบบเรามี Skill จัดการหลักสูตร (TQF3) ที่เก็บ ขั้นตอนยุ่บยั่บ ไว้ (เช่น “หมวด 2 ต้องเซฟสองรอบ ไม่งั้น PDF ว่าง”) —
ตอนว่างจ่ายแค่ไม่กี่ร้อย token พอผู้ใช้พิมพ์ตรงคำถึงโหลดเนื้อเต็ม ส่วนการเขียนจริงไปผ่าน tool แยกต่างหาก
ตรงข้ามกับการ ฝังขั้นตอนซ้ำ ๆ ไว้ใน system prompt ซึ่งจ่าย token เต็มทุกเทิร์นแม้ผู้ใช้แค่ทักทาย และ พกไปที่อื่นไม่ได้
เรื่องพื้นผิว tool: สภาพแวดล้อมที่คุณกำลังอ่านคู่มือนี้อยู่ ใช้ deferred discovery — มี tool จำนวนมากที่ส่งมาแค่ “ชื่อ”
แล้วดึง schema เต็มตอนจะใช้จริง ส่วนระบบของเรายัง ส่งคำนิยามครบ 56 ตัวทุกเทิร์น (always-on) — เป็นมิติที่ยังปรับให้เบาได้
ทำพลาด vs ทำถูก
⚠️ แย่ · ฝังขั้นตอนซ้ำใน system prompt
จ่ายภาษีทุกเทิร์น + พกไม่ได้
เอา “วิธีทำ” ที่ใช้ซ้ำ ๆ ไปยัดใน system prompt — มันถูกส่งเข้า context ทุกเทิร์นแม้ไม่เกี่ยว
และก๊อปไปใช้ที่อื่นไม่ได้ ทั้งที่ถ้าเป็น Skill จะจ่ายเกือบศูนย์จนกว่างานจะ trigger
⚠️ แย่ · ท่อง tool ทั้งหมด + ผลดิบท่วม context
ภาษีคงที่ + ผลสะสม
definitions ของ tool ทุกตัวถูกส่งทุกเทิร์น (ภาษีคงที่) และผลลัพธ์เทอะทะก้อนเดียว (เช่น dump ปฏิทินทั้งเดือน)
ค้างในบทสนทนาแล้วถูกส่งซ้ำตลอด (ภาษีสะสม)
✅ ดี · Skill + deferred discovery + กรองใน sandbox
ความสามารถเท่าเดิม ต้นทุนหด
Skill โหลด body เฉพาะตอน trigger; ส่ง “ชื่อ tool” แล้วดึง schema ตอนใช้; ให้โค้ดกรองผลใน sandbox
เหลือแต่คำตอบเข้ามา (150K→2K) — ไม่ได้ลบ tool สักตัว แค่ไม่ให้มัน “อยู่” ใน window
ลองเอง — มิเตอร์ภาษี context
กิจกรรม · เลื่อนสไลเดอร์ + สลับโหมด
Context Tax Meter
เลื่อนจำนวน tool ที่เปิด แล้วดู “ภาษีต่อรอบ” พุ่ง จากนั้นสลับ “ส่งเฉพาะชื่อ” และ “กรองใน sandbox”
แล้วกด “รันงาน” — ดูต้นทุนหดทั้งที่ จำนวน tool ยังเท่าเดิม และเลื่อนสเตจ Skill ดู progressive disclosure
ปรับสไลเดอร์ · สลับโหมด · รันงาน · เลื่อนสเตจ Skill
มองไปข้างหน้า — เข้าสู่ “เรื่องยาก”
เรามาตรฐานการเข้าถึงและทำพื้นผิวให้เบาแล้ว ส่วนที่ 4 คือหัวข้อที่ทำให้ของ “ดี ปลอดภัย และพิสูจน์ได้ว่าถูก”:
context engineering · security · บันไดความซับซ้อน · การประเมินผล
สรุปบทที่ 12
- Skill = วิธีทำที่พกพาได้ โหลดแบบ progressive disclosure (ชื่อ→body→รันสคริปต์) · MCP = สิทธิ์เข้าถึง, Skill = ขั้นตอน
- ทุก tool ที่เปิด = ภาษีต่อรอบ (~1K/ตัว ทุกเทิร์น) · ผลดิบเทอะทะ = ภาษีสะสม
- แก้ด้วย deferred discovery (ส่งชื่อ ดึง schema ตอนใช้) + กรองใน sandbox (150K→2K) ไม่ใช่ตัดฟีเจอร์
- เลขมาตรฐานของระบบเรา: 56/96 เปิดใช้งาน · ยัง always-on (ปรับให้เบาได้)
Harness Scorecard · มิติ: “พื้นผิว tool เบา + แพ็กขั้นตอนเป็น Skill ไหม?”
ระบบเรา: Skill ✅ (เช่น TQF3) · พื้นผิว tool ⚠️ — ยังส่งครบ 56 ตัวทุกเทิร์น (always-on) ปรับให้เบาได้
📋 build-your-harness checklist · บรรทัดที่ 11
“แพ็กขั้นตอนซ้ำ ๆ เป็น Skill (progressive disclosure) + กัน definitions/ผลลัพธ์ออกจาก context”