ChatWiki 自架 AI 知識庫平台：把公司文件變成問答機器人

Facebook Line Messenger Telegram

想把內部文件做成 AI 問答或客服機器人、又希望資料放在自己伺服器的人，搜尋自架方案時很快就會撞到 ChatWiki 這個名字。先講結論：它的功能面完整、維護節奏穩定（2026 年 7 月底到 9 月初連著發了五個版本），個人拿來評測或做專案可以直接用；但只要使用主體是公司行號，它的授權條款把「在公司內部環境部署」也劃進商業使用範圍，動手自架之前得先把授權、部署重量、資料流向這三件事看清楚，因為每一件都會直接改變你的決定。所有關鍵數字與條款內容，都可以在 GitHub 上的授權條款檔、原始碼與官方更新日誌裡自己核對一次；以下談的是能力與邊界，問答效果需要自己裝起來評測。

定位先看懂：知識庫是底盤，微信生態才是它的主戰場

ChatWiki 由中國武漢的開發團隊芝麻小客服（武漢芝麻小客服網路科技有限公司）開發，放在 GitHub 上公開原始碼，截至 2026 年 9 月中約有 2,076 顆星。維護節奏相當規律：從 v2.8.1（7 月 31 日）到 v2.9.3（9 月 4 日），五個版本排在五個星期裡，更新日誌每一版都列出具體變更，看得出有商業團隊在背後持續投入，而不是假日專案斷更的狀態。它的基礎是知識庫問答：把文件餵進去，建立可檢索的知識庫，再接上大型語言模型，讓使用者用問答的方式找到答案。不過 README 的產品定位現在寫的是「專注微信生態的工作流自動化平台」，repo 描述裡的官方說法是想做垂直領域的 Coze 與 n8n，也就是把中國微信公眾號的自動回覆、留言處理、推文改稿這類營運流程全部接進來。

在台灣做客服或內部問答，微信那一半的功能基本派不上用場（想看微信生態周邊工具的例子，可以參考我們介紹過的〈werss 微信公眾號 RSS 訂閱工具〉）。真正能用的是其餘三塊：文件知識庫、對話工作流編排、以及把機器人送到各種通路的輸出能力。把自己當成一個要選自架知識庫平台的人來看，這三塊才是評估的重點。

知識庫管線：文件進去、向量與知識圖譜一起檢索

照官方文件的說法，知識庫的輸入支援 URL 抓取、文件批次匯入與 API 對接，文件可以走 AI 自動分段、QA 分段或父子分段三種切法；檢索層同時用向量檢索與知識圖譜查詢，圖譜還提供視覺化查看。從技術棧看得出它是認真做事的架構：資料庫用 PostgreSQL 16 加上 pgvector 向量擴充與 zhparser 中文分詞，知識圖譜交給 Neo4j，等於一條文件進去、結構化與語意兩路並行的管線。

ChatWiki 知識圖譜視覺化介面，彩色節點連成網路並附文件列表與實體詳情面板 — ChatWiki 知識圖譜檢視畫面：節點與連線構成的圖譜可視覺化查看，右側顯示選中實體的詳情（官方 GitHub README，2026 年 9 月）

除了文件知識庫，它還有一條問答知識庫的路線：上傳文件後自動抽取問答對，遇到知識庫答不出來的問題會自動聚類，方便管理者回頭補內容，也能從人工對話紀錄裡總結出常用的 FAQ。知識庫可以設定有效期（永久、指定日期或指定天數），文件會過期的場景不用再手動清理。客服用途還有一個實用的細節：內建敏感詞過濾，上限兩萬個詞，是 2026 年 9 月初版本剛放寬的。

模型接線的廣度是它相對少見的地方。翻開原始碼裡的模型供應商定義檔，常數列了 25 個供應商：OpenAI、Claude、Gemini、DeepSeek、qwen、doubao、Kimi、ernie、Spark、Hunyuan、Baichuan、Zhipu、Minimax、SiliconFlow、OpenRouter、302AI、Cohere、Jina 等，另外保留一個自訂型讓你填任何相容 OpenAI 格式的端點。金鑰自己申請自己填，用量計在自己的帳號上，這跟自建 API 中繼閘道的邏輯相同（這類閘道工具可以參考〈New API 自架 LLM API 閘道〉）。文件解析的線上 OCR 功能，官方更新日誌寫明是走阿里雲 API 實現，這一點後面談資料流向時會再回來。

