用AI搭建Openclaw进行量化分析

1. 说明

近期 openclaw 比较火。说起来 openclaw 也就是个正常 agent，且由于没有直接背靠模型大公司，所以还得被迫接 API。

这意味着实际使用性价比大概率远劣于直接用模型公司的 agent 如 codex、antigravity、claude code。（这三个我同时开着会员在用）

不过用这几个头部公司的 agent 或者 app 依旧有不方便的地方：

时空局限：需要我开着 ide 或者他们专门的客户端进行使用，局限了我的使用场景（得电脑前），也局限了使用时机（得电脑前）。而 vibe working 天生适合异步的协作。但由于这些限制导致我走路/开会时候的想法并不方便落地。
不能语音：豆包 app 给我最大的吸引力是中文语音识别能力，我甚至用很牙尖的四川话她都能识别地一字不差。输入体验非常的棒。相比之下 gemini、chatgpt、claude 的手机 app 在中文语音识别的水平就是一坨。导致我日常简单的对话甚至宁愿用豆包。质量要求高的可能会先用豆包再复制到 claude 再问一遍。

openclaw 在解决这两个痛点的角度确实很棒：

接IM，随时想着就能拿手机发指令
可以接飞书，用上字节的语音识别

虽然个人认为 openclaw 非常的临时，长期几乎一定被头部模型厂出的专门产品替代（目前跟进最快的是 claude）。但短期 openclaw 确实还是有优势。

当然 openclaw 还有大量劣势如成本、安全性等等，但这些都不改变其临时的优势。

2. AI 部署

已经是 AI 时代了，代码都无需自己写，openclaw 这种东西自然也无需自己手动部署和维护。

直接用 codex(换用 claude code 也可以。年前我还试过让 antigravity 部署当时的 clawdbot，也没问题)。让 agent 部署 agent。

2.1 准备起始文档

类似 vibe coding，可以先写个简单小文档，阐述一下自己的需求，让 agent 基于需求先研究规划，不要一来就执行。这里我大致写了

搭建 openclaw 来做量化分析。
为了安全，需要把 openclaw 部署在 docker 中。
量化分析相关工程目录（包含 sqlite 形式数据库，以及回测框架、一些策略、分析代码等等）可以挂载给 openclaw 所在 docker 容器。
由于我也还不太了解 openclaw 的架构和注意事项，于是这部分就让 codex 去研究分析可行性，并且报告给我。
模型密钥等等信息我单独放在 info.md 中提供给 codex 部署用。

接下来就让 codex 先基于我们的起始需求进行分析设计草案和需要注意的事项，并输出成一个文档：

文档非常详实，codex 结合了我的机器、需求、openclaw相关资料给出了相对很完整的可行性报告。以及推荐方案：

可以大致看看整个报告，看是否符合自己的预期

比如 codex 建议我用一个量化工程的副本挂载给 openclaw，但由于我评估量化工程已在 git ，很安全，可以给 openclaw 所以无需采纳
有些建议可能很补自己知识盲区，比如建议我把 gateway 和 sandbox 分两个 image build，gateway 内含更多的重要 key，如大模型的 API，飞书机器人的 key 等等，且暴露到公网。而 sandbox 只用于执行，所在环境就更受限制。
阅读过程中把自己觉得需要调整的内容反馈给 codex 和它进一步讨论并修改 plan

2.2 准备部署指导文档

最后当改得差不多了，再让他生成一个最终的完整的执行指导手册（给 codex 的要求是我将新开一个会话让 agent 跟着手册执行部署）：

codex 输出了个非常详细的执行步骤文档。这个文档也最好大致阅读一下，并且把其中需要修改的点提出来，和 codex 讨论或者让他修改。直到整个文档都满意。

codex 的完整执行文档如下：

# OpenClaw 执行手册

更新时间：2026-03-10

## 1. 目标

把 OpenClaw 部署到当前这台云端 Linux 主机上，满足以下要求：

