Level 3 · ใช้ขั้นโปรscheduleอ่าน 20 นาที

Memory กับ context ทำไมแชทยาวถึงเริ่มหลุด

starsTL;DR

เข้าใจ context window กฎใหญ่ที่คุมความจำใช้งานของ AI ทำไมแชทยาวถึงช้าและพลาดมากขึ้น เมื่อไหร่ควรเริ่มใหม่ เมื่อไหร่ควรใช้ sub-agent และทำไมไฟล์อย่าง CLAUDE.md หรือ AGENTS.md จริง ๆ แล้วเป็นแค่ข้อความที่ถูกใส่เข้า context

Memory กับ context ทำไมแชทยาวถึงเริ่มหลุด

คุณเคยมีแชทที่เริ่มต้นดีมากไหม ตอนแรก AI เข้าใจงาน ตอบคม จับสไตล์ได้ พอผ่านไปสักชั่วโมง เริ่มมีอาการแปลก ๆ มันถามซ้ำเรื่องที่คุณบอกไปแล้ว ลืมข้อจำกัดสำคัญ เอาไฟล์เก่ามาปนกับไฟล์ใหม่ หรือแก้งานเหมือนคนงงว่าตอนนี้กำลังทำอะไรอยู่

หลายคนเรียกอาการนี้ว่า "AI เริ่มเมา" หรือ "แชทเน่า" แต่เบื้องหลังไม่ได้ลึกลับขนาดนั้น มันเกิดจากกฎข้อเดียวที่คุมทุกอย่างในงาน AI คือจำนวนข้อความทั้งหมดที่ model เห็นได้ในรอบนั้นมีเพดาน และพอข้อความกองนี้ยาวขึ้น คุณภาพการใช้ข้อมูลในกองก็เริ่มตก

กองข้อความนี้ในวงการ AI เรียกว่า context ส่วนเพดานของกองเรียกว่า context window บทก่อนหน้าอธิบายแล้วว่าทุกครั้งที่คุณกด Enter บทสนทนาทั้งหมดถูกส่งไปให้ model ใหม่ บทนี้จะตอบคำถามต่อว่า กองนั้นหนาได้แค่ไหน ทำไมหนาแล้วเริ่มพลาด และคุณควรจัดการมันยังไงแบบคนใช้จริง

Context คือโต๊ะทำงาน ไม่ใช่ความจำถาวร

เริ่มจากภาพที่ง่ายที่สุด ลองนึกว่า model มีโต๊ะทำงานหนึ่งตัว ทุกครั้งที่คุณให้มันทำงาน harness จะเอาเอกสารทั้งหมดที่เกี่ยวข้องมาวางบนโต๊ะนี้ก่อน เอกสารพวกนั้นมีคำสั่งระบบ ประวัติแชท ไฟล์ที่อ่าน ผลลัพธ์จาก tool ข้อความของคุณ และคำตอบเก่าของ model เอง

สิ่งที่อยู่บนโต๊ะตอนนั้นคือสิ่งเดียวที่ model ใช้ตอบได้ ถ้าเอกสารสำคัญไม่ได้อยู่บนโต๊ะ มันก็เหมือนไม่รู้เรื่องนั้น ถ้าเอกสารอยู่บนโต๊ะแต่ถูกฝังกองอยู่กลางเอกสารหนา ๆ มันก็ยังอาจใช้พลาดได้

โต๊ะนี้คือ context แปลเป็นภาษาคนคือ "ของทั้งหมดที่ model เห็นอยู่ตรงหน้าในงานนี้" ส่วน context window คือขนาดโต๊ะ โต๊ะใหญ่แค่ไหน วางเอกสารได้กี่ token ก่อนเต็ม

คำว่า window อาจทำให้รู้สึกเหมือนหน้าต่างที่มองออกไปข้างนอก แต่จริง ๆ มันใกล้กับ "พื้นที่ทำงาน" มากกว่า มีของที่วางได้จำกัด และทุกอย่างแย่งพื้นที่กันหมด คำสั่งระบบกินพื้นที่ ประวัติแชทกินพื้นที่ ไฟล์ยาว ๆ กินพื้นที่ output จาก tool กินพื้นที่ คำตอบที่ AI พิมพ์เองก็กลับมากินพื้นที่ในรอบถัดไป

