Onyx 開源企業知識搜尋：把公司文件收進可自架的 AI 問答庫

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

公司裡最難找的文件，往往不是沒有整理，而是散在太多地方：決議在 Slack 訊息裡、規格在 Notion 頁面裡、合約在 Google Drive 資料夾裡，每個工具都有自己的搜尋框，但沒有一個搜尋框找得到全部。Onyx 做的就是把這些來源接起來、建立索引，變成一個能直接用自然語言問問題的內部搜尋系統，答案會附上出自哪份文件。官網首頁舉的示例問題很典型：為什麼這個月的 AWS 帳單比上個月多了四萬美元，這種答案肯定存在於公司某個角落、但沒有人知道在哪裡的問題。整套軟體可以架在自己的伺服器上，資料不出公司，這是它與一般雲端企業搜尋服務最大的差別。

先講結論。這個專案值得放進團隊自架知識搜尋的候選清單：GitHub 上 32,545 顆星，前一天還有程式碼推送，正式版本發布到 v4.9.2，維護狀態在同類開源專案裡屬於前段班。但「開源免費」四個字要拆開讀：核心功能採 MIT 授權可以免費商用，企業功能放在另一份要照人數付費的授權條款裡；介面語言有中文但只有簡體；真正跑得起搜尋的標準部署，官方開出的最低記憶體需求是 10GB 等級。這些邊界下面會逐條攤開，讓你自己判斷要不要投入。

有件事得先交代：這套工具在 2023 年叫 Danswer，網路上留著大量舊名時期的介紹文章，那些文章裡的連結今天全部失效。先解決「去哪裡找它」，再談授權與資源。

Danswer 去了哪裡？舊入口今天的回應

把 2023 年舊文常用的三個入口逐一檢查，結果很一致：

• 舊程式碼倉庫 github.com/danswer-ai/danswer 回應 301 永久轉址，現在指向 onyx-dot-app/onyx，星數與版本記錄都還在
• 舊官網 www.danswer.ai 同樣回應 301，轉到 onyx.app
• 舊文件站 docs.danswer.dev 直接回應 404，連同所有舊教學連結一起失效

舊文不會把你帶到死路，但會把你帶到一個名字對不上的地方。改名留下的痕跡在專案裡隨處可見：根目錄授權檔的版權行寫的仍是 Copyright (c) 2023-present DanswerAI, Inc.，公司法定名稱沒有跟著品牌一起改；onyx.app 網頁的結構化資料裡，組織的 alternateName 欄位仍標著 Danswer，創立年份寫 2023，與 GitHub 倉庫 2023 年 4 月的建立時間對得起來；就連 2025 年 7 月 v1.0.0 的版本發布說明，貢獻者名單裡還出現了掛著 danswer 字樣的帳號 handle，出現十多次。品牌換了，地基沒換。

官方文件裡找不到一份寫明改名日期的公告，這裡不猜時間點。實際需要記住的新入口只有三個：官網 onyx.app、倉庫 onyx-dot-app/onyx、文件站 docs.onyx.app。搜尋引擎裡的 Danswer 舊文還會存活很長一段時間，跟著舊文走的人會迷路，先把新入口記下來，後面的討論才接得上。

32,545 顆星的活躍專案，README 的 MIT 徽章卻只說了一半

先看活躍度，這決定投入學習成本有沒有回報。2026 年 10 月 18 日查詢 GitHub API：32,545 顆星、4,569 次 fork，最近一次程式碼推送在 10 月 17 日。版本節奏相當密：公開發布記錄裡有 283 個正式版本，最早可以追溯到 2024 年 8 月的 v0.4.15，v1.0.0 在 2025 年 7 月出現，2026 年 10 月 14 日這一天同時對 v4.6、v4.7、v4.8、v4.9 四條版本線各發了一個修訂版，隔天 v4.9.2 接著出，10 月 16 日再連發兩個 Helm Chart 版本。多版本線並行維護，通常出現在有商業支援在背後的專案，因為付費客戶不會每次都跟最新版。目前開著 174 個 issue 與 427 個 pull request，以這個星數的專案來說不算堆積。

Pin

