Dify
Dify（开源项目） · 开源可自部署，编排与 RAG 一体
Dify 是一个开源的 LLM 应用开发平台。它同时提供云端托管版和可以自己部署的开源版本——这一点让它在低代码平台里比较特殊：大多数同类平台只有托管一条路。
它擅长什么
编排与知识库一体。 应用编排、知识库管理、检索配置在同一个界面里完成，不需要在多个系统之间来回倒腾。对于以「查资料然后回答」为主的场景，链路比较顺。
可自部署。 开源版本可以装在自己的服务器上。对数据有要求的团队，这是它相比纯托管平台最实际的优势。
多模型接入。 支持接入不同厂商的模型，也支持接本地部署的开源模型。
许可：能商用，但有两条附加条款
Dify 用的是改版 Apache 2.0，官方在标准条款之外加了附加条件。对做项目的人来说，要点是：
- 明确允许商业化使用，包括作为其他应用的后端服务，或者作为应用开发平台交付给企业——这一点写在官方 LICENSE 里，对系统集成商很关键
- 但两种情况需要单独获得商业授权：运营多租户环境（Dify 语境下一个 workspace 即一个租户），以及移除或修改前端控制台的 LOGO 与版权信息
也就是说，你可以拿它给甲方做项目并收费，但不能把它白牌化成自己的产品卖，也不能拿它去做一个类似的多租户 SaaS。
这跟 n8n 的许可差别很大——后者只允许自己内部使用，分发必须免费。同样是「可自部署」，能不能靠它接活完全不同。
这段是提示不是法律意见，商用前请自己读官方 LICENSE。
什么情况下它会不够用
自部署解决的是「应用本身在哪运行」，但如果你在里面配置的是在线大模型，提问和检索到的知识片段仍然要发给模型厂商——数据依然出网。要做到全链路不出网，模型也必须是本地部署的。这一点经常被混淆，值得单独确认。
另外，当检索效果需要针对特定文档结构深度调优、或者业务逻辑需要写进代码时，平台提供的配置项会显得不够用。
我们把这些分水岭写在了这里：什么时候必须从低代码转向原生开发。
相关教程（8）
用 Dify 的 API 把能力接进自己的系统：密钥、流式和会话状态
Dify 可以只当后端，前台是你自己的产品。这篇讲四种接法的取舍、密钥绝不能放前端的原因，以及会话状态该存在哪。
Dify 本地部署前要想清楚的六件事
官方文档告诉你怎么装，但没告诉你装之前该定什么。硬件怎么估、数据边界在哪、版本怎么选、升级怎么办——这些定错了，装好也白装。
Dify 用 Docker 部署时镜像拉不下来：成因与四种解法
国内网络拉镜像卡住、超时、拉一半断——这不是 Dify 的问题，是镜像源的问题。这篇讲清成因、四种解法各自的代价，以及给客户部署时该怎么办。
Dify 知识库的 embedding 模型怎么选：中文场景下这一步比换主模型有用
检索不准时大家都想换更强的对话模型，但真正决定「能不能找到」的是 embedding 模型。这篇讲它的作用、中文场景的坑，以及换模型的代价。
Dify 工作流和 Agent 到底什么区别：谁来决定下一步
这两个概念最容易搞混，选错了会一路别扭。区别只有一句话——步骤是你定死的，还是让模型临场决定的。
Dify 工作流什么时候该用、什么时候是在自找麻烦
不是所有需求都需要工作流。这篇讲清楚聊天助手和工作流的分界、节点图开始失控的四个信号，以及失控之后该往哪走。
Dify 和扣子怎么选：三个问题就能定
不用比功能清单。数据能不能出网、要不要交付给客户、团队有没有运维能力——这三个问题答完，答案基本就出来了。
Dify 知识库检索不准怎么排查：从切块到重排的五个环节
上传了文档，问出来的答案却答非所问。这篇按检索链路逐环节拆，讲清每一步会在哪出问题、怎么验证，以及哪些问题调参数解决不了。