memoryfield: ข้อเสนอว่าความจำของเอเจนต์ควรเป็น "ไฟล์ฟอร์แมต" ไม่ใช่ไปป์ไลน์ — ไฟล์ Markdown ในไฟล์ ZIP บวกดัชนี SQLite แค่นั้น

Cal Paterson เผยแพร่บทความ “Agent memory as a file format” เมื่อ 31 ส.ค. 2026 เสนอ memoryfield — ฟอร์แมตพกพาสำหรับเก็บความจำของ AI เอเจนต์ ที่หน้าตาเรียบจนแทบตลก:

my-memories.memoryfield.zip
├── carbon-fibre-woks.md
├── finnish-bureaucracy-tips.md
├── [... ไฟล์ .md อีกจำนวนมาก ...]
├── wec-2026-season-notes.md
└── nomic-embed-text-v1.5.sqlite3

แค่นั้นจริง ๆ — ไฟล์ Markdown ที่มี YAML frontmatter (ไม่บังคับ) และดัชนีเวกเตอร์ SQLite (ไม่บังคับเช่นกัน เพราะสร้างใหม่จากไฟล์ Markdown ได้ตลอด) เขาเขียนสเปกแบบ RFC ฉบับร่าง 0.1 ไว้บน GitHub ใต้ MIT พร้อม CLI tool (AGPL-3.0) และ agent skill (MIT) แยกรีโปกัน

ข้อโต้แย้งตั้งต้นคือ เบนช์มาร์กโมเดลส่วนใหญ่เริ่มจาก context window ว่างเปล่า ซึ่งยุติธรรมสำหรับการวัด แต่ เอเจนต์จริงไม่ควรเริ่มจากศูนย์ มันควรเริ่มด้วยความจำ

ทำไมระบบความจำที่มีอยู่ถึงไม่ค่อยเวิร์ก

Paterson จัดระบบความจำที่นิยมกันตอนนี้เป็นสามพวก แล้วบอกว่าแต่ละพวกพังคนละแบบ

• พวกที่ล็อกคุณไว้กับ harness เดียว มักเขียนโดยแล็บที่ให้เช่า harness นั้น ซึ่ง “อยากออกจากธุรกิจ API ที่แข่งกันดุ ไปอยู่ในธุรกิจแพลตฟอร์มที่กำไรดีกว่ามาก” ระบบพวกนี้ทำงานด้วยการขุดข้อมูลจากประวัติการสนทนา ผลคือความจำเกือบทั้งหมดเป็นเรื่อง เกี่ยวกับตัวคุณ ทั้งที่ข้อมูลเกี่ยวกับ โลก มีประโยชน์กว่ามาก
• พวกที่ซับซ้อนเกินเหตุ เขาบอกว่ารู้จักระบบดังตัวหนึ่งที่ต้องใช้ pgvector + ฐานข้อมูลกราฟ Neo4j + LLM ของตัวเองอีกตัว เพียงเพื่อตัดสินว่าอะไรควรจำ — นอกจากดูแลยากแล้วยังทำให้โมเดลสับสน และไม่สเกลตามความก้าวหน้าของโมเดล
• พวก “High Modernist” ที่จินตนาการความจำในอุดมคติแบบเหตุผลนิยม ลงเอยด้วยกราฟและบางทีก็มี logical proposition ด้วย ระบบแบบนี้ดึงข้อมูลออกจากบริบทของมันอย่างเป็นระบบ เหลือไว้แต่ก้อนที่ไร้ความหมาย — เขาถามกลับว่า “ลิสต์ของ distilled facts เฉย ๆ มันมีประโยชน์แค่ไหนกันแน่”

สิ่งที่ทั้งสามพวกมีร่วมกันคือ มองความจำเป็นกระบวนการ ทั้งที่สำหรับโมเดลแล้ว ความจำแทนด้วย ข้อมูล ได้ดีกว่ามาก เขาอ้าง Brooks: “โชว์ flowchart มาแล้วซ่อนตารางไว้ ผมก็ยังงงต่อไป โชว์ตารางมาสิ แล้วผมมักจะไม่ต้องการ flowchart เลย”

เหตุผลที่ทิ้งกราฟความรู้: N+1 tool call เทียบกับ 2

ส่วนที่มีค่าที่สุดของบทความคือการอธิบายว่าทำไม Karpathy wiki — ไฟล์ Markdown ที่ลิงก์ถึงกันแบบ Roam/Obsidian ให้เอเจนต์เดินกราฟหาข้อมูลเอง — ถึงไม่เวิร์กในทางปฏิบัติ ทั้งที่เป็น prior art สำคัญ

อัลกอริทึมของการเดินกราฟคือ: อ่านหน้าแรก [tool call] → หาลิงก์ที่เกี่ยว → อ่านหน้าที่ลิงก์ไป [tool call] → หาลิงก์ต่อ → ตัดสินว่าพอหรือยัง → ถ้ายังก็วนกลับ ถ้าข้อมูลที่ต้องการอยู่ลึก N ชั้น ก็ต้องเรียกทูล N+1 ครั้ง และแต่ละครั้งโมเดลราคาแพงต้องหยุดรอราว 2-3 วินาที — ซึ่งลงโทษกราฟที่ซ้อนลึก อันเป็นจุดขายของกราฟเสียเอง

