自托管一个 OpenClaw 风格的工作流听起来很简单：租一台 VPS，安装代理，把它指向一个仓库。真正让团队出问题的是这条循环周围的东西：密钥、分支、日志、消费上限，以及长任务在迁移中途卡住时的恢复路径。
这是我们推荐给 OpenClaw 用户的运维模型：获得更多控制权，但不假装 Office Claws 是原生 OpenClaw runtime。Office Claws 管理本地桌面状态和 VPS runner，用于 Codex 支持的代理。如果你的 OpenClaw 工作负载主要是仓库内的代码工作，这就给了你有用的 self-hosted 形态：密钥留在本地，每个任务有隔离 runner，每次修改仍然以可审查分支落地。
「OpenClaw Self Hosted」应该是什么意思
最安全的定义不是「把托管服务复制到一台服务器」。它是一种控制平面拆分。
| 层 | 保留位置 | 为什么重要 |
|---|---|---|
| 桌面控制 | 本地机器 | API token、SSH 密钥、审批和操作者意图都靠近开发者 |
| 代理执行 | VPS runner | 长任务能跨过笔记本休眠和不稳定 Wi-Fi |
| 仓库修改 | 每个任务一个分支 | Review、CI 和 rollback 保持正常 |
| 网络访问 | 私有 mesh | SSH 不直接暴露到公网 |
| 计费 | 订阅 + 小 VPS | 成本可预测，而不是每次空转重试都变成 API 惊喜账单 |
这个模型不同于运行 OpenClaw 本身。我们并不声称 Office Claws 会导入 OpenClaw 扩展、记忆或浏览器自动化。我们描述的是面向 OpenClaw 用户的 self-hosted workflow：他们主要需要在持久机器上完成自主编码工作。OpenClaw vs Codex 对比更适合用来判断这个取舍是否可接受。
参考架构
可靠的 self-hosted setup 有四部分：
- 桌面上的 Office Claws，负责 provision、审批、状态和本地密钥处理。
- 每个活跃 runner 一台 VPS，可以在 Contabo、DigitalOcean、Hetzner，或你已经信任的服务商上。
- Tailscale 或等价私有 mesh，让 runner 不把 SSH 暴露到互联网。
- runner 内的 Codex CLI，提供许多 OpenClaw 用户在订阅或成本变化后需要的仓库型执行路径。
关键习惯是：一个任务，一个 runner，一个分支。不要因为看起来高效，就让三个代理共享一个 checkout。那会把便宜的 self-hosted 实验变成神秘 diff 和被覆盖的测试输出。OpenClaw desktop manager 指南解释了为什么 UI 如此强调可见的 runner 状态：如果你看不出哪个代理拥有哪个仓库，你还没有运维层。
Setup 检查清单
从小开始。一台 runner 足以证明循环成立。
# target shape, not a magic installer
1. create a VPS from a known snapshot
2. join it to your private mesh
3. authenticate Codex CLI on the runner
4. clone one repo into one task workspace
5. create a branch before the agent edits files
6. run tests and push the branch
7. destroy or reset the runner when the task is done对 Office Claws 用户来说，应用会处理 provision 和状态层；仓库权限、GitHub review 规则和模型账号仍由你负责。self-hosted 方案的桌面/VPS 管理层是 $4.99/月；如果你想少承担服务器责任，managed runner 是 $14.99/月。把这些数字和你的模型订阅、VPS 账单分开看。
在把真实工作交给 runner 前，先检查这些无聊但重要的控制项：
- 受限 GitHub token： 只给仓库访问，不给组织级 admin token。
- 不要共享
.env泛滥： 只传递任务需要的 secrets。 - 消费上限： 在 VPS 服务商设置一个；如果模型账号流程支持，也设置一个。
- CI gate： 代理分支不能直接 deploy。
- 重置路径： snapshot 或 rebuild 应该比调试被污染的 runner 更快。
这些也是我们在 OpenClaw security best practices 中推荐的控制项。Self-hosting 移除了一层供应商表面，但增加了责任；它不会魔法般地让代理工作变安全。
需要提前设计的失败模式
大多数 self-hosted 代理问题都可以预料。第一次通宵运行前就要为它们设计护栏。
| 失败模式 | 症状 | 护栏 |
|---|---|---|
| 共享 workspace 冲突 | 两个代理编辑同一批文件 | 每个任务一个 runner 和分支 |
| 公网 SSH 暴露 | 日志里出现随机登录尝试 | 只用私有 mesh；关闭公网 SSH |
| secrets 权限过宽 | 代理能读取无关凭证 | 每任务 env 和 scoped token |
| 静默卡住 | job 在 prompt 或失败测试后停止 | 状态检查、日志和明确的 stuck-agent recovery |
| 成本漂移 | 额外 runner 整个周末都活着 | 消费上限和 runner 清理 |
状态层比很多人想象得更重要。终端复用器可以让会话活着，但回答不了操作者的问题：这个任务归谁，推了哪个分支，测试是否通过，机器能不能删除？所以我们的 OpenClaw 文章会反复指向 Office Claws for OpenClaw users，而不是假装一台裸 VPS 就足够。
建议
如果你的 OpenClaw 工作主要是代码，先 self-host 运维层，而不是 self-host 一切。把审批和凭证留在本地。让代理跑在私有 VPS runner 上。在适合的地方使用 Codex-backed execution。每个结果都像队友的分支一样经过 GitHub 和 CI。
如果你的 OpenClaw 工作依赖原生扩展、重浏览器自动化或特定平台流程，不要硬塞进这个模式。把 OpenClaw 留给这些任务，用 Office Claws 处理那些能从更便宜持久 runner 获益的仓库型工作。
最好的 self-hosted setup 是故意无聊的：一个任务，一个 runner，一个分支，一个 review gate。这就是重点。当基础设施拒绝耍聪明，自主编码才更容易被信任。