主旨：在攝取時編譯，而非在查詢時
2026 年 4 月，Andrej Karpathy 在 GitHub 上發布了一個 Gist。他在其中描述了一種方法，稱之為「LLM Wiki」。
隨後，四個團隊分別打造了類似的系統。Cognition 建構了 DeepWiki，Factory 建構了 AutoWiki，LangChain 發布了 OpenWiki，Garry Tan 則推出了 GBrain。
這四個系統的核心方法相同：LLM 一次性讀取你的原始文件，將資訊寫入 Markdown 頁面，並在原始內容變更時保持這些頁面的正確性。之後，Agent 會讀取這些頁面，而不是針對每個問題都重新讀取原始文件。
人們稱這類系統為「Agent Wiki」。這篇文章會說明它們是什麼、每個團隊的具體實作、此方法的限制，以及一個許多人忽略的重要差異。
主旨：在攝取時編譯，而非在查詢時
為模型提供大量文件的常見方法是「檢索」。你將文件放入資料庫，將其分割成片段，並為這些片段建立嵌入向量。針對每個問題，系統會找出相關的片段。
這個方法可行，但也有問題：系統不會保留查詢結果。它每次都從原始片段重新建構答案。第十次回答的品質不會比第一次更好，而你卻付出了十次工作的成本。
Agent Wiki 將這個成本轉移了。模型在讀取原始文件時一次性完成工作，將結果寫入頁面，這些頁面會被保留下來。
當新的原始文件加入時，模型會執行以下步驟：讀取原始文件、更新相關頁面、修正摘要，並標記與現有頁面不一致的資訊。
兩種方法都正確，但有以下兩個差異：第一，成本支付的時機點不同；第二，問題結束後，有什麼東西被保留下來。
每個系統都包含相同的三個層級。
第一層是原始文件，包含你的文章、論文和程式碼庫。模型會讀取它們，但不會修改它們。
第二層是 Wiki，採用 Markdown 格式。模型負責撰寫整個 Wiki 的內容，包含摘要、各主題的頁面，以及頁面之間的連結。
第三層是架構檔案。這個檔案告訴模型 Wiki 的結構，以及需要執行的任務。常見的檔名是 CLAUDE.md 或 AGENTS.md。這個檔案能讓模型成為 Wiki 正確的維護者。
系統執行三種操作：
攝取：模型讀取新的原始文件，然後將資料寫入每個相關的頁面。
查詢：你向 Wiki 提出問題。你也可以將優質的回答以新頁面的形式寫回 Wiki 中。
校驗：模型檢查整個 Wiki，找出不一致的資訊、過時的資訊，以及沒有被連結到的頁面。
為何有效
人類維護的 Wiki 會隨著時間推移而變得不正確，原因很明確。困難的部份不在於閱讀原始文件，也不在於產生想法，而是在於維護工作。
維護工作包含以下任務：你必須修正頁面之間的連結、保持摘要的正確性，並將每份新文件與現有的頁面進行比對。
這項工作永無止境，而且沒有報酬。忙碌的團隊會優先停止這項工作，然後 Wiki 就會開始變得不正確，最終大家就不再使用它。
模型可以毫無問題地完成這項工作。模型不會感到厭倦，也不會忘記建立連結。它可以在一次操作中修改十五個檔案。
這個概念由來已久。Vannevar Bush 在 1945 年描述了 Memex，這是一種個人文件儲存裝置，文件之間帶有連結。Bush 當時沒有解決維護問題，而模型正是這個問題的解答。
名稱的由來
直接閱讀 Karpathy 的 Gist 原文，會比閱讀任何摘要都更準確。
他對傳統方法如此描述：「LLM 在每個問題上都從頭開始重新發現知識，沒有累積。」
他的方法是「編譯」資訊，而非「檢索」資訊。如此一來，「知識被一次性編譯完成，然後保持更新，而不是在每次查詢時重新推導。」結果是「一個持續累積的、不斷增長的成果。」
你不需要自己撰寫 Wiki。他寫道：「你永遠（或極少）需要自己撰寫 Wiki，LLM 會撰寫並維護所有內容。」他將 Agent 與 Obsidian 結合使用。他寫道：「Obsidian 是 IDE；LLM 是程式設計師；Wiki 是程式碼庫。」
這個 Gist 也提到了規模限制，許多摘要都忽略了這點。不使用嵌入向量的方法「在中等規模（約 100 個原始來源、數百個頁面）下效果出奇地好，並且避免了建置基於嵌入向量的 RAG 基礎設施的需求。」
對於更多的原始來源，Gist 建議你加入搜尋功能，並以 qmd 為例。Gist 將 qmd 描述為「一個針對 Markdown 檔案的本地端混合搜尋引擎，結合了 BM25/向量搜尋與 LLM 重新排序。」
因此，這是一個關於規模的規則，而非替代法則。當原始來源集規模較小時，不需要使用檢索基礎設施；當原始來源集規模變大時，再加入檢索功能。
各團隊的實際建置
從這裡開始，這個概念不再只是個想法，而是進入了工程實作階段。不同實作之間的差異，正是最有價值的部分。
Cognition：DeepWiki，作為公共設施的 Wiki
Cognition 將這個方法應用於 GitHub 上的公開程式碼庫。只要將公開程式碼庫 URL 中的 github.com 替換為 deepwiki.com，就能獲得該程式碼庫的 Wiki。這個 Wiki 包含架構摘要、檔案索引、依賴關係圖和搜尋功能，並包含指向原始碼的連結。
超過 50,000 個最受歡迎的公開程式碼庫都擁有自己的 Wiki，包括 MCP 和 LangChain。
第二點更為重要：這個 Wiki 本身並非產品，而是為 Agent 提供的檢索基礎設施。Devin 使用這個 Wiki 來查找程式碼庫中的相關程式碼。因此，DeepWiki 是 Devin 中程式碼搜尋功能下方的編譯層。
Factory：AutoWiki，作為建置產物的文件
Factory 將這個方法應用於持續整合流程。Factory 認為，文件必須是建置過程的產物，而不是一個獨立的專案。文件源自於原始碼，具有與程式碼庫相同的結構，並在程式碼庫變更時同步更新。
AutoWiki 建立 Wiki 的過程分為兩個階段。第一階段是結構掃描，讀取 README 檔案、套件清單、CI 設定檔和進入點。第二階段是語意掃描，讀取路由、API 端點、服務類別、資料庫架構和功能開關。
Factory 將工作分配給專門的 Agent。每個 Agent 負責程式碼庫的一部分，並獲得足夠的上下文來撰寫一個優質頁面。這個方法避免了已知的問題：單一 Agent 難以為大型程式碼庫撰寫出良好的文件。
Factory 透過基礎設施而非紀律來確保 Wiki 的正確性。/wiki 指令會重新建立 Wiki。/install-wiki 指令會建立一個 CI 工作流程，該工作流程會在每次推送至預設分支時重新建立 Wiki。對於 GitHub 專案，Wiki 會被放置在程式碼庫的 Wiki 標籤頁中。
LangChain：OpenWiki，從程式碼到萬物的躍進
LangChain 以開源軟體的形式發布了 OpenWiki。OpenWiki 是一個 CLI 工具，用於撰寫和維護程式碼庫的 Agent 文件。隨後，LangChain 發布了 OpenWiki Brains，它包含兩種模式：Code Brain 用於程式碼庫，Personal Brain 則用於你個人的資料來源。
Personal Brain 是重要的變革。它可以讀取來自 Gmail、Notion、git 儲存庫、X（推特）、Hacker News 和網路搜尋的資料，並將所有這些資料寫入一個本機端的 Markdown Wiki。Agent 會讀取這個 Wiki。這個方法的應用範圍，從程式碼庫的文件擴展到了你工作內容的文件。
每個團隊都對輸出格式做出了相同的決定：輸出內容不是為了讓人閱讀，而是為了提供 LLM 上下文而結構化的 Markdown。它包含標題、頁面之間的連結和摘要。這種結構讓 Agent 能快速找到相關資訊。換句話說，Wiki 的讀者是模型。
GBrain：個人規模的開源版本
GBrain 將這個方法應用於個人知識庫，而非程式碼庫。GBrain 使用 git 儲存庫中的 Markdown 檔案，包含一個架構檔案，並能自動建立主題之間的連結圖譜。
GBrain 證明了這個方法只需要極少的基礎設施。它沒有向量資料庫，沒有運作中的服務，只有檔案。模型負責維護這些檔案，而人類也可以閱讀這些檔案。
技術矩陣
這四個系統的結構相同：它們都使用 git 中的 Markdown 檔案、一個架構檔案、在攝取時編譯、在原始來源變更時重新建立 Wiki，並為 Agent 閱讀而撰寫頁面。四個不同的團隊解決了四個不同的問題，卻得出了相同的結構。這種一致性強烈說明了這個結構是正確的。
這些系統在維護方式上有所不同。Factory 在 CI 中進行維護，而其他三個系統則在有人執行指令時進行維護。因此，它們的 Wiki 的正確性，取決於最後一次執行的指令。
限制
限制一：規模。Karpathy 提到了這個限制。不使用嵌入向量的方法，對於約 100 個原始來源是有效的。對於更多頁面，你必須加入搜尋引擎。Gist 建議你同時使用 BM25 搜尋和向量搜尋。
限制二：準確性。模型在攝取時編譯資訊。早期的摘要可能會遺漏原始文件中的某個細節，而後續的每個答案都會包含這個錯誤。直接從原始片段進行檢索則沒有這個問題。你是在用重複工作的成本，交換資料遺失的風險。
限制三：過時資訊。一個頁面的正確性，取決於它最後一次被更新的時間。這就是 Factory 方法重要的原因。一個不正確的 Wiki 比沒有 Wiki 更糟糕，因為錯誤的資訊披著正確資訊的外衣。
限制四：成本。你需要花費 token 來建立頁面，可能建立了一些沒人讀過的頁面。你也需要花費 token 來校驗那些沒有變更的頁面。
Wiki 並非記憶
有一個你必須知道的差異。這個領域的用詞還不夠精確。
許多人稱這些系統為「記憶」。LangChain 將 OpenWiki 稱為「AI Agent 的 Wiki 記憶層」。其他人則說 Wiki 為 Agent 提供了記憶。這裡的「記憶」一詞有兩種不同的含義。
第一種含義是「對文件集的知識」。Wiki 能做到這點。它編譯了你的文件、程式碼庫或 Gmail 中的資料，告訴你這些文件包含了什麼內容。
第二種含義是「對使用者的記憶」。這是不同的資料。它包含了一個人的偏好、決定、團隊曾經拒絕過的方法，以及 Agent 在另一個應用程式中嘗試某個方法的結果。
對使用者的記憶具有不同的結構。它與特定的人相關，而非文件集。它來自於互動，而非攝取。它還必須為每個使用者執行以下任務：修正不一致的資訊、移除過時的資訊、保留每個項目的來源，並根據要求刪除資料。
Wiki 能正確完成第一項任務，但無法完成第二項任務。你的 Gmail Wiki 會告訴 Agent 你 Gmail 郵件中的內容，但它不會告訴 Agent 你在星期二的一段對話中改變了某個決定，也不會告訴 Agent 某個方法對你來說已經失敗過。
記憶層則負責完成第二項任務。Mem0 就是一個例子。它將每條記憶與一個 user_id 綁定。因此，記憶能隨著使用者跨越多個會話、應用程式和 Agent 而移動。當一個事實改變時，它會更新該事實，而不是每次都新增一條記錄。
這兩個系統並非替代關係，而是應該同時使用。錯誤不在於不使用 Wiki，而在於認為 Wiki 能提供你對使用者的記憶。
總結
Agent Wiki 的概念是正確的。一次性編譯知識，然後保持其正確性，不要為每個問題重新建構。維護工作曾讓人類的 Wiki 難以為繼，而模型則能以零成本完成維護。四個團隊在短短幾個月內建構了相同的結構，這是個強而有力的證據。
請執行以下三件事：當你的文件集穩定且你經常閱讀時，將它們編譯成頁面。當文件集規模變大時，依照 Gist 的建議加入檢索功能。最後，務必區分「對文件集的知識」和「對使用者的記憶」。Wiki 能提供前者，但無法提供後者。
In Context 第 17 期
本文是 [@mem0ai](https://x.com/@mem0ai) 的 In Context 部落格系列一環，探討 AI Agent 記憶與上下文工程。
Mem0 是一個智慧型、開源的記憶層，專為 LLM 和 AI Agent 設計，能在多個會話中提供長期、個人化且具上下文感知的互動。
- 在此取得免費 API 金鑰：app.mem0.ai
- 或從我們的開源 GitHub 儲存庫自行託管 Mem0