要誠實標出邊界：檢索命中率、回答品質、長文件表現這些效果面指標，官方文件與原始碼都背書不了，任何自架知識庫方案都一樣，最終要拿自己的文件庫實測。

機器人往哪送：網頁嵌入、LINE、Telegram 與微信系列

知識庫建好後，ChatWiki 的輸出端不只有聊天視窗。它支援把機器人用 SDK 嵌入網站、發布成網頁應用、裝進桌面客戶端，也能走 H5 連結對外。通路支援的時間點值得記下來：Telegram 是 2026 年 7 月 17 日的版本加入的，LINE 則是 2026 年 8 月 7 日的 v2.9.0 加入，原始碼的介面字串裡可以找到對應的設定項，填的是 LINE 平台的 Channel ID 與 Secret。LINE 支援大概是這波更新裡最實際的一條，在台灣做客服的場景直接就用得上。

微信系列（公眾號、服務號、微信客服、微信小店客服）是它深耕的主戰場，屬於中國大陸的營運場景。客服場景的完整鏈路它也想到了：機器人處理一般諮詢，答不好時轉給人工客服接手，支援多客服協同分配，機器人、工作流與 Agent 都能設限流，避免用量爆表。

工作流編排是另一條值得細看的能力線。照官方文件的說法，工作流分對話型與插件型兩類，內容涵蓋基礎流程節點、雙向 MCP、Agent 模式與使用者互動節點，全部用拖拽方式組合，不必寫程式。更新日誌裡看得到這條線的工程深度：工作流有多人同時編輀時的版本鎖機制、會話觸發器可以在聊天測試裡直接驗證流程、執行測試的結果會按節點逐一回報，哪個節點出問題一目了然。還有兩個整合點對開發者更有感：可以把外部 MCP 服務引進來當工具用，也能把整理好的工作流發布成 MCP 服務給別的應用呼叫；對外還有一組 OpenAPI，方便接進既有系統。

ChatWiki 工作流編輯畫布，含問題分類、API 查詢與回覆狀態節點，可發布機器人 — ChatWiki 工作流編輯器：拖拽節點組合問題分類、API 查詢與回覆流程，完成後直接發布成機器人（官方 GitHub README，2026 年 9 月）

授權條款先看：免費商用只屬於個人

這是整篇文章最該停下來細讀的一段。ChatWiki 在 GitHub 上顯示「未辨識授權」，原因不是沒有授權，而是它用了一份自訂條款：主體是 Apache 2.0，上面疊了附加條款。條款原文把使用分成兩軌。

個人軌很寬鬆：個人使用免費，而且明文包含個人進行的商業與非商業活動。接案者、獨立開發者自己用來做專案或展示，都落在這一軌。

組織軌就完全不同了。條款寫明：任何公司、機構、團隊作商業使用，須向開發方取得商業授權，而且列舉的情境包含「在公司或組織的內部環境部署、營運或使用」。換句話說，就算不對外收一毛錢、只是內部員工查文件用，照條款文字也屬於需要商業授權的範圍。再往下一條更硬：沒有書面授權，禁止用這套原始碼經營多租戶的 SaaS 平台。還有一條影響客製化需求：使用前端元件時不可移除或修改 ChatWiki 的 Logo 與版權宣告，條款並明確定義前端元件是指原始碼裡 front-end、html-template、static 三個目錄；只用後端服務或 API 做整合的話不受此限。

條款裡還有一條對想貢獻程式碼的人很重要：貢獻者同意自己提交的程式碼，開發方可以拿去做任何商業使用，包含它的雲端服務業務，而且開發方保留未來調整條款寬嚴的權利。想送 pull request 回上游之前，這一條值得先想清楚。

