ข้ามไปยังเนื้อหา
Tayakorn
Harness Engineering Handbook

Harness Engineering Handbook

LEVEL 1 · เสาหลัก

Feedback Loops — ให้ agent ตรวจงานตัวเองได้

คำถามชวนคิด: ทำไม agent เขียนโค้ดถึงไปได้ไกลกว่า agent เขียนบทความ ทั้งที่ภาษาไทย/อังกฤษน่าจะง่ายกว่าภาษาโปรแกรม? · คำตอบไม่เกี่ยวกับความฉลาดเลย: โค้ดมีกรรมการในตัว — compiler บอกทันทีว่า syntax พัง เทสต์บอกทันทีว่า logic เพี้ยน ส่วนบทความไม่มีอะไรบอกว่า "ย่อหน้านี้อ่อน" จนกว่าคนจะอ่าน

นี่คือบทที่เป็นแก่นที่สุดของเล่ม: agent ที่ทำงานยาว ๆ ได้ คือ agent ที่รู้เองว่าผิด

5.1 open loop vs closed loop

ลองคิดเลขง่าย ๆ: สมมติโมเดลพลาดแค่ 5% ต่อขั้น งานที่ต้องทำ 20 ขั้นติดกันแบบไม่มีการตรวจเลย โอกาสรอดทั้งสาย = 0.95²⁰ ≈ 36% — ยิ่งงานยาว ยิ่งเข้าใกล้ศูนย์ · แต่ถ้าทุกขั้นถูกตรวจและแก้ก่อนไปต่อ ความผิดพลาดไม่ทบต้น — งานยาวแค่ไหนก็เดินได้ นี่คือเหตุผลเชิงคณิตศาสตร์ว่าทำไม closed loop เปลี่ยนเกม

OPEN LOOP · ทำเสร็จแล้วส่งเลยขั้น 1ขั้น 2ขั้น 3…✗ ✗✗ ✗ ✗พลาดเล็ก ๆ สะสมเงียบ ๆคนมาเจอบั๊กตอนจบแก้ตอนนี้แพงสุด — ต้องย้อนทั้งสายCLOSED LOOP · ทำ → ตรวจ → แก้ → วนลงมือทำขั้นนั้นตรวจกับ verifierเทสต์ · compiler · lintไม่ผ่าน→ แก้ วนใหม่ผ่าน ✓ส่งงานที่ตรวจแล้วความผิดถูกดักในรอบนั้นทันที — ไม่ทบต้น
FIG 5.1 open loop: ความผิดสะสมจนไปโผล่ตอนจบ · closed loop: verifier ดักไว้ทุกขั้น — งานยาวแค่ไหนก็เดินได้

5.2 "ประสาทสัมผัส" ของ agent

โมเดลมองไม่เห็นโลก — สิ่งที่ทำหน้าที่เป็นตา หู และปลายประสาทของมันคือเครื่องตรวจที่ harness จัดให้:

  • เทสต์ — บอกว่า logic ถูกตามสเปกไหม (แม่นสุดถ้าเทสต์ดี)
  • compiler / type checker — บอกทันทีว่าโค้ดประกอบร่างไม่ติด
  • linter / formatter — บอกว่าผิดกติกาสไตล์ตรงไหน
  • screenshot / preview — งาน UI: ให้ agent เห็นภาพที่ render จริง ไม่ใช่จินตนาการจากโค้ด
  • log / exit code — บอกว่ารันจริงแล้วเกิดอะไรขึ้น

สังเกตว่าทั้งหมดนี้ไม่มีอะไรเป็น AI เลย — เป็นเครื่องมือธรรมดาที่วงการมีอยู่แล้ว · งานของ harness engineer ไม่ใช่ประดิษฐ์ verifier ใหม่ แต่คือต่อสายประสาทพวกนี้เข้า loop ให้ agent เรียกใช้เองได้และเห็นผลเต็ม ๆ

5.3 verifier ที่ดีต้องมีสามคุณสมบัติ

  • เชื่อได้ — false pass (บอกว่าผ่านทั้งที่พัง) อันตรายกว่าไม่มี verifier เพราะ agent จะเดินหน้าอย่างมั่นใจบนของพัง · เทสต์ห่วย ๆ ที่ mock จนไม่เหลืออะไรจริง = ยาพิษ
  • เร็ว — closed loop ได้ผลจากการวนบ่อย ถ้าเทสต์รัน 20 นาที agent จะวนได้แค่ไม่กี่รอบ · เทสต์ย่อยที่รันเป็นวินาทีมีค่ากับ agent มากกว่า suite ใหญ่ที่สมบูรณ์แต่ช้า
  • agent เรียกเองได้ — ต้องอยู่ในรูปคำสั่ง/tool ที่มันกดเองได้ทุกเมื่อ ไม่ใช่รอคนมากดให้ — ไม่งั้นก็กลับไปเป็น open loop ที่มีพิธีกรรมเพิ่ม

5.4 กฎที่พยากรณ์อนาคตได้: งานเดินไกลเท่าที่ verifier พาไป

อยากรู้ว่า agent จะทำงานไหนได้ดี อย่าถามว่าโมเดลฉลาดแค่ไหน — ถามว่างานนั้นมี verifier ดีแค่ไหน:

งานverifieragent ทำงานยาวได้แค่ไหน
แก้บั๊กใน repo ที่มีเทสต์ครบเทสต์ + compiler — แม่น เร็ว เรียกเองได้เป็นชั่วโมงได้สบาย
เขียนฟีเจอร์ใหม่ปานกลาง — ให้เขียนเทสต์ก่อนแล้วค่อยทำ ช่วยได้มากยาวพอควร ถ้าวางเกณฑ์ก่อน
เขียนเอกสาร/แปล/วิเคราะห์อ่อน — ใช้ AI ตรวจ AI ได้แต่เชื่อได้น้อยกว่าเทสต์สั้น — ควรมีคนตรวจเป็นระยะ
งานรสนิยม (ดีไซน์, โทนภาษา)แทบไม่มี — เกณฑ์อยู่ในหัวคนสั้นมาก — คนต้องอยู่ใน loop

บทต่อ ๆ ไปจะเจอ verifier โผล่มาเป็นพระเอกซ้ำ ๆ: เป็นเงื่อนไข "เสร็จจริง" ของบทที่ 8, เป็นหัวใจของ evals บทที่ 11 และเป็นสิ่งแรกที่ต้องออกแบบเมื่อสร้าง harness เองในบทที่ 13

สรุปบทที่ 5 — agent ทำงานยาวได้ = รู้เองว่าผิด · open loop ความผิดทบต้น (0.95²⁰ ≈ 36%) — closed loop ดักทุกขั้น ไม่ทบต้น · ประสาทสัมผัส: เทสต์, compiler, linter, screenshot, log — ของธรรมดาที่ต่อเข้า loop · verifier ที่ดี: เชื่อได้ เร็ว agent เรียกเองได้ · งานไหน verifier ดี งานนั้น agent ไปได้ไกล — กฎนี้พยากรณ์ได้แม่นกว่าถามว่าโมเดลรุ่นไหน

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