接下來是授權，這裡有個容易踩坑的地方。同一個專案，三個地方給出三種答案：README 頁面的徽章寫著 MIT；GitHub 的自動授權偵測顯示 NOASSERTION，也就是無法歸類；而授權檔原文寫的是一種雙層結構。根目錄 LICENSE 這樣劃分：

All content that resides under “ee” directories of this repository is licensed under the Onyx Enterprise License… Content outside of the above mentioned directories or restrictions above is available under the “MIT Expat” license.

翻成白話：倉庫裡 ee 目錄下的程式碼（backend/ee、web/src/app/ee、web/src/ee 三處）走 Onyx Enterprise License，其餘全部是 MIT Expat，也就是一般人說的 MIT 授權，Expat 只是自由軟體基金會對這份條款的正式稱呼。企業授權的原文條款寫得更明白：

This software… may only be used in production, if you… have agreed to… the Onyx Subscription Terms of Service… and otherwise have a valid Onyx Enterprise License for the correct number of user seats.

ee 目錄裡的功能要在正式環境使用，條件是訂閱合約，加上按實際使用人數購買的授權；開發與測試用途則明文免費。條款同時禁止把這部分程式碼重製、合併、散布或轉售。

那免費自架究竟拿得到什麼？README 的授權段自述：社群版（CE）採 MIT，涵蓋檢索增強生成（RAG）、AI 對話、Agent 與 Actions 的核心功能。對照著看就清楚了：搜尋與問答這條主幹是 MIT，可以免費商用；單一登入之類的企業治理功能在 ee 側，正式使用要付費。「Onyx 是開源的」這句話沒有錯，但精確的說法是核心開源、企業功能商業授權，規劃自架時要先確認自己要的功能落在哪一層。

連接器到底幾個？README、定價頁、原始碼三個數字對不上

連接器（connector）決定它能吃進哪些來源的文件，而這個數字官方自己就給了兩套：README 寫 50+ applications，定價頁寫 40+ App Connectors。把原始碼攤開來數：backend/onyx/configs/constants.py 裡名為 DocumentSource 的列舉清單，扣除 INGESTION_API、NOT_APPLICABLE、MOCK_CONNECTOR、USER_FILE、CRAFT_FILE 這五個項目後剩下 58 個，這五個是系統內部用途（例如使用者上傳檔案、供外部攝取的 API），並不對接任何外部服務，扣掉才不虛報。要引用數字時，以這份 58 的清單為準。

58 個連接器大致涵蓋幾類。通訊與協作有 Slack、Teams、Discord、Zoom、Zulip；電子郵件有 Gmail、Outlook 與通用的 IMAP；文件與知識庫有 Notion、Confluence、Google Drive、OneDrive、SharePoint、Dropbox、Box，以及 MediaWiki、BookStack、Outline 這類可以自架的 wiki，已經在自己伺服器上跑 wiki 的團隊可以直接接上；開發工具有 GitHub、GitLab、Bitbucket；專案管理有 Linear、Asana、ClickUp、Jira；客服與業務系統有 Zendesk、Freshdesk、HubSpot、Salesforce；儲存有 S3、R2、Google Cloud Storage 與 OCI。另外也有單純的網頁爬取與檔案上傳管道。

對台灣的團隊，清單裡少了一個名字：LINE。58 個連接器裡沒有 LINE，如果把 LINE 群組當作事實上的知識庫，這條路目前不通，只能靠檔案匯出後上傳，或讓網頁連接器去抓公開內容。這種缺口在選型時，比「支援多少個 App」的總數字更該先查。

部署前還得先想一件事：連接器不是填個網址就能通。官方文件把這塊獨立成「連接器與憑證」一整區，每個連接器各有取得憑證的流程要走；文件抓進來之後，還要對上公司內部誰能看到哪些內容的權限規則，Onyx 這裡走群組權限模型，文件站上還掛著近期把權限系統整個搬到群組制的遷移公告。這代表自架專案真正難的環節常常在組織協調：你得先說服管 Slack workspace 與管 Google Workspace 的人，把這些來源的讀取權交出來。

機器需求有兩張表：2GB 跑的是 Lite，完整搜尋要 10GB RAM 級

