为什么 OpenClaw 远程 SSH 工作流需要边界
当 Agent 可以离开你的笔记本，在远程机器上继续运行时，OpenClaw 风格的工作才真正有用。SSH 让这一点成为可能，但也带来尖锐的风险：远程机器可能继承过多信任、过多密钥，以及过大的仓库访问权限。
Office Claws 不是原生 OpenClaw runtime。我们把同样的运维模型用于 Codex 支撑的 Agent：控制平面留在本地，通过私有路径连接到可丢弃的 VPS runner，并让每个远程会话都容易检查。如果你还在先选择 runtime 层，请从 OpenClaw vs Codex 开始，然后把这套流程作为更安全的 SSH 层。
OpenClaw 的 SSH Runner 模式
好的远程 SSH 工作流有三件事：隔离 runner、收窄凭据、保留审计线索。runner 应该足够有用，可以构建和测试代码；也应该足够普通，任务结束后可以直接销毁。
| 层级 | 保留在本地 | 允许在 runner 上存在 | 审查关口 |
|---|---|---|---|
| 控制 | Office Claws 桌面端、供应商密钥、审批 | Runner 状态和日志 | 人可以停止或删除 runner |
| 源码 | 主仓库和受保护分支 | 一个分支或 worktree | 合并前审查 PR diff |
| Secret | 长期 API key 和部署 token | 必要时使用短期 repo token | 任务后撤销 token |
| 网络 | Tailscale 或私有路由策略 | 来自已批准操作者的 SSH | 阻断未知入站端口 |
这个模式与 OpenClaw secrets management 的建议一致：不要把操作者的 vault 复制到执行不可信命令的机器上。SSH 应该是传输方式，而不是把 runner 变成第二台笔记本的借口。
最小远程 SSH 检查清单
具体命令会因云厂商和发行版不同而变化，但运维形状应该保持稳定。把任务交给 Agent 前，我们喜欢使用这份检查清单：
1. Create or reuse one VPS runner for one task.
2. Connect over Tailscale or another private route when possible.
3. Check out one repo branch or one isolated worktree.
4. Pass only the scoped token required for the task.
5. Stream logs back to the operator view.
6. Push a PR, validate CI, then destroy or reset the runner.关键是第四步。如果 runner 只需要创建分支并推送 PR，它不需要生产部署密钥。如果它只需要运行测试，可能根本不需要任何外部 token。OpenClaw sandbox 从 workspace 侧解释了同一个思路。
需要通过设计消除的失败模式
远程 SSH 工作流通常先静默失败，然后才显得严重。旧 runner 保留了旧的 .env 文件。共享机器上有两个 Agent 修改同一个 checkout。个人 token 被粘进 shell 历史。直到错误分支被推送、错误密钥泄漏之前，这些都不太像事故。
把流程设计成安全路径就是简单路径：
- 每个 runner 或 worktree 只处理一个任务；
- Agent 不直接写入
main； - 日志回流到本地操作者视图，而不是只留在 VPS 上；
- secret 短期、受限，并在使用后轮换；
- 卡住的会话可以从桌面管理器停止。
GitHub 侧可以搭配 OpenClaw GitHub workflow。SSH 把 Agent 带到机器上；分支、PR 和 CI 决定这些工作是否应该合入。
Office Claws 补上的部分
Office Claws for OpenClaw users 是围绕这一模式的操作者层：桌面管理、VPS runner provisioning、monitoring，以及更安全的本地密钥处理。今天的执行路径是 Codex-first，所以我们诚实地把这个工作流描述为 OpenClaw-adjacent，而不是宣称原生支持 OpenClaw。
实际结果很简单：Agent 可以远程工作，但不需要把每台 VPS 都变成永久信任锚。把控制留在本地，让 runner 可丢弃，并让每个 SSH 会话都通向一个可审查的分支。