在 Win11 环境下搭建Docker + Dify + Ollama 本地 AI Agent
这是我的第一篇博客，如果有不好的地方，还请多多指教。
可以先看文章内容，如果觉得麻烦的话，其实扣子是个不错的选择。
扣子网址：https://www.coze.cn/，打开后在左侧点击扣子编程。
正式开始：
我的配置介绍：
我的配置 RTX 4060 Laptop + 8GB 显存 + 16GB 内存
以下是我的从零搭建的步骤：
第一步：下载Docker
Docker官网：https://www.docker.com/products/docker-desktop/
Docker直接下载地址（点击以下链接即可）：
Download for Windows - AMD64（适用于大部分电脑）
第二步：将自己的配置发给AI，询问AI我的配置适合什么大模型
我问了Gemini，它给出以下三个大模型：
| 推荐模型 | 核心优势 | 建议用途 | 显存建议 |
| Qwen2.5-Coder-7B | 中文适配王者。对 Java 常用框架（Spring Boot, Mybatis）支持极佳。 | 日常学习与 Debug。当你需要快速查语法或改 Bug 时首选。 | Q8_0 量化 (约 7.5GB) |
| DeepSeek-Coder-V3 (Small) | 代码逻辑天花板。V3 版本在处理复杂 Java 设计模式和算法上非常强悍。 | 核心逻辑开发。遇到复杂的 Agent 逻辑编排或算法题时，用它更稳。 | Q4_K_M 量化 (约 8-9GB) |
| Llama-4-8B (Maverick) | Agent 生态最强。作为 2026 年的标杆模型，各类 Agent 框架对其兼容性最好。 | AI Agent 架构学习。学习如何调用工具、处理多轮对话状态。 | Q8_0 量化 (约 8GB) |
给出这三个的理由：
1：国内开发环境：Qwen (通义千问) 针对中文技术文档和国内大厂常用的中间件有专门优化，写出来的注释和命名更符合国内习惯。
2：Agent 进阶： 既然你想研究 Agent，Llama-4-8B 是必须的。目前主流的开源 Agent 框架（如 LangGraph, CrewAI）几乎都是优先适配 Llama 系列，学习成本最低。
3：显存容错： 你的 8GB 显存跑 14B 模型（如 DeepSeek V3 小参数版）会稍微挤占一点内存（RAM），速度会降到 15-20 token/s，虽然慢一点，但逻辑会比 7B 深刻很多。
第三步：下载Ollama（预计占用5.12G）
Ollama网址：https://ollama.com/
Ollama直接下载链接：https://ollama.com/download/OllamaSetup.exe
点击 Download 开始下载
注意：Ollama会强制安装在 C 盘的程序文件夹中，而且在安装过程中不会询问你想安装在哪里，即是软件本身和模型下载地址默认在C盘。
下载完后，可以将模型下载地址进行更改（这里我将下载模型地址放在了E盘的OllamaModels文件夹）
Ollama环境配置：
- 按下键盘上的
Win + S，搜索“环境变量”，选择“编辑系统环境变量”。 - 在弹出的窗口中点击右下角的“环境变量”。
- 在“用户变量”区域点击“新建”。
- 变量名：
OLLAMA_MODELS - 变量值：
OllamaModels文件夹位置，比如我的就是E:\OllamaModels
记得连续点击三个确定。
第四步：下载大模型
在OllamaModels的地址框中输入cmd来打开终端
在终端输入：
ollama run qwen2.5-coder:7b（这里是下载Qwen2.5-Coder-7B模型，预计4.36 GB）
如果是要下载其他主流的模型（也可以问AI）：
#DeepSeek-R1（目前最火的推理模型）： ollama run deepseek-r1:7b #Llama 3.2 / 3.3（Meta 开源标杆）： ollama run llama3.2 # 3B轻量版，适合普通电脑 ollama run llama3.3 # 70B强力版，需要较高显存 #Qwen 2.5 / 3（阿里通义千问，中文支持极佳）： ollama run qwen2.5 # 综合实力均衡 ollama run qwen3 # 最新版本 #Qwen2.5-Coder（目前开源代码模型梯队最顶尖）： ollama run qwen2.5-coder:7b #CodeLlama（Meta 专为编程优化的模型）： ollama run codellama #Gemma 3（Google 最新开源模型，支持视觉识图）： ollama run gemma3 #Llama 3.2 Vision： ollama run llama3.2-vision 可能在下载的时候会用到的命令：
| 功能 | 命令 |
| 查看已下载的模型 | ollama list |
| 仅下载不运行 | ollama pull <模型名> |
| 查看正在运行的模型 | ollama ps |
| 删除某个模型 | ollama rm <模型名> |
| 强制停止某个模型 | ollama stop <模型名> |
如果出现：
pulling manifest pulling 60e05f210007: 6% ▕███ ▏ 280 MB/4.7 GB 1.1 MB/s 1h9m那就说明开始下载了。
如果你在下载Ollama完后将Ollama的文件夹进行移动，终端可能显示：
'ollama' 不是内部或外部命令，也不是可运行的程序 或批处理文件。说明Ollama的Path 环境变量没有更改，需要打开环境变量寻找Path变量里的Ollama，将Ollama地址改为当前所在地址。
记得连续点击三个确定。
修改完后打开新的终端后，可以在终端输入
ollama --version如果出现：
ollama version is 0.15.4说明环境变量已经配置成功了
如果是：
Warning: could not connect to a running Ollama instance Warning: client version is 0.15.4也不要怕，出现这个 Warning: could not connect 的警告，是因为 Ollama 的后端服务还没有启动。双击运行 ollama app.exe就好了。
如果已经打开了Ollama却还是显示Warning: could not connect，按照以下步骤即可解决：
第一步：清空所有进程（重置状态）
- 关掉所有的终端窗口。
- 右键任务栏的Ollama，右键点击 Quit。
- 打开任务管理器（
Ctrl+Shift+Esc），在“详细信息”里找ollama.exe，如果有，全部右键“结束任务”。
第二步：只启动一次
双击运行 ollama app.exe
第三步：在新的终端输入
ollama list如果显示：
>ollama list NAME ID SIZE MODIFIED 说明成功了，如果依然 Warning：说明你的系统变量 OLLAMA_HOST 可能被意外设置了。输入 set OLLAMA_HOST 看看，如果没有这个变量，那就是正常的。
为什么是空白？因为你还没开始下载模型。
检查环境变量是否配置成功：
在新建的终端中分别输入：
where ollama和
echo %OLLAMA_MODELS%如果输出结果分别是：
Ollama 可执行文件所在的磁盘路径
OllamaModels文件夹所在地址
下载大模型成功的标志：
当你看到 CMD 窗口出现以下内容时，说明模型已经下载好了，你可以直接开始输入你需要提问的内容。
>>> Send a message 或者可以在新的终端输入来验证：
ollama list如果显示下面的内容，那就是下载好了：（我这边是下载了qwen2.5-coder:7b模型）
>ollama list NAME ID SIZE MODIFIED qwen2.5-coder:7b dae161e27b0e 4.7 GB 4 hours ago注：下载的时间较长，我们在等待下载完成的同时我们可以进行第四步：下载Dify。
第五步：下载Dify
打开终端，分别输入以下内容：
# 1. 下载 Dify 源代码 git clone https://github.com/langgenius/dify.git # 2. 进入部署目录 cd dify/docker # 3. 复制配置文件 copy .env.example .env # 4. 启动 Dify (这会下载很多镜像，建议在网速快的时候操作) docker-compose up -d当你运行 docker compose up -d 时，它会开始下载大概 10 多个容器镜像（包括数据库 PostgreSQL、缓存 Redis、Dify 后端等）可能需要一段时间。
第六步：打开Dify页面
启动成功后，在浏览器访问 http://localhost 或者输入 http://127.0.0.1:8090 就能看到 Dify 的界面了。加载需要一定时间，可如果一直都在加载界面的话，可以去终端输入：
>docker-compose ps如果显示以下内容，说明是关键组件（api, web, nginx, db）全部处于 Up 状态：
\dify\docker>docker-compose ps NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS docker-api-1 langgenius/dify-api:1.12.0 "/bin/bash /entrypoi…" api 14 minutes ago Up 14 minutes 5001/tcp docker-db_postgres-1 postgres:15-alpine "docker-entrypoint.s…" db_postgres 14 minutes ago Up 14 minutes (healthy) 5432/tcp docker-nginx-1 nginx:latest "sh -c 'cp /docker-e…" nginx 14 minutes ago Up 14 minutes 0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp docker-plugin_daemon-1 langgenius/dify-plugin-daemon:0.5.3-local "/bin/bash -c /app/e…" plugin_daemon 14 minutes ago Up 14 minutes 0.0.0.0:5003->5003/tcp, [::]:5003->5003/tcp docker-redis-1 redis:6-alpine "docker-entrypoint.s…" redis 14 minutes ago Up 14 minutes (healthy) 6379/tcp docker-sandbox-1 langgenius/dify-sandbox:0.2.12 "/main" sandbox 14 minutes ago Up 14 minutes (healthy) docker-ssrf_proxy-1 ubuntu/squid:latest "sh -c 'cp /docker-e…" ssrf_proxy 14 minutes ago Up 14 minutes 3128/tcp docker-weaviate-1 semitechnologies/weaviate:1.27.0 "/bin/weaviate --hos…" weaviate 14 minutes ago Up 14 minutes docker-web-1 langgenius/dify-web:1.12.0 "/bin/sh ./entrypoin…" web 14 minutes ago Up 14 minutes 3000/tcp docker-worker-1 langgenius/dify-api:1.12.0 "/bin/bash /entrypoi…" worker 14 minutes ago Up 14 minutes 5001/tcp docker-worker_beat-1 langgenius/dify-api:1.12.0 "/bin/bash /entrypoi…" worker_beat 14 minutes ago Up 14 minutes 5001/tcp如果网页一直在加载，最可能的原因是端口冲突或网络代理干扰。我们按顺序快速解决：
1. 强制使用 IP 访问（跳过 localhost 解析）
有时候 Windows 的 localhost 解析会有延迟。请直接在浏览器地址栏输入： http://127.0.0.1 （注意不要加 8080 或 5001，Dify 默认映射的是 80 端口）。
2. 检查 80 端口是否被占用
由于 docker-nginx-1 虽然显示 Up，但如果 80 端口被你电脑上其他的占用了，请求就进不去。
1：新开一个终端
2：在终端输入：
> netstat -ano | findstr :80如果返回的最后一列 PID 对应的程序不是 Docker，那么端口就冲突了。解决方法：
方案一：找出并杀掉占用进程（最推荐）
打开任务管理器（Ctrl + Shift + Esc），切换到 “详细信息” 选项卡，点击 “PID” 列进行排序，找到 4780 和 9596。如果是 System (PID 4) 或者 inetinfo.exe，那是 Windows 自带的服务，通常需要去“启用或关闭 Windows 功能”里关掉 Internet Information Services (IIS)。然后再访问 http://127.0.0.1。
方案二：给 Dify 换个端口（最稳妥，不影响系统）
如果你不想动系统服务，我们直接让 Dify 避开 80 端口：
- 访问新地址： 在浏览器输入：
http://127.0.0.1:8090
重新启动：
> docker-compose up -d 修改配置文件： 用记事本打开 docker-compose.yaml。 找到 nginx: 服务下的 ports: 部分，你会看到：（CTRL+F开始关键词搜索，也可以交给AI来找）
ports: - "80:80" - "443:443" 把它改成（比如改成 8090）：
ports: - "8090:80" - "443:443" 停止 Dify：
> docker-compose down 3. 关闭梯子
它们可能会拦截 localhost 的请求。
4. 终极重启大法
如果上述都不行，可能是某个容器内部卡住了，在新的终端执行这个命令组合：
> docker-compose stop > docker-compose start （start 比 up -d 快，因为它只是启动已经建好的容器，不重新检查配置）。
5. 现状确认
- Ollama 模型： 如果Ollama 模型没下好，它在高强度占用你的硬盘 IO，这会导致 Docker 响应极慢。
- 内存检查： 看看任务管理器里的内存占用。如果已经到了 15GB/16GB，Dify 这种重型应用会因为频繁使用虚拟内存而导致网页“假死”。
如果还是不行，可以在终端输入，检查 API 容器的实时进度：
docker-compose logs -f api如果看到很多 MIGRATING 或 SUCCESS：说明它正在拼命创建数据库表，请继续耐心等待 3-5 分钟。
如果看到 Error: Connection refused：说明 API 还没连上数据库容器，可以再等一会。
也可以在浏览器页面按下 Ctrl + F5 进行强制刷新
或者尝试用浏览器的无痕模式（Ctrl + Shift + N）重新访问 http://127.0.0.1:8090
终极解决（如果超过 10 分钟还没动静）：
如果日志一直不更新，可能是由于内存不足导致某个关键容器启动失败，请重启 Dify：
docker-compose restart api web如果刷新后依然超过 1 分钟没动静，可以在终端运行，单独重启一下前端容器
docker-compose restart web重启后可以输入来查看前端日志：
docker-compose logs -f web记得要重新访问 http://127.0.0.1:8090或者刷新页面。
还是不行可以点击F12，查看控制台，如果出现了反复出现的红色报错：
TypeError: Failed to construct 'URL': Invalid URL 表明 Dify 的前端代码在尝试拼接访问地址时失败了。这通常是因为 .env 配置文件中的某个 URL 格式不规范（比如多了一个空格、少了一个 http:// 或者环境变量为空）。
1：检查并修正 .env 配置文件
从资源管理器中打开 \dify\docker 目录，用记事本打开 .env 文件。
检查空值或非法字符：确保没有任何一项 URL 开头的变量末尾带着空格。
补充协议头：确保所有涉及 URL 的变量都以 http:// 或 https:// 开头。
重点排查项：（可以给AI排查）
CONSOLE_API_URLCONSOLE_WEB_URLSERVICE_API_URLAPP_API_URLAPP_WEB_URL
可以统一设为 http://127.0.0.1:8090（这个是我的本地端口号，注意不要弄错了）
# 修改前：CONSOLE_API_URL= # 修改后： CONSOLE_API_URL=http://127.0.0.1:8090 # 修改前：CONSOLE_WEB_URL= # 修改后： CONSOLE_WEB_URL=http://127.0.0.1:8090 # 修改前：SERVICE_API_URL= # 修改后： SERVICE_API_URL=http://127.0.0.1:8090 # 修改前：APP_API_URL= # 修改后： APP_API_URL=http://127.0.0.1:8090 # 修改前：APP_WEB_URL= # 修改后： APP_WEB_URL=http://127.0.0.1:8090 # 修改这个触发地址 [cite: 5] TRIGGER_URL=http://127.0.0.1:8090并在文件末尾检查这个模板地址：
# 修改前：ENDPOINT_URL_TEMPLATE=http://localhost/e/{hook_id} # 修改后： ENDPOINT_URL_TEMPLATE=http://127.0.0.1:8090/e/{hook_id}修改完后同步 EXPOSE 端口设置，为了保险，建议在 .env 里也同步一下这个变量 ：
# 找到这两行 EXPOSE_NGINX_PORT=80 EXPOSE_NGINX_SSL_PORT=443 # 修改为： EXPOSE_NGINX_PORT=8090 EXPOSE_NGINX_SSL_PORT=443修改完 .env 后，在新的终端输入：
#彻底移除旧的配置残留 docker-compose down #重新根据新环境变量创建 docker-compose up -d修改完 .env 后让 Docker 重新读取配置：
在终端输入：
#关闭 docker-compose down #启动 docker-compose up -d第七步：成功打开Dify页面
成功打开后注册管理员账户，提供邮箱、名字、密码。然后就成功进入到Dify页面了。
鼠标移至右上角，打开设置。
点击模型供应商，进行安装Ollama（我这边已经安装完成了）
安装完后就是上图所示，点击添加模型：
模型类型：LLM
模型名称：（输入你所下载的模型名称，比如我下载的：qwen2.5-coder:7b）
基础 URL：http://host.docker.internal:11434
模型类型：对话
模型上下文长度：(虽然默认是 4096，但 Qwen2.5 支持更长。如果和我的一样是 16GB 的内存，设为 8192 或 16384 比较稳妥，既能看长代码又不会爆内存)
最大 token 上限：4096
是否支持 Vision (视觉)：否 (Qwen2.5-Coder 是纯文本/代码模型，不支持图片识别，建议选“否”以免报错)。
是否支持函数调用 (Tool Call)：是（这个是AI Agent 核心功能——比如让 AI 自动去查数据库或运行代码，全靠这个功能）
点击添加。
点击右上角的X或者点击ESC退出设置页面，回到主页面。
恭喜你完成了从零搭建 Dify + Ollama 本地 AI Agent！
下一次打开的步骤：
1：打开 Docker Desktop
2：打开 ollama
3：在 ~\dify\docker 进入终端，输入 docker-compose up -d
4：打开网址 http://127.0.0.1:8090（记得端口号不要输错，这个是我的端口号）
注意！！！：
输入完 docker-compose up -d 后，关闭终端不会关闭。需要输入，才可以关闭。
docker-compose down谢谢你的观看。
