Dify 可视化编排

说实话，大多数人第一次听到"AI 工作流编排"这个概念，脑子里想的是写 Python、调 API、搞 prompt engineering。但 Dify 做了一件事：把这些全变成拖拽。你不需要写一行代码，就能搭出一个能跑的 AI 应用。

听起来像 magic？做过几个真实 workflow 之后你就知道了——它更像搭乐高。每块积木（node）有固定功能，你要做的是想清楚怎么连。

---

Dify 是什么

一句话解释：Dify 是一个开源的 LLMOps 平台，让你用可视化拖拽的方式搭建 AI 应用，而不是写代码。

生活类比：如果你用过 Zapier 或 Make.com 做自动化——Dify 就是 AI 版的 Zapier。Zapier 连接的是 SaaS 工具（Gmail → Slack → Google Sheets），Dify 连接的是 AI 模型和数据源（用户提问 → 知识库检索 → LLM 生成 → 格式化输出）。

工作中怎么用：产品经理想快速验证"给客服加个 AI 助手"的想法，不用等开发排期，自己拖拽搭一个，接上公司的 FAQ 文档，半天搞定 demo。

最常踩的坑：以为 Dify 能替代所有后端开发。它处理 AI 相关的逻辑很强，但复杂的业务逻辑（比如多步审批、权限管理、数据库事务）不是它的强项。我们团队有人用 Dify 做了一个"智能审批系统"，搞到最后发现 80% 的时间在写 HTTP Request node 调外部 API，还不如直接写代码。

---

自建 vs 云端：选哪个

直接给结论：

我的建议：先用 Cloud 版学会搭 workflow，确认真的要上生产了再 self-host。很多人一上来就折腾 Docker 部署，结果连 Dify 的基本概念都没搞清楚。

热知识：Dify 的 self-hosted 版本更新非常频繁，几乎每两周一个版本。v0.6 到 v0.7 的时候改了数据库结构，不少人升级后 workflow 直接挂了。所以 self-host 的话，一定要做数据库备份再升级。

---

核心概念：四个你必须懂的东西

1. Workflow（工作流）

就是一条从输入到输出的处理链。用户给一个输入，经过一系列 node 处理，最后输出结果。

两种类型：

• Chatflow：对话式，适合客服机器人、问答助手。有上下文记忆，支持多轮对话。
• Workflow：单次执行，适合批处理任务。输入 → 处理 → 输出，没有对话历史。

说实话，90% 的场景用 Chatflow 就够了。只有批量处理（比如"把这 100 篇文章全部翻译一遍"）才需要 Workflow 模式。

2. Knowledge Base（知识库）

你上传文档（PDF、Word、网页、Notion），Dify 帮你切片、向量化，存进向量数据库。然后 LLM 回答问题的时候可以检索这些文档。

这就是大家说的 RAG（Retrieval-Augmented Generation）。

关键参数：chunk size

这是我们踩过最多的坑。Chunk size 决定了文档被切成多大的片段：

我们遇到过一个真实 case：给客服机器人喂了 200 页的产品手册，用默认的 chunk size（1000 字），结果用户问"退款政策是什么"，AI 返回的是一大段包含退款信息但也夹杂了配送信息的内容。改成 300 字的 chunk size 后，回答精准多了。

3. Tools（工具）

Dify 内置了一些工具（Google 搜索、天气查询、计算器），你也可以通过 OpenAPI schema 接入自己的 API。

这玩意的价值是让 AI 不只是"聊天"，而是能"做事"。比如用户说"帮我查一下北京今天的天气"，AI 调用天气 API，拿到数据，再用自然语言回复。

4. Variables（变量）

Workflow 里 node 之间传递数据靠变量。上一个 node 的输出可以作为下一个 node 的输入。

写法是 {{node_name.output}}，很像模板引擎。搞过前端的人应该很熟悉。

踩坑提醒：变量名是大小写敏感的，{{LLM.output}} 和 {{llm.output}} 不是一回事。我在这上面浪费过 2 小时 debug 时间。

---

Node 类型速查

Dify 的 workflow 由各种 node 组成，每种 node 干一件事：

---

实战：搭一个 PDF 摘要 + 邮件通知的 Workflow

这是一个真实的业务场景：团队每天收到大量供应商发来的 PDF 报告，需要有人看完写摘要，再邮件通知相关同事。

流程设计

Start (上传 PDF URL)
  → HTTP Request (下载 PDF 内容)
  → Code (提取文本)
  → LLM (生成摘要)
  → IF/ELSE (摘要是否包含紧急关键词)
  → HTTP Request (发邮件通知)
  → End (返回摘要)

Step 1：Start Node

添加一个 file_url 输入变量，类型为 String。

Step 2：HTTP Request 下载 PDF

