为什么 OpenClaw 需要专门的 CI/CD 模式
OpenClaw 风格的编码智能体可以在团队处理其他事情时继续推进。但 CI/CD 决定这种自主性是变成可信流程，还是变成危险捷径。目标不是让智能体更快部署，而是让每个变更都足够小、可审查、可回滚，并且能被流水线明确拒绝。
Office Claws 不是原生 OpenClaw runtime。更准确的定位是运维层：用它管理桌面和 VPS runner，承载接近 OpenClaw 的 Codex-backed 工作，再让 GitHub 或 CI 系统执行 merge 与部署规则。如果你还在比较 runtime，先看 OpenClaw vs Codex。
OpenClaw CI/CD 契约
每个自动化任务都应该先定义契约：runner 可以写哪里，哪些检查必须通过，哪些决定必须由人负责。
| 字段 | 安全默认值 | 作用 |
|---|---|---|
| Branch | agent/<ticket>-<purpose> | 避免直接修改 main |
| Pull request | 先 draft，通过后 ready | 尽早暴露 CI 状态 |
| Checks | Typecheck、tests、lint、build、content validation | 在 review 前拦截基础错误 |
| Preview | 临时 URL 或 artifact | 让人检查行为而不只是 diff |
| Secrets | runner 无生产 secrets | 降低泄露风险 |
| Deploy | 绿灯后人工批准 | 分离代码生成和发布权限 |
这就是 Office Claws for OpenClaw users 的操作模型：一个任务、一个 runner、一个分支、一个日志流、一个 review gate。
面向智能体分支的最小流水线
先严格，再聪明。一个 pull request pipeline 至少应该证明仓库能构建：
name: agent-ci
on:
pull_request:
branches: [main]
permissions:
contents: read
pull-requests: read
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run lint --if-present
- run: npm test --if-present
- run: npx velite build
- run: npm run build后端服务应加入 migration dry-run、contract tests 和 container build。内容型网站应把 content validation 单独显示，避免 metadata 错误淹没在整体 build 中。
先预览，再部署
Preview 环境是在智能体速度和人工控制之间最好的折中。智能体创建 branch 和 PR，CI 创建 preview，人决定是否发布。
好的 preview gate 会回答：哪个 commit 生成了 preview，哪些 checks 通过或失败，哪些文件超出预期范围，以及如何回滚。
保持 CI/CD 安全的停止规则
如果出现无关测试失败、migration 删除数据、需要宽权限 secrets、diff 跨服务且没有计划，或同一验证失败三次，智能体应该停止。把这些规则和 OpenClaw monitoring、OpenClaw security best practices 配套使用。
推荐工作流
- 先创建新 branch。
- 尽早打开 draft PR。
- 在 CI 中运行 lint、tests、content validation 和 build。
- 生成 preview URL 或 artifact。
- 生产部署和破坏性 migration 必须人工批准。
- 在 Office Claws 中把 runner logs、branch 和 PR link 放在一起。
这样，OpenClaw 风格的自主性才会变成团队流程，而不是一堆没人敢合并的终端输出。