OKF Agent Memory เป็นเครื่องมือช่วยจำสำหรับ coding agent หรือ AI ช่วยเขียนและแก้โค้ดอย่าง Claude Code หรือ Cursor โดยเก็บความจำถาวรเป็นไฟล์ Markdown ธรรมดาไว้ในโฟลเดอร์ knowledge/ ภายในที่เก็บโค้ดหรือ repo ของเราเอง

ระบบนี้ไม่ต้องพึ่งฐานข้อมูลภายนอกหรือเปิดโปรแกรมเบื้องหลังทิ้งไว้ ความจำเก็บอยู่ในไฟล์ข้อความที่บันทึกประวัติการแก้ไข และตรวจสอบความเปลี่ยนแปลงด้วย git diff ได้เหมือนโค้ดทั่วไป ส่วนการค้นหาข้อมูลใช้โปรแกรมภาษา Go เพียงตัวเดียว โปรแกรมนี้ส่งข้อมูลให้ agent ผ่าน MCP ซึ่งเป็นโปรโตคอลมาตรฐานสำหรับเชื่อมต่อเครื่องมือภายนอกของ AI

ปัญหาหลักที่เครื่องมือนี้เข้ามาแก้ คือไฟล์คู่มือประจำ repo อย่าง CLAUDE.md ซึ่งรวบรวมกฎเกณฑ์ที่ agent ต้องอ่านก่อนเริ่มทำงาน มักมีขนาดใหญ่ขึ้นเรื่อยๆ ทำให้ทุกครั้งที่เราสั่งงาน agent ต้องอ่านเอกสารใหม่ทั้งฉบับตั้งแต่ต้นจนจบ แม้งานรอบนั้นจะเกี่ยวข้องกับกฎเพียงข้อเดียวก็ตาม

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

จากการทดสอบของทีมพัฒนาบนโมเดลคลาวด์ของ OpenAI พบว่า เมื่อเปลี่ยนมาให้ agent ดึงเฉพาะเนื้อหาส่วนที่เกี่ยวข้องกับงานรอบนั้นมาอ่าน ปริมาณ token ที่ส่งเข้า prompt ต่อรอบลดลงจาก 3,034 เหลือเพียง 603 token หรือประหยัดได้ถึง 80.1%

เก็บความจำไว้ใน Git เป็นไฟล์ Markdown ธรรมดาที่เราเปิดอ่านเองได้

ระบบเก็บความจำทั้งหมดไว้ในโฟลเดอร์ knowledge/ ภายในมีไฟล์ index.md ทำหน้าที่เป็นสารบัญ และไฟล์ log.md บันทึกประวัติการเปลี่ยนแปลงตามลำดับวันที่ ส่วนไฟล์ความรู้ย่อยเรียกว่า concept โดยแยกเก็บตามโฟลเดอร์หมวดหมู่ เช่น architecture/auth-decision.md

ไฟล์ concept แต่ละไฟล์เป็น Markdown ทั่วไป พร้อมส่วนหัวแบบ YAML frontmatter สำหรับระบุข้อมูลสำคัญ ได้แก่ ชื่อเรื่อง ประเภทเอกสาร เช่น Decision สำหรับบันทึกการตัดสินใจด้านสถาปัตยกรรม คำอธิบายสั้นๆ หนึ่งบรรทัดในฟิลด์ description และป้ายกำกับหมวดหมู่ในฟิลด์ tags นอกจากนี้ยังมีสถานะบอกว่าเนื้อหาผ่านการยืนยันจากคนแล้ว หรือเป็นร่างที่ agent สร้างขึ้น

รูปแบบไฟล์ทั้งหมดนี้อ้างอิงตามมาตรฐานเปิด Open Knowledge Format (OKF) v0.2 ของ Google Cloud แต่ตัว OKF Agent Memory เป็นโปรเจกต์อิสระแบบโอเพนซอร์สที่นำสเปกนี้มาทำให้ใช้งานได้จริง ไม่ใช่ผลิตภัณฑ์อย่างเป็นทางการของ Google

ข้อดีของการเก็บความจำลง Git คือเราตรวจสอบทุกอย่างได้เหมือนการตรวจโค้ด เราใช้ git diff ดูได้ทันทีว่า agent บันทึกอะไรเพิ่มเข้ามา ใช้ git blame ดูประวัติได้ว่าใครเป็นคนเขียนบรรทัดนี้ และถ้าข้อมูลส่วนไหนไม่ถูกต้อง ก็สั่ง revert เพื่อยกเลิกการเปลี่ยนแปลงได้ทันทีเหมือนโค้ดทั่วไป

