Stash - เลเยอร์หน่วยความจำแบบถาวรสำหรับ AI เอเจนต์

 (alash3al.github.io)
2 คะแนน โดย GN⁺ 3 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็น เลเยอร์หน่วยความจำแบบถาวร ที่ช่วยให้บทสนทนาและบริบทของงานต่อเนื่องข้ามเซสชันได้ โดยเก็บการสังเกตดิบเป็น episodes ก่อนสะสมเป็นองค์ความรู้ที่มีโครงสร้าง
  • ใช้ สถาปัตยกรรมที่ไม่ผูกกับโมเดล ทำให้เชื่อมต่อกับ Claude, GPT, LLM แบบโลคัล และเอเจนต์แบบกำหนดเอง บนเลเยอร์หน่วยความจำเดียวกันได้ โดยสตอเรจทำงานบน PostgreSQL และ pgvector
  • มีบทบาท ต่างจาก RAG โดยไม่ได้หยุดแค่การค้นเอกสาร แต่สะสมทั้งข้อเท็จจริงใหม่ ความสัมพันธ์ เป้าหมาย ความล้มเหลว และสมมติฐานจากบทสนทนา และสามารถใช้ร่วมกับ RAG ได้
  • ใช้ namespace และเส้นทางแบบลำดับชั้นเพื่อแยกความรู้ของผู้ใช้ โปรเจกต์ และความรู้เกี่ยวกับตัวเอเจนต์เอง พร้อม pipeline สำหรับ consolidation ที่สังเคราะห์ facts, relationships, causal links, patterns, contradictions อย่างต่อเนื่อง
  • มีทั้ง การเชื่อมต่อแบบ MCP-native, self-model ที่อิงกับ /self และลูปวิจัยแบบวนซ้ำ เพื่อเปลี่ยนเอเจนต์แบบอิงเซสชันที่ไม่มีความทรงจำ ให้กลายเป็นตัวปฏิบัติงานที่มีความต่อเนื่องระยะยาว

ภาพรวมของ Stash

  • เป็น เลเยอร์หน่วยความจำแบบถาวร ที่อยู่ระหว่าง AI เอเจนต์กับโลกภายนอก ทำให้ยังคงบริบทเดิมไว้ได้แม้เปลี่ยนเซสชัน
  • เก็บการสังเกตดิบเป็น episodes แล้วสะสมเป็นองค์ความรู้ที่มีโครงสร้าง เช่น facts, relationships, patterns, goals, failures, hypotheses
  • ไม่ได้มาแทนที่ตัวโมเดล แต่ช่วยเสริมความต่อเนื่อง และออกแบบให้เชื่อมต่อได้กับ เอเจนต์ทุกประเภท ไม่ว่าจะเป็น Claude, GPT หรือโมเดลแบบโลคัล
  • ใช้ PostgreSQL + pgvector เป็นฐานจัดเก็บข้อมูล
  • GitHub

วิธีจัดโครงสร้างหน่วยความจำ

  • ใช้ namespace เพื่อแยกหน่วยความจำ เช่น ของผู้ใช้ ของโปรเจกต์ และความรู้เกี่ยวกับตัวเอเจนต์เอง
  • แต่ละ namespace จัดเป็น เส้นทางแบบลำดับชั้น โดยเมื่ออ่าน /projects ก็จะรวมเส้นทางย่อยอย่าง /projects/stash, /projects/cartona มาด้วย
  • การเขียนจะบันทึกลงได้เฉพาะ namespace ที่ระบุแบบตรงตัวเท่านั้น เพื่อป้องกัน การปนเปื้อนของหน่วยความจำ
  • หน่วยความจำเกี่ยวกับผู้ใช้ หน่วยความจำของโปรเจกต์ และความรู้เกี่ยวกับตัวเองใต้ /self จะถูกแยกออกจากกันไม่ให้ปะปน
  • โครงสร้างตัวอย่างมี /users/alice, /projects/restaurant-saas, /projects/mobile-app, /self/capabilities, /self/limits, /self/preferences

