RAGFlow：用 Go 为 AI Agent 构建可靠上下文层
RAGFlow 是 Apache-2.0 开源 RAG 引擎，把文档解析切分、检索与 Agent workflow 编排整合成 LLM 的上下文层，官网定位为企业级 AI Agen
企业知识库问答最容易翻车的地方，往往不是模型不够强，而是喂给模型的那几段文字根本不对。PDF 里的表格被切碎、扫描件没做 OCR、跨页的条款断成两半——检索回来的“上下文”本身就是垃圾，再强的 LLM 也只能一本正经地编。RAGFlow 要解决的正是这一层：它不训练模型，它负责在模型开口之前，把上下文弄对。
一个被低估的定位：上下文层，而不是聊天框
官网首页的描述是 “Build a superior context layer for AI agents”，README 里反复出现同一个词：context engine。这两个说法指向同一件事——RAGFlow 的产出不是“一个能问答的界面”，而是一层可以被 Agent 反复调用的上下文供给。
这个定位决定了它的能力取舍。README 的 Key Features 里，排在最前面的不是模型接入，而是 “Quality in, quality out”：基于深度文档理解，从格式复杂的非结构化数据里抽取知识，并且声称能在“literally unlimited tokens”的数据堆里找到那根针。第二项是模板化切分（template-based chunking），强调“智能且可解释”，并提供多种模板可选。
换句话说，它把工程重心压在了链条的前半段：解析、切分、可解释。这也是它和“套一层向量库 + prompt”的轻量方案最本质的分野。
架构：一条从原始文档到 Agent 的流水线
README 给出了一张系统架构图（structure.jpg），但没有展开文字说明。从 README 里真实出现的组件名和部署描述，可以把这条链路还原成下面几层。
接入与解析层。异质数据源兼容是明确列出的能力：Word、PowerPoint、Excel、TXT、图片、PDF、扫描件、结构化数据、网页。网页这一路在更新日志里有具体支撑——2026-09-10 增加了通过 sitemap 摄取网站内容，2026-07-02 增加了 Google BigQuery 数据源摄取与增量同步。解析的核心组件是 DeepDoc，README 在 Docker 部署说明里点明：在开源 1.0 版本中，DeepDoc 使用 CPU 推理完成版面分析（layout analysis）、OCR 和表格识别。这三件事恰好对应复杂文档最容易出错的地方。
切分层。模板化切分是这一层的抓手。README 强调“可视化文本切分以允许人工干预”——切得对不对，人能看见、能改。这是把“可解释”落到操作层面的设计，而不是一句口号。
知识编译层。2026-08-19 引入的 Knowledge Compilation 是较新的一块：在文档级和数据集级把内容编译成结构化知识产物，通过编译模板生成 Wikis、Graphs、Trees、PageIndex、Mind Maps、Timelines 和 Skills。同时可以配置编译模型与处理规则，并对产物做查看、更新、重新生成。这一层的意义在于，检索的对象不再只是原始 chunk，还可以是已经组织好的结构化知识。
检索层。Agentic Retrieval 是这里的核心：面对复杂问题，模型先分析问题，必要时拆解，再检索、再验证证据；通过多轮检索与推理凑齐上下文。深度由 Low / Medium / High / Ultra 四档 thinking mode 控制，按问题复杂度选。配合 README 提到的“多次召回 + 融合重排（multiple recall paired with fused re-ranking）”，检索不是单次向量查询，而是一条可调深度的多步流程。
编排与输出层。预置 Agent 模板 + RAG workflow 编排，可配置 LLM 与 embedding 模型，对外提供 API 供业务系统集成。带引用的答案（grounded citations）在这里落地：关键参考可快速查看，引用可追溯。
服务与部署层。Docker 部署说明里泄露了服务拆分的线索：默认 MySQL 配置下，镜像入口会在启动 Admin、Syncer、Ingestor、API 等服务之前执行数据库迁移。也就是说，这套系统是按职责拆成多个进程的，不是单体。
用一张表归纳：
| 层 | 核心组件 / 能力 | 职责 |
|---|---|---|
| 接入与解析 | DeepDoc、多格式数据源、sitemap、BigQuery | 版面分析、OCR、表格识别，把异质文档转成可处理内容 |
| 切分 | 模板化切分、切分可视化 | 按模板切块，人工可干预、可解释 |
| 知识编译 | Knowledge Compilation、编译模板 | 生成 Wiki / Graph / Tree / PageIndex / Mind Map / Timeline / Skill |
| 检索 | Agentic Retrieval、四档 thinking mode、多次召回 + 融合重排 | 多步检索、问题拆解、证据验证 |
| 编排与输出 | Agent 模板、workflow、可配置 LLM/embedding、API、引用追溯 | 组织检索与生成，输出可溯源答案 |
| 服务 | Admin、Syncer、Ingestor、API | 多进程服务化，启动前执行数据库迁移 |
从零跑起来：Docker 这条路最短
README 把本地部署分成两条：Docker 和源码启动。Docker 适合快速评估、集成测试和生产部署，不需要 Go 编译器；源码启动面向 RAGFlow 本身的开发调试，需要 go.mod 里指定的 Go 版本，前端开发另需 Node.js 和 npm。
推荐起步配置是 4 核 CPU、16 GB 内存、50 GB 可用磁盘，实际需求取决于文档引擎、数据量、解析任务和并发。Docker 版本要求 ≥ 24.0.0，Docker Compose ≥ v2.26.1。
如果选用 Elasticsearch 作为文档引擎，需要先把宿主机的 vm.max_map_count 调到至少 262144；用 Infinity 通常不需要这一步。检查与设置：
bashsysctl vm.max_map_count sudo sysctl -w vm.max_map_count=262144
然后克隆仓库、切到发布 tag、启动服务：
bashgit clone https://github.com/infiniflow/ragflow.git cd ragflow/docker git checkout v1.0.0-rc2 docker compose -f docker-compose.yml up -d
启动后用 docker ps 确认依赖服务变成 healthy 且 RAGFlow 容器在运行，再打健康检查接口：
bashcurl -f http://localhost/api/v1/system/healthz
拿到 HTTP 200 后浏览器访问服务器 IP 即可。默认 HTTP 端口是 80，所以地址里不用写端口号；如果改过 SVR_WEB_HTTP_PORT，健康检查 URL 的端口也要跟着换。启动失败就看日志：
bashdocker logs --tail 50 ragflow-cpu
登录之后还有一步不能省：在模型供应商页面添加 LLM、embedding 和 reranker，填模型名、服务地址和 API key。这一步没做，整条链路是空转的。
需要提醒的是，README 明确写了当前不支持 macOS。想在自己 Mac 上试的，走云端服务更省事。
它想让你怎么用：把文档变成可检索的资产
RAGFlow 的使用心智不是“上传文件然后聊天”，而是三步：解析切分 → 组织成知识 → 编排检索与生成。
第一步的质量由 DeepDoc 和切分模板决定。README 把“可视化文本切分”单列为特性，是因为这一步几乎决定了后面所有环节的上限——切错了，重排再花哨也救不回来。
第二步是 Knowledge Compilation 提供的新选项。同一份内容可以编译成不同形态：Wiki 适合通读型知识，Graph 适合关系型查询，Tree 适合层级目录，PageIndex 偏向定位，Mind Map 和 Timeline 面向结构化理解，Skills 则直接面向 Agent 复用。编译模型和处理规则可配置，产物可查看、更新、重新生成——这意味着知识组织本身是一个可迭代的工程对象，不是一次性转换。
第三步是 Agentic Retrieval 与 workflow。简单问题用 Low 档，复杂问题往上调，让模型自己拆解、多轮检索、验证证据。答案带引用，引用可追溯。
和同主题项目比，它站在哪一格
把素材里给的对照项目排开，差异其实很清楚——它们大多在“Agent 怎么行动”这一侧，RAGFlow 在“Agent 拿什么当依据”这一侧。
| 项目 | 语言 | 核心定位 | 与 RAGFlow 的差异 |
|---|---|---|---|
| RAGFlow | Go | 开源 RAG 引擎，融合 RAG 与 Agent，构建上下文层 | 重心在文档解析、切分、知识编译与可追溯检索 |
| deepseek-harness | TypeScript | 「一切皆插件」的 Agent 框架 | 提供工具调用与 prompt 编排的组装能力，不负责文档理解与切分 |
| graphify | Python | 把代码库、文档、SQL schema、配置、PDF 转成知识图谱 | 同样在建知识结构，但面向代码库全貌，用本地 AST 建图、无需向量库 |
| browser-use | Python | 让 LLM 直接操控浏览器完成网页任务 | 解决“去哪里取”，RAGFlow 解决“取回来怎么变成可靠上下文” |
| TradingAgents | Python | 多 Agent 金融交易框架，角色分工辩论决策 | 垂直领域的 Agent 协作范式，与通用上下文层不在同一层 |
| JavaGuide | JavaScript | 后端面试与知识指南 | 知识内容本身，不是引擎 |
最值得对照的是 graphify。两者都在做“把杂乱材料变成可查询结构”，但路径不同：graphify 用本地 AST 解析建图，每条边都有解释，明确不依赖向量库；RAGFlow 走的是解析 + 切分 + 检索的 RAG 主线，知识编译只是新增的一层产物形态。前者偏“代码与工程资产的全景图”，后者偏“企业文档的问答供给”。
另一个对照是 deepseek-harness。它把工具调用、prompt 编排拆成可插拔模块，让开发者按需组装 Agent；RAGFlow 提供的是预置 Agent 模板加 workflow 编排，更偏开箱可用。一个给零件，一个给流水线。
数字背后的信号
仓库元数据值得单列，因为它说明这个项目不是实验品：
| 指标 | 数值 |
|---|---|
| 星标 | 92,383 |
| forks | 11,019 |
| open issues | 1,357 |
| 许可 | Apache-2.0 |
| 语言 | Go |
| 创建时间 | 2023-12-12 |
| 最近推送 | 2026-10-17 |
Apache-2.0 意味着商用友好，这也是它敢在官网写 “built for enterprise” 的底气之一。topics 里除了 rag、retrieval-augmented-generation 这些常规标签，还有 context-engine、context-engineering、context-management、knowledge-compilation、agent-harness、search-harness——标签本身就是一份路线图：它在把自己从一个“RAG 工具”重新定义成“上下文工程的基础设施”。
更新日志的节奏也印证了这一点：2026-08-19 同一天放出 Knowledge Compilation 和 Agentic RAG 四档 thinking mode，2026-09-29 发布 1.0.0-rc1。功能在往“知识组织”和“检索深度可控”两个方向加码，而不是往“更多模型适配”上堆。
该不该用它，看你的痛点在哪
如果你的场景是：文档格式杂（扫描件、表格、PPT 混着来）、答案必须能指回原文、业务系统需要通过 API 集成、团队不想自己维护一套解析流水线——RAGFlow 的架构正好压在这些点上，DeepDoc 的版面分析与 OCR、切分可视化、引用追溯、API 集成，都是为这类需求准备的。
如果你的需求只是拿几个 Markdown 文件做个轻量问答，那这套多进程服务、文档引擎依赖、模型配置流程会显得重。它的复杂度是换“解析质量”的代价，用不上这部分价值时，代价就白付了。
还有一个现实约束：README 写明当前不支持 macOS，本地评估基本要走 Linux 或云端。这不是小细节，它会影响你团队第一次接触这个项目的路径。
源码在 github.com/infiniflow/ragflow，官网 ragflow.io，云端入口在 cloud.ragflow.io，文档在 ragflow.io/docs/dev/。想验证它是否适合你的语料，最直接的办法是拿一批最脏的 PDF 跑一遍切分可视化——那一步的结果，比任何 benchmark 都更能说明问题。