企业官网建设流程全解析

1. 为什么要把 OpenClaw 塞进容器里跑

OpenClaw 这个项目最近在 Agent 圈子里讨论度不低，它把 gateway（网关）和 controlUi（控制台）拆成两个独立组件，一个负责模型请求的路由与转发，一个负责可视化操作和会话管理。听起来挺清晰，但真到部署环节，很多人第一步就卡住了：Node 版本不对、全局包权限报错、gateway 起来了 controlUi 连不上、设备配对一直 pending。我试过在裸机上折腾了两小时，最后还是决定用 docker-compose 把整条链路封起来。

容器部署 OpenClaw 的核心价值在于：把 Node 运行时、全局 npm 包、配置文件路径、端口映射全部固化到镜像和 compose 文件里，换台机器docker-compose up -d --build就能复现。更重要的是，gateway 和 controlUi 之间的通信走的是容器内网络，你不需要在宿主机上装一堆依赖，也不用担心~/.openclaw/openclaw.json被不同用户权限搞乱。

这篇文章面向的是想快速跑通 OpenClaw 全链路的开发者，尤其是那些准备把模型调用统一走 TaoToken 通道的人。我会给出可直接复制的 docker-compose 配置、环境变量设置、gateway 路由参数，以及 controlUi 打开后如何验证请求是否正常返回。整个过程不需要你提前理解 OpenClaw 的内部架构，跟着步骤走就行。

先说清楚两个组件的分工。gateway 是实际处理模型请求的服务，它监听一个端口（默认 18789），接收来自 controlUi 或其他客户端的调用，然后根据配置把请求转发到上游模型 API。controlUi 是一个 Web 界面，你可以在浏览器里打开它，配置令牌、发起对话、查看设备配对状态。两者通过 gateway 暴露的 HTTP 接口通信，所以容器网络里 gateway 必须先起来，controlUi 才能连上。

用 docker-compose 的好处是，你可以把 gateway 和 controlUi 定义成两个 service，用depends_on控制启动顺序，用volumes把配置文件挂进去，用ports把 controlUi 的 Web 端口暴露给宿主机。这样每次调试只需要改 compose 文件或环境变量，不用进容器手动改配置。

还有一个容易被忽略的点：OpenClaw 的设备配对机制。第一次用 controlUi 连接 gateway 时，gateway 会生成一个待批准的设备请求，你需要在容器内执行openclaw devices approve <requestId>才能完成配对。这个步骤在裸机部署时经常因为权限或路径问题失败，但在容器里，只要 gateway 进程在运行，配对命令就能正常执行。

所以整体思路是：先用 docker-compose 把 gateway 和 controlUi 的容器跑起来，然后在容器内安装 OpenClaw CLI、启动 gateway、配置 controlUi 的令牌，最后在宿主机浏览器里打开 controlUi 完成设备配对。模型调用统一走 TaoToken 的 Key 和 API 通道，这样你不需要在容器里配一堆上游厂商的密钥，只需要一个 TaoToken 的 Key 就能切换不同模型。

2. TaoToken 前置准备：Key、Base URL 与模型 ID 怎么拿

在写 docker-compose 之前，你需要先把 TaoToken 的接入信息准备好。这部分不复杂，但顺序不能乱，否则后面 gateway 启动时会因为缺少环境变量而报错。

首先打开 TaoToken 官网（https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=），注册并登录后进入控制台。如果你已经有账号，直接进 console 页面。在控制台左侧找到「API Keys」或「密钥管理」，点进去创建一个新的 Key。创建时建议给 Key 起一个能识别用途的名字，比如openclaw-gateway，这样以后排查问题时能快速定位是哪个服务在用。

创建完成后，你会看到一串以sk-开头的字符串，这就是你的 API Key。复制下来保存到安全的地方，因为页面刷新后可能不再完整显示。这个 Key 后面会写进 docker-compose 的环境变量里，gateway 用它来调用 TaoToken 的模型接口。

接下来确认 Base URL。TaoToken 的 API 地址是https://taotoken.net/api，注意这里不要加 UTM 参数，直接写这个地址就行。gateway 在转发请求时会把 Base URL 和具体的模型路径拼接起来，所以你在配置里只需要填这个根地址。