官方文件的資源需求頁開出兩張表，一張給 Onyx Lite、一張給 Onyx Standard，看的時候先別混在一起：

差異為什麼這麼大？看部署檔案就知道。標準版的 docker compose 定義了 14 個服務：API 伺服器、背景索引工作、網頁前端、MCP（模型上下文協定）伺服器、兩個模型伺服器、PostgreSQL、OpenSearch 搜尋與向量引擎、nginx、Redis、三個物件儲存相關服務，再加上程式碼直譯器。這是一套完整的搜尋基礎設施，不是單一容器的小工具。

官方文件還給出逐一容器的建議量：背景索引工作（background）要 2 顆 CPU 搭 8GB 記憶體，是整組最吃記憶體的角色；兩個模型伺服器各 2 顆 CPU 搭 4GB；OpenSearch 是 2 顆搭 4GB；PostgreSQL 2 顆搭 2GB，API 伺服器 1 顆搭 2GB；nginx 只需要四分之一顆 CPU 與 128MB。把這些建議加總，文件自己給的結論是整體節點至少約 12 顆 CPU、24GB 記憶體。這裡有一個能省錢的轉折：嵌入模型（embedding model）如果改用 OpenAI、Cohere 這類雲端服務而不在本機跑，兩個模型伺服器的記憶體需求會明顯下降，這是文件明寫的，不是猜的。

Lite 模式則是官方提供的極簡覆蓋檔，設計註解寫得很直白：

In this mode, connectors and RAG search are disabled, but the core chat experience (LLM conversations, tools, user file uploads, Projects, Agent knowledge, code interpreter) still works.

連接器與 RAG 搜尋在 Lite 模式下是停用的，留下來的是 AI 對話、工具、檔案上傳這些聊天體驗。部署檔案的對比同樣直接：標準版 14 個服務，Lite 只啟動 5 個（API、前端、PostgreSQL、nginx、程式碼直譯器），檔案儲存、快取與工作階段全交給 PostgreSQL 一手包辦。所以那張 2GB 的表並非「便宜版的 Onyx」，而是「沒有搜尋的 Onyx」：它適合用來熟悉介面與管理台，不適合用來評估搜尋品質，因為被評估的東西在這個模式根本沒開。基線記憶體用量官方標註在 1GB 以下，交換條件就是索引與連接器整組關閉。

標準版還有一個維運細節要記下：文件特別提醒 OpenSearch 在磁碟用量到達 95%（flood stage watermark 預設值）時，會把索引切成唯讀、擋掉所有寫入。索引資料隨文件量成長，磁碟建議量因此還要加上約 2.5 倍索引空間，磁碟監控要在上線前就排進維運清單，別等出事才回頭查。

安裝本身不複雜，README 給的是一行安裝指令，用 curl 把官方 install_onyx.sh 餵給 bash；從腳本註解看，它先裝好 onyx-cli，再由 CLI 執行引導式部署。規模往上走也有對應的路：官方文件提供 Helm Chart 給 Kubernetes 環境，AWS、GCP、Azure 三朵雲另有 Terraform 模組，部署形態從單機 docker compose 到叢集都排好了。已經在顧 Docker 環境的團隊，可以搭配 DPanel 這類 Docker 管理面板一起看資源用量。真正要預先想清楚的是機器等級：想認真評估搜尋，從 4 vCPU、10GB 記憶體這個水位起跳；手上只有 2GB 記憶體的小 VPS 或 NAS，能跑的只有 Lite 殼。

自架免費與雲端 $20 的邊界畫在哪裡

雲端版的定價結構簡單：Business 方案每人每月 20 美元、年繳計價，Enterprise 方案另洽。Business 段落列出的功能包含對話與搜尋介面、主流大型模型接取、自訂 Agent、走 MCP 與 OpenAPI 的 Actions、網頁搜尋、深度研究、程式碼直譯器、圖像生成、開發者 API，以及基本認證、Google OAuth、角色權限（RBAC）與密鑰加密。加價的 Enterprise 段落則把 OIDC 與 SAML 單一登入、地端部署、區域化部署、白標、自訂整合、資料匯出與發票支付收進去。這裡解釋一下名詞：OIDC 與 SAML 是企業把「登入這件事」交給公司既有身分系統管理的兩種標準協定，接了它，員工用平常開工作的那組帳號就能登 Onyx，離職停用也跟著身分系統同步。對許多組織來說，沒有單一登入就不能上線是硬規定，這代表免費自架版與他們之間隔著一道付費牆，牆的位置在企業治理功能；核心的搜尋與問答，兩邊都有。

