context degradation ในเซสชันยาว และ scratchpad ที่คงอยู่
แนวคิด
เมื่อสำรวจ codebase ใหญ่ในเซสชันที่ยืดยาว จะมีอาการหนึ่งค่อย ๆ ปรากฏ คือ agent เริ่มให้คำตอบที่ไม่สอดคล้องกัน และเริ่มอ้างถึง "รูปแบบทั่วไปที่มักเจอ" แทนที่จะอ้างถึงคลาสหรือฟังก์ชันเจาะจงที่มันค้นพบไปก่อนหน้า อาการนี้คือ context degradation คือความเสื่อมของบริบทเมื่อเซสชันยาวเกินไป
สาเหตุคือ context ที่บวมด้วย output จากการสำรวจจำนวนมากเริ่มทำให้รายละเอียดเจาะจงจางหายหรือถูกกลบ พอถามคำถามที่ต้องอ้างสิ่งที่ค้นเจอตอนต้นเซสชัน agent จึงตอบแบบเหมารวมแทนที่จะชี้ไปที่คลาสจริง นี่อันตรายเพราะคำตอบยังฟังดูมั่นใจ แต่เนื้อหาเริ่มคลาดเคลื่อนจากสิ่งที่ค้นพบจริง
ทางแก้คือให้ agent จด key finding ลง scratchpad file ที่คงอยู่ข้ามขอบเขตของ context แทนที่จะพึ่งความจำในบทสนทนาอย่างเดียว agent เขียนสิ่งที่ค้นเจอลงไฟล์ แล้วอ่านกลับมาเมื่อต้องตอบคำถามถัดไป finding ที่จดไว้จะไม่จางแม้ context จะเสื่อม เพราะมันอยู่ในไฟล์ ไม่ใช่ในหน้าต่างสนทนาที่บวมขึ้นเรื่อย ๆ
ทำไมสำคัญ
เอกสาร context windows อธิบายว่ายิ่ง token มาก ความแม่นยำและการเรียกคืนยิ่งเสื่อม เรียกว่า context rot การอ้าง "รูปแบบทั่วไป" แทนคลาสเจาะจงคือหน้าตาหนึ่งของ context rot ในงานสำรวจโค้ด docs จึงแนะนำให้ออกแบบ state artifact ให้การกู้บริบทเร็วเมื่อเริ่มเซสชันใหม่ แทนการหวังให้ทุกอย่างอยู่ในหน้าต่างเดียว
เอกสาร memory tool ให้กลไกที่ตรงกับแนวคิด scratchpad พอดี มันให้ agent สร้าง อ่าน แก้ และลบไฟล์ในไดเรกทอรี memory ที่คงอยู่ข้ามการสนทนา แนวคิดคือ just-in-time context retrieval คือไม่โหลดทุกอย่างขึ้นมาไว้ล่วงหน้า แต่จดสิ่งที่เรียนรู้ลงไฟล์แล้วอ่านกลับเมื่อจำเป็น วิธีนี้ทำให้ context ที่กำลังใช้งานโฟกัสอยู่กับงานตรงหน้า ซึ่งสำคัญมากสำหรับเซสชันยาวที่ context จะบวมจนล้น
สิ่งที่ต้องเข้าใจให้ลึกคือ scratchpad ไม่ได้แค่ประหยัดพื้นที่ แต่มันเปลี่ยนแหล่งความจริงของ agent จาก "บทสนทนาที่กำลังเสื่อม" มาเป็น "ไฟล์ที่แม่นยำและตรวจสอบได้" เมื่อ agent อ้าง finding มันอ้างจากไฟล์ ไม่ใช่จากความทรงจำที่จาง แนวปฏิบัติที่ดีคือสรุป finding สำคัญจากเฟสสำรวจหนึ่งก่อนขึ้นเฟสถัดไป แล้วฉีดสรุปนั้นเข้าไปใน context เริ่มต้นของเฟสใหม่ เพื่อให้ทุกเฟสเริ่มจากสถานะที่แม่นยำ
ตัวอย่าง
findings.md (scratchpad ที่ agent จดระหว่างสำรวจ)
## Auth flow
- entry: src/auth/login.ts → เรียก verifyToken() ใน src/auth/token.ts
- refund ต้องผ่าน verifyCustomer() ก่อนเสมอ (src/billing/refund.ts:42)
## Test files
- ทุกไฟล์ *.test.tsx อยู่ข้างไฟล์ที่มันเทสต์
→ เทิร์นถัดไปที่ถามเรื่อง refund agent อ่าน findings.md ก่อน
แล้วชี้ตรงไปที่ refund.ts:42 ไม่ใช่ตอบว่า "รูปแบบทั่วไปมักตรวจ customer ก่อน"
เช็คความเข้าใจ
context degradation ในเซสชันยาวแสดงอาการอย่างไร
scratchpad file ช่วยแก้ context degradation ได้อย่างไร