สถานะปัจจุบันของ Agent Wikis

ในเดือนเมษายน 2026 Andrej Karpathy ได้เขียน GitHub Gist ขึ้นมา เขาอธิบายวิธีการหนึ่งในนั้น เขาเรียกวิธีการนี้ว่า LLM Wiki

หลังจากนั้น สี่ทีมก็สร้างสิ่งเดียวกัน Cognition สร้าง DeepWiki Factory สร้าง AutoWiki LangChain ปล่อย OpenWiki Garry Tan ปล่อย GBrain

วิธีการนี้เหมือนกันในทั้งสี่ระบบ LLM อ่านเอกสารต้นฉบับของคุณหนึ่งครั้ง มันเขียนข้อมูลลงในหน้า markdown มันทำให้หน้าต่างๆ ถูกต้องเมื่อแหล่งข้อมูลเปลี่ยนแปลง เอเจนต์อ่านหน้าเหล่านี้ เอเจนต์ไม่ต้องอ่านเอกสารต้นฉบับอีกสำหรับแต่ละคำถาม

ผู้คนเรียกระบบเหล่านี้ว่า agent wikis บทความนี้จะบอกคุณว่ามันคืออะไร มันบอกคุณว่าแต่ละทีมสร้างอะไร มันบอกคุณถึงข้อจำกัดของวิธีการนี้ และมันยังบอกถึงความแตกต่างสำคัญหนึ่งอย่างที่หลายคนมองข้าม

แนวคิด: คอมไพล์เมื่อรับข้อมูล ไม่ใช่เมื่อค้นหา

วิธีการปกติในการให้โมเดลเข้าถึงเอกสารชุดใหญ่คือการค้นคืน (retrieval) คุณใส่เอกสารลงในฐานข้อมูล คุณแบ่งเอกสารออกเป็นส่วนๆ คุณสร้าง embeddings สำหรับแต่ละส่วน สำหรับแต่ละคำถาม ระบบจะหาส่วนที่เกี่ยวข้อง

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

Agent wiki ย้ายค่าใช้จ่ายนี้ โมเดลทำงานเพียงครั้งเดียว เมื่อมันอ่านแหล่งข้อมูล มันเขียนผลลัพธ์ลงในหน้า หน้าต่างๆ ยังคงอยู่

โมเดลจะทำตามขั้นตอนเหล่านี้เมื่อมีแหล่งข้อมูลใหม่เข้ามา มันอ่านแหล่งข้อมูล มันเปลี่ยนหน้าที่เกี่ยวข้อง มันแก้ไขบทสรุป มันทำเครื่องหมายข้อมูลที่ขัดแย้งกับหน้า

ทั้งสองวิธีถูกต้อง มันต่างกันสองอย่าง ความแตกต่างแรกคือเมื่อคุณจ่ายค่าใช้จ่าย ความแตกต่างที่สองคือสิ่งที่ยังคงอยู่หลังจากคำถาม

แต่ละระบบมีสามชั้นเหมือนกัน

ชั้นที่ 1 คือเอกสารต้นฉบับ เหล่านี้คือบทความ เอกสาร และ repositories ของคุณ โมเดลอ่านมัน โมเดลไม่เปลี่ยนแปลงมัน

ชั้นที่ 2 คือ wiki wiki คือ markdown โมเดลเขียน wiki ทั้งหมด wiki ประกอบด้วยบทสรุป หน้าสำหรับแต่ละหัวข้อ และลิงก์ระหว่างหน้า

ชั้นที่ 3 คือไฟล์ schema ไฟล์นี้บอกโครงสร้างของ wiki แก่โมเดล มันยังบอกโมเดลว่างานใดที่ต้องทำ ไฟล์ปกติคือ CLAUDE.md หรือ AGENTS.md ไฟล์นี้ทำให้โมเดลเป็นผู้ดูแล wiki ที่ถูกต้อง

ระบบดำเนินการสามอย่าง

Ingest: โมเดลอ่านแหล่งข้อมูลใหม่ จากนั้นโมเดลเขียนข้อมูลลงในแต่ละหน้าที่เกี่ยวข้อง

Query: คุณถามคำถามกับ wiki คุณสามารถเขียนคำตอบที่ดีกลับเข้าไปใน wiki เป็นหน้าใหม่

