项目快照：langgenius/dify，约 152,341 个 Star，24,044 个 Fork；最新推送时间 2026-08-13T14:19:47Z。本文基于仓库公开资料撰写。
项目地址：https://github.com/langgenius/dify · https://dify.ai
项目速览（TL;DR）
dify 是一个开源的大语言模型应用开发平台（LLM app development platform），目标是把人工智能工作流（AI workflow）、检索增强生成（Retrieval-Augmented Generation，RAG）、智能体（Agent）、模型管理和可观测性集中到协作式工作空间中。根据仓库描述，它支持部署到云环境、虚拟私有云（VPC）或自托管环境；README 给出的自托管启动方式基于 Docker Compose。
仓库资料显示，项目主要语言为 TypeScript，默认分支为 main，GitHub Star 数为 152341，Fork 数为 24044，仓库页面许可证元数据为 NOASSERTION。仓库同时提供了 LICENSE 文件，其内容说明项目采用带附加条件的 Apache License 2.0 修改版，实际使用、分发和商用应以仓库中的 LICENSE 为准。
- 定位：面向从原型开发到生产部署的 LLM 应用开发平台。
- 核心能力：可视化工作流、RAG 流程、模型提供商接入、提示词开发、Agent 工具调用和可观测性集成。
- 自托管入口：README 提供 Docker Compose 方式，最低要求为 CPU 不少于 2 Core、内存不少于 4 GiB。
- 前端技术信息：package.json 表明仓库使用 TypeScript，并声明 Node.js 版本范围为
^22.22.1。
定位与目标用户
这一节的结论是：Dify 更适合需要把模型、知识库、工具和业务流程放在同一开发工作区中的团队，而不是仅仅寻找一个单一模型调用库的项目。它的公开资料强调的是应用开发、流程编排和从原型到生产的部署连续性。
从 README 的功能描述看，Dify 将模型调用、提示词、知识检索和 Agent 行为放在统一的应用开发界面中。团队可以通过图形化画布构建并测试工作流，再根据部署要求选择 Dify Cloud、自托管或其他由项目资料列出的部署形态；具体云端能力、资源限制和服务等级不在给定资料中，官方仓库未提供该信息，建议以最新 README 和官方文档为准。
适用对象包括需要快速验证 LLM 应用流程的产品或研发团队、维护企业内部知识问答的技术团队，以及希望保留部署控制权的自托管用户。对于只需要在代码中调用某个模型接口、且不需要工作流、RAG、Agent 或协作界面的项目，Dify 的完整平台形态未必与需求匹配；这一判断属于根据本文作者的经验判断。
核心功能
Dify 的核心价值不在单一模型能力，而在于把应用构建过程中不同阶段的输入、处理和输出连接起来。下面按 README 明确列出的能力说明其工作方式；没有在资料中出现的接口签名、数据格式和内部实现不作推断。
可视化工作流（Workflow）
工作流通过可视化画布构建和测试 AI 流程。其基本机制是把多个处理步骤放入同一流程中，由流程中的节点承接输入并产生后续步骤所需的输出；README 没有提供节点类型、分支条件、变量格式、执行队列或错误重试规则，因此这些细节应以对应版本的官方文档为准。
从使用目的看，工作流适合将提示词处理、模型推理、知识检索和工具调用组织为可重复执行的应用逻辑。触发方式、输入输出字段和发布接口并未在给定仓库资料中说明，不能据此虚构具体 API 或运行时协议。
模型管理与多提供商支持
README 将模型支持描述为可连接数百个专有或开源大语言模型，并覆盖数十个推理提供商和自托管方案；列举的模型或兼容范围包括 GPT、Mistral、Llama3 以及 OpenAI API 兼容模型。模型管理层的作用是让工作流、提示词应用或 Agent 使用可配置的模型来源，而不是把业务代码固定绑定到某一个模型。
输入通常来自用户问题、工作流变量或 Agent 上下文，输出则由所选模型返回文本或模型能力相关结果。具体支持哪些提供商、需要哪些凭据、如何设置模型名称和限额，应查看 README 指向的模型提供商文档；给定资料没有提供环境变量名或密钥字段名。
提示词开发环境（Prompt IDE）
提示词开发环境用于编写提示词、比较模型表现，并为聊天应用增加包括文本转语音在内的附加能力。其工作流可以理解为：开发者输入提示词模板和测试内容，选择模型进行比较，再把验证后的提示词放入聊天应用或其他流程中。
README 没有给出比较实验的指标定义、样本管理格式、版本保存规则或文本转语音服务列表。因此，这项能力可以作为提示词验证和应用配置入口，但不能仅依据当前资料推断它具备自动评测、离线基准或固定的语音服务协议。
检索增强生成（RAG Pipeline）
RAG 流程覆盖从文档导入到检索的过程，并开箱支持从 PDF、PPT 及其他常见文档格式中提取文本。其核心链路是将文档内容导入系统，完成文本抽取和后续检索，再把检索结果提供给模型生成回答；README 未提供切分、嵌入模型、向量存储或召回排序的具体配置。
RAG 的输入可以是文档及用户查询，输出通常表现为与查询相关的检索内容和模型生成结果，但具体返回结构、索引生命周期、权限隔离和更新机制均未在资料中说明。部署前应特别核对文档解析覆盖范围、数据保存位置和所需模型提供商设置。
Agent 能力与工具调用
README 说明 Dify 可以基于大语言模型函数调用（LLM Function Calling）或 ReAct 定义 Agent，并允许添加预置工具或自定义工具。运行时，Agent 根据模型输出决定是否调用工具，再将工具结果纳入后续推理或最终回答；工具的参数约束、超时、失败处理和权限模型未在给定资料中公布。
资料片段末尾显示“Dify provides 50+ built-in too”，但该句在提供内容中被截断，因此不将其扩展为完整的工具数量或工具清单。使用自定义工具时，应只连接经过授权且可审计的服务，并为工具输入、输出和网络访问设置独立边界；这属于安全部署原则，不代表仓库已提供特定安全机制。
系统架构与关键模块
现有资料足以确认 Dify 的产品级模块边界，但不足以复原完整的服务拓扑。可以根据 README、LICENSE 和 package.json 对可确认部分进行分层说明，不能补写未公开的数据库、消息队列、后端语言或内部 API。
产品能力层
- 应用编排：通过工作流画布组织 AI 处理步骤，并提供测试入口。
- 知识增强：从文档导入和文本抽取进入 RAG 流程，再参与检索增强回答。
- 模型抽象：面向多个专有、开源、推理提供商和自托管模型统一组织模型使用。
- Agent 执行：以 Function Calling 或 ReAct 为基础决定是否使用预置或自定义工具。
- 质量与运行观察：README 明确提到包括 Opik、Langfuse 和 Arize Phoenix 在内的可观测性集成。
仓库与前端相关信息
package.json 位于仓库根目录，内容表明根项目是私有包，模块类型为 ESM（ECMAScript Modules），并使用 pnpm 作为包管理器。LICENSE 对前端范围作了明确约定：从原始源码运行时，前端包括 web/ 目录中的全部组件；使用 Docker 时，前端包括 web 镜像。
package.json 中的开发脚本通过 vp、concurrently、ESLint 和 Vite Plus 等工具组织前端开发及检查流程，但给定资料没有提供完整工作区文件、服务端目录、容器服务清单和生产拓扑。对于这些架构问题，官方仓库未提供该信息，建议以最新源码和部署文档为准。
依赖与运行环境
自托管启动的最低资源和软件前置条件在 README 中有明确记录，因而可以直接用于初步环境检查。它们只说明启动门槛，不等同于生产容量、并发上限或性能承诺。
| 项目 | 资料中的要求 | 来源 | 说明 |
|---|---|---|---|
| CPU | 不少于 2 Core | README | 自托管快速启动前的最低系统要求。 |
| 内存 | 不少于 4 GiB | README | 自托管快速启动前的最低系统要求。 |
| Docker | 需要安装 | README | Docker Compose 启动方式的前置软件。 |
| Docker Compose | v2.24.0 或更高版本 | README | README 明确要求 Docker Compose v2.24.0 or later。 |
| Node.js | ^22.22.1 |
package.json | 仓库 package.json 的 engines.node 声明。 |
| 包管理器 | pnpm@11.20.0 |
package.json | 仓库 package.json 的 packageManager 声明。 |
Docker Compose 方式并不要求先根据 package.json 在本地编译整个项目；README 的快速开始直接使用仓库中的 docker/docker-compose.yaml。如果进行源代码开发，则 package.json 还声明了 Node.js 运行时范围，具体依赖安装步骤和源码部署过程应以官方源代码部署指南为准。
快速开始
给定资料中的最小可运行闭环是：准备 Docker 与 Docker Compose，复制环境文件，启动 Compose 服务，再通过本机安装页面验证。以下命令保持 README 中的目录和命令，不增加未在资料中出现的参数。
安装与启动
# 进入已获取的 dify 仓库
cd dify
# 进入 Docker Compose 文件所在目录
cd docker
# 创建本地环境配置文件
cp .env.example .env
# 以后台方式启动 Dify
docker compose up -d执行前需要确认主机至少具备 2 Core CPU 和 4 GiB RAM，并安装 Docker 以及 Docker Compose v2.24.0 或更高版本。命令中的 .env 是从仓库提供的 .env.example 复制而来，但给定资料没有列出其中的字段，因此不在正文中臆造环境变量。
运行验证
# 在浏览器中打开 Dify 初始化页面
# http://localhost/installREADME 指出，服务启动后可以在浏览器访问 http://localhost/install，并开始初始化流程。此处只验证初始化页面是否可访问，不将页面可访问推断为模型、RAG、Agent 或外部工具已经配置完成。
问题处理入口
如果初始化或启动失败，README 建议先查阅自托管 FAQ；仍然无法解决时，再通过项目社区和维护者渠道寻求帮助。启动命令没有包含远程主机、生产域名、外部密钥或第三方服务配置，适合在本地或测试环境验证基础部署。
配置说明
资料中没有提供完整的 .env.example 内容，因此不能列出 Dify 的数据库、缓存、模型密钥或域名配置。下面的表格只整理 package.json 中真实出现的项目配置字段，字段默认值严格按资料记录；这些字段属于仓库开发工具链，不等同于 Docker 部署的全部运行配置。
| 字段名 | 类型 | 默认值 | 作用 |
|---|---|---|---|
name |
字符串 | "dify" |
根项目名称。 |
private |
布尔值 | true |
声明该 npm 项目为私有项目。 |
type |
字符串 | "module" |
声明使用 ECMAScript Modules 模块类型。 |
packageManager |
字符串 | "pnpm@11.20.0" |
声明项目使用的包管理器及版本。 |
engines.node |
字符串 | "^22.22.1" |
声明项目所需 Node.js 版本范围。 |
devEngines.runtime.name |
字符串 | "node" |
声明开发运行时名称。 |
devEngines.runtime.version |
字符串 | "^22.22.1" |
声明开发运行时版本范围。 |
package.json 还提供了 dev、check、lint:eslint、lint:oxlint、lint:tailwind 和 Knip 相关脚本。它们反映了仓库的开发检查方式，但资料没有给出从源码完整安装、启动后端或连接外部模型的全部步骤，所以不应将这些脚本当作完整生产部署命令。
进阶用法
进阶使用的重点是把 Dify 的能力组合成可维护的应用流程，而不是只验证安装页面。根据 README，进一步配置可以围绕工作流、模型、提示词、RAG、Agent 和观测集成展开，但每个领域的具体字段仍需查阅官方文档。
从提示词到工作流
可以先在提示词开发环境中编写和比较提示词，再将经过测试的提示词纳入可视化工作流。这样做的输入是测试问题、提示词内容和所选模型，输出是模型响应及开发者对结果的比较判断；README 未说明比较结果是否会自动保存或生成量化报告。
将 RAG 接入回答链路
对于包含 PDF、PPT 或其他文档的知识问答场景，可以先完成文档导入和文本抽取，再将检索结果交给模型生成回答。实施时应确认文档来源是否有授权、抽取结果是否包含敏感内容，以及知识库更新后的检索一致性；资料没有公布具体索引或向量数据库配置。
为 Agent 增加工具
Agent 可基于 Function Calling 或 ReAct 组织决策，并调用预置或自定义工具。自定义工具的输入应限定在业务所需字段，输出应保持可验证和可审计；对于能够写入数据、发送消息或改变外部系统状态的工具，应在测试环境进行隔离验证。项目资料没有给出工具注册命令或工具 API 示例，因此不提供虚构的代码签名。
可观测性与运维
README 明确把可观测性列为平台能力，并列出 Opik、Langfuse 和 Arize Phoenix 的集成链接。由此可以确认项目关注模型应用的运行观察，但给定材料没有定义日志字段、指标名称、链路追踪范围、告警规则、数据留存时间或高可用方案。
- 集成选择：根据团队已经采用的观测平台，在 README 列出的 Opik、Langfuse 或 Arize Phoenix 中核对对应集成文档。
- 运行审计：对工作流、RAG 检索和 Agent 工具调用分别记录必要的输入、输出与错误上下文，同时避免写入不必要的敏感数据。
- 故障定位：先区分 Docker Compose 启动问题、模型提供商配置问题、文档处理问题和工具调用问题，再根据官方文档核对配置。
- 容量规划：仓库资料只给出最低 CPU 和内存要求，没有并发、吞吐、延迟或资源扩展数据，不能据此制定 SLA 或性能承诺。
对于生产运维，备份策略、升级回滚、数据保留、容器编排平台和多实例部署方式均未在给定资料中说明。官方仓库未提供该信息，建议以最新自托管文档和实际验证结果为准。
安全与合规边界
Dify 可以连接模型、知识文档和外部工具，因此部署时必须把数据授权、凭据保护和工具权限作为独立控制项。下面只讨论在已获授权的本地、测试或企业环境中使用，不提供面向未授权目标的攻击教程、绕过检测技巧或账号自动化方案。
数据与凭据
- 导入 PDF、PPT 和其他文档前，应确认组织拥有相应的处理授权，并明确文档中是否包含个人信息、商业秘密或受监管数据。
- 模型提供商凭据、工具凭据和自定义服务凭据不应写入公开代码、截图或日志。资料没有列出具体密钥字段名，实际字段以
.env.example和官方文档为准。 - 测试环境应使用非生产数据，尤其要避免把真实客户资料直接用于提示词比较、RAG 索引或 Agent 工具测试。
- 外部工具应采用最小权限，优先使用只读接口；对写入、删除、发送或审批类动作增加人工确认或独立授权层。
隔离与责任边界
README 提供的是平台能力说明，并未承诺满足特定行业法规、数据驻留要求、认证标准或服务等级。对于多租户、跨组织数据隔离、审计留存和合规评估，不能仅依据“支持云、VPC 或自托管”的描述得出结论，应由部署方完成架构和法律审查。
许可证与商用条款
许可证判断应以仓库 LICENSE 文件为准，而不是只看 GitHub 页面中的许可证元数据。当前仓库资料同时显示 GitHub 元数据为 NOASSERTION，LICENSE 则明确写明 Dify 使用带附加条件的 Apache License 2.0 修改版。
- 商用：LICENSE 明确说明 Dify 可以用于商业目的，包括作为其他应用的后端服务或作为企业应用开发平台，但必须遵守附加条件。
- 多租户限制：未经 Dify 明确书面授权，不得使用 Dify 源代码运营多租户环境。LICENSE 将一个 workspace 定义为一个 tenant，并说明 workspace 为每个 tenant 提供数据和配置的分隔区域。
- 前端标识：使用 Dify 前端时，不得移除或修改 Dify 控制台或应用中的 LOGO 与版权信息。LICENSE 对前端范围作了定义，包含源码运行时的
web/目录及 Docker 运行时的web镜像。 - 贡献代码：贡献者需要同意生产方可以根据需要调整开源协议的严格程度，并允许其贡献代码用于商业目的，包括云业务运营。
- 其他条款：除上述特别条件外，其他权利和限制遵循 Apache License 2.0；LICENSE 还声明产品交互设计受外观专利保护。
因此，“可以商用”不能简化为“没有任何限制”。若计划提供多租户 SaaS、修改前端品牌信息、重新分发修改版或将 Dify 集成到受监管业务中，应在上线前逐条审阅 LICENSE，并在必要时向权利人获取商业许可；具体法律结论以仓库 LICENSE 和专业法律意见为准。
局限性与已知限制
当前资料能够说明 Dify 的产品范围，但不能支持对完整工程质量、生产性能或所有部署形态作结论。以下限制来自资料缺口或 LICENSE 中的明确约束，不能理解为对源码缺陷的断言。
- 给定资料没有提供数据库、缓存、队列、后端服务拆分和容器服务清单，无法仅凭 README 复原完整系统架构。
- 没有提供并发数、吞吐量、响应延迟、资源扩展比例、Benchmark、SLA 或灾备指标。
- 没有提供完整环境变量表、模型密钥字段、RAG 索引参数、工具注册协议和 API 接口签名。
- README 中关于内置工具数量的句子在资料片段中被截断，不能据此列出完整工具清单或确认具体数量。
- 自托管最低资源要求只适用于 README 所述快速开始条件，不能直接作为生产容量规划依据。
- 许可证对未经书面授权的多租户服务和前端 LOGO、版权信息修改设置了明确边界。
如果项目需要强合规、跨租户隔离、严格审计或固定性能目标，应先补齐部署文档、数据流图、容量测试和法律审查，再决定是否采用。该决策建议属于根据本文作者的经验判断。
适合谁
以下信号同时出现时，Dify 的平台化能力更有使用价值；判断依据主要来自 README 对工作流、RAG、模型、Agent 和部署方式的描述。
- 团队需要在同一工作区内同时管理提示词、模型、知识库和 Agent，而不是只维护一段模型调用代码。
- 业务流程包含多个 AI 步骤，需要通过可视化画布构建、测试和调整工作流。
- 应用需要处理 PDF、PPT 或其他常见文档，并将检索结果用于生成式回答。
- 团队需要在多个专有模型、开源模型、推理提供商或自托管模型之间进行选择。
- 部署方需要在 Dify Cloud、VPC 或自托管路径中选择运行位置，并愿意自行承担配置、运维和合规审查。
不适合谁
下列信号表明 Dify 可能不是当前问题的直接解决方案，或需要先完成额外评估。这里不构造未出现在资料中的替代产品比较。
- 需求只有一个简单的模型请求，且不需要工作流画布、RAG、Agent、工具调用或协作式管理界面。
- 团队无法接受自托管所需的 Docker、Docker Compose、资源准备和初始化维护工作。
- 业务要求未经授权即可直接提供多租户 Dify 服务，这与 LICENSE 中的多租户限制不一致。
- 产品必须移除或修改 Dify 前端控制台及应用中的 LOGO、版权信息，而项目方又不准备取得相应授权。
- 项目已经确定了严格的并发、延迟、SLA 或合规指标，但尚未通过实际部署、测试和法律审查验证 Dify 是否满足要求。
常见问题与排查（FAQ / Troubleshooting）
排查优先级应从环境和启动命令开始，再进入模型、文档和工具链路。README 已提供 FAQ 入口，但给定资料没有逐条复制 FAQ 内容，以下只回答当前材料可以核实的问题。
Q：启动前需要满足什么条件？
A：README 给出的最低系统要求是 CPU 不少于 2 Core、内存不少于 4 GiB；软件方面需要 Docker 和 Docker Compose v2.24.0 或更高版本。该要求是快速启动前提，不是生产性能保证。
Q：Docker Compose 启动后从哪里验证？
A：README 指定在浏览器访问 http://localhost/install，进入初始化流程。如果页面无法访问，应先确认当前目录为仓库的 docker 目录、.env 已由 .env.example 复制生成，并检查 Docker Compose 是否按后台命令启动。
Q：为什么正文没有列出环境变量？
A：给定资料只展示了复制 .env.example 的命令，没有展示文件内容。字段名、类型和默认值均未提供，官方仓库未提供该信息，建议以当前检出的仓库文件和最新自托管文档为准。
Q：模型、RAG 和 Agent 启动后是否自动可用？
A：不能这样推断。README 分别描述了模型提供商、RAG、Agent 和工具能力，但快速开始只说明完成 Dify 服务启动与初始化；模型凭据、知识文档、工具权限和相关配置需要按官方文档单独核对。
Q：源码开发使用哪些检查命令？
A：package.json 提供了以下真实脚本，可用于理解仓库开发检查入口：
# 运行项目检查与 ESLint
pnpm check
# 自动修复部分检查问题
pnpm check:fix
# 运行 ESLint
pnpm lint:eslint
# 运行开发脚本
pnpm dev这些脚本来自 package.json，但给定资料没有提供完整的源码开发前置步骤、工作区安装命令和各脚本所依赖的服务，因此不能把 pnpm dev 解释为完整的端到端生产启动方式。源码开发部署请参考 README 指向的本地源码部署指南。
Q：遇到安装问题应查什么资料？
A：README 明确建议查阅自托管 FAQ；仍有问题时可通过项目社区渠道联系维护者。排查时应保留 Docker Compose 输出、初始化页面现象和使用的仓库版本信息，但不要公开 API 密钥、个人数据或内部服务地址。
项目地址与资源
以下链接均来自仓库资料或 README 中出现的官方站点，适合用于源码获取、部署、模型配置和项目支持。