จุดสำคัญที่ต้องทำความเข้าใจคือ เครื่องมือนี้ไม่ใช่ตัวสรุปบทสนทนาในแชตแบบอัตโนมัติ

เครื่องมือกลุ่มที่ดักจับแชต เช่น agentmemory จะเปิดโปรแกรมเบื้องหลังคอยดักฟังบทสนทนา แล้วเรียกโมเดลภาษาขนาดใหญ่อย่าง LLM มาสรุปเป็นความจำให้อัตโนมัติ คล้ายกับ deja-vu ที่คอยขุด log เก่าของ agent ตามที่เราเคยเขียนถึง

แต่แนวทางของ OKF เลือกใช้แนวคิด LLM Wiki นั่นคือเป็นฐานความรู้ที่คนกับ agent ช่วยกันเขียนและกลั่นกรองจนได้ข้อสรุป จากนั้นจึงส่งเข้า repo ผ่าน Pull Request ให้คนในทีมช่วยรีวิวก่อนรวมเข้าโปรเจกต์ โดยไม่มีโปรแกรมเบื้องหลังคอยดักฟังอะไรทั้งสิ้น

Progressive Disclosure: ดึงความรู้ทีละส่วน ไม่ต้องโหลดทั้งเล่ม

กลไกสำคัญที่ช่วยลด token ได้มหาศาลคือ Progressive Disclosure ซึ่งให้ agent ค่อยๆ เข้าถึงข้อมูลทีละระดับ แทนที่จะยัดความจำทั้งหมดให้อ่านในคราวเดียว

ไฟล์ index.md ทำหน้าที่เป็นสารบัญสรุป โดยเก็บชื่อ concept และคำอธิบายสั้นๆ เพียงบรรทัดเดียวต่อเรื่อง และแต่ละ concept ยังเชื่อมโยงถึงกันเป็นกราฟได้ เมื่อ agent ต้องการค้นหาเรื่องใด มันจะอ่านสารบัญเพื่อเลือกเฉพาะข้อมูลที่ตรงกับงาน แล้วโหลดไฟล์นั้นเพียงไฟล์เดียวเข้า context ซึ่งเป็นพื้นที่ทำงานของโมเดล

ทีมพัฒนาประเมินว่าเนื้อหาแต่ละ concept ใช้พื้นที่ประมาณ 300 token เท่านั้น ซึ่งต่างกันลิบลับเมื่อเทียบกับการยัดไฟล์ CLAUDE.md ทั้งหมดเข้าไปใน prompt ทุกรอบ โดยโปรเจกต์ยกตัวอย่างว่าไฟล์นี้อาจบวมขึ้นไปได้ถึงระดับสองหมื่น token

จาก รายงานผลการทดสอบของโปรเจกต์ กับโมเดล gpt-5.6-sol ผ่านคลาวด์ของ OpenAI เมื่อเดือนกันยายน 2026 มีตัวเลขสรุปดังนี้:

• ปริมาณ token ต่อรอบ: ลดลงจาก 3,034 เหลือ 603 token (ลดลง 80.1%)
• เวลารอคำแรก หรือ TTFT: ลดลงจาก 9,227 ms เหลือ 8,682 ms (เร็วขึ้นราว 1.1 เท่า)
• เวลาประมวลผลรวมทั้งรอบ: ลดลงจาก 15.9 วินาที เหลือ 14.9 วินาที
• ตรวจสอบการปฏิบัติตามกฎที่กำหนด: ผ่าน 4 จาก 4 ข้อครบถ้วน

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

แต่สำหรับโมเดลที่รันบนเครื่องตัวเองอย่าง Local LLM ผลลัพธ์ต่างออกไปอย่างเห็นได้ชัด โปรเจกต์ระบุว่าโมเดลขนาด 8B ถึง 14B (แปดพันล้านถึงหมื่นสี่พันล้านพารามิเตอร์) อย่าง Qwen 2.5 Coder หรือ Llama 3 มีช่วง prefill time ที่ใช้ประมวลผล prompt ก่อนเริ่มตอบลดลงจากเดิมที่นานกว่า 6 วินาที เหลือไม่ถึง 50 ms และเวลารอคำแรกเร็วขึ้นได้ถึง 5.2 เท่า โดยตัวเลขทั้งหมดนี้เป็นผลการทดสอบภายในของทีมพัฒนาบนเครื่องตัวเอง