Lint: โมเดลตรวจสอบ wiki มันหาข้อมูลที่ขัดแย้งกัน มันหาข้อมูลที่เก่าเกินไป มันหาหน้าที่ไม่มีลิงก์

ทำไมมันถึงได้ผล:

Wiki ของมนุษย์จะไม่ถูกต้องตามกาลเวลา สาเหตุนั้นเฉพาะเจาะจง ส่วนที่ยากไม่ใช่การอ่านแหล่งข้อมูล ส่วนที่ยากไม่ใช่การมีไอเดีย ส่วนที่ยากคือการบำรุงรักษา

การบำรุงรักษามีงานเหล่านี้ คุณต้องแก้ไขลิงก์ระหว่างหน้า คุณต้องทำให้บทสรุปถูกต้อง คุณต้องเปรียบเทียบเอกสารใหม่แต่ละฉบับกับหน้าที่มีอยู่

งานนี้ไม่หยุด งานนี้ไม่ให้รางวัล ทีมที่ยุ่งจะหยุดงานนี้ก่อน จากนั้น wiki ก็ไม่ถูกต้อง จากนั้นผู้คนก็ไม่ใช้มัน

โมเดลทำงานนี้ได้โดยไม่มีปัญหา โมเดลไม่เบื่อ โมเดลไม่ลืมลิงก์ โมเดลสามารถเปลี่ยนไฟล์สิบห้าไฟล์ในการดำเนินการเดียว

แนวคิดนี้เก่าแล้ว Vannevar Bush อธิบาย Memex ในปี 1945 Memex คือคลังเก็บเอกสารส่วนตัวที่มีลิงก์ระหว่างกัน Bush ไม่มีคำตอบสำหรับการบำรุงรักษา โมเดลคือคำตอบ

ที่มาของชื่อ

อ่าน Karpathy gist โดยตรง มันแม่นยำกว่าบทสรุปของมัน

เขาเขียนเกี่ยวกับวิธีการปกติว่า: "LLM กำลังค้นพบความรู้ใหม่จากศูนย์ในทุกคำถาม ไม่มีการสะสม"

วิธีการของเขาคือการคอมไพล์ข้อมูล ไม่ใช่การค้นคืน แล้ว "ความรู้จะถูกคอมไพล์ครั้งเดียวและเก็บให้เป็นปัจจุบัน ไม่ใช่การได้มาใหม่ในทุกคำถาม" ผลลัพธ์คือ "สิ่งประดิษฐ์ที่คงอยู่และทวีคูณ"

คุณไม่ได้เขียน wiki เขาเขียน: "คุณไม่เคย (หรือแทบไม่เคย) เขียน wiki ด้วยตัวเอง LLM เขียนและดูแลรักษาทั้งหมด" เขาใช้เอเจนต์และ Obsidian ร่วมกัน เขาเขียน: "Obsidian คือ IDE; LLM คือโปรแกรมเมอร์; wiki คือ codebase"

Gist ระบุข้อจำกัดด้านขนาด บทสรุปหลายอันไม่รวมข้อจำกัดนี้ วิธีการที่ไม่มี embeddings "ใช้ได้ดีอย่างน่าประหลาดใจในระดับปานกลาง (~100 แหล่งข้อมูล, ~หลายร้อยหน้า) และหลีกเลี่ยงความจำเป็นในการใช้โครงสร้างพื้นฐาน RAG ที่ใช้ embedding"

สำหรับแหล่งข้อมูลเพิ่มเติม gist บอกให้คุณเพิ่มการค้นหา มันให้ qmd เป็นตัวอย่าง Gist อธิบาย qmd ว่า "เสิร์ชเอ็นจินท้องถิ่นสำหรับไฟล์ markdown พร้อมการค้นหาแบบ BM25/vector แบบผสม และการจัดอันดับด้วย LLM"

ดังนั้นกฎคือเรื่องขนาด กฎไม่ใช่เรื่องการแทนที่ อย่าใช้โครงสร้างพื้นฐานการค้นคืนเมื่อชุดแหล่งข้อมูลมีขนาดเล็ก เพิ่มการค้นคืนเมื่อชุดแหล่งข้อมูลมีขนาดใหญ่

สิ่งที่ห้องปฏิบัติการสร้างขึ้นจริง

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

Cognition: DeepWiki, wiki ในฐานะสาธารณูปโภคสาธารณะ