ความต่างจาก RAG

  • RAG ใกล้เคียงกับเลเยอร์ค้นคืนข้อมูลจากเอกสาร โดยดึงเนื้อหาที่เกี่ยวข้องจากเอกสาร แต่ไม่ได้จดจำหรือเรียนรู้จากบทสนทนาเอง
  • RAG จัดการได้เฉพาะสิ่งที่มีอยู่แล้วในเอกสาร และไม่สามารถสร้าง องค์ความรู้ใหม่จากบทสนทนา ได้
  • การติดตามเป้าหมาย การเข้าใจเจตนา การตรวจจับความขัดแย้งตามเวลา และการให้เหตุผลเรื่องสาเหตุและผลลัพธ์ ถูกนำเสนอว่าอยู่นอกขอบเขตของ RAG
  • Stash เรียนรู้อัตโนมัติจากบทสนทนา การตัดสินใจ ความสำเร็จ และความล้มเหลว พร้อมสะสมกราฟความรู้ไปเรื่อย ๆ
  • เพราะการค้นเอกสารกับความทรงจำจากประสบการณ์เป็นคนละปัญหากัน จึงสามารถใช้ RAG และ Stash ร่วมกันได้

จุดที่ต่างจากหน่วยความจำ AI แบบเดิม

  • แม้ Claude.ai และ ChatGPT จะมีฟีเจอร์หน่วยความจำ แต่ฟีเจอร์เหล่านั้นผูกอยู่กับ แพลตฟอร์มและโมเดลของตัวเอง
  • Stash ทำงานแบบ ไม่ผูกกับโมเดล และเชื่อมต่อได้กับทั้งโมเดลแบบโลคัลและโมเดลส่วนตัว
  • ความเป็นเจ้าของข้อมูลอยู่ฝั่งผู้ใช้ และเปิดให้ใช้งานแบบ โอเพนซอร์ส
  • มีองค์ประกอบอย่าง background consolidation, การติดตาม goals และ intent, การเรียนรู้จาก failures, causal reasoning และ agent self-model
  • ตามตารางเปรียบเทียบ ChatGPT Memory และ Claude.ai Memory ถูกจัดเป็น “notepad” ส่วน Stash ถูกจัดเป็น “mind”

ปัญหาที่ต้องการแก้

  • ปัจจุบันโมเดล AI แม้จะให้เหตุผลได้ดี แต่ไม่มี ความจำข้ามเซสชัน ทำให้ผู้ใช้ต้องอธิบายตัวเองและฉากหลังของโปรเจกต์ซ้ำทุกครั้ง
  • วิธีใส่ประวัติการสนทนายาว ๆ ลงในพรอมป์ต์ทุกครั้งนั้น ช้าและมีค่าใช้จ่ายสูง อีกทั้งยังติดข้อจำกัดของ context window
  • ยังขาด กลไกส่งต่อบทเรียน ที่ช่วยไม่ให้เอเจนต์ทำซ้ำความพยายามที่ล้มเหลวในเซสชันถัดไป
  • ฟีเจอร์หน่วยความจำมีให้ใช้เป็นความสามารถเฉพาะของบางแพลตฟอร์ม ทำให้เอเจนต์แบบกำหนดเองหรือ LLM แบบโลคัลต้องเริ่มต้นแบบไร้บริบททุกครั้ง

pipeline การรวมความรู้

  • มี background process ที่สังเคราะห์ประสบการณ์อย่างต่อเนื่อง เพื่อเปลี่ยน หน่วยความจำดิบ ให้เป็นองค์ความรู้ที่มีโครงสร้าง
  • ในขั้น Episodes จะเก็บการสังเกตแบบ append-only
  • ในขั้น Facts จะใช้ LLM สังเคราะห์ชุดของ episode
  • ในขั้น Relationships จะดึงความสัมพันธ์ของเอนทิตีระหว่าง fact ต่าง ๆ
  • ในขั้น Causal Links จะเชื่อมคู่ความสัมพันธ์เชิงเหตุและผลระหว่าง fact
  • ในขั้น Patterns จะสกัดรูปแบบเชิงนามธรรมในระดับสูงขึ้น
  • ในขั้น Contradictions จะทำ self-correction และ confidence decay
  • ด้วย Goal Inference ระบบจะติดตามข้อเท็จจริงที่เกี่ยวกับเป้าหมายที่กำลังใช้งานอยู่โดยอัตโนมัติ พร้อมแสดงความคืบหน้าและความขัดแย้ง
  • ด้วย Failure Patterns ระบบจะตรวจจับความผิดพลาดซ้ำ ๆ และสกัดเป็นข้อเท็จจริงใหม่เพื่อลดการล้มเหลวแบบเดิมซ้ำอีก
  • ด้วย Hypothesis Scan ระบบจะตรวจสอบหรือหักล้างสมมติฐานที่ยังเปิดอยู่จากหลักฐานใหม่ได้โดยไม่ต้องมีการแทรกแซงด้วยมือ

