ทำไม USER.md และ MEMORY.md ไม่สามารถรวมกันได้

สรุป

USER.md และ MEMORY.md คือสมุดบันทึกส่วนตัวสองเล่มที่อยู่เบื้องหลังความทรงจําระยะยาวของ Hermes Agent และมีข้อจํากัดที่ชัดเจนสามประการที่อธิบายว่าทําไมจึงไม่สามารถรวมกันได้ประการแรก ความจุเป็นอิสระ (USER.md ประมาณ 1,375 ตัวอักษร / 500 โทเคน; MEMORY.md ประมาณ 2,200 ตัวอักษร / 800 โทเคน) ดังนั้นไม่มีอันไหนบีบอีกฝ่ายประการที่สอง ความหมายในการโหลดแตกต่างกัน: ทั้งสองโหลดในแต่ละเซสชัน แต่บทบาทของแต่ละอันแตกต่างกันโดยสิ้นเชิง — อันหนึ่งอธิบาย "คุณเป็นใครอย่างมั่นคง" อีกอันมักจะบันทึก "สิ่งที่เราทํา"อันดับสาม ความหมายการอัปเดตแตกต่างกัน: ฟิลด์การตั้งค่าใน USER.md ส่วนใหญ่จะเขียนทับค่าเก่า ในขณะที่ MEMORY.md มักจะเพิ่มและรวมตามความต้องการ การรวมกันเป็น NOTES.md เดียวจะทําให้ข้อจํากัดทั้งสามถูกทําลายพร้อมกัน — เป็นกรณีตัวอย่างที่ว่า "ดูเรียบง่ายแต่ทํางานแย่กว่า".**

คำถามที่ยุติธรรมสำหรับเริ่มต้น

ทั่วความทรงจำแบบชั้นของ Hermes, USER.md และ MEMORY.md รวมกันได้เพียง ~3,575 อักขระ / ~1,300 โทเค็น — ถือว่าควบคุมได้อย่างน่าทึ่งในยุคที่มีหน้าต่างบริบทหกหลัก

ดังนั้นปฏิกิริยาแรกของคนส่วนใหญ่คือสามคำถาม:

• ทำไมไม่รวมพวกมันเข้าเป็น NOTES.md เดียวล่ะ?
• ทำไมไม่ขยายขึ้นไปถึงหลายหมื่นไบต์ล่ะ?
• ทำไมสองไฟล์นี้ถึงมีเพดานต่างกัน (2,200 กับ 1,375) ด้วยล่ะ?

ทั้งสามชี้ไปที่คำตอบเดียวกัน: USER.md และ MEMORY.md เป็นหน่วยความจำสองประเภทที่แตกต่างกัน และการนำมารวมกันทำให้ทั้งสองแย่ลง ด้านล่างนี้ หลักการออกแบบนั้นจะถูกอธิบายออกเป็นสามชั้น

1. USER.md: โปรไฟล์ผู้ใช้ที่มั่นคงและมีโครงสร้าง

USER.md เป็น คำอธิบายที่มั่นคงของคุณ:

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

คุณลักษณะสำคัญของมัน:

• เสถียร: อัปเดตทุก ๆ ไม่กี่วันหรือไม่กี่สัปดาห์
• มีโครงสร้าง: แบ่งเป็นส่วน ๆ, ระบุรายการ, อิงตามฟิลด์
• โหลดอยู่เสมอ: ถูกฉีดเข้าไปในพรอมต์ของระบบเมื่อเริ่มแต่ละเซสชัน
• เพดานสูงสุด: ประมาณ 1,375 ตัวอักษร / ประมาณ 500 โทเคน

คิดว่า USER.md เป็น โพสต์-อิทบนขอบหน้าจอของเอเจนต์ — มีข้อความไม่มาก แต่เห็นอยู่เสมอและมีประโยชน์เสมอ

2. MEMORY.md: แหล่งเก็บข้อเท็จจริงที่เติบโตและมีให้ตามต้องการ

MEMORY.md เก็บ สิ่งที่คุณและเอเจนต์ได้ทำร่วมกัน:

• สถานะโครงการ: ส่วนหน้าของ agent-demo ทำงานบนพอร์ต dev ภายในเครื่อง
• การตัดสินใจ: สัปดาห์ที่แล้ว ส่วน hero ถูกเปลี่ยนเป็นกราฟิกไล่สีแบบเคลื่อนไหว
• เหตุการณ์เฉพาะ: ตกลงกับทีม A ว่า X จะถูกส่งในไตรมาส 4
• ความรู้เฉพาะ: สิ่งนี้ API ทำการยืนยันตัวตนผ่าน SDK ภายในแทนการใช้จุดเข้าของสาธารณะ

คุณลักษณะสำคัญของมัน:

• ไดนามิก: เกือบทุกเซสชันที่มีเนื้อหาสำคัญจะเขียนหนึ่งหรือสองรายการ
• แยกรายการ: เพิ่มทีละรายการเพื่อให้ง่ายต่อการเรียกคืน
• โหลดเสมอพร้อมการจับคู่ FTS5 ตามต้องการ: รายการทั่วไปจะโหลดทุกเซสชัน รายการประวัติศาสตร์จะถูกดึงโดยการจับคู่ FTS5
• โดยทั่วไป 8–15 รายการ: เป้าหมายคือ 8–15 รายการ รวมประมาณ ~2,200 ตัวอักษร / ~800 โทเค็น

คิดถึง MEMORY.md เป็น สมุดบันทึกบนโต๊ะของคุณ — มากกว่ากระดาษโน้ต แต่ยังเขียนอย่างประหยัดเพื่อให้สามารถอ่านผ่านได้อย่างรวดเร็ว

3. "ทำไมไม่รวมพวกมันเป็น NOTES.md ไฟล์เดียว?" — สามข้อจำกัดที่เข้มงวด

จะมีคนถามอยู่เสมอ: ทั้งคู่เป็น Markdown ที่ถูกโหลดในทุกเซสชัน ดังนั้นทำไมไม่รวมพวกมันเข้าด้วยกันล่ะ?

นี่คือข้อจำกัดที่เข้มงวดสามข้อ แต่ละข้อแข็งแรงพอที่จะทำให้แนวคิดล้มเหลวได้

ข้อจำกัด 1: ความสามารถอิสระ ไม่บีบกันและกัน

USER.md ได้รับ 500 โทเค็น, MEMORY.md ได้รับ 800. หลังจากรวมกัน, NOTES.md ขนาด 1,300 โทเค็นเพียงตัวเดียวก็เจอปัญหา: เมื่อหน่วยความจำใกล้เต็ม, เอเจนต์จะลบบรรทัดเกี่ยวกับ "ผู้ใช้คือใคร" เพื่อบันทึกเหตุการณ์อีกหนึ่งเหตุการณ์หรือไม่?

อย่างชัดเจน มัน ไม่ควร — แต่เมื่อรวมกันแล้ว การตัดสินใจนั้นต้องถูกตัดสิน และตัดสิน ทุกครั้งที่มีการเขียน หากเก็บแยกกัน สองกลุ่มนี้จะพัฒนาไปอย่างอิสระ: เมื่อ MEMORY.md เต็ม มันจะบีบตัวเองเท่านั้นและไม่เคยทำให้โปรไฟล์ปนเปื้อน

ข้อจำกัด 2: พฤติกรรมการโหลดที่แตกต่างกัน

ทั้งสองไฟล์ถูก โหลดในทุกเซสชัน จริง ๆ แต่บทบาทของพวกมันในพรอมต์ของระบบแตกต่างกันโดยสิ้นเชิง:

• ส่วน USER.md ตอบคำถาม "คุณกำลังรับมือกับใคร" กำหนดโทนของเอเจนต์ ระดับรายละเอียด และสมมติฐานเกี่ยวกับสแตก
• ส่วน MEMORY.md ตอบคำถาม "คุณทำอะไรด้วยกันมาแล้วบ้าง" ให้เอเจนต์มีข้อมูลเชิงข้อเท็จจริง

หากรวมกัน ทั้งสองจะ เจือจางซึ่งกันและกัน — เอเจนต์จะไม่สามารถบอกได้อย่างรวดเร็วอีกต่อไปว่า “นี่คือสไตล์การสื่อสารที่ฉันต้องปฏิบัติตาม หรือเป็นข้อเท็จจริงในอดีตที่ฉันควรอ้าง?”

ข้อจำกัด 3: พฤติกรรมการอัปเดตที่แตกต่างกัน