Cognition นำวิธีการนี้ไปใช้กับ repositories สาธารณะบน GitHub แทนที่ github.com ด้วย deepwiki.com ใน URL ของ repository สาธารณะ คุณจะได้ wiki สำหรับ codebase นั้น wiki มีบทสรุปสถาปัตยกรรม ดัชนีไฟล์ กราฟการพึ่งพา และการค้นหา wiki มีลิงก์ไปยังแหล่งที่มา (Cognition)

มากกว่า 50,000 repositories สาธารณะที่ใหญ่ที่สุดมี wiki รายการรวมถึง MCP และ LangChain

ประเด็นที่สองสำคัญกว่า wiki ไม่ใช่ผลิตภัณฑ์ wiki คือโครงสร้างพื้นฐานการค้นคืนสำหรับเอเจนต์ Devin ใช้ wiki เพื่อค้นหาโค้ดที่เกี่ยวข้องใน codebase ดังนั้น DeepWiki จึงเป็นชั้นที่คอมไพล์แล้วภายใต้การค้นหาโค้ดใน Devin (Devin Docs)

Factory: AutoWiki, เอกสารในฐานะ build artifact

Factory นำวิธีการนี้ไปใช้กับการบูรณาการอย่างต่อเนื่อง (CI) Factory เขียนว่าเอกสารต้องเป็น build artifact ไม่ใช่โปรเจกต์แยกต่างหาก เอกสารมาจากแหล่งที่มา มันมีโครงสร้างของ codebase มันเปลี่ยนแปลงเมื่อ repository เปลี่ยนแปลง (Factory)

วิธีการสร้าง wiki มีสองรอบ รอบที่ 1 คือการสแกนโครงสร้าง มันอ่านไฟล์ README, package manifests, การกำหนดค่า CI และ entry points รอบที่ 2 คือการสแกนความหมาย มันอ่าน routes, API endpoints, service classes, database schemas และ feature flags

Factory แบ่งงานระหว่างเอเจนต์เฉพาะทาง แต่ละเอเจนต์ได้รับส่วนหนึ่งของ repository แต่ละเอเจนต์ได้รับบริบทเพียงพอที่จะเขียนหนึ่งหน้าที่ดี วิธีการนี้ป้องกันปัญหาที่รู้จักกันดี: เอเจนต์เพียงตัวเดียวเขียนเอกสารที่ไม่ดีสำหรับ repository ขนาดใหญ่

Factory ทำให้ wiki ถูกต้องด้วยโครงสร้างพื้นฐาน ไม่ใช่ด้วยวินัย คำสั่ง /wiki สร้าง wiki ใหม่อีกครั้ง คำสั่ง /install-wiki เขียน CI workflow workflow นี้จะสร้าง wiki ใหม่ทุกครั้งที่มีการ push ไปยัง branch เริ่มต้น สำหรับ GitHub wiki จะไปที่แท็บ wiki ของ repository (Factory Docs)

LangChain: OpenWiki, และการก้าวกระโดดจากโค้ดสู่ทุกสิ่ง

LangChain ปล่อย OpenWiki เป็นซอฟต์แวร์โอเพนซอร์ส OpenWiki คือเครื่องมือ CLI มันเขียนและดูแลรักษาเอกสารเอเจนต์สำหรับ codebase จากนั้น LangChain ปล่อย OpenWiki Brains ซึ่งมีสองโหมด Code Brain คือโหมดแรก สำหรับ repository Personal Brain คือโหมดที่สอง สำหรับแหล่งข้อมูลของคุณเอง (LangChain)

Personal Brain คือการเปลี่ยนแปลงที่สำคัญ มันอ่านข้อมูลจาก Gmail, Notion, git repositories, X, Hacker News และการค้นหาเว็บ มันเขียนข้อมูลทั้งหมดนี้ลงใน wiki markdown ในเครื่องเดียว เอเจนต์อ่าน wiki นี้ วิธีการเปลี่ยนจากการจัดทำเอกสารของ repository ไปเป็นการจัดทำเอกสารของงานของคุณ