BM25 ค้นหาด้วยคีย์เวิร์ดตรงตัว ไม่ต้องพึ่ง Vector Embedding

กลไกที่ใช้ค้นหาว่าข้อมูลก้อนไหนตรงกับงาน คืออัลกอริทึม BM25 ซึ่งเป็นการค้นหาแบบจับคู่คำหรือ Full-Text Search ที่คำนวณคะแนนความเกี่ยวข้องจากคีย์เวิร์ดที่ตรงกันในชื่อเรื่อง, description และแท็กของแต่ละ concept

เมื่อใช้งานจริงผ่าน CLI จะเห็นผลลัพธ์แบบนี้:

$ okf search "jwt auth flow" knowledge

Found 1 matching concept(s) in 'knowledge':

 1. [4.82] architecture/auth-decision (Decision)
    Standardized RSA-256 JWTs with 15m expiration & sliding refresh tokens.
    Matches: title, description, tags

In-Memory BM25 search completed in 268.4µs (<0.3ms)

ตัวเลข 4.82 คือคะแนนความเกี่ยวข้องของเนื้อหา ส่วน 268.4 ไมโครวินาทีคือเวลาที่ใช้ค้นหา โปรแกรมค้นหาได้เร็วมากเพราะโหลดไฟล์ทั้งหมดในโฟลเดอร์ knowledge/ ขึ้นหน่วยความจำ RAM ล่วงหน้า ขั้นตอนนี้ใช้เวลาไม่ถึง 4 ms จากนั้นจึงค้นหาใน RAM โดยตรง จึงไม่ต้องเรียก API ภายนอกแม้แต่ครั้งเดียว

นี่คือข้อแตกต่างสำคัญระหว่างสองแนวทางที่คุณต้องเลือก:

ถ้าเลือกใช้ Vector Database อย่าง Mem0 หรือ Letta ระบบจะค้นหาด้วย embedding หรือการแปลงข้อความเป็นเวกเตอร์เพื่อเปรียบเทียบความหมาย ซึ่งมีข้อดีคือค้นหาเจอได้แม้คำค้นจะไม่ตรงกับในเอกสาร แต่ต้องแลกกับการเรียก API เพื่อสร้าง embedding ทุกครั้งที่บันทึกหรือค้นหา ต้องเปิด database แยกไว้ตลอดเวลา และจากตารางเปรียบเทียบของโปรเจกต์ การค้นหาแต่ละครั้งจะใช้เวลาประมาณ 150 ถึง 800 ms

ส่วน BM25 ค้นหาเสร็จในเวลาไม่ถึง 300 ไมโครวินาที ไม่เสียค่า API เพิ่มเติม และทำงานแบบออฟไลน์ได้โดยไม่ต้องต่ออินเทอร์เน็ต แต่มีข้อจำกัดคือค้นหาจากคีย์เวิร์ดที่ตรงกันเท่านั้น ไม่ได้เข้าใจความหมายเหมือนเวกเตอร์

ดังนั้น ถ้าเลือกใช้แนวทางนี้ แนะนำให้เขียน description และแท็กของแต่ละ concept ให้ตรงกับคำที่ agent มักใช้ค้นหาจริงๆ เพราะข้อความในบรรทัดเหล่านั้นคือสิ่งที่ BM25 จะนำไปจับคู่กับคำค้นหาโดยตรง

verified: human กับ generated: agent กฎเหล็กว่าใครมีสิทธิ์เขียนทับ

ส่วนหัว frontmatter ของไฟล์ concept ทุกไฟล์ จะมีบรรทัดระบุระดับความน่าเชื่อถือ โดยค่า verified: human หมายถึงมนุษย์ได้ตรวจสอบและยืนยันแล้ว ถือเป็นข้อตกลงหรือกฎที่เป็นทางการ ส่วน generated: agent หมายถึงเป็นเพียงร่างที่ AI สร้างขึ้นมาเอง

