本地智能体部署全记录：Ollama+Dify从零搭建私有AI助手

本地部署大模型早就不是什么新鲜事了，Ollama 一行命令就能把 DeepSeek、Qwen 这类开源模型拉下来跑。但“跑模型”和“跑智能体”是两码事，后者需要一套能编排工具调用、记忆管理、多轮对话的框架。这篇“本地智能体部署全记录（一）”主要记录我最近在一台普通开发机上，从零把 Ollama 模型服务、Dify 智能体平台、本地 Agent 串起来的全过程，包含环境准备、组件部署、模型对接、第一个智能体落地实测，以及踩坑实录。适合已经用过一点大模型 API、想在本地跑一套私有智能体、又不想一开始就啃 RAG 和微调的新手参考。

1. 整体思路：为什么要把智能体放在本地跑

1.1 本地部署到底解决了什么问题

先说说我为什么没继续用云端 API，而是折腾本地部署。市面上有很多成熟的模型 API，调用方便、效果也好，但长期用下来有几个点绕不开：一是数据隐私，企业内部文档、个人笔记这些内容传到别人的服务器上，总归有点不踏实；二是调用成本，如果智能体要做多轮推理、频繁触发工具调用，token 消耗会很快，试错成本比想象中高；三是网络依赖，哪天网络波动或者服务商夜里维护，智能体就跟着断供了。

本地部署最直接的好处就是把模型权重、推理过程、业务数据全部留在自己的机器里。你加载模型也好，调试 Prompt 也好，不像在云端那样有那么多限制。只要机器配置够用，模型版本随你换，推理参数随你调，日志和中间结果也全部可见，排查问题会舒服很多。对于做原型验证、学习 Agent 原理的人来说，这套环境几乎是最低成本的学习沙盒。

当然，本地部署不是免费的午餐。最典型的代价是硬件门槛，其次是对工程能力的要求：模型服务怎么起、依赖组件怎么装、API 怎么对接，这些都要自己搭。但正因为如此，折腾一遍之后，你对“大模型应用”的理解会比单纯调云 API 深得多。

1.2 技术选型：Ollama + Dify + Docker 的组合

这次选型我几乎没纠结，直接定了三个核心组件：Ollama 负责加载和推理本地大模型，Dify 负责智能体的编排与可视化开发，Docker 负责把 Dify 的依赖环境隔离起来。这个组合可以理解为：Ollama 是发动机，Dify 是驾驶室，Docker 是集装箱。

• Ollama：目前最省心的本地模型运行工具，支持 macOS、Windows、Linux，一条命令就能拉取和运行大量开源模型（DeepSeek、Qwen、Llama、Phi 等）。它把模型量化、GPU 加速、API 服务都封装好了，默认暴露一个 HTTP 接口，任何应用都能通过 OpenAI 兼容格式调用。
• Dify：开源的 LLM 应用开发平台，提供可视化的工作流编排、Agent 构建、知识库管理（RAG）、Prompt 调试、日志追踪等功能。它可以理解成一个小型“AI 应用后端”，把模型接入、工具调用、多轮会话这些复杂的工程细节都包装成界面操作。
• Docker：因为 Dify 依赖 PostgreSQL、Redis、向量数据库等多个服务，逐个手动安装太容易翻车，用 Docker Compose 直接拉起整套服务是最稳妥的方式。

这个组合的优势在于分层清晰。底层模型服务独立运行，上层应用平台可以被替换，将来如果你想换 LangChain 或者自己写 Agent 框架，Ollama 依然可以继续用，不会被绑死。所以这篇记录的第一阶段，就是把地基打好，地基越稳，后面做复杂业务越省心。

1.3 整套系统的数据流长什么样

在动手安装之前，我建议先在脑子里过一遍系统架构，不然部署完会一脸懵：哪个组件是干嘛的？数据是怎么从用户请求流转到最终答案的？

整个链路大概是这样的：用户打开 Dify 的聊天界面，输入一个问题，Dify 根据你配置的应用类型（聊天助手或 Agent）决定如何响应。如果只问简单问题，Dify 直接把请求转发给 Ollama 模型服务，模型生成回答后原路返回。如果是复杂任务，Dify 会让模型进入“思考-行动-观察”循环：模型先生成下一步计划，Dify 根据计划调用已经授权的工具（比如搜索、计算器），拿到工具结果后再交给模型继续推理，直到最终生成答案。这个过程中，模型权重和推理都在本地机器上完成，Dify 更多承担调度、会话管理、工具调用这些工作。