ปัญหาที่สองคือความน่าเชื่อถือ: เอเจนต์ตัดสินว่าหน้าไหนเกี่ยวข้องได้จาก ข้อความลิงก์หรือชื่อหน้า เท่านั้น จึงเกิดแรงกดดันให้ต้องทำ metadata hacking แบบ SEO ยุค 1990 กับทุกหน้า ซึ่งลงโทษการเขียนนอกเรื่อง การจดรายละเอียดข้าง ๆ และ “implicit lore” ที่มักมีค่าสูงในคลังข้อความใหญ่ ๆ ข้อมูลที่เกี่ยวข้องจริงจึงมักถูกมองข้ามเพราะตั้งชื่อไม่เร้าใจพอ

ปัญหาที่สามคือ ระหว่างเดินกราฟ เอเจนต์ต้องอ่านของที่ไม่เกี่ยวเยอะมาก (หน้าแรกคือตัวการหลัก) ซึ่งอัดสัญญาณรบกวนเข้า context window ทำให้คุณภาพผลลัพธ์ตกและโมเดล “ดูหมกมุ่นกับเรื่องแปลก ๆ”

ทางแก้ของ memoryfield คือใช้ semantic search กระโดดตรงไปยัง ทุกหน้าที่เกี่ยวข้องพร้อมกัน โดยตัดสินจากเนื้อหาจริงไม่ใช่ metadata แล้วให้เอเจนต์อ่านทั้งหมดแบบขนาน — ซึ่งโมเดลรุ่นปัจจุบันเกือบทุกตัวทำได้แล้ว ผลคือ อย่างมากใช้ 2 tool call (หนึ่งครั้งค้น หนึ่งครั้งอ่านแบบขนาน)

รายละเอียดสเปกที่ควรรู้ก่อนลอง

สเปกเป็นร่างเวอร์ชัน 0.1 (2026-08) ใช้คำสำคัญตาม RFC 2119 และวางกฎที่เรียบแต่คม:

• memoryfield ต้อง เป็นไดเรกทอรีแบน — มีไฟล์ .md อย่างน้อยหนึ่งไฟล์ และ ต้องไม่ มีหน้าอยู่ในไดเรกทอรีย่อย (มีไดเรกทอรีย่อยเพื่อเหตุอื่นได้ แต่ implementation ต้องไม่ index มัน)
• ชื่อไฟล์หน้าใช้ได้แค่ตัวพิมพ์เล็ก ASCII ตัวเลข และยัติภังค์ เช่น carbon-fibre.md
• frontmatter มีฟิลด์ title, uuid, summary, created, updated — แต่ทั้งหมดเป็น SHOULD/MAY และ implementation ต้องไม่ พึ่งพาว่ามันมีอยู่ หน้าที่ไม่มี frontmatter เลยก็เป็นหน้าที่ถูกต้อง
• ถ้าเสิร์ฟเป็นอาร์ไคฟ์เดียว ต้อง เป็น ZIP ที่ถูกต้อง และ ควร ใช้นามสกุล .memoryfield.zip
• implementation ต้อง เมินไฟล์ขยะจากเครื่องมือ sync/editor/OS — ชื่อที่มี .sync-conflict-, ลงท้ายด้วย ~, และ .DS_Store, desktop.ini, Thumbs.db

ข้อจำกัดเดียวที่เขายอมรับคือ หน้าหนึ่งต้องสั้นพอจะใส่ลงเวกเตอร์เดียวได้ จึงมีลิมิตอ่อน ๆ ที่ราว 8KB (~2,000 โทเคน) แต่เขาแย้งว่านี่เป็นข้อจำกัดที่มีประโยชน์ — 8,000 ตัวอักษรคือราว 1,300 คำ หรือความยาวบทความนิตยสารขนาดกลาง ถ้าอยากใส่รายละเอียดเพิ่มก็เพิ่มหน้าเอา ซึ่งเอเจนต์ไม่มีปัญหาอยู่แล้ว

การติดตั้งจริงใช้สามคำสั่ง (ต้องมี ollama, uv และ npx อยู่ก่อน):

ollama pull nomic-embed-text
uv tool install git+https://github.com/calpaterson/memoryfield-tool
npx skills add calpaterson/memoryfield-skill -g -y

