GBrain: second brain ของ AI agent ที่ไม่ใช่แค่ค้นโน้ต

ปัญหาไม่ใช่ไม่มีโน้ต แต่ agent ใช้ไม่ออก

คนทำงานยุค agent มักสะสมความรู้ไว้หลายที่

• โน้ตส่วนตัวใน Obsidian หรือ Notion
• สรุปประชุมในแชท
• playbook ใน GitHub
• บทเรียนจากเคสลูกค้าในหัวคนเดียว

พอถาม AI agent เรื่องเดิมซ้ำ มันตอบได้บ้าง หลอนบ้าง หรือขอให้ส่งไฟล์ใหม่ทุกครั้ง

ปัญหาไม่ใช่ “เรายังไม่เก่ง prompt”

ปัญหาคือยังไม่มี brain layer ที่ agent เรียกใช้ได้ตอนทำงานจริง

GBrain คืออะไรในภาษาคนทำงาน

GBrain เป็น open source project ของ Garry Tan (YC) ที่ออกแบบให้ AI agent เป็นคนดูแล brain และให้ MCP client เป็นคนถาม brain

จาก README ทางการ จุดขายหลักมีประมาณนี้

1. ไม่หยุดที่รายการหน้า

เครื่องมือ second brain หลายตัวคืน 5-10 หน้าให้คุณไปอ่านเอง GBrain ตั้งเป้าคืนคำตอบที่สังเคราะห์แล้ว พร้อมแหล่งอ้าง และบอกช่องว่างว่า brain ยังไม่รู้อะไร

1. Hybrid search + graph

รวม vector search, keyword, ranking และสัญญาณจาก knowledge graph ทำให้คำถามแนว “ใครเกี่ยวอะไรกับโปรเจกต์นี้” ไปได้ไกลกว่ารายการ chunk เปล่า ๆ

1. ติดตั้งและคุยแบบ agent-native

มี CLI ให้คนและสคริปต์ใช้ มี MCP server ให้ Claude Code, Codex, Hermes หรือ agent อื่นเรียก tool ตรง ๆ

1. สอง engine ภายใต้สัญญาเดียวกัน

• PGLite: เริ่มเร็ว ไม่ต้องตั้ง Postgres เหมาะ personal brain เริ่มต้น
• Postgres + pgvector: ตอน brain ใหญ่ขึ้น แชร์ข้ามเครื่อง หรือต้อง concurrent จริงจัง

สรุปสั้น ๆ

GBrain ไม่ได้มาแทนที่การคิดของคุณ แต่มาแทนที่นิสัยให้ agent “เริ่มจากศูนย์ทุกเช้า”

ทำไมผมแนะนำให้ลองตอนนี้

ในความเห็นของผม timing ดี เพราะคนไทยเริ่มใช้ coding agent และ personal agent หนาขึ้น

แต่ส่วนใหญ่ยังติด 3 กับดักนี้

1) เก็บโน้ตเก่ง แต่ retrieval ยังเป็นงานคน

มี vault สวย ไม่ได้แปลว่า agent หาเจอตอนทำงาน

ถ้าทุกครั้งต้องแปะไฟล์เข้าแชท แปลว่า second brain ยังเป็นคลังคนอ่านอยู่

2) ใช้ chat memory แทน knowledge system

memory ในเซสชันช่วยได้ระยะสั้น แต่ playbook, ลูกค้า, สถาปัตยกรรม, และบทเรียนจากงานจริง ควรอยู่ชั้นที่ sync และค้นซ้ำได้

3) ติดตั้ง MCP แล้วคิดว่าจบ

MCP คือสายพูดของ agent กับ brain ยังไม่ใช่คำตอบเรื่อง

• ใครเป็น source of truth
• sync วันละกี่รอบ
• เปิด serve ค้างไว้แล้ว CLI/cron ทำอะไรได้บ้าง
• backup / rollback อยู่ไหน

