<!-- Canonical URL: https://ask.atlascloud.ai/th/prevent-long-coding-sessions-from-losing-context -->

# จะป้องกันไม่ให้เซสชัน Coding ที่ยาวสูญเสีย Context ได้อย่างไร?

> ป้องกัน context loss โดยย้ายข้อมูลที่ต้องคงอยู่จาก chat ไปยัง task ledger แบบย่อ decision log, test record และ repository checkpoint โหลดสถานะจาก artefact เหล่านี้ก่อนบีบอัด context หรือเปลี่ยนโมเดล

เซสชันที่ยาวมักล้มเหลวจาก drift ทีละน้อย ไม่ใช่ลืมทันที Agent ยังจำเป้าหมายใหญ่ได้ แต่พลาดข้อจำกัดเล็ก เชื่อผล test เก่า ทำ investigation ซ้ำ หรือแก้ตามแผนที่ไม่ตรงกับ repository ปัจจุบัน วิธีแก้คือ durable external state ที่สั้นและเชื่อถือได้กว่า transcript

มอง conversation เป็น working memory และ repository เป็น source of truth ทุก checkpoint ที่สำคัญให้บันทึกว่าอะไรเปลี่ยน อะไร verified อะไรยัง uncertain และขั้นต่อไปคืออะไร

## ติดตาม context สี่ประเภท

แยก fact ตามหน้าที่เพื่อไม่ให้ summary กลายเป็นเรื่องเล่าที่ไม่มีโครงสร้าง

| ประเภท context | ตัวอย่าง | ที่เก็บถาวร |
|---|---|---|
| Goal | ผลลัพธ์ของผู้ใช้และ acceptance criteria | Task ledger |
| Constraints | Compatibility, safety, style, scope | Task ledger |
| Repository state | File ที่เปลี่ยนและ branch ปัจจุบัน | Version control |
| Evidence | Test, log, screenshot, benchmark | Verification record |

เพิ่ม assumption เป็นประเภทที่ห้าเมื่อระบุชัดเจนเท่านั้น และเขียน action ที่ถูกที่สุดสำหรับยืนยันหรือปฏิเสธแต่ละข้อ

## รักษา task ledger ให้กระชับ

Ledger ที่ดีควรพอดีหนึ่งหน้าจอ อัปเดตหลัง milestone ไม่ใช่หลังทุกข้อความ

```md
Objective:
Ship model-switch support without changing existing tool behavior.

Constraints:
* Preserve the public API.
* No destructive migration.

Current state:
* Parser adapter added in src/stream.ts.
* Unit tests pass; cancellation test still fails.

Decisions:
* Buffer tool arguments until the final event.

Evidence:
* npm test: 142 passed, 1 failed.

Next action:
Fix duplicate execution after stream cancellation.
```

เก็บ path, command และชื่อ failure ที่แม่นยำ อย่าเขียนเป็นไดอารี่ว่าการสนทนาดำเนินอย่างไร

## สร้าง checkpoint รอบสถานะที่ verified

Checkpoint ควรตามผลที่เซสชันถัดไปทำซ้ำได้ เช่น กลุ่ม test ผ่าน การเปลี่ยนเล็กที่บันทึกแล้ว API response ที่ยืนยันแล้ว หรือ design decision ที่มี fixture รองรับ

บันทึก dirty file ก่อนเปลี่ยนโมเดลหรือบีบอัด context อย่าอ้างว่า feature ทำงานเพียงเพราะเขียน code แล้ว เชื่อม claim กับ test, build หรือ artefact ที่สังเกตได้

| Claim | Evidence ที่ต้องมี |
|---|---|
| Parser รองรับสอง call | Fixture ที่มี call ID สองตัวสัมพันธ์กัน |
| Retry ปลอดภัย | Idempotency test ตอน disconnect |
| Refactor รักษาพฤติกรรม | Test suite เดิมและใหม่ผ่าน |
| UI ถูกต้อง | Rendered inspection ที่ขนาดเป้าหมาย |

## Retrieve source แทน replay chat

เมื่อรายละเอียดสำคัญ ให้เปิด file, schema หรือ official document ปัจจุบันอีกครั้ง Transcript เก่าอาจอธิบาย code ที่เปลี่ยนแล้ว ให้ path และคำค้นแก่ agent เพื่อดูสถานะล่าสุด