โมเดล embedding ที่เลือกคือ nomic-embed-text-v1.5 ซึ่งเขารู้ตัวว่าอายุสองปีแล้ว และตอบข้อครหานั้นตรง ๆ ว่าโมเดล embedding ไม่ได้ใหญ่และไม่ได้เคลื่อนเร็วเท่าโมเดลแนวหน้า ตัวนี้เล็กพอ (270MB) และเร็วพอจะรันบนเครื่องที่ไม่มี GPU — และสเปกก็เปิดให้ใช้ตัวอื่นได้อยู่แล้ว โดยบังคับให้ระบุ model code แบบตรึงเวอร์ชัน (เช่น nomic-embed-text-v1.5 ไม่ใช่แท็กย่อ nomic-embed-text ของ ollama) เพื่อไม่ให้ดัชนีจากคนละเวอร์ชันปนกัน

เรื่องความปลอดภัย เขาไม่ตีขลุม — เขียนชัดว่า “คุณต้องไม่แชร์ context window ของคุณ รวมถึงผ่านความจำ กับฝ่ายที่คุณไม่ไว้ใจ” และเหตุผลหนึ่งที่สเปกมีรูปแบบ ZIP แบบสถิตคือให้ตรวจสอบด้วยมือและตรึงด้วย sha256sum ได้

มุมมอง AI Curator

ข้อเสนอนี้ยังเล็กมาก — ณ วันที่เขียน รีโปสเปกมี 18 ดาว, CLI มี 14 และ skill มี 7 ไม่ควรอ่านว่านี่คือมาตรฐานที่ใครก็ตามต้องรีบตาม แต่ควรอ่านในฐานะ การวิจารณ์ที่แม่นยำผิดปกติต่อสิ่งที่ทั้งอุตสาหกรรมกำลังทำอยู่ และตรงนี้มันมีค่าโดยไม่ต้องรอให้ใครมารับสเปก

จุดที่ผมเห็นด้วยที่สุดคือข้อสังเกตเรื่อง “ต่ำกลไก” — ระบบความจำที่มี API เฉพาะทางเยอะ ๆ บังคับให้เอเจนต์ต้องเดินเขาวงกตของอินเทอร์เฟซ ถ้าอินเทอร์เฟซใหญ่ก็ต้องอัด openapi.json เข้า context ถ้าเล็กก็จำกัด และถึงบาลานซ์ถูกก็มักออกแบบผิดอยู่ดี เพราะคนออกแบบไม่ได้คาดการณ์ความต้องการของคุณ ตรงข้ามกับฟอร์แมตไฟล์เปล่า ๆ ที่ปล่อยให้เอเจนต์คิดวิธีเข้าถึงเอง — เขายกตัวอย่างที่เจอจริงว่าเอเจนต์เคยใช้ perl ทำ find-and-replace ทั้งคลัง และเคยฝัง CSV ไว้ในความจำแล้วเรียก SQLite มาคิวรี ซึ่งไม่มีนักออกแบบ API คนไหนคิดเผื่อไว้

ในบริบทไทย ผมคิดว่าประเด็นที่ควรหยิบไปใช้ก่อนคือ ความเป็นเจ้าของความจำ ทีมไทยจำนวนมากกำลังสะสมความรู้เฉพาะทาง — ระเบียบราชการ, รายละเอียด PDPA, ข้อกำหนดของธนาคาร, ศัพท์เฉพาะในอุตสาหกรรม — ลงในระบบความจำของ vendor ที่ export ออกมาไม่ได้ นั่นคือทรัพย์สินที่ค่อย ๆ กลายเป็นตัวประกัน จุดแข็งที่สุดของ memoryfield ไม่ใช่ความเร็วในการค้น แต่คือการที่มันเป็น “ไดเรกทอรีของไฟล์ Markdown” ซึ่งย้ายไป harness อื่น อ่านด้วยตาเปล่า หรือ diff ด้วย git ได้ทั้งหมด และคำแนะนำของเขาที่ว่าความจำควรมี citation เป็น URL เสมอ เพื่อให้ตรวจสอบซ้ำได้ทีหลัง เป็นสิ่งที่ทีมภาษาไทยควรทำยิ่งกว่า เพราะข้อมูลไทยจำนวนมากเปลี่ยนบ่อยและหาแหล่งยืนยันยาก

ข้อควรระวังที่บทความไม่ได้พูดถึงคือคุณภาพของ embedding กับภาษาไทย nomic-embed-text-v1.5 เป็นโมเดลที่เก่งภาษาอังกฤษเป็นหลัก ถ้าจะเอาสถาปัตยกรรมนี้มาใช้กับความจำภาษาไทย การเลือก embedding ที่รองรับหลายภาษาได้ดีจะเป็นตัวแปรชี้เป็นชี้ตายมากกว่าตัวฟอร์แมต — ซึ่งโชคดีที่สเปกเปิดช่องให้เปลี่ยนได้อยู่แล้ว และควรทดสอบด้วยชุดคำถามภาษาไทยจริงก่อนตัดสินใจ

แหล่งข่าว

• Agent memory as a file format — Cal Paterson, 31 ส.ค. 2026
• สเปก memoryfield ฉบับ RFC (SPEC.md, MIT)
• memoryfield-tool — CLI (AGPL-3.0)
• memoryfield-skill — agent skill (MIT)