1. 自建 `Gateway` 镜像
2. 自建 `Sandbox` 镜像
3. 部署目录全部放在 `/root/dev/quant_claw`
4. OpenClaw 可直接读写 `/root/dev/quant_strategy_v2`
5. `data/data.sqlite` 允许 OpenClaw 读写
6. 通过 `https://openclaw.pangruitao.com` 远程打开 Control UI
7. 最终接入飞书，平时通过飞书和 Control UI 控制

## 2. 已确认前提

以下前提已确认，本手册直接基于这些条件执行：

- 系统：Debian 12
- Docker：`24.0.7`
- Docker Compose：`v2.21.0`
- Node：`v22.21.0`
- `nginx` 已安装并占用 `80/443`
- `acme.sh` 已安装
- 域名 `openclaw.pangruitao.com` 已解析到本机
- 量化工程目录：`/root/dev/quant_strategy_v2`
- `data/data.sqlite` 可被 OpenClaw 修改
- 当前工作区不是 git 仓库，`docs/info.md` 内的 key 不构成 Git 泄漏问题

## 3. 本次部署固定决策

以下决策已经确认，后续执行时不要再改成更保守方案：

- 只更新本手册，不以 `docs/openclaw-deployment-plan.md` 中的“先只读”方案为准
- OpenClaw 允许直接读写 `/root/dev/quant_strategy_v2`
- OpenClaw 允许直接读写 `/root/dev/quant_strategy_v2/data/data.sqlite`
- 允许 agent 直接执行数据库更新语句，不限制为只读查询
- 量化运行所需 `TUSHARE_API_TOKEN` 需要注入到 Gateway / Sandbox 环境
- 对外只保留 `https://openclaw.pangruitao.com`
- 旧入口 `https://pangruitao.com/clawbot/` 需要从 Nginx 配置中删除
- 远程 Control UI 改由 Nginx Basic Auth 控制访问，Gateway 使用 `trusted-proxy` 信任反向代理传入的认证用户
- 飞书接入采用官方 Feishu 插件，使用飞书 SDK 的 WebSocket 长连接模式；不需要公网 webhook
- Gateway 镜像和 Sandbox 镜像都要求自建，不能直接使用官方整镜像

## 4. 最终目录布局

执行时统一使用以下目录：

```text
/root/dev/quant_claw/
  docs/
  workspace/
    AGENTS.md
    SOUL.md
    USER.md
    IDENTITY.md
    MEMORY.md
    BOOTSTRAP.md
    HEARTBEAT.md
    TOOLS.md
    canvas/
    memory/
    deploy/
      config/
  deploy/
    .env
    docker-compose.yml
    Dockerfile.gateway
    Dockerfile.sandbox
    config/
      openclaw.json
    nginx/
      openclaw.pangruitao.com.conf
    state/
    output/
```

目录用途：

- `deploy/.env`：部署环境变量
- `workspace/`：agent 的 home/workspace 根目录，持久化容器中的核心工作区文件
- `workspace/MEMORY.md`：长期记忆文件
- `workspace/memory/`：按天记录的 daily memory
- `workspace/deploy/config/`：仅作为容器内 `/workspace/deploy/config/openclaw.json` 的挂载目标
- `deploy/docker-compose.yml`：容器编排
- `deploy/Dockerfile.gateway`：Gateway 自建镜像
- `deploy/Dockerfile.sandbox`：Sandbox 自建镜像
- `deploy/config/openclaw.json`：OpenClaw 配置
- `deploy/state/`：持久化 `~/.openclaw`
- `deploy/output/`：导出的报告、图表、临时文件

## 5. 总体执行顺序

按下面顺序执行，不能跳步：

1. 准备部署目录与 `.env`
2. 编写 Gateway 镜像
3. 编写 Sandbox 镜像
4. 编写 `docker-compose.yml`
5. 编写 `openclaw.json`
6. 启动 Gateway 并验证本机可用
7. 配置模型提供商并验证可对话
8. 验证 Sandbox 能运行 Python / SQLite / pytest
9. 配置 `nginx + TLS`，让远程 Control UI 可用
10. 安装并接入飞书
11. 完成验收

## 6. 第一步：准备部署目录