• Method: GET
• URL: {{start.file_url}}
• 这一步拿到 PDF 的原始内容

Step 3：Code Node 提取文本

def main(inputs):
    # Dify 的 Code node 支持简单的 Python
    raw_content = inputs["http_response"]
    # 实际场景中你可能需要 PDF parsing
    # 这里简化处理
    return {"text": raw_content[:5000]}

Step 4：LLM 生成摘要

Prompt 设计：

你是一个专业的商业分析师。请阅读以下文档内容，生成一份简洁的中文摘要。

要求：
1. 控制在 200 字以内
2. 提取关键数据点和结论
3. 标注是否有紧急事项需要关注

文档内容：
{{code.text}}

Model 选择：这种摘要任务用 GPT-4o-mini 或 Claude 3.5 Haiku 就够了，不需要上最贵的模型。

Step 5：IF/ELSE 判断紧急程度

条件：{{llm.output}} contains "紧急"

• 如果是 → 走紧急通知路径（发邮件 + Slack）
• 如果否 → 走普通路径（只记录）

Step 6：HTTP Request 发邮件

通过 webhook 或邮件 API（比如 SendGrid、Resend）发送通知。

这个 workflow 搭完大概 15 分钟。如果写代码实现同样的功能，加上错误处理和部署，至少半天。

---

Dify vs Coze vs n8n：到底选哪个

这是大家最关心的问题，我直接给对比表：

直接给结论：

• 你要搭 AI 应用（客服、问答、内容生成）→ 选 Dify
• 你要快速做一个能发布到多平台的 Bot → 选 Coze
• 你要做复杂的跨系统自动化，AI 只是其中一环 → 选 n8n
• 你的数据不能出境 → 选 Dify self-host

---

定价：别被"免费"骗了

热知识：Sandbox 的 200 条/天包括你自己测试的消息。开发阶段反复调试，一天 200 条根本不够用。我试过一个下午就把额度用完了，后面只能干等第二天。

Self-hosted 看起来是免费的，但别忘了你要付：

• 服务器费用（最低 2C4G，约 $20/月）
• LLM API 费用（这才是大头）
• 向量数据库存储（文档多了之后会很大）

---

版本管理的痛

Dify 目前（2025 年底）的版本迭代速度属于"激进"级别。v0.6 → v0.7 → v0.8 → v0.9，几乎每个大版本都有 breaking change。

我们遇到过的版本灾难：

1. v0.6 → v0.7：Workflow 的变量引用语法变了，所有 {{#node_id.output#}} 要改成 {{node_id.output}}。几十个 workflow 手动改。
2. v0.8 的知识库：引入了新的 embedding 模型切换功能，但升级后旧的 embedding 索引不兼容，需要重新索引所有文档。
3. Docker image tag：有段时间 latest tag 直接指向 nightly build，不是稳定版。生产环境用 latest 的人直接哭了。

最省事的做法：

• Self-hosted 锁定具体版本号，不用 latest
• 每次升级前看 GitHub Release Notes 的 Breaking Changes 部分
• 生产环境升级前先在 staging 跑一遍

---

常见错误和解决方案

---

从 Workflow 到 API：一键变成接口

Dify 搭好的 workflow 可以直接生成 API endpoint。在应用设置页面找到 API Access，你会拿到：

• Base URL
• API Key
• Curl 示例

curl -X POST 'https://api.dify.ai/v1/workflows/run' \
  -H 'Authorization: Bearer app-xxxxxxxxxxxx' \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {
      "file_url": "https://example.com/report.pdf"
    },
    "response_mode": "blocking",
    "user": "user-123"
  }'

response_mode 有两种：

• blocking：等 workflow 跑完再返回（适合短任务）
• streaming：边跑边返回（适合生成长文本）

这意味着你在 Dify 里搭的任何 workflow，都能被其他系统调用。前端应用、微信机器人、企业内部系统——只要能发 HTTP 请求就行。

---

什么时候不该用 Dify

说实话，Dify 不是银弹。以下场景建议直接写代码：

1. 需要复杂的状态管理：多步骤审批、需要回退和重试的流程
2. 高并发场景：每秒几百个请求，Dify 的性能不够
3. 深度定制 UI：Dify 自带的 WebApp 界面很基础，想做好看的前端还是得自己写
4. 模型微调相关：Dify 支持调用微调后的模型，但微调本身还是得用其他工具

但如果你的需求是"连接 LLM + 知识库 + 简单逻辑 + 快速上线"，Dify 是目前最省事的选择。特别是对于非全职开发者——产品经理、运营、创业者——Dify 把 AI 应用开发的门槛降到了"会用 Excel 就能搭"的程度。

先跑起来，再优化。这才是 AI Builder 的正确姿势。