在企业内部搭建 AI 应用时，团队往往既希望获得可视化工作流、知识库和接口发布能力，又不希望合同、客户资料、研发文档等敏感信息被发送到外部模型服务。Ollama 与 Dify 的组合提供了一条实用路径：前者负责在本地或内网运行模型，后者负责应用编排、知识检索与权限管理。🧩 不过，“模型本地运行”并不等于“数据天然安全”，网络边界、日志、向量库和插件同样需要纳入隔离设计。
一、先理解整体架构
典型调用链路是：用户访问 Dify 应用，输入内容经过开始节点、条件判断、知识检索或代码节点后，由 LLM 节点调用 Ollama，最后将结果返回给用户。Ollama 通常通过本地 HTTP API 提供推理能力，其本机服务地址一般为 来源链接；本地 API 默认不要求身份验证，因此不应把该端口直接暴露到公网。相关接口和认证说明可参考 Ollama 官方文档。
Dify 侧可在“集成—模型供应商”中安装模型供应商，并为自建推理服务添加自定义模型。模型名称必须与 Ollama 中实际存在的名称一致，例如模型标签包含版本后缀时，也应完整填写。Dify 对模型供应商、自定义端点及默认模型的说明可查看 Dify 模型供应商文档。
二、完成 Ollama 与 Dify 的连接
1. 准备并验证本地模型
安装 Ollama 后，先在终端执行 ollama list 查看已有模型；若尚未准备模型，可根据设备内存、显存和业务需求选择合适规格，再通过 ollama run 模型名 拉取并运行。不要只看模型参数规模，还要评估中文能力、上下文长度、工具调用支持和实际响应速度。✅
随后访问 Ollama API 或进行一次命令行问答，确认模型能够稳定返回结果。排障时可以执行 ollama ps，观察模型运行在 CPU、GPU 还是混合模式。Ollama 也会在 API 响应中提供加载时间、生成时间及输入输出 Token 等指标，可用于建立性能基线，参见 API 使用指标说明。
2. 处理 Docker 网络问题
如果 Dify 与 Ollama 都直接运行在同一主机环境中，Base URL 可以使用本机地址。若 Dify 运行在 Docker 容器内，而 Ollama 运行在宿主机，Dify 中填写 localhost 通常会失败，因为容器里的 localhost 指向容器自身。此时应使用宿主机可达地址，例如部分桌面环境可使用 host.docker.internal:11434，Linux 环境则应根据实际网桥或内网地址配置。
需要允许 Ollama 接受内网连接时，可通过 OLLAMA_HOST 调整监听地址。将其设为所有网卡地址虽然便于连接，却也会扩大攻击面；更稳妥的做法是配合主机防火墙，仅允许 Dify 所在主机或容器网段访问 11434 端口。不同操作系统的环境变量设置方式可参考 Ollama FAQ。🔐
3. 在 Dify 中添加模型
- 进入 Dify 的“集成—模型供应商”，安装或启用 Ollama 供应商。
- 填写 Ollama 的 Base URL，并输入与 ollama list 完全一致的模型名称。
- 按用途选择模型类型，例如对话模型或文本嵌入模型，不要把聊天模型直接当作 Embedding 模型使用。
- 保存后创建一个最精简的应用，只保留用户输入与 LLM 节点，先验证基础调用链路。
- 基础问答稳定后，再逐步加入知识检索、条件分支、变量转换和输出格式化节点。
三、搭建可维护的本地工作流
建议从“输入校验—敏感内容判断—知识检索—模型生成—结果检查”这一流程开始。输入校验负责限制文件类型与文本长度；条件节点按照业务部门或问题类型分流；知识检索节点只查询用户有权访问的数据集；LLM 节点根据检索结果生成回答；输出前再检查是否包含账号、密钥或不应展示的内部字段。Dify 的 LLM 节点支持提示词、上下文变量和结构化输出，具体能力可参考 LLM 节点文档。
实践中不要一开始就搭建复杂 Agent。先跑通单模型问答，再增加知识库，最后加入工具和外部系统调用。每增加一个节点，都应记录其输入、输出、联网行为和失败处理方式。
四、敏感数据隔离的关键措施
- 网络隔离：将 Dify、Ollama、数据库和向量库放在受控内网，禁止 Ollama 推理端口直接映射到公网；远程访问应通过 VPN、反向代理和访问控制完成。
- 环境隔离：开发、测试与生产使用不同实例、数据库和凭据，避免测试人员接触生产知识库，也不要用真实客户数据调试提示词。
- 权限隔离：按照部门、项目和数据等级拆分知识库，并限制工作空间管理员数量。应用可见不代表其背后的全部数据都应对所有用户开放。
- 日志治理：检查 Dify、反向代理、容器平台和操作系统日志是否保存完整问题、模型回答或上传文件；设置保留周期、脱敏规则和授权审计。
- 插件审查：工作流接入网页搜索、邮件、云盘或第三方 API 后，数据可能离开内网。上线前应逐项核对插件权限、目标域名及传输内容。⚠️
- 备份与删除：知识库原文件、解析结果、向量数据、会话记录和备份副本应采用统一的数据生命周期，确保删除请求能够覆盖全部存储位置。
五、上线前的验证清单
功能测试之外，还应准备一组贴近业务的评测问题，覆盖正常提问、缺少资料、越权查询、提示词注入、超长文本和多人并发等情况。重点记录答案是否有依据、检索结果是否越权、失败时是否泄露系统提示词，以及响应时间是否满足使用需求。模型能成功回答一次，只能证明链路可用，不能证明系统已经具备生产可靠性。
同时检查设备资源余量、模型冷启动时间、并发限制、磁盘增长和异常恢复流程。模型升级前应保留原版本和评测结果，避免直接替换导致回答风格、结构化输出或工具调用行为发生变化。📋
总结
Ollama 接入 Dify 的核心并不只是填写一个模型地址，而是建立一条可控制、可观测、可审计的本地 AI 调用链。正确处理 Docker 网络后，先用简单 LLM 节点验证连接，再逐步加入知识库和业务流程；在安全层面，则要同时治理端口、权限、日志、插件、备份与数据删除。只有推理服务和完整数据链路都留在受控边界内，本地化部署才能真正发挥敏感数据隔离的价值。🚀