在 `/root/dev/quant_claw` 下创建部署目录：

```bash
mkdir -p /root/dev/quant_claw/deploy/config
mkdir -p /root/dev/quant_claw/deploy/nginx
mkdir -p /root/dev/quant_claw/deploy/state
mkdir -p /root/dev/quant_claw/deploy/output
mkdir -p /root/dev/quant_claw/workspace/deploy/config
mkdir -p /root/dev/quant_claw/workspace/memory
```

设置可写权限：

```bash
chown -R 1000:1000 /root/dev/quant_claw/deploy/state
chown -R 1000:1000 /root/dev/quant_claw/deploy/output
```

说明：

- `1000:1000` 对应容器内 `node` 用户
- `quant_strategy_v2` 目录不需要在这一步改权限

## 7. 第二步：准备 `.env`

在 `/root/dev/quant_claw/deploy/.env` 中放置部署变量。

建议内容：

```dotenv
DASHSCOPE_API_KEY=replace_me
OPENCLAW_DOMAIN=openclaw.pangruitao.com
OPENCLAW_PORT=18789
OPENCLAW_MODEL=MiniMax-M2.5
OPENCLAW_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
TUSHARE_API_TOKEN=replace_with_quant_strategy_token
FEISHU_APP_ID=replace_me_later
FEISHU_APP_SECRET=replace_me_later
```

要求：

- `TUSHARE_API_TOKEN` 使用量化项目当前可用的 token，供 Sandbox 运行抓数/更新脚本时使用
- `FEISHU_APP_ID` 和 `FEISHU_APP_SECRET` 如果当前已经拿到真实值，可直接填真实值，不必再占位

说明：

- 量化项目本身兼容 `TUSHARE_API_TOKEN` 与 `tushare_api_token`
- 为了让 `docker compose` 统一注入，部署时以 `TUSHARE_API_TOKEN` 为准

## 8. 第三步：编写 Gateway 镜像

Gateway 镜像职责：

- 运行 OpenClaw Gateway
- 提供 Control UI
- 加载插件
- 加载模型配置
- 接入飞书

镜像要求：

- 基础镜像使用 `node:22-bookworm`
- 安装 `git`、`bash`、`curl`、`jq`、`python3`、`sqlite3`、`ca-certificates`
- 安装 OpenClaw 固定版本
- 预装 `@openclaw/feishu`

建议安装方式：

- 使用 `OPENCLAW_VERSION` build arg 固定 `npm install -g openclaw@${OPENCLAW_VERSION}`

不建议一开始使用源码构建，原因：

- 镜像更复杂
- 首次部署没有必要
- 固定 npm 版本更容易复现

启动方式：

- 用容器命令启动 `openclaw gateway --host 0.0.0.0 --port 18789`

额外要求：

- 镜像需要保留安装插件与写入 `~/.openclaw` 的能力
- 如果 Feishu 插件不能在 build 阶段稳定预装，则允许在容器首次启动时执行 `openclaw plugins install @openclaw/feishu`，并把插件状态持久化到 `deploy/state`
- Gateway 侧不负责量化 Python 运行时，但需要能读取配置、加载 provider、触发 sandbox

## 9. 第四步：编写 Sandbox 镜像

Sandbox 镜像职责：

- 执行 Python 脚本
- 执行 SQLite 查询
- 执行 pytest
- 生成图表
- 生成导出文件

Sandbox 镜像中至少安装：

- Python 3.11
- pip
- sqlite3
- git
- curl
- jq
- numpy
- pandas
- matplotlib==3.10.5
- pytest==8.4.1
- tushare==1.4.21
- ipykernel==6.30.0
- ipywidgets==8.1.7

原则：

- Sandbox 专注执行任务
- Gateway 不负责量化运行时
- Sandbox 需要显式接收 `TUSHARE_API_TOKEN`
- 不依赖挂载 `/root/dev/quant_strategy_v2/.env` 才能运行抓数脚本

## 10. 第五步：编写 `docker-compose.yml`

