Harness vs context engineering: ความต่างระหว่าง harness engineering กับ prompt และ context engineering

สรุป: สามระดับของโจทย์เดียวกัน

Prompt engineering ตอบคำถามว่า «จะขออย่างไร» context engineering ตอบว่า «โมเดลต้องรู้อะไรตอนนี้» ส่วน harness engineering ตอบว่า «agent ทำงานในสภาพแวดล้อมแบบใด และรู้ได้อย่างไรว่าตัวเองทำผิด» ทั้งสามไม่ใช่แนวทางที่แข่งกัน แต่เป็นระดับที่ซ้อนกัน พรอมป์ตที่ดีเป็นส่วนหนึ่งของบริบทที่ดี และบริบทที่ออกแบบดีเป็นหนึ่งในระบบย่อยของ harness

ความสับสนเกิดขึ้นเพราะทั้งสามอย่างเปลี่ยนพฤติกรรมของโมเดล แต่คันโยกของแต่ละอย่างต่างกัน ถ้า agent รันเทสต์ไม่ได้ ไม่มีการเขียนพรอมป์ตใดแก้ได้ ถ้า agent ลืมการตัดสินใจเมื่อวาน ปัญหาไม่ได้อยู่ที่ถ้อยคำของคำขอ แต่อยู่ที่ว่าสถานะถูกเก็บไว้ที่ไหน การเข้าใจความต่างระหว่าง harness vs context engineering ช่วยประหยัดเวลาเป็นสัปดาห์ เพราะคุณจะหยุดเขียนคำสั่งใหม่ในจุดที่สภาพแวดล้อมคือสิ่งที่พัง

Prompt engineering: วิธีเขียนคำขอหนึ่งครั้ง

Prompt engineering คืองานกับข้อความของคำขอ ได้แก่ บทบาท โจทย์ รูปแบบคำตอบ ตัวอย่าง (few-shot) ข้อจำกัด และลำดับขั้นตอน หน่วยของงานคือการเรียกโมเดลหนึ่งครั้ง ผลลัพธ์ถูกประเมินจากคำตอบ ว่าถูกต้องหรือไม่ อยู่ในรูปแบบที่ต้องการหรือไม่ และโมเดลไม่หลุดออกนอกประเด็นหรือไม่

เทคนิคที่ใช้บ่อย:

• อธิบายรูปแบบผลลัพธ์อย่างชัดเจน (สคีมา JSON ตาราง รายการ)
• ให้ตัวอย่าง 2–3 ตัวอย่าง «อินพุต → เอาต์พุตที่ถูกต้อง»
• ขอให้ให้เหตุผลทีละขั้นก่อนตอบ
• แยกคำสั่งกับข้อมูลด้วยตัวคั่นที่ชัดเจน
• ระบุสิ่งที่ห้ามทำ

Prompt engineering ได้ผลดีกับงานแบบ «อินพุตหนึ่งอย่าง เอาต์พุตหนึ่งอย่าง» เช่น การจัดหมวดหมู่ การดึงข้อมูล การแปล การสร้างข้อความตามแม่แบบ ขีดจำกัดของมันปรากฏเมื่อโมเดลเริ่มลงมือทำ เช่น เรียกเครื่องมือ แก้ไขไฟล์ ทำงานนับสิบขั้นติดต่อกัน ตรงนั้นคุณภาพไม่ได้ขึ้นอยู่กับประโยคเดียวอีกต่อไป แต่ขึ้นอยู่กับทุกอย่างที่อยู่รอบโมเดล

Context engineering: ข้อมูลอะไรเข้าไปในหน้าต่างของโมเดล

Context engineering คือการจัดการเนื้อหาของหน้าต่างบริบทในแต่ละขั้นตอน หน้าต่างมีจำกัด ขณะที่ agent ในเซสชันยาวสะสมผลลัพธ์ของคำสั่ง เนื้อหาของไฟล์ และประวัติการสนทนา เป้าหมายคือทำให้ในแต่ละช่วงเวลามีสิ่งที่จำเป็นและไม่มีสิ่งที่เกินมา