กฎเหล็กของโปรเจกต์นี้คือ agent ห้ามแก้ไขหรือเขียนทับข้อมูลที่คนยืนยันแล้วเด็ดขาด นอกจากนี้ในส่วนหัวยังมีฟิลด์ sources บอกแหล่งที่มาของข้อมูล รวมถึง status และ stale_after เพื่อระบุว่าเนื้อหานี้ยังใช้งานอยู่หรือไม่ และจะหมดอายุเมื่อไหร่

อีกกฎหนึ่งที่โปรเจกต์บังคับใช้อย่างเคร่งครัดคือ Search-Before-Write หมายความว่า ก่อนที่ agent จะสร้าง concept ใหม่ขึ้นมา จะต้องค้นหาความจำเดิมที่มีอยู่ก่อนเสมอ

ถ้าข้ามขั้นตอนนี้ไป agent อาจสร้างข้อมูลเรื่องเดียวกันซ้ำซ้อนขึ้นมาเป็นสองไฟล์ และเมื่อเวลาผ่านไป เนื้อหาในสองไฟล์นั้นก็จะค่อยๆ ต่างกันไป กฎข้อนี้จึงมีขึ้นมาเพื่อป้องกันปัญหาสองเรื่องนี้โดยเฉพาะ

คำสั่งสำหรับตรวจสอบความเรียบร้อยของระบบความจำคือ:

okf validate knowledge --strict --drift

คำสั่งนี้จะตรวจว่าโครงสร้างไฟล์ถูกต้องตามสเปกหรือไม่ ลิงก์เชื่อมโยงระหว่าง concept ยังชี้ถึงกันครบไหม และข้อความ description ในสารบัญยังตรงกับเนื้อหาจริงในไฟล์หรือเปล่า

สำหรับคำถามว่าใครควรเป็นคนอนุมัติหรือเปลี่ยนสถานะเป็น verified: human ตัวโปรเจกต์ไม่ได้กำหนดตายตัว แต่ให้แต่ละทีมตกลงกันเอง โดยแนวทางที่โปรเจกต์แนะนำคือให้แก้ไขหรือเพิ่มความจำผ่าน Pull Request เพื่อให้คนในทีมได้รีวิวความถูกต้องก่อนรวมเข้า repo เช่นเดียวกับการตรวจโค้ด

ติดตั้งและเชื่อมต่อกับ Claude Code ใน 3 ขั้นตอน

ขั้นที่ 1: ติดตั้ง CLI
ติดตั้งผ่านคำสั่งสั้นๆ บรรทัดเดียวจากหน้าเว็บ okf-memory.dev บน macOS หรือ Linux (นอกจากนี้ยังเลือกติดตั้งผ่าน Homebrew, go install หรือคอมไพล์จาก source code ได้เช่นกัน)

curl -fsSL https://okf-memory.dev/install.sh | sh

ขั้นที่ 2: เริ่มต้นระบบในโปรเจกต์
เข้าไปในโฟลเดอร์ repo ที่ต้องการใช้งาน แล้วรันคำสั่ง:

okf bootstrap .

คำสั่งนี้จะสร้างสิ่งที่จำเป็นทั้งหมดในครั้งเดียว ได้แก่ โฟลเดอร์ knowledge/ พร้อมไฟล์ index.md และ log.md รวมถึงโฟลเดอร์ skill ชื่อ okf-memory ซึ่งรวบรวมคู่มือและคำสั่งให้ agent ดึงความจำมาใช้ นอกจากนี้ยังสร้างไฟล์ AGENTS.md ที่ปรับให้เข้ากับโปรเจกต์ และไฟล์ Makefile พร้อมคำสั่งลัดอย่าง make validate กับ make search q="..."

ขั้นที่ 3: กำหนดค่า MCP Server ให้ agent รู้จัก
เพิ่มบล็อกคอนฟิกต่อไปนี้ลงในไฟล์ตั้งค่า MCP ของเครื่องมือที่คุณใช้ เช่น Claude Code, Cursor หรือ Codex:

{
  "mcpServers": {
    "okf-memory": {
      "command": "okf",
      "args": ["mcp", "knowledge"]
    }
  }
}

หลังจากตั้งค่าเสร็จแล้ว agent จะเรียกใช้คำสั่ง okf mcp knowledge ผ่านช่องทาง stdio ซึ่งสื่อสารผ่าน input/output ของโปรแกรมโดยตรง ไม่ต้องเปิดพอร์ตเครือข่าย ทำให้ agent สามารถค้นหาและบันทึกความจำได้เองจากหน้าแชตทันที

