RAGFlow 0.20.0 Agentic Workflow 特性预览

RAGFlow 0.20.0 版本的正式发布，可以说是一个具有里程碑意义的节点。它标志着 RAGFlow 在 RAG 与 Agent 这两大核心模块上，最终完成了深度融合，走向了功能完备的完整形态。

回顾一年前，RAGFlow 初次引入 Agent 特性时，其实仅提供了 Workflow 的能力。当时的 Agent 还不够完整，因为它缺少 Agentic Workflow 的自动编排能力。在 RAGFlow 的设计理念中，真正的 Agent 必须同时包含这两者：Workflow 依靠人工来规划和定义任务，而 Agentic Workflow 则依赖大语言模型（LLM）来自动规划与执行。

Anthropic 在 2024 年底那篇广受关注的“Building effective agents”博文中，也清晰阐述了两者之间的关系。文章强调，Workflow 依然是当前 Agent 应用的主要实现方式。但进入 2025 年后，随着 LLM 能力的显著提升，Agentic Workflow 开始解锁越来越多令人眼前一亮的应用场景。

理想情况下，完全交由 LLM 自主决策的 Agentic Workflow，是大多数 Agent 应用希望达成的终极目标。然而现实是，受限于 LLM 自身的能力边界，这种模式会引入执行上的不确定性和不可控性，这在企业级场景中往往难以被接受。

而 Workflow 则走向了另一个极端。它采用低代码平台，把每一个编排环节都定义得清晰明确，包括变量、条件判断、循环等。从本质上说，这是让不写代码的业务人员，按照自己的业务逻辑去“编程”。这种方式虽然保证了确定性，但也容易陷入像蜘蛛网一样复杂的编排中，造成误用、滥用以及后期维护困难。更关键的是，一些复杂任务的拆解和控制反而变得难以实现。

因此，从长远来看，Agentic Workflow 和 Workflow 都是构建 Agent 不可或缺的能力。只有两者协同工作，才能真正满足企业级场景的多样化需求。

当 RAGFlow 拥有了完整的 Agent 能力后，它就更像是一个真正适合企业使用的平台级 LLM 引擎了。在企业场景的生态位上，RAG 的地位类似于过去的数据库，而 Agent 则对应具体的应用。但二者的交互方式，与过去有本质的不同。

其一，RAG 更关注非结构化数据的利用。其二，RAG 和 Agent 之间的交互频率，远高于普通应用与数据库。因为 Agent 需要实时且精确的上下文，才能确保它的行动与用户意图保持一致，而 RAG 正是填充上下文的关键工具。所以，补全 Agent 这块拼图，是平台进化的必然选择。

下面，我们来具体看看 RAGFlow 0.20.0 版本带来了哪些新特性。

RAGFlow 0.20.0 特性更新列表

本次更新的核心特性包括：

• 支持统一编排 Agent 和 Workflow
• 重建了 Agent 的能力与易用性，支持 Multi-Agent，以及规划与反思、视觉等新特性
• 支持完整的 MCP 功能，包括导入 MCP Server、Agent 作为 Client 调用 MCP、RAGFlow 作为 MCP Server
• 可以查看 Agent 的运行时日志
• Agent 引入了管理面板，用于查看用户的聊天记录

这次更新后，开发者构建 Agent 的体验会有多大变化？以 v0.19.1 版本的客服模板为例。在旧版本中，构建这样一个 Workflow 需要用到 7 类算子：Begin、Interact、Refine Question、Categorize、Knowledge Retrieval、Generate、Message。针对第 4 类问题，最长的一条构建链路需要 7 步。

而在新版本中，如果采用纯 Workflow 模式，只需 5 类算子：Begin、Categorize、Knowledge Retrieval、Agent、Message。同样是第 4 类问题，构建链路被压缩到了 5 步。

如果采用 Agentic 模式，那就更简单了，只需要 3 类算子。原本 Workflow 里的那些复杂逻辑，都可以通过提示词工程来指导 Agent 完成。

开发者现在可以查看 Agent 的规划运行轨迹，以及检查它们的输入输出。业务用户通过 Embed 页面与 Agent 聊天时，也能直观地看到 Agent 的思考过程。

通过这个对比，我们可以很直观地感受到构建复杂度的降低和效率的提升。更多细节会在下文中展开，也欢迎大家亲自上手体验。

统一的 Agent 编排引擎

在 0.20.0 版本中，RAGFlow 实现了 Workflow 和 Agentic Workflow 的统一编排。正如前文所说，它们分别代表了两个极端。在企业场景中，长期需要它们协同配合。因此，它们不仅需要统一编排，更需要在同一个画布下完成，并且这个画布天生就是 Multi-Agent 的。当某个 Agent 的输入是不确定的，用户可以把它定义为 Agentic Workflow 风格；反之，则定义为 Workflow 风格。

