โพสต์แรก ของซีรีส์นี้บอกว่า Harness สำคัญกว่า Model โพสต์ที่สอง พาไปสำรวจเครื่องมือทั้งหมด ส่วนโพสต์นี้คือภาคลงมือทำ: มี Harness แล้ว จะทำให้มันนิ่งได้ยังไง
คำตอบมีชื่อเรียกตั้งแต่เดือนมิถุนายน 2026 — Loop Engineering — มาจากไอเดียเดียวที่เปลี่ยนวิธีคุยเรื่องการทำงานกับ AI ไปเลย: เลิกพิมพ์ Prompt ป้อน Agent เองทีละงาน แล้วหันมาออกแบบ Loop ที่ป้อน Prompt ให้มันแทน คุณไม่ได้เขียนคำสั่งเองอีกต่อไป คุณกำลังสร้างเครื่องจักรที่เขียนคำสั่งแทนคุณ นี่คือส่วนประกอบของเครื่องจักรนั้น
Instruction Files: Checklist ไม่ใช่คู่มือ
Harness ทุกตัวที่จริงจังจะอ่านไฟล์ Instruction ของโปรเจกต์ทุก Session — CLAUDE.md, AGENTS.md หรือไฟล์แบบเดียวกัน นี่คือจุดที่คุณคุมได้และส่งผลมากที่สุด แต่เกือบทุกคนพลาดแบบเดียวกัน — เขียนมันยาวเป็นนิยาย
ทีมที่ทำให้ระบบนิ่งจริง มองไฟล์นี้เหมือน Checklist ก่อนบินของนักบิน มีกฎ 2 ข้อ:
- สั้นเข้าไว้ — ไม่เกินประมาณ 60 บรรทัด ทุกบรรทัดแย่งความสนใจของ Model กันเอง ไฟล์ที่ยาวเกินไปจะเจือจางกฎที่สำคัญจริงๆ
- ทุกกฎต้องแลกมา อย่าเพิ่มกฎเพราะเดาไปเอง เพิ่มก็ต่อเมื่อมีความผิดพลาดจริงบังคับให้ต้องเพิ่ม
# AGENTS.md
- Run `pnpm test` before calling any change done. No exceptions.
- Never edit files under /generated — they're built, not authored.
- API responses are snake_case; the frontend is camelCase. Map at the boundary.
- If a migration is needed, stop and ask. Never auto-migrate.
ทุกบรรทัดคือแผลเป็นจากความผิดพลาดจริง มาดู Pattern ที่สร้างกฎพวกนี้ขึ้นมากันต่อ
Ratchet: ความผิดพลาดที่กลายเป็นกฎถาวร
Ratchet คือวินัยที่แยก Harness ที่ดีขึ้นเรื่อยๆ ออกจาก Harness ที่พลาดซ้ำเดิมไม่รู้จบ กฎง่ายๆ คือ: มองทุกความผิดพลาดของ Agent เป็นสัญญาณถาวร
สมมติ Agent ลบไฟล์ที่ไม่ควรลบ ท่าแบบมือใหม่คือแก้ปัญหาแล้วเดินหน้าต่อ ท่าแบบ Loop Engineering คือถามว่า ทำยังไงไม่ให้เกิดซ้ำอีก — แล้วเขียนคำตอบนั้นลงไป จะเป็นบรรทัดในไฟล์ Instruction หรือดีกว่านั้นคือทำเป็น Hook ที่บังคับใช้จริงก็ได้ Ratchet หมุนได้ทางเดียว ทุกรอบที่หมุน ช่องว่างของความผิดพลาดที่จะเกิดขึ้นได้ก็เล็กลงเรื่อยๆ
flowchart LR A[Agent makes a mistake] --> B[Fix it] B --> C[Encode a rule<br/>instruction file or hook] C --> D[That class of mistake<br/>can't recur] D --> A
Hooks: กฎที่ Model เลี่ยงไม่ได้
Instruction คือคำแนะนำ — Model เมินคำแนะนำได้ ส่วน Hooks คือการบังคับใช้จริง เป็นโค้ดที่ทำงานแน่นอนตายตัว ทำงาน ณ จุดที่กำหนดไว้ใน Loop ก่อนหรือหลัง Action ใดๆ Model เลี่ยงไม่ได้
Hook แบบ PreToolUse บล็อกคำสั่งอันตรายได้ก่อนที่มันจะรัน ส่วน Hook แบบ PostToolUse รัน Test Suite ให้หลังแก้โค้ดทุกครั้ง แล้วป้อนผลที่พังกลับเข้า Loop ทันที หลักการออกแบบที่ทำให้ต้นทุนถูกคือ: สำเร็จแล้วเงียบ พังแล้วค่อยส่งเสียง Hook ที่ผ่านจะไม่พูดอะไรเลย มีแค่ตอนพังเท่านั้นที่โผล่ขึ้นมา Feedback Loop เลยแทบไม่มีต้นทุนในเคสปกติ แต่จะร้องดังทันทีตอนที่ควรร้อง
# PreToolUse hook — refuse a destructive command
if echo "$COMMAND" | grep -qE 'rm -rf|DROP TABLE|force push'; then
echo "Blocked: destructive command requires human approval." >&2
exit 1
fi
Context Management: ไม่ให้ Agent ลืมเป้าหมาย
งานยาวๆ สร้างข้อความมหาศาล — เนื้อไฟล์ ผลลัพธ์คำสั่ง Log ข้อผิดพลาด ปล่อยไว้เฉยๆ สิ่งพวกนี้จะท่วม Context Window ของ Model จน Agent เริ่มลืมว่าตัวเองกำลังทำอะไรอยู่ มี 3 เทคนิคที่จัดการเรื่องนี้ และ Harness ที่โตแล้วจะทำให้อัตโนมัติ:
- Compaction — พอ Context Window เต็ม สรุปประวัติเก่าทิ้ง เก็บแค่ใจความ ตัด Transcript ทิ้งไป
- Offloading — เก็บ Output ก้อนใหญ่ (เช่น Log 5,000 บรรทัด) ไว้นอก Context แล้วให้ Agent ดึงมาเฉพาะส่วนที่ต้องใช้จริง
- Progressive Disclosure — โชว์ Tool หรือ Skill ให้ Agent เห็นเฉพาะตอนที่มันเกี่ยวข้องจริงๆ แทนที่จะอธิบายทั้ง 50 ตัวตั้งแต่ต้น
สำหรับงานที่ยาวข้ามหลาย Session ทีมต่างๆ จะเพิ่ม Planning Files เข้ามา — แตกเป้าหมายใหญ่เป็น Checklist เรียงลำดับให้ Agent ไล่ทำทีละข้อ แผนงานเลยอยู่บน Disk จริง ไม่ใช่แค่ความจำระยะสั้นที่หายง่าย
Planner กับ Evaluator: อย่าให้ Agent ตรวจการบ้านตัวเอง
อัปเกรดเดียวที่ทำให้ Loop นิ่งขึ้นมากที่สุด กลับเป็นเรื่องที่คนคิดไม่ถึงที่สุดด้วย: แยกตัวที่ลงมือทำ ออกจากตัวที่ตรวจ
Agent เป็นพวกมองโลกในแง่ดีเกินจริง ให้มันเขียนโค้ดเองแล้วตัดสินเองว่าถูกไหม มันจะให้คะแนนตัวเองใจดีทุกครั้ง ให้ Agent อีกตัวหนึ่ง (หรืออย่างน้อยก็อีก Pass ที่ใช้ Prompt คนละแบบ) มารับหน้าที่ตรวจแทน คุณภาพจะกระโดดขึ้นทันที เพราะ Evaluator ไม่มีอีโก้ผูกกับงานที่ทำ Planner เสนอแผน Worker ลงมือทำ Evaluator ตัดสิน — สามบทบาท ไม่ใช่ฮีโร่คนเดียว
รวมทุกอย่างเข้าด้วยกัน
ไม่มี Pattern ไหนในนี้ที่แปลกใหม่เลย แต่รวมกันแล้วคือความต่างระหว่าง Demo กับระบบที่พึ่งพาได้จริง:
- ไฟล์ Instruction สั้นๆ ที่อ่านแล้วเหมือน Checklist
- Ratchet ที่เปลี่ยนทุกความผิดพลาดให้เป็นกฎถาวร
- Hooks ที่บังคับใช้สิ่งที่ Instruction ทำได้แค่แนะนำ
- Context Management ที่ไม่ให้ Agent หลุดประเด็น
- การแยก Planner/Evaluator ที่ไม่ให้ใครตรวจงานตัวเอง
นี่แหละคือ Loop Engineering คุณไม่ได้ไล่ตามหา Model ที่ฉลาดกว่าเดิม — คุณกำลังสร้าง Loop ที่ทำให้ Model ที่มีอยู่แล้วนิ่งขึ้น ตอนนี้มีหมวดหมู่ธุรกิจใหม่ harness-as-a-service กำลังก่อตัวขึ้นมาขายเครื่องจักรสำเร็จรูปแบบนี้โดยเฉพาะ แต่ Pattern พวกนี้เรียนรู้ได้ พอมีติดตัวแล้ว ใช้ได้กับ Harness ตัวไหนก็ได้ที่คุณเลือก
ตอนที่สามของซีรีส์เรื่องยุคของ AI Harness ตอนต่อไป: เจาะลึก Pi — Harness แบบมินิมอลที่เดิมพันว่า Primitives ชนะ Features