模型 ID 这块，TaoToken 支持多种模型，你可以在控制台的模型列表里看到可用的模型标识。常见的比如claude-sonnet-4-20250514、gpt-4o等，具体以你控制台显示的为准。选一个你常用的模型 ID，后面在 gateway 的路由配置里会用到。

如果你打算长期跑 Agent 或编码任务，可以考虑开通 Coding Plan，这样在调用频率和额度上会更宽松。入口在控制台的套餐页面，按需选择就行。对于只是验证链路的场景，普通按量计费的 Key 就够用了。

还有一个细节：TaoToken 的 API 文档里有详细的请求示例和参数说明，建议在配置 gateway 之前先扫一眼文档，确认你用的模型 ID 和请求格式。文档入口在控制台顶部导航或官网的「文档」链接里。这样后面 gateway 报错时，你能快速判断是 Key 问题、Base URL 问题还是模型 ID 写错了。

把这三样东西准备好：API Key、Base URL（https://taotoken.net/api）、Model ID。接下来就可以写 docker-compose 文件了。

3. 可复制的 docker-compose 配置与 gateway 路由设置

这一节是整篇文章的核心，我会给出完整的 docker-compose.yml、环境变量文件、gateway 配置文件，以及 controlUi 的 settings 片段。你只需要把 TaoToken 的 Key 和模型 ID 替换成自己的，就能直接跑起来。

先看目录结构。建议在宿主机上建一个项目目录，比如openclaw-deploy，里面放以下文件：

openclaw-deploy/ ├── docker-compose.yml ├── .env ├── config/ │ └── openclaw.json └── Dockerfile

docker-compose.yml定义两个 service：gateway和controlui。gateway 负责跑 OpenClaw 的网关进程，controlui 负责跑 Web 控制台。两者共享一个自定义网络，这样 controlui 可以通过服务名访问 gateway。

version: "3.9" services: gateway: build: context: . dockerfile: Dockerfile container_name: openclaw-gateway restart: unless-stopped env_file: - .env volumes: - ./config:/root/.openclaw - ./logs:/var/log/openclaw ports: - "18789:18789" networks: - openclaw-net command: > sh -c "openclaw gateway run --bind lan --port 18789 > /var/log/openclaw/gateway.log 2>&1" controlui: build: context: . dockerfile: Dockerfile container_name: openclaw-controlui restart: unless-stopped env_file: - .env volumes: - ./config:/root/.openclaw ports: - "3000:3000" networks: - openclaw-net depends_on: - gateway command: > sh -c "openclaw controlui run --port 3000 --gateway http://gateway:18789" networks: openclaw-net: driver: bridge

这里有几个关键点。gateway 的--bind lan表示监听所有网络接口，这样容器内的 controlui 和宿主机都能访问。端口 18789 映射到宿主机，方便你直接用 curl 测试。controlui 的--gateway参数指向http://gateway:18789，这里用的是 Docker 内部的服务名解析，不需要写 IP。

Dockerfile负责安装 Node 和 OpenClaw CLI：

