最近朋友圈里聊 AI 工作流的密度明显高了尤其是扣子Coze这类 Agent 编排平台和大模型接入的搭配。我自己的需求很明确想把扣子本地化部署起来再把 DeepSeek 大模型接进去组成一套自己可控的 AI 应用底座。折腾了大概两天踩了无数坑最后在 Windows 上用 Docker Desktop 把整套服务跑通了。为什么要写这篇文章因为我在动手之前查了一圈资料发现大部分教程都是面向 Linux 或 Mac 的Windows 用户遇到的问题——WSL2、虚拟化、磁盘占用、端口冲突——往往被一笔带过。所以我决定把整个过程完整记录下来包括为什么这么选型、每一步怎么操作、中间踩了哪些坑、最后的配置长什么样。这篇文章适合三类人想在本地搭 Agent 开发环境但一直卡在 Windows 准备环节的读者想用低成本把 DeepSeek 接进可视化编排平台做私域工具的读者以及单纯想了解 Docker Desktop 部署多容器服务栈、想少走弯路的读者。内容偏实操基础概念会带一句但不会啰嗦到从零讲 Docker。1. 本地部署扣子到底图什么场景拆解与技术选型1.1 扣子能做什么以及本地版和云端的区别要理解这次部署的价值先说清楚扣子是个什么东西。它的本质是一个 Agent 编排平台把大模型、插件、知识库、工作流、定时任务这些能力用可视化方式串起来。你可以用它搭一个电商客服机器人、一个自动写周报的助手、一个带知识库的文档问答系统甚至是一个复杂的多智能体协作流程而不需要写太多后端代码。云端版的好处是开箱即用、模型丰富可缺点也很明显数据都在别人的服务器上插件生态虽然大但受平台管控调试过程中想看一眼底层请求日志也比较费劲。社区本地版的意义在于编排能力、插件机制、数据存储全部落到自己手里你可以放心地把内部文档、数据库内容接进来也可以随意缝接外部 API。我当时最直接的动机是做一个内部知识库问答助手涉及一些不方便传到公网的文档。如果直接用云端版光是数据合规这一关就要纠结半天而本地部署之后所有数据都在自己机器上这个问题自然就消失了。另外本地版在调试工作流时可以逐节点查看输入输出对排查问题来说实在太重要了。1.2 为什么用 Docker 而不是原生安装扣子本地版不是一个单文件程序它的运行依赖数据库、缓存、对象存储等好几个组件。如果采用原生安装意味着要手动装 MySQL、Redis、MinIO还要处理版本依赖和 Windows 服务冲突。Docker 的价值是把这些依赖全部打包成容器一条 compose 命令就能把整个服务栈拉起来。迁移、备份、重置也都是删除重建的事非常契合这类多组件的应用形态。我见过不少人在 Windows 上对 Docker Desktop 有顾虑觉得内存占用高、启动慢。说实话这个顾虑有一定道理但比起手动维护一套 MySQL Redis MinIO 应用服务的原生环境Docker Desktop 的开销是值得的。毕竟后面升级版本、迁移机器、回滚配置都是容器的常规操作省下来的时间远超多花的那点内存。1.3 模型层为什么选 DeepSeek模型选择是这套部署里最关键的一环。DeepSeek 有两个特点让我最终定了它一是接口兼容 OpenAI 的 Chat Completions 格式这意味着任何支持 OpenAI 协议的编排平台都能快速接入不需要写定制 SDK二是它在推理任务上的表现非常能打尤其是 deepseek-reasoner 这类推理模型适合塞进复杂工作流里替代人工判断环节。还有一个更现实的理由成本。DeepSeek 的 API 价格比主流海外模型有数量级的优势在本地调试阶段可以放心大胆地反复调用不用时刻盯着账单。对于个人开发者或者小团队来说这是很实际的考量。如果只是自己用、或者做内部小工具模型调用成本几乎可以忽略不计。2. 前置条件Docker Desktop 在 Windows 上的安装与磁盘迁移2.1 先确认虚拟化环境和 WSL2Docker Desktop 在 Windows 上最稳妥的运行模式是 WSL2 后端所以在装 Docker 之前得先确认两件事。第一CPU 虚拟化是否已在 BIOS 中开启。打开任务管理器切到性能标签右下角会显示虚拟化已启用或已禁用。如果显示禁用需要进 BIOS 开启 Intel VT-x 或 AMD-V/SVM。不同主板菜单位置不一样但关键词就是 Virtualization Technology 或 SVM Mode。第二Windows 功能里是否启用了适用于 Linux 的 Windows 子系统和虚拟机平台。最快的检查方式是在管理员 PowerShell 里执行wsl --status如果没有输出 WSL 版本信息就执行wsl --install安装然后重启系统。我当时就是忽略了第二步Docker Desktop 装完后一直报 WSL 内核错误折腾了半小时才发现系统没装 WSL。这个顺序问题值得提醒所有人先装 WSL、再装 Docker Desktop顺序反了会多一些无谓的报错。2.2 Docker Desktop 安装选项与资源分配从 Docker 官网下载 Docker Desktop for Windows 安装包安装过程中保持默认勾选使用 WSL 2 而不是 Hyper-V即可。安装完成后进入 Settings - General确认勾选了 Use the WSL 2 based engine。这一步决定了 Docker 跑在 WSL2 还是 Hyper-V 上WSL2 的启动速度和资源管理都更好。然后重点来了资源分配。Settings - Resources - Advanced 里可以调整 CPU 和内存上限。比如我本机是 32G 内存给 Docker 分配了 8G如果你只有 16G 内存建议先给 4~6G。Coze 整栈跑起来大约需要 3~5G留一点余量给系统和其他程序。Swap 可以设置 2G避免内存紧张时直接 OOM。这里有个容易忽略的点资源上限不是越大越好。给 Docker 的配额太大WSL2 会在后台占用大量物理内存导致其它应用越来越卡配额太小模型加载、容器构建又会频繁报错。我给自己的经验值是总内存 16G 给 Docker 6G32G 给 8G比较均衡。2.3 把 Docker 数据迁出系统盘不少人装完 Docker Desktop 后会发现 C 盘空间急剧减少因为默认镜像和容器数据都存在系统盘的 vhdx 文件里。如果你有 D 盘或其他数据盘最好在装完 Docker 后立刻迁移。具体做法Settings - Resources - Advanced找到 Disk image location把虚拟磁盘位置改成 D:\DockerData 之类的目录点击 Apply Restart。Docker Desktop 会重新初始化原来的镜像和容器会被清空所以这个操作最好在安装早期、还没拉取镜像之前就完成。我就是先跑了一堆镜像才想起来迁移结果重新拉了一遍镜像白白浪费了流量和时间。2.4 镜像加速配置拉取 Coze 相关的几个基础镜像MySQL、Redis、MinIO 等时直接在默认网络环境下拉取 Docker Hub 镜像经常会碰到超时。标准做法是在 Settings - Docker Engine 里配置 registry-mirrors填入一个你当前网络环境下可用的镜像加速地址保存后 Docker 会重启。配置前缀是registry-mirrors的那段 JSON填完保存后拉取速度会有明显改善。需要注意镜像加速只对 Docker Hub 服务端有效如果你后续自己构建镜像时又去拉其它外部源速度问题要单独处理。另外不要同时配置太多镜像源有些源同步不及时反而会报 manifest 找不到的错误一个稳定可用的加速地址就够了。3. 用 Compose 拉起 Coze 服务栈镜像、端口与数据卷3.1 服务栈里都有什么扣子社区版的部署不是单一容器而是由多个组件组成。从官方仓库的编排文件来看最少包含四个部分主应用服务承载扣子平台的 Web 界面、API 服务和工作流引擎MySQL保存用户、应用、流程定义等结构化数据Redis处理会话缓存、任务队列和临时状态MinIO对象存储用于知识库文件、附件等非结构化数据。这个架构并不复杂但缺一不可。数据库挂了平台直接起不来Redis 挂了会话和任务队列会异常MinIO 挂了知识库文件传不上去。所以部署时我给每个组件都挂了独立的数据卷防止容器重建后数据归零。3.2 编排文件的写法与参数说明以官方仓库为准的话直接拉取仓库里的 docker-compose.yml 然后执行docker compose up -d是最省事的方式。如果你想自己写编排下面这个最小结构可以参考。我特意把镜像名写成了占位符因为社区版迭代很快镜像 tag 变化也频繁真正部署时请使用官方仓库里指定的名称和版本。services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: your_password MYSQL_DATABASE: coze volumes: - mysql_data:/var/lib/mysql restart: always redis: image: redis:7-alpine volumes: - redis_data:/data restart: always minio: image: minio/minio:latest command: server /data --console-address :9001 environment: MINIO_ROOT_USER: coze_admin MINIO_ROOT_PASSWORD: your_password volumes: - minio_data:/data restart: always coze-studio: image: your-image-placeholder/coze-studio:latest ports: - 127.0.0.1:8000:80 environment: DB_HOST: mysql DB_PORT: 3306 DB_USERNAME: root DB_PASSWORD: your_password DB_NAME: coze REDIS_HOST: redis REDIS_PORT: 6379 MINIO_ENDPOINT: http://minio:9000 volumes: - coze_data:/app/data depends_on: - mysql - redis - minio restart: always volumes: mysql_data: redis_data: minio_data: coze_data:这里注意几个点。第一服务名不要乱改因为容器之间是通过服务名做网络通信的改完之后环境变量里的 HOST 也要同步改。第二restart: always建议加上Windows 偶尔重启后 Docker 服务能自动拉起来减少人工干预。第三端口映射8000:80表示宿主机的 8000 端口转发到容器的 80 端口如果 8000 被占了可以换成 127.0.0.1:8000:80 或者换其它端口。我在示例里直接写了本机监听方式这样也能减少外网暴露风险。3.3 首次启动与初始化检查执行docker compose up -d之后用docker compose ps查看容器状态正常情况下所有容器都会显示 running。如果某个容器反复重启用docker compose logs 服务名看日志。最常见的两类问题一是 MySQL 还没初始化完成主服务就连不上数据库了解决办法是给 MySQL 加healthcheck或者在主服务启动前等待 30 秒二是 MinIO 的 bucket 没创建导致文件上传报错需要在初始化阶段确认 bucket 已经建好或者由初始化脚本自动创建。主服务起来后浏览器访问 http://localhost:8000会进入初始化页面设置管理员账号和密码。这个账号后面登录控制台要用建议立刻记到密码管理器里。初始化完成后你会看到一个跟云端版风格很接近的工作台界面到这里部署就算完成了大半。4. 把 DeepSeek 接进扣子自定义模型供应商配置全记录4.1 申请 DeepSeek API KeyDeepSeek 开放平台上有两个模型值得关注deepseek-chat 和 deepseek-reasoner。前者是通用对话模型延迟低、价格便宜适合大多数日常 Agent 场景后者是推理增强模型会在回答前生成思维链适合需要复杂推理的任务比如代码审查、数据分析、多步骤规划。申请流程很简单注册开放平台账号进入 API Keys 页面创建一个新的 Key记下来。Key 只会完整显示一次漏看就只能重新生成。费用方面DeepSeek 按 token 计费新用户一般会有赠送额度个人调试完全够用。4.2 在扣子控制台配置自定义模型进入扣子工作台后找到模型配置相关的入口。不同版本的菜单位置可能有差异一般在设置、模型管理或模型供应商这类菜单下。添加一个 OpenAI 兼容的自定义供应商供应商名称填 DeepSeekBase URL填 https://api.deepseek.com/v1API Key填上一步申请的 sk- 开头密钥模型列表至少填上 deepseek-chat 和 deepseek-reasoner请求方式选择 OpenAI 兼容协议保存后扣子会发起一次连通性测试如果返回模型列表正常说明网络和鉴权都没问题。这里有个细节Base URL 到底带不带/v1要看 DeepSeek 官方文档当前的说明实际上是兼容两种写法的但如果你遇到 404优先检查这个字段。4.3 参数推荐与实测对比模型接进来之后具体参数怎么设置我给出我实测后比较稳的组合温度Temperaturedeepseek-chat 日常任务调到 0.7 左右创意写作可以到 1.0deepseek-reasoner 建议默认或更低因为推理模型本身已包含判断机制温度太高会显得发散。最大 Token按任务类型设长文写作调到 4096 以上简单问答 1024 就够设得太大反而增加等待时间。超时时间如果网络波动较大建议把超时时间从默认的 30 秒调到 60 秒避免工作流中途失败。实测下来deepseek-chat 在普通问答和工具调用场景的响应速度大约 1~3 秒deepseek-reasoner 因为要生成思维链会慢一些但在复杂逻辑任务上的准确率明显更高。我一般把 reasoner 用在判责、分类、决策这类场景把 chat 用在生成、改写、总结这类场景。4.4 把 DeepSeek 挂到 Agent 工作流里配置好模型供应商后在创建 Agent 或工作流时选择 DeepSeek 作为默认模型即可。比较推荐的做法是入口对话层用 deepseek-chat 保证响应速度工作流内需要进行数据提取、逻辑判断的节点用 deepseek-reasoner 提升准确率。这样既省钱又稳。另外扣子的插件机制也可以把 DeepSeek 的能力封装成一个自定义插件在工作流里以节点方式调用。我实际用下来这种方式适合你不希望所有请求都走同一个模型的场景比如让某一个节点固定用 reasoner 做代码审查而整体的对话继续用默认模型。这种灵活度是本地版比云端版顺手的地方。5. 踩坑实录两天内遇到的四个关键报错与排查链路5.1 虚拟化未开启导致 Docker 启动失败第一次打开 Docker Desktop右下角图标一直处于异常状态点开看报错提示 WSL2 相关的虚拟化组件不可用。我一开始以为是 Docker 安装坏了重装两遍没用最后才定位到是 BIOS 里的虚拟化开关没打开。排查链路是这样的先用任务管理器确认虚拟化已启用发现显示禁用于是重启进 BIOS找到 SVM ModeAMD 平台改为 Enabled保存重启后再启动 Docker Desktop问题消失。这个坑本身不复杂难的是容易下意识认为是软件问题而忽略硬件开关。建议所有人在安装前先花一分钟做这个检查。5.2 端口冲突8000 被本地服务占用Coze 主服务默认映射到 8000 端口结果我启动后浏览器访问一片白docker compose ps显示容器一直在 restarting。查日志发现是端口绑定失败因为我本机某个服务已经占用了 8000。排查和修复都不难用netstat -ano | findstr :8000找到占用进程的 PID再在任务管理器里结束它或者直接改 compose 里的端口映射把宿主机端口换掉。我最终选择了后者把端口改为 127.0.0.1:8010:80这样既解决了冲突也只在本机监听降低了被局域网内其它设备访问的风险。5.3 容器重启丢数据问题出在卷挂载有一段时间我频繁改配置动不动就docker compose down docker compose up -d结果发现之前创建的 Agent 全没了。查了一圈才意识到我在最初的编排文件里忘了给 MySQL 和 MinIO 声明数据卷容器一删数据跟着烟消云散。修复方法是把上面编排文件里的volumes段补上并在宿主机上指定一个明确的目录比如D:\DockerVolumes\mysql_data:/var/lib/mysql。这样即使容器重建数据也留在宿主机磁盘里。这里想提醒一句数据卷的配置一定要在第一次启动前就写进 compose 文件否则后期再补上加数据卷容器可能读取不到已有数据反而更麻烦。5.4 DeepSeek 调用超时与并发限制模型接好后第一个 Agent 跑起来经常在调用 DeepSeek 时超时。我先看了扣子的日志发现请求确实发出去了但响应迟迟不回。又去 DeepSeek 开放平台后台看调用记录发现系统返回了限流状态码。这里的根因是我在测试工作流里同时发起了多个并发请求而免费档次的并发限制比较低。解决方案分两层一层是在扣子侧调低工作流的并发数把重试机制打开另一层是在 DeepSeek 侧检查当前账户的速率限制如果确实需要高并发考虑升级或对请求做排队。经过调整后工作流的成功率从 70% 左右提升到了接近 100%。6. 部署完成之后资源控制与应用扩展建议6.1 优化 Docker 资源占用部署完 Coze 全栈后我观察了几个小时的资源占用内存基本维持在 4~5GCPU 在空闲时很低但启动瞬间会有明显尖峰。如果你的电脑内存只有 16G建议把 Docker Desktop 的内存上限控制在 4G再给 WSL2 单独配置.wslconfig文件限制总内存避免 Docker 把系统内存吃满导致卡顿。具体做法是在用户目录下创建.wslconfig文件写上memory4GB和processors2之类的限制然后重启 WSL。这是我在资源紧张时比较常用的手段实测对日常使用影响不大但能让系统整体稳定很多。6.2 本地知识库与 DeepSeek 的配合Coze 本地版自带知识库功能可以把 PDF、Word、Markdown 文档传到 MinIO在 Agent 里通过知识库检索来增强回答。这一块配合 DeepSeek 的 reasoner 模型效果很好RAG 检索到的内容加上推理模型的归纳能力能够把企业内部文档问答做成一个实用的私域助手。我建议把文档切分粒度控制在 500~800 字之间太小则上下文碎片化太大则检索噪音多。扣子控制台里有对应的分段设置调一次就能感受到效果差异。这个细节在网上很少被提到但实际影响很大。6.3 后续扩展定时任务与多 Agent部署的价值在于长期使用。扣子本地版的定时任务功能可以让 Agent 每天早上自动汇总邮件、生成日报多 Agent 协作可以把客户咨询拆成多个子 Agent 并行处理。这些都是云端版也有的能力但本地部署后不受平台调用额度限制自由度更高。我下一步的计划是把它接进团队内部的项目管理系统让 Agent 自动更新任务状态、整理每周迭代记录。如果你也准备长期用建议养成定期备份数据卷的习惯这一步的成本很低但在出事时会帮你省下大量恢复时间。最后分享一个我在这次部署中养成的小习惯每次修改完编排文件或模型配置都会先把旧的 docker-compose.yml 复制一份带日期的备份再往上改。听起来很笨但前后两天里我靠这个习惯三次回滚到可用状态省掉了大量重新排查的时间。Windows 上跑 Docker 服务栈其实没有那么可怕只要把虚拟化、WSL2、数据卷这三件事在动手前想清楚后面基本就是按流程走的问题了。