• ฟิลด์การตั้งค่าใน USER.md ส่วนใหญ่จะเขียนทับ: เมื่อผู้ใช้บอกว่า "หยุดสรุปตั้งแต่ตอนนี้" บรรทัดการตั้งค่าที่เกี่ยวข้องจะถูกเขียนทับโดยตรง
• MEMORY.md ส่วนใหญ่จะต่อท้ายและรวบรวมตามต้องการ: เหตุการณ์เป็นลำดับเหตุการณ์ตามเวลา ดังนั้นประวัติไม่สามารถลบออกได้โดยง่าย เมื่อความจุเต็ม การตอบข้อผิดพลาดต่อไปนี้จะกระตุ้นการรวบรวมอย่างกระตือรือร้น:

{
  "success": false,
  "error": "Memory at 2,100/2,200 chars. Consolidate now...",
  "current_entries": [...],
  "usage": "2,100/2,200"
}

หลังจากการรวม add / replace / remove ทั้งหมดจะต้องอยู่ร่วมกันในไฟล์เดียว ซึ่งทำให้ทั้งการดำเนินการและแบบจำลองทางจิตของผู้ใช้แย่ลง พร้อมกัน

4. ตัวอย่างที่ชัดเจน

สมมติว่าคุณบอกเอเจนต์:

"ฉันชื่อจัสมิน เป็นวิศวกรด้าน frontend และฉันชอบการสื่อสารแบบสรุปก่อน ฉันกำลังทำงานในเว็บไซต์ระดับโลกสำหรับ agent-demo (แอป AI agent) ด้วย Next.js เมื่อสัปดาห์ที่แล้วเราปรับส่วน hero ให้เป็นกราฟิกเคลื่อนไหวแบบไล่สี"

เอเจนต์ Hermes ที่ผ่านการฝึกอบรมมาอย่างดีจะแบ่งสิ่งนั้นออกดังนี้:

เขียนถึง USER.md:

## Identity
- Name: Jasmin
- Role: Frontend engineer

## Preferences
- Communication style: conclusion first
- Usual stack: Next.js

เขียนถึง MEMORY.md:

- [2026-07-30] agent-demo: hero section on the global site changed to an animated gradient.
- Related project: agent-demo / global site (global region)

เห็นความแตกต่างหรือไม่?

• “คุณเป็นคนแบบไหน” ใส่ลงในโปรไฟล์; “สิ่งที่เราเคยทำด้วยกัน” ใส่ลงในคลังข้อมูล
• ข้อแรกจะเปลี่ยนก็ต่อเมื่อ คุณ เปลี่ยน (งานใหม่ ทีมใหม่); ข้อหลังจะเติบโตขึ้นกับ ทุกวันที่สนทนา
• การแยกไฟล์คือสิ่งที่ทำให้แต่ละอย่างพัฒนาได้ด้วยตัวเอง

5. รายการข้ามห้ารายการ

Hermes ไม่ผลักทุกอย่างเข้าไปใน USER.md มันเก็บ รายการข้าม:

1. อารมณ์ชั่วครั้งชั่วคราว: "วันนี้หัวฉันเจ็บ" — ไม่ใช่ลักษณะคงที่
2. พารามิเตอร์งานชั่วคราว: "เปลี่ยนหัวข้อนี้เป็น X ให้ฉันหน่อย" — ใช้ครั้งเดียว
3. ทัศนคติไม่ชัดเจน: "ฉันคิดว่าฉันชอบสิ่งที่กระชับมากขึ้นหน่อย" — ไม่สามารถนำกลับมาใช้ได้มากพอ (ต้องปรับคุณสมบัติหรือข้ามไป)
4. สิ่งใดก็ตามที่สามารถคาดเดาได้จากบริบทการสนทนาสด — ไม่จำเป็นต้องเก็บ
5. ข้อมูลที่ละเอียดอ่อน (อีเมล รหัสผ่าน ที่อยู่ที่ผู้ใช้ไม่ได้ยืนยันโดยตรง) — ข้อมูลเกี่ยวกับความเป็นส่วนตัวโดยปกติจะไม่ถูกบันทึก

รายการข้ามนั้นคือสิ่งที่ทำให้ USER.md อยู่ที่ "500 โทเค็นและความหนาแน่นสูง"

6. สิ่งนี้หมายถึงอะไรสำหรับผลิตภัณฑ์

