post cover

技术热点落地：Dify + Ollama 搭建私有 AI 工作流平台（2026-05-16）

适用场景与目标

谁适合用这套方案？

  • 已有 Ollama 环境，想从”单点 AI 对话”升级为”可复用的 AI 应用”（昨天方案的延伸）
  • 需要为团队或企业内部构建 AI 能力平台（客服机器人、合同审查、数据提取等）
  • 对接内部知识库 CRM/OA 系统，需要私有化部署
  • 想控制 AI 应用成本，不被云端 API 按 Token 计费持续吸血

核心目标：

通过 Dify（开源 LLM 应用开发平台）+ Ollama，构建一套：

  • 拖拽式 AI 工作流编排：无需写代码即可串联 Prompt、变量、函数、API
  • 完全私有化部署：所有数据不出本地网络
  • 多模型统一接入：同时接入 Ollama 本地模型 + 可选云端模型作为补充
  • API 对外服务：一键将工作流发布为 REST API，供其他系统调用
  • 零额外成本：基于已有 Ollama，无需额外支付模型调用费

最小可行方案（MVP）步骤

第一步：理解工具定位

工具职责特点
Ollama本地大模型推理引擎提供 LLM API（昨天已部署）
DifyAI 应用编排平台拖拽工作流、Prompt 管理、API 发布

Dify 相当于 AI 应用的”低代码平台”，Ollama 负责底层推理。

第二步：安装 Dify（Docker 方式，15 分钟）

Dify 支持 Docker 一键部署，与 Ollama 无缝集成。

# 克隆 Dify 源码
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 复制环境配置
cp .env.example .env

# 启动所有服务（包含 PostgreSQL、Redis、Nginx 等）
docker-compose up -d

注意：如果机器内存小于 8GB，先编辑 .env 调低各服务资源限制：

# 在 .env 中添加或修改
WORKER_TIMEOUT=300
DB_CONNECTION_TIMEOUT=60

验证安装： 浏览器访问 http://<服务器IP>:80，看到 Dify 登录页即成功。

首次使用需要创建管理员账号。

第三步：在 Dify 中接入 Ollama

  1. 进入 Dify → 设置（Settings） → 模型供应商（Model Providers）
  2. 找到 Ollama，点击添加模型
  3. 填写连接信息：
Base URL: http://<Ollama服务器>:11434
模型名称（Model Name）: qwen2.5:7b  （或你本地已拉取的模型）

💡 如果 Dify 和 Ollama 在同一台机器，填写 http://localhost:11434；在不同机器则填实际 IP。

  1. 点击保存，Dify 会自动测试连接，绿色✅表示成功。

第四步：创建第一个聊天应用（10 分钟）

  1. Dify 首页点击创建应用 → 选择 Chatbot
  2. 左侧菜单选择添加模型，切换到 Ollama 选项卡
  3. 选择刚才接入的模型
  4. 在 Prompt Engineering 中填写系统提示词，例如：
你是一个公司内部 IT 助手，熟悉常见系统故障排查。
回答时先给出判断，再给出具体解决步骤。
  1. 右下角点击发布，获得一个可嵌入网站的聊天窗口

第五步：发布为 REST API（5 分钟）

  1. 应用发布后，点击左侧 API Access
  2. 记录 DIFY-API-KEY 和 API 地址
  3. 其他系统即可通过 HTTP 调用：
curl -X POST https://your-dify.example.com/v1/chat-messages \
  -H "Authorization: Bearer <DIFY-API-KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "打印机无法连接怎么办？",
    "user": "employee-001"
  }'

关键实现细节

细节一：工作流编排（比单纯聊天更强大）

Dify 的**工作流（Workflow）**功能适合复杂场景：

典型场景：客服工单处理

用户输入 → 意图识别（LLM） → 分支判断
  ├─ 技术问题 → 知识库检索 → 生成答案
  ├─ 投诉反馈 → 记录到内部系统 → 发送邮件通知
  └─ 其他     → 转人工客服

操作步骤：

  1. 创建应用时选择 Workflow 类型
  2. 从左侧组件库拖入节点：
    • LLM 节点：模型调用
    • 条件分支节点：if/else 逻辑
    • HTTP 请求节点：调内部 API
    • 模板转换节点：格式化输出
  3. 连接各节点，配置输入输出变量
  4. 测试运行，修复报错
  5. 发布

细节二：Ollama 模型升级不停服

Ollama 模型更新后，Dify 无需重新配置，刷新模型列表即可：

# 在 Ollama 服务器拉取新模型
ollama pull qwen2.5:14b