这个架构虽然简单，但恰好体现了智能体应用的核心逻辑：大模型负责“大脑”，应用平台负责“手脚”，本地部署保证“大脑”和“手脚”都在自己控制范围内。

2. 环境准备与基础组件部署

2.1 硬件自查清单

本地部署第一件事不是装软件，而是先搞清楚机器能跑多大规模的模型。很多人上来就下载几十个 G 的大模型，结果内存直接爆掉，这其实可以提前避免。

我的开发机配置是：Intel i5 处理器、16GB 内存、无独立显卡（NVIDIA 显卡没有的话就用 CPU 推理）、500GB 可用磁盘。这个配置属于“能跑但不算宽裕”的水平，作为参考：

• 7B~8B 参数的量化模型（如 Qwen2.5-7B、DeepSeek-R1-8B）：CPU 推理勉强可用，生成速度大约每秒 3~8 个 token，适合日常聊天和调试，内存占用约 5~8GB。
• 13B~14B 参数量化模型：CPU 会比较吃力，建议至少 24GB 内存，最好有显卡。
• 30B 以上参数模型：基本要有 16GB 以上显存或者 64GB 以上内存才考虑，否则体验很痛苦。

判断模型能不能跑，核心看两个指标：内存（或显存）容量和内存带宽。容量决定能不能装下模型，带宽决定生成速度快不快。没有显卡的情况下，CPU 推理主要吃内存带宽，普通双通道 DDR4 内存跑 7B 量化模型大概就是每秒几个 token 的水平，不适合做复杂 Agent 推理，但用于学习和验证完全够。

磁盘空间也要留意。一个 7B 的量化模型文件大约 4~5GB，Ollama 底层的镜像文件也需要约 8GB（Windows 用的是 WSL2 虚拟磁盘），加上 Dify 的镜像和日志，建议至少留出 50GB 可用空间。

2.2 安装 Docker 与 Ollama

环境准备我按“先底部后顶部”的顺序来，先装基础设施，再装模型服务。

第一步：安装 Docker

在 Windows 上安装 Docker Desktop 很直接，下载安装包双击安装，启动后确认左下角鲸鱼图标变绿就行。有几个细节值得注意：Docker Desktop 默认依赖 WSL2，安装过程中如果提示启用虚拟化，记得进 BIOS 打开 VT-x；安装完成后打开 CMD 或 PowerShell，执行docker version能看到 Client 和 Server 两段信息才算成功，Server 上显示linux/amd64或者类似内容。

Linux 上更简单，以 Ubuntu 为例，用 apt 安装 docker.io 之后，把当前用户加入 docker 组：

sudo usermod -aG docker $USER newgrp docker

如果 Linux 上安装完 docker 后执行命令报权限错误，多半是没有把用户加入 docker 组，或者没重新登录。

第二步：安装 Ollama

Windows 直接下载 OllamaSetup.exe 安装，装完会自动把命令行工具放到 PATH 里。Linux 一条命令：

curl -fsSL https://ollama.com/install.sh | sh

安装完成后，测试一下服务是否在运行：

ollama serve

这个命令会以前台方式启动 Ollama 服务，看到Listening on 127.0.0.1:11434就说明服务起来了。Windows 上 Ollama 会作为后台服务自启，不需要手动保持前台。

验证 Ollama 是否正常还有一个更直接的方式：

ollama list

如果命令不报错，说明客户端和服务端通信正常。

2.3 下载并加载本地模型

模型的选择决定了后面所有体验。我这次先用 DeepSeek-R1-8B 作为主力推理模型，再用 Qwen2.5-7B 做备选，实测下来各有优劣。DeepSeek-R1 系列是推理模型，适合让 Agent 做逐步思考；Qwen2.5 系列通用性更强，指令跟随表现稳定。

拉取模型：

ollama pull deepseek-r1:8b ollama pull qwen2.5:7b

第一行命令是从模型仓库下载模型，如果中途网络断开，重新执行会断点续传。下载完成后，直接运行：

ollama run deepseek-r1:8b

进入交互模式后输入“你好”，能收到回复就说明模型已经可以正常推理了。这时候再打开一个新的终端，执行：

ollama list

能看到已下载模型的名称和大小。

