llm-wiki：把研究筆記編譯成 LLM 可查詢的知識庫
LLM-compiled knowledge bases for any AI agent. Parallel multi-agent research, thesis-driven investigation, source ingestion, wiki compilation, querying, and artifact generation.
秒懂
- 它是什麼？
- nvk/llm-wiki 是一套以 Python 撰寫、MIT 授權的 agent 外掛，把原始素材編譯成主題式 wiki，再讓 AI agent 查詢與產出文件。它的價值在流程約束，不在生成能力本身。
- 適合誰用？
- 若你已經在用 Claude Code 或 Codex，而且手上有一批散落的來源檔案與未整理的想法，llm-wiki 的主題式 wiki 加上 read-only 的 wiki-query 技能值得先試。若你需要的只是單次問答、或不想讓 agent 在你的 vault 目錄寫入檔案，這套流程反而增加負擔。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它處理的不是問答，而是素材到知識的落差
多數人用 LLM 的流程是：貼一段文字，得到一段回答，然後那段回答消失在對話紀錄裡。下一次要用的時候，得重新貼一次。llm-wiki 針對的正是這個斷點。README 把它描述為「LLM-compiled knowledge bases for any AI agent」，工作流是先用 /wiki:research 之類的指令蒐集與整理素材，再經由編譯步驟把素材寫成主題式 wiki 頁面，之後才用查詢指令取用。
它的目標使用者不是想找一個通用聊天介面的人，而是已經有主題意識的個人研究者或小團隊。README 舉的例子包括硬體錢包威脅模型、bitcoin memes 這類具體主題，並用 --wiki 參數指定主題名稱。這代表使用者必須先決定「我關心什麼主題」，而不是期待工具自己長出分類。這個前提本身就是一道篩選。
另一條線是 Idea 與 Project 的區分。README 描述可以「Capture rough Ideas, research and shape them, then explicitly promote approved briefs into delivery Projects」。Idea 是粗糙的、還在成形的；Project 必須經過明確的 promote 動作才會成立。v0.18.0 的 /wiki:portfolio 更明確列出 canonical Ideas 與 active Projects，並區分「explicitly promoted」與「direct」兩類 Project。這種把構想與交付分開的設計，是它與單純筆記工具最大的差異。
編譯管線與適配器邊界
從 changelog 的演進可以看出架構走向。v0.19.0 引入「Private adapter protocol」，定義了 llm-wiki-adapter/v1 的 JSON 契約，包含 manifest handshakes、path scopes、sanitized environments 與 hash-verified artifacts，並強調這個邊界「never passes a wiki destination or auto-promotes adapter output」。v0.22.0 進一步改成宣告式路由，適配器自行宣告 provider-neutral intent 與 exact-URL routes，公開外掛只負責在擷取前發現路由，不再內嵌任何供應商的認證、瀏覽器或編輯流程。
這個切分方式值得注意。公開 repo 保留的是框架與契約，涉及登入、瀏覽、復原的供應商細節則移到私有適配器。對使用者來說，好處是核心外掛不會因為某個網站的登入流程改版而整批壞掉；代價是如果你需要的來源剛好沒有對應的適配器，就得自己依契約實作，而公開 repo 並不提供那些實作範例。
v0.20.0 再往外延伸一層，加入 governed remote writes：遠端資源 allowlist、宣告讀寫效果、綁定計畫雜湊的明確核准、expected revisions、idempotency keys 與 verified receipts。這說明專案對「agent 自動寫入外部系統」的態度是保守的，寧可多一層人工核准。v0.24.0 的 Project Knowledge Checkpoints 同樣延續這個立場，README 的 changelog 寫明 checkpoint 寫入「never authorize commit, publication, or import」。
安裝路徑依 runtime 分歧
Claude Code 走原生外掛，一行指令：claude plugin install wiki@llm-wiki。
Codex 走 marketplace，需要兩步：codex plugin marketplace add nvk/llm-wiki 註冊目錄，再 codex plugin add wiki@llm-wiki 安裝並啟用快取的插件。若用本地 checkout，README 提供 ./scripts/bootstrap-codex-plugin.sh --scope user --verify，或手動以絕對路徑註冊。升級是 codex plugin marketplace upgrade llm-wiki 加一次 codex plugin add。
OpenCode 沒有外掛安裝步驟，改成在 opencode.json 的 instructions 陣列指向遠端 SKILL.md URL，並在 permission.external_directory 開兩個路徑：~/.config/llm-wiki/** 與 iCloud 路徑下的 wiki 目錄。README 說明 OpenCode 每次 session 啟動都會重新抓取該 URL，所以不需要手動更新。想縮小權限範圍的話，可改用 wiki-query 的 SKILL.md，那是唯讀版本。
Codex 這邊有幾個容易卡住的點，README 的 troubleshooting 列得很直白：@wiki 技能在 hook 未信任時仍可用，但自動 session 擷取需要先到 /hooks 信任綑綁的 hook；$wiki-query 是明確、唯讀的查詢技能，不會隱式啟動；改動 config 後要重啟 Codex 才會生效；若在 nono 這類沙箱包裝下執行，Codex 需要 $HOME/.codex 的讀寫權限才能安裝外掛。
查詢深度與研究模式是兩個獨立旋鈕
README 的目錄把 Research Modes、Thesis Research、Query Depths 分成三節，代表研究階段與查詢階段各自有控制參數，而不是一個籠統的「深度」設定。Thesis-driven research 意味著研究可以帶著一個待驗證的命題進行，而不是無方向地蒐集。這對寫作或盡職調查類的用途比較貼近，因為你通常已經有一個想推翻或支持的說法。
指令面可以看到分工：@wiki research 負責研究，@wiki collect 帶 --wiki 指定主題做蒐集，@wiki ingest 吃單一 URL，@wiki audit 帶 --project 做稽核，@wiki session status 看 session 狀態，@wiki feedback list --unpromoted 列出尚未 promote 的回饋，@wiki ll 則是查詢。
這裡有一個明確的取捨。指令數量多、每個都有自己的參數，學習曲線比單純丟問題給模型高。而且 audit 綁在 --project 上，表示稽核的對象是已 promote 的 Project，不是隨手的 Idea。如果你從來不 promote，audit 對你就沒什麼用。
v0.23.0 加入的 personal specialist framework 是另一個值得留意的設計：使用者可以在自己的本地 wiki hub 下放 instruction-only 的 SKILL.md 作為審查方法，搭配 per-topic allowlist 與 version/hash provenance。README 特別聲明公開版本只含框架，個人 specialist 套件與 wiki 衍生的候選報告不會被綑綁或發布。這對在意資料外流的人是加分，但也意味著這部分你得自己養。
Obsidian 相容與 session 記憶的實際代價
README 標明 Obsidian-compatible，OpenCode 的權限範例也直接指向 iCloud 的 wiki 目錄。這暗示它預設使用者會把編譯結果當成一般 markdown vault 來讀，而不是鎖在專有介面裡。對已經有 vault 的人來說，這是降低遷移成本的做法。
Session 記憶靠 hook 實作。Codex 的說明提到要到 /hooks 檢視並信任綑綁的 hook，才能有自動 session 擷取；README 也提供 @wiki session disable 作為 opt-out。這裡的關鍵是：hook 未信任時，@wiki 技能仍可運作，但自動擷取不會發生。也就是說，你可以在不信任 hook 的前提下使用研究與查詢功能，只是失去記憶累積。
v0.24.3 的版本標題是 Privacy-Sensitive Log Retraction，v0.24.4 是 Adapter CLI Compatibility，v0.24.2 是 Safe Index Contract Repair。三個連續版本分別處理日誌撤回、CLI 相容與索引契約修補，這個節奏說明專案仍在頻繁調整內部契約。對打算長期依賴的人，這代表升級不是無痛的，尤其是在你已經寫了自訂適配器或依賴索引格式的情況下。README 沒有描述索引格式的穩定性保證，這一點無法從現有材料確認。
什麼情況下它會變成負擔
最明顯的限制是 runtime 綁定。README 列出 Claude Code、OpenAI Codex、OpenCode 與 portable agents，但安裝章節只給這三者的具體步驟。如果你的 agent 不在這份清單裡，你得自己處理 SKILL.md 的載入方式，公開材料沒有提供通用安裝路徑。
第二個限制是它假設你願意維護主題結構。--wiki 參數要求你替每個主題命名，v0.18.0 的 portfolio 也明確說要避免 catch-all topics 與重複記錄。這表示如果主題界線模糊，你會需要不斷手動整理，而工具本身不做這件事。
第三，v0.22.0 之後公開外掛不再內嵌任何供應商的認證與瀏覽流程。這在架構上是乾淨的，但對只想抓某個需要登入的網站的人來說，公開版本幫不上忙，得走私有適配器那條路。
如果你要的只是把幾份 PDF 丟進去問問題，用一般的 RAG 工具或直接把內容貼進對話視窗更快。llm-wiki 的整套流程是為了「同一主題反覆研究、需要累積與稽核」的情境設計的，單次任務用不上 promote、audit、portfolio 這些機制。
與一般 RAG 工具的路線差異
典型的檢索增強生成做法是：把文件切塊、向量化、存進索引，查詢時取回最相似的片段塞進 context。知識本體是原始文件，切片只是為了塞進視窗。llm-wiki 走的是相反方向：它先把素材編譯成主題式 wiki 頁面，也就是知識在進入查詢階段之前就已經被重寫、合併與結構化過一次。查詢面對的是編譯產物，不是原始切片。
這個差異帶來兩個後果。好處是 wiki 頁面本身可以被人閱讀、被 Obsidian 開啟、被 commit 進版控，檢索品質不依賴切塊策略。代價是編譯階段會引入 LLM 的改寫，而 README 沒有描述編譯的驗證機制，v0.24.0 的 checkpoint 提到「read-only verification」與「exact source and section coverage」，但那是針對 checkpoint 匯出，不是針對 wiki 編譯本身。
另一條對照是純筆記工具。筆記工具不會替你研究，也不會替你編譯；llm-wiki 把研究、編譯、查詢、稽核串成管線，並用 Idea 與 Project 的狀態區分把關。你換到的是流程約束，付出的是學習指令與維護主題結構的時間。
授權是 MIT，這代表你可以修改、商用、再散布，只要保留授權聲明。README 沒有提到任何商業支援或託管服務，llm-wiki.net 是專案首頁，但材料中沒有說明它提供什麼。這一點我無法從現有資訊判斷。
編輯結論
若你已經在用 Claude Code 或 Codex，而且手上有一批散落的來源檔案與未整理的想法，llm-wiki 的主題式 wiki 加上 read-only 的 wiki-query 技能值得先試。若你需要的只是單次問答、或不想讓 agent 在你的 vault 目錄寫入檔案，這套流程反而增加負擔。動手前先確認三件事：你的 agent 是否支援外掛安裝、~/.config/llm-wiki 是否在可寫路徑內、以及 hooks 是否已被信任，因為 session 記憶與自動擷取都依賴 hook 信任狀態。
社群筆記