FROM node:20-slim RUN apt-get update && apt-get install -y \ curl \ ca-certificates \ && rm -rf /var/lib/apt/lists/* RUN npm install -g openclaw@latest WORKDIR /root EXPOSE 18789 3000 CMD ["openclaw", "--help"]

.env文件放 TaoToken 的接入信息：

TAOTOKEN_API_KEY=sk-你的实际Key TAOTOKEN_BASE_URL=https://taotoken.net/api TAOTOKEN_MODEL_ID=claude-sonnet-4-20250514 OPENCLAW_GATEWAY_TOKEN=your-gateway-token-here

OPENCLAW_GATEWAY_TOKEN是 controlUi 连接 gateway 时用的令牌，你可以自己生成一个随机字符串，比如用openssl rand -hex 16。

config/openclaw.json是 gateway 的核心配置文件，定义模型路由和 controlUi 的接入参数：

{ "gateway": { "bind": "lan", "port": 18789, "token": "your-gateway-token-here" }, "controlUi": { "enabled": true, "gatewayUrl": "http://gateway:18789", "token": "your-gateway-token-here" }, "models": { "default": { "provider": "taotoken", "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的实际Key", "modelId": "claude-sonnet-4-20250514" } }, "routes": [ { "path": "/v1/chat/completions", "target": "taotoken", "model": "claude-sonnet-4-20250514" } ] }

注意controlUi.gatewayUrl写的是http://gateway:18789，这是容器内网络地址。如果你在宿主机浏览器访问 controlUi，controlUi 的 Web 服务会通过这个地址去连 gateway，所以必须用服务名而不是 localhost。

如果你用的是 Cline MCP 或 Codex 的auth.json方式接入，配置逻辑类似，核心三件套是 Base URL、Key、Model ID。Cline 的 MCP 配置里，baseUrl填https://taotoken.net/api，apiKey填你的 Key，model填模型 ID。Codex 的auth.json里对应字段是api_base、api_key、model。CC Switch 的场景下，你在切换配置时确保这三个字段指向 TaoToken 即可。

把文件都建好后，执行：

docker-compose up -d --build

第一次构建会拉取 Node 镜像并安装 OpenClaw，可能需要几分钟。构建完成后，用docker-compose ps确认两个容器都是 Up 状态。

4. 验证请求：从 gateway 日志到 controlUi 连接成功

容器起来之后，先别急着开浏览器。按顺序验证 gateway 是否正常监听、模型请求是否能通、controlUi 是否能连上，这样出问题时能快速定位是哪一层的问题。

第一步，看 gateway 日志：

docker-compose logs -f gateway

如果配置正确，你会看到类似gateway listening on 0.0.0.0:18789的输出。如果报错EADDRINUSE，说明端口被占用，改一下 compose 里的端口映射。如果报config file not found，检查config/openclaw.json是否挂载到了/root/.openclaw目录下。

第二步，在容器内测试模型请求。进入 gateway 容器：

docker exec -it openclaw-gateway sh

然后用 curl 发一个请求：

curl -X POST http://localhost:18789/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer your-gateway-token-here" \ -d '{ "model": "claude-sonnet-4-20250514", "messages": [{"role": "user", "content": "你好，请回复ok"}] }'

如果返回的 JSON 里有choices字段和模型回复内容，说明 gateway 到 TaoToken 的链路是通的。如果返回 401，检查.env里的TAOTOKEN_API_KEY是否正确，以及openclaw.json里的apiKey是否和.env一致。如果返回local proxy failed或连接超时，检查baseUrl是否写成了https://taotoken.net/api，不要多写或少写路径。

第三步，打开 controlUi。在宿主机浏览器访问http://localhost:3000。页面加载后，你会看到一个令牌输入框。把OPENCLAW_GATEWAY_TOKEN的值粘贴进去，点击连接。

这时候可能会出现设备配对提示。controlUi 会显示一个待批准的设备请求，你需要回到容器内执行批准命令。先列出待配对设备：

docker exec -it openclaw-gateway openclaw devices list

输出里会有一个requestId，复制它，然后执行：

docker exec -it openclaw-gateway openclaw devices approve 5f2ec3ce-ae5b-4edb-9aa0-68fa5a062df5

把5f2ec3ce-ae5b-4edb-9aa0-68fa5a062df5替换成你实际的 requestId。批准成功后，gateway 日志里会显示设备已配对的信息。回到 controlUi 页面，点击概览中的连接按钮，这次应该能正常进入控制台。

第四步，在 controlUi 里发一条测试消息。如果能看到模型回复，说明整条链路——controlUi → gateway → TaoToken → 模型——全部打通。如果 controlUi 显示连接成功但发消息没反应，检查 gateway 日志里是否有reading choices相关的报错，这通常是模型 ID 写错或 TaoToken 返回格式不匹配导致的。

验证模型对话是否正常，也可以直接用 TaoToken 的模型对话入口测试，确认 Key 本身没问题。如果那边能通，问题就在 gateway 配置上。

5. 常见报错排查：401、local proxy failed、reading choices、OAuth

这一节整理几个我在部署过程中实际遇到的报错，以及对应的排查思路。你遇到问题时可以按这个顺序对照。

401 Unauthorized：最常见的原因是 Key 写错或没生效。先检查.env里的TAOTOKEN_API_KEY是否以sk-开头，有没有多余空格。然后确认openclaw.json里的apiKey和.env一致。如果都没问题，进容器执行echo $TAOTOKEN_API_KEY看环境变量是否真的传进去了。有时候 docker-compose 改了.env但没重启容器，环境变量不会更新，需要docker-compose down && docker-compose up -d。

local proxy failed：这个报错通常出现在 gateway 尝试连接上游 API 时。检查baseUrl是否写成了https://taotoken.net/api，注意不要写成https://taotoken.net/api/v1或带其他路径。另外确认容器内能解析和访问外网，可以用docker exec -it openclaw-gateway curl -I https://taotoken.net/api测试连通性。如果容器网络有问题，检查 docker 的 DNS 配置。

reading choices 报错：这个一般发生在 gateway 收到上游响应后解析失败。原因可能是模型 ID 写错了，TaoToken 返回了错误信息而不是正常的 choices 结构。检查openclaw.json里的modelId是否和控制台里显示的完全一致，大小写和连字符都不能错。另外确认请求体里的model字段和配置里的modelId一致。

OAuth 相关报错：如果你在 controlUi 里看到 OAuth 授权失败的提示，通常是因为 gateway 的 token 配置和 controlUi 里输入的不匹配。检查openclaw.json里的gateway.token和.env里的OPENCLAW_GATEWAY_TOKEN是否一致。如果不一致，改完后重启 gateway 容器。另外，设备配对没批准也会导致 OAuth 流程中断，按第 4 节的步骤执行openclaw devices approve即可。

controlUi 页面空白或连不上：先确认 controlui 容器是否在运行，docker-compose ps看状态。如果容器频繁重启，看日志docker-compose logs controlui。常见原因是--gateway参数指向的地址不对，容器内必须用服务名http://gateway:18789，不能用localhost。另外确认 controlui 的端口映射是否正确，宿主机访问的是http://localhost:3000。

gateway 启动后立即退出：检查openclaw.json的 JSON 格式是否合法，可以用python -m json.tool config/openclaw.json验证。如果配置文件里有注释或尾随逗号，会导致解析失败。另外确认config目录的挂载路径是否正确，容器内路径是/root/.openclaw。

排查时养成看日志的习惯，gateway 和 controlui 的日志分别用docker-compose logs -f gateway和docker-compose logs -f controlui查看。大部分问题在日志里都有明确提示。

6. 把模型调用统一走 TaoToken 的长期实践

链路跑通之后，你可以把 OpenClaw 的模型调用固定走 TaoToken 通道，这样后续切换模型或调整额度都在 TaoToken 控制台操作，不用改 gateway 配置。具体做法是在openclaw.json的models.default里把provider设为taotoken，baseUrl和apiKey指向 TaoToken。如果以后要换模型，只改modelId就行。

对于需要长期跑 Agent 或编码任务的场景，建议开通 Coding Plan，这样在调用频率和并发上更稳定。入口在 TaoToken 控制台的套餐页面，按你的实际用量选择。开通后，Key 的权限和额度会自动更新，gateway 不需要重启就能生效。

如果你同时用 Cline、Codex 或 CC Switch，可以把它们的 Base URL 都指向https://taotoken.net/api，Key 用同一个，Model ID 按各自配置填。这样多个工具共享一个通道，管理起来更省心。Cline 的 MCP 配置里注意baseUrl不要带尾部斜杠，Codex 的auth.json里api_base字段同理。

日常维护上，建议把config/openclaw.json和.env纳入版本管理，但不要把真实 Key 提交到公开仓库。可以用.env.example放占位符，实际.env加到.gitignore。gateway 的日志会滚动写入logs/gateway.log，定期清理避免占满磁盘。

最后，如果你在容器里改了配置，记得重启对应容器让配置生效。gateway 改配置后执行docker-compose restart gateway，controlui 改配置后执行docker-compose restart controlui。设备配对信息保存在config目录下，重启不会丢失，不需要重新批准。

整套流程跑下来，从docker-compose up -d --build到 controlUi 里看到模型回复，顺利的话十分钟以内能完成。遇到报错就按第 5 节的顺序排查，大部分问题都能定位到具体的配置项。