EP05: Memory: ทำไม AI Coworker ต้องจำงานได้ [Hermes Agent 101]

Memory: ทำไม AI Coworker ต้องจำงานได้

Hook: AI ที่จำไม่ได้ คือ intern ที่ต้อง onboard ใหม่ทุกเช้า

ลองนึกภาพนี้: คุณจ้าง intern คนใหม่เข้ามาช่วยงาน วันแรกคุณอธิบายทุกอย่างให้ฟัง ชื่อบริษัท สินค้า กลุ่มลูกค้า style การเขียน งานที่ทำ intern เก่งมาก ทำงานได้ดี

แต่วันรุ่งขึ้น intern คนเดิมมาถึงบริษัท แล้วพูดว่า “สวัสดีครับ ผมมาเริ่มงานวันแรกวันนี้เลยครับ คุณช่วย onboard ผมใหม่ได้ไหมครับ”

ถ้าเป็นแบบนี้ทุกวัน คุณจะรู้สึกยังไง?

นั่นคือประสบการณ์ที่หลายคนเจอกับ AI chatbot ทั่วไป รวมถึง ChatGPT เวอร์ชันธรรมดา ทุก session เริ่มต้นใหม่จากศูนย์ บริบทหายหมด ต้องพิมพ์บริบทใหม่ซ้ำทุกครั้ง

Hermes Agent แก้ปัญหานี้ด้วย Memory System

Memory System ของ Hermes ทำงานอย่างไร

ไฟล์ความจำ 2 ไฟล์

Hermes เก็บความจำไว้ใน 2 markdown file ภายใต้ ~/.hermes/memories/:

MEMORY.md (ขีดจำกัด 2,200 ตัวอักษร ประมาณ 800 tokens)

  • บันทึกข้อมูลที่ agent ต้องรู้เกี่ยวกับ environment และงาน
  • เช่น: โครงสร้าง project, convention ของโค้ด, คำสั่ง deploy, ข้อผิดพลาดที่ต้องหลีกเลี่ยง, งานที่เสร็จแล้ว

USER.md (ขีดจำกัด 1,375 ตัวอักษร ประมาณ 500 tokens)

  • บันทึกข้อมูลเกี่ยวกับคุณในฐานะ user
  • เช่น: ชื่อ เวลาทำงาน timezone, style การสื่อสาร, สิ่งที่ชอบและไม่ชอบ, วิธีทำงาน

ทั้งสองไฟล์ถูก inject เข้า system prompt ตั้งแต่เริ่ม session ทุกครั้ง โดยอัตโนมัติ Hermes จึงรู้จักคุณและ context งานของคุณโดยไม่ต้องพิมพ์ซ้ำ

Frozen Snapshot Pattern

รายละเอียดเล็กน้อยที่น่ารู้: การแก้ไข memory ระหว่าง session จะ save ลงไฟล์ทันที แต่จะปรากฏใน prompt ครั้งถัดไปที่เปิด session ใหม่ ไม่ใช่ทันทีในการสนทนาเดียวกัน

เหตุผลคือ efficiency: pattern นี้รักษา LLM prefix cache ไว้ทำให้ inference เร็วและประหยัดกว่า

ควรจำอะไร ควรข้ามอะไร

สิ่งที่ควรบันทึก (Hermes ทำเองเมื่อเรียนรู้หรือคุณบอก)

ประเภท ตัวอย่าง เก็บใน
User preferences “ผมชอบ TypeScript ไม่ชอบ JavaScript” USER.md
Environment facts “server นี้รัน Debian 12 กับ PostgreSQL 16” MEMORY.md
การแก้ไขสำคัญ “อย่าใช้ sudo กับ Docker” MEMORY.md
Convention ของ project style โค้ด, คำสั่ง test, flow deploy MEMORY.md
งานที่เสร็จแล้ว “migrate DB จาก MySQL เสร็จ 15 ม.ค.” MEMORY.md
คำขอพิเศษ “จำด้วยว่า API key หมุนเปลี่ยนทุกเดือน” MEMORY.md

สิ่งที่ควรข้าม

  • ข้อมูลทั่วไปที่ค้นหาใหม่ได้ง่าย (เช่น feature ของ library รุ่นนั้น)
  • Raw data ขนาดใหญ่ (log เต็ม ๆ, code block ยาว ๆ, ตาราง raw data)
  • เหตุการณ์ที่ไม่ได้ใช้ซ้ำ (debug context เฉพาะครั้ง, path ชั่วคราว)
  • สิ่งที่อยู่ใน AGENTS.md, SOUL.md, หรือ project docs อยู่แล้ว

Memory Tool: add / replace / remove

Hermes จัดการ memory ผ่าน tool 3 action:

  • add: บันทึกข้อมูลใหม่
  • replace: แทนที่ entry เดิมด้วย substring ที่ unique
  • remove: ลบ entry ด้วย substring ที่ unique

ไม่มี read action เพราะ memory อยู่ใน prompt อยู่แล้วตั้งแต่เริ่ม session

Capacity Management: bounded by design

ขีดจำกัดที่ตั้งใจ