在 `/root/dev/quant_claw/deploy/docker-compose.yml` 中定义 `gateway` 服务。

必须满足的条件：

1. 使用 `Dockerfile.gateway` 构建 Gateway 镜像
2. 挂载 `/var/run/docker.sock:/var/run/docker.sock`
3. 挂载 `/root/dev/quant_claw/deploy/state:/home/node/.openclaw`
4. 挂载 `/root/dev/quant_claw/workspace:/workspace`
5. 再额外挂载 `/root/dev/quant_claw/workspace:/root/dev/quant_claw/workspace`
6. 再覆盖挂载 `/root/dev/quant_claw/deploy/output:/workspace/openclaw-output`
7. 再覆盖挂载 `/root/dev/quant_strategy_v2:/workspace/quant_strategy_v2`
8. 端口只先绑定到 `127.0.0.1:18789:18789`
9. 从 `.env` 注入模型和飞书相关环境变量
10. 从 `.env` 注入 `TUSHARE_API_TOKEN`

这里明确采用以下策略：

- OpenClaw 对 `quant_strategy_v2` 读写开放
- OpenClaw 对 `data/data.sqlite` 读写开放
- 允许 OpenClaw 直接执行 SQL 更新、插入、删除
- 代码错误通过 Git 或备份回滚
- 数据错误通过重新抓取恢复

执行要求：

- `/workspace` 根目录只挂载核心 workspace 目录，不直接映射整个 `quant_claw` 根目录，避免 agent 误改 `deploy/`、`docs/`
- 因为 Gateway 通过宿主机 `docker.sock` 创建 sandbox，`agents.*.workspace` 必须配置为宿主机可见的绝对路径 `/root/dev/quant_claw/workspace`；容器内 `/workspace` 只作为 sandbox `workdir`，不能拿来当宿主机 bind source
- Gateway 版本号要集中维护在 `deploy/.env` 的 `OPENCLAW_VERSION`，重建镜像时由 compose build args 注入 Dockerfile
- `quant_strategy_v2` 挂载必须是读写，不允许退回只读挂载
- 如果容器默认用户对宿主目录写权限不足，执行阶段需要一并处理目录权限、容器用户或运行用户映射，直到实际写入通过为止

## 11. 第六步：编写 `openclaw.json`

配置文件路径：

```text
/root/dev/quant_claw/deploy/config/openclaw.json
```

需要包含以下内容：

1. Gateway 监听配置
2. Gateway `trusted-proxy` 鉴权
3. 默认模型配置
4. DashScope OpenAI-compatible provider 配置
5. 默认 agent 配置
6. Sandbox 镜像配置
7. 飞书 channel 配置占位
8. 默认 agent 对工作目录和数据库的写权限策略
9. 内部 hooks 配置，启用 `session-memory`

关键约束：

- `agents.defaults.workspace` 和 `agents.list[].workspace` 必须写成 `/root/dev/quant_claw/workspace`
- `agents.defaults.sandbox.docker.workdir` 保持 `/workspace`
- `agents.defaults.sandbox.workspaceRoot` 不能替代上面的 `workspace`；在 `workspaceAccess=rw` 下，sandbox 主工作区挂载仍取 `workspace`

这里采用的模型接入方式是：

- `base_url=https://dashscope.aliyuncs.com/compatible-mode/v1`
- `api_key=DASHSCOPE_API_KEY`
- `model=MiniMax-M2.5`

执行原则：

- 先走 `Custom Provider (OpenAI-compatible)`
- 跑通后再决定是否改成 OpenClaw 的原生 MiniMax provider

飞书配置要求：

- 使用官方 Feishu channel
- 采用飞书 SDK 的 WebSocket 长连接模式
- 不配置公网 webhook
- 先只开私聊 DM
- 群聊默认禁用或不启用

## 12. 第七步：首次启动并验证本机可用

在 `/root/dev/quant_claw/deploy` 下执行：

```bash
docker compose up -d --build
docker compose ps
docker compose logs -f gateway
```

首次验收标准：

