2026-08-07 实采:151,683★ / v1.16.1 / 当天仍在合入 commit。Dify 很热,但热度解决不了选型问题。
一、开头
8 月 7 日上午,我拉了一次 Dify 的 GitHub API:151,683 stars、23,941 forks,最新 release 是 7 月 28 日的 v1.16.1,标题写着 "Bug Fixes and Security Enhancements"。就在我拉数据的同一小时,仓库还在合入 commit(#40147)。一个 2023 年 4 月创建的项目,三年冲到 15 万星,日更不断。这不是"AI 是未来"的空话,这是"平台已经赢了"。
但越是这种时候,我越想问一句:Dify 解决的是"把 LLM 变成业务能力",它解决"让 agent 自己变好"吗?
二、Dify 真账盘点
先把我这次实采的数据摆全(2026-08-07,GitHub API):
| 指标 | 数值 |
|---|---|
| Stars / Forks / Open Issues | 151,683 / 23,941 / 941 |
| 主语言 / 创建时间 | TypeScript / 2023-04-12 |
| 最近推送 / 最新 Release | 2026-08-07 / v1.16.1(07-28) |
| License | Apache 2.0 修改版,多租户 SaaS 需商业授权 |
Release 节奏:5/19 v1.14.2 → 6/25 v1.15.0 → 7/17 v1.16.0 → 7/28 v1.16.1,两个月三个版本,而且 v1.14.2 和 v1.16.1 的 release note 都带 security 字样——迭代快,安全修复也密。仓库 topics 里躺着 agentic-framework / skills / mcp / low-code / no-code,官方定位是 "Deploy on cloud, VPC, or self-hosted"。
国产、中文文档、社区活跃度高。对掘金读者来说,Dify 就是"最容易跑起来的那一档",这点没有争议。
这份数据还能读出三件事:第一,低代码加可视化这条路线被市场验证了,15 万 star 不是营销堆出来的;第二,仓库几乎每两天就有新 PR 合入,迭代速度说明团队投入极重;第三,941 个 open issues 对这个体量不算多,但也说明用户基数大、反馈密集。对国内团队来说,中文文档、企微/钉钉集成、国内模型直连这些本地化细节,是海外同类产品给不了的。
三、对位分析:Dify 和自进化框架,差在哪一层
先摆立场:这篇不是捧谁踩谁,是把两种思路拆开看——你会发现它们根本不在同一个抽象层。
| 维度 | Dify | 自进化 Agent 范式 |
|---|---|---|
| 编排单元 | 可视化 Workflow DAG(对模型只读的图) | profile + skill + cron 三层(可写、可 git) |
| 检索与记忆 | 知识库 + embedding + rerank(人喂) | 三层记忆,运行时自动回写 |
| Agent 执行 | ReAct + 工具/MCP,策略写在图里 | ReAct + Router + 反射,失败信息回流 |
| 自进化 | 无内置,进化靠 Dify 团队发版 | 自进化飞轮:运行→复盘→改技能 |
1. 编排:Dify Workflow vs profile + skill 三层
Dify 的编排单元是"图":可视化拖拽的 DAG,节点类型固定(LLM、知识检索、工具、代码、条件分支),业务同学也能上手。图的优点是可审计、可复现,缺点是静态。拿最常见的客服问答流举例:Dify 里是拖 12~15 个节点(意图识别→知识检索→LLM 生成→条件分支→转人工),需求一改,人就得进编辑器改图;图多了以后,复用靠复制模板,版本靠导出导入 JSON。节点类型固定还有个衍生问题:官方没提供的节点,要么等版本更新,要么写自定义代码节点——自定义节点一多,"低代码"就悄悄变回"代码"了。
自进化 Agent 范式的编排单元是三层:profile(身份与上下文边界)+ skill(程序化技能)+ cron(定时触发)。profile 决定"这个 agent 是谁、能碰什么",skill 决定"遇到什么场景调什么流程",cron 决定"每天/每周自动干什么"。这里没有"图",只有一段段 skill 文档:告诉 agent 目标、步骤、禁忌,它自己按需调用工具;需求变了,改几行描述,它下次自动调整执行路径——代价是执行路径不可见,只能靠日志和复盘观测。Dify 用确定性换可观测性,自进化范式用灵活性换确定性。
这就是第一道分水岭:Dify 的图对模型是只读的,它不会因为你跑得多而改你的 workflow;自进化 Agent 的技能是"可写记忆",跑挂了复盘,复盘完改技能,下次绕开坑。
2. RAG 与记忆:Dify 知识库 vs 三层记忆
Dify 的知识库是"按文档组织的检索池":上传→切分→embedding→检索,再配 rerank 调质量,更新靠人手动同步或定时任务。它解决"怎么查得准",不解决"查完之后知识从哪来"。
我自己的笔记库攒了 200 多篇,每周新增 20 篇左右。按 Dify 知识库的模式,这个更新量意味着每周手动上传加重新切分,还得盯 rerank 阈值;自进化 Agent 范式下,每次跑完任务自己写笔记、自己更新事实,人只做抽查。差别不在检索质量——两边都能调——在知识更新的驱动方。
3. Agent 执行:Agent Node vs ReAct + Router + 反射
Dify 的 Agent Node 支持 ReAct / function calling,工具生态是它的强项:MCP 接入、内置工具一大排。决策逻辑写在提示词和图里,够用,但"策略"是写死的,失败信息不回流。
自进化 Agent 范式的执行链路是 ReAct(推理行动)+ Router(任务路由)+ 反射(事后复盘):Router 把不同类型的任务分给不同的 profile 和技能组合,反射层在每次任务结束后复盘,把失败模式写进错题本,下次执行前先读。上个月我跑一个批量调研任务,同一类错误(输出格式不符)连踩三次,第三次之后反射层把"先校验格式再输出"写进技能,此后没再犯过。这个闭环在 Dify 里不存在:agent 报错只留在日志里,改不改提示词取决于人。
4. 自进化能力:最本质的差距
上面三条是表象,第四条才是本质。Dify 有没有自进化?有,但进化的是 Dify 团队:1.14.2 → 1.16.1 两个月三版,是 langgenius 在替你进化,你的 agent 并没有因此变强。941 个 open issues 里,workflow 相关报错占比不低,每一条背后都是"人改图"的人力——这不是 Dify 独有的,是平台型产品的共性。自进化范式的迭代单元是技能、规则、记忆,进化发生在你自己的机器上,每次运行都在发生。
一句话总结:Dify 给你一个越来越好的平台,自进化 Agent 范式给你一个越来越懂你的进程。 前者是工具逻辑,后者是系统逻辑。
四、谁适合谁:决策矩阵
别听我下结论,给你一张表(团队规模 × 私有化诉求):
| 私有化诉求低(数据可上云) | 私有化诉求高(数据不出内网) | |
|---|---|---|
| 个人 / 小团队 | Dify Cloud / SaaS:零运维、模板多,一周出 Demo | 自进化框架本地跑;要可视化就 Dify 自托管,但得接受运维成本 |
| 中大型团队 | Dify 企业版:多用户、权限、审计开箱即用 | Dify 自托管(升级是长期负债)或自研框架路线,关键看要不要"记忆沉淀" |
三个问题帮你对号入座:
- 数据能不能出内网? 不能,先排除 SaaS,Dify 自托管和本地框架二选一。
- 知识要不要沉淀成"模型可读、可回写"的记忆? 要,且要 agent 自己写,只有框架路线能给;只要人管文档,Dify 够用。
- 谁负责让它变好? 希望系统自己复盘进化,选框架;希望人和流程主导,选 Dify。
这两个轴怎么用:横轴问的是合规和信任——数据能不能出内网,很多时候不是技术问题,是合同问题;纵轴问的是人力——有没有人长期维护这套系统。象限不是死的:3 人小团队如果接的是银行项目,私有化诉求直接拉满,照样得走左下象限;50 人的公司如果只是做内部效率工具,数据上云无压力,右上象限更省心。真正翻车的选型,都是把横轴当纵轴用——为了"看起来私有"付出运维代价,却没换回记忆沉淀。
反面案例:一个 5 人团队为了"数据私有化"把 Dify 自托管在 2 台机器上,半年后维护 docker compose、追版本的时间超过了写业务的时间——私有化诉求是真的,但团队没算运维账。我的观察:纯业务交付(客服助手、报表问答、审批流)选 Dify 没毛病;但如果你在养一个"长期替你干活、越干越懂你"的数字分身,自进化框架的护城河是 Dify 补不上的。
五、Dify 落地的真实坑(公开资料 + 架构推演,非我实测)
按纪律声明:这篇没有装 Dify,以下判断来自 release notes、issue 区和公开文档;标为推演的内容,我不装成实测。
- 自托管运维是隐形负债。官方部署是 docker compose 全家桶:api / worker / web / sandbox,加上 Postgres、Redis、向量库,组件多,升级有 breaking change 风险;而 v1.14.2、v1.16.1 连续两个版本带 security 修复,意味着你不追版本就裸奔。自托管跑半年后的常态是:镜像和中间件要一起升,某个组件版本不兼容就整体回滚——升级从"一条命令"变成"一次演练"。15 万 star 的仓库躺着 941 个 open issues,自托管踩坑的素材管够。建议:评估时把"升级 + 备份 + 故障处理"按每人每月固定工时算进成本,再决定要不要自托管。
- 知识库是"人喂的",不是"自己长的"。切分策略、rerank 调优、文档同步全是人工;规模上来后检索质量下降是常态,又没有运行时回写机制,知识资产不会自我增值。建议:先量化自己的文档更新频率,每周更新超过 10 篇的场景,迟早要上自动化同步。
- 开源版的多租户和细粒度权限偏弱。团队协作往往要往企业版走——License 文件写得很明白:多租户 SaaS 属于需要商业授权的场景(仓库 LICENSE 原文,不是我猜的)。建议:5 人以上团队先看企业版功能清单再决定,别拿开源版硬扛。
- 计费模型要想清楚。SaaS 按用量和席位计费;自托管省了 token 费,没省人力和机器。为了"私有化"而自托管,运维时间可能比云上费用更贵。还有一个隐性成本:模型接入——Dify 支持多模型厂商,但自托管时每家模型的 API 配置、限流、降级策略都要自己维护;这些在 SaaS 版是平台的事,自托管版全回到你头上。建议:把云上费用、自托管机器加人力两份账单都列出来再比。
这些坑不是 Dify 的错,是"平台型产品"的结构性成本:平台替你封装了复杂度,复杂度的账单在运维和定制化里结。
六、结论与展望
Dify 和自进化框架不是替代关系,是不同抽象层:一个把 LLM 变成业务系统的能力,一个把 agent 变成长期运行、自我迭代的系统。选型别问"哪个强",问三件事:数据能不能出内网、记忆要不要沉淀、进化由谁驱动。
生态会收敛:Dify 的 topics 里已经出现 agentic-framework 和 skills,迟早要补自进化能力;自进化框架也在补可视化与可观测。今天做选型,想清楚你的"迭代单元"是什么——是人改的图,还是系统自己长的记忆——比押哪边更重要。
参考资料
- Dify 仓库:github.com/langgenius/… GitHub API 实采)
- Dify Releases:github.com/langgenius/…
- Dify 官方文档:docs.dify.ai
- Hermes Agent:github.com/NousResearc…
- obra/superpowers:github.com/obra/superp…
- Langflow:github.com/langflow-ai…
