Harness engineering คืออะไร: ทำให้ AI agent เป็นเครื่องมือทำงานจริง

Harness engineering แบบเข้าใจง่าย

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

ประโยคที่สั้นที่สุดที่อธิบายเรื่องนี้คือ:

Agent = Model + Harness

Model คือน้ำหนักของโมเดล และความสามารถในการให้เหตุผล เขียนข้อความหรือโค้ด ส่วน Harness คือทุกอย่างที่เหลือ ได้แก่ คำสั่งระบบและไฟล์อย่าง CLAUDE.md หรือ AGENTS.md ชุดเครื่องมือ (shell การแก้ไขไฟล์ MCP server) sandbox ที่ agent ใช้รันคำสั่ง ไฟล์สถานะที่เก็บข้ามเซสชัน และ tests, linter, hooks ที่บอก agent เมื่อเกิดข้อผิดพลาด ถ้าเอา harness ออกไป สิ่งที่เหลือคือแชตที่ทำได้แค่ตอบเป็นข้อความ

ทำไม agent บางครั้ง «เก่งเหมือนซีเนียร์» บางครั้ง «ฝึกหัด»

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

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

อาการทั่วไปของ harness ที่ไม่ดี

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

Harness ประกอบด้วยอะไร: ห้าระบบย่อย

ความเข้าใจผิดที่พบบ่อยคือคิดว่า harness คือไฟล์ prompt เพียงไฟล์เดียว ในความเป็นจริงมันคือกลไกห้าอย่าง และแต่ละอย่างพังในแบบของตัวเอง

คำสั่ง

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

เครื่องมือ

agent ตรวจสอบได้เฉพาะสิ่งที่มันเข้าถึงได้ ถ้ามันรัน linter ไม่ได้ กฎ «รัน linter ก่อน commit» ก็ไม่มีผล เครื่องมือถูกเชื่อมผ่านความสามารถในตัวของ agent (อ่านและแก้ไขไฟล์ รันคำสั่ง) และผ่าน MCP ซึ่งเป็นโปรโตคอลที่ให้ agent เข้าถึงฐานข้อมูล เบราว์เซอร์ และระบบจัดการงานได้

สภาพแวดล้อม

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

สถานะ

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

วงป้อนกลับ

วงป้อนกลับคือระบบย่อยที่สำคัญที่สุด ถ้าไม่มี agent จะเป็นผู้ตัดสินเพียงคนเดียวของตัวเอง และจะคิดว่างานเสร็จโดยไม่สงสัย เทสต์ การตรวจชนิดข้อมูล linter hook ที่ทำงานหลังแก้ไขทุกครั้ง หรือสคริปต์ E2E ในเบราว์เซอร์ ทั้งหมดนี้ส่งสัญญาณสีแดงกลับไปให้ agent ตั้งแต่ตอนที่การแก้ไขยังไม่แพง

Harness คือวงปิด ไม่ใช่รายการ

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

คำสั่ง → โมเดล → เครื่องมือ → สภาพแวดล้อม → การเปลี่ยนแปลง
                ↑                              ↓
                └──── แดง ── ตรวจสอบ ──────────┘
                                     ↓ เขียว
                                 สถานะ → (เซสชันถัดไป)

ถ้าตัดลูกศรลูกใดลูกหนึ่งออก วงจรจะขาดตรงจุดนั้น ไม่มีการตรวจสอบ agent ก็ไม่รู้ว่าผิด ไม่มีสถานะ เซสชันถัดไปก็ต้องเสียเวลาขุดหาข้อมูลแทนที่จะทำงาน ดังนั้นการลงทุนในระบบย่อยหนึ่งไม่ได้ชดเชยช่องโหว่ของระบบอื่น ไฟล์ AGENTS.md ยาวห้าหน้าไม่สามารถแทนเทสต์ที่ขาดหายไปได้

Harness engineering ต่างจาก prompt engineering และ context engineering อย่างไร

แนวคิดเหล่านี้ซ้อนกันอยู่ ไม่ได้แข่งกัน

Prompt engineering คือส่วนหนึ่งของระบบย่อยคำสั่ง ส่วน context engineering ครอบคลุมทั้งคำสั่งและสถานะ คือ agent เห็นอะไรในแต่ละช่วงเวลา ส่วน harness engineering เพิ่มสิ่งที่ยัดเข้าหน้าต่างบริบทไม่ได้เลย ได้แก่ สิทธิ์การเข้าถึง sandbox เทสต์ hooks และกระบวนการทำงาน prompt ที่เขียนดีแค่ไหนก็ไม่ช่วยอะไร ถ้า agent รันเทสต์ไม่ได้จริง ๆ