1. 容器成功启动
2. 本机能打开 `http://127.0.0.1:18789/`
3. 通过 Nginx 暴露时会先经过 Basic Auth，再进入 Control UI
4. 发送一条测试消息后，模型能正常回复

这一步如果没通过，不进入 Nginx 和飞书步骤。

## 13. 第八步：验证 Sandbox 能工作

必须验证以下能力：

1. 能读取 `/workspace/quant_strategy_v2`
2. 能访问 `data/data.sqlite`
3. 能执行一个简单 SQLite 查询
4. 能执行一段 Python 读取数据库
5. 能运行 `pytest`
6. 能把结果写到 `/workspace/openclaw-output`
7. 能在 `data/data.sqlite` 上执行一次真实写操作并恢复现场

第 7 条建议验证方式：

- 使用显式事务执行一次 smoke test
- 例如：`BEGIN; CREATE TABLE IF NOT EXISTS openclaw_smoke_test (...); INSERT ...; ROLLBACK;`
- 验证目标是确认容器对 SQLite 文件具备真实写权限，而不是只验证查询权限

验收目标：

- OpenClaw 不只是“能聊天”
- 而是“已经能完成量化研究任务”

## 14. 第九步：配置 Nginx 反向代理

由于你需要远程访问 Control UI，这一步是必做项。

反代目标：

- `https://openclaw.pangruitao.com`
- 反代到 `http://127.0.0.1:18789`

当前机器现状：

- `nginx` 已在运行
- `80/443` 已被现有 `nginx` 使用
- 当前主要配置文件为 `/etc/nginx/sites-enabled/revers_proxy.conf`

执行策略：

1. 在现有 Nginx 配置体系中新增 `openclaw.pangruitao.com` 的独立 `server` 块
2. 删除现有 `pangruitao.com` 下的 `/clawbot/` 旧反代
3. 为 `openclaw.pangruitao.com` 使用专属证书；如果当前没有覆盖该子域名的证书，则用 `acme.sh` 新申请
4. 把 `https://openclaw.pangruitao.com/` 根路径直接反代到 `http://127.0.0.1:18789`
5. 在 Nginx 启用 `auth_basic`，并向 Gateway 传递 `X-Forwarded-User`

反代配置必须支持：

- `auth_basic`
- `limit_req_zone` 与登录入口 `limit_req`（建议按单 IP `2 秒 1 次`）
- `proxy_http_version 1.1`
- `Upgrade`
- `Connection`
- `Host`
- `X-Forwarded-Host`
- `X-Forwarded-User`
- `X-Forwarded-For`
- `X-Forwarded-Proto`
- 较长的 `proxy_read_timeout`

这一步的验收标准：

1. 浏览器可从外网打开 `https://openclaw.pangruitao.com`
2. 先弹出 Nginx Basic Auth
3. Basic Auth 通过后可正常打开并使用 Control UI
4. 旧入口 `https://pangruitao.com/clawbot/` 已不再保留

## 15. 第十步：接入飞书

飞书接入采用 OpenClaw 官方 Feishu 插件。

已确认的关键点：

- 插件名：`@openclaw/feishu`
- 连接方式：飞书 SDK 的 WebSocket 长连接
- 不需要公网 webhook

执行顺序：

1. 确认飞书开放平台中的应用权限申请已完成
2. 确认 Bot 已开启并可接收私聊消息
3. 把 `App ID` 和 `App Secret` 填入 `/root/dev/quant_claw/deploy/.env`
4. 在 OpenClaw 中安装 Feishu 插件
5. 在 OpenClaw 配置中添加 Feishu channel
6. 重启 Gateway
7. 在飞书私聊中与 bot 对话
8. 完成 pairing

执行原则：

- 先只开私聊 DM
- 群聊先不启用
- 等 DM 稳定后再考虑群聊或更宽权限

## 16. 第十一步：最终验收

部署完成的标准如下：