ถ้าข้ามชั้นนี้ second brain จะสวยในเดโม แล้วพังในวันที่สอง

บทเรียนจากของจริง: single-writer ชน agent ที่ออนไลน์ตลอด

ประเด็นนี้มีหลักฐานสองชั้นที่ต้องแยกกันครับ

• ข้อเท็จจริงสาธารณะที่ทำซ้ำได้: เอกสารทางการเรื่อง gbrain serve กับ gbrain sync บน PGLite ระบุว่า PGLite เป็น single-writer, process serve ที่ยังเปิดอาจแย่ง write lock กับ sync, และข้อจำกัดนี้ไม่ใช้กับ Postgres engine
• หลักฐาน operator ในเครื่อง: การย้าย engine, ผล concurrent search, สถานะ doctor และ topology ที่ผมใช้จริงเป็น proof จากระบบ local วันที่ 27 กรกฎาคม 2026 ซึ่งตัด path, host, key, ชื่อ profile และจำนวนหน้าภายในออกจากบทความสาธารณะ

จากที่ผมลองใช้ GBrain กับ agent stack จริง จุดพังแรกไม่ใช่คุณภาพ embedding

แต่เป็น concurrency

ภาพที่เกิดบ่อย:

1. เปิด gbrain serve ให้ Hermes หรือ coding agent เรียก MCP ได้ทั้งวัน
2. ตอนเย็นหรือเช้ามีงาน sync โน้ต/wiki เข้า brain
3. หรืออยากรัน CLI search / doctor ระหว่าง agent ยัง online
4. ถ้า engine ยังเป็น PGLite แบบ single-writer งานหลังบ้านจะชน lock

อาการที่คนเจอ:

• CLI บอกว่า database ถูกเปิดอยู่แล้ว
• daily sync ต้องฆ่า serve ก่อน แล้ว MCP ของ agent กระพริบหาย
• หลายโปรไฟล์ agent เปิด serve คนละ process แล้วแย่ง writer

ตรงนี้สำคัญมาก

การมี MCP ไม่ได้แก้ปัญหา storage concurrency ให้เอง

MCP แก้แค่ “agent เรียก brain ยังไง” ยังไม่แก้ “ใครเขียน/อ่านพร้อมกันได้แค่ไหน”

เลยได้กฎที่ใช้ซ้ำได้:

ถ้า brain ต้องทั้ง online ให้ agent และถูกดูแลด้วย CLI/cron ทุกวัน อย่าออกแบบรอบ single-writer lock

ทางออกที่ผมใช้แล้วไปต่อได้:

• ย้าย engine ไป Postgres + pgvector บนเครื่องตัวเองตอนยังเป็น personal brain
• ให้ config engine อยู่ที่เดียว ทุก agent profile ชี้ชุดเดียวกัน
• daily sync วิ่งได้โดยไม่ต้องปิด serve
• เก็บ PGLite ไว้เป็น rollback ช่วงแรก ไม่ต้องทิ้งทางหนีทีไล่

หลังย้าย สิ่งที่ต้อง proof ไม่ใช่สไลด์ architecture

แค่ข้อนี้ก็พอเริ่ม:

ตอน serve ยังเปิดอยู่ CLI search ต้องได้ผล และ agent เรียก MCP ได้ในเวลาใกล้เคียงกัน

แผนที่ Second Brain Stack ที่ผมแนะนำ

อย่าเริ่มจาก “ยัดทุกอย่างลง vector DB”

ใช้ 3 ชั้นนี้ก่อน

ชั้น 1) Source of truth = ไฟล์ที่คนอ่านและแก้ได้

เช่น markdown wiki / Obsidian vault / repo docs

ชั้นนี้ตอบคำถาม:

• ความจริงล่าสุดอยู่ไฟล์ไหน
• ใครแก้ได้
• diff/history ดูยังไง

ชั้น 2) Brain index = GBrain

ชั้นนี้ตอบคำถาม:

• agent ค้นอะไรเจอเร็ว
• สังเคราะห์คำตอบจากหลายหน้าได้ไหม
• อ้าง slug/แหล่งกลับมาได้ไหม
• graph ช่วยเชื่อมคน โปรเจกต์ บทเรียนได้ไหม

ชั้น 3) Agent runtime = Hermes / Claude Code / Codex / team bots

ชั้นนี้ตอบคำถาม:

• งานไหนเรียก brain ก่อนตอบ
• tool ไหนเปิดให้ read/search
• งานไหนห้ามให้ agent เขียนทับ SoT มั่ว

กฎสั้น ๆ ที่ช่วยลดความสับสน:

ชั้น	ทำ	ไม่ทำ
Wiki / files	เก็บความจริงที่คนดูแล	ไม่ใช่แค่ dump แชทดิบทั้งก้อน
GBrain	index, search, synthesize สำหรับ agent	ไม่แย่งเป็น SoT หลักของเอกสาร
Agent	ใช้ brain ตอนทำงาน	ไม่จำทุกอย่างแค่ใน thread

ถ้าสลับชั้น เช่น ให้ chat memory เป็น SoT หรือให้ vector DB เป็นที่แก้เอกสารหลัก ระบบจะเริ่ม drift เร็วมาก

เริ่มยังไงใน 7 วันโดยไม่ overbuild

วันที่ 1-2: เลือกคลังความรู้แคบ ๆ

อย่า sync ทั้งชีวิตเข้าไปวันแรก

เริ่มจากชุดที่ใช้ซ้ำจริง เช่น

• playbook งานซ้ำ
• โปรไฟล์ผลิตภัณฑ์/บริการ
• โน้ตลูกค้า active 2-3 ราย
• สถาปัตยกรรมระบบที่ทีมอ้างบ่อย

วันที่ 3: ติด GBrain แบบ personal ก่อน

ใช้ทางเริ่มต้นของโปรเจกต์ได้ (PGLite เหมาะลองเร็ว)

เป้าหมายวันนั้นมีแค่:

• sync ชุดความรู้ชุดแรกเข้า brain
• search คำที่คุณรู้คำตอบแล้ว แล้วดูว่าเจอหน้าถูกไหม
• ต่อ MCP เข้า agent ตัวหลัก 1 ตัว

วันที่ 4: บังคับให้ agent ถาม brain ก่อนเดา

อย่าเพิ่งให้ agent เขียนโน้ตทั้งวัน

ให้ rule ง่าย ๆ:

1. ก่อนตอบเรื่องภายในบริษัท เรียก search/query ก่อน
2. ถ้า brain ไม่มี บอกว่ายังไม่มี แล้วค่อยถามคน
3. ทุกคำตอบสำคัญต้องมีแหล่งหรือ slug กลับมาได้

วันที่ 5: ใส่ daily sync

second brain ที่ไม่มีจังหวะเติมของจะเน่า

อย่างน้อยมีสคริปต์หรือ checklist รายวัน:

• ดึงไฟล์ที่ curate แล้ว
• sync เข้า brain
• รัน search smoke 1 คำ
• ถ้า fail ต้องมี alert ไม่ใช่เงียบ

วันที่ 6: บททดสอบ concurrency

เปิด MCP serve ทิ้งไว้ แล้วลองงานหลังบ้าน

ถ้า search/sync พังเพราะ lock:

• บันทึกอาการ
• ตัดสินใจย้าย Postgres + pgvector
• อย่าแก้ด้วยการ “เลิก sync แล้วกัน” เพราะเดี๋ยว brain ล้า

วันที่ 7: ตัดขอบเขตการเขียนของ agent

ตอนนี้ค่อยเปิดสิทธิ์เขียนทีละน้อย

เช่น

• อนุญาต draft โน้ตใหม่ใน inbox
• ไม่อนุญาตแก้ playbook หลักเองโดยไม่มีคนรับ
• ทุกหน้าสำคัญต้องมีคนหรือ rule ตรวจ