แต่ละทีมตัดสินใจเหมือนกันเกี่ยวกับผลลัพธ์ ผลลัพธ์ไม่ใช่ข้อความให้คนอ่าน ผลลัพธ์คือ markdown ที่มีโครงสร้างสำหรับบริบทของ LLM มันมีหัวข้อ ลิงก์ระหว่างหน้า และบทสรุป โครงสร้างช่วยให้เอเจนต์ค้นหาข้อมูลที่เกี่ยวข้องได้อย่างรวดเร็ว ผู้อ่าน wiki คือโมเดล

GBrain: เวอร์ชันโอเพนซอร์สขนาดส่วนบุคคล

GBrain นำวิธีการนี้ไปใช้กับคลังความรู้ส่วนบุคคล ไม่ใช่ codebase GBrain ใช้ markdown ใน git repository มันมีไฟล์ schema มันสร้างกราฟลิงก์ระหว่างหัวข้อโดยอัตโนมัติ

GBrain แสดงให้เห็นว่าวิธีการนี้ต้องการโครงสร้างพื้นฐานน้อยมาก มันไม่มีฐานข้อมูลเวกเตอร์ มันไม่มีบริการ มันมีแค่ไฟล์ โมเดลดูแลรักษาไฟล์ บุคคลสามารถอ่านไฟล์ได้

เมทริกซ์เทคนิค

ทั้งสี่ระบบมีโครงสร้างเดียวกัน พวกเขาใช้ markdown ใน git พวกเขาใช้ไฟล์ schema พวกเขาคอมไพล์เมื่อรับข้อมูล พวกเขาสร้าง wiki ใหม่เมื่อแหล่งข้อมูลเปลี่ยนแปลง พวกเขาเขียนหน้าให้เอเจนต์อ่าน สี่ทีมแก้ปัญหาสี่ปัญหาที่แตกต่างกันและสร้างโครงสร้างเดียวกัน ความสอดคล้องนี้เป็นหลักฐานที่ดีว่าโครงสร้างนั้นถูกต้อง

ระบบต่างกันที่การบำรุงรักษา Factory ทำการบำรุงรักษาใน CI อีกสามระบบทำการบำรุงรักษาเมื่อมีคนรันคำสั่ง ดังนั้น wiki ของพวกเขาจึงถูกต้องเท่ากับคำสั่งล่าสุดเท่านั้น

จุดที่มันหยุด

ข้อจำกัดที่ 1 คือขนาด Karpathy ระบุข้อจำกัดนี้ วิธีการที่ไม่มี embeddings ถูกต้องสำหรับประมาณ 100 แหล่งข้อมูล สำหรับหน้าที่มากขึ้น คุณต้องเพิ่มเสิร์ชเอ็นจิ้น Gist บอกให้คุณใช้การค้นหา BM25 และการค้นหาเวกเตอร์ร่วมกัน

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

ข้อจำกัดที่ 3 คือข้อมูลเก่า หน้าจะถูกต้องเท่ากับการอัปเดตล่าสุดเท่านั้น นี่คือเหตุผลที่วิธีการของ Factory มีความสำคัญ wiki ที่ไม่ถูกต้องแย่กว่าไม่มี wiki ข้อมูลที่ไม่ถูกต้องมีรูปแบบของข้อมูลที่ถูกต้อง

ข้อจำกัดที่ 4 คือค่าใช้จ่าย คุณจ่าย tokens เพื่อสร้างหน้า คุณสามารถสร้างหน้าที่ไม่มีใครอ่าน คุณยังจ่าย tokens เพื่อ lint หน้าที่ไม่มีการเปลี่ยนแปลง

Wiki ไม่ใช่ความทรงจำ

มีความแตกต่างหนึ่งที่คุณต้องรู้ คำศัพท์ในสาขานี้ยังไม่แม่นยำ

หลายคนเรียกระบบเหล่านี้ว่าความทรงจำ (memory) LangChain เรียก OpenWiki ว่าเลเยอร์ความทรงจำแบบ wiki สำหรับ AI agents คนอื่นๆ บอกว่า wiki ให้ความทรงจำแก่เอเจนต์ คำว่าความทรงจำมีความหมายสองแบบที่แตกต่างกันที่นี่

ความหมายแรกคือความรู้เกี่ยวกับชุดเอกสาร Wiki ทำสิ่งนี้ มันรวบรวมข้อมูลในเอกสาร repository หรือ Gmail ของคุณ มันบอกคุณว่าเอกสารมีอะไรบ้าง

