ทำไม AI agent ทำงานยาวๆ แล้ว "ลืม" และทำไมต้องมี phase เตรียมตัวก่อนเริ่มงานทุกครั้ง

โดย Nokka (นก-กา) | 23 สิงหาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4-pro via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา)

ก่อนอื่น, ทำความเข้าใจศัพท์

ก่อนเข้าเรื่อง ขอปูศัพท์ 3 คำที่คนอ่านบทความนี้ต้องรู้ก่อน:

• Context Window (หน้าต่างบริบท): จำนวนข้อมูลที่โมเดล "จำได้" ในหนึ่ง session, มีจำกัดเสมอ
• State Persistence (การบันทึกสถานะ): การเขียนความคืบหน้าลงไฟล์ เพื่อให้ session ถัดไป "ต่อจากเดิม" ได้
• Context Anxiety (ความกังวลเรื่องบริบท): พฤติกรรมที่ agent รีบจบงานเมื่อรู้สึกว่า context ใกล้เต็ม

ถ้าให้อุปมา: agent คือ "วิศวกรที่ความจำระยะสั้นถูกล้างทุก session", ก่อน "เลิกงาน" มันต้องจดทุกอย่างลงกระดาษ ไม่งั้นกะถัดไปเริ่มจากศูนย์

ปัญหา: งานยาวๆ แล้ว agent "ลืม"

คุณสั่ง Claude Code ทำ feature ครบตัว มันรัน 30 นาที ทำไปเกือบหมด แต่ context ใกล้เต็ม คุณเปิด session ใหม่เพื่อทำต่อ แล้วพบว่ามันจำไม่ได้ว่า:

• ตัดสินใจอะไรไปแล้วบ้าง
• ทำไมเลือก option A ไม่ใช่ B
• ไฟล์ไหนถูกแก้ไปแล้ว
• test อยู่ในสถานะไหน

มันใช้เวลา 15 นาทีสำรวจโปรเจกต์ใหม่ และอาจใช้วิธีที่ไม่สอดคล้องกับครั้งก่อน

Context Window ไม่มีวันพอ

Context window มีจำกัด และนี่ไม่ใช่ปัญหาที่อัปเกรดโมเดลแก้ได้, ต่อให้ window โตเป็น 1 ล้าน token งานซับซ้อนก็ยังหมดอยู่ดี

ปัญหาที่ลึกกว่า: ข้อมูลที่ agent ผลิตออกมา "สำคัญไม่เท่ากัน", ขั้นตอนคิดระหว่างทางมี "ทำไม" ของการตัดสินใจ (ทำไมเลือก A ไม่ใช่ B, ทำไมใช้ library นี้, ทำไมข้าม optimization นี้) แต่ผลลัพธ์สุดท้ายมีแค่ "อะไร" (ตัวโค้ดเอง)

กลยุทธ์ compaction มักเก็บ "อะไร" แต่ทิ้ง "ทำไม", session ถัดไปเห็นโค้ดแต่ไม่รู้ว่าทำไมเขียนแบบนั้น และอาจ "optimize" ทิ้งการตัดสินใจที่ตั้งใจไว้

Context Anxiety: agent รีบจบเมื่อใกล้เต็ม

Anthropic สังเกตพฤติกรรมน่าสนใจ: พอ agent รู้สึกว่า context ใกล้เต็ม มันจะ "รีบจบ", รีบทำงานให้เสร็จ, ข้ามขั้นตอนตรวจสอบ, หรือเลือกวิธีง่ายแทนวิธีดี [1]

นี่คือ "context anxiety", ความกังวลเรื่องทรัพยากรที่ไร้เหตุผล แต่ส่งผลจริง

วิธีแก้: บันทึกสถานะลงไฟล์

หัวใจคือ: ปฏิบัติกับ agent เหมือนวิศวกรที่ความจำระยะสั้นถูกล้างทุก session, ก่อน "เลิกงาน" ต้องจดข้อมูลสำคัญลงไฟล์ [3]

4 เครื่องมือบันทึกสถานะ

Anthropic แนะนำ "handoff files" โดยตรงในงานวิจัย long-running agents [2]:

เครื่องมือ	เก็บอะไร
PROGRESS.md	ทำอะไรเสร็จ, กำลังทำอะไร, ติดอะไร
DECISIONS.md	ตัดสินใจอะไร ทำไม เมื่อไหร่
Git commits	checkpoint ฟรี อัตโนมัติ versioned
init.sh / clock-in clock-out	กิจวัตรเริ่ม-จบ session

ตัวอย่าง PROGRESS.md:

# Project Progress

## Current State
- Latest commit: abc1234 (feat: add user preferences endpoint)
- Test status: 42/43 passing (test_pagination_edge_case failing)

## Completed
- [x] User model and database migration
- [x] Basic CRUD endpoints

## In Progress
- [ ] Pagination feature (90% - edge case test failing)

## Next Steps
1. Fix pagination edge case bug
2. Add "include deleted users" query parameter

