RAGFlow 是 InfiniFlow 開源的檢索增強生成引擎，GitHub 星標達 92,547，fork 數 11,049，於 2026 年 9 月 29 日發布 v1.0.0-rc1，並在 10 月 16 日推出 v1.0.0-rc2。這次發布的份量不在功能清單的長度，而在於該專案選擇把整套核心以 Go 重寫，同時更換訊息佇列與快取層的技術選型。對於已經把 RAGFlow 放進生產環境的團隊，這是一次架構層級的遷移，而非例行版本更新。
RAGFlow 是 InfiniFlow 開源的檢索增強生成引擎，星標 92,547，v1.0.0 系列以 Go 重寫核心並更換訊息佇列與快取，主打更輕量的部署架構。
專案由 InfiniFlow 團隊維護，主儲存庫於 2023 年 12 月 12 日建立，採 Apache-2.0 授權，官方網站為 ragflow.io。專案描述在 1.0 版本中同步調整，把自己定位為「融合 RAG 與 Agent 能力的上下文層」，並以代理式檢索、知識編譯與預建代理模板作為主要賣點。這種表述上的位移，與程式碼層的重寫方向一致：從一套文件問答系統，走向可供企業長期維運的資料基礎設施。
RAGFlow v1.0.0-rc2 是什麼？
v1.0.0-rc2 是 RAGFlow 1.0 系列的第二個候選版本，於 2026 年 10 月 16 日發布，修正 rc1 的多項問題並補上代理模式、共享權限與新資料來源整合。
rc2 的定位是收尾。官方說明指出，此版本修復 rc1 的多項缺陷，並保留與 rc1 資料的直接升級相容性。最受注目的變動是把對話中的 Low、Medium、High、Ultra 四段思考等級，統一收斂為單一的代理模式（Agentic mode）。這項調整的意義在於簡化使用者決策：過去使用者需要自行判斷問題複雜度以選擇思考深度，如今由模型在檢索過程中自行拆解問題與驗證證據。
第二項變動是 Team/Me 共享。rc1 的已知問題清單曾明列此權限模型尚未支援，rc2 補上之後，知識庫與代理的協作場景才真正可用。整合層面亦有擴張，新增 DemonRoute 與 Opper 兩家模型供應商、Firecrawl 與 Search1API 兩種網頁搜尋工具，以及 MinerU 4 解析模型；檢索語言支援擴及捷克語與斯洛伐克語，Docker 映像則增補 arm64 架構。
為什麼 RAGFlow 要用 Go 全面重寫？
官方以「大幅降低系統資源消耗」為主因，把原本重量級的部署模型換成輕量架構，並藉單一語言簡化服務編排與啟動流程。
rc1 的發布說明把這次改寫定義為「以 Go 全面重寫」，首要目標是顯著降低系統資源佔用，並以輕量架構取代先前的重量級部署模型。對照 README 記載的起始需求，四核心 CPU、16GB 記憶體與 50GB 磁碟的門檻並未改變，但實際佔用與啟動時間的改善，正是自架團隊過去最常抱怨的環節。
技術選型的替換同樣指向維運成本的下降。訊息佇列由 Redis 遷移到 NATS，快取與檢查點則改由 Kvrocks 同時承擔。原本 RAGFlow 的服務編排涉及 Python 後端、前端與多個相依服務，如今官方描述啟動時由映像入口點先執行資料庫遷移，再啟動 Admin、Syncer、Ingestor 與 API 等服務，整個流程收斂在同一套生命週期之內。命令列工具亦以 Go 重寫，取代先前的 Python 版本。
Go 重寫帶來哪些部署上的變化？
部署仍以 Docker Compose 為主，但 1.0 版的 DeepDoc 僅支援 CPU 推論，本機沙盒不再支援，且需以健康檢查端點確認服務就緒。
啟動流程本身變化不大。使用者複製儲存庫、切換到 v1.0.0-rc2 標籤，於 docker 目錄執行 docker compose 啟動，預設可透過 80 埠直接開啟網頁介面。真正的差別在就緒判斷方式：官方明確指出 RAGFlow 容器本身並未定義 Compose 健康檢查，需改用 HTTP 端點確認狀態，回傳 200 之後才代表系統可服務。這個細節對自動化部署腳本尤其重要，若沿用舊版的容器狀態判斷，容易在資料庫遷移尚未完成時就對外提供服務。
元件支援範圍則出現實質限縮。rc1 的已知問題列出三項：DeepDoc 目前僅支援 CPU 環境、本機沙盒不再支援、Team/Me 權限模型尚未實作。其中沙盒移除的影響最直接，過去依賴容器內執行程式碼的代理流程需要另尋方案。使用 Elasticsearch 作為檢索引擎的部署，仍需在主機設定核心參數至 262144，並寫入系統設定檔方能永久生效。
v1.0.0-rc2 修正與新增了哪些功能？
rc2 統一代理解析流程、補上 Team/Me 共享與 arm64 映像，並讓十二種內建文件解析器與管線解析器對齊，同時新增多國語言檢索。
解析層的整合是 rc2 較少被提及卻影響深遠的改動。官方把十二種內建文件解析器與管線解析器統一，並將原生 PDF 與 Office 文件抽取移入 DeepDoc 的統一入口，同時把解析設定改為元件層級作用域。對使用者的直接好處是行為一致：過去同一份文件走不同解析路徑可能得到不同切塊結果，如今兩條路徑共用同一套實作。表格處理亦改以分段 HTML 中介格式傳遞，避免跨列合併時結構失真。
檢索與生成層則有數項增量。影像解析新增可選的視覺語言模型增強，讓圖表內容能轉為可檢索文字；知識編譯模板經過重整，Wiki、圖譜、樹狀結構、頁面索引、心智圖、時間軸與技能等產出型態得以在文件與資料集兩個層級重複使用。這些能力最早於 2026 年 8 月 19 日引入，1.0 系列則把它們從附加功能變成架構的一部分。
升級到 1.0 有哪些風險與前置條件？
官方要求先完整備份、確認現行版本為 v0.27.2，且升級不可逆；失敗時須自備份還原並回報議題，不可直接降版。
這是本次發布最需要謹慎對待的部分。官方在 rc1 說明中明確指出，容器啟動時會自動執行從 v0.27.2 到 1.0 的資料升級，且該程序不可逆，完成之後無法回退到舊版。前置條件包括三項：升級前備份全部資料、確認現行部署已在 v0.27.2、以及接受升級失敗時需自備份還原並提交議題的處理方式。
相容性方面，Go 版本不再支援已標示棄用的 API 別名，若有系統直接呼叫這些端點，需先改寫；Python SDK 則不受影響，這對多數整合場景是好消息。命令列工具雖以 Go 重寫，但仍是獨立執行檔，透過安裝腳本取得，與伺服器版本的對應關係需留意。對於仍停留在 0.2x 早期版本的團隊，升級路徑必須先逐段推進到 v0.27.2，跳版並不支援。
RAGFlow 與同類 RAG 引擎相比如何？
RAGFlow 的差異在於深度文件理解與代理式檢索的結合，並以知識編譯產出結構化資產，而非僅提供向量檢索與提示組合。
多數開源 RAG 方案的核心是向量資料庫加上檢索流程，文件解析多半委外給通用工具。RAGFlow 的立足點則是把解析視為品質的第一道關卡，以 DeepDoc 處理雙欄排版、跨頁表格與掃描件，再用模板化切塊保留段落結構，並以視覺化標註讓人為介入。這條路線的代價是資源需求較高，也解釋了 1.0 為何要以 Go 重寫來壓低執行成本。
代理式檢索則是另一個分水嶺。系統會先分析問題，必要時拆解為子問題，再分輪檢索與驗證證據，最後才生成答案，並附上可追溯的引用。與單純的單輪檢索相比，這種做法在複雜問題上更不容易產生幻覺，但延遲與 token 消耗也相應提高。rc2 把思考等級收斂為單一代理模式，等同承認多層級設定對使用者的認知負擔大於實際價值。
RAGFlow 的授權與取得方式是什麼？
專案採 Apache-2.0 授權，可自 Docker Hub 取得映像或自原始碼建置，另提供 ragflow.io 雲端服務作為免部署選項。
Apache-2.0 允許商業使用、修改與再散布，僅需保留授權聲明與變更說明，對想在企業內部平台整合的團隊相對友善。取得方式有三：自 Docker Hub 拉取官方映像並以 Compose 啟動、自原始碼建置（需符合 go.mod 指定的 Go 版本，前端開發另需 Node.js 與 npm）、或直接使用官方雲端服務。三者的功能邊界與資料存放位置不同，涉及敏感資料的場景仍建議自架。
官方同時提供繁體中文、日文、韓文、法文、印尼文、葡萄牙文、阿拉伯文、土耳其文與俄文等多語言說明文件，對跨區團隊的導入門檻有實質幫助。專案亦維護完整的版本發布紀錄，1.0 系列的候選版本節奏約為兩至三週一次，正式版時間尚未公布。
出處連結有哪些？
主要出處為 GitHub 的 infiniflow/ragflow 儲存庫，版本細節見 rc1、rc2 發布說明，文件位於 ragflow.io。
程式碼與議題追蹤集中於 https://github.com/infiniflow/ragflow，版本變更以該儲存庫的 Releases 頁面為準，其中 v1.0.0-rc1 的說明詳述 Go 重寫範圍、架構替換與升級注意事項，v1.0.0-rc2 的說明則列出修正項目與新增整合。部署與 API 文件位於 https://ragflow.io/docs/dev/，代理式上下文引擎的設計理念另有專文說明。
總結：RAGFlow 1.0 適合什麼團隊？
適合已熟悉 Docker 維運、需要處理複雜格式文件並要求答案可溯源的團隊；若重度依賴沙盒執行程式碼或 GPU 加速解析，宜暫緩升級。
判斷這次改寫的成敗，關鍵不在功能多寡，而在資源消耗是否真的下降，以及 Go 版本能否承接原本 Python 生態的既有整合。對已在生產環境運行的團隊，合理的做法是先以備份環境演練一次從 v0.27.2 到 1.0 的遷移，確認解析結果與檢索品質沒有退化，再決定正式切換。若系統重度依賴本機沙盒或 GPU 加速的文件解析，等待後續版本補齊相關支援會更穩妥。
對尚未導入的團隊而言，1.0 的吸引力在於部署形態收斂與解析品質的持續投入。輕量架構降低了試用成本，而知識編譯與代理式檢索則指向比單純問答更長期的價值：把散落的內部文件轉化為可重複使用的結構化資產。
