前幾天我們總算把混沌工程的主角 lite-bank 與監控架構都搞定了，但這時候問題來了：我要怎麼讓 AI Agent 記得這個系統的所有背景知識？如果每次要它跑混沌實驗，它都得重新看一遍所有程式碼、去讀 API 規格、看資料庫 schema，這不僅燒 token，context 太長 AI 也會直接變笨。

這時候你可能會問：「有 RAG 不就好了？」常見的 RAG 流程會在每次提問時，先從原始資料找出相關片段，再交給 LLM 整理答案。遇到需要跨多份文件推導的問題，下次提問時還是得重新找資料、重新拼一次。

有些 RAG 架構還會帶上 embedding、chunk 與 Vector DB，等於又要多維護一套東西。（誰想維護資料庫）

把知識寫下來之後，總要訂出一套結構與規則。當時我剛好看到社群正在討論 llm-wiki，就跑去研究它到底在做什麼。看完才知道，這是 Andrej Karpathy 提出的一種知識整理方法。

接下來簡單介紹一下 llm-wiki。完整概念可以參考他放在 GitHub 上的原始說明。

核心理念

llm-wiki 在「人」與「原始資料」之間，放入一個由 Markdown 檔案構成的持久化 Wiki 資料夾。Wiki 內容主要由 LLM 寫入與維護；人類負責挑選來源、引導整理方向、檢查變更，並持續調整 Schema。

當我們加入一份新的 Raw Source，例如某個系統的架構圖或 K8s YAML，還要明確要求 Agent 執行 Ingest。Agent 會先讀取來源、跟我們確認重點，再把內容整合進現有的 Wiki。

舉個例子，假設我們把一個新的 payment-service.yaml（部署設定檔）當成 Raw Source 丟給系統：

1. 更新特定的頁面：LLM 會自動跑去 payment-service.md，把這隻服務的 Port 號、環境變數或 CPU Limit 更新進去。
2. 修改主題總結：它會順手打開 系統總體架構.md 或 資源使用總覽.md，把這個新服務塞進列表裡，重新計算總資源用量。
3. 標註新舊資料之間的矛盾：如果它發現 payment-service.yaml 裡設定的 connection pool 上限，早就超過了 postgres.md 裡面記錄的資料庫最大連線數，它就會直接在檔案裡噴一個「警告：連線數設定衝突」的標籤，提醒你設定有鬼。
4. 自動建立關聯連結：它看到這個服務會呼叫 order-service 的 API，就會在 payment-service.md 加入 [[order-service]] Wiki Link。使用 Obsidian 查看時，也能透過 Backlinks 找到哪些頁面引用了 order-service，不用自己手動整理關聯。

這是一種「一次編譯，持續更新」的概念。知識會先被整理並保存到 Wiki；收到問題時，Agent 直接查詢這些已經整理過的內容。隨著新資料與問答加入，Wiki 也會像滾雪球一樣越來越豐富。

llm-wiki 的三層架構

Karpathy 提出的 llm-wiki 設計非常簡潔，主要由三個層次組成：

1. Raw Sources

人類收集並提供給系統的原始文件，例如論文、程式碼、API 規格、K8s YAML 等。這層資料不可修改，LLM 只能讀取，也是整套系統的唯一可信來源。

2. Wiki

一個 Markdown 檔案目錄，包含了實體頁面、概念總結、比較表格、索引檔等。這一層完全由 LLM 掌控，LLM 負責建新頁面、更新舊內容、維持頁面之間的連結與內容一致。

3. Schema

這是一個說明文件（例如 repo 中的 AGENTS.md 或 CLAUDE.md），用來引導 LLM 當個「紀律嚴明的 Wiki 維護者」，防止它在 Markdown 裡面胡言亂語。這份檔案會定義 Ingest、Query 與 Lint 的詳細流程規範。

運作機制

整套流程主要分成三個核心機制：

Ingest

每次加入新的 Raw Source，我們會要求 LLM 執行 Ingest。它會先讀取來源、跟人討論哪些內容值得保留，再建立或更新相關的 Wiki 頁面，最後同步修改 index.md 與 log.md。例如加入一份新的 API 規格，可能會連帶更新 10～15 個相關頁面，把新的 endpoint 資訊整理進現有知識中。

Query

當你向 Wiki 提問時，LLM 會先去查目錄或搜尋對應的頁面，整合後輸出。這裡最厲害的設計在於：好的問答與分析成果，可以被直接保存回 Wiki 中當作新頁面。這讓我們的討論過程與推導結論，也能像資料一樣沉澱下來。

Lint

定期請 LLM 替 Wiki 做一次體檢。它會掃描 Markdown 檔案，找出互相矛盾的內容、已經過期的說法、沒有人連結的孤兒頁面（Orphan Pages），以及漏掉的頁面連結。檢查完成後，它也會列出目前缺少哪些資料，提醒我們接下來可以補哪些來源。

兩大輔助檔案：Index 與 Log

為了讓 LLM 在不需要複雜的向量資料庫（Vector DB）架構下也能高效運作，llm-wiki 導入了兩個特別的檔案：

• index.md（內容導向）：這是整套 Wiki 的大目錄。LLM 每次執行 Ingest 時都會更新它；收到問題後，也會先讀取 index.md，像翻書本目錄一樣，判斷接下來需要讀哪些頁面。在大約 100 份來源、數百個頁面的中等規模下，這種方式通常已經足以支撐基本導覽。如果 Wiki 繼續長大，就要再觀察只靠 index.md 是否還找得到需要的資料，再依實際情況尋找其他做法。
• log.md（時間導向）：一個 append-only 的操作 log，記錄了什麼時候做了 Ingest、什麼時候跑了 Query。因為每個記錄都有固定的 prefix，我們可以直接用 grep 或是 tail 快速過濾出最近的操作紀錄。

結論

在 llm-wiki 的世界裡，Obsidian 是 IDE，LLM 是程式設計師，而 Wiki 就是我們的程式碼。

整理頁面之間的連結、保持一致性、更新總結這些最沒人想做的筆記維護工作，可以交給 LLM 處理。人類則把時間放在挑選可信的資料、引導分析方向，以及檢查 Agent 寫進 Wiki 的內容有沒有亂講。

到這裡，我們已經知道 llm-wiki 如何讓知識隨著資料與問答持續累積。

下一篇先替這個大腦訂規則，看看 lite-bank 的 Schema 該怎麼設計，開始準備後續混沌工程實驗要用的系統知識庫。我們明天見！