今天（8月19日），RAGFlow 正式发布 v0.27.0。一直关注这个开源项目的朋友应该知道，它最近热度不低：Star 数已经突破8.8万。小红书8月15日，它还登上了 GitHub 日榜。哔哩哔哩
没接触过的朋友先补一句：RAGFlow 是一个主打深度文档理解的开源 RAG 引擎，把 PDF、表格、扫描件喂进去，就能直接做带原文引用的问答，是眼下私有化知识库最热门的选择之一。它的卖点一直是"质量进、质量出"——解析这一步不可靠，后面模型答得再顺也是空中楼阁。
这次 0.27 称得上 RAGFlow 开源以来最猛的一个版本：官方 changelog 有 100KB，塞进去 1200 多个 PR、65 位新贡献者。对比一下，之前最大的版本 v0.25.0 也只有 75KB，而距离上个版本 v0.26.4 才过去 6 周。我把 changelog 全部读完、帮你滤掉了 bug 修复的噪音，下面这四个方向性信号，比功能清单更重要。
信号一：Go 重写走到"半山腰"
1200 多个 PR 里，很大一块都带 Go 前缀：任务执行器迁移到了 Go，Google 搜索、PubMed、arXiv、Wikipedia 这些 Agent 组件被移植成 Go，模型驱动分六批统一重写，连知识编译器和数据同步引擎都有了 Go 实现。GitHub官方甚至加了一个接口，用来识别当前跑的是 Go 还是 Python 运行时。这意味着 RAGFlow 在努力甩掉"重 Python 栈"，押注更快的解析性能和更轻的部署体验；但也意味着当前版本是 Python、Go 双运行时并行，正处在迁移中途，尤其生产环境，请把它当过渡状态而不是完全体。
信号二："知识编译"升格为一等公民
这是我这次最看好的部分。0.27 加了一整套知识编译能力：LLM 引导的语义重切块（让大模型帮你重新划分 chunk）、实体/主题级 Wiki 模式、Wiki 增量更新、知识图谱节点检索，还有一套 Agentic Search 框架。GitHub一句话：RAGFlow 不再满足于"把文档解析成块"，而是想先把你的文档"编译"成结构化知识，再让 Agent 在里面找答案。这正好对上官方一直在讲的"context engine"方向，如果你的知识库正卡在"切块粗糙、检索不准"的阶段，这条线值得盯。
信号三：模型供应商重构，对外接口 OpenAI 兼容
模型配置这套被重做了：供应商重构、支持批量校验模型实例、支持按模型覆盖 URL，对外 API 直接做到 OpenAI-API 兼容。新增支持里包括 Qwen3.8 系列、AWS Bedrock 重排、OpenRouter 嵌入模型、FunASR/SenseVoice 语音识别，有意思的是 Mistral OCR 现在也能直接当文档解析器用。对混用多家模型的团队来说，配模型这件事的成本明显降了。
信号四：连接层大爆发
IM 渠道一口气上了飞书、钉钉、企业微信、QQ、Discord、Telegram、WhatsApp、Line 八种。GitHub数据源这边加了 Notion、Gmail、Outlook、GitLab、Bitbucket、Google Cloud Storage、WebDAV、REST API 等支持断点续传的同步源。意图很明确：RAGFlow 想做那个能插进你所有 IM 和文档来源的"知识后端"。
还有个容易被忽略的变化：这次顺手打了一批安全补丁，包括 nginx 相关 CVE 修复和一个 IDOR 越权问题修复。GitHub如果你的 RAGFlow 部署在公网，光这一条就足够构成升级理由。
那么，该不该升级？
如果你是准备从零开始的新手，不用犹豫，直接装 0.27。新人没有历史包袱，新功能全是白赚。但注意硬件底线：4 核 CPU、16GB 内存、50GB 磁盘，而且官方镜像目前只提供 x86 版本，Mac M 系列用户得自己构建镜像。GitHub配置达标的话，Docker 一把就能拉起来，下图就是 compose 启动后容器全部跑起来的样子。
如果你是中小规模、内网或测试环境部署，可以升，但先备份 MySQL 元数据和文档源。这个版本移除了 pageindex 选项，聊天和检索表单里的"use kg"也被拿掉了。GitHub如果你的流程依赖这些配置，升级前先确认替代方案。
如果你是生产环境、数据量大，我的建议是再等几天。RAGFlow 自 0.25 以来迭代节奏明显加快，几乎每周都会发布一个小版本。知乎社区里也不缺"每次更新都带新 bug"的吐槽。小红书这次版本改动量巨大、Go 运行时又没完全打磨完，等社区先踩一两周的坑再动手更稳，升级时盯一下官方仓库新增的 issue。
顺手给第一次部署的朋友一份避坑清单
下面这几条是社区反复踩过的，0.27 也照样适用：
启动前把 vm.max_map_count 调到至少 262144，否则 ES 起不来，你还不明白为什么。
海外拉镜像非常慢，提前准备镜像加速或代理。
接 Ollama 本地模型时，留意默认 2k 上下文窗口，知识库"答非所问"多半是它，不是检索的锅。
文档以扫描件、复杂表格为主的话，社区现在主流玩法是让 RAGFlow 负责解析和知识库，再接给 Dify 做编排对话，两者是流水线分工，不是竞品。
这些坑都有人真金白银验证过：有人光拉镜像就花了整整两天。微博社区高赞避坑帖里，作者最后发现问题出在本地模型默认 2k 上下文。小红书再说得直白一点：RAGFlow 解决的是"文档解析质量"，Dify 解决的是"应用编排灵活度"，两者互补。知乎
RAGFlow 显然已经不满足于只做"解析文档很厉害的 RAG 引擎"，这次 0.27 就是它野心的一次集中展示：Go 底座、知识编译、全渠道接入。它能不能真的长成企业知识后端，要看接下来 Go 迁移的完成度和知识编译的实际效果，我会持续盯着。已经升级的朋友，评论区聊聊你的上手体验。