为了符合主流使用习惯，画布上将 Agentic Workflow 定义成了一个单独的 Agent 算子。新版本的所有设计，无论是编排界面还是每个算子的具体功能，都围绕这个目标展开。同时，针对老版本 Workflow 不易用的缺点，核心 Component 的数量从原本的 12 个减少到了 10 个。主要的改动如下：

开始 (Begin)

在原有的 Conversational 对话模式基础上，新增了无需对话触发的任务型 Task 模式。开发者可以在同一个画布下构建这两类 Agent。

检索 (Retrieval)

Retrieval 既可以作为算子存在于工作流中，也支持作为 Agent 的 Tool，让 Agent 自主决定调用的时机和检索语句。

智能体 (Agent)

一个 Agent 应该能独立替你工作。因此它需要具备自主推理、根据环境反馈进行反思与调整，以及使用工具完成任务的能力。在新版的 Agent 算子下，大家只需要配置 Prompt 和 Tools，就能立刻搭建出一个 Agent——RAGFlow 在底层已经为你完成了技术实现。除了单 Agent 模式，新 Agent 算子还支持添加自己的 Subagent，在运行时调用。你可以任意添加 Agent，构建属于自己的无限 Agent 团队。同时，也支持添加和批量导入你已经部署好的 MCP Server，Agent 可以在运行时使用这些 MCP Server 下的工具。

等待回复 (Await Response)

重构了原有的 Interact 算子为等待对话算子。这让开发者可以在流程运行中主动暂停，并发起预设的对话或通过表单采集关键信息。

条件 (Switch)

Switch 优化了交互体验。

迭代 (Iteration)

迭代算子的入参类型调整为数组。迭代运行时的 Index 和 Value 都可以被内部算子访问，内部算子的输出也支持组成数组传递给下游。

回复消息 (Reply Message)

通过 Reply Message 可以直接回复消息，不再需要 Interact 算子。

文本处理 (Text Processing)

通过字符串处理，开发者可以轻松地拼接字符串，或者将字符串切割成数组。

如何协同：总结与最佳实践

结合上述案例，在 RAGFlow 的设计中，通过在一个画布下同时提供 Agentic 和 Workflow，并设计了专门的无代码平台，使得两者可以统一编排。当 Agent 的输入是确定的，开发者选择 Workflow；当输入是不明确的，开发者选择 Agentic。一张画布上，可以同时存在多个 Agentic 和 Workflow。开发者只需要进行少量的工具配置和拖拽操作，剩下的工作就是调整各类提示词。无论是什么样的 Agent 组合，在一张画布上都不应出现密集蜘蛛网状的编排。Agentic 和 Workflow 有机配合，才是智能体落地的最佳实践方式。

应用生态及后续演进

有了完整且统一的无代码 Agent 构建框架，自然就离不开大量贴近场景的 Agent 应用。这也是 RAGFlow 长期建设的重点。换句话说，未来将会有海量的 Agent 模板构建在 RAGFlow 平台之上。为此，我们将开启配套的生态共建计划。

RAGFlow v0.20.0 首先内置了 Deep Research。这是一个特殊的 Agent 模板，因为它既可以单独成为一个应用，也可以作为构建其他场景智能体的基础。在下一篇文章中，我们会详细描述 Deep Research 模板的构建方式。这里先看一个简单的样例：在 RAGFlow 平台上，可以同时以 Agentic 和 Workflow 两种方式构建 Deep Research，但前者的灵活度和简洁性明显优于后者。

RAGFlow 的生态计划，目标是以嵌入 Know-how 的企业场景为基础，提供一系列 Agent 模板。这些模板，开发者稍加改动，就能应用到自身业务中。在这些模板中，Deep Research 之所以最重要，是因为它实质上就是 Agentic RAG 最常用的表现形式，也是 Agent 挖掘企业深层次数据价值的必经之路。以 RAGFlow 内置的 Deep Research 模板为基座，开发者稍加修改，就能打造出属于自己的内部法律助手、医疗助手等等。

以这种形式构建的生态体系，最大程度地拉近了业务系统与底层基础设施之间的距离。正是由于 RAG 和 Agent 之间这种紧密的协作关系，才使得这种构建应用生态的方式成为可能。

0.20.0 版本开启了 RAGFlow 整合 RAG 与 Agent 的实质性步骤。接下来的迭代将会加速，记忆管理、人工调整 Agent Plan 等特性都会快速推出。如果说统一 Workflow 和 Agentic Workflow 大大降低了企业级 Agent 的构建门槛，生态计划拓展了 Agent 的应用边界，那么以 RAG 为核心，共同围绕结构化数据和非结构化数据打造 Agent 的数据基座，则是保障 Agent 能力的基石。它在当下被称作一个新潮的名词——上下文工程。与之相伴，朴素单一的 RAG 则可以被称为上下文工程的 1.0 版本。后续的文章，将会围绕这些工作展开深入介绍。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：RAGFlow 0.20.0 Agentic Workflow 特性预览要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题