為什麼版本化的 Markdown 資料夾是 AI 代理的理想「大腦」

過去幾年，AI 產業一直走高複雜度的路徑來解決代理的記憶問題。數百萬美元被投入專有記憶系統與龐大的向量資料庫，以解決「遺忘」問題。然而，當這些系統投入生產後，工程師們遇到一系列重複出現的失敗：會話重置、知識缺口，以及「學習洩漏」——關鍵洞見在會話結束的瞬間即消失。

與其說這是上下文窗口的問題，不如說是組織知識的問題。對於生產等級的代理部署而言，逐漸形成的共識是：對代理最有效的「大腦」不是複雜的資料庫，而是以 Git 版本化資料夾儲存的簡單純文字 Markdown 檔案系統。

純向量記憶的失敗

許多團隊最初使用純向量資料庫部署 RAG（檢索增強生成）。雖然在語意相似度上很強大，但這些系統帶來了多個關鍵的失敗點：

  • 不透明儲存： 向量資料庫以浮點數陣列儲存意義。如果代理學到錯誤的資訊，無法簡單打開資料庫並編輯文字來修正。
  • 時間矛盾： 向量儲存常在事實演變時出問題。如果客戶的地址變更了三次，向量搜尋可能把三個版本都視為「相關」，導致代理混亂。
  • 維護缺口： 大多數 RAG 設定失敗並非技術本身，而是知識庫變得雜亂，讓人類難以整理或稽核。

Git 後端大腦的架構

兩個顯著的例子——Garry Tan 的 GBrain 與社群驅動的 DiffMem 專案——展示了此簡化方法的威力。

GBrain 模型

GBrain 採用「上層編譯真相、下層僅追加時間線」的模式。每個頁面包含隨新證據出現而重寫的活躍摘要，之後是一條不可變更的時間線，保留證據追蹤。這讓代理能取得當前真相，同時為人類保留完整稽核紀錄。

  • 混合搜尋： 結合 BM25（關鍵字搜尋）與 pgvector 進行語意檢索。
  • 自動化知識圖譜： 從 Markdown 寫入中抽取類型化連結（例如 works_at、invested_in），無需昂貴的 LLM 呼叫。
  • 夜間夢境循環： 在系統閒置時，對實體頁面進行豐富、記憶整合與引用修正的流程。

DiffMem 方法

DiffMem 把 Git 視為記憶的主要版本引擎。透過將對話儲存為提交，開發者可以使用 git diff 觀察代理對某主題的理解如何隨時間演變。這提供了在標準向量儲存中無法達到的可重現性與透明度。

為什麼 Markdown 與 Git 獲勝

1. 以人為本的可維護性

在基於 Markdown 的系統中，人類是第一級的作者。行銷負責人可以在標準文字編輯器中更新品牌語調指南，提交變更後，代理立即繼承新知識。這種雙向同步是企業知識管理最強大的模式。

2. 版本控制即記憶演化

Git 將歷史視為第一級資產。團隊可以二分查找事實何時被破壞、分支測試不同的知識配置，或還原引發幻覺的「學習」會話。

3. 多代理安全性

當多個代理寫入同一向量資料庫時，競爭條件與嵌入漂移常見。Git 的分支與合併模型提供經驗驗證的併發框架，讓代理在知識的「功能分支」上工作，然後再合併回主大腦。

回應反對意見

對 Markdown 為先的做法的批評者常提出規模與搜尋效率的顧慮。然而，證據顯示這些是可解決的實作細節，而非架構阻礙：

  • 關於語意搜尋： 混合搜尋（BM25 + 稀疏向量）常能匹配或超越純向量檢索在代理記憶上的表現。目標是為 Markdown 檔案建立索引以供搜尋，而非以嵌入取代檔案本身。
  • 關於權限： 雖然 Git 預設是開放的，但企業級權限可透過 access-policy.yaml 層在檢索時過濾結果來處理。
  • 關於技術門檻： 非技術使用者不必直接使用 Git；他們可以透過 Obsidian、Notion 匯出或自訂的 Web UI 與系統互動，這些介面會寫入 Markdown 後端。

綜合：新興標準

產業正趨向一種以人類可讀性與稽核性為優先，而非專有複雜度的模式。成功的技術堆疊包括以 Markdown 捕捉知識、以版本化資料夾結構（例如 /people、/companies、/procedures）儲存，並使用 YAML frontmatter 來記錄中繼資料與權限。

正如社群開發者所指出的，問題從未在於儲存記憶，而在於組織記憶，使代理能使用且人類能維護。將代理的大腦視為版本化文件庫，組織即可打造一個不僅智慧且透明、可編輯且可信賴的系統。

Sources