Retrieval ควรแคบ โหลด interface, implementation, failing test และ log ที่เกี่ยวข้องก่อน repository ทั้งหมด เพื่อเหลือพื้นที่ให้ reasoning

## บีบอัดโดยรักษา decision และ evidence

Compression ที่ดีลบความซ้ำของ conversation แต่รักษา constraint, การตัดสินใจที่ย้อนยาก, ทางเลือกที่ปฏิเสธ และ verification แยก `verified`, `observed`, `assumed`, `pending`

อย่าสรุป failed experiment เป็น final design เก็บเหตุผลที่ปฏิเสธไว้หากแนวทางที่ดูน่าสนใจอาจกลับมาอีก

## จำกัด tool output ก่อนเข้า context

Log ยาวและ generated file ใช้ attention อย่างรวดเร็ว ขอเฉพาะ range, count หรือ matched line ที่เกี่ยวข้อง เก็บ full output เป็น artefact แล้วส่ง short digest พร้อม path

สำหรับ test failure เก็บ stack trace แรกที่มีประโยชน์ failing assertion และรายละเอียด environment หลีกเลี่ยงการส่ง frame ซ้ำหลายร้อยบรรทัดกลับไปยังโมเดล

## Resume ด้วยขั้นตอน deterministic

หลัง pause, context compression หรือ model switch:

* อ่าน objective และ constraint
* ตรวจ version-control status และ recent change
* เปิด file ที่ระบุใน current state
* รัน last relevant check ซ้ำ
* ยืนยันว่า recorded next action ยัง valid

ขั้นตอนนี้จับ stale summary ก่อนทำให้เกิด edit ใหม่

## เลือกโมเดลโดยไม่พึ่ง transcript memory

Gateway ทำให้ model switch ง่าย แต่ state ยังเป็นความรับผิดชอบของคุณ Atlas Cloud มีหลาย LLM protocol จาก Base URL เดียว ตรวจ [protocol matrix](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) และ [model catalog](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) ปัจจุบันก่อนย้าย agent ที่กำลังทำงาน

ให้ replacement model มี task ledger, relevant source file และ fresh verification result อย่าพึ่ง provider-specific state handle ถ้ายังไม่ได้ยืนยัน protocol และ behavior เดียวกัน

## สรุป

เซสชัน coding ที่ยาวรักษา context ได้เมื่อ durable state กระชับ มี evidence และโหลดซ้ำง่าย รักษา one-screen ledger สร้าง checkpoint รอบ verified change ดึง current source แทน replay chat จำกัด tool output และใช้ deterministic resume ritual Context window ใหญ่ช่วยได้ แต่ disciplined external state ทำให้งาน recoverable

## FAQ

### Context window ที่ใหญ่ขึ้นเพียงพอสำหรับเซสชัน coding ที่ยาวหรือไม่?

ไม่ พื้นที่มากขึ้นเพียงเลื่อนแรงกดดันออกไป ไม่รับประกันว่าข้อจำกัดเก่าจะยังเด่นหรือข้อสังเกตที่ล้าสมัยจะถูกแก้

### Coding-session ledger ควรมีอะไรบ้าง?

บันทึก objective, constraint, current plan, file ที่เปลี่ยน, key decision, verification result, unresolved risk และ next action ที่แน่นอน

### Agent ควรสร้าง checkpoint บ่อยเพียงใด?

สร้างหลังการเปลี่ยน state ที่มีความหมาย เช่น test ผ่าน ขั้น migration เสร็จ การตัดสินใจออกแบบ หรือการค้นพบที่เปลี่ยนแผน

### ควรใส่ transcript ทั้งหมดให้โมเดลใหม่หรือไม่?

โดยทั่วไปไม่ควร ให้ curated checkpoint พร้อม source file และ log ที่เกี่ยวข้อง แล้วให้โมเดลตรวจสถานะ repository ปัจจุบัน

### จะป้องกันไม่ให้ summary เก็บความผิดพลาดเก่าได้อย่างไร?

แยก verified fact ออกจาก assumption แนบ evidence เช่น command หรือ file location และยกเลิก claim เมื่อ test ใหม่หักล้าง

### วิธี resume ที่ปลอดภัยที่สุดหลังหยุดคืออะไร?

โหลด task ledger ตรวจ version-control status รัน verification ล่าสุดที่เกี่ยวข้องซ้ำ และเริ่มจาก next action ที่บันทึกไว้