在本地部署大模型时，Ollama 负责模型下载、加载与推理，Dify 则提供可视化工作流、智能体编排、知识库和工具管理能力。两者结合后，可以搭建一个数据尽量留在本地、流程可控、便于调试的 AI 应用平台。本文以“本地问答智能体”为例，完整梳理模型接入、工作流设计和工具调用配置。🚀
一、部署前的环境准备
建议提前安装 Docker、Docker Compose、Git 和 Ollama。硬件配置需要根据模型规模决定，不宜简单照搬网络上的显存结论；首次实践可以选择体积较小、支持对话的模型，确认链路可用后再逐步更换。Ollama 支持通过命令行拉取、运行和查看模型，具体参数可参考 Ollama CLI 官方文档。
安装 Ollama 后，执行 ollama pull 模型名称下载模型，再通过 ollama run 模型名称进行基础问答测试。如果模型能正常返回内容，说明推理服务基本可用。还可以执行 ollama ls检查已安装模型，使用 ollama ps观察当前模型运行状态。
实践建议：先验证 Ollama，再部署 Dify。这样出现故障时，可以快速判断问题位于模型服务还是平台连接层。🔍
二、启动 Dify 本地服务
Dify 自托管版通常通过 Docker Compose 部署。获取官方项目后进入 docker 目录，复制环境变量示例文件，然后执行 docker compose up -d启动服务。容器初始化完成后，在浏览器中访问部署地址并创建管理员账户。生产环境还应配置反向代理、HTTPS、持久化备份及访问权限，不建议直接暴露数据库与内部服务端口。
进入 Dify 控制台后，先打开“设置”或“集成”中的模型供应商页面。如果当前版本采用插件化模型供应商，需要从 Marketplace 安装对应的 Ollama Provider，再添加模型。Dify 的 LLM 节点要求预先配置可用模型，节点能力可参考 Dify LLM 节点文档。
三、正确配置 Ollama 连接地址
模型名称必须与 ollama ls显示的名称一致，包括可能存在的标签。Base URL 则取决于 Dify 和 Ollama 的部署位置：如果 Dify 运行在 Docker 中，而 Ollama 运行在宿主机，容器内的 localhost指向容器自身，不能直接代表宿主机。
- Docker Desktop：可以优先尝试 来源链接。
- 同一 Compose 网络：如果 Ollama 也以容器运行，应使用服务名，例如 来源链接。
- 独立局域网主机：填写 Ollama 所在设备的局域网 IP 和 11434 端口，并限制防火墙访问来源。
Ollama 本地 API 默认使用 11434 端口，本机访问通常不需要额外认证，相关说明见 Ollama API 认证文档。如果需要让其他主机或容器访问，可以通过 OLLAMA_HOST调整监听地址，配置方式参考 Ollama FAQ。不要把未认证的 Ollama 接口直接开放到公网。⚠️
四、搭建第一个本地智能体工作流
在 Dify 中新建 Chatflow 或 Workflow：需要连续对话时选择 Chatflow，执行一次性处理任务时选择 Workflow。一个便于验证的基础流程可以设计为“用户输入 → 参数检查 → Agent 或 LLM → 输出”。两种应用类型的区别可查看 Workflow 与 Chatflow 官方说明。
- 添加用户输入节点，定义问题字段，并设置合理的长度限制。
- 添加 LLM 节点，选择已经配置好的 Ollama 模型。
- 编写系统提示词，限定智能体角色、回答范围、输出格式和异常处理原则。
- 将用户问题变量传入提示词，连接输出或回答节点。
- 在预览页面测试普通问题、空输入、模糊问题和超长内容。
本地模型能力存在差异，提示词应尽量具体。例如要求模型“信息不足时明确说明，不自行补全事实；调用工具后依据工具结果作答”。Temperature 可以从偏低设置开始，以提高工具选择和结构化输出的稳定性；上下文窗口则应结合模型能力与机器内存谨慎调整。
五、配置工具调用能力
Dify 中常见的工具接入方式包括工具插件、基于 OpenAPI 或 Swagger 的自定义 API、工作流工具以及 MCP。工具既可以作为独立 Tool 节点按固定流程执行，也可以挂载到 Agent 节点，由模型根据任务动态决定是否调用。工具类型与管理入口可参考 Dify Tools 官方文档。🧰
以内部查询 API 为例
假设已有一个查询业务状态的内部接口，应先为工具填写清晰名称和描述，例如“根据单号查询当前处理状态，仅用于已有单号的进度查询”。参数中定义单号的类型、是否必填和格式约束；涉及密钥时，应通过 Dify 凭据管理保存，不要把密钥直接写入提示词。
随后在 Agent 节点中选择该工具，并配置智能体规则：缺少单号时先向用户询问；不得猜测参数；一次查询失败时返回可理解的错误提示；工具结果为空时说明未找到记录。Agent 节点支持模型自主选择工具和迭代执行，但所选本地模型必须具备与对应策略相匹配的能力，详细配置见 Dify Agent 节点文档。
如果本地模型的原生工具调用不稳定，可以改用结构更明确的方案：先通过 LLM 节点把用户问题分类，再使用条件分支决定是否进入 Tool 节点，最后将工具结果交给另一个 LLM 节点整理。相比完全自治的 Agent，这种工作流可预测性更强，也更适合业务审批、数据库写入等需要严格控制的场景。
六、常见故障与排查方法
- 连接被拒绝：检查 Ollama 是否启动、11434 端口是否监听，以及 Dify 容器能否访问对应地址。
- 模型不存在：核对模型名称和标签，确认模型已完成下载。
- 工具始终不调用：检查模型是否支持当前 Agent 策略，并优化工具描述、参数定义和系统指令。
- 响应速度较慢：观察 CPU、内存、显存和模型加载状态，减少上下文长度或更换更轻量的模型。
- 结果格式不稳定：明确字段要求，增加条件校验，并为工具异常设置备用分支。
调试时不要只看最终答案，还应查看 Dify 的节点输入输出、Agent 日志和工具返回值。建议准备一组固定测试用例，分别覆盖正确参数、缺少参数、错误参数、接口超时和无权限访问，从而确认智能体不会绕过规则执行高风险操作。
总结
Ollama 与 Dify 的组合重点不在“把模型地址填进去”，而在于打通容器网络、匹配模型能力、明确工具边界并设计可靠的异常分支。先用简单 LLM 流程验证本地推理，再增加工具节点和 Agent 策略，最后补充日志、安全控制与回归测试，能够显著降低排错成本。对于强调数据控制、内部知识问答和流程自动化的场景，这套方案具有较强的实践价值。✅