การเชื่อมต่อ MCP

  • ทำงานแบบ MCP-native และเชื่อมต่อกับ Claude Desktop, Cursor, OpenCode, เอเจนต์แบบกำหนดเอง, LLM แบบโลคัล และ MCP client อื่น ๆ ได้
  • เชื่อมต่อได้โดยไม่ต้องใช้ SDK และทำให้ใช้เลเยอร์หน่วยความจำเดียวกันได้จากทุกที่โดยไม่มี vendor lock-in
  • มีเครื่องมือรวม 28 รายการ ครอบคลุมตั้งแต่ remember, recall, forget, init ไปจนถึง causal links, contradictions, hypotheses
  • สามารถใช้ ./stash mcp execute --with-consolidation เพื่อเริ่ม stdio MCP server พร้อม consolidation ได้
  • สามารถใช้ ./stash mcp serve --port 8080 --with-consolidation เพื่อรัน SSE server สำหรับเอเจนต์ระยะไกลได้

self-model ของเอเจนต์

  • เมื่อเรียก init ระบบจะสร้างโครง namespace ของ /self เพื่อเริ่มต้นการสร้าง self-model
  • ใน /self/capabilities จะจดจำสิ่งที่เอเจนต์ทำได้ดีเพื่อนำไปใช้กับการวางแผนงาน
  • ใน /self/limits จะเก็บประวัติความล้มเหลวและข้อจำกัด เพื่อช่วยป้องกัน การทำพลาดแบบเดิมซ้ำ
  • ใน /self/preferences จะเรียนรู้รูปแบบการทำงานที่ให้ผลดีที่สุด และค่อย ๆ สร้างสไตล์การทำงานในระยะยาว

ลูปการเรียนรู้อัตโนมัติ

  • หากรัน research loop ทุก 5 นาที ระบบจะดึงบริบทปัจจุบันจากหน่วยความจำเดิม เลือกหัวข้อไปค้นคว้าด้วยตัวเอง สร้างความเชื่อมโยงใหม่ รวมความรู้กลับเข้าไป แล้วจบการทำงาน
  • ในขั้น Orient จะดึงบริบทเดิม เป้าหมายที่กำลังใช้งานอยู่ สมมติฐานที่ยังเปิดอยู่ และความล้มเหลวในอดีตขึ้นมา
  • ในขั้น Research เอเจนต์จะค้นเว็บตามหัวข้อที่เลือกเอง
  • ในขั้น Think จะเปิดให้เห็นความตึงเครียด ช่องว่าง และความขัดแย้งในสิ่งที่รู้อยู่ตอนนี้
  • ในขั้น Invent จะสร้างผลลัพธ์ใหม่ เช่น สมมติฐาน รูปแบบ และการค้นพบ
  • ในขั้น Consolidate จะรัน pipeline เพื่อสังเคราะห์ raw episode ให้เป็นองค์ความรู้ที่มีโครงสร้าง
  • ในขั้น Reflect + Sleep จะบันทึกสรุปของเซสชัน ตั้งบริบทสำหรับการทำงานครั้งถัดไป แล้วหยุด
  • ดูพรอมป์ต์ของลูป

ความเข้ากันได้กับโมเดลและโครงสร้างพื้นฐาน

  • ทั้ง embedding และ reasoning ใช้การตั้งค่า provider เดียวที่อิงกับ OpenAI-compatible API
  • ระบุว่ารองรับทั้งคลาวด์ โลคัล และการติดตั้งแบบ self-hosted โดยไม่มี vendor lock-in
  • ระบุว่ากำลังใช้งาน OpenRouter แบบโลคัล และสามารถเข้าถึงโมเดลหลายร้อยตัวได้ด้วย API key เดียว
  • ใช้งานกับ Ollama ได้ทันที และสามารถตั้งค่าหน่วยความจำแบบ ออฟไลน์ ด้วยโมเดลโลคัลอย่าง Qwen, Llama, Mistral
  • ยังระบุว่ารองรับแบ็กเอนด์ที่ใช้รูปแบบ OpenAI API เช่น vLLM, LM Studio, llama.cpp server, Together AI, Groq
  • โมเดล embedding เริ่มต้นคือ openai/text-embedding-3-small และในชุดค่าผสมนั้นใช้ STASH_VECTOR_DIM=1536
  • STASH_VECTOR_DIM สามารถตั้งค่าได้ ก่อนการรันครั้งแรกเท่านั้น และหากเปลี่ยนหลังเริ่มต้นแล้ว จะต้องรีเซ็ตฐานข้อมูลทั้งหมด