所以「開源、免費、可商用」這三個詞要拆開檢驗：原始碼公開，成立；Apache 2.0 主體，成立；免費商用，只對個人成立。網路上不少介紹文章直接把它寫成免費開源且可商用，隻字未提組織商用授權這一層，對組織用戶來說這樣的說法會踩線，導入前請以授權條款原文為準，商業授權的聯絡信箱在條款文末。

部署重量：15 個容器起跳

ChatWiki 不是那種單一執行檔就能跑起來的輕量自架。docker compose 檔裡定義了 15 個服務：PostgreSQL、Neo4j、Redis、NSQ 訊息佇列、Playwright 無頭瀏覽器、文件轉換器、Python 執行環境、長連線服務等等，一個指令拉起來的是一整個小型叢集。這對維運的意義有兩層：機器的記憶體與磁碟規格要先抓穩，出問題時要能分別看各服務的日誌。

另一個實際細節：這 15 個容器的映像檔全部拉自阿里雲杭州鏡像倉庫。從台灣或其他地區拉中國 registry 的速度要有心理準備，官方文件有提供鏡像站與離線安裝的替代路徑；不想直接碰 Docker 指令的人，官方也整理了安裝助手、寶塔面板與 1Panel 的部署教學，甚至有免 Docker 的安裝方式。另外兩個自架前該知道的點：管理介面目前只有簡體中文與英文兩種語言，沒有繁體中文；一鍵部署的預設管理帳號是 admin，預設密碼直接寫在原始碼常數裡，裝完的第一個動作就是改掉它。ARM 架構的部署支援目前還是開放中的功能需求，想用 ARM 小主機自架的人先確認映像檔相容性。

資料流向：自架不等於 AI 處理在地

「私有化部署」這四個字容易被讀成「一切都在自己機器上」，實際要拆成兩層看。儲存層確實在自己家：文件、知識庫、對話紀錄落在你自己的 PostgreSQL 裡。處理層則看你怎麼設定模型：預設的用法是填入雲端模型的 API 金鑰，文件內容與使用者的問題會送給你選的那家模型供應商處理；線上 OCR 文件解析也是送阿里雲 API。資料落地與 AI 處理是兩件事，自架只保證前者。

想把處理層也留在本地，路是存在的：供應商清單裡有 Ollama 與 Xinference 兩條本地模型路徑，把對話模型與嵌入模型都指到本地跑，文件不出機房的全程在地處理才成立（本地 AI 工具的完整介紹可參考〈AgenticSeek 本地 AI 搜尋代理〉）。這條路對文件量大或內容敏感的組織尤其重要，只是每一環都要自己設定與驗證，本地模型的問答品質也要自己承擔。

個人可以直接上，公司行號要先停一下

個人開發者與接案者：適合。個人軌授權免費、功能完整、LINE 與 Telegram 都通，拿來做文件問答機器人或網站客服都很順手，前提是有 Docker 維運經驗、能接受簡中或英文介面。

公司行號：先停一下。內部部署就屬於條款定義的商業使用，先和開發方談妥商業授權再動工，採購或法務看條款原文比看任何介紹文章都快。想做 SaaS 轉售的更不用說，條款明文禁止。

只想輕量試水溫的人：官方在 chatwiki.com 提供免費試玩，程式碼裡也能看到另有雲版服務，先在雲版驗證知識庫品質再決定要不要自架，是省力的順序。兩者的功能分級在更新日誌裡看得很清楚：雲版專屬的功能會標上【STD】記號，例如模型分時段計費、簡訊發送插件、釘釘與企業微信、飛書的帳號登入，這些都是社群版拿不到的；反過來說，社群版的核心（知識庫、工作流、機器人通路）並沒有被閹割，自架的價值主要差在維運責任與這些雲端加值功能。

實際動手的起點很單純：克隆倉庫、進 docker 目錄、一個 docker compose up -d 拉起全部服務，瀏覽器開埠 18080 就進管理介面，改掉預設密碼後開始建第一個知識庫。