เห็นหน่วยความจำสำหรับ agent ตัวใหม่เปิดตัวมาอย่างน่าดึงดูด คำถามแรกไม่ควรถามว่ามันจำอะไรได้บ้าง แต่ควรถามว่ามันฝากหน่วยความจำของเราไว้ให้ได้อย่างปลอดภัยหรือไม่ และถ้ามันพังขึ้นมา ระบบของเราจะหยุดตามไปด้วยไหม เราใช้กรอบนี้ลองตรวจ Hy-Memory จาก Tencent Hunyuan ว่าสมควรนำมาเป็น memory backend ให้ Hermes agent หรือไม่ และหยิบส่วนที่ดีของมันกลับมาโดยไม่ต้องเอาร่างทั้งหมดมาใช้ได้แค่ไหน
บทความนี้สรุปจากบทวิเคราะห์การอ่านโค้ดต้นฉบับของทีมเรา ซึ่งบันทึกไว้ที่ Issue #5 ของ muse101 โดยใช้ upstream Hy-Memory จาก Tencent-Hunyuan เป็นหลักควบคู่กัน ตัวเลขประสิทธิภาพหลายตัวที่กล่าวถึงข้างล่างเป็นการรันของผู้พัฒนาเองและยังไม่มีการตรวจสอบอิสระ โปรดอ่านตามนั้น
สรุปสำหรับผู้บริหาร
- คำตัดสิน: Skip ก่อน ยังไม่ใช้ Hy-Memory เป็น memory backend ให้ Hermes
- เพราะหน่วยความจำเป็น state อายุยาวที่สะสมมูลค่า แต่โค้ดยังอ่อน มีบั๊กทำให้ store เสียหาย และทุกเทิร์นโดนล่ามไว้กับมัน
- ของเดิมใน Hermes (MEMORY.md, USER.md ที่ดูแลคุณภาพเอง พร้อม FTS5) แข็งแรงกว่าในมิติ governance และไม่เสี่ยงต่อความล้มเหลวแบบ chain-fail
- สิ่งที่หยิบไปใช้ได้ทันทีคือ working/coding capture, supersedes chain และ git diff chain
- กลับมาดูใหม่อีกครั้งเมื่อมีปลั๊กอิน Hermes แบบ source-available ที่รองรับ SDK 2.0.2, repo มีประวัติแก้บั๊กต่อเนื่อง และ prefetch พิสูจน์ได้ว่าไม่ค้าง
Hy-Memory คืออะไร
Hy-Memory คือ SDK หน่วยความจำ Python (Apache-2.0) ที่ออกแบบมาเก็บสารสนเทศสำหรับ agent แบบแบ่งฉาก (scene) เป็นสามกลุ่มผ่านตัวจัดเส้นทาง ฉาก chat เก็บข้อมูลการสนทนาตามโครงชั้น L0 ถึง L7 (โปรไฟล์ ข้อความดิบแบบ append-only ข้อเท็จจริงย่อยพร้อมเวอร์ชันและห่วงโซ่ supersedes บทสรุป กราฟความรู้ และเจตนาที่มีวันหมดอายุ) ฉาก working เก็บ WorkingFact ต่อเซสชันพร้อม Experience ที่ผ่านเกณฑ์คุณค่า และฉาก coding เก็บข้อเท็จจริงของงานโค้ดพร้อม version-evolution chain จาก git diff จริงโดยไม่ต้องเรียก LLM เลย ข้อมูลเก็บอยู่ในเครื่องที่ ~/.hy_memory ทั้งนั้น มีสามโหมดจากเบาไปหนักคือ lite (embedding-only ไม่เรียก LLM), pro (แยกแยะด้วย LLM และ reconcile โดยค่าเริ่มต้น) และ ultra (แถมตัว graph เสมอและมีการสร้าง schema ผ่าน client.evolve())
จุดที่ควรตั้งใจอ่านแทนโฆษณาคือค่าเริ่มต้นจริง: การค้นคืนแบบดีฟอลต์คือ vector ล้วน ถ้าจะมี keyword (hybrid) ให้พึ่ง Qdrant มิฉะนั้นจะพังลงเป็น vector อย่างเดียว ตัว reranker แบบ cross-encoder ปิดอยู่โดยค่าเริ่มต้น episode summary และกลไก recall decay ก็ปิดอยู่เช่นกัน และไม่มีกลไกลลืมข้อมูลอัตโนมัติทั่วไป มีเฉพาะ reconcile กับ supersede และการลบแบบสั่งตรงเท่านั้น มากกว่านั้น ระบบนี้ต้องใช้ LLM endpoint และ embedding endpoint ของตัวเองซึ่งโดยค่าเริ่มต้นชี้ไปผู้ให้บริการคลาวด์ ถ้าตั้งค่าไม่ครบ เนื้อหางาน ops อย่าง hostname โครงสร้างพื้นฐาน และผลจาก tool จะไหลออกไปยังภายนอกเงียบ ๆ แม้ตัวเซิร์ฟเวอร์ REST ของมันที่รันบน loopback จะไม่มีกลไกยืนยันตัวตนและเปิด CORS แบบ * โดยอาศัย loopback เป็นเกราะเดียวก็ตาม
โฆษณา vs ค่าเริ่มต้นจริง
| หัวข้อ | โฆษณา / ความประทับใจ | ค่าเริ่มต้นจริงหรือข้อจำกัด |
|---|---|---|
| Retrieval | ค้นแบบผสม hybrid | vector อย่างเดียวบน Chroma; hybrid จริงต้อง Qdrant |
| Reranking | อ่านลึกขึ้น | ปิดอยู่โดยค่าเริ่มต้น (cross-encoder off) |
| Janitor/forgetting | มี memory decay | Episode summary และ decay ปิดอยู่; ไม่มี auto-forgetting ทั่วไป |
| Benchmark วัตถุดิบ | LongMemEval ชนะเด่น | ตัวเลขผู้พัฒนารันเอง: ชนะบน backbone หนึ่ง แพ้บนอีกตัวหนึ่ง |
| ต้นทุนการรัน | เบาและเร็ว | Pro mode ~1–3 LLM calls ต่อเทิร์นที่บันทึก ตลอดไป |
จุดเรียนรู้ที่สำคัญจากหน่วยความจำนี้คือแยกสถาปัตยกรรมที่น่าสนใจออกจากการดูแลที่ยังไม่ตกผลึกเป็นซอฟต์แวร์การผลิต repo เพิ่งเปิดสาธารณะไม่นาน ประวัติถูก squash เหลือเพียงไม่กี่ commits และยังคงเปิดตัวเรื่องที่อาการรุนแรงอยู่ ถึงขนาดแยกตัวเก็บข้อมูลให้พังหลังบันทึกไม่สำเร็จ จะฝาก memory ที่สะสมมูลค่าวันต่อวันไว้กับโค้ดชุดใหม่แบบนี้ยังเป็นความเสี่ยงที่รับไม่ได้
ทำไมของที่มีอยู่ไม่ใช่แค่ "พอใช้ได้"
ฝั่ง Hermes ในปัจจุบันมีกลไกที่ตรงประเด็นมากกว่าเรื่องนี้ ไฟล์ MEMORY.md และ USER.md ให้พื้นที่ดูแล (curation) ถูกต้อง ทำงานตัวแทนด้วย frozen snapshot ทันที ที่เริ่ม session โดยที่ไม่ต้องรอเรียก LLM เป็นจำนวนมาก ส่วน session_search ทำงานผ่าน SQLite FTS5 ในเวลาหลักสิบมิลลิวินาทีและไม่ติด LLM calls และทุกการเขียนรวมถึงกระบวนการ self-improvement ต้องผ่าน write_approval ก่อนเสมอ โมเดลนี้ทำให้หน่วยความจำเป็น "บันทึกที่มนุษย์เห็นชอบ" ไมใช่ "การแคปเจอร์อัตโนมัติที่ไม่รู้ว่าเก็บอะไรไว้บ้าง" อันนี้เองที่เป็นข้อได้เปรียบที่สุดเมื่อเทียบกับ passive auto-capture ที่ส่ง inbox โดยตรงโดยไม่มีจุดตรวจ ซึ่งในงานจริงที่เราทำกันวันนี้มีข้อมูลรันระบบสำคัญแฝงอยู่ใน tool output ตลอดเวลา การรั่วออกไปถือเป็นความเสี่ยงที่ไม่มีใครคิดถี่ถ่วง
อีกเรื่องคือความต่อเนื่องของระบบ Hy-Memory จะฝังตัวแทนอ่านความจำ (prefetch) ให้เป็นส่วนหนึ่งของเทิร์นเลยและ timeout เกี่ยวกับลูกโซ่โดยฝั่ง ตัวแทนรอง เคยมีเคสจริงที่ระบบล่มลงเงียบ ๆ หลังใช้งานไปชั่วโมงหนึ่งและเงียบไว้สองนาทีทุกเทิร์นจนกว่าจะ kill เอง ถ้า memory ทำตัวเป็นบังคับผ่านก่อนเริ่มงาน การล้มของ memory หมายความว่า agent ล้มตามทันที ขณะที่ Hermes ยังใช้ค้นหาฐานข้อมูลพื้นฐานได้ แม้ผู้ให้บริการภายนอกจะล้มก็ตาม และสำหรับปลั๊กอินที่ Tencent ประกาศ เวอร์ชันปัจจุบันยังผูกกับ SDK 1.x รุ่นเก่า ไม่รองรับ 2.0.2 การใช้ตอนนี้จึงเป็นได้เพียง prototype เฉพาะทางภายใต้ความเสี่ยงและงานเชื่อมต่อที่ต้องใช้เวลาเป็นสัปดาห์
สองกลไกควรหยิบไปใช้เลย
ถ้ายกความเห็นดังกล่าวออกไป มีสองกลไกที่เราปรับไปใช้ทันที อย่างแรกคือ pattern working/coding capture: แต่ละ session ที่ทำงานควรมีบันทึกข้อเท็จจริงหลักหนึ่งชิ้น พร้อมคัดประสบการณ์ที่มีคุณค่าเท่านั้น ในงาน ops/infra ของเราแบบนี้จะกลายเป็นบันทึกติดตามว่างานใด เซสชันใด ทำอะไรไปบ้าง และเรียนรู้อะไรในแต่ละรอบ ตัวอย่างที่สองคือ supersedes chain: ข้อเท็จจริงแบบตีเวอร์ชันและระบุว่าข้อใดแทนข้อใด ใช้ได้เลยสำหรับบันทึกหรือ claim ที่ถูกแทนที่ ปิดท้ายด้วย git diff version chain ที่ติดตามการเปลี่ยนแปลงของโค้ด ทุกตัวของทั้งสามอย่างนี้สามารถทำได้เลยในระบบบันทึกของเราโดยไม่ต้องเปลี่ยน memory backend
สรุปชวนใช้
ข้อสรุปที่เราได้คืออย่าตัดสินจากข้อมูลสถาปัตยกรรมอย่างเดียว ให้ถามก่อนเสมอว่า "ถ้ามันค้าง agent จะหยุดตามไปด้วยหรือไม่" และ "ถ้าเก็บอะไรไว้ ใครเป็นคนอนุมัติ" Hy-Memory มีไอเดียแยกฉากที่ดี แต่ยังไม่พร้อมเป็นหลังบ้านให้งานจริงของเรา ทีมที่กำลังชั่งใจควรหยิบบทเรียนสามเรื่องด้านบนไปปรับใช้ก่อน ส่วนกลไกบันทึกเชิงรับ (passive) ให้หยุดไว้สำหรับงานที่ยังขาดตัวกรองในตอนนี้ เมื่อครบเงื่อนไขกลับมาประเมินใหม่สามข้อ — มีปลั๊กอิน Hermes แบบ source-available ที่รองรับ SDK ตัวปัจจุบัน ทาง repo มีประวัติแก้บั๊กอย่างต่อเนื่องเป็นเวลา 4–8 สัปดาห์ และพิสูจน์ได้ว่า prefetch ไม่ค้างทั้งเทิร์น — เราจะกลับมาดูอีกครั้งด้วยเหตุผลที่เพียงพอ ไม่ใช่เพราะไล่ตามรุ่นที่เพิ่งออก
ขอบคุณทีม Tencent Hunyuan สำหรับงานต้นแบบแบบสิ้นเชิงใน repo Hy-Memory และรายงานประเมินฉบับเต็มจาก muse101 Issue #5 ที่เป็นแหล่งหลักให้บทความนี้