ทำไมต้องมี harness: คณิตศาสตร์ของงานที่ยาว

ดูเผิน ๆ โมเดลที่ทำถูกต้อง 95% ของขั้นตอนน่าจะเกือบสมบูรณ์แบบ แต่งานของ agent มีหลายขั้นตอน และข้อผิดพลาดสะสมกันไป ถ้าแต่ละขั้นตอนเป็นอิสระต่อกัน ความน่าจะเป็นที่จะผ่านทุกขั้นโดยไม่ผิดพลาดคือผลคูณของความน่าจะเป็นแต่ละขั้น:

0.95 ^ 10 ≈ 0.60
0.95 ^ 20 ≈ 0.36
0.95 ^ 50 ≈ 0.08

ถึงขั้นที่สิบ มีเพียงประมาณ 60% ของการรันที่ไม่มีข้อผิดพลาดเลย และถึงขั้นที่ห้าสิบ มีน้อยกว่าหนึ่งในสิบ การพัฒนาโมเดลให้ได้ 97% นั้นแพงและไม่อยู่ในมือคุณ แต่การจับข้อผิดพลาดในขั้นตอนที่มันเกิดขึ้น แล้วส่งกลับให้ agent เป็นหน้าที่ของ harness วงป้อนกลับเปลี่ยนห่วงโซ่ที่ «ข้อผิดพลาดลากข้อผิดพลาดตามมา» ให้กลายเป็นชุดขั้นตอนสั้น ๆ ที่แก้ไขได้

ตัวอย่าง: agent ตัวเดียวกันใน repository สองแห่ง

โจทย์: เพิ่มส่วนลดจากโค้ดโปรโมชันในแบ็กเอนด์การชำระเงินที่ใช้ FastAPI

ไม่มี harness

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

มี harness

ที่รากของโปรเจกต์มี AGENTS.md ยาวไม่กี่สิบบรรทัด บอกวิธีตั้งค่าสภาพแวดล้อม คำสั่งตรวจสอบที่บังคับ และตำแหน่งที่อธิบายสถาปัตยกรรมการชำระเงิน สภาพแวดล้อมเปิดด้วยคำสั่ง docker compose up -d ใน repository มีไฟล์แผนงานพร้อมเกณฑ์ความสำเร็จ: «เทสต์ E2E ของการสั่งซื้อด้วยโค้ดโปรโมชันผ่าน» หลังทุกการแก้ไข hook จะรัน linter และการตรวจชนิดข้อมูล และก่อนจบงาน agent ต้องรันเทสต์ E2E

# AGENTS.md (ส่วนหนึ่ง)
## การตรวจสอบ — บังคับก่อนพูดว่า «เสร็จแล้ว»
make lint        # ruff + mypy
make test        # pytest, unit และ integration
make e2e         # สถานการณ์การสั่งซื้อ

## MUST
- เงินคำนวณเป็นสตางค์ (int) ห้ามใช้ float
- คำสั่ง SQL ทุกตัวต้องใช้ parameter
- ห้ามแก้ migration ที่ถูกนำขึ้น production แล้ว

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

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

1. อธิบายว่า agent ตรวจสอบงานของมันอย่างไร: หนึ่งถึงสามคำสั่งที่มันต้องรันเสมอ การป้อนกลับให้ผลมากที่สุด ดังนั้นควรเริ่มจากตรงนี้
2. ทำให้สภาพแวดล้อมทำซ้ำได้: เปิดด้วยคำสั่งเดียว และมีวิธีย้อนกลับได้อย่างรวดเร็ว
3. สร้างไฟล์สถานะ: เป้าหมาย สิ่งที่ทำไปแล้ว การตัดสินใจ ทางตัน และขั้นตอนถัดไป
4. ย่อคำสั่งให้เป็นแผนที่: คำสั่งตรวจสอบ ข้อจำกัดที่ห้ามละเมิด และลิงก์ไปยังเอกสารรายละเอียด
5. บันทึกความล้มเหลวของ agent: ทุกครั้งที่พลาด ให้จดว่าระบบย่อยใดเปิดช่องให้เกิดขึ้น บันทึกนี้จะบอกว่าควรแก้อะไรต่อไป

แนวทางที่ใช้ได้จริงคือให้คะแนนระบบย่อยแต่ละตัวจาก 1 ถึง 5 ใช้เวลาครึ่งชั่วโมงกับตัวที่อ่อนที่สุด แล้วรันชุดงานทั่วไปห้าอย่างเดิมก่อนและหลังการแก้ไข วิธีนี้ทำให้การปรับปรุง harness วัดผลได้ ไม่ต้องอาศัยความรู้สึก

สรุป

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