นอกจากการทำงานผ่าน agent แล้ว เราเองก็มักใช้คำสั่ง CLI เหล่านี้:

• okf search "<คำค้น>" knowledge เพื่อค้นหาข้อมูล
• okf show <concept> knowledge เพื่อเปิดดูเนื้อหาของเรื่องนั้น พร้อมความสัมพันธ์ที่เชื่อมโยงกับเรื่องอื่น
• okf create เพื่อสร้าง concept ใหม่ ซึ่งระบบจะอัปเดตทั้ง log.md และ index.md ให้โดยอัตโนมัติ

okf create decisions/auth-flow knowledge \
  --type Decision \
  --title "OAuth2 Authorization Flow" \
  --desc "Standardized on PKCE for client authentication."

(หมายเหตุ: ถ้าต้องการเพียงโครงสร้างโฟลเดอร์ความจำเปล่าๆ โดยไม่เอาไฟล์ AGENTS.md และ skill เสริม ให้ใช้คำสั่ง okf init my-project/knowledge แทน bootstrap)

ข้อจำกัดที่ควรรู้ก่อนตัดสินใจนำไปใช้งาน

ปัจจุบันตัวโปรแกรมยังเป็นเวอร์ชัน 0.1.5 ภายใต้สัญญาอนุญาตแบบ MIT License ซึ่งยังใหม่อยู่มาก

ระบบความจำนี้ออกแบบมาให้ผูกกับ repo แบบแยกเดี่ยว ถ้าทีมของคุณมีไมโครเซอร์วิสหลายสิบตัวและต้องการให้ agent ค้นหาข้อมูลข้าม repo ไปมา ในตอนนี้ยังทำไม่ได้ ส่วนบริการที่ชื่อ OKF Cloud ซึ่งชูจุดเด่นเรื่องการค้นหาข้าม repo และมีแดชบอร์ดแสดงกราฟความรู้ ก็ยังอยู่ในช่วง Private Beta ที่เปิดให้ลงชื่อรอคิวเท่านั้น

ตัวเลข benchmark ทั้งหมดในรายงานเป็นการวัดผลภายในของผู้พัฒนาเอง และพบว่าตารางเปรียบเทียบทั้งสองแห่งของโปรเจกต์ยังแสดงตัวเลขฝั่งคู่แข่งไม่ตรงกัน โดยในเอกสารบน GitHub ระบุว่า Vector Database ใช้เวลาเริ่มต้นโปรแกรมหรือ startup latency ประมาณ 250 ถึง 600 ms แต่บนหน้าเว็บไซต์กลับระบุไว้ที่ 1.5 ถึง 3 วินาที จึงควรมองตัวเลขเปรียบเทียบฝั่งคู่แข่งเป็นเพียงการประมาณการคร่าวๆ แต่ตัวเลขฝั่ง OKF เองในตารางทั้งสองแห่งระบุตรงกัน

สุดท้าย แม้หน้าเว็บไซต์หลักจะชูจุดขายว่าเครื่องมือนี้สร้างมาสำหรับ coding agent แต่ใน README ระบุว่าสถาปัตยกรรมนี้ออกแบบมาให้ประยุกต์ใช้กับงานด้านอื่นได้ด้วย โดยมีตัวอย่างโฟลเดอร์ความรู้ให้ดู 3 รูปแบบ ได้แก่ การอ่านหนังสือ, การโค้ช และงานพัฒนาซอฟต์แวร์ เพราะแก่นแท้คือโฟลเดอร์ Markdown ที่มีสารบัญและระบบค้นหาที่รวดเร็ว อะไรก็ตามที่สรุปเป็นหัวข้อได้ ก็นำมาจัดเก็บด้วยวิธีนี้ได้ทั้งหมด

หัวใจสำคัญของระบบความจำสำหรับ agent ไม่ได้อยู่ที่การอัดข้อมูลทั้งหมดเข้าไป แต่อยู่ที่การเลือกดึงเฉพาะข้อมูลไม่กี่บรรทัดที่จำเป็นจริงๆ มาให้อ่านก่อนลงมือตอบ

ที่มา: โปรเจกต์ OKF Agent Memory บน GitHub