💡 ใจความสำคัญ: context window ไม่ใช่ความจำถาวรของ AI แต่คือพื้นที่ทำงานชั่วคราวของรอบนั้น ยิ่งคุณใส่ของเยอะ พื้นที่ยิ่งเต็ม และ model ต้องทำงานกับกองเอกสารที่รกขึ้น

จุดที่การเปรียบเทียบโต๊ะทำงานใช้ไม่ได้คือ model ไม่ได้ "มอง" เอกสารแบบคน มันไม่ได้ใช้สายตากวาดโต๊ะ แต่ใช้กลไกเดาคำจาก token ทั้งหมดที่ถูกส่งเข้าไป ถึงอย่างนั้น ภาพโต๊ะช่วยให้เห็นสิ่งสำคัญคือ ทุกอย่างต้องอยู่ในพื้นที่เดียวกัน และพื้นที่นั้นมีขีดจำกัด

อะไรบ้างที่กิน context

เวลาคุณพิมพ์ประโยคสั้น ๆ คุณอาจคิดว่า context เพิ่มแค่นิดเดียว แต่ในเครื่องมือ agent อย่าง Claude Code สิ่งที่อยู่ใน context เยอะกว่าข้อความที่คุณเห็นมาก

ก่อนคุณพิมพ์อะไรด้วยซ้ำ อาจมีของหลายชั้นถูกโหลดเข้ามาแล้ว เช่น system prompt, ไฟล์คำสั่งของโปรเจกต์อย่าง CLAUDE.md, auto memory, ชื่อเครื่องมือ MCP, คำอธิบาย skill และข้อมูลสภาพแวดล้อมอื่น ๆ ที่ harness ต้องให้ model เห็นเพื่อทำงานได้

พอเริ่มทำงาน context จะโตขึ้นจากทุกอย่างที่เกิดขึ้นใน session

  • คุณพิมพ์คำสั่งหนึ่งครั้ง ข้อความนั้นเข้า context
  • AI ตอบยาว ๆ คำตอบนั้นเข้า context
  • AI อ่านไฟล์หนึ่งไฟล์ เนื้อหาไฟล์เข้า context
  • AI รันคำสั่งแล้วได้ผลลัพธ์ยาว ๆ ผลลัพธ์นั้นเข้า context
  • AI แก้ไฟล์แล้วอธิบายสิ่งที่ทำ ข้อความนั้นเข้า context
  • คุณแนบเอกสารหรือ paste ข้อมูลยาว ๆ ทั้งก้อนนั้นเข้า context

นี่คือเหตุผลที่งานที่ดูสั้นบนหน้าจออาจหนักมากข้างหลัง เช่นคุณบอกว่า "ช่วยดู error นี้หน่อย" แล้ว AI อ่าน log ยาว 2,000 บรรทัด เปิดไฟล์อีก 8 ไฟล์ รัน test แล้วได้ output อีกหลายหน้า context ไม่ได้โตตามความยาว prompt ของคุณ แต่มันโตตามของทั้งหมดที่ถูกนำเข้ามาให้ model เห็น

ลองทำดู: ถาม AI ว่าอะไรน่าจะอยู่ใน context ตอนนี้

เปิดแชทที่คุณใช้ทำงานมาสักพัก แล้วพิมพ์ว่า

ลองประเมินให้หน่อยว่าในบทสนทนานี้ ตอนนี้มีอะไรบ้างที่น่าจะกิน context อยู่
แยกเป็นหมวด เช่น ประวัติแชท ไฟล์ที่แนบ ข้อมูลที่ฉัน paste คำสั่งที่ฉันให้ไว้ และสิ่งที่คุณตอบไปแล้ว

มันอาจไม่เห็นตัวเลขจริงของระบบ แต่คำตอบจะช่วยให้คุณมองแชทเป็นกองเอกสาร ไม่ใช่เป็นบทสนทนาลอย ๆ ถ้าใช้ Claude Code คำสั่ง /context จะให้ breakdown ที่ตรงกว่า เพราะเครื่องมือรู้จริงว่าพื้นที่กำลังถูกใช้อะไรบ้าง

ทำไมแชทยาวไม่ได้แค่ "เต็ม" แต่เริ่มใช้ข้อมูลแย่ลง