# Dify 中：设置 → 模型供应商 → Ollama → 刷新模型列表

细节三：多模型组合策略

结合昨天 Ollama 方案，可以这样分配：

任务类型推荐模型说明
简单问答/客服qwen2.5:7b速度快，资源占用低
复杂分析/代码qwen2.5:14b 或 codellama质量更高
长文本处理llama3.1:8b上下文更长

在 Dify 工作流中，为不同 LLM 节点指定不同模型即可。

常见坑与规避清单

坑 1：Dify 无法连接 Ollama（超时/502）

原因：Ollama 默认只监听 localhost，跨机器访问被拒绝。

解决：

# 在 Ollama 服务器上设置环境变量后重启
export OLLAMA_HOST=0.0.0.0  # 监听所有网卡
systemctl restart ollama

同时确保防火墙开放 11434 端口：

sudo firewall-cmd --add-port=11434/tcp --permanent
sudo firewall-cmd --reload

坑 2：Ollama 模型版本与 Dify 不兼容

原因：某些特殊模型（如 CodeGeex）未在 Dify 模型列表中注册。

解决：在 Dify 中手动添加自定义模型：

  • 进入设置 → 模型供应商 → 选 Ollama
  • 找到”添加自定义模型”入口
  • 填写模型名称（必须与 Ollama 中 ollama list 显示的名称完全一致）

坑 3：工作流节点间变量类型不匹配

原因：LLM 输出是文本，但 HTTP 请求节点需要 JSON。

解决：在 LLM 节点和 HTTP 节点之间插入模板转换节点，将文本格式化为结构化 JSON：

{{ output.text }} → {"query": "{{ output.text }}", "lang": "zh"}

坑 4：内存不足导致 Dify 组件崩溃

原因：Dify 包含多个服务（前端、后端、Worker、PostgreSQL、Redis），默认配置内存占用约 4-6GB。

解决：在 .env 中限制 worker 并发数：

# 限制并发推理数量
PIPELINE_API_TIMEOUT=60

或直接使用 Dify Lite 版本（不含所有插件，适合内存受限机器）：

docker-compose -f docker-compose-lite.yaml up -d

坑 5：Ollama 模型加载慢/推理卡顿

解决：优先使用 qwen2.5 系列（对中文优化好，推理效率高）；避免用 llama3 8B 以下版本处理中文任务。

# 推荐的中文编程+聊天组合
ollama pull qwen2.5:7b        # 快速问答
ollama pull qwen2.5:14b       # 复杂任务

成本/性能/维护权衡

成本对比

方案基础设施成本模型调用成本数据隐私
纯云端（GPT-4o API）~$0/人/月（服务器）~$3-10/人/月数据上云
Dify + Ollama 本地取决于硬件（电费）零增量完全私有
混合方案（Dify+本地+云端备援）同上 + 云端备用低增量核心数据本地

性能参考

以下为实测数据（MacBook M3 Pro 16GB，qwen2.5:7b）：

任务首次响应延迟持续吞吐
简单问答（50字内）1-2s~15 req/s
工作流节点调用2-5s~8 req/s
复杂分析（200字以上）5-15s~3 req/s

⚠️ 注意：Ollama 推理速度受并发数影响极大，同一时刻超过 2 个请求会显著变慢。生产环境建议加一层请求队列（用 Dify 内置的队列机制即可）。

维护成本

维护项频率工作量
Ollama 模型更新按需（新技术出现时）10 分钟
Dify 版本升级每月检查一次30 分钟（备份+升级+验证）
知识库数据更新视业务不定
硬件扩容瓶颈时一次性的

Dify 的优势是开源社区活跃，bug 修复快，且有商业版本（Dify Pro）可在关键时刻购买支持。

一周内可执行行动清单

  • Day 1：在已有 Ollama 环境的机器上用 Docker 部署 Dify，验证基础聊天功能
  • Day 2：将 Dify 接入 Ollama 的多个模型（qwen2.5:7b + 14b），测试响应质量差异
  • Day 3：设计一个实际业务场景工作流（如内部 FAQ 机器人），发布为 API 并用 curl 验证
  • Day 4：处理一个复杂场景：多模型组合 + 条件分支 + HTTP 调用内部 API
  • Day 5：将工作流嵌入内部工具（飞书/钉钉机器人或网页），做真实用户测试
  • Day 6：排查所有坑，整理 SOP 文档（方便团队成员复用）
  • Day 7：评估效果，决定是否需要升级硬件（内存/GPU）或切换部分流量到云端

延伸阅读（与昨天方案配套）：