理想情况下，完全交给 LLM 的 Agentic Workflow 是绝大多数 Agent 应用期望达成的目标，但由于 LLM 能力限制，会引入执行的不确定和不可控性，这在企业场景尤其难以接受；
而 Workflow 则走向另一个极端：
采用低代码平台完全定义每个编排环节，包括变量、条件判断、循环等等，实质上是不写代码的业务人员按照他们对业务逻辑的理解进行编程，在保证确定性的同时却容易陷入蛛网密布的复杂编排，从而导致误用、滥用以及可维护性差，更重要的是导致一些任务的拆解和控制难以实现。
因此，长期来看 Agentic Workflow 和 Workflow 都是构建 Agent 所必备的，两者统一协同工作，才可以满足企业级场景的需要。
实现了完整 Agent 能力的 RAGFlow 成为更加适合企业使用的平台级 LLM 引擎，如下图所示，RAG 在整个企业场景的生态位，跟过去的数据库等同，而 Agent 则对应具体应用。
但它们之间和过去又有很大不同：
其一，RAG 更关注非结构化数据的利用；
其二，RAG 和 Agent 的交互频繁程度远高于普通应用和数据库，因为 Agent 需要实时且精确的上下文，以使得它的行动和用户意图保持一致，而 RAG 则是填充上下文的重要工具。
因此完成 Agent 拼图是平台进化的必然选择。
本次更新的核心特性包括：
支持统一编排 Agent 和 Workflow；
重建 Agent 能力和易用性，支持 Multi-Agent，支持规划与反思、视觉等特性；
支持完整的 MCP 功能，包括导入 MCP Server、Agent 作为 Client 调用 MCP 以及 RAGFlow 作为 MCP Server；
可以查看 Agent 的运行时日志；
Agent 引入管理面板查看用户聊天记录；
0.19.1 Customer Service Template
开发者可以查看 Agent 的规划运行轨迹以及检查它们的输入输出。
业务用户通过 Embed 页面和 Agent 聊天也会展示 Agent 的思考过程。
0.20.0 版本，RAGFlow 实现了Workflow和Agentic Workflow的统一编排。
正如前文所说，它们分别代表了一个极端，而在长期来看，企业场景需要它们协同配合，因此，它们不仅仅需要统一编排，更应在一个画布下实现编排，并且该画布天生就是Multi-Agent—— 当某个 Agent 的输入是不确定的，用户可以将它定义成Agentic Workflow风格，反之则定义成 Workflow 风格。
为符合主流使用习惯，画布上把Agentic Workflow定义成单独的 Agent 算子。
新版本内都是围绕此目标设计编排界面和每个算子的具体功能，并且针对老版本 Workflow 不易用的缺点进行了改进，将核心 Component 数量从原本的12 个减少至 10 个，主要改动如下。
开始
Begin
检索
Retrieval
智能体
Agent
等待回复
Await Response
条件
Switch
迭代
Iteration
回复消息
Reply Message
文本处理
Text Processing
总结
Text Pocessing
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 版本。
后续文章，将会围绕这些工作展开深入介绍。