มีความเข้าใจผิดที่ต้องแก้ตรงนี้ หลายคนคิดว่า context window ทำงานเหมือนกล่อง ถ้ายังไม่เต็มก็ไม่มีปัญหา พอเต็มปุ๊บค่อยพัง ความจริงไม่เรียบแบบนั้น

ก่อนจะเต็ม คุณภาพอาจเริ่มตกแล้ว เพราะ model ต้องใช้ข้อมูลจากกองที่ยาวขึ้นเรื่อย ๆ ยิ่งกองยาว สัญญาณสำคัญยิ่งจมอยู่ในเสียงรบกวนเยอะขึ้น ประโยคหนึ่งที่คุณบอกไว้ตอนต้นว่า "ห้ามใช้สีม่วง" อาจยังอยู่ใน context แต่ตอนนี้ถูกฝังอยู่ระหว่างคำตอบเก่า log ยาว ๆ ไฟล์หลายไฟล์ และการแก้งานที่ล้มเหลว 3 รอบ

งานวิจัยที่คนมักอ้างถึงเรื่องนี้ชื่อ Lost in the Middle ทีมวิจัยทดสอบว่า model ใช้ข้อมูลใน context ยาว ๆ ได้ดีแค่ไหน ผลสำคัญคือ model หลายตัวทำได้ดีที่สุดเมื่อข้อมูลสำคัญอยู่ต้นหรือท้ายกอง แต่ทำได้แย่ลงเมื่อข้อมูลสำคัญอยู่กลางกอง แม้เป็น model ที่รองรับ context ยาวก็ตาม

นี่แปลว่า "ข้อมูลยังอยู่" ไม่เท่ากับ "model ใช้มันได้ดี" เหมือนคุณมีเอกสารสำคัญอยู่ในแฟ้มจริง แต่แฟ้มนั้นหนา 300 หน้า และเอกสารสำคัญอยู่หน้า 147 เวลาต้องตอบเร็ว ๆ คุณมีโอกาสพลาดสูงกว่าการวางเอกสารสำคัญไว้หน้าแรกหรือหน้าสุดท้าย

💡 ใจความสำคัญ: แชทยาวไม่ได้พังเพราะ AI ลืมอย่างเดียว บางทีข้อมูลยังอยู่ใน context แต่ model ดึงมาใช้ได้แย่ลง โดยเฉพาะข้อมูลที่จมอยู่กลางกองยาว ๆ

ตรงนี้คือคำตอบของประโยคจากบทก่อนที่บอกว่าแชทยาว "โง่ลงแบบวัดได้" มันไม่ได้เป็นแค่ความรู้สึก งานวิจัย long-context วัดให้เห็นแล้วว่าตำแหน่งของข้อมูลใน context มีผลต่อ performance และเอกสารของ Claude Code เองก็เตือนว่าคำสั่งจากช่วงต้นของบทสนทนาอาจหายหรือถูกสรุปจนเสียรายละเอียดเมื่อ context ใกล้เต็ม

Fresh-start rule: context ที่ว่างที่สุดเท่าที่ยังเกี่ยวข้อง

กฎใช้งานจริงที่ควรจำมีประโยคเดียว

context ที่ว่างที่สุดเท่าที่ยังเกี่ยวข้อง มักให้คำตอบดีที่สุด

ไม่ใช่ "ยิ่งให้ข้อมูลเยอะยิ่งดี" และไม่ใช่ "ล้างใหม่ตลอดเวลาดีที่สุด" จุดที่ดีคือให้เฉพาะของที่จำเป็นต่องานตอนนี้ และตัดของที่ไม่เกี่ยวออกให้มากที่สุด

ลองเทียบสองสถานการณ์

สถานการณ์แรก คุณใช้แชทเดียวทำทุกอย่างตั้งแต่ brainstorm ชื่อโปรเจกต์ เขียนแผนการตลาด ถามเรื่องภาษี แก้อีเมลลูกค้า แล้วกลับมาขอให้มันเขียน copy หน้าเว็บ แชทนี้มีข้อมูลเยอะจริง แต่เยอะปนกันไปหมด model ต้องอ่านเรื่องไม่เกี่ยวจำนวนมากก่อนตอบเรื่องหน้าเว็บ

