本地部署大模型早就不是什么新鲜事了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-8BCPU 推理勉强可用生成速度大约每秒 3~8 个 token适合日常聊天和调试内存占用约 5~8GB。13B~14B 参数量化模型CPU 会比较吃力建议至少 24GB 内存最好有显卡。30B 以上参数模型基本要有 16GB 以上显存或者 64GB 以上内存才考虑否则体验很痛苦。判断模型能不能跑核心看两个指标内存或显存容量和内存带宽。容量决定能不能装下模型带宽决定生成速度快不快。没有显卡的情况下CPU 推理主要吃内存带宽普通双通道 DDR4 内存跑 7B 量化模型大概就是每秒几个 token 的水平不适合做复杂 Agent 推理但用于学习和验证完全够。磁盘空间也要留意。一个 7B 的量化模型文件大约 4~5GBOllama 底层的镜像文件也需要约 8GBWindows 用的是 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 组或者没重新登录。第二步安装 OllamaWindows 直接下载 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. 部署智能体编排平台 Dify3.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.jsonLinux或 Docker Desktop 设置里添加registry-mirrors然后重启 Docker。镜像加速器用云服务商提供的公共地址即可。容器全部启动后其他容器在后台跑着Dify 的容器负责 Web 页面默认端口是 80Windows 和 Linux 都是http://localhost。如果是 Linux 服务器想用 IP 访问注意防火墙要放行 80 端口。如果端口被占用可以编辑.env里的EXPOSE_NGINX_PORT改成其他端口。3.3 配置模型供应商让 Dify 接入 OllamaDify 安装好还只是个空壳它自己不带模型必须把 Ollama 配置成模型供应商。这一步是整篇记录里最容易踩坑的地方之一重点说一下。打开 Dify 后台首次登录会让你设置管理员邮箱和密码。进入主界面后点击右上角头像进入「设置」再点「模型供应商」找到 Ollama 那一项并填写配置配置项填写内容说明模型名称deepseek-r1:8b必须和ollama list显示的完全一致Base URLhttp://host.docker.internal:11434Dify 容器访问宿主机 Ollama 的地址模型类型LLM语言模型上下文长度4096 或 8192步数越多内存消耗越大这里最关键的就是 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 选择应用类型聊天助手还是 AgentDify 里新建应用时会让你选类型常见的两种是「聊天助手」和「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 模式会强制模型使用工具来执行计算而不是凭空回答。提交之后我盯着运维日志看它按顺序做了这几件事调用calculator工具传入24*7365表达式得到结果533。再次调用calculator工具传入533/13得到结果41.0。模型综合工具结果生成最终回复“结果约为 41.00”。这个看起来简单的过程其实牵涉到模型函数调用、工具执行、结果回填、代码解释器等多个环节。能跑通这一步说明 Ollama、Dify、工具链已经全部串起来了有功夫的情况下完全可以用这套基础环境去接文档问答、网页摘要、数据图表生成等复杂应用。5. 常见问题与排查技巧实录5.1 Ollama 连不上、模型加载失败我在部署过程中遇到的第一类问题集中在“Ollama 服务连不上”和“模型加载失败”。现象 1Dify 里测试模型一直提示超时。排查思路先确认宿主机上 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 网络。现象 2ollama 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_PARALLEL1让一次只处理一个请求能减少等待和内存峰值。5.4 知识库的嵌入模型怎么处理如果不想止步于“聊天 工具”接下来一定会碰知识库RAG。Dify 的知识库功能需要一个嵌入模型把文档切片向量化这个模型同样可以用 Ollama 本地跑。我测试时拉取了bge-m3ollama pull bge-m3然后在 Dify 的模型供应商页面再把 Ollama 的嵌入模型配置一遍类型选择Text Embedding模型名称填bge-m3。之后新建知识库上传一个本地文档Dify 会自动将文档内容切块、调用嵌入模型生成向量再存入向量数据库Dify 默认的 Weaviate。整个数据流程完全本地化外网不通也能完成文档问答。这一块涉及切片大小、检索策略、召回模式等配置等第二篇再展开说。写到了这里基础版本的“本地智能体”已经完整跑通了Ollama 提供大脑、Dify 提供躯体、Docker 提供稳定环境从界面提问到工具调用再到结果生成整条链路都落在自己的机器上。我个人的体验是在没开始做之前觉得“本地智能体”是个很复杂的系统工程真正动手把组件一个个串起来之后会发现难点其实不在于某个单一工具而在于理解数据如何在组件间流动。这套环境搭好之后后续扩展知识库、接语音输入、做定时任务都变成相对轻松的增量工作。期待下一篇能和你们一起把这套本地智能体打磨得更接近一个“成熟产品”。