从零搭出第一个 Dify 应用：用云版完成一次 Chatflow 上线
上一篇结尾，我说下一步要“进入机器房”，从私有化部署开始真正动手。
计划后来遇到了一个很具体的限制：这台写作机器连不上公司内网里的自建 Dify。既然无法亲手核对环境，我不想把官方文档改写成一篇仿佛亲自验证过的部署实录。
所以这一篇先换一条路：使用 Dify 官方云版，从零创建一个应用，完成配置、测试和发布的完整闭环。
这不是为了避开真正的工程问题。
Dify 云版和自建版面对的是同一套产品概念：工作空间、Studio、应用类型、节点、变量、模型、调试和发布。自建版多出来的，是安装、配置、网络、存储、升级和运维责任；应用设计本身并不会因此变成另一门学问。
先在云版里把核心操作跑通，等以后进入内网环境，你需要补的是部署与运维这一层，而不是重新学习 Dify。
更重要的是，云版替我们移除了第一次上手时最容易干扰判断的变量：Docker 是否启动、模型密钥是否有效、服务之间能否通信、反向代理有没有配对。
这一篇只验证一件事：你能不能把一个想法，清楚地表达成一条可运行、可测试、可发布的 AI 应用流程。
我们要做的应用叫“国家信息小助手”。用户输入一个国家的名字，它用一句自然的话回答这个国家的首都。
功能很小，但链路是完整的：
用户输入 → Start 接收 → LLM 理解并生成 → Answer 返回 → 发布上线。
只要这条链路真正跑通，你就已经跨过了“看懂界面”和“做出应用”之间的第一道门槛。
| # | 主题 | 一句话 | 状态 |
|---|---|---|---|
| 1 | AI 应用平台通识与选型 | 认知/选型判断力：这个领域是什么、要不要学、怎么定位 | 已发布 |
| 2 | 云版搭第一个 Chatflow 应用 | 5 种应用类型、Start/LLM/Answer、Prompt 分层、发布分发 | ← 你在这里 |
| 3 | 给应用装上"分岔路" | If/Else、问题分类器：写死的规则 vs 交给模型判断 | 已发布 |
| 4 | 别只让数据路过：用变量打地基 | 会话变量、环境变量、变量聚合器/赋值器 | 已发布 |
| 5 | 把外部世界接进来 | HTTP Request、Code 节点、参数提取器 | 已发布 |
| 6 | 知识库与 RAG 实战 | 文档处理/分段/检索策略/Rerank | 已发布 |
| 7 | 批量处理与循环 | Iteration、Loop、列表操作 | 已发布 |
| 8 | 工具与 Agent | 工具市场、自定义工具、Function Calling/ReAct、双向 MCP | 已发布 |
| 9 | 从 Demo 到生产：运维篇 | DSL 版本管理、执行日志、标注、可观测性、权限 | 已发布 |
| 10 | 私有化部署实战 | Docker Compose、.env、报错排查 |
已发布 |
开始之前：云版和自建版到底是什么关系
第一次接触 Dify 的人，常把“用云版”和“学私有化部署”理解成两条互相排斥的路线。
其实它们解决的是两个不同层次的问题。
| 层次 | 你主要关心什么 |
|---|---|
| 应用层 | 选哪种应用、节点怎么连接、Prompt 怎么写、变量怎么传、怎样测试和发布 |
| 平台运维层 | 服务如何部署、数据放在哪里、模型密钥怎样管理、网络和存储怎样配置、如何升级与排障 |
本篇学习的是应用层。
无论 Dify 运行在官方云端，还是运行在公司内网，用户输入进入 Chatflow 后，仍然要经过节点、变量和模型调用，最后由输出节点返回结果。
界面版本可能有细微差异，企业环境也可能关闭某些模型、插件或发布权限，但核心思路不会改变。
这也是为什么云版适合第一课：它把平台先运行起来了，让我们可以直接观察应用本身。
当然，云版并不等于自建版的预演环境。真正进入企业内网后，你还会遇到模型访问策略、账号权限、敏感数据、日志留存、网关和版本差异。
所以更准确的说法是：
云版帮你学会“如何使用一座工厂”；私有化部署再教你“如何把这座工厂建起来并维护好”。
这一篇先把前一件事做扎实。
Sandbox 免费套餐，究竟够不够学
打开 cloud.dify.ai 后，新用户可以从 Sandbox 套餐开始。
根据 Dify 官方文档与官方博客目前给出的信息，Sandbox 免费、无需信用卡，并提供一次性的 200 条消息试用额度。
这里最值得注意的是“一次性”。
它不是每月重新发放 200 条，而是一份入门试用额度。一次 LLM 调用大约会消耗 1—10 条消息额度，实际消耗与所选模型和消息长度有关。
因此，200 条不能简单理解成“可以完整聊 200 轮”。如果一个流程里放了多个 LLM 节点，或者一次输入很长，额度消耗也会更快。
Sandbox 的优势，是默认提供 OpenAI、Anthropic Claude、Google Gemini 和 xAI Grok 四家模型的免费试用额度。
你不需要先去模型厂商注册账号、充值、创建 API Key，再回到 Dify 配置模型供应商。登录之后，就可以直接选择可用模型开始搭建。
对第一次学习尤其重要。很多“Dify 入门失败”，其实不是不会连节点，而是卡在模型密钥、余额、网络或供应商配置上。
云版把这些前置问题暂时拿走了。
免费套餐也有明确边界：
| 项目 | Sandbox 边界 |
|---|---|
| 工作空间 | 1 个 |
| 用户 | 1 个 |
| 应用 | 最多 5 个 |
| 消息试用额度 | 200 条，一次性额度 |
| 知识库 | 最多 50 份文档、50MB 存储 |
| 日志 | 保留 30 天 |
| API 调用 | 每月 5000 次 |
这些额度足以完成本系列前期的大多数练习，但不适合把一个有真实流量的产品长期免费运行下去。
还要区分两个容易混淆的计数：消息试用额度针对平台提供的模型调用资源；每月 API 调用次数则针对外部程序调用 Dify 应用接口。它们不是同一件事，也不能相互替代。
当试用额度用完，你需要接入自己的模型 API Key，或者升级付费方案。套餐细节可能随官方策略变化，真正使用时应再看一眼 Dify 当前的定价页和文档。
但对于这篇文章的目标，结论很明确：
Sandbox 不是“只能看不能做”的演示账号，它足够让你零成本完成一次真实的应用发布。
登录以后，先认清 Studio
进入 cloud.dify.ai，可以直接使用 Google 或 GitHub 账号登录。
邮箱注册在部分情况下可能会卡在验证流程。如果你只是想尽快开始练习，优先使用 Google 或 GitHub 一键登录，通常更省事。
登录后首先看到的是工作空间。Sandbox 只允许 1 个工作空间和 1 个用户，因此这里不需要先研究复杂的组织管理。
进入 Studio，应用列表页就是你之后最常回来的地方。
这里的“应用”不是一个单独的 Prompt。
它是一组可以独立编辑、运行、记录日志并发布的配置。应用类型、节点结构、模型、Prompt、变量和发布入口，都归在这个边界里。
如果你以后同时做“合同摘要”“客服问答”和“销售邮件生成”，更合理的做法通常是创建三个应用，而不是把所有需求塞进一张无限膨胀的画布。
应用是 Dify 中最基本的交付单元。
点击“创建空白应用”后，先不要急着随便选一个类型。这里的选择，会决定应用怎样接收输入、如何执行以及最终怎样和用户交互。
五种应用类型，差别不只在名字
Dify 当前提供五种常见应用类型：Chatbot、Agent、Text Generator、Workflow 和 Chatflow。
它们都能调用大模型，但对“应用应该怎样运行”给出了不同答案。
Chatbot：快速搭一个基础对话机器人
Chatbot 是无代码的简化聊天应用。
你主要配置指令、变量、开场白和回答语气，不必先在画布上搭建完整流程。它能保留对话上下文，适合常规问答、简单客服和角色型助手。
它的优势是快。
如果需求只是“让模型按一段固定指令与用户聊天”，Chatbot 可以很快得到结果。但当应用开始加入检索、条件分支、数据处理或多个模型步骤时，简化界面能够表达的结构就有限了。
Agent：让模型自己决定下一步
Agent 同样是对话式应用，但它的重点不是聊天界面，而是自主决策。
模型可以根据目标拆解任务、推理，并在运行过程中选择工具。例如面对“查找某地未来三天的天气，再给出行李建议”，Agent 可以决定何时调用天气工具、怎样读取结果，再组织回答。
这种灵活性很有吸引力，也带来更高的不确定性。
当任务路径本来就很清楚时，预先定义好的工作流往往更容易测试、控制和排错。不要因为 Agent 听起来更“智能”，就把所有任务都交给它。
Text Generator：一次输入，生成一次文本
Text Generator 面向单轮文本生成。
它通常通过前缀提示词定义任务，适合文章改写、标题生成、摘要、分类和 Prompt 测试。用户提交一次输入，应用返回一次结果，没有天然的连续对话形态。
如果下一次输入不需要依赖上一次回答，Text Generator 的抽象很直接。
Workflow：从头到尾处理一次任务
Workflow 使用可视化画布和节点系统。
每次运行接收一组输入，从开始节点出发，按照你预先定义的路径执行，最后返回结果。它没有天然的对话层，适合自动化报告、数据处理、内容流水线和作为后端 API 的单轮任务。
判断它是否合适，可以问一个问题：这次运行结束后，下一次运行是否必须理解上一轮对话？
如果不需要，Workflow 往往更自然。
Chatflow：让每轮对话都经过一条流程
Chatflow 也使用可视化画布，但在 Workflow 之上加入了对话能力。
用户每发一条消息，都会触发一次预设流程。流程可以读取用户输入、调用模型、检索知识、经过分支，再由 Answer 节点直接回复用户。
Chatflow 还支持会话级自定义变量，也可以在 LLM 节点中开启 Memory，让模型使用对话历史。它能够以流式方式输出带格式的文字、图片和文件。
两者最重要的区别可以这样看：
| 对比项 | Workflow | Chatflow |
|---|---|---|
| 交互方式 | 提交一次任务，返回一次结果 | 用户每说一句，触发一轮流程并回复 |
| 对话上下文 | 没有天然的对话层 | 支持会话变量与模型记忆 |
| 常见收尾节点 | End | Answer（直接回复） |
| 典型场景 | 数据处理、报告生成、自动化管道 | 客服、知识问答、咨询助手 |
根据 Dify 官方文档，新项目应优先考虑 Workflow 或 Chatflow。它们使用新一代节点引擎，能够更完整地表达应用逻辑。
Chatbot、Agent 和 Text Generator 是基于同一套旧版引擎的简化界面，继续保留主要是为了兼容早期用户的使用习惯和快速创建需求。
这并不代表后三种完全不能用，而是提醒我们：如果准备认真学习 Dify 的编排能力，Workflow 和 Chatflow 更值得作为起点。
为什么第一个案例选择 Chatflow
我们的目标是：用户说出一个国家，应用回复它的首都。
这是明显的对话场景。用户通过聊天框输入，机器人通过聊天框回答，因此 Workflow 并不是最贴切的选择。
Chatbot 其实也能完成这个功能，而且操作更少。
但本系列的目标不是用最少点击做出一个聊天框，而是理解 Dify 怎样把输入、模型和输出组织成应用。
Chatflow 会把这三部分直接画在画布上。你能看到数据从哪里进入，在哪个节点变成模型输出，又由哪个节点发给用户。
这个结构虽然简单，却已经包含后续复杂应用的基本骨架。以后加知识库、条件分支、代码执行和工具调用，都是在这条骨架上继续扩展。
所以这一次选 Chatflow，不是因为案例必须用它，而是因为它最适合承担第一张“可运行的结构图”。
在创建弹窗中：
- 选择“创建空白应用”；
- 应用类型选择 Chatflow；
- 名称填写“国家信息小助手”；
- 图标和颜色可以按自己的偏好选择；
- 点击创建。
如果你想换一个主题，也可以做“水果营养小助手”或“城市介绍小助手”。只要交互仍然是“用户输入一个对象，模型用一句话回答”，后面的流程都可以照做。
创建完成后，Dify 会进入 Chatflow 编排页。
先读懂默认画布，再开始填写
新建 Chatflow 自带一条最小流程：
开始（Start）→ LLM → 直接回复（Answer）
这正好就是本次需要的全部节点，不必删除，也不用再添加节点。
Start：定义这一轮从哪里开始
Start 节点是流程入口。
在 Chatflow 中，用户在聊天框输入的消息会作为系统变量进入流程。后面的节点可以引用这份输入，而不需要自己再写一个网页表单或接口接收参数。
复杂应用还可以在 Start 中定义其他输入字段，例如产品类型、输出语言、文件或用户选择。但这次只需要用户的自然语言消息。
Start 本身不负责理解“法国”是什么意思。它的职责只是把输入可靠地交给后面的节点。
LLM：把输入和指令交给模型
LLM 节点是这条流程的处理核心。
它接收我们写好的 Prompt 和用户输入，调用选定的模型，再产生文本输出。
在本次实操中，模型选择 gpt-4o-mini。它足以完成“识别国家并回答首都”这种明确、短文本的任务，也能减少对试用额度的消耗压力。
如果你登录时看到的可用模型列表不同，不必执着于完全相同的选项。云版可用模型与套餐策略可能调整，选择当前可用的聊天模型即可。
真正需要保持一致的，是输入、Prompt 和输出之间的连接关系。
Answer：把结果真正回复给用户
中文界面中的“直接回复”，就是官方文档里的 Answer 节点。
LLM 节点生成了文字，并不等于用户已经收到了文字。Answer 节点需要引用 LLM 的输出变量，才会把结果显示在聊天界面中。
这一区分非常重要。
流程内部的“产生结果”和面向用户的“交付结果”是两步。以后一个 Chatflow 里可能有多个中间结果，但你未必希望全部展示给用户。
Answer 节点决定了这一轮对话最终说什么。
配置 LLM 节点：先确认模型能用
点击画布中的 LLM 节点，右侧会打开配置面板。
使用 LLM 节点有一个前提：工作空间里至少存在一个可用的模型供应商。通常可以在“集成（Integrations）→ 模型供应商（Model Provider）”中查看和配置。
如果是自建 Dify，这往往是必须先完成的一步。你需要选择供应商、填写 API Key，并确认部署环境能够访问对应模型服务。
但在官方云版 Sandbox 中，平台已经提供了试用模型额度。本次不需要自行配置 API Key，直接在 LLM 节点的模型选择器里选 gpt-4o-mini。
如果模型旁边显示不可用，先不要反复修改 Prompt。依次检查：
- 是否还有试用额度；
- 当前模型是否在工作空间中可用；
- 模型供应商页面是否提示需要授权或配置；
- 是否能改选另一个已有额度的聊天模型。
模型不可用是连接问题，Prompt 不理想才是内容问题。排错时先把两者分开。
Prompt 不只是“一段话”
Dify 的聊天模型 Prompt 通常分为 System、User 和 Assistant 三个区域。
它们不是三种不同模型，而是发送给同一个聊天模型的三类消息角色。
System：定义长期有效的行为规则
System 用来告诉模型，它在这个节点中扮演什么角色、要完成什么任务、遵守哪些边界、以什么格式输出。
我们这次填写：
你是一个国家小百科助手。用户会提到一个国家的名字，你需要用一句话说出这个国家的首都，语气亲切自然。
这段话很短，但包含了四个关键约束：
- 身份：国家小百科助手；
- 输入预期：用户会给出国家名；
- 任务：回答首都；
- 输出要求：一句话、亲切自然。
如果只写“回答用户问题”，模型的可发挥范围会大很多。它可能介绍国旗、人口、历史，也可能写成一整段。
Prompt 的作用不是让模型显得更聪明，而是缩小可接受答案的范围。
User：把本轮真实输入交给模型
User 区域用于组织用户在这一轮提供的内容。
这里通常会插入 Start 节点提供的用户输入变量。变量的写法是 {{变量名}}，但不建议靠记忆手敲名称。
在编辑器里输入 / 或 {，Dify 会弹出变量插入菜单。选择 Start 节点下对应的用户输入，编辑器会插入正确引用。
这样做的价值不只是少打几个字符。
变量引用建立了节点之间的数据依赖。以后 Start 字段、上游节点输出或变量名称变化时，编辑器也更容易提示问题。
如果默认模板已经替你插好了用户输入，不要重复添加。确认 User 区域中存在来自 Start 的输入即可。
Assistant：提供模型可以模仿的示例
Assistant 区域常用于少样本示例。
例如，你可以先给出一组 User 示例“日本”，再给出 Assistant 示例“日本的首都是东京。”，让模型更稳定地模仿回答格式。
本次任务足够简单，System 规则已经清楚，不需要额外示例。
示例并非越多越好。它们会占用上下文，也可能让模型过度贴近示例措辞。只有当输出格式不稳定、仅靠规则难以讲清时，再加入代表性的少量示例。
新手最容易填错的位置：描述框不是 Prompt
LLM 配置面板最上方有一个“添加描述...”输入框。
它和下面真正的 Prompt 编辑区域距离很近，外观看起来也像是可以填写指令，因此非常容易把 System 提示词粘贴到这里。
我们这次操作时就踩过这个坑。
“添加描述...”只是给节点写备注。它帮助你或协作者理解这个节点的用途，不会作为 System 消息发送给模型。
真正应该填写 Prompt 的，是下面标有 SYSTEM、placeholder 显示“在这里写你的提示词”的富文本编辑区。
这个区域在技术上是 contenteditable 富文本元素，不是普通的 <textarea>。如果你使用浏览器自动化、密码管理器或某些填表工具，它可能不会像普通输入框那样被正确识别。
最稳妥的判断方法不是看“能不能输入文字”，而是看三个信号：
- 输入位置是否位于 SYSTEM 区域；
- 空白时是否显示“在这里写你的提示词”；
- 填完以后，这段文字是否仍位于模型的 Prompt 配置中，而不是节点标题下方。
如果 Prompt 填错进描述框，流程未必会报错。
模型仍可能根据“法国”猜出你想问什么，也可能给出一段泛泛介绍。这类错误最难发现，因为节点能运行，只是行为不受你写下的规则控制。
所以配置完成后，不要只检查“文字有没有保存”，还要检查“文字保存在哪一层”。
把 LLM 输出接到直接回复
默认模板通常已经把 Start、LLM 和直接回复连好，但节点连线只表示执行顺序，不等于 Answer 已经引用正确内容。
点击“直接回复”节点，检查它的回复内容。
这里应该插入 LLM 节点的文本输出变量。不同界面版本可能把它显示为类似 LLM / text 的变量标签，而不是一段手写文本。
如果回复框是空的，可以输入 / 或 { 打开变量菜单：
- 选择上游的 LLM 节点；
- 选择它的文本输出；
- 确认回复框出现变量标签；
- 保存或离开节点后，再回来检查一次。
不要把字面量“LLM 输出”四个字写进回复框。那只会让机器人每次都回复同一句固定文字。
变量的意义，是把上一节点本次运行产生的值传给下一节点。
到这里，整条数据链已经闭合：
| 阶段 | 数据是什么 | 由谁负责 |
|---|---|---|
| 输入 | “法国” | Start 接收 |
| 处理 | System 规则 + 用户输入 | LLM 调用模型 |
| 中间结果 | “法国的首都是巴黎。” | LLM 文本输出 |
| 展示 | 将中间结果发进聊天窗口 | Answer 直接回复 |
这张表比记住按钮位置更重要。以后界面换版，只要还能识别输入、处理、输出三个阶段，你就不会迷路。
这个 LLM 节点，远不止会写一句回答
目前我们只用了 LLM 节点最基础的能力：选择模型、写 System Prompt、插入用户变量、返回文本。
但根据 Dify 官方文档，LLM 节点还可以承担更复杂的工作：
- 接收知识库检索结果作为上下文变量，组成 RAG 链路；
- 通过 JSON Schema 定义结构化输出，供下游节点稳定读取；
- 使用 Jinja2 模板处理循环、条件和复杂变量组织；
- 接收图片或文件等多模态输入；
- 以流式方式输出结果，降低用户等待时的停顿感；
- 设置失败重试和兜底策略，避免一次模型异常让整条流程直接中断。
这些能力暂时不需要逐项打开。
第一次练习如果同时加入知识库、结构化输出和分支，任何一处出错都会让排查变得困难。先让最小链路运行，再一次只增加一个变量，才是更可靠的学习方法。
但知道能力边界仍然有意义。
今天的“国家信息小助手”不是一条只能回答首都的特殊流程，而是一条可以逐步生长的骨架。以后加入知识检索，它可以只根据指定资料回答；加入结构化输出，它可以把国家、首都和洲别交给下游系统；加入条件分支，它可以处理无法识别的输入。
我们现在用的是能力表面最小的一块，背后却已经是完整的节点引擎。
预览不是看看效果，而是验证数据链
配置完成后，先不要发布。
打开右侧预览面板，在聊天框输入：
法国
本次实操中，机器人正确回复：
法国的首都是巴黎哦！
看到正确答案当然很好，但更重要的是知道这次测试证明了什么：
- Start 成功接收了用户输入；
- User 区域正确引用了输入变量；
- 模型当前可用；
- System Prompt 实际进入了模型上下文；
- LLM 成功产生文本输出；
- Answer 引用了正确的上游变量。
一次成功不能证明应用已经足够稳健，但可以证明最小链路已经连通。
接下来至少再试几类输入：
- 常见国家，例如“日本”；
- 带问句的表达，例如“德国的首都是什么？”；
- 与任务无关的输入，例如“今天天气怎么样？”；
- 含糊或错误的国家名。
后两类尤其重要。
当前 Prompt 只说明了正常任务，没有规定遇到无关输入和无法识别内容时怎样回答。模型可能自行发挥。对于学习案例可以先接受，但如果准备公开给真实用户，就应该补上边界，例如“如果输入不是明确的国家名称，请提示用户重新输入，不要猜测”。
这就是调试的意义：不是不断问模型你已经知道答案的问题，而是寻找应用规则没有覆盖的地方。
如果预览没有得到预期结果，可以按数据流从前往后排查：
- Start 是否真的收到了本轮消息；
- LLM 的 User 区域是否引用了 Start 输入；
- System Prompt 是否填在正确区域；
- 模型是否可用、额度是否充足；
- Answer 是否引用了 LLM 的文本输出。
不要一遇到异常就重建应用。沿节点逐段检查，正是可视化编排最大的价值之一。
点击发布，应用才从草稿变成交付物
预览通过后，点击页面右上方的“发布（Publish）”。
发布的含义，不只是保存。
编辑画布时，你在修改工作空间里的最新编排；点击发布后，Dify 会基于当前最新配置生成可供使用的 Web App 和 API 端点。
换句话说，编辑解决“应用应该怎样运行”，发布解决“别人怎样使用这次确定下来的版本”。
本次真实操作到这里完成：我们创建了“国家信息小助手”，使用默认的 Start → LLM → 直接回复结构，选择 gpt-4o-mini，写入 System Prompt，在预览中得到“法国的首都是巴黎哦！”，随后成功发布。
这是一条很短的流程，但它已经不是 Demo 截图，而是一个有入口、有运行逻辑、有测试结果、有发布状态的 Dify 应用。
发布以后，你实际拿到了什么
很多人发布后只打开 Web App 看一眼，就以为 Dify 的交付方式只有“分享一个聊天网页”。
实际上，同一套应用逻辑可以通过多种方式进入外部世界。
1. Web App：直接把链接交给用户
Dify 会为已发布应用提供一个现成的 Web App。
它适合内部试用、需求验证、演示和小范围分享。你不需要另外开发前端，用户打开链接就可以开始对话。
但“生成了链接”不等于“互联网上任何人立刻都能访问”。
根据 Dify 官方文档，新发布的 App 默认只向工作空间内部成员开放。谁可以访问 Web App，以及谁可以创建和发布 Web App，是分开管理的权限。
Workspace Owner、Admin 和 Editor 才能创建和发布 Web App。真正分享前，需要进入访问控制设置，按当前需求开放合适范围。
权限默认收紧是合理的。应用可能包含内部 Prompt、知识库和业务数据，发布动作不应该自动等于公开到互联网。
2. API：把 Dify 变成程序后端
发布后也会得到 API 端点。
外部网站、移动 App、企业系统或自动化脚本可以携带 API Key 调用应用，而不必使用 Dify 自带界面。
这时 Dify 扮演的是 AI 后端：
- 前端负责产品体验和用户身份；
- Dify 负责执行 Chatflow；
- 模型、Prompt 和节点变化可以继续在 Dify 中维护；
- 外部程序只按接口提交输入并接收结果。
API Key 属于服务凭证，不应直接写进公开网页的前端 JavaScript，也不应提交到公开仓库。生产使用时，应由自己的后端安全保存并代理调用。
Sandbox 每月 5000 次 API 调用的边界，也是在这类接入中需要关注的。
3. Embed：把聊天入口嵌进现有网站
如果已经有网站，又不想从头开发聊天界面，可以使用 Dify 的嵌入方式。
官方提供 iframe 标签、script 标签以及 Dify 官方 Chrome 插件等接入选择，展示形态可以是聊天气泡，也可以是页面内嵌区域。
iframe 更像把一个完整页面嵌入当前页面，接入直观；script 方式更适合把聊天入口挂在网站界面上。选择哪种方式，取决于现有页面结构、样式控制和安全要求。
真正上线前还应检查移动端布局、访问权限、跨域策略、隐私提示和用户输入是否可能包含敏感信息。
“复制一段代码能显示”只是接入成功，不能替代产品和安全检查。
4. MCP：让应用成为其他 Agent 可调用的工具
Dify 还支持把应用发布为 MCP 兼容工具，供其他 Agent 或支持 MCP 的客户端调用。
这次不展开配置，但它说明了一件事：Dify 应用的终点不一定是一个聊天页面。
一条已经编排好的能力，可以被人直接使用，也可以成为更大智能体系统里的一个工具。
四种方式可以用一张表概括：
| 分发方式 | 谁来使用 | 适合什么阶段 |
|---|---|---|
| Web App | 直接面对人 | 试用、演示、内部工具、快速上线 |
| API | 自己的程序或后端 | 正式产品集成、自定义界面与业务逻辑 |
| Embed | 现有网站的访客 | 快速增加聊天气泡或内嵌助手 |
| MCP | 其他 Agent 或 MCP 客户端 | 把 Dify 应用封装成可复用工具 |
发布不是流程的终点，而是应用第一次获得交付形态。
一次最小案例，真正应该学会什么
回看整个过程，我们只写了一段 Prompt，也没有添加任何新节点。
如果按点击次数评价，这个案例甚至有些过于简单。
但第一课真正要建立的不是“我会找到 LLM 节点”，而是五个更稳定的认识。
第一，先根据交互模型选择应用类型。
单轮任务优先考虑 Workflow，对话任务优先考虑 Chatflow，需要模型自主选择工具时再认真评估 Agent。不要把应用类型当作随便换皮的模板。
第二，节点同时表达执行顺序和数据依赖。
Start、LLM、Answer 连在一起，只说明谁先运行；变量引用才说明数据具体从哪里来、交给谁。
第三，Prompt 有角色和层次。
System 负责规则，User 承载本轮输入，Assistant 可以提供示例。把所有内容混成一段，简单时能跑，复杂后很难维护。
第四，预览是在验证链路。
正确答案只是结果。真正可复用的排错方法，是从 Start 开始，沿着变量、模型和 Answer 一段一段检查。
第五，发布意味着权限和交付。
Web App、API、Embed 和 MCP 面向不同使用者。一个应用能在预览里回答，不代表它已经具备合适的访问控制、安全策略和产品体验。
这五点，才是从“试了一下 Dify”走向“开始理解 Dify”的分界线。
下一步：在这条骨架上增加真实复杂度
这一篇完成的是最小可行案例。
它没有知识库，没有条件分支，没有工具调用，没有代码节点，也没有认真处理异常输入。模型知道巴黎，不代表我们已经做出了可靠的国家知识产品。
但最小不等于草率。
我们已经完成一次从创建到发布的真实闭环，也看清了 Dify 应用最基本的数据路径：输入进入节点，变量连接节点，模型产生中间结果，Answer 面向用户交付。
接下来的文章会从这条骨架继续向里走：逐步拆开具体应用类型和核心概念，引入更复杂的节点，并开始处理“能运行”之外的可靠性问题。
当流程变长时，你会发现，真正困难的从来不是把节点拖上画布。
困难的是决定每一步该由模型判断，还是由确定规则控制；哪些信息应该进入上下文，哪些结果应该暴露给用户；一次失败应该重试、降级，还是明确停止。
而这些判断，都建立在今天这条最简单的链路上。
第一个应用的价值，不在于它回答了巴黎，而在于你已经知道一句用户输入怎样穿过 Dify，最终变成一个可以交付的回答。