สถานการณ์ที่สอง คุณเปิดแชทใหม่ แล้ว paste brief หน้าเว็บที่จำเป็นจริง ๆ ใส่เป้าหมาย กลุ่มลูกค้า tone และข้อห้ามสำคัญ แค่นี้ context บางกว่าเยอะ แต่เกี่ยวกับงานตรงหน้ามากกว่า คำตอบมักคมกว่า

นี่คือ fresh-start rule แปลเป็นภาษางาน

  • ถ้าเปลี่ยนหัวข้องาน เปิดแชทใหม่
  • ถ้าคุยเรื่องเดิมแต่เริ่มวนผิดทาง เปิดแชทใหม่พร้อมสรุปที่ถูกต้อง
  • ถ้าข้อมูลเก่าเยอะมากแต่ยังต้องใช้บางส่วน ให้สรุปเฉพาะส่วนสำคัญแล้วเริ่มใหม่
  • ถ้าทำงานยาวเรื่องเดียวและยังต้องรักษารายละเอียดจำนวนมาก ใช้การ compact หรือเขียน handoff file แทนการลากประวัติทั้งหมด

ใน Claude Code มีคำสั่งที่ทำให้กฎนี้จับต้องได้ /clear ใช้เริ่ม context ใหม่เมื่องานไม่เกี่ยวกับของเดิม ส่วน /compact ใช้แทนประวัติยาว ๆ ด้วย summary เมื่อคุณยังทำงานเดิมต่อ เอกสารของ Claude Code แนะนำแนวคิดเดียวกันคือ clear ระหว่างงานที่ไม่เกี่ยวกัน และ compact เมื่อต้องต่อ session ยาว

ลองทำดู: รีเซ็ตแบบมี handoff

เปิดแชทยาวที่คุณรู้สึกว่าเริ่มหลุด แล้วพิมพ์ว่า

สรุป handoff สำหรับเปิดแชทใหม่ให้หน่อย
เอาเฉพาะเป้าหมายงาน ข้อสรุปที่ตัดสินใจแล้ว ข้อห้ามสำคัญ ไฟล์หรือข้อมูลที่ยังต้องใช้ และ next step
ตัดบทสนทนาที่ลองผิดลองถูกหรือไม่เกี่ยวแล้วออก

จากนั้นเปิดแชทใหม่ paste handoff นี้ แล้วให้ทำงานต่อ คุณจะเห็นว่ามันเหมือนย้ายจากโต๊ะรกไปโต๊ะใหม่ โดยเอาเฉพาะเอกสารที่ต้องใช้จริงไปด้วย

Compact ช่วยได้ แต่ไม่ใช่ยาวิเศษ

เมื่อ session ยาวมาก เครื่องมือบางตัวจะช่วยย่อประวัติให้เอง Claude Code เรียกสิ่งนี้ว่า compaction แนวคิดคือเอาบทสนทนายาว ๆ มาแทนด้วย summary ที่สั้นกว่า เพื่อคืนพื้นที่ใน context

ฟังดูเหมือนชนะฟรี แต่มี trade-off ชัดเจน เพราะ summary คือการบีบอัด ข้อมูลบางอย่างต้องหายไปเสมอ ถ้า summary เก็บเป้าหมายหลักได้ แต่ตัดข้อห้ามเล็ก ๆ ที่สำคัญทิ้ง งานหลัง compact ก็อาจเริ่มเพี้ยนได้

ดังนั้น compact เหมาะกับงานยาวเรื่องเดียวที่ยังต้องเดินต่อ แต่ไม่ควรใช้แทนการเริ่มใหม่ทุกกรณี ถ้าคุณเปลี่ยนจาก "แก้ bug login" ไปเป็น "เขียนบทความการตลาด" การ compact ประวัติเก่าไว้ก็ยังพกขยะจากงานเก่ามาด้วย เปิดใหม่ดีกว่า

ในงานจริงให้คิดแบบนี้

  • /clear หรือแชทใหม่ คือย้ายโต๊ะ ล้างทุกอย่าง แล้วเริ่มจาก brief ใหม่
  • /compact คือจัดกองเอกสารเดิมให้สั้นลง เพื่อทำงานเดิมต่อ
  • handoff file คือเขียนสรุปเองให้ชัด แล้วเอาไปใช้เปิด session ใหม่