ทีมเล็กไม่ต้องมี company brain แสนหน้าก่อนมีวินัย 7 วันนี้

Operator Kit

Mini playbook: Brain Concurrency Card

คัดลอกไปใส่ Linear, Notion หรือ GitHub issue ตอนเริ่ม second brain สำหรับ agent ได้เลย

A) ข้อมูลตั้งต้น

• Brain tool / version: เช่น GBrain 0.42.x
• Engine ตอนนี้: PGLite / Postgres+pgvector / อื่น
• SoT path หรือ repo:
• Agent runtime ที่ต่อ MCP:
• Daily sync มีไหม: ใช่/ไม่
• Owner:
• Date:

B) บัตรตรวจ 5 ช่อง

1. Source of truth

• [ ] รู้ว่าไฟล์/หน้าไหนคือความจริงล่าสุด
• [ ] ไม่ยัด secrets หรือ dump ส่วนตัวทั้งก้อนเข้า brain
• [ ] มีคนหรือ process รับผิดชอบ curate
• [ ] agent ไม่ได้เป็น writer หลักของเอกสารสำคัญ

2. Retrieval quality

• [ ] มีชุดคำถามทดสอบ 5 ข้อที่รู้คำตอบแล้ว
• [ ] search เจอหน้าถูกอย่างน้อยในคำถามหลัก
• [ ] คำตอบสำคัญอ้างแหล่ง/slug กลับมาได้
• [ ] เคสที่ brain ไม่รู้ ต้องพูดว่ายังไม่รู้ ไม่ใช่แต่ง

3. MCP / agent path

• [ ] agent หลักเรียก brain tool ได้จาก session จริง
• [ ] เปิดเฉพาะ tool ที่จำเป็น (search/query/read) ก่อน
• [ ] มี rule ให้ถาม brain ก่อนเดาเรื่องภายใน
• [ ] โปรไฟล์ agent หลายตัวไม่สร้าง config แตกเป็นคนละความจริง

4. Concurrency และ sync

• [ ] รู้ว่าตอน serve เปิดอยู่ CLI/cron ทำอะไรได้บ้าง
• [ ] daily sync ถูกลองตอน agent online
• [ ] ถ้าเจอ single-writer lock มีแผนย้าย Postgres+pgvector
• [ ] ไม่ใช้วิธี “ปิด brain ตอน sync” เป็นคำตอบถาวร ถ้าทีมพึ่ง agent ทั้งวัน

5. Proof และ rollback

• [ ] มี backup ก่อน migrate engine
• [ ] มีคำสั่ง proof สั้น ๆ หลังเปลี่ยนระบบ
• [ ] รู้ version/tag ที่ rollback ได้
• [ ] fail แล้วมี log หรือ alert ไม่เงียบทั้งวัน

C) เกณฑ์ผ่านแบบทีมเล็ก

ผ่านเมื่อครบทุกข้อนี้:

1. คนหาเอกสารต้นทางเจอใน SoT ภายใน 1 นาที
2. agent เรียก brain ได้โดยไม่ต้องแปะไฟล์ทุกครั้ง
3. search ตอน serve online ผ่าน
4. daily sync ผ่านอย่างน้อย 1 รอบโดยไม่ทำ MCP พังทั้งเช้า
5. มี rollback/backup ก่อนแตะ engine

D) ประโยคสั้น ๆ ใส่ ticket

เขียน 3 บรรทัดนี้:

1. รอบนี้ตั้ง brain เพื่องานอะไร: meeting prep / support / coding context / founder ops
2. สิ่งที่เคยพังและต้องกันซ้ำ: lock, sync, hallucinate without source, dual SoT
3. หลักฐานผ่าน: ผล search, บันทึก concurrent test, หรือลิงก์ sync log

ใช้ GBrain เมื่อไหร่ และเมื่อไหร่ยังไม่ต้อง

เหมาะถ้าคุณ

