Dify：让 LLM 应用开发回归业务逻辑

共计 2712 个字符，预计需要花费 7 分钟才能阅读完成。

最近一直在折腾各种 LLM (Large Language Model) 应用开发工具。从最初硬写 OpenAI API，到后来即便用上了 [[LangChain]]，也总觉得差点意思——代码写得倒是很欢，但真要弄成一个不仅自己能用，还能给朋友、同事甚至客户用的"产品"，中间还隔着十万八千里。

比如，怎么管理那一堆 Prompt 版本？知识库 RAG 的切片和检索效果怎么调优？后端 API 怎么暴露？前端界面难道还要自己从头撸一个？

直到我深度体验了 Dify (dify.ai)。说实话，刚开始看到它打出 "The Innovation Engine for GenAI Applications" 的 Slogan 时，我是持保留态度的。但当我在本地用 Docker 把它跑起来，并且在 10 分钟内搭出了一个带完整 RAG 能力、支持混合检索、甚至还能调用 Google 搜索工具的智能助手后，我被说服了。

今天想聊聊，为什么我觉得 Dify 可能是目前最懂开发者的 LLM 应用编排平台。

什么是 Dify？

简单来说，Dify 是一个开源的 LLM 应用开发平台。它的名字来源于 "Define" 和 "Modify"，寓意你可以不断定义和修正你的 AI 应用。现在的 AI 技术栈里，底层是各种大模型（GPT-4, Claude 3, Llama 3），中间层有 LangChain 这样的框架。但 Dify 并没有把自己定位成另一个 LangChain，而是站在了更高的位置——BaaS (Backend as a Service)。

它把模型管理、知识库（RAG）、工作流编排、Prompt 调试、API 发布甚至前端界面都打包在了一起。你不再需要去写 Python 脚本来切分 PDF，也不用担心怎么把向量存进 Milvus 或 Weaviate，Dify 把这些"脏活累活"都干了。

如果说 LangChain 是给造轮子的人用的零件箱，那 Dify 就是给造车人用的流水线。

为什么它值得关注？

"所见即所得"的 Prompt IDE

在 Dify 里调试 Prompt 是一种享受。左边写 Prompt，右边直接预览对话效果。它甚至支持在一个界面里同时对比 GPT-3.5 和 GPT-4 对同一个 Prompt 的输出区别。这种对比调试的能力，对于追求性价比的开发者来说非常实用。

把 RAG 做成了"白以此"

做过 RAG 的人都知道，文本切分（Chunking）和清洗是多大的坑。Dify 内置的知识库管理非常成熟：

自动分段与清洗：上传 PDF/Markdown，它自动处理空行、乱码。
混合检索 (Hybrid Search)：这是我最喜欢的功能。它能同时利用向量检索（语义匹配）和关键词检索（精确匹配），再通过 Rerank 模型（重排序）来优化结果。在实际测试中，加上 Rerank 后，知识库问答的准确率有肉眼可见的提升。

工作流 (Workflow) 才是杀手锏

早期的 Dify 主要是简单的对话应用，但新推出的 Workflow 功能才是真正的"大杀器"。它引入了类似编程的逻辑：

条件分支：如果用户问天气，走天气查询分支；如果问代码，走代码生成分支。
代码执行：直接在流程里写 Python/JavaScript 代码处理数据。
HTTP 请求：轻松调用外部 API。

这让它不再只是一个"聊天机器人生成器"，而是一个真正的业务逻辑编排引擎。

实践经验：搭建一个"全能"个人助理

光说不练假把式。分享一下我是如何在本地部署并搭建一个个人助理的。

本地部署 (Self-hosted)

官方推荐使用 Docker Compose 部署，非常简单。

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d

启动后，访问 http://localhost:3000 就能看到界面了。

如果你需要修改默认端口，可以编辑 .env 文件，找到以下变量（通常在文件末尾附近）并修改为你想要的端口：

EXPOSE_NGINX_PORT: HTTP 服务对外暴露的端口（默认是 80）。
EXPOSE_NGINX_SSL_PORT: HTTPS 服务对外暴露的端口（默认是 443）。

小提示：在 .env 文件里，你可以配置 PostgreSQL 的参数，或者开启一些高级功能。如果是生产环境，记得改掉默认的密码。

接入模型

进入设置，Dify 支持的模型非常全。除了 OpenAI、Anthropic，它对本地模型（通过 Ollama 或 LocalAI）的支持也很好。

我目前的配置是：

主力推理：Claude 3.5 Sonnet (逻辑强)
日常对话：GPT-4o mini (速度快，便宜)
Embedding：text-embedding-3-small
Rerank：Cohere (这对 RAG 效果至关重要，建议去申请一个 API key)

搭建工作流

我创建了一个 "Chatflow" 类型的应用。

意图识别：首先加一个 LLM 节点，专门用来判断用户的意图（是闲聊、查文档、还是写代码）。
工具调用：如果是查资料，我接入了 Tavily Search 工具（Dify 内置支持），它比 Google Search 更适合 AI 读取。
知识库检索：如果是问我的个人笔记，直接路由到"知识库检索"节点，开启 Rerank。
代码执行：为了好玩，我加了一个 Python 节点，每天早上让它读取当天的日期，并根据星期几给我生成不同的问候语。

整个过程不需要写一行后端代码，连线、配置、调试，一气呵成。

几个避坑指南

在使用过程中，也踩过一些坑，分享给大家：

RAG 的召回问题：如果发现知识库总是答非所问，首先检查切片（Chunk）设置。对于中文文档，默认的 500 字符可能太长，建议尝试 300-400，并适当增加重叠（Overlap）。另外，一定要开 Rerank，效果天差地别。
API Key 的额度：Dify 会高频调用 LLM，特别是在调试 Workflow 时。务必监控好你的 Token 用量。
本地部署的资源：如果你在本地跑 Dify 还要跑 Ollama，8G 内存的电脑会非常吃力。Dify 的中间件（Redis, Postgres, Weaviate/Qdrant, Sandbox）本身就会占用 2-3G 内存。

最后

Dify 给我最大的感觉是"克制"与"开放"的平衡。它克制在没有把界面做得花里胡哨，每一个功能（如 API 自动生成、日志监控）都切中开发者在生产环境的痛点；它开放于极其丰富的插件生态和模型支持。对于不懂代码的产品经理，它是一个好用的原型工具；对于开发者，它是一个节省了 80% 重复劳动的中间件平台。
如果你也想拥有一个完全属于自己的、数据隐私可控的 AI 应用，不妨试试 Dify。在这个 AI 甚至能帮我们写代码的时代，也许我们要学的，是如何更好地去"编排"它们。