Dify：把 Agentic Workflow 收进一块画布
Dify 用一块可视化画布把 workflow、RAG、agent、模型管理和 LLMOps 收进同一个平台，Docker Compose 四条命令即可自托管，同一份应用可搬到 C
一个团队做 LLM 应用，最费时间的往往不是写 prompt，而是把 prompt、检索、工具调用、日志、模型切换这几件事拼成一条能上线的链路。Dify 的判断是：这条链路不该由每个团队各拼一遍，它应该是一块画布上的节点。
这个判断撑起了 15.8 万星标。但星标不是重点，重点是它把「原型」和「生产」放在了同一套抽象里——官网首页的定位写得很直白：The Platform for Production-Ready Agentic Workflows，Cloud、VPC、self-hosted 三种部署方式共用同一份应用定义。
一块画布下面压着七层能力
README 把核心能力列成七项：Workflow、Comprehensive model support、Prompt IDE、RAG Pipeline、Agent、LLMOps、Backend-as-a-Service。这七项不是并列的功能清单，而是有依赖关系的分层。按数据与请求的流转顺序重新排一遍，结构就清楚了：
| 层 | 对应能力 | 职责 | 在链路中的位置 |
|---|---|---|---|
| 接入层 | Backend-as-a-Service | 每个能力都带对应 API，供外部业务系统调用 | 最外层，对外暴露 |
| 编排层 | Workflow | 在可视化画布上搭建并测试 AI 工作流 | 定义执行顺序 |
| 智能体层 | Agent | 带沙箱的自主 agent，可执行命令、装软件、处理文件；可挂 Dify Marketplace 工具、MCP server 或自有 API | 作为 chat app 或 workflow 中的一个步骤 |
| 知识层 | RAG Pipeline | 从文档摄入到检索的完整链路，开箱支持 PDF、PPT 等格式的文本抽取 | 为编排层和智能体层供料 |
| 模型层 | Comprehensive model support | 对接数十家推理提供方的数百个闭源/开源 LLM，含 GPT、Mistral、Llama3 及任何 OpenAI API 兼容模型 | 被上层任意节点调用 |
| 调试层 | Prompt IDE | 编写 prompt、对比模型表现、给 chat 应用加 TTS 等能力 | 开发期介入 |
| 观测层 | LLMOps | 监控应用日志与性能随时间的变化，基于生产数据和标注持续改 prompt、数据集、模型 | 上线后回流 |
自上而下读这张表：外部系统通过 API 进入，请求落到画布上定义好的 workflow，其中某一步可能是 agent，agent 调工具、查知识库，知识库背后是 RAG pipeline，所有模型调用统一走模型层，开发期用 Prompt IDE 调，上线后由 LLMOps 收集日志反哺。
两个细节值得单独拎出来。
Agent 有沙箱。 README 的原话是「Autonomous agents with a sandbox of their own: they run commands, install software, and handle files to get open-ended tasks done」。这意味着 agent 不是只调 HTTP 工具的函数集合，它能在隔离环境里执行真实操作。同一段还写了「Describe the agent you want and it builds itself」——用自然语言描述想要的 agent，它自己构建自己。
工具来源是三条腿。 Dify Marketplace、MCP server、自有 API。MCP 出现在 topics 列表里，说明这不是事后补的兼容层，而是被当作一等公民对待。
四条命令之后
自托管是 Dify 最常被引用的入口。README 给的门槛很低：CPU ≥ 2 核，RAM ≥ 4 GiB，Docker 与 Docker Compose v2.24.0 以上。
bashcd dify cd docker cp .env.example .env docker compose up -d
跑完在浏览器打开 http://localhost/install 进入初始化流程。
这四行的分量在于 .env.example：所有可配置项集中在一个环境变量文件里，docker/docker-compose.yaml 定义了服务编排。想改配置就改 .env，想加观测就在这套 compose 上加服务。README 把「自定义配置、可观测性、部署选项」指向了 docs/ADVANCED_SETUP.md，把「从源码部署」指向了文档站的 local-source-code 页面——也就是说，从「跑起来」到「改起来」有明确的下一站，不是让你自己猜。
观测这块 README 点名了三个集成：Opik、Langfuse、Arize Phoenix。它们不是 Dify 自建的能力，而是通过集成接入的外部工具。这个选择很务实：LLMOps 的日志与追踪已经有成熟方案，Dify 提供的是接入点，不是重造一套。
它和同主题项目差在哪
把 Dify 和几个常被放在一起比较的项目摆开，定位差异比功能对比更说明问题。
| 项目 | 语言 | 星标（快照） | 定位 |
|---|---|---|---|
| Dify | Python | 158717 | 可视化 LLM 应用开发平台，workflow + RAG + agent + LLMOps 一体 |
| AutoGPT | Python | 187526 | 给一个目标，让 agent 自主拆解、规划、迭代执行 |
| hermes-agent | Python | 252822 | agent 框架，把 prompt、工具调用、workflow 串起来 |
| ECC | JavaScript | 277276 | 给现有编程 agent 加装 skills、记忆与安全层 |
| firecrawl | TypeScript | 190553 | 网页抓取解析成 Markdown/JSON，给 LLM 喂干净数据 |
| ollama | Go | 182792 | 本地一条命令跑起大模型，CLI + SDK |
差别在抽象层级。AutoGPT 和 hermes-agent 是「让 agent 自己跑」的框架，你写代码定义 agent 怎么思考、怎么调工具；ECC 是给已有 agent 加装能力的外挂层；firecrawl 是数据入口，专攻网页转干净文本；ollama 是模型运行时的最底下一层，管的是模型怎么在本机跑起来。
Dify 站的位置不一样：它假设模型从哪来、工具从哪来、数据从哪来都可以是外部提供的，它负责的是把这些东西编排成一条可观测、可部署的应用。所以它同时需要模型层的兼容性（任何 OpenAI API 兼容模型都能接）、工具层的开放性（Marketplace / MCP / 自有 API）、数据层的摄入能力（PDF、PPT 抽取），以及最上面的画布。
这也解释了为什么它的语言标注是 Python 而站内快照写 TypeScript——后端是 Python，前端是 Next.js，topics 里 nextjs 和 python 同时出现。一个平台型项目，前后端各用各的生态是常态。
谁该用它，谁不该
如果需求是「给我一个能自己规划步骤、跑长任务的 agent」，Dify 不是最直接的答案，hermes-agent 或 AutoGPT 更贴。如果需求是「把网页抓成干净数据喂给 RAG」，firecrawl 干得更专。如果只是「在本机跑个模型调 prompt」，ollama 一条命令就够。
Dify 的适用面是另一种：团队里有人写 prompt、有人管知识库、有人要接业务系统、有人负责上线后的日志和效果回流，这些人需要看同一份东西。画布是这个协作的载体，API 是它伸向业务系统的接口，LLMOps 是把生产数据送回开发端的回路。
一个具体的落地路径是：先在 Cloud 上做原型，验证 workflow 和 RAG 的效果，然后把同一份应用搬到自托管或 VPC 环境上线，不重写技术栈。这是站内简介里点明的典型场景，也是「production-ready」这个词在官网标题里的实际含义。
许可与参与
许可标注为 NOASSERTION，README 的 License 段落写的是 Dify Open Source License——基于 Apache 2.0 并附加条件。要商用或二次分发，这一段值得逐字读，不要按 Apache 2.0 想当然。
参与方式 README 列了四条：代码（先读 Contribution Guide，再从 good first issue 入手）、想法与反馈（GitHub Discussions）、翻译（按 web/i18n/README.md 的国际化为指南，README 本身已有近二十种语言版本）、社区分享。安全漏洞走 GitHub Security Advisories 私下报告，不走公开 issue。
仓库创建于 2023 年 4 月，最近一次推送在 2026 年 10 月，forks 25087，open issues 1134。这些数字说明它是一个仍在高频演进的活跃项目——对平台型工具来说，这既是功能在长，也是接口在变，锁定版本再升级比一路跟 main 更稳妥。