ความหมายที่สองคือความทรงจำของผู้ใช้ นี่คือข้อมูลที่แตกต่างกัน มันรวมถึงความชอบของบุคคล มันรวมถึงการตัดสินใจของบุคคล มันรวมถึงวิธีการที่ทีมปฏิเสธ มันรวมถึงผลลัพธ์เมื่อเอเจนต์ลองวิธีการในแอปพลิเคชันอื่น

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

Wiki ทำภารกิจแรกได้ถูกต้อง Wiki ไม่ได้ทำภารกิจที่สอง Wiki Gmail ของคุณบอกเอเจนต์ว่ามีอะไรใน Gmail ของคุณ มันไม่ได้บอกเอเจนต์ว่าคุณเปลี่ยนการตัดสินใจในการสนทนาเมื่อวันอังคาร มันไม่ได้บอกเอเจนต์ว่าวิธีการหนึ่งล้มเหลวสำหรับคุณแล้ว

เลเยอร์ความทรงจำทำภารกิจที่สอง Mem0 คือตัวอย่าง มันเก็บความทรงจำแต่ละรายการด้วย user_id ดังนั้นความทรงจำจึงเคลื่อนที่ไปกับบุคคลระหว่างเซสชัน แอปพลิเคชัน และเอเจนต์ มันเปลี่ยนข้อเท็จจริงในตำแหน่งเมื่อข้อเท็จจริงเปลี่ยน มันไม่ได้เพิ่มบันทึกใหม่ทุกครั้ง

ทั้งสองระบบไม่ใช่ทางเลือกอื่น ใช้ทั้งสองอย่าง ข้อผิดพลาดคือไม่ใช้ wiki ข้อผิดพลาดคือการคิดว่า wiki ให้ความทรงจำของผู้ใช้แก่คุณ

สรุป

แนวคิดใน agent wikis ถูกต้อง คอมไพล์ความรู้ครั้งเดียว จากนั้นดูแลให้ถูกต้อง อย่าสร้างใหม่อีกสำหรับทุกคำถาม การบำรุงรักษาหยุด wiki ของมนุษย์ และโมเดลทำการบำรุงรักษาโดยไม่มีค่าใช้จ่าย สี่ทีมสร้างโครงสร้างเดียวกันภายในไม่กี่เดือน นี่คือหลักฐานที่แข็งแกร่ง

ทำสามสิ่งนี้ คอมไพล์เอกสารของคุณเป็นหน้าเมื่อชุดเอกสารคงที่และคุณอ่านบ่อย เพิ่มการค้นคืนเมื่อชุดเอกสารมีขนาดใหญ่ ตามที่ gist บอกคุณ รักษาความแตกต่างระหว่างความรู้ของชุดเอกสารและความทรงจำของผู้ใช้ Wiki ให้สิ่งแรกแก่คุณ Wiki ไม่ได้ให้สิ่งที่สองแก่คุณ

In Context #17

บล็อกนี้เป็นส่วนหนึ่งของ In Context ชุดบทความบล็อกจาก @mem0ai ที่ครอบคลุมเรื่องความทรงจำของ AI Agent และวิศวกรรมบริบท

Mem0 คือเลเยอร์ความทรงจำอัจฉริยะแบบโอเพนซอร์สที่ออกแบบมาสำหรับ LLM และ AI agents เพื่อให้การโต้ตอบระยะยาว เป็นส่วนตัว และรับรู้บริบทข้ามเซสชัน

• รับ API Key ฟรีของคุณได้ที่นี่: app.mem0.ai
• หรือโฮสต์ mem0 ด้วยตนเองจาก github repository โอเพนซอร์สของเรา

ข้อมูลอ้างอิง

• Andrej Karpathy, LLM Wiki (GitHub Gist, เมษายน 2026)
• qmd: การค้นหาแบบ BM25/vector แบบผสมสำหรับ markdown ในเครื่อง
• Cognition, DeepWiki: เอกสาร AI สำหรับทุก repo
• Devin Docs, DeepWiki
• Factory, เปิดตัว AutoWiki
• Factory Documentation, ภาพรวม AutoWiki
• langchain-ai/openwiki (GitHub)
• LangChain, Wiki Memory
• garrytan/gbrain (GitHub)
• Vannevar Bush, As We May Think (The Atlantic, 1945)
• Mem0