为什么我把DIFY删了？

过去两年，我在 Dify 上搭建了十几条工作流，从即时翻译到 WordPress 的 SEO 提效工具——TDK 自动生成、内容润色、多语言批量翻译——全都跑在 Dify 上，博查搜索、SerpAPI、各家大模型的 API 我一层层串起来，调参、调试、上线。

今天下午我把 WordPress TDK 插件重新写了一遍，把 Dify 的依赖一刀砍掉，整个流程搬到了阿里百炼。跑了几轮测试，Token 消耗低到可以忽略不计，效果跟之前完全一样，甚至响应更快。

Dify 没做错什么，问题是它的存在本身，在这套新范式里已经变得多余。

Dify 到底臃肿在哪

自己部署过 Dify 的人都明白我在说什么，一套生产环境跑起来，至少六个组件：PostgreSQL、Redis、向量数据库（Weaviate 或 Milvus）、API Server、Worker、前端。官方给的 Docker Compose 一键启动看着优雅，实际跑起来的坑只有踩过才知道：数据库备份策略、日志轮转没配好三天撑爆磁盘、内存泄漏、版本升级后 schema 迁移报错——Dify 的迭代节奏又快，每个月都出新版，每升一次级都是一次心跳加速。

资源开销也是一笔烂账，一台 2C4G 的轻量服务器根本拉不动全套，4C8G 是勉强起步。如果你还挂了个 RAG 知识库做向量检索，8C16G 都不一定稳。问题是——我一天才调用 API 几十次，大部分时间它在空转。

最要命的是抽象过度，Dify 在你和大模型之间塞了一层编排引擎。当你真的只需要「接收一段文本 → 调大模型处理 → 返回结果」这条链路时，这层编排就变成了纯负担。你不需要一个工作流引擎来包装一个 API 调用。你不需要一个知识库引擎来存储三个 prompt 模板。你不需要一个对话管理系统来管理一个单次请求。

Dify 诞生于 Agent 生态还没成熟的年代，那时候用拖拽式工作流来弥补编排能力缺失是合理的。但现在不是那时候了。

新范式：百炼 + MCP + OpenClaw

过去半年整个 AI 基础设施层的变化，比之前两年加起来都大。核心就三点：

第一，大厂的应用平台已经够用了。 阿里百炼的智能体应用，直接在控制台配置 prompt、知识库、MCP 服务，发布之后就是一个标准 API endpoint。不做 RAG、不调复杂工作流的前提下，百炼的应用层已经覆盖了我绝大部分需求。关键是计费模式——只按 Token 收费，没有固定月费。不用的时候成本为零。

第二，MCP 协议让工具调用彻底解耦。 以前在 Dify 里接入一个搜索服务，要去插件市场找有没有现成的、没有就自己写 HTTP 节点、配 URL、处理返回格式。现在百炼的 MCP 广场直接挂了一堆现成服务——联网搜索 MCP 每月前 2000 次免费，超出后按次计费；高德地图、天气查询、网页解析、代码解释器，全都是即开即用。MiniMax 的 Token Plan 也有自己的 MCP Server，网络搜索、图片理解、图片生成全部打包，一个 API Key 搞定。你自己部署的 MCP Server 也可以注册进百炼，完全兼容 SSE 协议。

第三，Agent 框架已经成熟了。 OpenClaw 这类工具的出现，意味着你不需要一个 Web 端的编排界面来管理 Agent。它的配置方案、技能系统、持久记忆、心跳机制，都是在你的本地机器上跑的，开源的，可控的。你在本地写好配置文件，Agent 自己就能调度工具、执行任务。不需要再把逻辑交给一个远端的工作流引擎。

这三个变化拼在一起，Dify 的护城河就没了。编排能力？Agent 框架已经更灵活。工具生态？MCP 协议覆盖面更广，接入更简单。可观测性？百炼控制台有完整的调用日志和 Token 统计。部署维护？不需要了——你用的是别人的平台和协议。

一个真实的迁移案例：WordPress TDK 插件

说说我今天的这次迁移。我的博客和一些客户站点用的 SEO TDK 插件，逻辑是这样的：

1. 用户打开文章编辑页，点「生成 TDK」
2. 插件把文章标题、正文摘要发给后端
3. 后端调博查搜索 API 获取相关关键词和竞品信息
4. 结合搜索结果和文章本身，调大模型生成 title、description、keywords
5. 返回结果，填入 Yoast SEO 或 Rank Math 的对应字段

之前在 Dify 上的实现：建一条工作流，四个节点——HTTP 请求节点接博查搜索 → LLM 节点做关键词提取 → 第二个 LLM 节点生成 TDK → 代码节点做格式清洗。每次调整 prompt 或切换模型，要进 Dify 后台改工作流、测试、发布。博查的 API Key 存在 Dify 的环境变量里。工作流出过一次 bug，一个节点改参数后下游格式对不上，我对着 Dify 的执行日志排查了一下午。

今天在百炼上的新实现：

1. 在百炼控制台创建一个应用，prompt 写清楚 TDK 生成规则
2. 去 MCP 广场开通 MiniMax 的 MCP Server，配置 Token Plan 的 API Key
3. 把 MiniMax 搜索 MCP 挂到应用里
4. 发布应用，拿到 API endpoint

我的 WordPress 插件后端从调 Dify API 变成调百炼 API。代码改动不到 20 行，主要是换了 URL 和鉴权方式。效果完全一致，延迟比 Dify 还低——Dify 每个工作流节点之间有一次调度开销，百炼是直接把应用 prompt 和 MCP 工具丢给模型，一轮调用完成。

费用方面，Dify 那套方案，服务器固定成本 300+/月，博查搜索 API 按次收费，我已经用掉了五百多块了，有些时候Dify的AGENT超时会反复请求，反复请求会导致多次请求博查的API。百炼这边，我用的是千问 Flash 模型，超低价 Token，MiniMax MCP 搜索走的 Token Plan 套餐（29 元/月起）。整体算下来，月成本从「大几百」变成了「两位数」。

不是我吹百炼有多神，是我以前根本没算过这笔账——我以为「自建后端」是标配，结果发现大厂的平台应用加标准协议已经足够完成我的业务需求，而且更便宜、更稳定。

给还在用 Dify 的你的建议

我不建议你明天就把 Dify 删了跑路，我的建议是，拿一个边缘项目试水。

挑一个你目前在 Dify 上跑的功能点——最好是逻辑简单、不依赖复杂工作流的那种——试着用百炼应用或直接调 API 来替代它。注意观察几个指标：开发时间、运行延迟、月费账单、维护精力。

如果你的需求确实复杂——多条工作流互相调用、知识库体量很大需要精细的检索策略、需要多租户权限管理——Dify 依然有它的价值。但如果你跟我一样，大部分场景是「接收输入 → 调模型 → 返回输出」，那你大概率会发现，扔掉 Dify 之后整个系统清爽了不止一个量级。

Agent 已经足够成熟，MCP 协议把工具调用标准化了，大厂的平台应用把 Token 价格打到地板了。你真正需要的，可能只有几行配置文件和一张 API Key。