← Harness Engineering Handbook
LEVEL 0 · ปูพื้น
Model vs Harness — ทำไมโมเดลเดียวกันเก่งไม่เท่ากัน
ลองนึกภาพนี้ครับ — พี่แปะ error ลงแชตธรรมดาแล้วถามว่า "ช่วยแก้บั๊กนี้หน่อย" · AI ตอบวิธีแก้มาเป็นฉาก ๆ อ่านดูก็สมเหตุสมผล แต่พอเอาไปใช้จริง: ไฟล์ที่มันอ้างไม่มีอยู่จริง ฟังก์ชันที่มันบอกให้แก้ก็ชื่อไม่ตรง — เพราะมันไม่เคยเห็นโปรเจกต์ของพี่เลย มันเดาจากประสบการณ์ล้วน ๆ
ทีนี้เปิด Claude Code แล้วสั่งประโยคเดียวกัน — มันไล่เปิดไฟล์จริง หาโค้ดที่เกี่ยวจริง ลงมือแก้ รันเทสต์ พอเทสต์พังมันอ่าน error แล้วแก้ต่อ วนจนผ่าน · โมเดลข้างในคือตัวเดียวกันเป๊ะ — แล้วอะไรทำให้ผลงานต่างกันคนละโลก?
คำตอบคือสิ่งที่เล่มนี้ทั้งเล่มว่าด้วย: harness — ระบบรอบตัวโมเดล
1.1 Agent = Model + Harness
คำว่า harness แปลตรงตัวคือ ชุดสายรัด/บังเหียนม้า — ชื่อนี้จงใจ: ตัวม้า (โมเดล) มีแรงมหาศาล แต่ลำพังมันวิ่งสะเปะสะปะ สิ่งที่แปลงแรงม้าให้กลายเป็น "งานที่ควบคุมได้" คือบังเหียนกับสายรัดที่ห่อตัวมันอยู่ · ในโลก AI, harness คือชั้นซอฟต์แวร์ที่ห่อโมเดลไว้ ทำหน้าที่ 5 อย่าง:
- Context — คัดว่าโมเดลจะ "เห็น" อะไรบ้างในแต่ละจังหวะ (บทที่ 3)
- Tools — ให้มือมัน: อ่านไฟล์ รันคำสั่ง ค้นเว็บ ทำอะไรกับโลกภายนอกได้บ้าง (บทที่ 4)
- Feedback — ช่องทางให้มันรู้เองว่างานที่ทำถูกหรือผิด (บทที่ 5)
- Guardrails — กันความเสียหาย: อะไรทำได้เลย อะไรต้องถามคนก่อน (บทที่ 6)
- Observability — ให้คนมองเห็นว่ามันกำลังทำอะไร คิดอะไร เปลืองเท่าไหร่ (บทที่ 7)
ภาพจำง่าย ๆ: วางโมเดลไว้ตรงกลาง — มันทำได้อย่างเดียวคือพ่นข้อความ — แล้วห่อรอบด้วยห้าหน้าที่ข้างบนของ harness ก้อนทั้งหมดที่ห่อเสร็จแล้วคือสิ่งที่ผู้ใช้เห็น เรียกว่า agent · ห้าหน้าที่นี้ต่อเข้ากับวงจรการทำงานจริงตรงไหนบ้าง จะเห็นเป็นแผนที่เต็มในบทถัดไป (FIG 2.2) — รูปนั้นคือรูปที่จะพากลับมาดูซ้ำตลอดเล่ม
ประโยคที่อยากให้จำจากบทนี้: โมเดลคือส่วนที่เราคุมไม่ได้ แต่ harness คือส่วนที่เราออกแบบได้ · โมเดลเก่งขึ้นทุกปีตามจังหวะของ lab ผู้สร้าง — เราทำอะไรกับมันไม่ได้นอกจากรอ แต่ harness อยู่ในมือเราทั้งหมด และมันคือตัวตัดสินว่าความเก่งของโมเดลจะถูกรีดออกมาใช้กับงานจริงได้กี่เปอร์เซ็นต์
1.2 สามยุคของการทำงานกับ AI
ถ้าไล่เส้นทางของ collection นี้ จะเห็นวิวัฒนาการของ "ทักษะฝั่งคน" ชัดมาก:
| ยุค | คำถามหลัก | ตัวอย่างทักษะ |
|---|---|---|
| Prompt engineering (เล่ม #06–#07) | พูดกับโมเดลยังไงให้ได้งาน | few-shot, chain-of-thought, จัดโครง prompt |
| Context engineering | ป้อนข้อมูลอะไร เมื่อไหร่ ให้โมเดลเห็น | grounding/RAG, เลือกเอกสาร, จัดการหน้าต่างความจำ |
| Harness engineering (เล่มนี้) | ออกแบบ "ระบบรอบโมเดล" ยังไงให้ agent ทำงานจริงจบได้เอง | tool design, feedback loops, guardrails, evals |
สังเกตว่าแต่ละยุคไม่ได้แทนที่กัน แต่ซ้อนขยายกันขึ้นมา — ใน harness ที่ดี ยังมี prompt ที่ดีอยู่ข้างใน (system prompt, tool description) และมี context engineering เป็นเสาหลักเสาหนึ่ง (บทที่ 3) · สิ่งที่เปลี่ยนคือหน่วยของการคิด: จาก "ข้อความหนึ่งกล่อง" → "ข้อมูลหนึ่งชุด" → "ระบบทั้งระบบ"
1.3 ทำไมศาสตร์นี้เพิ่งมีชื่อ — และทำไมมันสำคัญตอนนี้
คำว่า harness engineering ตกผลึกเป็นชื่อเรียกช่วงปลายปี 2025 ถึงต้นปี 2026 — จุดที่คนดัง ๆ ในวงการ (เช่น Mitchell Hashimoto ผู้สร้าง Terraform) เริ่มเขียนว่างานหลักของเขาตอนนี้ไม่ใช่การเขียนโค้ดตรง ๆ แต่คือการออกแบบระบบให้ agent เขียนโค้ดได้ดี และทีมผู้สร้างโมเดลเองก็เริ่มมีทีม harness แยกออกมาจริงจัง
หลักฐานที่จับต้องได้สุดมาจาก benchmark อย่าง SWE-bench (ชุดทดสอบให้ AI แก้ issue จริงจาก GitHub): โมเดลตัวเดียวกัน รันผ่าน harness คนละตัว คะแนนต่างกันได้เป็นหลายสิบเปอร์เซ็นต์ — อันดับใน leaderboard ขยับได้โดยไม่ต้องแตะโมเดลเลยสักนิด แค่เปลี่ยนเครื่องมือที่ให้ วิธีป้อน context และวิธีให้มันตรวจงานตัวเอง · นั่นคือวินาทีที่วงการยอมรับกันว่า "ตัวห่อ" ไม่ใช่รายละเอียด แต่เป็นครึ่งหนึ่งของความเก่ง
✅ สรุปบทที่ 1 — Agent = Model + Harness · harness คือชั้นซอฟต์แวร์ห่อโมเดล ทำ 5 หน้าที่: context, tools, feedback, guardrails, observability · โมเดลคือส่วนที่เราคุมไม่ได้ — harness คือส่วนที่เราออกแบบได้ และตัดสินว่าความเก่งถูกรีดออกมากี่ % · prompt → context → harness ไม่ได้แทนที่กัน แต่ขยายหน่วยการคิดจากข้อความเดียวเป็นทั้งระบบ · benchmark ยุคนี้ คะแนนขึ้นกับ harness พอ ๆ กับโมเดล