Pin

官網首頁掛著每週 100 萬次以上查詢、超過 1000 個團隊使用，還有一組 6.7 秒完成回答、總成本 0.69 美元的對照示例；定價頁甚至有一個投資報酬試算器，預設場景是 500 人組織、80% 採用率、每人每個工作天省半小時，一年就試算出 288 萬美元的節省。這些是官方的行銷宣稱與自行建構的示例，數字出自它自己填的假設，不是第三方稽核結果，參考時保持這個認知即可。商業上這是一家有創投支持的公司：官方部落格在 2025 年 9 月公布了 1000 萬美元募資。回頭看雙層授權就不意外了，ee 目錄的企業授權正是這條商業路線的載體；開源核心與付費企業功能並存是設計出來的結構，核心長期獲得維護的動機也因此比較足。

定位上它可以跟兩類工具對照。TechMoon 介紹過的 TurboSeek與把調查流程搬進本機的 Local Deep Research，處理的是網路上的公開知識；Onyx 的方向相反，它只搜尋你家組織授權它讀的內部來源。另外像 ai-memory 這類共用專案記憶的工具，解決的是團隊協作時的上下文傳承，與全公司文件搜尋是不同層的需求，選型時常被放在一起，實際上互補多於替代。

介面有中文，但選單裡只有簡體

前端介面的語言設定定義在 web/src/i18n/config.ts，支援清單是英文、西班牙文、葡萄牙文、法文、德文、日文、中文、韓文、阿拉伯文共九種，其中中文（zh）對應的顯示名稱用的是簡體字，清單裡沒有繁體中文選項。清單裡甚至收了阿拉伯文這種由右至左書寫的語言，排版方向都處理了，就是沒有繁中；後端的語言列舉與這份清單保持同步，代表繁中缺席是產品層級的現況，改前端補一個下拉選項救不了，優先順序反映的是它主要客群的樣貌。

要區分兩件事：介面語言沒有繁體，不等於不能索引繁體中文文件。實際被搜尋的內容是各連接器抓進來的文件，繁中內容能不能被好好檢索，官方文件沒有提供測試數字，這點只能自己架起來用實際文件驗。會被簡體介面卡住的，是每天要盯著管理台與對話介面的管理者與使用者的體驗。繁中為主的公司要嘛接受現況，要嘛等社群補上（i18n 架構已就位，加語言是工程問題，不是架構問題），短中期內先把這項列入期待管理。

誰該現在架起來，誰先放著

值得現在就架起來試的團隊，條件大概是這樣：文件確實散落在多個 SaaS 服務裡、有 Docker 部署經驗、機器預算到得了 4 vCPU 與 10GB 記憶體，而且「資料不能離開自己伺服器」是來自法規或客戶合約的硬需求。這幾個條件都成立的話，MIT 核心加上 58 個連接器的組合，市面上同等成熟度的替代品多半是純商業方案。

先放著的訊號也很具體：組織規定沒有單一登入不能上線（那在付費牆內，先去談 Enterprise 價格再說）、主要知識來源是 LINE（沒有連接器）、機器只有 2GB 記憶體而想試的是搜尋（Lite 試不到）、繁體介面是剛性需求。任何一條成立，投入前都該再想一次。

下一步很單純：照著 docs.onyx.app 的部署文件走，遇到授權疑慮就回頭對照 ee 目錄的條款原文。評估期最省力的走法，是租一台 4 vCPU、10GB 記憶體等級的機器跑標準版，先接一個傷害最小的來源，用自家真正的繁中文件去驗檢索效果，這比照著舊文去裝 Danswer 少走非常多彎路。文中這些數字記錄的是 2026 年 10 月的專案現況，星星數、版本號與價格都會變；授權的雙層結構與這些決策邊界的思考方式，會比任何單一數字活得久。