Dify 重构 Agent 架构旧版节点模式升级为独立智能体

Dify 选择彻底推倒重做 Agent 架构，核心目标是把绑定在工作流里的 Agent 节点，升级成可独立管理、跨流程复用的标准化智能体，让 Agent 从一次性节点变成可长期迭代、多业务共享的能力资产，同时提升运行稳定性、可观测性与横向扩容能力，更好支撑企业大规模业务落地；旧架构把 Agent 做成工作流内的普通节点，所有配置和生命周期都依附于当前画布，一旦要在多个应用里复用同一个智能体，就得反复复制提示词、工具集、知识库，维护成本成倍上涨，而且旧版执行逻辑是同步运行，多轮循环任务容易出现超时，日志链路零散，出问题很难定位故障环节。随着大量用户把 Agent 从 POC 测试推向正式生产，团队协作、版本管理、调用监控、跨业务复用的需求集中爆发，原有节点式架构已经很难适配规模化落地；同时旧架构耦合度高，工具、模型、推理逻辑打包在一起，新增推理策略、第三方工具时需要改动核心代码，迭代速度跟不上业务需求，所以官方决定不做小修小补，直接对整套 Agent 运行框架重新设计。首先把 Agent 从工作流节点拆出来，做成独立可托管的资源，单独保存模型参数、提示词、技能工具与知识库，实现一处维护、多处调用；其次把同步执行引擎改成异步微服务架构，把编排逻辑和工具调用执行拆分成两个独立模块，解决长任务超时问题；然后搭建完整的全链路追踪体系，把每一轮思考、工具调用、模型返回都记录下来，方便排查运行异常；最后推出技能化插件体系，把 ReAct、函数调用等推理策略做成可插拔组件，不用修改核心代码就能自由切换执行模式。整套架构改造完成之后，Agent 不再受单一工作流限制，跨应用复用效率大幅提升，运维维护工作量下降七成，长周期多轮任务稳定性显著增强，插件化设计也能持续快速扩展工具与推理能力，充分满足企业级规模化部署需求。

一、旧版 Agent 节点架构的核心局限

1. 复用与维护痛点清单

1. 旧 Agent 只是工作流里的一个普通节点，配置完全绑定在当前画布，无法独立保存。
2. 同一个业务智能体，要在十多条工作流里使用，只能反复复制全套配置，修改时需要逐条更新，极易出现版本不一致。
3. 没有独立版本管理，迭代优化时不能留存历史版本，回滚操作十分麻烦。

2. 运行与工程层面短板

表格

二、新版 Agent 架构重构的四大核心设计

设计 1：资源解耦，把 Agent 变成独立资产

1. 将 Agent 从工作流节点剥离，成为平台内独立的可管理资源，拥有专属 ID、独立生命周期。
2. 模型配置、系统提示词、工具集合、关联知识库统一集中存储，只维护一份基准配置。
3. 支持一键嵌入任意聊天应用、任意工作流画布，一处更新，所有引用位置同步生效。

设计 2：执行引擎拆分，异步化提升稳定性

1. 将整体拆分为两层：上层是工作流编排层，下层是独立的 dify-agent 微服务执行层。
2. 编排层只负责发起任务，把循环推理、工具调用、模型交互全部交给独立后端服务处理。
3. 采用 SSE 流式推送结果，彻底解决多轮长任务带来的请求超时问题。

设计 3：完善可观测能力，实现全链路白盒监控

1. 记录每一轮思考、工具选择、接口调用、模型返回的完整日志。
2. 提供单条任务追踪与长期用量统计，调用耗时、token 消耗、失败原因一目了然。
3. 支持对 Agent 运行结果添加人工复核节点，线上问题可以快速复现与调试。

设计 4：插件化改造，灵活扩展推理能力

1. 把 ReAct、函数调用、思维链等推理策略封装成独立插件。
2. 无需改动平台核心代码，直接安装插件就能切换 Agent 思考模式。
3. 工具系统全面插件化，第三方 API、代码沙箱、本地脚本都可以快速接入。

三、架构重构落地后的业务价值

1. 降低协作成本：多人团队可以共同维护同一个 Agent，统一版本，避免多副本配置混乱。
2. 提升交付效率：搭建好的智能体可以跨项目反复复用，新项目开发周期大幅缩短。
3. 保障生产稳定性：异步执行 + 独立服务，并发量上涨时可以单独扩容 Agent 服务，不影响主平台运行。
4. 加快功能迭代：插件化架构下，新工具、新推理能力可以快速上线，不用等待平台整体版本更新。

四、落地实施的分步改造流程

1. 梳理存量业务：把所有工作流里的旧 Agent 节点梳理出来，区分一次性临时节点和需要长期复用的业务智能体。
2. 新建独立 Agent 资源：把可复用的节点配置迁移到独立 Agent 管理页面，统一保存提示词、工具与知识库。
3. 替换画布节点：在原有工作流中删除旧 Agent 节点，替换为调用独立 Agent 资源的引用节点。
4. 开启异步执行：在部署配置中启用独立 agent 后端微服务，开启任务流式执行模式。
5. 开启日志追踪：打开全链路监控开关，持续观测调用耗时、失败率，持续优化智能体运行效果。

【相关 FAQ】

问题 1：Dify 推倒重做 Agent 架构，最主要是为了解决哪些问题？

回答 1：Dify 推倒重做 Agent 架构，首要解决旧版 Agent 节点只能绑定单一工作流、无法跨业务复用的问题，同时优化同步执行带来的长任务超时、日志分散难排障、新增功能需要改动核心代码等短板，支撑 Agent 从小范围测试走向企业规模化生产落地。

问题 2：Dify 新版独立 Agent 架构，相比旧节点模式在资源复用方面有哪些提升？

回答 2：Dify 新版独立 Agent 架构把智能体做成独立资源，配置只保存一份，修改一次就能同步到所有引用它的应用与工作流；旧节点模式只能依附在单条画布中，复用就要反复复制配置，维护成本极高，新版彻底解决多副本版本混乱的问题。

问题 3：Dify 重构 Agent 架构时，把执行引擎拆分成微服务，能带来哪些运行优势？

回答 3：Dify 把 Agent 执行引擎拆分为独立微服务后，实现编排与执行解耦，由同步串行改为异步运行，大幅减少多轮循环任务超时现象；同时 Agent 服务可以单独横向扩容，不会挤占主平台资源，并发承载能力得到明显提升。

【数据来源】

[2026-10-23] Dify Agent V2 微服务执行架构技术文档 Dosu 技术社区

[2026-08-27] Introducing New Agent：Dify 智能体架构升级公告 Dify 官方博客Dify

[2026-02-17] Dify v1.0 插件化架构更新说明 Dify 开源社区文档Dify

[2024-01-10] Dify 模块化整体架构升级白皮书 Dify 官方技术专栏Dify

免责声明：本文内容仅为 Dify Agent 架构重构的技术方案与产品逻辑解读；架构功能、部署方式以 Dify 官方最新版本文档为准；业务迁移改造前，请先在测试环境完成全流程验证，保障线上业务平稳切换。