RAGFlow 加入 Agent 與自架部署
RAGFlow 把開源 RAG、Agent、自架部署和新模型支援整合在一起，適合處理 PDF、表格和多來源文件的團隊。
RAGFlow 是一個開源 RAG 引擎，現在把 Agent 功能和自架部署一起做進來。
說真的，這東西蠻猛的。RAGFlow 的 GitHub 現在有 80.3k stars、9.1k forks、6,155 commits。這不是玩票專案，是很多人真的在用。
它的方向也很直白。把 retrieval-augmented generation 做好，再加上 Agent 能力。對常碰 PDF、表格、掃描檔、簡報的人來說，這比純聊天機器人實用很多。官方也提供 RAGFlow Cloud，想自己控資料的人則可以走 Docker 自架。
| 項目 | 數值 | 意義 |
|---|---|---|
| GitHub stars | 80.3k | 代表開發者採用度高 |
| GitHub forks | 9.1k | 表示有人在改、在接、在試 |
| Commits | 6,155 | 顯示專案還在持續動 |
| 最低 CPU | 4 cores | 自架門檻不算低 |
| 最低 RAM | 16 GB | 本機或伺服器要有點料 |
| 最低磁碟 | 50 GB | 文件索引和資料會吃空間 |
RAGFlow 想解的問題
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
很多 RAG 系統，一碰到真實文件就翻車。PDF 有表格、掃描檔有 OCR、簡報有圖片、Excel 有欄位，最後模型只會亂猜。RAGFlow 就是想處理這種髒資料場景。
它把自己定位成 converged context engine。白話講，就是不只切 chunk、做 embedding，還要盡量看懂文件結構，讓引用來源能追得到。這點對企業很重要，因為你總不能讓 AI 一本正經地胡說八道。
講白了，企業 AI 最常死在 context。模型本身不一定差，資料前處理一亂，答案就會看起來很像對的，其實全錯。
- 支援 PDF、Word、簡報、Excel、圖片、掃描檔、網頁
- 有模板化切分流程，引用路徑也比較好查
- 支援多路召回，再做 re-ranking
- 適合文件量大、格式雜的團隊
最近更新在忙什麼
RAGFlow 最近的更新很密。這通常是好事，代表團隊還在磨產品，不是發完版就裝死。從更新紀錄看，它已經開始跟新模型和新資料源對接。
像是 DeepSeek v4、GPT-5、Gemini 3 Pro 都在支援清單裡。它也加了 agent memory、MCP，還能從 Confluence、S3、Notion、Discord、Google Drive 同步資料。
這裡有個重點。它不是只做檢索，而是往 agent workflow 靠。也就是說，模型拿到 context 後，不只是回答，還可能接著做下一步動作。
「The most important thing about AI is that we need to understand that it is not magic.」— Sundar Pichai
這句話放在 RAGFlow 很貼切。它賣的不是魔法，是把資料管線做好。對企業來說，這通常比模型口號更有用。
下面這些更新，對評估導入很有參考價值：
- 2026-04-24：支援 DeepSeek v4
- 2026-03-24：推出 RAGFlow Skill on OpenClaw
- 2025-12-26：加入 agent memory
- 2025-11-19：支援 Gemini 3 Pro
- 2025-11-12：可同步 Confluence、S3、Notion、Discord、Google Drive
- 2025-10-23：加入 MinerU 和 Docling parsing
- 2025-10-15：支援可編排 ingestion pipeline
- 2025-08-08：支援 GPT-5 系列
自架部署到底麻不麻煩
先講結論，不是玩具等級。官方文件要求 4 CPU cores、16 GB RAM、50 GB disk，還要 Docker 24.0.0 和 Docker Compose v2.26.1。如果你要跑 sandboxed agent flow，還得加上 gVisor。
這代表什麼？代表它真的把自己放在能進 production 的位置，不是只給 demo 看。代價就是部署比較重，對小團隊來說，維運成本會比一般 RAG 套件高一截。
還有一個常被忽略的坑。官方 Docker image 是給 x86 用的。你如果用 Apple Silicon，或是 ARM 伺服器，很多時候得自己 build。這種事最容易在最後一刻才爆。
儲存層也很實際。RAGFlow 預設用 Elasticsearch 做全文和向量搜尋，也能切到 Infinity。這種設計很務實，因為不同團隊對成本和效能的取捨真的不一樣。
如果你在比對其他 RAG stack，可以先看這幾點：
- RAGFlow 比輕量方案更重，但文件理解更完整
- 它對引用與追溯比較友善
- 自架門檻比純 SaaS 高
- 適合文件量大、資料源多的團隊
跟其他方案比，差在哪
市面上很多 RAG 工具，都卡在「能跑」跟「能上線」之間。能跑，代表你塞一份 PDF 它會回你答案。能上線，代表你要處理權限、引用、資料同步、版本更新，還要讓工程師少掉坑。
RAGFlow 比較像後者。它把文件解析、召回、重排、引用、Agent、部署都包進來。優點是整合度高，缺點是學習成本也高。
如果跟 LlamaIndex 或 LangChain 這類框架相比，RAGFlow 更像完整產品。那些框架偏向組件層，你要自己拼很多東西。RAGFlow 則把常見需求先包好，適合想少踩坑的人。
- LlamaIndex：彈性高，但要自己組很多流程
- LangChain：生態廣，但工程整合工作多
- RAGFlow：偏完整方案，文件場景更集中
- Elasticsearch：搜尋強，但不是完整 RAG 應用層
如果你只想做一個簡單問答，RAGFlow 可能太重。可是一旦你要處理公司知識庫、法務文件、客服知識、內部 SOP，它的價值就會跑出來。
這個專案的產業脈絡
現在很多公司都在做 AI 搜尋、內部知識助理、文件問答。問題是，資料都很亂。文件散在 Google Drive、Notion、S3、Confluence，還有一堆掃描檔和舊版 Excel。這種環境下，單純靠 LLM 不夠。
RAG 的重點，本來就不是「讓模型更會講」。重點是讓模型拿到對的資料，再把來源講清楚。Agent 功能加進來後，系統還能往任務執行走，像是查資料、整理內容、接下一個工具。
我覺得這類工具會越來越像基礎建設。前端可以換，模型可以換，真正難的是 context layer。誰能把資料接好、切好、排好，誰就比較有機會做出能用的 AI 產品。
如果你是台灣團隊，這個趨勢也很現實。很多公司不想把文件丟到外部 API，或者資料合規有要求。這時候可自架、可追溯、可控權限的方案，就比單純雲端聊天介面更有吸引力。
結尾：值不值得試
我的建議很直接。只要你的資料不是乾乾淨淨的 Markdown，而是 PDF、表格、掃描檔混在一起，RAGFlow 就值得試。它不是最輕的方案，但很可能比你自己東拼西湊省事。
如果你已經有成熟的資料管線，先拿一個內部文件集做測試。看它的引用準不準、同步穩不穩、ARM 環境好不好跑。這三件事，比看 demo 更重要。
接下來我會盯兩件事。第一，它能不能把 Agent 功能做穩。第二，它會不會繼續把部署門檻壓低。這兩個答案，會決定它是工具，還是團隊真的會拿來當底層系統。