งานในส่วนนี้ประกอบด้วย:

• การคัดเลือก โหลดไฟล์ เอกสาร และส่วนของโค้ดใดสำหรับงาน (การค้นหา RAG การอ่านตามต้องการ)
• การบีบอัด สรุปประวัติที่ยาว ตัดผลลัพธ์คำสั่งที่ยาวเกินไป ย่อเซสชัน
• โครงสร้าง ไฟล์คำสั่งทำหน้าที่เป็นสารบัญ ส่วนรายละเอียดอยู่ในเอกสารแยกที่ agent เปิดดูเมื่อต้องการ
• การแยกส่วน ส่งงานย่อยให้ subagent ที่มีบริบทของตัวเองและสะอาด เพื่อไม่ให้เธรดหลักปนเปื้อน

ตัวชี้วัดของ context engineering คือ agent หาพบกฎหรือข้อเท็จจริงที่ถูกต้องในเวลาที่เหมาะสมหรือไม่ และไม่จมอยู่กับสัญญาณรบกวนหรือเปล่า อาการที่พบบ่อยของปัญหานี้คือกฎถูกเขียนไว้ใน CLAUDE.md แต่ agent ยังฝ่าฝืนอยู่ เพราะไฟล์ยาวห้าหน้า และกฎนั้นหายไปท่ามกลางน้ำเสียงและรูปแบบที่หัวหน้าทีมชอบ

Harness engineering: ทุกอย่างรอบโมเดล

Harness («สายรัด») คือสภาพแวดล้อมที่ agent ทำงาน ในนั้นโมเดลเป็นเพียงองค์ประกอบหนึ่งที่เข้าสู่วงจรเพียงครั้งเดียว ทุกอย่างอื่น ได้แก่ คำสั่ง เครื่องมือ สภาพแวดล้อม สถานะ และวงป้อนกลับ เป็นสิ่งที่วิศวกรออกแบบ Harness engineering รับผิดชอบให้ agent ไม่เพียงเขียนโค้ดได้ แต่รันได้ ตรวจสอบได้ รู้ว่าผิดได้ และทำงานต่อในเซสชันถัดไปจากจุดเดิมได้

สามารถแบ่ง harness ออกเป็นห้าระบบย่อย:

ใน diagram นี้ context engineering อยู่ภายในสองระบบย่อยแรก มันตัดสินว่าคำสั่งและผลลัพธ์ของเครื่องมือเข้าสู่หน้าต่างได้อย่างไร ส่วน harness เพิ่มสิ่งที่ยัดเข้าบริบทไม่ได้: คำสั่งตรวจสอบที่ใช้งานได้จริง สภาพแวดล้อมที่ทำซ้ำได้ ไฟล์สถานะที่คงอยู่ผ่านการรีสตาร์ต

ตารางเปรียบเทียบ

ทำไมพรอมป์ตและบริบทเพียงอย่างเดียวไม่พอ

เรื่องคลาสสิก: ทีมเห็นว่า agent ทำผิดจึงใช้เวลาหนึ่งสัปดาห์เขียน AGENTS.md ยาวห้าหน้า agent ยังไม่รัน linter ก่อน commit สาเหตุไม่ได้อยู่ที่ถ้อยคำ: agent ไม่มี shell ที่มีสิทธิ์ที่จำเป็น และ linter ก็ไม่ได้ติดตั้งในอิมเมจ นี่เป็นปัญหาของเครื่องมือและสภาพแวดล้อม แต่กลับถูกแก้ด้วยคำสั่ง

