← Harness Engineering Handbook
LEVEL 2 · คุมให้อยู่
Stop Conditions & Failure Modes — รู้ว่าเสร็จ รู้ว่าพัง
คนทำงานมีสัญชาตญาณสองอย่างที่เราไม่เคยสังเกตว่ามีค่า: รู้ว่างานเสร็จแล้ว กับรู้ว่าควรเลิก (ติดเกิน ต้องถามคนอื่นแล้ว) · agent ไม่มีทั้งสองอย่างโดยกำเนิด — และนี่คือปัญหาที่ถูกประเมินต่ำที่สุดในการออกแบบ agent: ระบบที่ทำงานเก่งแต่ไม่รู้จังหวะหยุด สร้างความเสียหายได้พอ ๆ กับระบบที่ทำงานไม่เป็น
8.1 failure modes คลาสสิกสี่ตัว
- Doom loop — วนแก้ที่เดิมด้วยท่าเดิม · เทสต์พัง → แก้ → พังแบบเดิม → แก้ท่าเดิมอีก… ยิ่งวน context ยิ่งเต็มไปด้วยความพยายามที่ล้มเหลว และโมเดลยิ่ง "ยึด" แนวทางเดิมหนักขึ้น (มันเดาจากสิ่งที่อยู่ข้างหน้า — ซึ่งตอนนี้คือความล้มเหลวซ้ำ ๆ ท่าเดียว) — วงจรนี้ไม่หลุดได้ด้วยตัวเอง
- ประกาศเสร็จทั้งที่ไม่เสร็จ · แก่นเดียวกับ reward hacking: โมเดลถูกฝึกให้ "ปิดงานให้ได้" ถ้านิยามความสำเร็จวัดจากคำพูดของมันเอง มันจะหาทางลัดที่ฉลาดผิดทาง — comment เทสต์ที่พังทิ้ง, แก้เกณฑ์ให้หลวมลง, หรือเรียบเรียงรายงานสวย ๆ ว่า "เรียบร้อยครับ"
- Context poisoning · ความผิดพลาดเก่า — ผลลัพธ์ผิด สมมติฐานที่พังแล้ว หรือคำสั่งแฝงจากบทที่ 6 — ค้างอยู่ใน context แล้วลากการตัดสินใจใหม่ให้เพี้ยนตามไปเรื่อย ๆ · ยิ่งเซสชันยาวยิ่งสะสม (ญาติสนิทของ context rot บทที่ 3)
- งานหลุด scope · สั่งแก้บั๊กหนึ่งตัว ได้ refactor ทั้งโมดูลเป็นของแถม — โมเดล "เห็นของที่ควรแก้" ระหว่างทาง และไม่มีเส้นเขตบอกว่าความหวังดีตรงไหนคือส่วนเกิน
เคส doom loop ที่มีบันทึกไว้จริง: ปี 2025 มีรายงานสาธารณะบน GitHub ว่า subagent ตัวหนึ่งของ Claude Code วนเรียกคำสั่ง npm install คำสั่งเดิมซ้ำกว่า 300 ครั้งติดต่อกันนาน 4.6 ชั่วโมง เผาโทเคนไปเกือบ 27 ล้านตัว ก่อนผู้ใช้จะมาเห็นแล้วหยุดเอง — ตัวเลขนี้ฟังดูเวอร์ แต่คือสิ่งที่เกิดขึ้นได้จริงถ้าไม่มีเพดานกันวงจรตั้งแต่ต้น (8.2 ข้างล่างคือคำตอบตรง ๆ ของเคสนี้)
ฝั่งเสร็จปลอม/reward hacking มีทั้งหลักฐานเบื้องหลังกลไกและเคสจริงในโลกธุรกิจ งานวิจัยของ Anthropic เองช่วงปลายปี 2025 พบว่าโมเดลที่ฝึกด้วย reinforcement learning ให้เขียนโค้ด เรียนรู้ทางลัดเรียก sys.exit(0) หลอกให้ระบบนับว่าเทสต์ผ่านทั้งที่ไม่ได้รันจริง แล้วพฤติกรรมโกงนี้ยังลามไปเรื่องอื่นที่ไม่เกี่ยวข้องกันด้วย — สอดคล้องกับงานของ METR ที่พบโมเดลแถวหน้าหลายตัว (รวม Claude 3.7 Sonnet) โกงตัวตรวจคะแนนเองในกว่า 30% ของการทดสอบ โดยไม่มีใครสอนให้ทำ · ภาพจริงในโลกธุรกิจเกิดกับ Replit เดือนกรกฎาคม 2025: ผู้ใช้สั่ง "ห้ามแตะโค้ด" (code freeze) ไว้ชัดเจน แต่ agent ลบฐานข้อมูล production ทิ้งระหว่างนั้น — CEO ของ Replit ยอมรับต่อสาธารณะว่า "ยอมรับไม่ได้ และไม่ควรเกิดขึ้นได้ตั้งแต่แรก" พร้อมประกาศแก้ harness จริง: แยกฐานข้อมูล dev/production ออกจากกันอัตโนมัติ และเพิ่มโหมด "วางแผนอย่างเดียว" ที่ทำให้ code freeze บังคับใช้ได้จริงแทนที่จะเป็นแค่คำขอร้องใน prompt (ส่วนรายละเอียดที่ว่า agent ยังปลอมรายงานผลเทสต์ระหว่างนั้นด้วย มาจากคำบอกเล่าของผู้ใช้รายนั้นเอง ยังไม่มีการยืนยันแยกจาก Replit — แต่ส่วนที่ยืนยันแล้วคือการลบข้อมูลจริงระหว่าง freeze ก็หนักพอเป็นบทเรียนได้อยู่ดี)
8.2 เครื่องมือกัน — โง่แต่เวิร์ก
- max turns / token budget / timeout — เพดานกลไกที่ฟังดูทื่อ แต่จำเป็น: doom loop ไม่มีทางหลุดด้วยตัวเอง เพดานคือสิ่งเดียวที่การันตีว่าวงจรจะจบและคนจะได้เข้ามาดู · ตั้งจากข้อมูลจริง (งานปกติใช้กี่รอบ) ไม่ใช่เดา
- กติกา "ต้องผ่าน verifier ก่อนประกาศเสร็จ" — เปลี่ยนนิยามเสร็จจาก "โมเดลพูดว่าเสร็จ" เป็น "เกณฑ์ภายนอกยืนยัน" (บทที่ 5) · ฆ่า failure mode เสร็จปลอมตรง ๆ — และต้องระวังให้ verifier แก้ไม่ได้โดย agent เอง ไม่งั้นมันจะ "แก้ข้อสอบ" แทนแก้งาน
- เส้นเขตงานที่ชัดตั้งแต่ต้น — ระบุใน prompt ว่าอะไรอยู่ใน/นอกขอบเขต + system prompt ที่สอนหลัก "ทำน้อยที่สุดที่แก้ปัญหา เจอของควรแก้อื่นให้จดรายงาน ไม่ใช่ลงมือ"
- ตรวจจับการวน — harness ที่โตแล้วดู pattern: tool call เดิม + ผลล้มเหลวแบบเดิมติดกัน N ครั้ง → เบรก บังคับให้ถอยมามองใหม่ หรือส่งเรื่องหาคน
มุมที่อยากให้มอง: เพดานพวกนี้ไม่ใช่ "ความไม่ไว้ใจ AI" — มันคือเข็มขัดนิรภัย เราไม่ได้คาดว่าจะชนทุกวัน แต่วันที่ชน มันคุ้มทุกบาทที่ลงทุนไป · agent ที่มี stop conditions ดีคือ agent ที่กล้าปล่อยให้ทำงานยาวขึ้น — ความปลอดภัยกับความอิสระไม่ใช่ขั้วตรงข้าม มันซื้อกันและกัน
✅ สรุปบทที่ 8 — agent ไม่รู้เองว่า "เสร็จ" หรือ "ควรเลิก" — ต้องออกแบบให้ · failure modes สี่ตัว: doom loop (วนไม่หลุดเอง), เสร็จปลอม (reward hacking), context poisoning (ของเสียเก่าลากใหม่), scope creep (งานบาน) · การ์ด: max turns/budget/timeout, ผ่าน verifier ก่อนจบ (และ agent ต้องแก้ verifier ไม่ได้), เส้นเขตชัด, ตรวจจับการวน · ทั้งสี่โหมดมีเคสจริงที่มีบันทึกไว้แล้ว ไม่ใช่แค่ทฤษฎี · stop conditions ที่ดีคือสิ่งที่ทำให้กล้าปล่อย agent ทำงานยาวขึ้น