ความรู้ AI agent อยู่ 3 ชั้น: chat / memory / repo — อะไรรอด /clear
TL;DR — ความรู้ที่ agent ใช้ อยู่ได้ 3 ชั้น: chat context (บทสนทนาตอนนี้) · agent memory (ไฟล์ส่วนตัวที่ถูกโหลดกลับทุก session) · repo files (ไฟล์ใน git). ต่างกันที่ 2 แกน — “รอด
/clearไหม” (durability) × “ใครเห็น” (sharing). วางความรู้ผิดชั้น = ไม่ก็ หาย (ฝากไว้ใน chat) ไม่ก็ หลุด scope (ฝากของทีมไว้ใน memory ส่วนตัว). รู้ 3 ชั้นนี้แล้วจะตอบได้ทันที ว่าอะไรควรเก็บที่ไหน
🌐 vendor-neutral — โมเดล 3 ชั้นนี้จริงกับ agent ทุกตัวที่มี memory/instruction ต่อโปรเจกต์ (Cursor, Copilot, Codex, Antigravity, Claude Code) — ต่างกันแค่ชื่อ/ที่เก็บ. ป้าย 🔷 = เจาะจง Claude Code, 🌐 = หลักการทั่วไป
การทดลอง: /clear แล้ว agent ลืมอะไร ไม่ลืมอะไร
ลองสังเกต — พอคุณ /clear (หรือเปิด session ใหม่) agent ลืมบทสนทนาเมื่อกี้เกลี้ยง แต่กลับ
ยังจำ บาง preference หรือ convention ของโปรเจกต์ได้ และแน่นอนว่าไฟล์ในเรพ ไม่หายไปไหน
ทำไมบางอย่างหาย บางอย่างรอด? เพราะความรู้พวกนี้ อยู่คนละชั้น — และแต่ละชั้นมีกฎการอยู่รอด ของมันเอง. (ถ้ายังไม่เห็นภาพว่าทำไม chat ถึงหาย ลองย้อน context window ทำงานยังไง — LLM เป็น stateless สิ่งที่ “จำ” ได้คือสิ่งที่ถูกประกอบกลับเข้า context เท่านั้น)
3 ชั้นของความรู้ (จับด้วย 2 แกน)
| ชั้น | อยู่ที่ไหนจริง | รอด /clear? | ใครเห็น |
|---|---|---|---|
| chat context | context window ของ session (transcript อยู่บนดิสก์ แต่ ไม่ auto-reload) | ❌ หาย | แค่ session นี้ |
| agent memory | ไฟล์ ~/.claude/…/memory/*.md (harness โหลด MEMORY.md กลับ ทุก session) | ✅ รอด | เครื่อง/agent นี้ (private) |
| repo files | ไฟล์ที่ commit ใน git | ✅ รอด | ทุกคน/ทูล/เครื่อง (shared) |
อ่านตารางนี้เป็น “พิกัด”: เลื่อนลงล่าง = durable ขึ้น + คนเห็นเยอะขึ้น. ของชั่วคราวอยู่บนสุดก็พอ · ของที่ต้องรอดข้ามวัน/ข้ามคนต้องเลื่อนลงล่าง
ทำไม memory “รอด” แต่ chat ไม่รอด
จุดที่คนเข้าใจผิด: คิดว่า chat ก็ถูกเก็บเป็นไฟล์ (transcript) เหมือนกัน ทำไมไม่รอด?
durability ไม่ได้มาจาก “เป็นไฟล์” — แต่มาจาก “ถูกโหลดกลับเข้า context”
- transcript เป็นไฟล์จริง แต่ harness ไม่ได้เอากลับมาใส่ context ให้อัตโนมัติ → เท่ากับหาย
- memory รอด เพราะ harness โหลด
MEMORY.mdกลับเข้า context ทุก session — มันเลย “จำได้”
พูดอีกแบบ: ชั้นที่รอด = ชั้นที่ มีกลไกประกอบมันกลับเข้า context ทุกครั้ง (ตรงกับหลัก stateless ในตอนที่แล้วเป๊ะ — จำได้ = ถูก re-load ไม่ใช่ระลึกได้)
🌐 ทั่วไป: ทุกเครื่องมือมี “ชั้นที่โหลดเสมอ” (rules / instructions / memory index) vs “ชั้นที่ ไม่โหลด” (log บทสนทนา) — สิ่งที่อยู่ชั้นบนเท่านั้นถึง “จำได้”
ชั้น memory เข้าใจผิดบ่อย — 3 จุด
ชั้น memory เป็นชั้นที่ใช้ผิดกันมากสุด เพราะเข้าใจธรรมชาติมันคลาดเคลื่อน:
1. มัน durable “โดยตั้งใจ” — รอดทั้ง /clear และปิด session
ตรงข้ามกับ chat ที่ระเหย: memory ถูกออกแบบให้ อยู่ยาว (นั่นคือหน้าที่ของมัน) · เป็น
private/local (เห็นเฉพาะ agent/เครื่องนี้) · และ ผูกกับ path ของโปรเจกต์ (ดูหัวข้อถัดไป)
2. ไม่มี auto-clear / auto-expire → มันโตแบบสะสม ไม่มีอะไรมาลบให้ ยิ่งใช้ยิ่งพอก → ต้อง consolidate เอง เป็นระยะ: merge อันซ้ำ · ลบอัน stale (ที่ไม่จริงแล้ว) · trim index ให้กระชับ. memory ที่ไม่เคยจัด = รกและเริ่มขัดกันเอง
3. 🔷 (Claude Code) ไม่ใช่ทุกไฟล์ memory ที่โหลดเข้า context
ทุก session โหลดเข้า context แค่ MEMORY.md = ตัว index (บรรทัดละ memory หนึ่งอัน) — ไม่ใช่
ทุกไฟล์. ไฟล์ fact ย่อยถูก recall เฉพาะตอน relevant
💰 ผลเชิงต้นทุน: context ที่ memory กินจริง = ความยาวของ index ไม่ใช่จำนวนไฟล์ → มี 200 memory แต่ index กระชับก็ยังถูก. คุมต้นทุนที่ “index สั้น” ไม่ใช่ “จำนวนไฟล์น้อย”
🌐 ทั่วไป: เครื่องมืออื่นมักโหลด “ดัชนี/สรุป” เข้า context ไม่ใช่ทุก note — เช็คว่าเครื่องมือคุณ โหลดอะไรต่อ session
gotcha ของชั้น memory: มันผูกกับ path
ชั้น memory มีกับดักหนึ่งที่ต้องรู้ — มันไม่ได้ผูกกับ “repo” แต่ผูกกับ path ของโฟลเดอร์ที่เปิด. เปิดจาก git worktree / symlink / subfolder = path คนละอัน = memory กองใหม่ (ว่าง) ทั้งที่เป็น repo เดียวกัน
รายละเอียดเต็ม + วิธีกันอยู่ใน memory ผูกกับ path (worktree มีของตัวเอง) — สรุปสั้น: ความรู้ที่ต้องรอดข้าม worktree/เครื่อง/เพื่อนร่วมทีม อย่าฝากชั้น memory → เลื่อนลงชั้น repo
capture: จับ “เนื้อ” ไม่ใช่ “ชื่อ” — ตอน context ยังอยู่
นี่คือ move ที่พลาดกันบ่อยสุด. สมมติระหว่าง debug service A คุณเจอวิธีแก้ปัญหาที่ดีมาก อยากเก็บไว้
ทำเป็น doc/บทความทีหลัง. ตอนนี้ความรู้นั้นอยู่ ชั้น chat เท่านั้น (รายละเอียดปัญหา + ตัวอย่าง +
วิธีแก้) — ซึ่ง จะหายตอน /clear
ทางแก้มี 2 กฎ:
- ย้ายขึ้นชั้น durable ตอน context ยังถือมันอยู่ — อย่าเลื่อนไปทำทีหลัง เพราะ session ปิดเมื่อไร เนื้อหายเมื่อนั้น (stateless). “ทีหลัง” = สาย
- capture “เนื้อ” พอให้ session ที่ความจำเป็นศูนย์ทำต่อได้ — ไม่ใช่แค่หัวข้อ. จดหัวข้อลอย ๆ = ทีหลังเปิดมาไม่มีใครรู้ว่าเคสคืออะไร. เกณฑ์วัด: “คนที่ไม่เคยเห็นบทสนทนานี้ อ่านโน้ตแล้วทำต่อได้ไหม”
ตัวอย่างคลาสสิกอีกอัน: pending action ข้าม session — เช่น “ping ทีม X หลัง merge”. ถ้าฝากไว้ ในแชท =
/clearทีเดียวหาย. ต้องเลื่อนลงชั้น memory (ถ้าเป็นเรื่องเรา) หรือ repo (ถ้าทีมต้องรู้)
ของนี้ควรอยู่ชั้นไหน? (ตัดสินเร็ว ๆ)
ถามแค่ 2 แกนของตาราง — “ต้องรอด /clear ไหม + ใครต้องเห็น”:
- ใช้จบใน session นี้ (ลอง ๆ, คิดดัง ๆ) → chat พอ ไม่ต้อง capture
- “ฉัน/เครื่องนี้ทำงานยังไง” (preference, gotcha ส่วนตัว) → memory
- ทีมต้องเห็น / ต้องรอดข้ามเครื่อง (decisions, conventions, สถานะงาน, ความรู้ที่ reuse) → repo
เมื่อความรู้ควรอยู่ชั้น repo แล้ว จะมีคำถามต่อว่า “แล้วกันมันซ้ำหลายที่จนขัดกัน (drift) ยังไง” — อันนั้นคือกติกา source of truth เดียว + pointer (ตอนท้ายซีรีส์) · ตอนนี้แค่วางให้ถูก ชั้น ก่อน
สรุป
- ความรู้ agent อยู่ได้ 3 ชั้น: chat context · agent memory · repo files
- จับด้วย 2 แกน: รอด
/clearไหม (durability) × ใครเห็น (sharing) — เลื่อนลงล่าง = durable ขึ้น + shared ขึ้น - durability มาจากการถูกโหลดกลับเข้า context ไม่ใช่แค่ “เป็นไฟล์” (transcript เป็นไฟล์แต่ไม่ reload = หาย)
- ชั้น memory ผูกกับ path (worktree = กองใหม่) → ของที่ต้องรอดข้ามเครื่อง/ทีม เลื่อนลงชั้น repo
- capture เนื้อ (ไม่ใช่ชื่อ) ตอน context ยังอยู่ — วางผิดชั้นแล้วของหาย/หลุด scope
ต่อไปในซีรีส์ “Working with AI agents”: พอรู้แล้วว่าความรู้ควรอยู่ชั้นไหน — ตอนถัดไปเอาหลักนี้มา ประกอบเป็น ระบบ state ที่ resume ได้จริง (PLAN/PROGRESS/HANDOFF + memory + git) (ระบบ handoff ที่ resume ได้)