1. `docker compose up -d --build` 可正常启动
2. `docker compose restart` 后服务可恢复
3. 本机可访问 `http://127.0.0.1:18789/`
4. 远程可访问 `https://openclaw.pangruitao.com`
5. Control UI 可正常对话
6. Agent 可读写 `/root/dev/quant_strategy_v2`
7. Agent 可读写 `data/data.sqlite`
8. Agent 可直接执行数据库更新操作
9. Agent 可运行 Python / SQLite / pytest
10. Agent 可使用 `TUSHARE_API_TOKEN` 运行需要该凭据的脚本
11. Agent 可输出图表和报告到 `deploy/output`
12. 飞书私聊可控制 OpenClaw
13. `https://pangruitao.com/clawbot/` 旧入口已清理

## 17. 下一会话的执行目标

你在下一会话里让 Codex 按手册直接执行部署时，应该按下面顺序产出实际文件：

1. `/root/dev/quant_claw/deploy/Dockerfile.gateway`
2. `/root/dev/quant_claw/deploy/Dockerfile.sandbox`
3. `/root/dev/quant_claw/deploy/docker-compose.yml`
4. `/root/dev/quant_claw/deploy/config/openclaw.json`
5. `/root/dev/quant_claw/deploy/nginx/openclaw.pangruitao.com.conf`

然后再：

1. 启动容器
2. 验证本机 UI
3. 配置远程反代
4. 配置飞书
5. 做最终验收
6. 删除旧的 `/clawbot/` Nginx 配置入口

## 18. 参考资料

以下资料已核对，供实际执行时参考：

- OpenClaw 安装总览：<https://docs.openclaw.ai/install/index>
- OpenClaw Docker 安装：<https://docs.openclaw.ai/install/docker>
- OpenClaw Wizard：<https://docs.openclaw.ai/start/wizard>
- OpenClaw Plugins：<https://docs.openclaw.ai/tools/plugin>
- OpenClaw Feishu：<https://docs.openclaw.ai/channels/feishu>
- OpenClaw Providers：<https://docs.openclaw.ai/providers>
- OpenClaw MiniMax：<https://docs.openclaw.ai/minimax/>
- OpenClaw Configuration Reference：<https://docs.openclaw.ai/gateway/configuration-reference>

可见还是非常详实的。一步一步各做什么，包括一些需要我们手动的部分，如飞书机器人应该怎么申请也写了（当然实际做的时候可能依旧有不清楚的地方，但可以随时追问），整体还是非常简单

2.3 Codex 执行部署

然后新开一个对话，让 codex 跟着上面的文档执行部署。

我经过十分钟左右等待（codex 做事确实有点慢，不过质量还行）。部署完成。

2.4 调试

这时候打开 codex 给的 openclaw 网址，看看是否正常

也可以在网站直接对话

如果网站打开有问题就反馈给 codex（如果暴露公网一定至少要 ssh + auth，不会就让 codex 搞和指导）

对话有问题有问题也反馈 codex

反正我遇到的问题基本上 codex 都能搞定，不过搞定的过程中多看看其报告，不确定的地方问一下，了解清楚上下文原因更能增加掌控感。

最后再接入自己的目标 IM 平台，如飞书、whatsapp 等等，过程也可以靠 codex 指导。

整体还是挺可用的。让我随时有些想分析的想法都可以丢给 openclaw。

btw， minmax 2.5 质量也还不错，处理日常简单问题应该够用了。

2.5 踩坑记录

记忆丢失问题：我的部署模式下，每次 /new 会重启一个新的 sandbox 容器，然后我发现之前对话修改的 USER.md 之类的文件也被重置了。后来让 codex 查发现是 docker 挂载路径的问题。
token 统计问题：openclaw 后台可以查用了多少 token，但我一开始的对话 token 都没记上。也是靠 codex 搞定（codex 甚至会去改 openclaw 的 js 代码，因地制宜修 bug，非常强）
飞书发图片问题：一开始在对话中发不了图片。但由于曾经我自己做过飞书机器人，了解发图片原理，就指导 openclaw 去查对应方法并创建 skill，后来需要发图片的都能正常发了。

以上，整体而言，有了 AI agent 让做各种事情都变简单了很多，包括搭建 openclaw 这种 agent 来玩玩，哈哈哈。