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 พอ ๆ กับโมเดล

อ่านแบบเต็มเล่ม