💡 ใจความสำคัญ: compact ลดความหนาของ context แต่แลกกับการสูญเสียรายละเอียดบางส่วน ถ้างานเปลี่ยนเรื่อง ให้เริ่มใหม่ ถ้างานเดิมยาวมาก ให้ compact หรือทำ handoff อย่างตั้งใจ

ทำไม sub-agent ถึงมีเหตุผลให้มีอยู่

พอเข้าใจ context แล้ว sub-agent จะคลิกทันที

สมมติคุณกำลังให้ AI เขียนรายงาน 10 หน้า แล้วอยากให้มันไปหาข้อมูลประกอบ 20 แหล่ง ถ้าให้ main chat ไปค้นเองทั้งหมด ผลการค้นหา เนื้อหาเว็บ ข้อความที่เปิดอ่าน และการลองผิดลองถูกจะไหลกลับเข้ามาใน context หลัก กองเอกสารบนโต๊ะหลักหนาขึ้นทันที ทั้งที่คุณอาจต้องการแค่ข้อสรุป 10 บรรทัด

sub-agent คือการส่งผู้ช่วยอีกตัวไปทำงานย่อยบนโต๊ะอีกตัว มันมี context window แยกของตัวเอง ไปอ่านเว็บ เปิดไฟล์ หรือไล่ log ยาว ๆ ในพื้นที่ของมัน ทำงานเสร็จแล้วส่งสรุปกลับมาที่ main chat แทนที่จะลากเอกสารดิบทั้งหมดกลับมา

เอกสาร Claude Code อธิบายตรงกันว่า sub-agent ทำงานใน context แยก และเมื่อจบงานจะส่ง summary กลับมา นี่คือเหตุผลเชิงกลไกว่าทำไม sub-agent ช่วย long session ได้ มันกันไม่ให้งานย่อยที่สกปรกหรือยาวมากมาทำให้โต๊ะหลักรก

ลองเปรียบเทียบกับออฟฟิศ คุณเป็นผู้จัดการที่กำลังเขียน memo สำคัญ ถ้าคุณต้องอ่าน invoice ทุกใบเอง โต๊ะคุณจะเต็มไปหมด แต่ถ้าคุณให้ทีมบัญชีไปตรวจ invoice แล้วส่งสรุปว่า "มี 3 รายการผิดปกติ" โต๊ะคุณยังโล่ง และคุณใช้ข้อมูลสำคัญได้ทันที

จุดที่การเปรียบเทียบนี้ใช้ไม่ได้คือ sub-agent ไม่ได้มีความเข้าใจถาวรแบบคนในทีม มันก็เป็น model อีก session หนึ่งที่ทำงานจาก context ของมันเอง ถ้าคุณส่งโจทย์ให้ sub-agent ไม่ครบ มันก็ไม่รู้สิ่งที่อยู่ในหัว main chat เพราะช่องทางจาก parent ไป sub-agent คือ prompt ที่ส่งไปเท่านั้น

แล้วทำไมไม่ spawn sub-agent ตลอดเวลา

ถ้า sub-agent ช่วยให้ context หลักไม่รก คำถามธรรมชาติคือ ทำไมไม่เรียก sub-agent ทุกงานไปเลย

คำตอบคือเพราะการแยกโต๊ะก็มีต้นทุน

ต้นทุนแรกคือการส่งต่อบริบท sub-agent ไม่ได้รับประวัติทั้งหมดของ parent โดยอัตโนมัติ มันได้เฉพาะ prompt ที่ถูกส่งไป พร้อมบริบทระดับโปรเจกต์บางอย่าง เช่น CLAUDE.md และ tool definitions ตามการตั้งค่า ถ้าคุณอยากให้มันรู้ decision สำคัญ คุณต้องเขียนให้ชัดใน prompt ที่ส่งไป ไม่อย่างนั้นมันอาจทำงานถูกส่วนแต่ผิดเจตนา

ต้นทุนที่สองคือการสูญเสียรายละเอียดตอนสรุปกลับ sub-agent อาจอ่านข้อมูล 50 หน้า แล้วส่งกลับมา 20 บรรทัด ถ้า 20 บรรทัดนั้นตัดรายละเอียดที่คุณต้องใช้ทิ้ง main chat ก็ไม่มีทางรู้ ยกเว้นคุณสั่งให้ sub-agent แนบหลักฐานหรือ quote สำคัญกลับมาด้วย