สำหรับผลิตภัณฑ์ของเอเจนต์ การแบ่งระหว่าง USER.md และ MEMORY.md ไม่ใช่เพียงรายละเอียดทางวิศวกรรม มันกำหนดสามสิ่ง:

1. คุณสามารถแสดงให้ผู้ใช้เห็น "สิ่งที่ฉันคิดเกี่ยวกับคุณ" ได้หรือไม่ — นั่นต้องการโปรไฟล์ที่เสถียร อ่านได้ และแก้ไขได้ (ความหมายของ USER.md)
2. เอเจนต์สามารถหลีกเลี่ยงการลืมในระยะยาวได้หรือไม่ — นั่นต้องการคลังข้อเท็จจริงที่เติบโตและสามารถเรียกคืนได้ (ความหมายของ MEMORY.md)
3. ต้นทุนยังคงถูกจำกัดหรือไม่ — มีเพียงการโหลดแบบหลายชั้นเท่านั้นที่สามารถ "รู้ว่าคุณคือใคร" และหลีกเลี่ยงการใช้บริบททั้งหมดจนหมดได้

7. LightVela: การเปลี่ยนสมุดบัญชีสองเล่มนี้ให้กลายเป็นผลิตภัณฑ์

การออกแบบหน่วยความจำของเอเจนต์ภายในของ LightVela ยืมแนวคิดแบบเป็นชั้นนี้อย่างตรงไปตรงมา Hermes' USER.md และ MEMORY.md เป็นไฟล์ Markdown ที่เขียนขึ้นสำหรับนักพัฒนา; LightVela แปลงไฟล์เหล่านี้เป็นสองสิ่งที่ผู้ใช้ทั่วไปสามารถใช้งานได้โดยตรง:

• เลเยอร์โปรไฟล์ที่มองเห็นได้: ผู้ใช้สามารถดูได้ว่าเอเจนต์จำข้อเท็จจริงในโปรไฟล์ใดบ้างและมาจากการสนทนาใด และสามารถแก้ไขได้เพียงคลิกเดียว โปรไฟล์ไม่ใช่กล่องดำอีกต่อไป USER.md
• เลเยอร์ข้อเท็จจริงที่จัดระเบียบได้: ความจำเชิงข้อเท็จจริงไม่ใช่เพียงกองของรายการ — สามารถติดแท็กตามโปรเจกต์ งาน หรือเวลาเพื่อให้จำและทำความสะอาดได้ง่ายขึ้น ในสถานการณ์ทีม ความจำของทีมและความจำส่วนตัวสามารถจัดการเป็นเลเยอร์แยกได้
• เส้นทางที่สั้นที่สุด: หากไอเดียเลเยอร์ความจำดึงดูดคุณ แต่คุณไม่อยากแก้ไข ~/.hermes/USER.md, ดูแล FTS5 และสำรอง SQLite ด้วยตัวเอง LightVela คือเส้นทางที่สั้นที่สุดสู่ไอเดียนั้นในรูปแบบผลิตภัณฑ์สำเร็จ

ในหนึ่งบรรทัด: Hermes ให้แผนผังวิศวกรรมสำหรับหน่วยความจำแบบหลายชั้น และ LightVela เปลี่ยนมันให้เป็นประสบการณ์ผลิตภัณฑ์ที่ใคร ๆ ก็สามารถใช้ได้.

ข้อสรุปสำคัญ

• USER.md: โปรไฟล์ผู้ใช้ ที่มั่นคงและมีโครงสร้าง ถูกโหลดทุกครั้งที่เปิดใช้งาน (~500 โทเค็น, 8–15 ช่องข้อมูลโปรไฟล์).
• MEMORY.md: คลังข้อเท็จจริง ที่เติบโตและใช้ตามความต้องการ (~800 โทเค็น, 8–15 รายการเหตุการณ์).
• มีข้อจำกัดสามประการที่ทำให้ทั้งสองแยกจากกัน: ความจุอิสระ / วิธีโหลดที่ต่างกัน / วิธีอัปเดตที่ต่างกัน.
• การวางชั้นเป็นความสามารถพื้นฐานสำหรับความจำที่ดีของเอเจนต์ และเป็นจุดเริ่มต้นสำหรับการทำให้ความจำเป็นผลิตภัณฑ์ที่ LightVela.