Store ขีดจำกัด จำนวน entry ทั่วไป
MEMORY.md 2,200 chars 8-15 entries
USER.md 1,375 chars 5-10 entries

เหตุผลที่ bounded memory ดีกว่า unlimited:

  1. Prompt ไม่บวม: inference เร็วและถูกกว่าเมื่อ context กระชับ
  2. บังคับให้คิดว่าอะไรสำคัญจริง ๆ: ไม่ใช่ dump ทุกอย่าง
  3. ตรวจสอบได้ง่าย: เปิดไฟล์ดูได้เลยว่า Hermes จำอะไร
  4. แก้ไขได้ง่าย: ถ้าจำผิดก็ replace ออกได้เลย

เมื่อ memory ใกล้เต็ม (เกิน 80%) best practice คือ consolidate entries ที่เกี่ยวกันก่อน แล้วค่อย add ใหม่

Session Search: Deep Recall On-Demand

นอกจาก compact memory ยังมี Session Search

Hermes เก็บประวัติ session ทั้งหมดใน SQLite database พร้อม FTS5 full-text search เรียกใช้ได้ผ่าน session_search tool เมื่อต้องค้นหาข้อมูลจาก session ก่อนหน้า

ความต่างจาก compact memory:

| | Compact Memory | Session Search | |–|—————-|—————-| | เมื่อใช้งาน | อัตโนมัติทุก session | on-demand เมื่อขอ | | ใช้สำหรับ | high-leverage facts ที่ต้องรู้ทุกวัน | deep recall จาก session ที่ผ่านมา | | ขนาด | เล็ก จำกัด | ทุก session ที่ผ่านมา |

Optional: External Memory Providers

สำหรับคนที่ต้องการ memory แบบ semantic/richer ยิ่งขึ้น Hermes รองรับ external memory provider 8 ตัว:

Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory

เปิดใช้ได้ทีละตัว และ additive กับ built-in memory (ไม่แทนที่)

ตัวอย่างจริง: เจ้าของธุรกิจ SME

สมมุติว่าคุณเปิดร้านออนไลน์ขายสินค้าออร์แกนิก และใช้ Hermes ช่วย content ทุกวัน

Session แรก: คุณอธิบาย Hermes ว่า ธุรกิจขายสินค้าออร์แกนิก target แม่บ้านอายุ 30-45 tone ต้องเป็นกันเอง ชอบ emoji ไม่ชอบ jargon ภาษาอังกฤษ

Hermes บันทึกลง MEMORY.md และ USER.md โดยอัตโนมัติ

ทุก session ถัดมา: คุณพิมพ์แค่ “ช่วยร่าง caption Instagram สำหรับสินค้าใหม่หน่อย” Hermes รู้ทันทีว่าต้องเขียนสไตล์ไหน กลุ่มเป้าหมายคือใคร อะไรที่คุณไม่ชอบ

ไม่ต้องพิมพ์ context ซ้ำอีก

ระบบ Memory คือรากฐานของ AI Coworker จริง

Memory ใน Hermes ไม่ใช่ feature เสริม แต่คือความต่างระหว่าง chatbot กับ coworker

Chatbot: เริ่มใหม่ทุกครั้ง ทำงานได้แต่ไม่มี context

AI Coworker: เติบโตไปพร้อมคุณ จำ preference จำ project จำสิ่งที่ไม่ควรทำ และเรียนรู้ style การทำงานของคุณไปเรื่อย ๆ

ซีรีส์ Hermes Agent 101 ยังมีต่อ ตอนหน้าเราจะพูดถึง Skills วิธีเปลี่ยนประสบการณ์ที่สะสมให้กลายเป็นความสามารถถาวรของ agent

EP05 จากซีรีส์ Hermes Agent 101: จาก Chatbot สู่ AI Coworker ที่ทำงานจริง

OPB Stack tie-in: Memory คือ business context ไม่ใช่แค่ประวัติแชต

ICP ที่เหมาะกับ OPB Stack คือคนที่มีงานจริงแล้ว และใช้ AI อยู่แล้ว แต่ยังติดปัญหาว่า “ต้อง brief ใหม่ทุกครั้ง” หรือ “AI จำระบบงานเราไม่ได้”

ในมุมนี้ memory ของ Hermes ไม่ใช่ฟีเจอร์สวย ๆ แต่คือชั้นที่ทำให้ AI coworker จำบริบทธุรกิจได้ เช่น ลูกค้าหลักคือใคร สินค้าขายอะไร ราคาเท่าไร โทนแบรนด์เป็นแบบไหน งานไหนเคยตัดสินใจแล้ว และอะไรคือข้อห้ามของธุรกิจ

OPB Stack จึงควรขาย memory ในภาษาธุรกิจว่า “AI กลับมาทำงานต่อจากเมื่อวานได้” ไม่ใช่ “มี database เก็บข้อความ” เพราะเจ้าของธุรกิจไม่ได้ซื้อ architecture เขาซื้อความต่อเนื่องของงาน

ดู managed sandbox สำหรับ AI coworker ได้ที่ opbstack.com

Leave a Comment

สอบถามข้อมูล
Scroll to Top