如果你是 Dify 的老用户，最近可能都有同一个疑问：这家伙是不是「哑火」了？
翻一翻版本记录你会发现，稳定版的小步快跑停了下来，没有再像过去那样密集地蹦出一个个带着新特性的大版本号。社区里甚至有人开始担心：Dify 是不是「卷不动」了？
但如果你真的点开它的 GitHub 仓库，看一眼那条还在疯狂滚动的 Pull Request 列表,你就会立刻明白——它不是在躺平，而是在憋一个更大的东西。
截至目前,langgenius/dify 仓库里挂着 600 多个待合并的 PR、累计处理过 1.9 万个 之多。这不是「没活干」的样子,恰恰相反,这是暴风雨前的集中火力。今天我们就顺着这些代码提交的蛛丝马迹,聊聊 Dify 的下一个版本到底在准备什么,以及那个所有人都在问的问题:它真的要「推倒重来」做一次大重构吗?
一、先说结论:是的,Dify 正在进行一次「伤筋动骨」的重构
把最近的开发动态摊开来看,一个非常清晰的信号浮出水面:Dify 的下一代版本,核心不是「加功能」,而是「换地基」。
从 GitHub 上公开的架构重构议题可以看到几条主线 [@4c09e7 @451e90 @b4d0db]:
-
工作流图引擎重写(Queue-based Graph Engine):把工作流的执行内核改造成基于队列的全新图引擎架构,引入可配置的工作线程池,并通过环境变量灵活调优性能。关键是——它在保持对老工作流向后兼容的同时,为未来打下了一个更稳、更能扛的底座 [@4c09e7]。 -
知识库彻底解耦(Decoupled Knowledge Base):把知识库和文档管理能力从「大一统」的主应用里拆出来,独立成一个专门的内部微服务。这意味着 Dify 正在从单体架构,向更现代的服务化架构演进 [@451e90]。 -
清理历史包袱:逐步移除工作流层对老旧内部参数(如 GraphInitParams)的直接依赖,等新 API 稳定后再删掉兼容层;前端也在把工作流节点的渲染和配置面板的加载解耦,给画布「减重」[@b4d0db @0ca9d0]。
换句话说,这一轮不是刷漆补墙,而是把承重墙都重新砌了一遍。这类改动风险高、周期长、对外不「性感」,但一旦完成,就是脱胎换骨。这也完美解释了为什么稳定版的更新节奏看起来「慢」了——团队的主要精力,都压在了地基上。
二、下一个版本会有哪些重要功能?看官方路线图在「正在做」什么
地基之外,上层的新能力同样值得期待。根据 Dify 官方路线图上标记为 「正在构建中(In Progress)」 的条目,下一代版本大概率会带来这几件硬货 [@07e5bd]:
1. 全新 RAG 知识平台(New RAG)
这是最受关注的一项。官方明确表示要用一个全新的知识平台替换掉现有的 RAG 实现,并且是「以 Agent 为核心」重新设计的 [@07e5bd]。配合前面提到的知识库解耦,可以预见:新一代 RAG 不只是检索更准,而是从架构到交互的一次整体升级。(社区里早有迁移说明提到,新版采用了更高效的检索引擎,老的向量索引甚至无法跨版本复用——侧面印证了这次换血的彻底 [@378429]。)
2. 技能管理(Skill Management)
把散落在各个 Agent 提示词里的业务 SOP(标准作业流程)抽取出来,变成集中管理、可版本化的资源,任何 Agent 都能复用。一句话:改一处,处处生效。对于管理着大量 Agent 的团队来说,这是治理层面的刚需 [@07e5bd]。
3. Dify App Builder(自然语言搭建助手)
在编排页面上,把「用自然语言搭工作流、改工作流、试跑排错」整合成一个统一的 AI 助手:业务同学用大白话就能搭简单流程,IT 同学可以生成节点脚手架做精调,试跑失败时还能拿到 AI 的诊断建议 [@07e5bd]。这是把「低代码」往「无代码 + AI 陪跑」又推了一大步。
4. 子图展开能力(Subgraph Expansion)
支持在画布里直接内联、展开「工作流即工具(Workflow as Tool)」的子图,大幅提升复杂流程的可视化与调试体验 [@07e5bd]。
5. 企业级能力补齐
-
HITL 融入主流 IM:把「人工审批(Human-in-the-loop)」能力接入 Teams、Slack、钉钉、飞书等企业 IM,审批人不用切换工具就能完成任务 [@07e5bd]。 -
应用多环境部署:为应用配置相互隔离的部署环境(资源、配置完全隔离),并提供环境管理与版本发布能力 [@07e5bd]。 -
工作区级 Access Token:引入工作区级别的访问令牌,让自动化任务和外部系统能以受限范围访问指定的 Dify 应用、App Runner 部署与知识库 [@07e5bd]。
三、从一堆 PR 里,能嗅到团队的「真实优先级」
路线图是「想做什么」,而 PR 列表是「正在做什么」——后者往往更诚实。扫一眼最近的提交,几个趋势很明显:
-
稳定性和正确性压倒一切:大量 fix提交集中在工作流执行、追踪、分页、取消/幂等等「硬核」环节,比如在运行准入阶段强制幂等键、实时追踪里保留迭代与循环的轮次、用稳定游标给会话列表分页等。这都是把一个工具「从能用做到可靠」的脏活累活。 -
开发体验在升级:多个 refactor在给代码库「立规矩」,比如为工具类单测开启严格类型检查、为工作流评论试点聚合根(aggregate)模式——这些都是为长期可维护性铺路。 -
CLI 和插件生态在变强:围绕命令行工具的下载、文件名编码、设备授权重试等细节持续打磨,凭据校验与 OAuth 吊销适配器也在补齐,说明「让 Dify 更好地接入外部系统」是重点方向之一。
把这些拼在一起,结论很一致:团队没有在堆花哨功能,而是在为一次大版本做「全面体检 + 换骨」。
四、对我们意味着什么?
如果你正在用 Dify,或者在评估它,这波「沉默」其实是个好信号:
-
别只盯着版本号。真正的大动作往往发生在版本号跳变之前。地基重构期的「慢」,换来的是下一代的「稳」。 -
提前规划 RAG 迁移。既然新一代知识平台是重写、且索引可能无法跨版本复用,现在就该把知识库的数据和构建流程梳理清楚,为升级留出余量 [@378429]。 -
企业用户可以期待治理能力。RBAC、多环境部署、HITL 接 IM、Access Token……这些拼图凑齐后,Dify 会更像一个「能放心交给大团队用」的企业级平台。
写在最后
Dify 的这半年,表面上风平浪静,水面下却是一次罕见的「大换血」:图引擎重写、知识库解耦、RAG 2.0、技能管理、App Builder——每一项单拎出来都够发一个版本,而它选择攒在一起,一次性把地基和上层一起换掉。
所以回到开头那个问题:Dify 要重点重构吗?
答案是肯定的。而且这次,它赌的是下一代的天花板。
至于那个「下一个大版本」何时正式发布——按这个节奏,或许就在不远的将来。值得蹲一个。
Dify社区群：嗨聊吧
欢迎扫码加入嗨聊吧！
