llm-wiki-agent：把 raw/ 目錄交給 coding agent，讓它自己長出一座互連 wiki
A personal knowledge base that builds and maintains itself. Drop in sources — Claude (or Codex/Gemini) reads them, extracts knowledge, and maintains a persistent interlinked wiki. Works with Claude Code, Codex, OpenCode, Gemini CLI. No API key needed.
秒懂
- 它是什麼？
- 這是一個掛在 Claude Code、Codex、Gemini CLI 等 coding agent 上的 skill，把散落的來源文件轉成持續累積的 markdown wiki 與知識圖。它的價值不在檢索，而在 ingest 當下就完成的交叉引用與矛盾標記；代價是你把知識庫的結構主導權交給了模型。
- 適合誰用？
- 如果你已經每天開著 Claude Code 或 Codex，而且手上有長期累積、格式混雜的來源文件，這個專案值得先拿十份真實文件跑一輪 ingest，再打開 graph/graph.html 檢查 entity 與 concept 的切分是否符合你的心智模型。若你的來源大多是掃描 PDF、需要精確引用頁碼，或你要求每一條知識都能追溯到原文段落，那它現階段的設計不是為你準備的，因為 README 只描述 ingest 與查詢的流程，沒有交代引用回溯與 OCR 的處理方式。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的不是搜尋問題，而是維護問題
多數個人知識工具的假設是：你把筆記存好，之後再自己想辦法找回來。搜尋品質再好，交叉引用、矛盾比對、跨來源綜整這些工作仍然落在人身上，而且沒有人會定期回頭做。llm-wiki-agent 把這個順序倒過來。README 的定位句寫得很直接：多數知識工具讓你搜尋自己的筆記，這個工具則讀完你收集的一切，寫出一座會隨時間累積的結構化 wiki。
它的目標使用者是已經在用 coding agent 的人。安裝段落列出的前置條件是 Claude Code、Codex、Gemini CLI，或任何會讀設定檔的 agent，並且明講不需要 API key、不需要 Python 環境設定。換句話說，它不打算服務想要一個獨立桌面應用的人，而是寄生在你本來就開著的終端 session 裡。這個選擇決定了它的成本結構：沒有額外的服務要維運，但你每一次 ingest 都在消耗 agent 的 context 與時間。
ingest 是唯一入口，wiki 是被推導出來的產物
整個系統的資料流可以從 README 的目錄樹讀出來。來源文件先放進 raw/，agent 讀取後在 wiki/ 底下產生對應頁面：sources/ 一份來源一頁，entities/ 放人物、公司、專案，concepts/ 放想法、框架、方法，syntheses/ 則把查詢的答案存回成 wiki 頁面。index.md 是全部頁面的目錄，每次 ingest 都更新；overview.md 是跨全部來源的即時綜整，同樣每次 ingest 重寫；log.md 依描述是 append-only 的操作紀錄。
第二層是 graph/。graph.json 存節點與邊，README 標注它帶 SHA256 快取；graph.html 是 vis.js 的互動視覺化，用瀏覽器直接開。圖上的邊有兩種：一種來自頁面裡的 [[wikilink]]，另一種是模型推斷出的隱含關聯，在圖上以虛線呈現。README 另外提到社群偵測會把相關主題聚成叢集。
這裡有一個值得注意的設計取向：矛盾不是等到查詢時才浮現，而是在 ingest 當下就被標記。這代表 agent 在寫入每個新來源時，必須拿它去比對既有頁面的主張。好處是問題不會被埋在檔案堆裡；代價是每次 ingest 的工作量隨 wiki 規模上升，而不是固定成本。
啟動只需要 git clone，觸發詞才是真正的介面
安裝步驟只有兩行：git clone 專案，cd 進去，然後用你慣用的 agent 開啟。README 列出四種啟動方式，claude 會讀 CLAUDE.md 與 .claude/commands/，codex 與 opencode 讀 AGENTS.md，gemini 讀 GEMINI.md。Claude Code 另外提供 /wiki-ingest、/wiki-query、/wiki-lint、/wiki-graph 四個 slash command，README 明確指出這組指令是 Claude Code 專屬，其他 agent 走自然語言觸發，行為一致。
實際操作層面，README 給的範例是這幾種寫法：ingest raw/papers/my-paper.md 處理單一 markdown；ingest report.pdf 會先自動轉檔再 ingest；ingest slides.pptx notes.docx 支援批次混合格式；query: what are the main themes? 從既有 wiki 頁面綜整答案；lint 找出孤兒頁面、矛盾與缺口；build graph 從所有 wikilink 產生 graph.html。自然語言也通，例如「Ingest this paper: raw/papers/llama2.md」或「Check for contradictions across sources」。
格式支援方面，README 列出 markdown、PDF、DOCX、PPTX、XLSX、HTML、TXT、CSV、JSON、XML、RST、EPUB 等，非 markdown 檔案在 ingest 時透過 markitdown 自動轉換，不需要獨立的前置步驟。這是整個流程裡唯一的外部依賴，也意味著轉檔品質會直接決定後續抽取的品質上限。
lint 的建議來自 wiki 自身的缺口，不是外部索引
lint 這個動作值得單獨看。README 在企業情境的範例裡給了兩條輸出樣貌：某個專案在五個頁面被提到卻沒有專屬頁面，以及 roadmap 與客戶訪談在某个功能優先順序上互相矛盾。研究情境的範例則更進一步，lint 會指出「沒有關於 mixture-of-experts 的來源，可以考慮 Mixtral 論文」。
這種建議的來源是 wiki 內部的連結結構與覆蓋密度，不是任何外部資料庫或文獻索引。它偵測的是你已經放進 raw/ 的東西之間的落差，所以它給的建議品質，取決於你餵進去的來源本身有沒有形成可辨識的缺口。一份孤立來源不會產生有用的 lint 結果，因為沒有足夠的連結可以判斷什麼是「缺席」。
反過來說，這也解釋了為什麼 README 把「每個新來源都讓 wiki 更豐富」當成核心賣點。這套機制的產出確實與累積量正相關，但相關的方式是覆蓋率與連結密度，不是單純的檔案數量。
適用情境的邊界比 README 的四個範例窄
README 示範四種用途：數週的論文研究、逐章讀一本書、追蹤個人目標與健康、團隊會議與客戶訪談情報。這四個情境有共同特徵：來源是文字為主、會持續增加、而且價值來自跨來源的關聯而非單篇檢索。
反過來說，什麼情況下這是錯的工具。第一，如果你的需求是精確引用，例如法律或學術寫作要標到頁碼與段落，README 只描述 wiki 頁面的產生，沒有交代引用回溯機制，你無法從產出的頁面確認某句話出自哪一份文件的哪一段。第二，如果來源是掃描 PDF 或圖片，轉檔這關就會先卡住，而 README 沒有提到 OCR。第三，如果來源是一次性的，例如你只想讀完一篇論文就丟掉，那 ingest 加上後續維護的開銷並不划算，直接讀原文更快。第四，如果團隊需要多人同時寫入同一座 wiki，README 描述的是單一 agent session 依序 ingest 的模式，log.md 是 append-only 紀錄，但沒有提到並發寫入的處理。
還有一個結構性的風險：entity 與 concept 頁面的切分由模型決定。同一個人名在不同來源以不同形式出現時，會不會被合併成同一頁，README 沒有給出規則。這不是缺陷，而是這類自動化知識庫的固有取捨，但採用前應該先用真實資料觀察一輪。
與 RAG 管線的差異在寫入時機
最直接可比的替代方案是標準的 RAG 管線：把文件切塊、算 embedding、存進向量庫，查詢時做相似度檢索再交給模型生成。兩者的差別不在模型，而在知識被整理的時機。
RAG 把整理推到查詢時。文件原封不動進向量庫，每次提問才臨時拼湊上下文，所以同一份文件裡互相矛盾的主張不會自動被發現，除非你的問題剛好同時命中兩塊。llm-wiki-agent 把整理拉到 ingest 時，代價是寫入路徑變重，好處是矛盾與關聯在寫入那一刻就被記錄下來，而且產出是人可讀的 markdown 檔案，可以直接用 Obsidian 之類的工具打開，也可以在版本控制裡 diff。
另一個方向是 Obsidian 加社群外掛。那條路線讓你完全掌控頁面結構，但交叉引用與矛盾比對仍然要你自己做，或靠規則式的外掛。llm-wiki-agent 交出的是結構主導權，換來的是不用自己動手維護。這個交換是否值得，取決於你對 wiki 分類方式的在意程度。
維護成本與 MIT 授權的實際含意
這個專案的維護成本有兩塊。第一塊是 agent 的用量：每次 ingest 都要模型讀完新來源、比對既有頁面、改寫 overview.md，成本隨 wiki 規模成長。第二塊是 wiki 本身：頁面會持續累積，index.md 每次更新，如果 entity 切分出現漂移，清理的責任在你身上，因為 README 沒有描述任何合併或重新命名的機制。
相依性方面，README 點名 markitdown 是非 markdown 來源的轉檔工具。這代表上游 markitdown 對某種格式的處理方式改變時，你的 ingest 結果也會跟著變。graph.html 依賴 vis.js，屬於前端相依。
授權是 MIT，README 開頭的 badge 與 repo 的 License 欄位一致。實務上 MIT 允許修改、再散布與商業使用，但這不構成法律意見，如果你要把產出或程式碼併入商業產品，還是應該自己確認授權全文與第三方相依（例如 markitdown 與 vis.js）的條款。另外，README 沒有檢索到任何 release，這意味著沒有版本化的升級路徑，你追的是 main 分支的狀態。要更新，就是重新 pull 並確認 CLAUDE.md 或 AGENTS.md 是否變動。
編輯結論
如果你已經每天開著 Claude Code 或 Codex，而且手上有長期累積、格式混雜的來源文件，這個專案值得先拿十份真實文件跑一輪 ingest，再打開 graph/graph.html 檢查 entity 與 concept 的切分是否符合你的心智模型。若你的來源大多是掃描 PDF、需要精確引用頁碼，或你要求每一條知識都能追溯到原文段落，那它現階段的設計不是為你準備的，因為 README 只描述 ingest 與查詢的流程，沒有交代引用回溯與 OCR 的處理方式。決定採用前，先確認 wiki/log.md 是否如文件所述是 append-only，以及 graph.json 的 SHA256 快取在檔案內容變更後是否真的觸發重建。
社群筆記