← Harness Engineering Handbook
LEVEL 1 · เสาหลัก
Context Management — จัดการทรัพยากรที่แพงที่สุด
เคยเจอไหมครับ — ปล่อย agent ทำงานยาว ๆ ผ่านไปสักพักมันเริ่ม "โง่ลง": ลืมข้อตกลงที่คุยกันตอนต้น กลับไปแก้ไฟล์ที่บอกแล้วว่าห้ามแตะ เรียกฟังก์ชันที่เพิ่งเปลี่ยนชื่อไปด้วยชื่อเก่า · โมเดลไม่ได้เสื่อมกลางทาง — แต่ "โต๊ะทำงาน" ของมันกำลังล้น
3.1 บนโต๊ะมีอะไรวางอยู่บ้าง
เล่ม #07 เปรียบ context window เป็นโต๊ะทำงานที่วางของได้จำกัดไปแล้ว · ใน agent ของบนโต๊ะมี 4 กอง: system prompt (คงที่), tool schemas (คงที่ — แต่ต่อ MCP เยอะ ๆ ก็บวมได้ · บทที่ 4.5), ประวัติการคุย และ ผลลัพธ์ tool — กองสุดท้ายคือตัวร้าย: อ่านไฟล์หนึ่งครั้งได้หลายพัน token, รันเทสต์หนึ่งรอบได้ log ยาวเหยียด และทุกอย่างกองอยู่บนโต๊ะไปตลอดเซสชันถ้าไม่มีใครจัดการ
3.2 ทำไม context ยาวถึงเป็นปัญหา
- แพง — โมเดลไม่ได้ "จำ" อะไรข้ามรอบ ทุกรอบของ loop คือการส่ง context ทั้งก้อน เข้าไปใหม่ · ประวัติ 100k token × วน 200 รอบ = จ่ายมหาศาล (caching ช่วยได้ส่วนหนึ่ง แต่หลักการนี้ไม่เปลี่ยน)
- ช้า — context ยิ่งยาว โมเดลยิ่งใช้เวลาประมวลนานขึ้นทุกรอบ
- จำเลอะ — อาการที่วงการเรียก context rot: ยิ่งยาว ความสนใจของโมเดลยิ่งเบลอ ข้อมูลที่อยู่กลาง ๆ ถูกมองข้าม (lost in the middle) ความผิดพลาดเก่า ๆ ที่ค้างอยู่ก็ลากงานใหม่ให้เพี้ยนตาม
ตลกร้ายคือสามข้อนี้มาพร้อมกัน: ยิ่งปล่อยให้ยาว เรายิ่งจ่ายแพงขึ้นเพื่อผลลัพธ์ที่แย่ลง — context จึงเป็นทรัพยากรที่ต้องบริหาร ไม่ใช่ถังที่เทอะไรลงไปก็ได้
3.3 เทคนิคหลักสามตัว
① Compaction / summarization — พอใกล้เต็ม harness สรุปประวัติเก่าให้เหลือย่อสั้น ๆ (ทำอะไรไปแล้ว ตกลงอะไรกันไว้ กำลังทำอะไรอยู่) แล้วเริ่มหน้าต่างใหม่ด้วยสรุปนั้น · ราคาที่จ่ายคือรายละเอียดหาย — ศิลปะอยู่ที่สรุปให้เก็บ "การตัดสินใจและเหตุผล" ไม่ใช่เก็บคำพูดดิบ ๆ
② Just-in-time retrieval — อย่ายัดข้อมูลล่วงหน้า "เผื่อได้ใช้" ให้ agent ค้นเมื่อต้องใช้ผ่านเครื่องมือ (ค้นไฟล์, grep, ค้นเอกสาร) · นี่คือเหตุผลที่ Claude Code ไม่โหลดทั้ง repo เข้า context แต่ให้เครื่องมือค้นแทน — จ่ายเฉพาะสิ่งที่หยิบมาใช้จริง
③ ตัดผล tool ยาว ๆ ตั้งแต่ต้นทาง — ผล tool ทุกตัวอักษรคือ "ค่าเช่ารายเดือน" ที่ต้องแบกไปทุกรอบที่เหลือ · harness ที่ดีจึง truncate ไฟล์ยาว แบ่งหน้าให้ขอเพิ่มทีหลัง และคืนเฉพาะส่วนที่เกี่ยว (เรื่องนี้โยงตรงเข้าบทที่ 4 — การออกแบบผลลัพธ์ของ tool)
3.4 RAG ที่พี่รู้จัก คือ special case ของเรื่องนี้
เล่ม #07 สอน grounding/RAG ไว้แล้ว — ระบบค้นเอกสารที่เกี่ยวแล้วแปะให้โมเดลก่อนตอบ · มองผ่านเลนส์เล่มนี้ RAG คือ just-in-time retrieval แบบ push: ฝั่งระบบเดาว่าโมเดลต้องใช้อะไรแล้วป้อนให้ · agent ยุคนี้ขยับไปอีกขั้นเป็นแบบ pull: โมเดลถือเครื่องมือค้นเอง ตัดสินใจเองว่าจะค้นอะไร เมื่อไหร่ ค้นซ้ำกี่รอบ — วงการเรียก agentic search · หลักการเดียวกัน แต่ย้ายคนตัดสินใจจากระบบไปที่ตัว agent
✅ สรุปบทที่ 3 — context = โต๊ะทำงานที่ทุกอย่างต้องจ่ายค่าเช่าทุกรอบ · ตัวกินพื้นที่ตัวจริงคือผล tool เก่า ๆ · ยาวเกิน = แพง + ช้า + จำเลอะ (context rot / lost in the middle) · สามเทคนิคหลัก: compaction (สรุปแล้วเริ่มใหม่), just-in-time retrieval (ค้นเมื่อใช้ ไม่ยัดล่วงหน้า), ตัดผล tool ตั้งแต่ต้นทาง · RAG คือ special case แบบ push — agent ยุคนี้ pull เอง