Sage Wiki：從 README 拆解安裝、能力與限制
sage-wiki 是人工智慧代理和人類共同建構和查詢的圖形記憶和知識庫。放入檔案； LLM 編譯器將它們轉換為帶有知識圖譜的相互連結的 wiki。 One Go 二進位檔案將其從個人保管庫擴展到團隊中心，再到公司知識圖譜。
秒懂
- 它是什麼？
- 以官方 README 的命令、設定與專案結構，整理 Sage Wiki 的適用範圍與核驗重點。
- 適合誰用？
- Sage Wiki 適合需要其 README 所列工作流、且能接受來源未承諾部分由自己驗證的使用者；不適合把文件清單直接當成生產保證的人。先依專案指定命令、檔案與發布格式完成一次最小流程，記錄實際輸出，再決定是否納入日常環境。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 3 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月14日）與我們的分析，不構成法律意見。
開源專案深度解析
文件進來，帶知識圖譜的維基出去
sage-wiki 是一個用 Go 寫成的圖記憶與知識庫。README 開篇說明它的運作方式：把檔案放進來源資料夾，一個 LLM 編譯器把它們變成互相連結的維基和一張知識圖譜。人類以相容 Obsidian 的 Markdown 瀏覽結果，智慧體則透過模型上下文協定（MCP）查詢，該協定以包含 19 個工具的伺服器形式暴露。專案源自 Andrej Karpathy 關於 LLM 編譯個人知識庫的想法，並建構在 Sage Framework 之上。README 將它定位為從個人 Obsidian 儲存庫覆蓋層到由 PostgreSQL 支撐的公司級知識圖譜。
README 將 Sage Wiki 描述為與 Sage 生態系相關的文件或知識入口；使用前應對照其頁面結構、連結與更新紀錄，不能把文件內容視為執行時保證。 本節聚焦 Sage Wiki 的第 1 個觀察點。若要採用，應直接執行上述命令或開啟專案指定的設定檔，觀察輸出、錯誤訊息、產物與版本行為是否符合你的工作流程。這些觀察點比抽象的功能清單更能分辨文件描述與環境實際結果。
圖譜是檢索通道，不是側面視圖
向量檢索回傳與查詢相似的片段；圖譜還記錄事物之間如何關聯，因此需要兩跳或三跳的問題透過遍歷來回答。sage-wiki 在編譯期間建構這張圖譜，而不是維護第二個需要同步的資料庫。預設圖譜把同一塊中關係關鍵詞與 [[wikilink]] 共現的概念相連。選用流程增加證據：三元組抽取（每份文件多一次 LLM 呼叫）產生帶證據跨度、0 到 1 信賴度和來源文件的型別化實體與關係；實體解析把 K8s 和 Kubernetes 這類變體合併為同一節點，提案預設經過審查門檻，閾值為 0.85 時自動套用。搜尋融合三個通道：詞法 BM25、向量和圖譜鄰近度，用加權 RRF 合併。邊是雙時的：反駁一個事實會使舊邊失效，as_of 查詢回答維基在過去某個日期相信什麼。
README 將 Sage Wiki 描述為與 Sage 生態系相關的文件或知識入口；使用前應對照其頁面結構、連結與更新紀錄，不能把文件內容視為執行時保證。 本節聚焦 Sage Wiki 的第 2 個觀察點。若要採用，應直接執行上述命令或開啟專案指定的設定檔，觀察輸出、錯誤訊息、產物與版本行為是否符合你的工作流程。這些觀察點比抽象的功能清單更能分辨文件描述與環境實際結果。
編譯管線與支援的格式
管線接受 Markdown、PDF、Word、Excel、PowerPoint、CSV（最多 1000 列）、EPUB、電子郵件、純文字、字幕、影像（由視覺 LLM 產生說明）和程式碼。未列出的格式可以由外部解析器處理：任何語言的指令碼讀取標準輸入並把文字寫到標準輸出，在雙重選擇同意後作為子程序執行。編譯分四層：第 0 層用 FTS5 建索引，第 1 層加向量嵌入，第 2 層用程式碼解析器而不呼叫 LLM，第 3 層是完整 LLM 編譯，負責摘要、抽取概念和寫文章。README 給出的專案佈局顯示 raw/ 放來源檔案，wiki/ 放編譯後的 Markdown，包含 summaries、concepts、under_review 和 archive 資料夾，另有一個 SQLite 檔案容納 FTS 索引、向量、本體和佇列。
README 將 Sage Wiki 描述為與 Sage 生態系相關的文件或知識入口；使用前應對照其頁面結構、連結與更新紀錄，不能把文件內容視為執行時保證。 本節聚焦 Sage Wiki 的第 3 個觀察點。若要採用，應直接執行上述命令或開啟專案指定的設定檔，觀察輸出、錯誤訊息、產物與版本行為是否符合你的工作流程。這些觀察點比抽象的功能清單更能分辨文件描述與環境實際結果。
面向智慧體與人類的介面
同一份資料上有三個介面。終端儀表板有四個標籤頁：瀏覽、搜尋、問答和即時編譯監視。Web 介面用 Preact 和 Tailwind 建構，透過 go:embed 在建構標籤後嵌入，提供帶渲染 Markdown 的文章瀏覽器、混合搜尋、力導向知識圖譜視圖和串流問答。MCP 伺服器透過 stdio 或 SSE 暴露 19 個工具，包括只基於序列化圖邊的多跳圖問答工具 wiki_graph_query，以及把洞察寫回知識庫的 wiki_capture。實驗性的 /v1 HTTP API 把同樣的工具掛成 REST 路由，帶 Bearer 認證和編譯、lint 的非同步任務。型別化的 Python 與 TypeScript 用戶端覆蓋 /v1 表面，Go 程式可以完全跳過 HTTP，透過程序內 MCP 傳輸嵌入 pkg/sagewiki。
README 將 Sage Wiki 描述為與 Sage 生態系相關的文件或知識入口；使用前應對照其頁面結構、連結與更新紀錄，不能把文件內容視為執行時保證。 本節聚焦 Sage Wiki 的第 4 個觀察點。若要採用，應直接執行上述命令或開啟專案指定的設定檔，觀察輸出、錯誤訊息、產物與版本行為是否符合你的工作流程。這些觀察點比抽象的功能清單更能分辨文件描述與環境實際結果。
維運、成本與大型儲存庫
儲存預設是一個 SQLite 檔案；伺服器部署的文件使用 PostgreSQL 加 pgvector。查詢輸出先被隔離，直到接地、經共識確認或手動提升，README 把這套流程稱為輸出信任。編譯管線追蹤 token 用量並估算成本，預設開啟提示快取（README 稱對 Anthropic、Gemini 和 OpenAI 的輸入 token 節省 50% 到 90%），並支援把大型編譯成本減半的批次 API。對於大型儲存庫，分層編譯先給一切建索引；README 給出約 5.5 小時完成 10 萬文件第 1 層索引的數字，完整 LLM 編譯隨後按需執行。憑證在可用時存進作業系統鑰匙圈，auth migrate 指令負責遷移檔案儲存的憑證。
README 將 Sage Wiki 描述為與 Sage 生態系相關的文件或知識入口；使用前應對照其頁面結構、連結與更新紀錄，不能把文件內容視為執行時保證。 本節聚焦 Sage Wiki 的第 5 個觀察點。若要採用，應直接執行上述命令或開啟專案指定的設定檔，觀察輸出、錯誤訊息、產物與版本行為是否符合你的工作流程。這些觀察點比抽象的功能清單更能分辨文件描述與環境實際結果。
套件、基準與授權
八個離線貢獻套件為學術研究、軟體工程、法律合規等領域打包本體型別、提示詞和技能觸發器。README 報告兩套基準：在公開資料集上用 LLM 評委打分的記憶基準（LOCOMO 92.0%、LongMemEval 93.3%、BEAM 100K 平均 nugget 0.691），並明確說明這些是抽樣集，與已發佈的 Mem0 Platform 數字不是同口徑對比；另一套品質和效能評估報告十個維基的中位總分為 87.4%。專案處於 1.0 之前，README 反覆建議鎖定版本。儲存庫以 MIT 授權發佈，授予使用、複製、修改、合併、發佈、分發、再授權和出售副本的權利，並宣告軟體按現狀提供、不附帶任何擔保；授權文字沒有提及支援、安全態勢或維護承諾。
README 將 Sage Wiki 描述為與 Sage 生態系相關的文件或知識入口；使用前應對照其頁面結構、連結與更新紀錄，不能把文件內容視為執行時保證。 本節聚焦 Sage Wiki 的第 6 個觀察點。若要採用，應直接執行上述命令或開啟專案指定的設定檔，觀察輸出、錯誤訊息、產物與版本行為是否符合你的工作流程。這些觀察點比抽象的功能清單更能分辨文件描述與環境實際結果。
編輯結論
Sage Wiki 適合需要其 README 所列工作流、且能接受來源未承諾部分由自己驗證的使用者；不適合把文件清單直接當成生產保證的人。先依專案指定命令、檔案與發布格式完成一次最小流程，記錄實際輸出，再決定是否納入日常環境。
社群筆記