WeKnora 拆解：把文件堆成可查的知識庫，代價在沙箱與授權
Open-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.
秒懂
- 它是什麼？
- 騰訊開源的 WeKnora 用 Go 寫成，把 RAG 問答、ReAct 代理與自動產生的 Wiki 綁在同一套多租戶平台上。這篇看它的資料流、部署指令，以及 v0.8.0 把本機沙箱後端移除後留下的實際限制。
- 適合誰用？
- 需要把 Feishu、GitLab、Notion、語雀這類來源的文件收進同一個可查知識庫，並且願意自己維護 Docker Compose 與多租戶 RBAC 的團隊，可以從 v0.8.0 開始評估。只想做單一 PDF 問答、或不想碰容器執行環境的人不必進來，v0.8.0 已移除本機沙箱後端，代理的程式執行能力只剩 Docker、E2B、Cube 三條路。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
WeKnora 想解決的是文件散在多個 SaaS 裡的檢索斷層
多數團隊的文件不是不存在，而是散在飛書、GitLab、Notion、語雀、IMA 各自一套搜尋裡。WeKnora 的定位是把這些來源拉進同一個知識庫，再往上長出問答、代理與 Wiki 三層。README 列出的擷取來源包含 Feishu wiki、Feishu Drive、GitLab、Tencent IMA、Notion、Yuque、RSS，並註明仍在增加。
它明顯不是給個人做單檔問答的工具。多租戶、多工作區、四層角色矩陣、每資源擁有者、每工作區審計日誌，這幾項一起出現，說明目標讀者是有內部合規壓力的工程團隊。README 也直接寫出「enterprise-grade」與「data sovereignty」，對應的是私有雲或地端部署需求。
反過來說，如果你只有十份 PDF 想問答，這套東西的安裝面積遠大於問題本身。它的價值來自來源多、租戶多、權限雜，這三件事你都不缺時，它才划算。
從上傳到回答：擷取、切塊、檢索、重排的實際鏈路
依 README 描述，文件進來的路徑是：多來源擷取、格式解析、切塊、向量化、存入向量庫，檢索時再經過重排。支援的格式超過十種，涵蓋 PDF、Word、圖片、Excel，v0.8.0 加入 XMind 解析與內建的 anydoc 辦公室文件解析器，後者意味著 Office 檔案不必外掛獨立服務就能在流程內處理。
問答層有兩條路。日常查詢走 RAG 快速問答；複雜任務交給 ReAct 代理，由它自行調度檢索、MCP 工具、租戶技能目錄、網路搜尋，以及在 Docker、E2B、Cube 沙箱中執行的程式。README 明確說代理會「autonomously orchestrates」這些能力，也就是工具選擇不是寫死的流程圖，而是模型每步決定。
Wiki 模式是第三條線：代理把原始文件蒸餾成互相連結的 markdown 知識庫，附互動式知識圖譜，並支援手動編輯、修訂歷史與一鍵回滾。切塊本身也能編輯，有版本 diff 與還原，還原後自動重建索引。這一點比多數 RAG 專案細：它承認切塊會切錯，並給了修補介面。
v0.8.0 移除本機沙箱後端，是這次最需要留意的變更
發布說明寫得很直白：v0.8.0 的沙箱執行環境改為工作階段持續的 Docker、E2B、Cube 三種後端，帶每租戶網路策略，Local host-process 後端被移除，Docker 改為需明確開啟。
這代表兩件事。第一，代理執行程式碼不再能直接跑在主機行程上，安全性提升，但部署前提變硬：主機必須有可用的容器執行環境，或你得接上 E2B、Cube 這類外部沙箱服務。第二，升級不是無痛替換，原本依賴本機後端的設定在 v0.8.0 之後沒有對應選項，只能改走容器路線。
README 沒有說明遷移步驟，也沒有列出從舊設定轉換的對照表。手上已有 v0.7.x 部署的人，升級前應該先確認容器環境與網路策略能不能滿足代理的執行需求，再決定是否跟進。這是文件目前偏薄的地方。
啟動指令與設定檔：Docker Compose 是主要入口
README 的 Getting Started 以 Docker Compose 為主要部署方式，服務本身是 Go 寫的模組化架構。設定集中在 `config/config.yaml`，README 指出官方文件站涵蓋約 150 個環境變數與約 360 個 API 端點，這兩個數字說明可調項目相當多，也說明預設值不一定合用。
幾個在 README 中被點名的鍵值值得先看：`RESOURCE_URL_MODE` 對應 `resource_urls=public`，開啟後第三方應用能直接載入圖片與檔案 URL，不必再走一次帶認證的代理請求。這對要嵌入外部網站的場景有用，代價是資源 URL 變成公開可達，需要自行評估暴露範圍。
模型供應商方面，README 列出 20 多種整合，包含 OpenAI、DeepSeek、Qwen、Zhipu、Hunyuan、Gemini、MiniMax、NVIDIA、LiteLLM、Ollama。向量庫與儲存後端可換，且支援每個工作區使用不同的儲存後端實例，資料落地位置因此可以按工作區切分。觀測性接 Langfuse，另有執行期任務佇列儀表板與 worker pool 治理。
要注意的是，README 沒有在本文中給出可直接複製的 `docker compose up` 完整片段，實際指令請以官方文件站與儲存庫內的 compose 檔為準，不要照著二手教學拼湊。
授權標示不一致，採用前必須自己確認
README 的徽章寫的是 MIT，並連到 `LICENSE` 檔。但 GitHub 對這個儲存庫的授權判定是 NOASSERTION，意思是平台無法從檔案內容自動識別出標準授權條款。兩者不一致。
這種情況常見於自訂授權、附加條款，或檔案格式非標準。對商業採用來說，差別可能很大：MIT 允許幾乎無限制使用，自訂條款則可能帶商用限制、商標條款或附加義務。
這裡不提供法律意見，只指出事實：徽章與平台判定對不上。要落地的人應該直接讀 `LICENSE` 全文，必要時走內部法務流程。把 README 徽章當成授權結論，是這類專案最常見的誤判。
與 Dify、RAGFlow 的取向差異
同類專案裡，Dify 走的是視覺化工作流編排，重點在把 LLM 應用拉成一張可拖拉的流程圖；RAGFlow 把資源壓在深度文件解析，尤其是複雜版面的 PDF。WeKnora 的重心不在這兩處。
它的差異點在來源同步與 Wiki 產出。Feishu、GitLab、Notion、語雀這類來源是持續同步而非一次性上傳，Wiki 模式則把蒸餾結果寫成可編輯、可 diff、可回滾的 markdown，而不是只留一份向量索引。切塊層級同樣可編輯並重建索引，這在 RAGFlow 與 Dify 的公開說明裡不是主要賣點。
代價是代理執行面的複雜度。Dify 的工具呼叫相對收斂，WeKnora 把沙箱、技能目錄、MCP、網路搜尋全部掛進 ReAct 迴圈，能做的事更多，需要治理的面也更大。選擇時該問的是：你要的是可預測的流程，還是願意為自主性付維運成本。
維護成本與版本節奏
從發布紀錄看，v0.7.1、v0.7.2、v0.8.0 分別落在 2026 年 7 月下旬、8 月上旬與 9 月初，節奏偏快，且 v0.8.0 屬於帶破壞性變更的版本。這對自行部署的團隊意味著升級需要排程，不能無腦跟進。
維運面有幾項固定支出：容器執行環境（沙箱需要）、向量資料庫、LLM 供應商額度、Langfuse（若開啟觀測）。多租戶與每工作區儲存後端會讓備份與容量規劃變複雜，因為資料不再集中在一處。
專案本身沒有在 README 中承諾長期支援週期或 LTS 版本。採用前應該確認的是：你的團隊能不能跟上這種發布頻率，以及每次升級要重驗哪些設定。這比功能清單更決定它會不會長期留在生產環境。
編輯結論
需要把 Feishu、GitLab、Notion、語雀這類來源的文件收進同一個可查知識庫，並且願意自己維護 Docker Compose 與多租戶 RBAC 的團隊，可以從 v0.8.0 開始評估。只想做單一 PDF 問答、或不想碰容器執行環境的人不必進來，v0.8.0 已移除本機沙箱後端，代理的程式執行能力只剩 Docker、E2B、Cube 三條路。動手前先確認兩件事：儲存庫的 LICENSE 檔實際內容與 GitHub 上的 MIT 標籤是否一致，以及 `config/config.yaml` 中向量資料庫與 LLM 供應商的鍵值是否對得上你手上的服務。
社群筆記