ต้นทุนที่สามคือการประสานงาน ถ้างานย่อยเล็กมาก เช่น "แก้คำผิดในย่อหน้านี้" การเรียก sub-agent อาจยุ่งเกินจำเป็น ทำเองใน main chat เร็วกว่า

ดังนั้นกฎใช้งานคือ ใช้ sub-agent เมื่องานย่อยจะสร้างข้อมูลดิบเยอะ แต่ผลที่คุณต้องการกลับมาสั้น เช่น research, code review, ไล่ log, ตรวจไฟล์จำนวนมาก, เปรียบเทียบเอกสารหลายชิ้น หรือให้หลายมุมมองตรวจงานเดียวกัน

ไม่ต้องใช้ sub-agent เมื่องานต้องอาศัยความต่อเนื่องละเอียดกับบทสนทนาหลัก หรือเมื่อข้อมูลที่ต้องส่งไปให้มันแทบเท่ากับ context หลักทั้งก้อน แบบนั้นแยกไปก็ไม่ได้ประหยัดอะไร

Auto vs manual: ใครเป็นคนเรียก sub-agent

ในเครื่องมือ agent บางระบบ model เลือกเรียก sub-agent เองได้เมื่อเห็นว่างานตรงกับคำอธิบายของ sub-agent นั้น นี่คือแบบ auto คุณไม่ต้องสั่งละเอียดทุกครั้ง แค่มี sub-agent ที่นิยามไว้ดี

อีกแบบคือ manual คุณสั่งตรง ๆ เช่น "ให้ sub-agent สาย technical review อ่านไฟล์นี้ แล้วส่งกลับเฉพาะ bug ที่มีหลักฐาน" แบบนี้เหมาะตอนคุณรู้ชัดว่าต้องการมุมมองไหน และอยากคุมขอบเขตให้แคบ

แบบ auto สะดวก แต่ต้องนิยาม description ของ sub-agent ให้ดี ไม่อย่างนั้น model อาจเรียกผิดงานหรือไม่เรียกตอนควรเรียก แบบ manual ช้ากว่าเล็กน้อย แต่ควบคุมเจตนาดีกว่า

Agent teams และ Agent SDK อยู่ตรงไหน

พอพูดถึง sub-agent จะเจอคำอีกสองคำคือ agent teams และ Agent SDK อย่าเพิ่งให้มันทำให้เรื่องใหญ่เกินจำเป็น

agent teams คือแนวคิดให้ agent หลายตัวทำงานพร้อมกันและสื่อสารกันได้โดยตรง เหมือนมีทีมย่อยหลายคน ไม่ใช่แค่ส่งผู้ช่วยหนึ่งคนไปทำงานแล้วกลับมาสรุป เหมาะกับ workflow ที่ซับซ้อนกว่า เช่นแยกคนหนึ่งทำ research คนหนึ่งทำ implementation คนหนึ่งทำ review แล้วประสานกัน

Agent SDK คือเครื่องมือสำหรับคนสร้างระบบ ที่เอา loop แบบ Claude Code ไปฝังในแอปของตัวเอง คุม tool, permission, งบ, model, output และ session ได้ระดับโปรแกรม ถ้าคุณเป็นผู้ใช้ทั่วไป แค่รู้ว่ามันคือทางที่นักพัฒนาสร้าง agent ของตัวเองก็พอ รายละเอียดเชิง builder จะไปอยู่ใน บทสาย builder

สิ่งที่เชื่อมทั้งหมดเข้าด้วยกันคือ context ทุก feature ที่เปิดเพิ่ม ไม่ว่าจะ sub-agent, skill, hook, MCP หรือ agent teams ล้วนมีผลต่อ context ไม่ทางตรงก็ทางอ้อม คำถามไม่ใช่ "เปิดให้เยอะที่สุดดีไหม" แต่คือ "อะไรจำเป็นต่องานนี้จริง ๆ"

ไฟล์ก็เป็น memory ได้ เพราะมันถูกอ่านเข้า context

ตอนใช้ agent ทำงานจริง คุณจะเจอไฟล์ชื่อแปลก ๆ เช่น CLAUDE.md, AGENTS.md, SKILL.md, โฟลเดอร์ .claude/ หรือไฟล์ memory ที่ระบบสร้างไว้ หลายคนรู้สึกเหมือนของพวกนี้เป็นเวทมนตร์ เป็นที่เก็บความจำลับของ AI

