Dify 是一个开源的全栈 LLM 应用开发平台，提供可视化 AI 工作流编排、RAG 管道、Agent 框架和模型管理等核心能力，帮助开发者和企业快速构建生产级的 AI 应用。名称源自 "Define"（定义）和 "Modify"（修改）的组合，体现了"定义和修改 AI 应用"的核心理念。
Dify（开发团队：LangGenius）在当前的开源 LLM 开发生态中占据一个独特的位置。如果说 LangChain 是一盒积木（需要自己组装），OpenAI Assistants API 是一套成品家具（但只能买同一品牌），那么 Dify 就是一套完整的脚手架系统——预制的架构设计、工程化的组件和现成的部署方案，让开发者可以直接在上面构建应用，而不是从零开始。
截至 2025 年，Dify 在 GitHub 上已获得超过 100,000 星标，服务 180,000+ 开发者，被银行、科技公司、医疗机构等广泛用于生产环境。版本迭代速度约每 2-4 周一次。
| 能力 | 描述 | 适用场景 |
|---|---|---|
| 可视化工作流 | 拖拽式画布编排 AI 逻辑，支持条件分支、循环、并行 | 复杂多步 AI 流程 |
| RAG 管道 | 文档导入→分块→向量化→混合检索→重排序 | 企业知识库问答 |
| Agent 框架 | 支持 ReAct、Function Calling、Chain-of-Thought 策略 | 自主推理与工具调用 |
| Prompt IDE | 提示词编写、模型对比、变量注入、版本管理 | 提示词工程 |
| 模型管理 | 统一接入 100+ 模型（GPT、Claude、Llama、Qwen 等） | 模型选型与成本控制 |
| 部署中心 | 一键发布为 API、Web App 或嵌入式 Widget | 快速上线 |
| MCP 集成 | 原生支持 MCP 协议，可作为 MCP Server 发布 | 系统集成 |
Dify 在 0.4.0 版本完成了从单体架构到六边形模块化架构的重大重构。Beehive 架构的核心理念是：每个模块像蜂巢的六边形单元格一样，既独立又协作，灵活且可扩展。
┌────────────────────────────────────────────────────────────────┐
│ Dify 整体架构 │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ API 服务层 │ │ Worker 异步层 │ │
│ │ (Flask/Python) │ │ (Celery) │ │
│ │ │ │ │ │
│ │ REST 端点 │ │ 文档索引 │ │
│ │ 业务逻辑 │ │ 模型调用 │ │
│ │ 认证授权 │ │ 批量处理 │ │
│ └────────┬─────────┘ └────────┬─────────┘ │
│ │ │ │
│ ┌────────┴──────────────────────┴──────────┐ │
│ │ 数据层 │ │
│ │ ┌─────────┐ ┌──────┐ ┌──────────────┐ │ │
│ │ │PostgreSQL│ │Redis │ │向量数据库 │ │ │
│ │ │(元数据) │ │(缓存) │ │(Qdrant/ │ │ │
│ │ │ │ │(队列) │ │ Weaviate/ │ │ │
│ │ │ │ │ │ │ pgvector) │ │ │
│ │ └─────────┘ └──────┘ └──────────────┘ │ │
│ └───────────────────────────────────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │安全沙箱 │ │SSRF Proxy │ │插件守护进程 │ │
│ │(chroot隔离) │ │(安全隔离) │ │(4种运行时) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Web 前端 (Next.js) │ │
│ │ 工作流画布 │ 知识库管理 │ 应用发布 │ 监控面板 │ │
│ └─────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘
三大核心服务说明：
API 服务（Python/Flask）：处理所有 REST 端点和业务逻辑。这是用户与 Dify 交互的主要入口，包括知识库管理、工作流定义、用户认证等。
Worker 服务（Celery）：异步任务处理的核心。它处理文档索引（PDF 解析、文本分块、向量化）、长时间运行的模型调用、批量数据处理等操作。通过任务队列（Redis）与 API 服务解耦，保证高负载下的响应性能。
Web 前端（Next.js）：基于 React 的现代化界面，提供可视化工作流画布、知识库管理、Prompt IDE、监控面板等功能。
数据层组件分工：
辅助服务：
Dify 的插件系统支持四种执行环境，这是其灵活性的关键体现：
| 运行时模式 | 通信方式 | 适用场景 | 特性 |
|---|---|---|---|
| Local | STDIN/STDOUT 子进程 | 开发调试 | 快速迭代 |
| Debug | TCP 长连接（Redis 状态管理） | 开发调试 | 热重载支持 |
| Serverless | AWS Lambda | 云端部署 | 自动弹性伸缩 |
| Enterprise | 受控环境 | 私有部署 | 安全隔离 |
安全模型方面，插件使用加密签名验证完整性，通过公私钥验证机制允许插件拥有完整能力的同时保证安全性，相比传统的沙箱限制方案更为灵活。
Dify 的工作流引擎是平台的核心。它采用图执行引擎（Graph Execution Engine），支持节点间的依赖关系解析，自动识别可并行执行的节点，以及处理条件分支和循环。
所有节点类型速查表：
| 节点类型 | 功能 | 输入 | 输出 | 示例应用 |
|---|---|---|---|---|
| LLM | 调用大语言模型 | 提示词、变量 | 生成文本 | 文本生成、摘要 |
| 知识检索 | 从知识库检索 | 查询文本 | 相关文档列表 | RAG 问答 |
| 代码 | 执行 Python/JS | 变量 | 处理后变量 | 数据清洗 |
| HTTP 请求 | 调用外部 API | URL、参数 | API 响应 | 查天气、查数据库 |
| 条件分支 | if-else 路由 | 条件表达式 | 分支结果 | 逻辑分叉 |
| 变量赋值 | 设置/修改变量 | 变量名、值 | 更新后变量池 | 保存中间状态 |
| 迭代 | 循环处理列表 | 列表变量 | 处理结果集 | 批量文档处理 |
| 工具 | 调用内置工具 | 工具参数 | 工具返回 | Google 搜索、绘图 |
| Agent | 自主推理决策 | 用户指令 | 综合回答 | 复杂推理任务 |
| 模板转换 | 格式化输出 | 模板+变量 | 格式化文本 | 报告生成 |
| 参数抽取 | 从文本提取参数 | 原始文本 | 结构化参数 | 表单填充 |
| Human Input | 人工审核 | 待审批内容 | 审批结果 | 人工确认环节 |
工作流示例：电商客服工单自动分类与处理
用户输入：申请退货（订单号：ORD-2025-1234）
│
▼
[LLM 节点] 意图识别
│
▼
[条件分支] 判断意图类型
├── "退货申请" → [HTTP 请求] 查询订单状态
│ │ → 条件判断是否在退货期内
│ │ ├── 是 → [知识检索] 查询退货政策
│ │ │ → [LLM] 生成退货指引
│ │ └── 否 → [LLM] 生成拒绝说明
│ │
├── "技术问题" → [知识检索] → [LLM] 技术解答
│
└── "投诉" → [Human Input] 转人工客服
并行执行实现原理：
迭代节点支持并行处理，底层使用线程池管理，通过 is_parallel 标记控制是否并行执行：
# Dify 迭代节点的并行执行逻辑（简化示意）
if self.node_data.is_parallel:
# 创建线程池，parallel_nums 控制并发数
thread_pool = GraphEngineThreadPool(
max_workers=self.node_data.parallel_nums
)
futures = []
for item in iterator_list_value:
future = thread_pool.submit(
self._run_single_iteration, item
)
futures.append(future)
# 智能聚合结果，处理错误和超时
results = self._collect_results(futures)
else:
# 串行执行
results = [self._run_single_iteration(item)
for item in iterator_list_value]
这种实现巧妙地处理了串行和并行两种模式，变量池系统实现了跨节点的变量传递和层级作用域隔离。在复杂工作流中，变量池采用层级作用域（类似编程语言中的作用域链），子节点可以访问父节点的变量，但反之不行。
批量文档处理示例对比：
| 处理方式 | 100 份文档 | 1,000 份文档 | 10,000 份文档 |
|---|---|---|---|
| 串行（逐个处理） | ~8 分钟 | ~80 分钟 | ~13 小时 |
| 并行（10 线程） | ~50 秒 | ~8 分钟 | ~80 分钟 |
| 并行（50 线程） | ~15 秒 | ~2 分钟 | ~20 分钟 |
注：以上数据基于单文档处理约 5 秒的简假设，实际表现因文档复杂度、模型响应速度等因素而异。
Dify 的 RAG 引擎是平台的重要竞争力之一。它涵盖了从文档摄入到最终检索生成的完整流程，无需用户搭建单独的技术栈。
完整 RAG 管道流程：
文档上传 → 格式解析 → 文本清洗 → 分块策略
↓
向量化(Embedding)
↓
存入向量数据库
↓
用户查询 → 查询重写 → 多路检索(向量+关键词)
↓
结果融合 → 重排序(Rerank)
↓
LLM 生成回答(含引用来源)
Dify RAG 引擎的文档格式支持：
| 格式 | 解析方式 | 质量 | 说明 |
|---|---|---|---|
| 内置解析器 + OCR 可选 | ⭐⭐⭐⭐ | 支持表格提取 | |
| Word (.docx) | python-docx | ⭐⭐⭐⭐ | 保持段落结构 |
| PPT | 内置解析器 | ⭐⭐⭐ | 提取文字内容 |
| Excel | 内置解析器 | ⭐⭐⭐ | 按工作表分页 |
| Markdown | 直接解析 | ⭐⭐⭐⭐⭐ | 保留标题层级 |
| 纯文本 | 直接使用 | ⭐⭐⭐⭐⭐ | 无格式信息 |
| 网页 URL | 爬虫抓取 | ⭐⭐⭐ | 依赖网页结构 |
分块策略对比：
| 策略 | 分块方式 | 优点 | 缺点 | 最佳场景 |
|---|---|---|---|---|
| 固定大小 | 按字符数切分 | 简单可预测 | 可能切在句中 | 简单文本、代码文档 |
| 语义分块 | 按段落/章节切分 | 保持语义完整 | 块大小不均 | 文章、报告 |
| 父文档-子文档 | 大块(父)+小块(子) | 兼顾上下文和精确度 | 实现复杂 | 法律文档、技术手册 |
检索策略对比与效果数据：
| 检索策略 | 实现方式 | 技术文档命中率 | 客服问答命中率 | 法律文书命中率 | 平均速度 |
|---|---|---|---|---|---|
| 纯向量检索 | 余弦相似度 | 72% | 68% | 65% | 50ms |
| 关键词检索(BM25) | 倒排索引 | 68% | 75% | 71% | 30ms |
| 混合检索 | 向量+BM25 加权融合 | 89% | 91% | 88% | 80ms |
| 混合+重排序 | 混合后 Rerank 精排 | 93% | 94% | 92% | 150ms |
注：数据基于 Dify 内部测试集（含 50,000+ 文档），实际效果随数据集和 Embedding 模型选择有所差异。
从表中可以看出，混合检索相比纯向量检索命中率提升 15-20 个百分点，而增加 Rerank 重排序后又能额外提升约 3-4%。这是 Dify 在生产环境中推荐使用的完整配置。
Agentic RAG：带推理的智能检索
传统 RAG 的流程是固定的：接收查询→检索→生成。如果第一次检索结果不好，用户只能手动修改查询再试。Agentic RAG 引入了 Agent 作为"检索大脑"，每次检索都是一个多步推理过程：
实验对比数据：
| 场景 | 传统 RAG 完整率 | Agentic RAG 完整率 | 平均延迟 |
|---|---|---|---|
| 单跳简单问答 | 91% | 93% | +0.5s |
| 多跳复杂问答 | 56% | 87% | +2.3s |
| 跨知识库查询 | 43% | 82% | +3.1s |
| 需要推理的综合问题 | 38% | 76% | +4.5s |
Agentic RAG 的代价是更高的延迟和更多的 Token 消耗（约 1.5-3 倍），适用于对准确率要求高、用户能接受稍长等待时间的场景。
Dify 的 Agent 节点是工作流中的"大脑"——它能根据任务自主决定调用哪些工具、何时检索知识库、以及是否需要多步推理。
支持的 Agent 推理策略对比：
| 策略 | 工作方式 | 适合场景 | 能力等级 | 速度 | Token 消耗 |
|---|---|---|---|---|---|
| ReAct | 思考→行动→观察→再思考循环 | 复杂多步推理任务 | 高 | 慢 | 高 |
| Function Calling | 模型直接输出结构化函数调用 | 工具调用明确的任务 | 中 | 快 | 中 |
| Chain-of-Thought | 链式思考，分步推理 | 需要逐步推导的分析 | 中 | 中 | 中 |
Agent 节点内部架构：
用户输入
│
▼
┌──────────────────────────┐
│ Agent 节点 │
│ │
│ 1. 意图分析模块 │
│ 2. 工具选择器 │
│ 3. 知识检索协调器 │
│ 4. 结果合并器 │
│ 5. 重试/降级策略 │
│ │
│ ┌── 50+ 内置工具 ──┐ │
│ │ Google Search │ │
│ │ DALL·E 绘图 │ │
│ │ WolframAlpha │ │
│ │ 自定义 API │ │
│ │ MCP 集成工具 │ │
│ └──────────────────┘ │
└──────────────────────────┘
│
▼
输出响应
Agent 实际运行案例：研究报告生成
用户提问："帮我分析一下 2025 年 AI Agent 开源的三个主要框架，对比它们的 GitHub Stars、核心特性和适用场景"
Agent 的执行步意：
Dify 的 Prompt IDE 不是一个简单的文本编辑器，而是一个完整的提示词开发环境：
核心功能：
{{variable}} 语法，支持变量池、对话历史、知识库上下文的动态填充提示词模板示例（客服场景）：
你是一个{{company_name}}的{{role}}客服。
## 可用信息
- 当前对话历史：
{{history}}
- 知识库结果：
{{context}}
- 用户当前位置：{{user_location}}
## 任务
用户的问题：{{query}}
请按照以下步骤处理：
1. 先确认用户的问题类型（售后/技术/投诉）
2. 如果是已知问题，引用知识库中的标准答案
3. 如果是新问题，生成初步回答并标记为"待确认"
4. 保持语气专业且友好
## 输出格式
{{
"question_type": "...",
"answer": "...",
"needs_escalation": true/false,
"references": [...]
}}
Dify 的 Model Runtime 是整个平台的"万能插座"——通过统一的抽象层，让开发者可以透明地切换不同的模型提供商，无需修改应用代码。
支持的模型类型与提供商：
| 模型类型 | 提供商 | 具体模型示例 |
|---|---|---|
| 大语言模型 | OpenAI | GPT-4o、GPT-4o-mini、o1、o3-mini |
| Anthropic | Claude 3.5 Sonnet、Claude Opus、Claude Haiku | |
| Gemini 1.5 Pro、Gemini 2.0 Flash | ||
| DeepSeek | DeepSeek-V3、DeepSeek-R1 | |
| 阿里云 | Qwen-Max、Qwen-Plus、Qwen-Turbo | |
| Meta | Llama 3.1 (8B/70B/405B) | |
| Mistral | Mistral Large、Mistral Small | |
| 智谱 | GLM-4、GLM-4-Plus | |
| 月之暗面 | Moonshot-v1 | |
| 零一万物 | Yi-Large、Yi-Medium | |
| Embedding | OpenAI | text-embedding-3-large/small |
| 智谱 | text2vec-bge | |
| M3E | M3E-large | |
| Rerank | Cohere | rerank-v3 |
| BGE | BGE-Reranker | |
| 语音输入 | OpenAI | Whisper |
| Azure | Azure Speech-to-Text | |
| 语音输出 | Azure | Azure TTS |
| ElevenLabs | ElevenLabs TTS |
Model Runtime 实现原理（Java 风格伪代码示意）：
class ModelRuntime:
"""统一的模型运行时，所有模型调用都经过这里"""
def invoke_llm(self, model_id, **kwargs):
# 1. 根据模型 ID 自动检测提供商
provider = self._resolve_provider(model_id)
# 2. 获取凭证（支持多 Key 负载均衡）
credentials = self._get_credentials(provider)
# 3. 统一调用，自动处理重试和降级
with self._telemetry_context():
result = provider.invoke(
model=model_id,
messages=kwargs.get('messages'),
streaming=kwargs.get('streaming', False),
credentials=credentials
)
# 4. 记录用量（精准分离输入/输出 Token）
self._track_usage(
provider=provider,
model=model_id,
input_tokens=result.input_tokens,
output_tokens=result.output_tokens
)
# 5. 如果失败且有备用 Key，自动切换重试
if result.error and self._has_fallback(provider):
return self._retry_with_fallback(model_id, kwargs)
return self._format_output(result)
多凭证管理与成本控制：
Dify v1.7.0+ 支持为同一模型提供商配置多个 API Key，实现负载均衡和故障切换。
多 Key 配置示例与成本计算：
| Key | 提供商 | 模型 | RPM 限制 | TPM 限制 | 优先级 | 月配额 |
|---|---|---|---|---|---|---|
| Key-1 | OpenAI | GPT-4o | 10,000 | 10M | 1（主） | $500 |
| Key-2 | OpenAI | GPT-4o | 5,000 | 5M | 2（备用1） | $200 |
| Key-3 | OpenAI | GPT-4o-mini | 10,000 | 10M | 3（降级备用） | $200 |
成本节约场景：当主 Key 的月度配额用尽时，自动降级到价格更便宜的 GPT-4o-mini，或者切换到 Claude Haiku，保证服务不中断的同时控制成本。
| 模型 | 输入价格（每百万 Token） | 输出价格（每百万 Token） | 相对 GPT-4o 成本 |
|---|---|---|---|
| GPT-4o | $2.50 $10.00 | 100% | |
| GPT-4o-mini | $0.15 $0.60 | 6% | |
| Claude 3.5 Haiku | $0.25 $1.25 | 12% | |
| DeepSeek-V3 | $0.27 $1.10 | 11% | |
| Qwen-Plus | $0.80 $2.00 | 20% |
通过智能路由，可在高峰期将 80% 的简单查询路由到 4o-mini 或 Haiku，在保证回答质量的前提下将推理成本降低 70-90%。
| 部署方式 | 难度 | 适用场景 | 运维成本 | 弹性扩展 |
|---|---|---|---|---|
| Docker Compose | 低 | 个人/小团队原型验证 | 低 | 不支持 |
| 源码部署 | 中 | 开发调试/深度定制 | 中 | 可定制 |
| Kubernetes | 高 | 生产环境大规模部署 | 高 | 支持 |
| Dify Cloud | 无需部署 | 快速试用/小微企业 | 零 | 自动 |
| 企业版 | 低 | 大型组织/有合规要求 | 低 | 支持 |
Docker Compose 快速部署命令：
# 前提：已安装 Docker 和 Docker Compose
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
# 编辑 .env 配置关键参数后
docker compose up -d
启动后访问 http://localhost:3000 完成初始化设置（创建管理员账号、配置 LLM 提供商）。
Dify 提供三种应用发布选项，覆盖不同的使用场景：
| 发布方式 | 访问形式 | 认证方式 | 适合场景 | 配置复杂度 |
|---|---|---|---|---|
| Web App | 独立 URL 访问 | 公开/Token 认证 | 内部工具、Demo | 低 |
| API 端点 | RESTful API | Bearer Token | 嵌入到现有系统 | 中 |
| Widget | iframe 嵌入 | 继承宿主系统 | 嵌入官网/用户系统 | 低 |
以 API 方式调用已发布的工作流：
curl -X POST https://your-dify.app/api/workflows/run \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"inputs": {
"query": "2025年Q3的营收是多少？",
"department": "finance"
},
"response_mode": "blocking"
}'
返回结果包含工作流执行的完整输出和历史 ID，便于追踪。
从 1.x 版本开始，Dify 支持将工作流或 Agent 发布为标准 MCP 服务器，兼容所有 MCP 客户端（包括 Claude Desktop、VS Code 等）。这意味着：
| 对比维度 | Dify | LangChain | Flowise | Langflow |
|---|---|---|---|---|
| 产品类型 | 全栈 LLM 应用平台 | Python 代码框架 | LangChain 的可视化封装 | LangChain/LangGraph 可视化 IDE |
| 目标用户 | 开发者 + 非技术人员 | 软件开发者 | 初级开发者、爱好者 | 开发者、数据科学家 |
| 学习曲线 | 低（0.5-1 天上手） | 高（1-4 周） | 中（2-5 天） | 中高（3-7 天） |
| 编码需求 | 低/无代码 | 全代码 | 低代码 | 中代码 |
| 工作流引擎 | 自研图执行引擎 | 代码链(Chain) | LangChain 链 | LangGraph 图 |
| 工作流迭代能力 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| 调试体验 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| RAG 管道 | 内置完整（含重排序） | 需自行组装组件 | LangChain 组件组合 | LangChain 组件组合 |
| Agent 能力 | 原生强大（多策略） | 灵活可定制 | 有限 | 中等 |
| API 部署 | 一键 API + Web App + Widget | 需搭配 LangServe | REST API | 可导出 Python |
| 版本管理 | 内置版本历史 | 手动导出 Git | 无内置 | 有限 |
| 社区规模 | 100K+ Stars | 100K+ Stars | 70K+ Stars | 40K+ Stars |
| 许可证 | Apache 2.0 类似（有额外条款） | MIT | Apache 2.0 | MIT |
| 部署方式 | Docker / K8s / Cloud | pip 库 | Docker / Cloud | Docker / Cloud |
分场景选择建议：
| 场景指标 | Dify | LangChain | Flowise | Langflow |
|---|---|---|---|---|
| 从零开始到第一个 Chatbot 上线时间 | 1-2 小时 | 8-40 小时 | 2-4 小时 | 3-8 小时 |
| 构建复杂 RAG 应用所需代码量 | 0-50 行 | 200-1000 行 | 0-50 行 | 0-50 行 |
| 单应用维护成本（人月/月） | 0.1 | 0.5-1 | 0.2 | 0.3 |
| 非技术人员可操作比例 | 60% | 0% | 40% | 20% |
Kakaku.com 采用 Dify Enterprise 将分散的 AI 实验转化为生产级解决方案。结果：
一家全球领先的消费电子企业使用 Dify 打通了技术和非技术团队的协作：
某金融机构使用 Dify + Milvus 构建合规知识库问答系统：
| 配置 | 无模型集成 | 含模型集成 |
|---|---|---|
| 1 CPU + 2GB RAM | ~10 QPS | ~6 QPS |
| 2 CPU + 4GB RAM | ~18 QPS | ~11 QPS |
| 4 CPU + 8GB RAM | ~35 QPS | ~20 QPS |
注：数据来自 Dify 社区测试，含模型集成的场景指工作流中包含 LLM 调用。
当前版本的主要性能瓶颈：
| 版本 | 发布日期 | 重要特性 |
|---|---|---|
| v0.4.0 | 2024-01 | Beehive 架构重构，Model Runtime 独立模块 |
| v0.7.0 | 2024-08 | 对话变量(Variable Assigner)、多路径知识检索 |
| v1.0.0 | 2024 | 首个稳定版，企业版发布 |
| v1.7.0 | 2025 | OAuth 工具支持、多凭证管理、负载均衡 |
| v1.7.2 | 2025 | 工作流增强 |
| v1.8.0 | 2025 | 智能提示优化、代码节点自动修复 |
| v1.13.0 | 2026-03 | Human Input 节点（人工审核）、Creator Center 创作者中心、Template Marketplace 模板市场 |
| v1.14.1 | 2026-05 | 工作流团队协同、复用和版本管理 |
目标：上传一份产品手册，搭建一个能回答产品问题的对话机器人。
步骤：
1. 环境准备（1 分钟）
docker compose up -d
访问 http://localhost:3000
2. 配置模型（1 分钟）
设置 → 模型提供商 → 填入 OpenAI/DeepSeek/其他 API Key
3. 创建知识库（1 分钟）
知识库 → 创建 → 上传 PDF/Word → 自动分块和向量化
4. 创建应用（1 分钟）
应用 → 创建对话型应用 → 填写系统提示词(角色设定)
知识库 → 关联刚创建的知识库
5. 发布和测试（1 分钟）
发布 → 获得 Web App URL 或 API 端点
在预览界面开始对话测试
提示词建议（产品客服机器人）：
你是一个{产品名}的产品专家。请基于知识库中的内容回答用户问题。
如果知识库中没有相关信息，请如实告知，不要编造答案。
回答时引用具体文档来源。
引用格式：[文档名称 - 页码]
Dify 作为目前最流行的开源 LLM 应用开发平台之一，它的核心价值在于降低了 AI 应用开发的准入门槛，同时不牺牲生产环境的可靠性和可扩展性。
核心优势总结：
适用场景：
不太适合的场景：