Dify 本地部署实战：把 Ollama 变成能编排、能发 API 的 AI 应用工厂

之前写过 AnythingLLM 搭 RAG 知识库，写过 n8n 接自动化工作流，也写过 Ollama 跑本地模型。三篇文章看下来你可能有个疑问：这三件事能不能串起来，做成一个能对外发 API、能拖拽编排、能带知识库和 Agent 的”AI 应用工厂”？答案能，中间那层胶水，今天的主角——Dify。

一、Dify 到底是什么？和你已经会的那些有啥区别

先给结论：Dify 是一个开源的 LLM 应用编排平台，它把模型管理、知识库、工作流、Agent、API 发布这五件事塞进了一个 Web 界面里。说人话就是——你不用再写一堆胶水代码，在网页上拖拖拽拽，就能把”模型 + 文档 + 逻辑”拼成一个能上线、能被别人调用的东西。

为了说清楚它的定位，我把你之前折腾过的几个家伙摆一起对比一下：

• Ollama：只负责”算”。它是推理引擎，把模型跑起来吐字，不管界面、不管业务。
• Open WebUI：只负责”聊”。它是聊天界面，长得像 ChatGPT，但做不了复杂业务。
• AnythingLLM：轻量 RAG。上传文档、向量化、问答，够用但编排能力弱。
• n8n：通用自动化。能把各种服务串起来，但它是”通用”的，不是为 LLM 量身定做的。
• Dify：AI 原生的中间层。上面这些它都能接，然后输出成一个标准 REST API 或 Web 应用。

一句话总结：Dify 不抢 Ollama 的活，也不抢 n8n 的活，它是站在中间，把”算力 + 知识 + 流程”编排成一个产品的那个人。

二、环境准备与硬件要求

Dify 官方用 Docker Compose 部署，对环境要求不算高，但有几个硬指标得先摸清楚：

• Docker 24+ 和 Docker Compose v2（`docker compose` 带空格的那种）。
• 内存：最低 8GB，建议 16GB 起。别被吓到，Dify 全家桶里跑着 api、worker、web、postgres、redis、向量库、sandbox 一堆容器，吃内存是常态。
• Ollama 得先跑着：Dify 自己不推理，它是调 Ollama 的，所以你得先有个在跑的 Ollama 服务。

如果你之前已经按我的文章把 Ollama 起在宿主机上，那这步可以跳过，直接进入部署。

三、部署步骤

先克隆仓库，进到 docker 目录，复制一份环境变量模板：

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

这里有个坑：Dify 默认用 80 和 443 端口跑它的 nginx。如果你机器上已经跑了 Caddy 或 Nginx，端口会冲突。两种解决办法——要么改 `.env` 里的端口，要么用你现有的反代去转发。图省事的话，先在 `.env` 里把 HTTP 端口改掉：

# 找到这一行，改成你想要的端口，比如 8088
EXPOSE_NGINX_PORT=8088

改完直接拉起全家桶：

docker compose up -d

等容器起完，浏览器访问 http://你的服务器IP:8088/install，第一次会引导你创建管理员账号。设完账号就能进后台了。

四、接入 Ollama 本地模型（最容易翻车的一步）

Dify 的模型供应商里自带 Ollama，但难点不在配置，而在容器网络互通。Dify 跑在容器里，Ollama 跑在宿主机上，容器里怎么找到宿主机？

最省事、最不容易出错的方案：直接用宿主机的局域网 IP。假设你宿主机是 192.168.1.100，Ollama 默认监听 11434 端口，那 Base URL 就填 http://192.168.1.100:11434，啥额外配置都不用加。

进入 设置 → 模型供应商 → Ollama，点”添加模型”，关键的三栏这么填：

• 模型名称：填 Ollama 里已经拉好的模型名，比如 qwen2.5:14b（名称要和你 `ollama list` 里看到的一模一样）。
• 基础 URL：http://192.168.1.100:11434。
• 模型类型：选 LLM。