จริง ๆ แล้วมันธรรมดากว่านั้นมาก

ไฟล์พวกนี้คือข้อความ markdown ธรรมดา ที่ harness รู้ว่าควรโหลดเข้า context เมื่อถึงเวลา แค่นั้นเอง

CLAUDE.md มักใช้เก็บคำสั่งของโปรเจกต์ เช่น "ใช้ design system นี้" "เวลาตอบให้สั้น" "ก่อนแก้ UI ให้อ่านไฟล์ DESIGN.md" พอ Claude Code เริ่ม session หรืออ่านไฟล์ใน scope ที่เกี่ยวข้อง เนื้อหาเหล่านี้จะถูกใส่เข้า context ให้ model เห็น เหมือนคุณ paste brief ให้มัน แต่เป็นการ paste อัตโนมัติ

AGENTS.md ในบางโปรเจกต์ทำหน้าที่คล้ายกันสำหรับ coding agent อีกสายหนึ่ง เป็นไฟล์บอก agent ว่า repo นี้มี convention อะไร ต้อง test ยังไง ห้ามแตะอะไร ความคิดหลักเหมือนเดิม มันไม่ใช่ memory วิเศษ มันคือ brief ที่อยู่ในไฟล์

SKILL.md คือไฟล์คำสั่งของ skill บอกว่าเมื่อเจองานประเภทนี้ควรทำอย่างไร ใช้ไฟล์ไหน รัน script ไหน ระวังอะไร บางระบบโหลดแค่ description ตั้งแต่ต้น แล้วค่อยโหลดเนื้อหาเต็มเมื่อ skill ถูกใช้ เพื่อประหยัด context

โฟลเดอร์ .claude/ คือที่เก็บการตั้งค่า คำสั่ง rules หรือสิ่งที่เกี่ยวกับ Claude Code ในโปรเจกต์หรือเครื่องของคุณ ส่วน auto memory คือโน้ตที่ระบบเก็บไว้แล้วโหลดกลับเข้ามาตามกฎของมัน เอกสาร context-window ของ Claude Code ระบุว่า auto memory และ CLAUDE.md สามารถถูก re-inject หลัง compaction ได้ ถ้ายังอยู่บน disk

💡 ใจความสำคัญ: memory ที่ไว้ใจได้ที่สุดในงาน agent มักไม่ใช่ "ให้ AI จำไว้ในแชท" แต่คือเขียนสิ่งสำคัญลงไฟล์ แล้วให้ harness โหลดไฟล์นั้นเข้า context เมื่อจำเป็น

นี่คือเหตุผลที่คนใช้ agent จริงจังชอบเขียนไฟล์ handoff, decision log, project rules หรือ checklist แทนการหวังว่า AI จะจำจากบทสนทนายาว ๆ เพราะไฟล์อยู่กับที่ แก้ได้ ตรวจได้ และโหลดใหม่ได้ ส่วนบทสนทนาเก่าอาจถูก compact, ถูกสรุปผิด, หรือถูกฝังกลางกองจน model ใช้ไม่ดี

ลองทำดู: เขียน memory เป็นไฟล์แทนการฝากไว้ในแชท

ถ้าคุณทำโปรเจกต์ยาว ให้สร้างไฟล์สั้น ๆ ชื่อ project-brief.md หรือ handoff.md แล้วใส่ 5 อย่างนี้

1. เป้าหมายของงาน
2. decision ที่ตัดสินแล้ว
3. ข้อห้ามสำคัญ
4. ไฟล์หรือข้อมูลที่เกี่ยวข้อง
5. next step ล่าสุด

เวลาเปิดแชทใหม่ ให้แนบหรือ paste ไฟล์นี้ก่อนเริ่มงาน คุณจะได้ context ที่บางกว่าแชทเก่า แต่คุมสาระสำคัญได้ดีกว่า

Checkpoint กับ rewind: ตาข่ายกันตก ไม่ใช่ความจำ

อีก feature ที่ควรวางให้ถูกที่คือ checkpoint หรือ rewind

ใน Claude Code, checkpointing คือระบบที่ติดตามการแก้ไฟล์ของ Claude ระหว่างทำงาน เพื่อให้คุณย้อนกลับไปจุดก่อนหน้าได้ถ้างานเริ่มออกนอกทาง เอกสารระบุว่า prompt ของผู้ใช้แต่ละครั้งสร้าง checkpoint ใหม่ และ checkpoint อยู่ข้าม session ได้ภายใต้กฎการเก็บรักษาของระบบ

