Dify 实测：拖拽编排 AI 工作流，自托管部署与适用边界

Dify 是一个开源的 LLM 应用开发平台。它把提示词、知识库检索、工具调用和发布方式收进同一张画布，让同一件事不必为每个小需求重写一套脚本。本文按实测顺序讲清三件事：它能搭出什么、Workflow 与 Chatflow 怎么分工、自托管部署时要改哪几个配置。

它能解决哪类问题

不用 Dify 的常见做法是：调模型写一段脚本，做检索再写一段，接工具又是另一段，最后用 Flask 拼一个界面。需求一变，四段代码都要动。Dify 把这些环节拆成节点，串在同一条流程里，改一个节点不会牵动其他部分。

官方文档把应用分成五类。Workflow 与 Chatflow 是当前推荐的入口，另外三种是聊天助手、Agent 和文本生成器。这几种底层运行同一套工作流引擎，只是界面更简单，适合明确知道要做什么的场景。核心概念里对这点写得很直白，值得先读一遍再动手。

发布形态也不止一种。应用发布后可以通过 API 调用、以 Web 页面直接用，或者作为 MCP 服务器挂到别的客户端上。对已经在用 MCP 的团队，这条路径省掉一层自建网关，站内MCP 协议入门里讲过协议侧的取舍。

Workflow 与 Chatflow 怎么分工

两个名字都带 flow，实际差别在触发次数和状态。Workflow 处理单轮任务，跑一次给一次结果，适合批处理和定时任务。Chatflow 在对话的每一轮都会触发，能存会话变量、能开记忆，还能在流程中间流式吐出文本、图片或文件。

容易踩的坑是术语。Dify 文档里的「工作流」泛指 Workflow 和 Chatflow 两类，社区文章则常把 Chatflow 单独叫对话流。看教程时先确认作者说的是哪一层，能省不少来回试的时间。

两种应用都能导出成 YAML 格式的 DSL，也能从 DSL 直接新建应用。团队里传流程、换实例重建，靠的就是这个文件。注意导出的 DSL 不含 Secret 类型环境变量的值，换机器后密钥要重新填一次。

自托管部署：16 个容器与两个必改配置

官方Docker Compose 部署文档给出的系统要求下限是 2 核 CPU、4 GiB 内存，Docker Compose 需要 2.24.0 及以上，Linux 上 Docker 引擎从 19.03 起。文档也提醒，这组数字只是能起来，实际跑起来建议留更多余量。

完整命令只有几条，顺序不能乱：

1. 克隆指定版本的仓库。版本号写死比用移动标签稳，出错时也容易回退。
2. 进入 docker 目录，把 .env.example 复制成 .env。
3. 执行 openssl rand -base64 32 生成令牌，填进 DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN。这一步漏了，Agent 后端和它的沙箱都起不来。
4. 执行 docker compose up -d，再用 docker compose ps 逐个确认状态。
5. 浏览器打开 /install 建管理员账号，然后从首页登录。

跑起来一共 16 个容器。7 个核心服务是 api、api_websocket、worker、worker_beat、web、plugin_daemon、agent_backend；8 个依赖组件是 weaviate、db_postgres、redis、nginx、ssrf_proxy、agent_ssrf_proxy、sandbox、local_sandbox；另有 1 个一次性任务 init_permissions 负责设置文件权限，状态显示 Exited 属正常。

升级时官方强调的顺序是：先对照各 .env.example 检查有没有新增或变更的变量，再看 Releases 里的版本升级说明。如果你改过 docker-compose.yaml，要把自己的改动重新套到新文件上，而不是继续沿用旧文件，因为近期版本可能新增了必需的服务。

插件与模板：用安装量判断该装什么

1.0 起 Dify 把模型接入、工具、扩展统一做成了插件，插件市场是独立站点。判断某个插件值不值得装，安装量是一个粗糙但有效的信号。以下数字取自 2026 年 11 月 4 日市场首页的展示：

读法有两层。模型类插件的高安装量说明多数人直接选官方维护的模型入口，自己写模型适配的不多。工具类的差异大得多，搜索和文档解析是刚需，OCR 类数字低一些，但处理扫描件时绕不开它。

安全性值得单独提一句。市场里有 SkillWard 这类插件，做法是把待审查的 Skill 和 MCP 项目放进隔离的 Docker 沙箱实际执行，再给出风险结论。它反映一个现实：第三方插件能调外部 API、能读你的知识库，装之前至少看一眼它要哪些凭证。

想自己写插件，官方有插件开发速查表，涵盖环境配置、安装、开发流程和插件类型。这属于查手册就够的活，不必先读完整个平台文档。

边界：哪些场景别硬上 Dify

社区里有团队把 Workflow 迁到代码框架后做压测，报告称吞吐量和并发表现更好。这类实践说明一件事：可视化画布擅长表达「步骤」，不擅长表达细粒度的并发控制和资源调度。请求量大、延迟要求紧的服务，最终往往仍要落回代码。

版本管理有几个付费门槛，自建前要确认清楚。草稿、当前发布版本、历史版本三层是免费的；恢复某个历史版本、导出指定版本、通过 Service API 运行指定的已发布版本，需要付费套餐。沙箱套餐只会运行当前发布的版本，这点在版本控制文档里写明。

• 只想要一个能聊本地模型的界面：那类需求用站内介绍过的Open WebUI更轻。
• 只想要统一的模型调用入口，不需要画布：LiteLLM 那一层就够。
• 流程里有复杂状态机、长事务、多表写入：画布会变得难读，考虑直接写服务。

上手路线与几个常见问题

建议的顺序是先云后自建。云端有免费套餐，可以先把 Workflow 和知识库跑通，确认流程值得留下来，再决定要不要自己维护 16 个容器。

知识库这块，1.12.0 起引入摘要索引 Summary Index。它给每个 Chunk 加一个摘要字段，内容和摘要都做向量化。检索命中摘要时，会召回同摘要的全部 Chunk，用来应对「帮我总结这份文档」这类跨段落提问（机制细节见第三方的 1.12.0 梳理）。

4 GiB 内存够用吗

能起来，但插件守护进程、向量库、沙箱都在同一台机器时，余量会很紧。个人试用 8 GiB 更从容，多人共用建议把向量库单独放。

从 0.x 升到 1.x 要注意什么

1.0 换了插件体系，模型供应商的配置方式随之变化。升级前先导出应用 DSL 做备份，再按目标版本的升级说明逐条走，遇到报错优先查 Releases 里的已知问题。

换一台机器怎么搬应用

导出 DSL 再导入即可，但 Secret 类型的环境变量值不会被带走。重新填一遍比改成明文更稳妥，也别把它提交进仓库。

能不能对外提供接口

可以。应用发布后从 API 页面取密钥，或者把应用当作 MCP 服务器挂到客户端。对外开放前记得在 .env 里配好 APP_URL 与访问控制，别让测试实例直接见公网。