寻书人最近我把手头的几个杂活——群消息自动回复、小说大纲整理、定时抓取热点——全部交给了一个叫 openclaw 的开源智能体框架，底层大脑用的是 DeepSeek 的云端模型，整套东西跑在 Docker 容器里。从零开始到正常跑起来，大概花了一个下午。这篇文章就把这套 "Docker + DeepSeek 云模型部署 openclaw" 的方案完整拆开来讲：openclaw 负责接收任务和调用工具，DeepSeek 负责生成内容，Docker 负责让这套组合在任何机器上都能一键跑起来。适合有一定命令行基础、想玩智能体但不想碰显卡和本地模型部署的同学。如果你已经在用 Docker 跑过别的服务，那这篇基本就是照着抄的事。
1. 这套组合到底在解决什么问题：openclaw、DeepSeek 与 Docker 的分工
很多人第一次看到 openclaw 这个名字，会下意识把它归类成"又一个聊天机器人"。但真正上手之后你会发现，它做的事情比聊天宽得多。它更像一个智能体调度中枢，负责接收各个渠道来的指令，调用背后的大模型去理解任务，再把任务拆解成具体的工具调用或者回复内容。而这个背后的模型，就是 DeepSeek 云模型。
1.1 openclaw 不是又一个聊天机器人，而是智能体的"调度中枢"
openclaw 是 ClawAI 社区维护的开源智能体框架，设计上走的是"渠道接入 + 多智能体编排 + 工具调用 + 记忆管理"这条路。它和那种套壳聊天机器人最大的区别在于，你可以在它身上挂多个渠道，比如微信、Telegram、网页、API，也可以给它配置多个不同角色的智能体，每个智能体有独立的人设、模型参数和工具权限。它还能在对话过程中自动决定要不要调用外部工具，比如查时间、做计算、抓网页、调接口，这些动作对大模型本身来说是不需要预置的，全部通过函数定义交给模型去判断。
我用一个不太严谨但很好理解的类比：DeepSeek 是一个知识渊博但只会动嘴的专家，openclaw 是这位专家的助理，负责接电话、记笔记、安排日程、跑腿。专家不关心电话是从微信打来还是从 Telegram 打来，也不关心日程要写进哪个表格，这些全是助理的事。openclaw 解决的就是"把大模型的能力真正落进具体场景"这一层问题。
1.2 DeepSeek 云模型：只出脑子，不出力气
DeepSeek 作为云模型，在这套架构里的角色就是"推理引擎"。openclaw 收到用户消息后，会把消息历史、人设、可用工具定义一起打包发给 DeepSeek 的 API，DeepSeek 返回生成结果，openclaw 再决定下一步动作。这个链路和调用 OpenAI 接口的逻辑几乎一样，因为 DeepSeek 对外提供的是 OpenAI 兼容接口，所以配置上非常顺手。
为什么选 DeepSeek 而不是其他模型？对我来说三个理由：第一，推理能力已经经过大量用户验证，尤其中文场景的生成质量很稳；第二，API 价格比海外主流模型低一个量级，个人拿来跑自动化任务，一天跑几千次调用也花不了几块钱；第三，国内直连畅通，没有额外的网络门槛。对于大多数个人项目来说，这三点就是你选模型时最实际的标准。
1.3 Docker：把复杂环境问题压缩成一个命令
openclaw 本身是通过 Node.js 写的，直接跑也不是不行，但环境问题会烦死你：Node 版本要求、依赖冲突、数据目录权限、不同操作系统上配置文件路径不一致。一旦涉及升级或者换机器，重来一遍非常痛苦。
Docker 的价值在于把整个运行时环境固化成一个镜像。你在自己机器上测得好好的，同事或者服务器上执行同一个命令，起出来的环境完全一致。openclaw 的数据是一个持久化的状态，里面包括对话历史、记忆、定时任务，所以在 Docker 里必须用数据卷把数据目录挂出来，这样容器删了重建，东西还在。后面第四章我会专门讲这个配置，这里先记住一个结论：所有需要长期保留的数据，都必须映射到宿主机目录，而不是存在容器内部。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先把 Docker 环境整干净：从安装到常见启动失败排查
不管你是 Windows、macOS 还是 Linux，第一步都是把 Docker 环境准备好。这个环节看起来简单，但我在帮朋友排查时发现，很多人卡在最开始的地方不是不会装，而是装完之后 Docker Desktop 起不来，然后直接弃坑。
2.1 Docker Desktop 与 Docker Engine 怎么选
如果你是个人开发机，建议直接用 Docker Desktop，它自带图形界面，还能管理容器状态、日志、资源占用，对新手很友好。Linux 服务器上则没必要装 Desktop，装 Docker Engine 就够了，体积更小，也没有 GUI 依赖。
安装方式这里不展开，主要提醒几个坑。Windows 上 Docker Desktop 依赖 WSL2，安装完 Docker Desktop 之后，最好在 PowerShell 里执行一下 wsl --update 把 WSL 内核更新到最新。macOS 上 Intel 芯片和 Apple Silicon 芯片下载的安装包不一样，注意别下错。Linux 上不同发行版的安装命令不同，但装完记得把当前用户加入 docker 组，否则每次都得 sudo，很烦。
2.2 Windows 上 Docker Desktop 启动失败，virtualisation support 不存在的排查链路
这是一个非常高频的错误。Docker Desktop 启动时报错"virtualisation support was not detected"或者类似的提示，很多人以为是 Docker 没装好，其实大概率是底层虚拟化没开。排查链路是这样的：
第一步，先确认 Windows 的虚拟化功能是否开启。打开 PowerShell（管理员），执行：
powershell复制systeminfo | Select-String "Hyper-V"
如果显示"已检测到虚拟机监控程序"或者"Hyper-V 要求: 已列出管理程序"，说明 CPU 虚拟化已经可用。如果显示"未检测到"，那大概率是 BIOS/UEFI 里 Intel VT-x 或者 AMD-V 没有打开，需要重启进 BIOS 开启。
第二步，确认 Windows 功能组件。在"启用或关闭 Windows 功能"里，把"虚拟机平台"和"适用于 Linux 的 Windows 子系统"两个选项勾上，重启机器。这一步经常被忽略，因为 Docker Desktop 安装程序不一定会自动帮你开启。
第三步，如果以上都没问题，但还是启动失败，检查一下是否装了其他虚拟化软件，比如 VirtualBox、VMware，有时候它们和 Hyper-V 会冲突。我遇到过一次很隐蔽的情况：电脑上装了一个旧版沙盒软件，把 Hyper-V 的资源占了，Docker Desktop 怎么都起不来，卸载之后立刻正常。
2.3 macOS 和 Linux 服务器上的注意点
macOS 上 Docker Desktop 的问题相对少，Apple Silicon 机器要注意的是有些老镜像没有 arm64 版本，跑起来会被 Rosetta 模拟，性能差不说，还可能报奇怪的错。部署 openclaw 这类 Node.js 应用基本不受影响，但如果后面你打算挂 NVIDIA NIM 之类的本地推理服务，就要特别注意架构匹配。
Linux 服务器上最常见的坑是磁盘空间不足。Docker 镜像、容器日志、数据卷都会占空间，跑一段时间后 /var/lib/docker 可能把根分区撑爆。建议在安装 Docker 之后顺手检查一下磁盘挂载，把 Docker 的数据目录指到有大空间的分区。
2.4 验证 Docker 与 Compose 状态
环境装好后，用两个命令验证：
bash复制docker --version
docker compose version
然后跑一个最小的容器确认整个链路是通的：
bash复制docker run --rm hello-world
看到 "Hello from Docker!" 的输出，说明 Docker 环境没问题了。这一步很有必要，至少能区分"问题出在 Docker 本身"还是"问题出在后面的 openclaw 配置"。
3. 拿 DeepSeek 云模型的钥匙：Key 申请、模型选型和成本控制
openclaw 本身不带模型能力，它需要一把钥匙去调用 DeepSeek 的云端 API。这一章讲两件事：怎么拿到钥匙，以及拿到之后怎么选模型参数。
3.1 API Key 申请流程
登录 DeepSeek 开放平台的控制台，注册账号，然后在"API Keys"页面创建一个新的 Key。创建的时候可以把 Key 命名为 openclaw，方便以后识别。创建完成后 Key 只会显示一次，务必备份到本地密码管理器里，丢了就得重新生成。
这里有个很多人踩过的坑：DeepSeek 平台账户余额和 API Key 是两回事，注册之后账户里是没钱的，需要先充值才能调用 API。充值可以按平台规则来，不用一次充太多，个人测试先充个最低档就够跑了。
Key 拿到之后，不要放在任何会提交到 Git 的文件里。后面我们会用 .env 文件管理环境变量，这个文件要写进 .gitignore。
3.2 deepseek-chat 还是 deepseek-reasoner
DeepSeek 平台目前对外提供两个模型名，一个是 deepseek-chat，对应通用对话模型，适合大多数场景；另一个是 deepseek-reasoner，对应深度推理模型，在复杂逻辑、代码生成、数学推理这类任务上表现更强，但响应时间更长，token 消耗也更大。
在 openclaw 这种智能体场景里，我个人的配置建议是：日常聊天、内容整理、写小说用 deepseek-chat，因为它快，成本低，响应及时；如果某个智能体专门负责代码审查或者复杂任务规划，可以单独给那个智能体配 deepseek-reasoner。openclaw 支持不同智能体用不同模型，这个灵活性很实用。
3.3 OpenAI 兼容格式带来的配置便利
DeepSeek 的 API 接口是 OpenAI 兼容格式，这意味着所有原本为 OpenAI 接口设计的工具、SDK、框架，只要把 base_url 改掉就可以无缝切换。在 openclaw 的配置里，我们需要告诉它三件事：API 地址指向 https://api.deepseek.com，模型名填 deepseek-chat，认证方式用 Bearer Token 带上你的 Key。
这个兼容性省了很多事。曾经有一段时间生态里出现了各种"deepseek harness""deepseek hermes"之类的名字，听起来五花八门，其实本质都是把 DeepSeek 的 OpenAI 兼容接口包装成不同的形态。你只要记住底层协议是一样的，就不容易被各种包装搞晕。
3.4 成本控制与上下文长度
云模型按 token 计费，所以成本控制的核心逻辑是减少无效 token。openclaw 在对话轮次增多后，会把整个历史记录发给模型，如果历史太长，单次请求的 token 消耗会指数级上升。
我的做法是在 openclaw 的配置里限制上下文长度，比如只保留最近 20 轮对话，或者按字符数截断。具体参数每个版本可能略有不同，但思路是一样的：不是所有历史都要让模型完整阅读，有些只影响短期连贯性的内容可以丢弃。另外，给智能体设置 yield（最大回复 token 数）也很重要，否则模型有时候会自作主张把回答拉得很长，完全没必要。
4. 手写 openclaw 的部署配置：从目录结构到 docker-compose
环境准备好，模型钥匙拿到手，接下来是重头戏：部署 openclaw。这一章我会给出一套可以直接落地的目录结构和配置方案。openclaw 的官方配置格式可能随版本更新有所调整，但核心思路不变，核心字段以官方仓库文档为准。
4.1 获取 openclaw 与目录规划
先建一个项目目录，比如：
bash复制mkdir -p ~/openclaw-app/{data,config}
cd ~/openclaw-app
openclaw 的获取方式有两种，一种是直接通过 npm 全局安装：
bash复制npm install -g @openclaw/openclaw
另一种是通过源码构建。更推荐的做法是把它封装进 Docker 镜像，这样同一套环境可以复制到任何机器上。我习惯的项目结构是这样的：
text复制openclaw-app/
├── .env
├── docker-compose.yml
├── Dockerfile
├── openclaw.yaml
└── data/
4.2 核心配置 openclaw.yaml：模型、智能体与渠道
openclaw 的配置集中在一个 YAML 文件里，下面是我用的一份示例配置：
yaml复制agents:
main:
model:
provider: deepseek
name: deepseek-chat
base_url: https://api.deepseek.com
api_key_env: DEEPSEEK_API_KEY
yield: 1024
context_window: 4096
tools:
- datetime
- web_search
channels:
web:
enabled: true
port: 8080
telegram:
enabled: false
db:
path: /app/data/openclaw.db
这里解释一下几个关键字段。agents.main.model 定义了主智能体使用的模型，api_key_env 表示 API Key 从环境变量 DEEPSEEK_API_KEY 读取，而不是直接写在文件里。yield 是单次回复最大 token 数，context_window 是上下文窗口大小，tools 列表声明了这个智能体可以调用哪些工具。channels.web 开启网页控制台，端口映射到容器的 8080。
在实际部署时，建议先把渠道只开 web 一个，跑通之后再增加微信、Telegram 这些渠道，每次只引入一个变量，排查问题会容易得多。
4.3 用 Dockerfile 把 openclaw 封装成镜像
openclaw 运行时基于 Node.js，官方如果有现成镜像，直接引用即可；如果没有，用 Dockerfile 封装也很简单：
dockerfile复制FROM node:20-slim
WORKDIR /app
RUN npm install -g @openclaw/openclaw
EXPOSE 8080
CMD ["openclaw"]
这个镜像很小，构建也快。注意工作目录 /app 下面我们要挂载配置和数据卷，所以在 compose 文件里要对应起来。
4.4 docker-compose.yml 编排：端口、数据卷与重启策略
docker-compose.yml 是整套容器编排的核心：
yaml复制services:
openclaw:
build: .
container_name: openclaw
ports:
- "8080:8080"
env_file:
- .env
volumes:
- ./openclaw.yaml:/app/openclaw.yaml:ro
- ./data:/app/data
restart: unless-stopped
这里有三处细节值得注意。
端口映射 "8080:8080" 冒号左边是宿主机端口，右边是容器端口。如果 8080 被占用，可以改成 "18080:8080"，只是访问地址也要跟着变。
数据卷 ./data:/app/data 解决了数据持久化问题。所有对话历史、记忆、数据库文件都存在宿主机 ./data 目录，容器删掉重建也不会丢数据。
restart: unless-stopped 让 Docker 在容器异常退出后自动重启。但要注意，如果配置本身有问题，容器会陷入反复重启的循环，所以后面有一章专门讲日志排查。
4.5 环境变量怎么传，不要在配置文件里硬编码 Key
在项目根目录创建 .env 文件：
bash复制DEEPSEEK_API_KEY=sk-你的key
docker-compose.yml 里用 env_file 引入这个文件，openclaw 内部通过配置里的 api_key_env 字段读取。千万注意：.env 文件不要提交到 Git，最好一开始就把它写进 .gitignore。我见过不少人在开源项目里把自己 API Key 传上去，结果被机器人扫到，几分钟内被盗刷。
5. 启动、验证与第一次对话
配置全部写完，就可以启动容器了。这个阶段的目标不是一步到位做多复杂的自动化任务，而是先确认整条链路是通的：手机/浏览器发消息 -> openclaw 接收 -> 调用 DeepSeek -> 返回结果。
5.1 docker compose up 之后看什么日志
在项目目录下执行：
bash复制docker compose up -d --build
-d 表示后台运行，--build 表示构建镜像。第一次启动会拉取基础镜像，时间取决于网络状况。启动后查看日志：
bash复制docker compose logs -f openclaw
正常的日志里会看到 openclaw 启动成功、模型连接就绪、web 渠道监听 8080 端口之类的信息。如果日志里出现 Error: Cannot find module 或者 Connection refused，那基本都是配置问题，不是代码问题，顺着报错信息往回查即可。
5.2 用 curl 验证 DeepSeek 链路是否打通
在 openclaw 跑起来之后，如果你怀疑问题出在模型调用，可以用 curl 直接测试 DeepSeek API，绕过 openclaw 做隔离验证：
bash复制curl https://api.deepseek.com/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $DEEPSEEK_API_KEY" \
-d '{"model":"deepseek-chat","messages":[{"role":"user","content":"你好"}]}'
返回一段 JSON，里面包含 choices[0].message.content，说明 API Key 和网络链路都没问题。那问题就只可能出在 openclaw 的配置上，缩小排查范围。
5.3 浏览器打开 Control UI
openclaw 的 web 渠道启动之后，浏览器访问 http://localhost:8080，一般就能进入 Control UI。这是它提供的图形管理界面，可以在里面直接和智能体对话，查看日志，管理会话。第一次进入如果页面空白或者报错，不要急着怀疑 openclaw 本身，先按后面第七章的排查思路走一遍。
5.4 修改配置后如何平滑重启
openclaw 的配置不支持全部热更新，改完 YAML 之后需要重启。简洁的方式是：
bash复制docker compose restart openclaw
如果改动了 Dockerfile 或者依赖，需要重新构建：
bash复制docker compose up -d --build --force-recreate
我个人的习惯是每次改动配置前先 docker compose cp 备份当前 data 目录，改坏了能马上还原。数据是无价的，多花几秒备份永远值得。
6. 从跑通到实用：接入微信、写小说与定时任务
部署只是开始，真正有意思的是让 openclaw 干活。这一章讲三个我实际用过的场景：接入微信、写小说、定时任务。每个场景背后其实都有一些容易忽略的细节。
6.1 渠道接入的真实情况与风险边界
openclaw 支持多个渠道，比如 Telegram、Discord、Webhook、API 等，这些接入方式相对正规。至于微信，需要特别谨慎：个人微信的自动化登录本身存在账号安全风险，可能违反平台用户协议。我自己测试时只用小号，并且不搞任何大规模群发、加好友之类的操作，只是做消息自动回复的验证。
如果你真的需要接入微信生态，更稳妥的思路是用企业微信的 API 或者服务号接口，这些是官方允许的接入方式，虽然配置流程长一些，但长期用下去更安全。openclaw 的渠道配置逻辑都差不多，核心是拿到对应的 bot token 或者 webhook 地址，再在配置里把对应 channel 的开关打开。
6.2 让 openclaw 帮你写小说：人物设定与上下文管理
写小说是 openclaw 社区里很火的玩法。核心思路不是让模型"临场发挥"，而是通过智能体的人设和系统提示词，把故事大纲、角色设定、文风要求全部固化下来。
我在配置里给小说智能体单独建了一个 agent，系统提示词大概是这样的思路：先告诉模型它是一名小说创作者，然后给它一段"世界观设定文档"，里面包括主线冲突、人物关系、关键伏笔，最后要求它每次只续写一章，字数控制在 1200 到 1500 字之间。openclaw 的工具能力在这时候也能派上用场，比如让智能体自动保存每次生成的内容到本地文件。
这里的坑在于上下文管理。小说写长之后，前面章节内容会超出 context window。我的做法是每次续写前只把最近两章内容作为参考上下文，再把一个"剧情备忘录"放在系统提示词里。备忘录是局部更新的，模型每次续写后，我会在提示词里附上一段自动生成的"当前剧情状态"，确保后续续写不会前后矛盾。
6.3 定时任务和工具调用怎么配
openclaw 的定时任务和工具调用是让智能体真正"自动化"的关键。定时任务在配置里声明，比如每天上午九点让智能体抓取某个网页的最新新闻，整理成摘要后发到指定渠道。工具调用则是给模型暴露一些函数接口，比如 web_search、datetime、http_request，模型会在需要的时候自动触发。
配这些功能的关键是谨慎授权。你允许智能体调用哪些工具、访问哪些资源，应该有明确边界。我一开始把 http_request 工具全放开，结果智能体在一次对话中主动访问了一个内网地址，虽然没有造成破坏，但提醒了我：工具权限是实打实的安全边界，不能图省事全部放开。
6.4 多人使用的并发与配额思路
如果多个人要共用一套 openclaw，建议在渠道层面对不同用户做隔离。最简单的方式是给不同用户分配不同的智能体，每个智能体有自己的模型配置和上下文窗口，避免互相干扰。
成本控制上，可以给不同智能体设置不同的 yield 和 context_window，限制单次请求的 token 上限。如果你的 DeepSeek API 冲了固定金额，还可以定期查一下账户消耗，看哪个智能体是耗 token 大户，再针对性调优。
7. 部署路上值得记录的坑与取舍
最后这部分是我实际跑下来觉得最值得记录的几件事。表面看每个都是小问题，但如果不提前知道，真的会卡住很久。
7.1 "control ui did not start"：先查端口和磁盘权限
你可能会在日志里看到 control ui did not start 之类的报错，或者在浏览器里打不开界面。这个问题的根源很少是 openclaw 本身挂了，绝大多数是下面两个原因之一。
第一个是端口被占用。你的宿主机上可能已经有别的服务占了 8080，Docker 端口映射起来后容器里的服务是好的，但宿主机访问不到。排查方法很简单：
bash复制lsof -i :8080
如果有其他进程占用了端口，换一个宿主机端口即可。
第二个是数据目录权限问题。容器内的 openclaw 进程需要读写的 /app/data 目录如果宿主机上没有对应权限，会导致启动过程中初始化失败，Control UI 跟着起不来。解决方法是把数据目录的属主改成容器内运行的用户，或者直接给一个宽松权限：
bash复制chmod -R 755 ~/openclaw-app/data
7.2 新手不建议一上来就碰 NVIDIA NIM
NVIDIA NIM 是一套本地推理微服务，可以让 openclaw 连接本地 GPU 跑模型。听起来很酷，但如果你之前没有折腾过 GPU 环境，我强烈建议第一版部署直接跳过。原因很简单：NIM 需要支持 CUDA 的镜像、显卡驱动、GPU 容器运行时，还要下载几个 GB 的模型权重。任何一个环节出错，排查成本都远超你省下的那点 API 费用。
先把 DeepSeek 云模型跑通，后面确实有隐私或者成本需求，再考虑本地化替换。openclaw 的模型层是抽象出来的，换模型基本就是改配置，不用重新搭建整体架构，这才是智能体框架应该有的样子。
7.3 云端模型和本地模型到底怎么选
和 NIM 类似的还有 Ollama 等本地模型方案。它们的优势是数据不出本机、无 API 调用成本，劣势是对硬件要求高，而且模型能力普遍打不过云端主力模型。我的判断标准很简单：如果你的任务容忍 2 至 5 秒的响应延迟，且对内容质量要求高，直接选云端模型；如果你的任务涉及隐私数据，或者需要长时间高频运行、成本敏感，才考虑本地模型。
在 openclaw 里切换这两者很轻松，因为配置层只关心"接口地址和模型名"这两个值。这让我觉得 openclaw 的一个隐藏价值是把模型的选择权留给了使用者，而不是绑定某一家。
7.4 YAML 缩进和其他低级但致命的错误
最后说一个看起来很低级、但几乎每个人都遇到过的坑：YAML 格式错误。openclaw.yaml 里只要一个字段缩进错了，整个配置就解析失败，容器启动直接退出。
我在第一次部署时遇到过一个很隐蔽的问题：model 字段下面的 name 被我不小心多缩进了两个空格，结果 openclaw 把 deepseek-chat 当成了某个不存在的嵌套对象，日志里报了一大串错误。排查了很久才发现是 YAML 缩进问题。
解决方法是借助工具，在本地预览 YAML：
bash复制python3 -c "import yaml,sys; yaml.safe_load(open('openclaw.yaml')); print('OK')"
能输出 OK 再启动容器，基本上能避免 80% 的启动失败问题。另外记得不要把中文标点符号混进配置里，YAML 解析器对全角冒号、全角逗号非常敏感，这个问题在真实场景里出现频率比想象中高得多。
最后再分享一个小技巧。openclaw 跑稳之后，我习惯定期用 docker compose exec openclaw sh 进入容器内部，看看日志文件和缓存目录的大小，顺手清理掉明显无用的临时文件。容器是进程隔离的好帮手，但数据卷还是会持续增长的，养成"容器可以随便删、数据必须常备份"的习惯，才敢在生产环境里长期依赖这套方案。