跑模型的时候有一点要提前说明：Ollama 默认允许的模型上下文长度是 2048 个 token，如果要多轮会话、处理长文档，需要在 Modelfile 里加大num_ctx，后面我会讲到怎么调。模型默认会占用内存作为缓存，如果同时跑多个模型，内存不够时会自动卸载一部分。对 Agent 场景来说，一次还是集中精力跑一个主模型比较稳妥。

3. 部署智能体编排平台 Dify

3.1 为什么需要一个编排平台

有人可能会问：我已经有 Ollama 和模型了，直接用 Python 调用 API 不就行了吗？确实可以，但如果只靠手写代码，你会发现要额外自己处理的问题很多：多轮对话的会话管理怎么做、工具调用的函数定义怎么写、工具返回结果如何反馈给模型、日志和 Prompt 版本怎么管理，更别提知识库检索、文件上传这些更复杂的功能。逐个手写当然能做，但前期效率太低。

Dify 这类平台的价值就是把“模型应用开发”里的通用环节抽离出来。你只需要定义应用类型、写 Prompt、接工具，剩下的事它替你兜底。而且 Dify 是开源项目，界面和代码都能本地化部署，不产生额外费用，数据也不出网。对想快速看到智能体效果的人来说，这是最高效的路径。

3.2 用 Docker Compose 拉起整套依赖

Dify 的部署方式在官方文档里写得很清楚，核心是用 Docker Compose 拉起多个容器。我实际操作时的步骤如下：

打开终端进到一个准备存放项目的目录，比如D:/Projects，然后：

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

如果没有安装 git，也可以直接去 GitHub 仓库把docker文件夹下的内容下载下来，重点拿到docker-compose.yaml和.env.example。.env.example复制成.env后，里面包含了所有服务的环境变量，比如数据库密码、密钥、模型供应商配置等，默认值可以直接用，但不建议在生产环境不改密码。

docker compose up -d会拉取并启动所有依赖容器。这一步通常会耗时较长，因为需要拉取 PostgreSQL、Redis、Weaviate（向量数据库）、API 服务、Web 服务等多个镜像。如果你的网络条件一般，Docker 镜像拉取可能会超时，此时可以给 Docker 配置国内镜像加速器。配置方式因 Docker Desktop 和 Linux 版本各有不同，原理都一样：在/etc/docker/daemon.json（Linux）或 Docker Desktop 设置里添加registry-mirrors，然后重启 Docker。镜像加速器用云服务商提供的公共地址即可。

容器全部启动后，其他容器在后台跑着，Dify 的容器负责 Web 页面，默认端口是 80（Windows 和 Linux 都是http://localhost）。

如果是 Linux 服务器，想用 IP 访问，注意防火墙要放行 80 端口。如果端口被占用，可以编辑.env里的EXPOSE_NGINX_PORT改成其他端口。

3.3 配置模型供应商：让 Dify 接入 Ollama

Dify 安装好还只是个空壳，它自己不带模型，必须把 Ollama 配置成模型供应商。这一步是整篇记录里最容易踩坑的地方之一，重点说一下。

打开 Dify 后台，首次登录会让你设置管理员邮箱和密码。进入主界面后，点击右上角头像进入「设置」，再点「模型供应商」，找到 Ollama 那一项并填写配置：

这里最关键的就是 Base URL。很多人第一次配置会写成http://localhost:11434，结果 Dify 里测试模型总是超时，原因很简单：Dify 跑在 Docker 容器里，那里的localhost指向容器自己，不是你的宿主机，自然找不到 Ollama。在 Windows 和 macOS 的 Docker Desktop 环境中，应该用host.docker.internal这个特殊域名来访问宿主机。Linux 下如果 Dify 容器用了 host 网络模式，直接用localhost就行，但默认的 bridge 网络下需要改成172.17.0.1之类的网关地址。

配置好之后，Dify 后台会出现 Ollama 的模型图标，新建应用时就能选中这个模型了。

除了对话模型，如果想用 Dify 的知识库功能，还会用到嵌入模型（Embedding），比如bge-m3。这个我放在第 5 章细说，先别急着下，免得占内存。

4. 创建第一个本地智能体

4.1 选择应用类型：聊天助手还是 Agent

Dify 里新建应用时会让你选类型，常见的两种是「聊天助手」和「Agent」。刚开始很多人分不清，我简单梳理一下：

