Model vs harness

ในโปรเจกต์ shop-api คุณขอให้ Claude Code เพิ่มการตรวจสอบข้อมูลก่อนบันทึก order แล้วเจอสองอาการที่ดูคล้ายกัน: - ครั้งหนึ่ง มันเสนอโค้ดที่ใช้ `any` ขัดกับ type ที่ทั้งโปรเจกต์ประกาศไว้ใน `src/domain/` - อีกครั้ง มันแก้ไฟล์ถูก แต่สรุปว่าเสร็จโดยไม่มีหลักฐานว่าเทสต์ผ่าน ทั้งสองครั้งคุณตอบสนองเหมือนกัน: "โมเดลไม่เก่งพอ" แล้วลองสลับไปใช้รุ่นที่ใหม่กว่า — อาการเดิมก็ยังเกิด คำถามของบทนี้จึงไม่ใช่ "โมเดลรุ่นไหนเก่งกว่า" แต่คือ "เมื่อผลลัพธ์ผิด เราจะรู้ได้อย่างไรว่าควรแก้ที่สิ่งที่โมเดลเลือก หรือที่ชั้นซึ่งห่อโมเดลอยู่ทำหรือไม่ทำ" การตอบคำถามนี้ต้องเริ่มจากกลไกของทั้งสองชั้นก่อน แล้วจึงเรียกชื่อมันอย่างแม่นยำ

โมเดลภาษาทำได้อย่างเดียว: รับข้อความที่อยู่ในสายตาของมัน แล้วสร้างข้อความถัดไป มันไม่มีมือไว้แตะไฟล์ ไม่มีความจำที่ติดตัวข้ามการเรียกแต่ละครั้ง และไม่มีอำนาจบังคับกฎใด ๆ ดังนั้นงานสามประเภทนี้จึงเป็นไปไม่ได้เลยในตัวโมเดล และต้องมีชั้นที่ห่อมันไว้ทำแทน: - **ลงมือ** — เปิดไฟล์ แก้ไฟล์ รันคำสั่ง แล้วเก็บผลลัพธ์จริงที่เกิดขึ้น - **ตัดสินว่าอะไรอยู่ในสายตา** — ประกอบ context ที่โมเดลจะเห็นในแต่ละรอบ - **บังคับกฎ** — ตรวจสิทธิ์ก่อนการกระทำ และปฏิเสธเมื่อกฎห้าม ชั้นที่ห่อโมเดลไว้และทำสามอย่างนี้คือ **harness** ส่วนโมเดลคือเครื่องยนต์ให้เหตุผลที่อยู่ข้างใน ชื่อ "Claude Code" หมายถึงทั้งสองชั้นรวมกัน การแยกสองชั้นนี้ไม่ใช่รายละเอียดปลีกย่อย แต่เป็นเหตุผลว่าทำไมงานเดียวกันจึงได้ผลต่างกันในสองวัน: โมเดลตัดสินใจจากสิ่งที่มันเห็นเท่านั้น ถ้า harness ไม่ได้ป้อน pattern ของโปรเจกต์เข้ามา โมเดลก็ไม่มีทางรู้ว่ามันมีอยู่

ทุกครั้งที่โมเดล "ตอบ" ใน Claude Code ข้อความนั้นเดินผ่านสองชั้นเป็นลำดับ: 1. **harness ประกอบ context** — คำสั่งของคุณ + ไฟล์ instruction ของโปรเจกต์ + ประวัติของ session นี้ + ผลลัพธ์จริงจากเครื่องมือรอบก่อน 2. **โมเดลตัดสินใจจากสิ่งที่เห็น** — เลือกว่าจะตอบเป็นข้อความ หรือขอเรียกเครื่องมือหนึ่งอย่าง เช่น อ่านไฟล์ที่มันยังไม่เคยเห็น 3. **harness ตรวจสิทธิ์และลงมือ** — ถ้ากฎอนุญาตก็รันเครื่องมือจริง ถ้ากฎห้ามก็ปฏิเสธแล้วบอกโมเดล 4. **ผลจริงกลับเข้า context** — output ของเครื่องมือกลายเป็นวัตถุดิบของรอบถัดไป ไม่ใช่ความคาดเดาของโมเดล เพราะทุกเทิร์นไหลผ่านลำดับนี้ อาการที่เห็นจึงชี้ได้ว่าปัญหาอยู่ที่ชั้นใด

การแยกชั้นแบบนี้ทำให้สองสิ่งเป็นจริง: - **สลับรุ่นโมเดลได้โดยไม่ต้องเปลี่ยนวิธีทำงาน** — เครื่องมือ การประกอบ context และการบังคับกฎเป็นของ harness จึงเหมือนเดิมเมื่อเปลี่ยนเครื่องยนต์ข้างใน สิ่งที่เปลี่ยนคือคุณภาพของการตัดสินใจ - **การให้เหตุผลยังเป็นงานของโมเดล** — harness จัดหาเครื่องมือ ประกอบ context และบังคับกฎ แต่ไม่ได้ให้เหตุผลแทนโมเดล; การเลือกทางแก้ยังมาจากสิ่งที่โมเดลเห็นและตัดสินใจเอง

ลองเทียบโมเดลตัวเดียวกันตอนอยู่ในหน้าต่างแชท กับตอนอยู่ใน harness ที่ทำงานกับ shop-api ความต่างทั้งหมดอยู่ที่ชั้นที่ห่อมันไว้ ไม่ใช่ที่ตัวโมเดล

• โมเดลตัดสินใจจาก context ที่เห็น; harness ประกอบ context ลงมือ ตรวจสิทธิ์ และป้อนผลจริงกลับ
• การวินิจฉัยเริ่มจากคำถามเดียว: โมเดลเห็นข้อมูลที่จำเป็นครบหรือยัง ถ้ายัง ปัญหาอยู่ที่ harness
• สลับรุ่นโมเดลได้โดยกลไกไม่เปลี่ยน เพราะเครื่องมือ กฎ และ context ไม่ได้อยู่ในตัวโมเดล
• ก้าวต่อไป: บทถัดไปคือ The agentic loop ซึ่งจะพาไปดูว่าสองชั้นนี้ประสานกันเป็นลูป gather → act → verify ที่คุณขัดจังหวะได้อย่างไร