# Agent Wikis 的現狀 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 原作者：mem0 (@mem0ai) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥🔥 · 日期：2026-07-24 > 原始來源：https://x.com/mem0ai/status/2079585032587694582 ## 中文摘要 # Agent Wikis 的現狀 在 2026 年 4 月，Andrej Karpathy 寫了一篇 GitHub Gist，並在其中描述了一種方法，他稱之為 LLM Wiki。 在此之後，有四個團隊建構了相同的東西。Cognition 建構了 DeepWiki；Factory 建構了 AutoWiki；LangChain 發布了 OpenWiki；Garry Tan 則發布了 GBrain。 這四個系統的方法完全相同。LLM 會先閱讀你的來源文件一次，將資訊寫入 markdown 頁面中，並在來源變更時確保這些頁面保持正確。接著，Agent 會去讀取這些頁面，而不需要針對每個問題重新讀取來源文件。 人們將這些系統稱為 Agent wikis。這篇文章將會告訴你它們是什麼、各個團隊建構了什麼、這項方法的限制在哪裡，以及一個許多人容易忽略的重要差異。 --- ## 核心概念：在載入時編譯，而非在查詢時編譯 過去要將大量文件提供給模型使用，最常見的方法是檢索。你會把文件放進資料庫裡、將文件分割成多個片段、為這些片段建立嵌入（embeddings），然後在每次使用者提出問題時，系統就會找出相關的片段。 ![一張名為「The agent wiki, end to end.」的架構圖，詳細展示了以大型語言模型（LLM）驅動的代理人 Wiki 系統的運作流程與各個元件之間的關聯。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/05c70bfb118ef0d7.jpg)
展開畫面重點
轉錄畫面中的所有文字內容與結構如下： - 頂部標題： - IN CONTEXT - ARCHITECTURE / 17 - The agent wiki, end to end. - 右上角 Logo：memo - 第一部分：`RAW SOURCES / IMMUTABLE` (read, never edited) - 標籤包含：`articles`, `papers`, `repositories`, `data`, `raw/` - 透過 `ingest` (read the source, file it across every page it touches) 向下傳遞。 - 第二部分：`THE WIKI / LLM-OWNED MARKDOWN` - 頂端橫幅：`index.md` (read first, every query) - 包含三個區塊： - `entities/` (people, companies) - `concepts/` (ideas, terms) - `summaries/` (per-source digests) - 交叉引用：`cross-references, maintained by the model` - 底部區塊 (`PAST ~100 SOURCES`)：`add qmd: hybrid BM25 / vector search with LLM re-ranking` - 第三部分：`THE SCHEMA` - 右側紫色區塊，標題為 `THE SCHEMA`，受 `governs` 指引，內含輸入框 `CLAUDE.md` - 包含要點： - how the wiki is organized - which workflows to run - start + end of session rules - 說明：`a disciplined maintainer, not a chatbot with file access` - 第四部分：`QUERY` - 流程步驟：`agent asks` -> `reads index.md` -> `opens the pages it names` -> `answer` - 與 Wiki 系統的互動：`serves the pages`，以及透過虛線回饋 `good answers filed back as pages`。 - 第五部分：`LINT / A PERIODIC PASS / KEEPS THE PAGES TRUE` (黑色區塊) - 包含四個按鈕/項目： - `hunt contradictions` - `refresh stale claims` - `fix orphaned pages` - `update cross-refs` - 底部結語： - Compiled once at ingest, governed by a schema, read by agents, kept current by lint.
這個方法確實可行，但也有個問題：系統不會保留查詢結果，每次都要從原始片段重新組合出答案。第十次回答並不會比第一次回答更好，而你卻必須付出了十次的運算成本。 Agent wiki 改變了這個成本結構。當模型第一次讀取來源時，就已經完成了這項工作，並把結果寫入頁面中，而這些頁面會被保留下來。 當有新來源進來時，模型會執行以下步驟：讀取來源、修改相關頁面、修正摘要，並標記出與現有頁面不一致的資訊。 這兩種方法都是正確的，但它們在兩個方面有所不同。第一是付出成本的時間點；第二是在回答問題後，究竟留下 了什麼。 每個系統都具備相同的三個層級： 第一層是來源文件。這些是你的文章、論文與程式庫。模型會讀取它們，但不會對其進行修改。 第二層是 wiki。這個 wiki 是由 markdown 組成的，並由模型負責編寫所有內容。Wiki 包含摘要、針對各個主題的頁面，以及頁面之間的連結。 第三層是 schema 檔案。這個檔案會告訴模型 wiki 的結構，以及該執行哪些任務。常見的檔案名稱是 `CLAUDE.md` 或 `AGENTS.md`。這個檔案能確保模型成為一個合格且維護得當的 wiki 管理者。 ![一張名為「IN CONTEXT ARCHITECTURE / 17」的架構圖，標題為「Three layers, three operations. Always the same shape.」，展示包含三層架構與三項運作機制的系統設計。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/d6d726453dbbde66.jpg)
展開畫面重點
IN CONTEXT ARCHITECTURE / 17 mem0 Three layers, three operations. Always the same shape. RAW SOURCES immutable: articles, papers, repositories, data the model reads them, never edits them THE WIKI LLM-generated markdown the model owns entirely summaries, entity pages, concepts, cross-references THE SCHEMA CLAUDE.md / AGENTS.md, how it is organized what makes it a disciplined maintainer, not a chatbot with file access THREE OPERATIONS RUN ON TOP 1 ingest a new source arrives file it across every page it touches 2 query ask the wiki good answers can be filed back as pages 3 lint a periodic pass hunt contradictions, stale claims, orphans The maintenance that killed human wikis is exactly the labor a model performs for free.
系統會執行三種操作： 載入（Ingest）：模型讀取新來源，然後將資料寫入每一個相關的頁面。 查詢（Query）：你向 wiki 提出問題，並可以把品質良好的解答作為新頁面寫回 wiki 中。 整理（Lint）：模型檢查 wiki，找出彼此矛盾的資訊、過時的資訊，以及沒有任何連結孤立頁面。 --- ## 為什麼它行得通： 人類編寫的 wiki 隨著時間過去往往會變得不再正確，原因很明確。困難之處不在於閱讀來源，也不在於產生想法，真正的難點在於維護。 維護工作包含以下這些任務：你必須修正頁面之間的連結、確保摘要保持正確，並且將每一份新文件與現有的頁面進行比對。 這項工作永無止盡，卻沒有實質回報。一個忙碌的團隊通常會最先放棄這項工作，接著 wiki 就會過期失效，最後大家也不再使用了。 模型則能完美勝任這項工作，它不會感到厭倦、不會漏掉任何連結，還能在單一操作中同時修改十五個檔案。 這個點子其實由來已久。Vannevar Bush 在 1945 年就曾描述過 Memex，這是一個能儲存個人文件並在其中建立連結的系統。然而，Bush 當時並未解決維護的問題，而模型正是這個問題的最佳解答。 --- ## 名稱的由來 建議直接閱讀 Karpathy 的 Gist原文，會比任何摘要都來得準確。 他在文中這樣描述傳統方法：「LLM 在面對每一個問題時，都是從零開始重新探索知識，完全沒有累積性。」 而他的方法則是將資訊「編譯」起來，而不是靠「檢索」。如此一來，「知識只需被編譯一次並持續保持最新狀態，而不需要在每次查詢時重新推導。」其結果就是「一個持久且具備複利效果的產物（persistent, compounding artifact）。」 這個 wiki 並不是由你來寫。他寫道：「你從不（或極少）親自編寫 wiki，一切都是由 LLM 來編寫與維護。」他是將 agent 與 Obsidian 搭配使用，並形容：「Obsidian 是 IDE，LLM 是程式開發者，而 wiki 就是程式庫。」 這篇 Gist 也為規模設下了限制，許多摘要往往忽略了這一點。在沒有嵌入（embeddings）的情況下，這種方法「在中等規模下（約 100 個來源、數百個頁面）展現出驚人的成效，並且省去了建置基於嵌入的 RAG 基礎架構的需求。」 如果來源更多，Gist 則建議加入搜尋功能，並以 qmd 作為範例。Gist 將 qmd 描述為「一個針對 markdown 檔案的本地搜尋引擎，結合了 BM25 與向量搜尋，並具備 LLM 重新排序（re-ranking）功能。」 因此，這項規則是關於規模的，而不是關於取代。當來源集很小時，不要使用檢索基礎架構；當來源集變得龐大時，再加入檢索功能。 --- ## 實驗室實際建構了什麼 這正是這個模式從點子轉化為工程實作的關鍵，而各個實作之間的差異也正是最有價值的部分。 Cognition：DeepWiki，作為公共公用事業的 wiki Cognition 將這項方法應用在 GitHub 上的公開程式庫。只要把公開程式庫 URL 中的 `github.com` 替換成 `deepwiki.com`，就能立刻為該程式庫產生一個 wiki。這個 wiki 包含了架構摘要、檔案索引、相依性圖表（dependency graph），以及搜尋功能，並且帶有連回原始碼的連結（Cognition）。 目前已有超過 50,000 個大型公開程式庫擁有了自己的 wiki，其中包含 MCP 和 LangChain。 第二點更加重要。這個 wiki 本身並不是產品，而是提供給 agent 使用的檢索基礎架構。Devin 會利用這個 wiki 在程式庫中尋找相關的程式碼。因此，DeepWiki 實際上就是 Devin 程式碼搜尋底下的編譯層（Devin Docs）。 Factory：AutoWiki，作為建構產物的說明文件 Factory 將這項方法應用在持續整合（CI）流程中。Factory 認為，說明文件應該是建構產物（build artifact），而不是獨立的專案。說明文件應源自原始碼，並具備與程式庫相同的結構，且會隨著程式庫的變更而自動更新（Factory）。 ![顯示 AutoWiki 文件建構管線架構的流程圖，說明如何將原始碼自動轉化為隨時更新的 Wiki 文件。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/184f026285537cc1.jpg)
展開畫面重點
IN CONTEXT PIPELINE / 17 mem0 AutoWiki: documentation as a build artifact. YOUR REPOSITORY the only input 1 structural scan how the repo is laid out README | package manifests | CI config | entry points then deeper 2 semantic scan how the codebase actually works routes | API endpoints | service classes | database schemas | feature flags split across SPECIALIZED AGENTS one facet each, just enough context agent architecture | agent API surface | agent data model | agent operations THE WIKI organized around how the codebase works, synced to the repo's wiki tab refreshed on every push, never stale by discipline CURRENCY AS INFRASTRUCTURE push to default branch -> CI workflow fires -> wiki regenerates /install-wiki Built from source, split across agents, kept current by the build system itself.
產生 wiki 的過程包含兩個階段。第一階段是結構掃描，會讀取 README 檔案、套件資訊清單（package manifests）、CI 設定檔以及進入點（entry points）。第二階段則是語意掃描，會讀取路由、API 端點、服務類別（service classes）、資料庫 schema 以及功能旗標（feature flags）。 Factory 將工作分配給不同的專門 agent。每個 agent 負責程式庫的一部分，並獲得足夠的 context 來編寫出品質良好的頁面。這種方法避免了一個常見的問題：單獨一個 agent 在面對大型程式庫時，往往寫不出高品質的說明文件。 Factory 是透過基礎架構來確保 wiki 的正確性，而不是依賴人工紀律。只要執行 `/wiki` 指令就能重新產生 wiki；而執行 `/install-wiki` 指令則會寫入一個 CI 工作流程（workflow），這個工作流程會在每次推送（push）至預設分支時自動重新產生 wiki。以 GitHub 為例，wiki 會直接存放在程式庫的 wiki 分頁中（Factory Docs）。 LangChain：OpenWiki，實現從程式碼到萬物的跨越 LangChain 推出了開源軟體 OpenWiki。OpenWiki 是一個命令列工具（CLI tool），用於為程式庫編寫和維護 agent 說明文件。隨後，LangChain 發布了 OpenWiki Brains，其中包含兩種模式。第一種是 Code Brain，適用於程式庫；第二種則是 Personal Brain，適用於你個人的各種來源（LangChain）。 Personal Brain 是其中一項重要的變革。它會從 Gmail、Notion、git 程式庫、X、Hacker News 以及網路搜尋中讀取資料，並將所有資料寫入同一個本地 markdown wiki 中，再由 agent 進行讀取。這個方法已經從單純的「程式庫說明文件」轉變為「你工作內容的說明文件」。 每個團隊對輸出結果都做出了相同的決定：輸出內容並不是給人類閱讀的文字，而是專為 LLM context 設計的結構化 markdown。它包含了標題、頁面之間的連結以及摘要。這樣的結構讓 agent 能夠快速找到相關資訊，因為這個 wiki 的真正讀者是模型。 GBrain：個人規模的開源版本 GBrain 將這項方法應用在個人知識庫而非程式庫上。GBrain 使用存放在 git 程式庫中的 markdown，搭配一個 schema 檔案，就能自動建立主題之間的連結圖表。 GBrain 證明了這項方法僅需極少的基礎架構：它不需要向量資料庫、不需要後端服務，有的只是檔案。模型負責維護這些檔案，而人類也可以隨時閱讀它們。 ## 技術矩陣 ![一張名為「IN CONTEXT MATRIX / 17」的比較表格，分析了 DeepWiki、AutoWiki、OpenWiki 與 GBrain 四個系統在語料庫、更新機制與適用對象上的差異。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/492a2695f28c9e79.jpg)
展開畫面重點
IN CONTEXT MATRIX / 17 mem0 Same shape, different corpora. Currency is the tell. SYSTEM | CORPUS | CURRENCY | WRITTEN FOR --- | --- | --- | --- DeepWiki <br> Cognition | any public repo, <br> 50k+ indexed | re-indexed; <br> grounds Devin | agents, and <br> humans browsing AutoWiki <br> Factory | your org's <br> repos | CI refresh, <br> every push | engineers and <br> Droids together OpenWiki <br> LangChain | repos + Gmail, <br> Notion, X, HN | re-run to <br> refresh | LLM context, <br> not human prose GBrain <br> Garry Tan | personal <br> sources | manual or <br> scheduled runs | a person and <br> their agent Factory treats staleness as a build problem and solves it in CI. Everyone else is exactly as current as the last time someone ran the command. That divergence is the maturity tell.
這四個系統都具備相同的架構：使用 git 中的 markdown、使用 schema 檔案、在載入時編譯、在來源變更時重新產生 wiki，以及為 agent 閱讀而編寫頁面。四個團隊解決了四個不同的問題，卻打造出相同的架構，這項高度的一致性正是該架構正確性的有力證明。 這些系統的差異在於維護方式。Factory 是在 CI 流程中進行維護，而其他三個系統則是在使用者手動執行指令時才進行維護。因此，後者的 wiki 正確性僅取決於上一次執行指令時的狀態。 --- ## 限制所在 限制一：規模。Karpathy 點出了這個限制。在不使用嵌入的情況下，這種方法大約適用於 100 個來源。如果頁面數量更多，你就必須加入搜尋引擎。Gist 建議將 BM25 搜尋與向量搜尋結合使用。 限制二：準確度。模型是在載入時編譯資訊，因此早期的摘要可能會遺漏來源中的某個細節，而後續的所有回答都會帶有這個錯誤。從原始片段進行檢索則沒有這個問題。你等於是用「重複工作的成本」換取了「遺失資料的風險」。 限制三：資訊過時。頁面的正確性完全取決於上一次的更新時間，這也是 Factory 的方法如此重要的原因。一個不正確的 wiki 比沒有 wiki 更糟糕，因為錯誤的資訊往往包裝得像正確資訊一樣。 限制四：成本。你需要消耗 token 來產生頁面，甚至可能會產生沒人閱讀的頁面；同時，你也需要消耗 token 來整理（lint）那些根本沒有變更的頁面。 --- ## Wiki 不等於記憶 有一個關鍵差異是你必須知道的，雖然這個領域的術語目前還不夠精確。 許多人將這些系統稱為「記憶」。LangChain 將 OpenWiki 稱為 AI agent 的 wiki 記憶層；也有人說 wiki 為 agent 提供了記憶。但「記憶」這個詞在這裡有兩種不同的含義。 ![該圖比較了「記憶」在 AI 系統中的兩種不同維度，分別是「語料知識（corpus knowledge）」與「使用者與經驗記憶（user + experience memory）」，並點出該服務（mem0）所專注的核心領域。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/5192f6180f7e6ed2.jpg)
展開畫面重點
IN CONTEXT MODEL / 17 "Memory" is carrying two different things. AXIS 1 / WHAT A WIKI DOES corpus knowledge "what does this material contain" - scoped to a corpus - accumulates from ingestion - answers about documents, repos, your Gmail Compiling your Gmail tells an agent what is in your Gmail. AXIS 2 / WHAT A WIKI DOES NOT ATTEMPT user + experience memory "what did this person decide, prefer, try" - scoped to an identity - accumulates from interaction - must handle contradiction, staleness, deletion per user It does not tell the agent you changed your mind about the vendor last Tuesday. THE SECOND AXIS IS WHAT MEM0 IS FOR memory tagged to a user_id, following a person across sessions, apps, and agents, updated in place when facts change rather than appended forever The mistake is not choosing a wiki. It is believing you solved memory because you compiled a corpus.
第一種含義是對文件集的知識。Wiki 做到了這點，它會編譯你的文件、程式庫或 Gmail 中的資料，並告訴你這些文件包含什麼內容。 第二種含義則是使用者的記憶。這是一種截然不同的資料，包含了使用者的偏好、使用者的決議、團隊曾否決過的方法，以及當 agent 在其他應用程式中嘗試某種方法時的結果。 使用者記憶具有不同的結構。它與特定使用者相關，而不是與文件集相關；它源自於互動，而不是載入。此外，它必須針對每個使用者執行以下任務：修正矛盾的資訊、移除過時的資訊、保留每個項目的來源，以及根據要求刪除資料。 Wiki 可以完美完成第一項任務，卻無法完成第二項任務。你的 Gmail wiki 可以告訴 agent 你的 Gmail 裡有什麼，但它無法告訴 agent 你在週二的對話中更改了決定，也無法告訴 agent 某個方法先前已經對你宣告失敗。 記憶層則能處理第二項任務。Mem0 就是一個例子，它會將每筆記憶與一個 `user_id` 進行綁定，讓記憶能夠隨著使用者在不同的階段、應用程式和 agent 之間攜帶。當事實改變時，它會直接在原位更新該項事實，而不是每次都新增一筆記錄。 這兩個系統並非互相替代的關係，而是應該兩者並用。錯誤的做法是不使用 wiki；但同樣錯誤的是，以為 wiki 能夠提供使用者的記憶。 --- ## 總結 Agent wikis 的核心概念是正確的：將知識編譯一次，然後保持其正確性，而不是針對每個問題重新建構答案。人類編寫的 wiki 往往因為維護困難而停擺，而模型能夠以零成本完成這項維護工作。四個團隊在短短幾個月內建構出相同的架構，這就是強而有力的證明。 請採取以下三個作法：當你的文件集保持穩定且會被頻繁讀取時，將文件編譯成頁面；當文件集變大時，按照 Gist 的建議加入搜尋功能；並且分清楚「文件集的知識」與「使用者的記憶」之間的差異。Wiki 能給你前者，但無法給你後者。 --- In Context #17 這篇部落格文章是 In Context 系列的一部分。這是由 @mem0ai 推出的專欄，探討 AI Agent 記憶與 context 工程。 Mem0 是一個智慧型開源記憶層，專為 LLM 與 AI agent 設計，能在不同的對話階段中提供長期、個人化且具備 context 意識的互動體驗。 - 在此取得你的免費 API Key：app.mem0.ai - 或從我們的開源 GitHub 程式庫自行架設 mem0 --- ## 參考資料 - Andrej Karpathy, LLM Wiki (GitHub Gist, April 2026) - qmd: local hybrid BM25/vector search for markdown - Cognition, DeepWiki: AI docs for any repo - Devin Docs, DeepWiki - Factory, Introducing AutoWiki - Factory Documentation, AutoWiki overview - langchain-ai/openwiki (GitHub) - LangChain, Wiki Memory - garrytan/gbrain (GitHub) - Vannevar Bush, As We May Think (The Atlantic, 1945) - Mem0 ## 標籤 Agent, 開源專案, 產業趨勢, Cognition, LangChain