• ใช้ AI agent ทำงานจริงทุกวัน ไม่ใช่แค่ลองแชท
• มี knowledge ที่กระจายหลายที่ แล้วเสียเวลามากับการป้อนบริบทซ้ำ
• อยากได้ชั้น search/synthesize ที่ agent เรียกผ่าน MCP ได้
• พร้อม curate เอกสารบ้าง ไม่ได้คาดหวังว่า dump ทุกอย่างแล้วจะฉลาดเอง

ยังไม่ต้องรีบถ้าคุณ

• ยังไม่มีคลังความรู้ขั้นต่ำที่คนอ่านเองยังหาไม่เจอ
• ยังไม่มีงานซ้ำที่ agent ควรช่วย
• ต้องการแค่ chatbot ตอบ FAQ เว็บสาธารณะ (อาจเริ่มจาก KB เว็บธรรมดาก่อน)
• ยังไม่มีเวลารับ daily sync และ backup เลยสักนิด

GBrain ช่วยคนที่มีวัตถุดิบและความถี่ในการใช้ agent ไม่ใช่ยาวิเศษสำหรับทีมที่ยังไม่จดอะไรเลย

Caveat: สิ่งที่ยังต้องระวัง

1. ตัวเลข production ระดับแสนหน้าใน README เป็นของโปรเจกต์ต้นทาง

ทีมเล็กควรเริ่มจากชุดความรู้แคบ ๆ แล้ววัดคุณภาพคำตอบ ไม่ใช่แข่งจำนวนหน้า

1. embedding แพงและพังได้

ถ้าเส้น embed มีปัญหา ยังควรมี keyword search และการ curate ไฟล์เป็นทางรอด ไม่ให้ brain ตายทั้งก้อน

1. graph และ synthesis คุณภาพดีแค่ไหน ขึ้นกับของที่ใส่เข้าไป

ขยะเข้า ขยะออก ยังจริงอยู่ แม้ tool จะฉลาดขึ้น

1. company brain กับ personal brain คนละระดับสิทธิ์

ถ้ายกไปใช้ทีม ต้องคิดเรื่อง scoping, secrets, และสิ่งที่ agent แต่ละบทบาทเห็นได้ บทความนี้โฟกัสการเริ่ม personal/operator brain ให้ถูกทางก่อน

1. บทเรียน concurrency ในที่นี้มาจากเคส operator จริงบน GBrain + MCP

engine อื่นอาจพังคนละจุด แต่คำถามกลางเหมือนกัน: online agent กับงานดูแล brain ทำพร้อมกันได้ไหม

สรุป

ในความเห็นของผม GBrain ได้ 9/10 ในฐานะตัวเลือกที่คนใช้ AI agent ควรรู้จักตอนนี้

ไม่ใช่เพราะชื่อดังหรือฟีเจอร์แน่นที่สุดในสไลด์ แต่เพราะมันจับ pain จริง: agent ขาด brain layer ที่ค้น สังเคราะห์ อ้างแหล่ง และถูกเรียกผ่าน MCP ได้

ถ้าคุณเพิ่งเริ่ม อย่าเริ่มจาก architecture ใหญ่

เริ่มจาก Second Brain Stack 3 ชั้น แล้วใช้ Brain Concurrency Card 5 ช่อง

สุดท้าย second brain ที่ดี ไม่ใช่ vault ที่สวยบนหน้าจอคนครับ แต่คือชั้นที่ agent ถามแล้วได้คำตอบ ขณะที่คุณยังทำงานต่อได้โดยไม่ต้องปิดระบบทุกครั้งที่ sync

ถ้าอยากให้ Data-Espresso ช่วยแปลง AI tools แบบนี้เป็น workflow/checklist ที่ทีมเล็กเอาไปใช้ต่อ ติดตามได้เรื่อย ๆ หรือคุยต่อที่ OPB Stack เมื่อพร้อมทำให้ AI coworker อยู่ใน sandbox/workflow จริงของธุรกิจ