ข้อมูลการติดตั้งและการใช้งาน

  • มีคอนฟิกสำหรับเปิดใช้งาน Postgres, pgvector, Stash พร้อมกันด้วย Docker Compose
  • ขั้นตอนเริ่มใช้งานนำเสนอเป็น 3 ขั้น คือ clone รีโพซิทอรี, คัดลอก .env.example เป็น .env แล้วตั้งค่า API key กับโมเดล, จากนั้นรัน docker compose up
  • หลังรันครั้งแรก คาดว่าจะมีการเตรียม postgres + pgvector, ใช้ migration, รอ MCP server และรัน background consolidation
  • โปรเจกต์เผยแพร่ภายใต้ไลเซนส์ Apache 2.0
  • GitHub Repository
  • alash3al.com

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 일 전
ความคิดเห็นจาก Hacker News

  • ตอนแรกกดเข้าไปเพราะนึกว่าในที่สุดมีคนทำอะไรแบบ ระบบความทรงจำของ Claude.ai ให้พกพาได้แล้ว แต่ไม่ใช่แบบนั้นเลย
    ของที่มีตรงนี้เป็นแค่แนว store/remember ธรรมดา ส่วนที่ผมรู้สึกว่าดีกว่าคือวิธีที่โมเดลเบื้องหลัง สรุปประวัติแชต แล้วสร้างความทรงจำขึ้นมา
    แบบนั้นทำงานดีกว่ามากเพราะไม่ต้องให้โมเดลมาเขียนเมมโมรีเอง ดังนั้นการนำเสนอตัวนี้ว่าอยู่ระดับเดียวกับ Claude.ai เลยดูค่อนข้าง misleading
    ผมเองก็พยายามหาระบบความทรงจำแบบเดียวกันอยู่เรื่อย ๆ เพื่อจะย้ายไปทาง LibreChat แต่ก็ยังหาไม่ได้ และตอนนี้เหตุผลแทบจะอย่างเดียวที่ยังอยู่กับ Claude.ai ก็เพราะฟีเจอร์นี้
    อ้างอิงไว้ว่า ระบบนี้มีเฉพาะใน Claude.ai ไม่มีใน Claude Code

    • ตาม Claude Code leak ล่าสุด เคยมีสิ่งที่เรียกว่า autoDream ซึ่งในนั้นอธิบายว่าเป็น background memory consolidation engine: https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it
    • ผมอยากลองแนวทางนี้มาก
      ประสบการณ์ของผมกลับตรงกันข้ามเลย เพราะผมสร้าง https://github.com/flippyhead/ai-brain ขึ้นมาใช้เองเป็นหลัก และเพื่อนอีกไม่กี่คนก็ใช้ด้วย
      ที่ผ่านมาวิธีใช้ CLAUDE.md เพื่อให้ AI ค้นหาเมมโมรีที่เกี่ยวข้อง และคิดเองว่าควรเก็บเมื่อไรและอย่างไร กลับได้ผลค่อนข้างดี
      วิธีนี้สร้างโครงสร้างตามลำดับความสำคัญได้ และยังทิ้งโน้ตไว้เผื่ออนาคตได้ด้วย เลยให้ความรู้สึกต่างจากการสรุปทุกอย่างแบบล้วน ๆ พอสมควร
    • ผมชอบแบบที่ recall อัตโนมัติ ทำงานอยู่เบื้องหลังโดยเอเจนต์ไม่เห็นมันมากกว่า
      การสร้างเมมโมรีผ่าน tool call ก็ใช้ได้ดีพอสมควร และการสร้างเมมโมรีอัตโนมัติระหว่างบีบอัดคอนเท็กซ์ก็ดูโอเค
      แต่ถ้าจะสร้างอัตโนมัติจริง ๆ ก็ต้องมี consolidation แบบอะซิงก์ ซึ่งจะเรียกมันว่า dreaming ก็รู้สึกพูดเกินไปหน่อย
      implementation ของผมอยู่ใน Elroy.bot และผมสรุปหลายแนวทางไว้ที่นี่: https://tombedor.dev/approaches-to-agent-memory/
    • ผมสงสัยว่าเขา benchmark กันยังไง
      ปัญหาคือถ้าดึงเมมโมรีออกมาในเบื้องหลัง มันจะเข้ากับ prefix cache ได้ยาก
      แค่ใช้ LOG.md สองชั้นแบบง่าย ๆ (ล็อกรายละเอียดของงานและบทเรียน) + MEMORY.md (บันทึกรายการที่ถูกยกระดับเมื่อล็อกโดนตัด) + stop hook ที่รันตอนจบแต่ละเทิร์น ก็ไปได้ไกลพอสมควรแล้ว
    • แนวคิดนี้น่าสนใจทีเดียว
      มันให้ความรู้สึกเหมือนมีทีมผู้ช่วยอยู่หลังเอเจนต์ที่คุยกับผู้ใช้ คอยแอบฟังบทสนทนาแล้วจดข้อเท็จจริงสำคัญ หรือค้นหาข้อเท็จจริงที่เกี่ยวข้องจาก DB แล้วแทรกขึ้นมาว่า เมมโมรี X นี้น่าจะเกี่ยวข้อง
      ถ้า token ฟรีก็คงดูง่าย แต่การทำให้มัน มีประสิทธิภาพ นี่เป็นโจทย์ที่น่าสนุกทีเดียว

  • โปรเจกต์ที่แทบไม่เปิดเผยวิธี implementation แต่กลับสัญญาอะไรหลายอย่าง มักดูเป็น red flag ใหญ่ เสมอ
    พอขุดต่อก็แทบจะเป็นแค่ pg_vector กับ mcp แล้วมีฟังก์ชัน recall/remember แปะอยู่
    สุดท้ายมันก็ใกล้กับ RAG มากกว่า จะบอกว่า data structure สำคัญก็ได้ แต่ระบบความทรงจำแนวนี้ที่ออกมาก่อนหน้านี้แทบทั้งหมดก็ทำงานคล้าย ๆ กัน
    จนถึงตอนนี้ผมยังไม่เห็นกรณีที่พิสูจน์ได้ว่าค้นหาได้ดีกว่า vector DB search แบบพื้นฐาน

    • เว็บสวยดี มีคำว่า memory แปะอยู่ และทำให้ดูเหมือนว่า LLM แย่มากแต่ผลิตภัณฑ์นี้จะแก้ให้แบบมหัศจรรย์
      ถ้ามันทำได้จริง สุดท้ายมันก็ใกล้เคียงกับการเอา vectordb มาห่อใหม่ให้ดูดี

  • มีรีวิวแล้ว: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
    และมี LLM memory systems อื่น ๆ อีกมากรวมไว้ที่นี่: https://zby.github.io/commonplace/agent-memory-systems/
    รวมถึงมีการสรุปสิ่งที่อยากได้จากระบบแบบนี้ไว้ด้วย: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/

  • agent memory systems แบบนี้ดูทั้งออกแบบเกินไปและในขณะเดียวกันก็ออกแบบไม่พอ แถมยังดูเหมือนทางตันพอสมควร
    ผมนึกภาพไม่ออกเลยว่ามันจะไม่หลุดจากสิ่งที่โมเดลรุ่นใหม่ต้องการ และไม่เสื่อมสภาพไปอย่างรวดเร็วได้ยังไง
    เช่น แค่เคยทำระบบจ่ายเงินครั้งหนึ่ง เมมโมรีอย่าง don't use stripe ก็อาจทำให้หลายเซสชันถัดไปเอนเอียงไปทางงานจ่ายเงินตลอด

    • ที่แย่กว่านั้นคือดูเหมือนคนเขียนเองก็แทบไม่ได้ใช้มันจริงด้วยซ้ำ
      มันเป็น memory layer ที่ยังไม่ผ่านการพิสูจน์ และให้ความรู้สึกเหมือนมีแต่เว็บการตลาดหรู ๆ พร้อมคำกล่าวอ้างเกินจริงโดยไม่มีของจริง
    • ผมมองว่านี่เป็น ปัญหาด้านข้อมูล เลยทำยูทิลิตีเล็ก ๆ ที่ตั้งใจจะไม่เก็บเกือบทุกอย่าง: https://github.com/skorokithakis/gnosis
      สมมติฐานเรียบง่ายมาก: สิ่งที่ LLM รู้อยู่แล้วมันก็จะรู้อยู่ต่อไป ดังนั้นสิ่งที่ LLM พูดเองไม่ต้องเก็บ ส่วนเรื่องที่เกี่ยวกับโค้ดก็ปล่อยไว้ในโค้ดและคอมเมนต์ได้
      แต่ก็ยังมีบางอย่างที่ไม่ใช่ทั้งสองแบบและไม่ถูกจับไว้เลย
      เวลาสร้างอะไรขึ้นมา บ่อยครั้งสิ่งที่ ตัดสินใจไม่ทำ สำคัญกว่าสิ่งที่ทำจริง และยูทิลิตีนี้จะจับทางเลือกที่ถูกปัดทิ้งตอนท้ายเซสชันพร้อมเหตุผล แล้วเก็บเป็น system knowledge
      สุดท้ายสิ่งที่อยากเก็บไว้คือข้อมูลที่ grep จากโค้ดอย่างเดียวหาไม่เจอ เป็นพวกความรู้ที่อยู่แต่ในหัวเพื่อนร่วมทีม ซึ่งจนถึงตอนนี้ก็ค่อนข้างได้ผล แต่ก็ยังเร็วเกินไปจะสรุป
    • ผมใช้ bespoke memory system ที่ทำเอง โดยทำให้ทุกเมมโมรีเป็นพื้นที่ค้นหาตามบริบท จึงหลีกเลี่ยงปัญหานี้ได้
      เมมโมรีอย่าง don't use stripe จะเข้ามาในคอนเท็กซ์ก็ต่อเมื่อโมเดลได้รับพรอมป์ให้ทำงานที่เกี่ยวกับ payment processing เท่านั้น

  • ผมหาสิ่งแบบนี้อยู่เรื่อย ๆ และก็ดีใจที่เห็นว่าบัญชีนี้ปล่อยซอฟต์แวร์สาธารณะมาตั้งแต่ ก่อนยุค LLM บูม
    แต่อยากให้แต่ละโปรเจกต์มีอะไรอย่าง ประวัติการใช้ LLM ติดมาด้วย
    เช่น สร้างด้วย LLM หรือไม่ ถ้าใช่ใช้มากแค่ไหน ใช้ในขั้นตอนไหน ตรวจผลลัพธ์ละเอียดแค่ไหน และรู้สึกว่าคุณภาพอย่างน้อยเท่ากับหรือดีกว่าตอนทำคนเดียวไหม
    ไม่ได้จะสงสัยใครเป็นพิเศษ แค่อยากให้เป็นข้อมูลมาตรฐานของทุกโปรเจกต์ และผมเองก็ตั้งใจจะทำแบบนั้นด้วย

    • พูดตรง ๆ ว่ามันฟังดู entitled นิดหน่อย
      ไม่มีใครบังคับให้ใครใช้โปรเจกต์นี้อยู่แล้ว จะใช้หรือไม่ใช้ก็อ่านโค้ด ตรวจเอง แล้วตัดสินใจเองได้
    • คำถามนี้สมเหตุสมผล แต่ผมไม่คิดว่าควรปล่อยให้ตอบด้วย การรายงานตัวเอง อย่างเดียว
      คงมีไม่กี่คนที่จะยอมรับตรง ๆ ว่าแทบไม่ได้ออกแบบ ไม่ได้ทดสอบ และโค้ดคุณภาพไม่ดี
      บางทีอาจต้องมีระบบจากบุคคลที่สามที่คอยตอบคำถามพวกนี้แทน ซึ่งแน่นอนว่าถ้าเป็นระบบฐาน LLM เองก็อาจจะค่อนข้างอัตวิสัยเหมือนกัน
    • วิธีใช้ LLM ทำซอฟต์แวร์มีได้หลากหลายมาก
      ช่วงนี้ผมทำโปรเจกต์ส่วนใหญ่โดยยึด ไฟล์ Markdown หลายไฟล์ เป็นแกน ใช้ AI เพื่อค้นคว้าก่อน วางแผน และติดตามความคืบหน้าการ implementation
      ส่วน implementation ก็ทำตามแผนแบบทีละขั้น พร้อมทบทวนต่อเนื่องทุกขั้น
      ถ้าจะให้เอกสารเวิร์กโฟลว์ของผม ไฟล์เหล่านั้นก็คือนั่นแหละ
      โค้ด 99% ถูก generate แต่ผมใส่ใจมากให้มันถูก generate ในแบบที่ผมพอใจ และผลลัพธ์ก็บ่อยครั้งดีกว่าที่ผมทำเองล้วน ๆ
    • ผมไม่ค่อยเข้าใจว่าทำไมเรื่องนี้ถึงสำคัญ
      ซอฟต์แวร์ที่ดี และซอฟต์แวร์ที่แย่ สร้างได้ทั้งแบบไม่ใช้ LLM และใช้ LLM
      เราไม่ถามช่างไม้ว่าใช้ค้อนหรือ nail gun หรือใช้เครื่องมือไหนกับหลังคาและอันไหนกับเด็ค
      ถ้าไม่มีฐานความเชื่อใจ สุดท้ายก็ต้องตรวจคุณภาพเองหรือไม่ก็สร้างเองอยู่ดี นอกนั้นก็ใกล้เคียงกับการหวังเอาเองมากกว่า

  • ผมยังไม่เจอ memory ที่ใช้งานได้จริง
    แบบหนึ่งเหลือไว้แค่สรุประดับสูงอย่าง agents.md เลยไม่ช่วยเรื่องรายละเอียดเฉพาะ เช่น ถ้าแก้องค์ประกอบนี้ ต้องทำให้อีกองค์ประกอบแสดงเป็น draft
    แต่อีกแบบที่ละเอียดเกินไปก็ทำให้ข้อมูลจุกจิกจนถูกเมิน หรือทำให้รายละเอียดจากฟีเจอร์หนึ่งไปปนเปื้อนตอนแก้อีกฟีเจอร์หนึ่ง
    ท้ายที่สุดสิ่งที่ได้ผลที่สุดสำหรับผมจนถึงตอนนี้คือ ไม่ใช้เมมโมรีเลย แต่คัดคอนเท็กซ์ที่สำคัญกับเซสชัน/พรอมป์นั้นด้วยมือ

    • ผมสนใจเรื่องเมมโมรีมาก แต่ถ้าอย่างน้อยในฐานะ เครื่องมือสำหรับเขียนโค้ด ผมยังไม่เห็นว่ามันมีประโยชน์เท่าไร
      source of truth ว่า repo ทำอะไรและควรทำอะไร สุดท้ายก็คือ ตัว repo เอง
      สิ่งที่คุณพูดมาดูใกล้กับแนวทาง code review มากกว่า และของแบบนั้นควรถูกใส่เข้าไปในคอนเท็กซ์แบบ explicit ตามจังหวะการเปลี่ยนแปลง
      เมื่อเทียบกันแล้วระบบเมมโมรีซับซ้อนเกินไปและแม่นยำน้อยกว่า
    • wishlist สำหรับระบบแบบนี้อยู่ที่นี่: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
    • ผมก็รู้สึกคล้ายกัน
      สงสัยว่าในสักวันโมเดลพวกนี้จะมี continual learning ไหม
      ตอนนี้มันฉลาดพอแล้ว แต่การไม่มีเมมโมรีจริง ๆ ทำให้ใช้งานลำบาก
    • เมมโมรีที่ Claude สร้างให้แทบทั้งหมดเป็นแนว remember-to-not-forget เลยสุดท้ายผมปิดฟีเจอร์นี้ไป

  • สำหรับผม ของง่าย ๆ ไม่กี่อย่างกลับได้ผลดีมาก โดยอิงเครื่องมือเป็น Codex

    1. functional specification ที่ละเอียดและอัปเดตเสมอ
    2. codebase ที่จัดโครงสร้างเป็นหลายโปรเจกต์
    3. โค้ดที่ตั้งชื่อดีและมีเอกสารประกอบดี ชื่อคลาส ตัวแปร ฟังก์ชัน จะยาวหรือดูตลกแค่ไหนก็ได้ แต่ต้องสื่อจุดประสงค์ชัดเจน และผมใส่กฎพวกนี้ไว้ใน coding guideline ของ Agent.md
      functional spec ของผมทำหน้าที่เป็น Project.md ให้เอเจนต์
      และก่อนทำ agentic code review ทุกครั้ง ผมจะสร้าง directory tree ของโปรเจกต์ แล้วรวมมันกับ codebase เป็นไฟล์เดียว จากนั้นใส่ timestamp ไว้ในชื่อไฟล์
      เรื่องนี้สำคัญกว่าที่คิด เพราะช่วยลดการที่ LLM ไปอ้างอิงเวอร์ชันเก่า และยังช่วยให้ดู diff ได้เร็วโดยไม่ต้องส่ง git ไปทั้งก้อน
      จนถึงตอนนี้เวิร์กโฟลว์เรียบง่ายแบบนี้ก็ทำงานได้ดีมาก แม้กับ codebase ขนาดใหญ่และซับซ้อน
      มันไม่ค่อยประหยัด token แต่ใช้ได้ผลจริง
      ไม่จำเป็นต้องรวมทั้ง codebase ทุกครั้งก็ได้ โปรเจกต์ที่เสร็จแล้ว ทดสอบแล้ว หรือไม่เกี่ยวกับงานปัจจุบันสามารถตัดออก
      แต่ยังควรใส่ไว้ใน printed directory tree เพื่อให้เอเจนต์รู้ว่าอย่างน้อยมันมีอยู่ และสามารถขอไฟล์เฉพาะเพิ่มได้ถ้าจำเป็น
    • แนวทางน่าสนใจดี
      ผมอยากรู้ว่าคุณทำ งานรวมไฟล์ นั้นยังไง
      เป็นแบบทำมือ รวมเฉพาะไฟล์ที่เปลี่ยน หรือเป็นแบบผสมกัน

  • LLM memory ฟังดูดีในทางทฤษฎี แต่ในทางปฏิบัติพอมันใหญ่ขึ้นก็เละพอ ๆ กับตอนทำงานแบบไม่มีเมมโมรี
    อย่างตัวอย่างหน้าแรกที่บอกว่า ช่วยทำโปรเจกต์ของฉันต่อ แต่ความจริงคนส่วนใหญ่ไม่ได้ทำแค่โปรเจกต์เดียว
    อาจมี 5 หรือ 10 โปรเจกต์อยู่ในเมมโมรี และแต่ละอันก็คงมีเหตุผลตอนที่ถูกเก็บไว้
    สุดท้ายคุณก็ยังต้องระบุใหม่อยู่ดี เช่น ช่วยทำโปรเจกต์ sass ต่อ โดยแลกกับการได้บริบทเฉพาะเพิ่มนิดหน่อย แต่ต้องเอา LLM context ไปเติม และยังต้องจ่ายค่า MCP calls เพิ่ม

    • ก็จริง แต่แบบนี้มันเป็น implementation ที่ naive เกินไป
      ถ้าทำ implementation ดี ๆ ก็น่าจะไปไกลกว่าข้อจำกัดนี้ได้
    • ท้ายที่สุดพอคุณเริ่มระบุอย่างเจาะจงว่าต้องจำอะไรบ้าง มันก็แทบไม่ต่างจากสั่งให้ AI write/read ผ่านไฟล์อยู่ดี

  • อ่านแล้วเหมือนมันมีไว้เพื่อ vibecoder ที่ทำงานคนเดียวหรือเปล่า
    ถ้าทำโปรเจกต์จริงกับคนจริง ระบบนี้ไม่มีทางมีเมมโมรีทั้งโปรเจกต์ได้ และผมเองก็ไม่ได้มีเมมโมรีทั้งหมดของโปรเจกต์เหมือนกัน
    พอมี PR อื่น merge เข้ามา สิ่งที่ผมจำไว้ก็ล้าสมัยทันที และสิ่งที่ผมสนใจก็มีแค่ ticket ของตัวเอง
    เลยยิ่งรู้สึกว่าของแบบนี้อาจไม่ใช่เครื่องมือสำหรับงานร่วมกันลักษณะนั้น

  • ตอนนี้ต้นทุนการสร้างซอฟต์แวร์แทบจะใกล้ศูนย์อยู่แล้ว แต่ก็ยังน่าแปลกที่ยังมีคนพยายามขายของแบบนี้ผ่าน เว็บการตลาดที่ vibe-coded
    ผมไม่แน่ใจว่าใครจะมีเวลาลองใช้ แล้วรอเป็นสัปดาห์หรือเป็นเดือนเพื่อดูว่ามันเวิร์กจริงไหม
    ในเว็บไม่มีตรงไหนแสดงหลักฐานเลยว่ามันดีกว่า RAG หรือดีกว่าแค่มีโฟลเดอร์เก็บไฟล์เมมโมรีกับ grep ธรรมดา
    แต่กลับมีแต่คำกล่าวอ้างเกินจริงเต็มไปหมด แถมสโครลยังหน่วงแค่ 14fps
    มันดูเหมือนของที่โค้ดเสร็จเมื่อ 24 ชั่วโมงก่อน และพูดตรง ๆ ว่ารู้สึกขี้เกียจมาก