我要投稿

Agentic Workflow——RAGFlow 0.20.0 特性预览

发布日期：2025-08-04 10:19:57 浏览次数： 1522

作者：InfiniFlow

微信搜一搜，关注“InfiniFlow”

从 Workflow 到 Agentic Workflow

经历了较长时间的等待，RAGFlow 0.20.0 版本终于发布，这是一个里程碑式的版本，因为它代表 RAGFlow 在 RAG/Agent 的拼图终于完整。

在一年前的此时，RAGFlow 推出了 Agent 特性，但在当时这只包含 Workflow ，并没有提供 Agentic Workflow 的编排能力，因此不是完整体的 Agent —— 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 所必备的，两者统一协同工作，才可以满足企业级场景的需要。

实现了完整 Agent 能力的 RAGFlow 成为更加适合企业使用的平台级 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 步。

0.19.1 Customer Service Template

在新版本下如果是通过纯 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 个，主要改动如下。

分类	0.19.1	0.20.0	核心改进
流程开始	开始 Begin	开始 Begin	支持无需对话触发的任务型 Agent 模式定义了文件变量后依旧能够被公开分享
AI	生成回答 Generate	智能体 Agent	自主规划与反思支持 Multi-Agent 架构，Agent 可以无限递归创建属于自己的 Subagent 团队支持调用内置 Tools 并包括了知识检索让 Agent 可以搜索企业内部知识库支持 Agent 可以作为 MCP Client 连接外部 MCP Server 引入 Context Engineering 支持 Vision 让 Agent 拥有多模态能力对齐行业标准提供 System Prompt 和 User Prompt
AI	知识检索Knowledge Retrieval	检索 Retrieval	原有功能基础上新支持跨语言搜索优化交互降低配置复杂度
对话	对话 Interact	等待回复 Await Response	开发者可以设定主动发起的消息支持发送表单采集信息
对话	静态消息 Message	回复消息 Message	从只支持静态文本改为能够引用变量的动态消息支持 Jinja2 模板能直接返回消息，不需要回到 Interact
流程	迭代 Iteration	迭代 Iteration	输入变量类型从原本的字符串改为数组迭代输入变量数组过程中的 Index 以及 Value 变量能够被访问迭代运行时产生的所有数组变量都可以在结束时返回供下游算子使用
数据操控	无	文本处理 Text Processing	负责操作文本，支持：自由拼接多个变量成为一个字符串将一个字符串变量切割成数组
其他	集线器 Concentrator	删除	支持将一个算子连接多个下游算子，其输出能够作为下游算子的输入
	问题优化 Rewrite	删除	能力被整合进 Knowledge Retrieval 可以通过 Agent 的提示词来实现同样的能力
	关键词 Get Keywords	删除	能力被整合进 Knowledge Retrieval 可以通过 Agent 的提示词来实现同样的能力

开始

Begin

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

检索

Retrieval

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

智能体

Agent

一个 Agent 能够独立替代你工作，因此它需要具有如下能力：

自主推理【文献 1】并根据环境给予的反馈进行反思和调整
使用工具完成任务【文献 3】

大家在新 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

通过字符串处理，开发者可以轻松地拼接字符串。

也可以将字符串切割成数组。

总结

Text Pocessing

结合上述案例，在 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，但前者的灵活度和简洁性大大优于后者。

Workflow 方式构建的 Deep Research：

Agentic 方式构建的 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 版本。

后续文章，将会围绕这些工作展开深入介绍。

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业