Dify的“中年危机”：一个明星项目正在经历的尴尬时刻

如果你关注AI应用开发，一定知道Dify。
153K Star，国产开源AI应用平台的标杆，被无数团队用来搭建Agent和知识库应用。听起来很美，对吧？
但今天我想聊的不是它的成绩单，而是它的尴尬。

重新设计Agent：一个迟到的承认

Dify最近发了一篇博客，标题是《Why We Redesigned Dify's Agent?》。

博客写得很有诚意，坦诚地回顾了问题：过去的Agent“被困在它被创建的那个工作流里”，想复用到其他地方，“意味着要重新搭建Prompt、Tools和其他设置”。

翻译一下：过去Dify的Agent系统，设计上就是一个孤岛。你在一个工作流里辛辛苦苦调好的Agent，换个场景就得从零再来。

这已经不是“不够好”的问题了，这是产品逻辑上的根本性缺陷。

Dify给出的解决方案是：让Agent可以通过CLI工具和Bash命令来完成复杂任务，同时推出Build Mode，让用户通过聊天来构建Agent，而不需要手动填写每一个设置。

思路本身没问题。CLI Agent确实是当下的技术趋势。但问题是：一个以“可视化拖拽”为核心卖点的低代码平台，把核心能力交给了命令行——这个转向本身就透着一种无奈。

那些被“低代码”困住的人

Dify最吸引人的地方，是它承诺让“不懂技术的人也能搭建AI应用”。

但现实是怎样的呢？

社区里一位负责推广Dify平台的同学分享了他的经历：让公司各部门自己用Dify搭流程，结果“他们都不会懂太深奥的流程，最后还是堆给开发”。而开发的态度更直接——“又嫌这玩意太垃圾费时间”。

这就是低代码平台最典型的困境：它既没有真正降低门槛，也没有给专业开发者提供足够的效率。

有一位开发者的批评非常深刻：Dify的代码编辑器就是“低代码”哲学的必然产物。为了照顾“不会写代码的人”，它提供了一个简化版编辑器。结果是，对不会写代码的人，它依然帮不上忙；对会写代码的人，效率远低于本地IDE，还不如直接写代码。

低代码在AI领域面临一个更本质的矛盾：AI应用的核心是让模型自主决策和规划，而不是让人类提前设计好每一个节点和连线。如果AI能自主规划，那可视化编排的价值在哪里？如果AI不能自主规划，那它还算真正的AI吗？

性能和部署：用户的耐心正在耗尽

如果说产品定位的问题还可以争论，那性能和部署的问题就没得争了。

“简单查询和知识库检索的性能慢，这在社区版中是已知问题。”这是官方在GitHub讨论区的回复。具体慢到什么程度？简单问答在本地部署后要等40到50秒。

而官方给出的解决方案是：高性能优化只在企业版提供。

翻译一下：想快？掏钱。

部署体验也好不到哪去。有用户在Issue里详细列举了自托管部署的复杂步骤，指出“很多手动步骤、没有自动生成密钥”，和其他开源项目的一键安装相比差太远。

架构的天花板，不是靠更新能突破的

更让人担忧的是架构层面的局限。

从技术架构角度分析，Dify的核心聚焦于“单应用级开发部署”，在多Agent协作编排、项目级聚合监控、精细化权限与成本管控方面，“架构上缺乏对应层级的设计”。

这意味着什么？当你只是想做一个Demo的时候，Dify够用。但当你要在企业里部署几十个Agent、要按项目维度控制成本、要做精细化的权限管理，Dify的架构根本撑不住。

有一位架构师分享了他们放弃Dify的完整经历。他的判断很精准：“低代码平台的‘拖拽’背后，其实是一堵看不见的墙。它把工程细节都替你屏蔽掉了，连你想动手改的权利也一并拿走了”。

他们最终选择基于Kubernetes自建沙箱架构，因为“隔离这件事，没有捷径可走”。

时间不等人

Dify当然在努力。重新设计Agent系统、接入CLI模式、推出Build Mode、加强企业级安全沙箱——这些都是正确的方向。

但问题是，AI Agent领域的技术迭代速度太快了。

当你在修复架构缺陷的时候，LangGraph已经在生产级复杂工作流上建立了口碑；当你在优化性能的时候，Coze已经用更流畅的体验吸引了大量用户；当你还在讨论“Agent和Workflow哪个更重要”的时候，社区用户已经在说“连MCP都过时了，Codex/CC/Pi + Skill什么都有了”。

Dify的处境，其实是所有“中间态产品”都会面临的困境。它想同时服务好“不会写代码的人”和“会写代码的人”，结果可能是两边都服务不好。它想同时做好“低代码平台”和“Agent开发框架”，结果可能是两头都不够深。

当然，Dify还有庞大的用户基础和活跃的社区。但对于一个技术产品来说，用户基础从来不是护城河，技术方向的正确性和执行速度才是。

Dify的自我革命刚刚开始。但问题是，市场会给它多少时间？