除了对话模型，你还要再拉一个 embedding 模型，因为知识库向量化靠它。中文场景我强烈建议用 bge-m3，别拿英文的 nomic 硬上中文，召回效果差得不是一点半点：

ollama pull bge-m3

拉完后，回到 Ollama 供应商里再添加一个模型，这次类型选 Text Embedding，名称填 bge-m3。至此，算力这条线就通了。

五、实战一：五分钟建一个带知识库的问答机器人

先建知识库：左侧菜单 知识库 → 创建知识库，上传你的 PDF / Markdown / TXT 文档，Dify 会自动分段、向量化、建索引。分段策略别急着调，先用默认的”自动”跑通，后面再按需精调。

然后 创建应用 → 聊天助手（Chatbot），起个名字，把刚才的知识库勾上，模型选 qwen2.5:14b。右上角点”发布”，一个能回答”你的文档里写了啥”的机器人就上线了，回答还会带引用来源，能溯源到具体段落，这点比裸聊强太多。

六、实战二：用工作流让 AI 学会”分诊”

Dify 的杀手锏是可视化工作流。举个最经典的场景：用户一个问题进来，先让模型判断它是”技术问题”还是”售后问题”，再路由到不同的处理分支。在 创建应用 → 工作流 里，拖这几个节点就能搭出来：

• 开始：接收用户输入。
• LLM 节点：写一句提示词”判断以下问题属于技术类还是售后类，只输出这两个词之一”。
• 条件分支：根据上一个节点的输出，走 A 或 B。
• 两个 LLM 节点：分别处理技术类和售后类，各自带不同的系统提示词。
• 结束：输出最终答案。

整个过程不用写代码，搭完点”运行”就能在调试窗口里测试。这套”意图识别 + 分支路由”的玩法，就是我之前用 n8n 要绕半天才能实现的效果，Dify 里拖一下就成。

七、实战三：发布成 API，一行 curl 调起来

这才是 Dify 对我最大的意义——它能把任何一个应用一键变成标准 REST API，你的其它程序、脚本、甚至另一个服务都能直接调。进应用页，找到 API 访问，生成一个 API Key，然后：

curl -X POST 'http://192.168.1.100:8088/v1/chat-messages' \
  -H 'Authorization: Bearer app-你的API密钥' \
  -H 'Content-Type: application/json' \
  --data-raw '{
    "inputs": {},
    "query": "我们公司退款流程是怎么规定的？",
    "response_mode": "blocking",
    "conversation_id": "",
    "user": "it-dashu"
  }'

response_mode 填 blocking 是等它一次性返回，填 streaming 就是流式输出，适合接前端做打字机效果。配合我之前写的 Ollama REST API 那篇，你的本地 AI 已经能从”自己玩”进化到”给全家桶当后端”了。

八、踩过的坑，提前帮你填了

• Ollama 连不上：九成是容器网络问题。别死磕 host.docker.internal（Linux 下默认不认），直接用宿主机局域网 IP，最稳。
• 内存爆炸：如果机器内存紧张，可以把 sandbox（代码沙箱）关掉，或者只保留一个 worker 副本，能省下 1-2GB。
• embedding 选错：中文资料用 bge-m3，别用英文模型硬上，否则检索出来一堆不相关的东西。
• 端口冲突：80/443 被占是常态，提前改 EXPOSE_NGINX_PORT，或者用 Caddy/Nginx 反代。
• 数据安全：你的应用、知识库、配置全在 docker volume 里。要备份就备份整个 dify 目录和它的 volumes，别只备份个 `.env` 就以为万事大吉。

九、写在最后

Dify 适合谁？适合那些想在本地把 AI 真正做成工具、做成产品，又不想陷进胶水代码里的人。你把 Ollama 的算力、知识库的检索、工作流的逻辑交给它，它给你一个能对外服务的 API。

下一步我会聊聊怎么把 Dify 和之前写的 LiteLLM 串起来做多模型路由——本地 Ollama 和云端 API 自动切换、按成本分流，让这套”应用工厂”更抗造。老规矩，折腾中遇到坑，欢迎留言，咱们一起填。