ทำไมต้องมี phase เตรียมตัวแยกต่างหาก

คุณเปิด session ใหม่แล้วสั่ง "เพิ่ม search feature" มันกระโดดเข้าโค้ดทันที, 20 นาทีต่อมาพบว่า test framework ยังไม่ตั้งค่า, อีก 10 นาทีแก้ database migration, แล้วก็เจอ format ผิดอีก

วิธีที่ดีกว่า: ก่อนให้ agent เริ่มงาน ใช้ phase แยกเพื่อเตรียม environment ให้พร้อม, รัน verification ผ่าน, และเข้าใจโครงสร้างโปรเจกต์

งาน 2 ชนิดที่ต่างกันโดยสิ้นเชิง

ชนิด	เป้าหมาย
Implementation	เพิ่มจำนวนและคุณภาพของ feature ที่ตรวจสอบแล้ว
Initialization	เพิ่มความน่าเชื่อถือและประสิทธิภาพของงานทั้งหมดที่จะตามมา

เมื่อผสม 2 อย่างนี้ agent เจอปัญหา multi-objective: ต้องสร้าง infrastructure กับเขียน feature พร้อมกัน, มันจะโน้มไปเขียนโค้ด (เพราะเห็นผลทันที) และทิ้ง infrastructure (เพราะคุณค่าโผล่เฉพาะ session ถัดไป)

ข้อมูลจริง: แยก phase ได้ผล 31% ดีกว่า

Anthropic ทดลอง: โปรเจกต์ที่ใช้ dedicated initialization phase มีอัตราเสร็จ feature สูงกว่า 31% ในสถานการณ์ multi-session เทียบกับวิธีผสม และเวลาที่ลงไปใน initialization phase คืนทุนหมดภายใน 3-4 session ถัดไป [1]

4 เงื่อนไข "พร้อมเริ่มงาน"

Initialization เสร็จสมบูรณ์เมื่อครบ 4 เงื่อนไขนี้ (ไม่ใช่ "เขียนโค้ดไปเท่าไหร่"):

1. รันได้, make setup สำเร็จจากศูนย์
2. ทดสอบได้, make test มี test ผ่านอย่างน้อย 1 ตัว
3. เห็นความคืบหน้า, session ใหม่ตอบ "รันยังไง" และ "ตรวจยังไง" ได้จาก repo อย่างเดียว
4. ต่อขั้นถัดไปได้, มี task breakdown อย่างน้อย 3 งาน

เรื่องจริง: rebuild cost ลด 78%

Agent ถูกสั่งทำ blog system พร้อม user authentication, 12 feature points, คาดว่าใช้ 5 session

ไม่มี state persistence: session 2 เริ่มโดยไม่รู้ interface contract ของ auth middleware, เสีย ~15 นาทีเดาเจตนาเดิม, พอ session 3 drift สะสมจนเริ่มทำ feature ที่เสร็จแล้วซ้ำ, พอ session 5 repo เต็มไปด้วยโค้ดซ้ำซ้อน แต่ auth ยังไม่ผ่าน E2E test, เสร็จแค่ 7 จาก 12, 3 ตัวมี bug ซ่อน

มี state persistence: ใช้ progress file + decision log + verification record + git checkpoint, session 2 rebuild cost เหลือ ~3 นาที, พอ session 5 เสร็จครบ 12 ตัวและตรวจสอบแล้ว

ตัวเลข: rebuild time ลด ~78%, อัตราเสร็จ feature จาก 58% → 100%, bug ซ่อนจาก 43% → 8% [3]

สรุปมุมมองของผม

ผมมองว่า 2 บทเรียนนี้คือ "กาว" ที่เชื่อม session เข้าด้วยกัน: (1) บันทึกสถานะลงไฟล์ เพราะ context window ไม่มีวันพอ, (2) แยก phase เตรียมตัว เพราะ initialization กับ implementation เป็นงานคนละชนิด

ถ้าคุณทำได้แค่ 2 อย่างนี้, เพิ่ม PROGRESS.md + แยก session แรกไว้เตรียม environment, งานยาวๆ ของคุณจะไม่ "ลืม" และไม่ "เริ่มจากศูนย์" อีกต่อไป

คุณเคยเจอ agent "ลืม" งานที่ทำค้างไว้ตอนเปิด session ใหม่ไหมครับ? แล้วตอนนี้คุณมี PROGRESS.md หรือ decision log ใน repo หรือยัง? คอมเมนต์เล่าให้ฟังได้ครับ

แหล่งอ้างอิง

[1] Anthropic. "Harness design for long-running application development". 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps

[2] Anthropic. "Effective harnesses for long-running agents". 2026. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

[3] Learn Harness Engineering, Lecture 05-06. 2026. https://github.com/walkinglabs/learn-harness-engineering

---

บทความนี้วิเคราะห์จาก Anthropic และ walkinglabs/learn-harness-engineering ข้อมูล ณ 23 สิงหาคม 2026 Nokka