คิดง่าย ๆ ว่ามันเหมือน save point ในเกม ก่อน AI จะเดินเข้าเขาวงกตแก้ไฟล์เยอะ ๆ ระบบถ่ายรูปสถานะไว้ ถ้ามันเดินผิดทาง คุณย้อนกลับมาได้

แต่ checkpoint ไม่ได้แก้ปัญหา context โดยตรง มันไม่ได้ทำให้ model จำดีขึ้น ไม่ได้ทำให้แชทยาวคมขึ้น และไม่ได้ล้างกองเอกสารบนโต๊ะ มันเป็นตาข่ายกันตกด้านสถานะไฟล์และบทสนทนา ช่วยให้คุณกล้าลองงานใหญ่ขึ้น เพราะถ้าพังยังถอยได้

บางระบบมีทางเลือกอย่าง "summarize from here" เพื่อบีบช่วงบทสนทนาหลัง checkpoint ให้สั้นลง อันนี้แตะเรื่อง context เพราะช่วยคืนพื้นที่ แต่หลักคิดยังเหมือนเดิม การสรุปคือการบีบอัด มีโอกาสเสียรายละเอียด

เรื่อง permission และความปลอดภัยของการปล่อย agent แก้ไฟล์หรือรันคำสั่งจะอยู่ใน บทวิจารณญาณและความปลอดภัย ตรงนี้จำแค่ว่า checkpoint ช่วยให้ย้อนเมื่อหลุด แต่ไม่ควรใช้เป็นข้ออ้างให้ไม่ดูว่า AI กำลังทำอะไร

สรุป: ใช้ AI เก่งขึ้นคือจัดโต๊ะให้มันดีขึ้น

ถ้าบทก่อนหน้าคือ "ทุกครั้งที่กด Enter กองข้อความถูกส่งไปใหม่" บทนี้คือ "กองข้อความนั้นมีขนาดจำกัด และความรกของกองมีผลต่อคุณภาพ"

context คือทุกอย่างที่ model เห็นในงานนั้น context window คือขนาดพื้นที่ทำงานทั้งหมด ยิ่ง session ยาว ยิ่งอ่านไฟล์เยอะ ยิ่ง paste ข้อมูลมาก กองนี้ยิ่งหนา พอหนาขึ้นก็ช้าลง แพงขึ้น และเริ่มใช้ข้อมูลแย่ลง โดยเฉพาะข้อมูลที่จมอยู่กลางกองยาว ๆ งานวิจัย Lost in the Middle ทำให้เราไม่ต้องพูดเรื่องนี้แบบเดา ๆ อีกต่อไป มันวัดได้

วิธีใช้จริงจึงไม่ใช่ยัดทุกอย่างให้ AI จำ แต่คือจัด context อย่างตั้งใจ งานใหม่ให้เริ่มใหม่ งานเดิมที่ยาวให้ compact หรือทำ handoff ของสำคัญให้เขียนลงไฟล์ งานย่อยที่ข้อมูลดิบเยอะให้ส่ง sub-agent ไปทำใน context แยก และถ้าปล่อย agent แก้ไฟล์ ให้ใช้ checkpoint เป็นตาข่ายกันตก

พอคุณมอง AI แบบนี้ คุณจะเลิกถามว่า "ทำไมมันจำไม่ได้" แล้วเริ่มถามคำถามที่ดีกว่า "ตอนนี้ฉันวางอะไรบนโต๊ะให้มันเห็นบ้าง ของไหนจำเป็น ของไหนรก และของสำคัญอยู่ตรงไหนของกอง"

บทถัดไปจะต่อจากตรงนี้ในมุมที่เจ็บกระเป๋ากว่าเดิม เมื่อ context คือ token และ token คือเงิน เราจะดูว่า token หายไปตรงไหน ทำไมภาษาไทยทำให้ต้นทุนบานง่ายกว่า และจะลดความเปลืองโดยไม่ทำให้คุณภาพตกได้ยังไง

อ่านต่อ: Token optimization จัด context ให้คุ้ม ไม่ใช่แค่ให้สั้น

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