• 聊天助手：适合多轮对话场景，系统眼里就是“用户提问-助手回答”，不会主动调用工具。如果你只是想验证模型能不能回答好你的领域问题，选这个类型就够了。
• Agent（智能体）：适合需要工具调用的场景，系统会让模型自主规划，什么时候调用什么工具、拿到工具结果后如何组织回答，都由模型决定。Dify 的 Agent 类型默认使用“函数调用”机制，也就是说模型需要从预设好的工具列表里选出合适的工具执行。

这次我们要做的“本地智能体”肯定选 Agent。因为它才能体现“智能体”三个字的含义——不是只会聊天，而是会“干活”。

4.2 设计系统提示词与编排逻辑

创建 Agent 应用后，第一件要做的事就是写好系统提示词。系统提示词决定了智能体的身份定位和行为准则，我建议按这个模板来写：

你是一个本地智能体助手，运行在用户的个人设备上。 你的职责范围包括：回答用户问题、辅助信息整理、调用可用工具完成具体任务。 当你需要实时信息或执行操作时，你应该优先调用工具，而不是凭空猜测。 所有回答应当简洁、准确，逻辑清晰。如果工具返回结果为空，请如实告知用户，不得编造结果。

写完系统提示词，还要给 Agent 配置“模型”。在 Dify 应用编排界面，右上角模型选择区域选中刚刚配置的deepseek-r1:8b。如果模型不显示，回去检查模型供应商配置是否正确。

在编排逻辑上，Dify 的 Agent 类型默认提供两类模式：function calling（函数调用）和ReAct 模式。当模型本身不支持 function calling 时，可以切到 ReAct 模式。Ollama 拉取的大部分新模型（qwen2.5、deepseek-r1 等）都支持原生的工具调用函数接口，直接保留 function calling 即可。实测下来，function calling 模式在 Dify 界面上更好调试——每一步调了什么工具、传给模型什么参数、拿回什么结果，都看得一清二楚。

4.3 挂载实用工具，跑一个多步任务

Agent 最有意思的地方是能执行多步任务。Dify 在左侧「工具」面板里内置了不少现成工具，比如时间工具、计算器、网络搜索（需要配置搜索 API 密钥）等。为了演示本地智能体的能力边界，我先接入了两个零成本工具：计算器和时间工具。

然后我在测试区试了一个问题：

“现在是哪一年的哪一天？如果距离今年的最后一天过去了 45 天，那当前日期减 45 天后是多少？”

这个问题对纯聊天模型来说不难，但会让 Agent 自动分两步：先调时间工具获取当前日期，再调计算器算日期减 45 天的结果。最终模型的回答要综合两次工具结果再生成。从 Dify 部署界面右上角的运行日志里可以清楚看到步骤1步骤2的调用记录，这对理解 Agent 的“思考-行动-观察”循环非常有帮助。

如果想让智能体具备联网搜索能力，需要先去工具市场配置一个搜索 API Key。Dify 支持配置 SerpAPI、Tavily 等搜索服务的 API Key；对于没有 Key 的场景，也可以自己写一个简易的 HTTP 工具，比如封装一个“查询服务器状态”的接口，再挂到工具面板里。这一步能显著提升智能体的实用性，但它依赖外部 API，我给你一个思路，你在自己的网络环境下去配置即可。

4.4 实测：让智能体完成一个多步任务

工具挂载好之后，我实测了一个相对完整的任务，用来验证整个链路是否真的通了。

在 Dify 的 Agent 调试面板输入：

“帮我计算 24 乘以 7 的结果，再加 365，最后除以 13，保留两位小数。”

这个任务对聊天模型不难，但 Agent 模式会强制模型使用工具来执行计算，而不是凭空回答。提交之后我盯着运维日志看，它按顺序做了这几件事：

1. 调用calculator工具，传入24*7+365表达式，得到结果533。
2. 再次调用calculator工具，传入533/13，得到结果41.0。
3. 模型综合工具结果，生成最终回复：“结果约为 41.00”。

这个看起来简单的过程，其实牵涉到模型函数调用、工具执行、结果回填、代码解释器等多个环节。能跑通这一步，说明 Ollama、Dify、工具链已经全部串起来了，有功夫的情况下，完全可以用这套基础环境去接文档问答、网页摘要、数据图表生成等复杂应用。

5. 常见问题与排查技巧实录

5.1 Ollama 连不上、模型加载失败

我在部署过程中遇到的第一类问题集中在“Ollama 服务连不上”和“模型加载失败”。