เรื่องที่สอง: agent แก้บั๊กเดิมซ้ำสามเซสชันติดต่อกันเพราะรีสตาร์ตแล้วจำไม่ได้ว่าลองอะไรไปแล้ว Context engineering ภายในเซสชันช่วยอะไรไม่ได้ เพราะหน้าต่างถูกล้างไปแล้ว ต้องมีระบบย่อยสถานะ คือไฟล์ที่ agent บันทึกความพยายามและการตัดสินใจ พร้อมกฎให้อ่านไฟล์นั้นตอนเริ่มทำงาน

เรื่องที่สามแพงที่สุด: agent เขียนว่า «เสร็จแล้ว» เทสต์ยูนิตเขียวหมด แต่ฟีเจอร์ไม่ทำงาน ไม่มีพรอมป์ตอย่าง «ตรวจสอบให้ดี» และไม่มีเอกสารเพิ่มเติมในบริบทที่จะมอบการตรวจสอบอิสระให้ agent ได้ มีเพียงผลตอบรับจากเครื่องเท่านั้น ได้แก่ เทสต์ปลายทางถึงปลายทาง สคริปต์ยืนยัน หรือผู้ประเมินแยกที่ไม่มีสิทธิ์เข้าถึงเหตุผลของผู้ทำ

ข้อสรุปรวม: พรอมป์ตและบริบทส่งผลต่อสิ่งที่โมเดล คิด ส่วน harness ส่งผลต่อสิ่งที่โมเดล ทำได้ และ รู้อะไร หลังลงมือทำ

ทำไมการเปลี่ยนโมเดลไม่ช่วยแก้ปัญหา

ปฏิกิริยาที่พบบ่อยเมื่อ agent ไม่มั่นคงคือเปลี่ยนไปใช้โมเดลที่แรงกว่า ซึ่งมักไม่ได้แก้อะไร โมเดลเดียวกันใน repository ที่ตั้งค่าดีทำงานเหมือนซีเนียร์ที่มั่นใจ แต่ใน repository ที่ไม่มีคำสั่งตรวจสอบและไม่มีคำอธิบาย stack มันจะสับสน โมเดลที่แรงกว่าไม่สามารถเดาแบบแผนของทีมคุณได้ ไม่ได้รับสิทธิ์เข้าถึงฐานข้อมูลที่ไม่ได้ให้ และไม่รู้ว่า migration พังถ้าไม่มีใครรันมัน

Harness ก็ไม่ล้าสมัยเมื่อมีโมเดลใหม่ คำสั่ง สภาพแวดล้อมที่ทำซ้ำได้ และการตรวจสอบยังจำเป็นสำหรับทุกโมเดล สิ่งที่เปลี่ยนไปคือปริมาณการควบคุมแบบจุกจิกที่ตัดทิ้งได้ โมเดลที่แรงกว่าต้องการเพียงหลักการที่ไม่เปลี่ยน («ข้อมูลถูกตรวจสอบที่ขอบเขตของโดเมน») ไม่ต้องการคำสั่งทีละขั้น

จะรู้ได้อย่างไรว่าควรแก้ชั้นไหน

การวินิจฉัยจากอาการเร็วกว่าการทดลองใด ๆ:

เริ่มสร้าง harness จากตรงไหน

หากสร้างตั้งแต่ต้น ลำดับที่ใช้ได้จริงคือ วงป้อนกลับ → คำสั่ง → สถานะ → สภาพแวดล้อม → เครื่องมือ วงป้อนกลับมาก่อนเพราะถ้าไม่มีมัน จะวัดผลของการเปลี่ยนแปลงอื่นไม่ได้ เมื่อยังไม่มีคำสั่งที่ตอบอย่างซื่อตรงว่า «ทำงานได้หรือไม่» การปรับปรุงคำสั่งทุกครั้งจะถูกประเมินด้วยความรู้สึก

ตัวอย่างจุดเริ่มต้นขั้นต่ำ:

# AGENTS.md (ส่วนหนึ่ง)
## วิธีตรวจสอบ
- make check   # lint, ชนิดข้อมูล, unit tests
- make e2e     # สถานการณ์ปลายทางถึงปลายทาง
ฟีเจอร์จะถือว่าพร้อมเมื่อทั้งสองคำสั่งจบด้วยรหัส 0 เท่านั้น

## กฎ
- MUST: คำสั่ง SQL ทุกตัวต้องใช้ parameter
- MUST: ก่อน commit ให้รัน make check
- รายละเอียดเรื่องการชำระเงิน: docs/payments.md (อ่านเมื่องานเกี่ยวกับการชำระเงิน)

สังเกตบรรทัดสุดท้าย นี่คือ context engineering ภายใน harness ไฟล์หลักคือแผนที่ ไม่ใช่หนังสือเรียน รายละเอียดถูกโหลดตามเงื่อนไข «เมื่อไร»

วิธีวัดผลของแต่ละส่วน

Harness มีตัวชี้วัดที่ prompt ไม่มี คือสัดส่วนของงานที่ agent ประกาศว่าเสร็จแล้ว แต่การตรวจสอบอิสระไม่ยืนยัน เรียกว่า verification gap หยิบงาน 10 ชิ้นติดต่อกัน หลังแต่ละชิ้นบันทึกว่า agent รายงานว่า «เสร็จแล้ว» หรือไม่ และการตรวจสอบผ่านหรือไม่ คุณจะได้ตัวเลขที่ใช้เปรียบเทียบการเปลี่ยนแปลงได้

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

ข้อผิดพลาดที่พบบ่อย

• ถือว่า harness คือไฟล์พรอมป์ต คำสั่งเป็นเพียงหนึ่งในห้าระบบย่อย ชั้นวางตำราอาหารยังไม่ใช่ครัว
• แก้ปัญหาเครื่องมือที่ขาดด้วยข้อความ «รันเทสต์เสมอ» ไร้ประโยชน์ถ้าเทสต์รันไม่ได้ในสภาพแวดล้อมของ agent
• ขยายคำสั่งจนบวม ยิ่งไฟล์หลักยาว ยิ่งมีโอกาสที่กฎสำคัญจะไม่ถูกอ่าน กฎสำคัญควรกลายเป็นการตรวจสอบที่รันได้จริง
• เชื่อรายงานตัวเองของ agent โมเดลที่ประเมินงานของตัวเองมักประเมินเกินจริง ผู้ตรวจต้องเป็นสคริปต์หรือ agent แยกที่มีบริบทสะอาด
• ตั้งค่า harness ครั้งเดียวแล้วทิ้งไว้ มันล้าสมัยเหมือนโค้ด กฎจะห่างจากความเป็นจริงและคำสั่งจะเปลี่ยนไป ต้องทบทวนเป็นประจำ

สรุป

Prompt engineering ปรับปรุงวิธีการเขียนคำขอ context engineering คัดเลือกข้อมูลที่เข้าสู่หน้าต่างของโมเดล ส่วน harness engineering สร้างสภาพแวดล้อมทั้งหมดของ agent รวมถึงเครื่องมือ สภาพแวดล้อม สถานะ และการตรวจสอบ เมื่อ agent ทำงานนานและแก้โค้ดเอง harness กลายเป็นปัจจัยตัดสิน มันเปลี่ยนคำว่า «agent บอกว่าเสร็จแล้ว» ให้เป็น «ระบบตรวจแล้วว่าทำงานได้จริง» ดังนั้นในการถกเถียงเรื่อง harness vs context engineering จึงไม่ใช่ตัวเลือกแบบใดแบบหนึ่ง บริบทเป็นส่วนหนึ่งของ harness และต้องแก้ระบบย่อยที่อาการชี้ไป หัวข้อนี้ถูกอธิบายในทางปฏิบัติในหลักสูตร harness engineering ผ่านโปรเจกต์แบ็กเอนด์การชำระเงินจริง