现象 1：Dify 里测试模型一直提示超时。
排查思路：先确认宿主机上 Ollama 服务是否真的在运行。用浏览器访问http://localhost:11434，如果能看到Ollama is running之类的文本，说明服务在跑。接下来要检查 Dify 容器里的 Base URL 是否写的是host.docker.internal。另外，Windows 上如果 Ollama 是在 WSL2 里启动的，Dify 容器访问的host.docker.internal指向的可能是 Windows 宿主，而不是 WSL2 内部，此时需要把 OLLAMA_HOST 设置为0.0.0.0，让 Ollama 监听所有网卡，或者在.env里配置服务的容器名称，让它们处于同一 Docker 网络。

现象 2：ollama run拉模型卡在 downloading 不动。
这通常是网络问题，解决办法是把模型源切换到国内可用的镜像源。Ollama 支持通过环境变量覆盖模型仓库地址，设置OLLAMA_BASE_URL指向一个你可用的镜像服务即可。如果镜像源不靠谱，换一个时间段再试，下载是有断点续传的。

现象 3：模型加载后生成回答极慢。
CPU 推理跑 8B 模型本来就有限速，但如果慢到离谱，打开任务管理器看内存是否被占满，如果占满了，可能同时跑了多个模型，或者上下文长度设置过大。用ollama ps查看当前加载的模型列表，把不用的模型卸载掉。

5.2 容器起不来、镜像拉取慢

Dify 部署过程中最容易在第一步就卡住的就是镜像拉取。docker compose up -d之后发现卡在某个镜像下载，半天没动静，多半是 Docker 镜像源不通。

解决办法是配置国内镜像加速器后再重启 Docker。配置完成后，重新执行docker compose up -d。如果镜像层已经拉了一半，继续拉时会接着下载，不会从头开始。

还有一个常见问题是端口占用。Dify 默认映射 80 端口到宿主机，如果你的机器上已经有 Nginx 或 IIS 占了 80 端口，容器启动会报bind: address already in use。解决方式是改.env中的EXPOSE_NGINX_PORT，例如改成8080:80。

容器都启动后，不要急着立即访问页面，Dify 首次启动要做数据库迁移，前后大约需要 1~3 分钟。如果很快打开页面出现白屏，先等一下再刷新。

5.3 生成速度慢、内存占用高怎么调

本地部署智能体，性能和内存是永远绕不开的坎。实测下来有几个比较实用的调节手段：

• 限制上下文长度：在 Dify 模型配置里把上下文从 8192 调回 4096，内存占用立竿见影地下降。Agent 场景如果不需要处理长文档，4096 完全够用。
• 使用更小的量化模型：Ollama 仓库里同一个模型通常有多种量化格式，默认拉取的一般是 Q4_K_M 量化版本，已经是平衡点。如果想要更低的资源占用，可以拉取模型里带q2_k标签的版本，代价是回答质量略降。
• 调整 Ollama 的并发数：如果你只是个人调试，就不需要让 Ollama 同时处理多个请求。可以在环境变量里设置OLLAMA_NUM_PARALLEL=1，让一次只处理一个请求，能减少等待和内存峰值。

5.4 知识库的嵌入模型怎么处理

如果不想止步于“聊天 + 工具”，接下来一定会碰知识库（RAG）。Dify 的知识库功能需要一个嵌入模型把文档切片向量化，这个模型同样可以用 Ollama 本地跑。我测试时拉取了bge-m3：

ollama pull bge-m3

然后在 Dify 的模型供应商页面，再把 Ollama 的嵌入模型配置一遍，类型选择Text Embedding，模型名称填bge-m3。

之后新建知识库，上传一个本地文档，Dify 会自动将文档内容切块、调用嵌入模型生成向量，再存入向量数据库（Dify 默认的 Weaviate）。整个数据流程完全本地化，外网不通也能完成文档问答。这一块涉及切片大小、检索策略、召回模式等配置，等第二篇再展开说。

写到了这里，基础版本的“本地智能体”已经完整跑通了：Ollama 提供大脑、Dify 提供躯体、Docker 提供稳定环境，从界面提问到工具调用再到结果生成，整条链路都落在自己的机器上。我个人的体验是，在没开始做之前，觉得“本地智能体”是个很复杂的系统工程，真正动手把组件一个个串起来之后，会发现难点其实不在于某个单一工具，而在于理解数据如何在组件间流动。这套环境搭好之后，后续扩展知识库、接语音输入、做定时任务都变成相对轻松的增量工作。期待下一篇能和你们一起，把这套本地智能体打磨得更接近一个“成熟产品”。