企业官网建设流程全解析

OpenRig rig env 管理 Docker 服务环境：status、checkpoints 与健康检查完全指南

【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrig

OpenRig（rig env）是一个多智能体协作框架（multi-agent harness），它把 Claude Code 与 Codex 作为同一系统的成员统一管理。除了管理智能体团队，OpenRig 的rig env能力还能托管你的 Docker Compose 服务环境：在智能体启动前自动拉起依赖服务、等待健康检查通过、用 checkpoints 导出可恢复的状态。本文带你快速掌握rig env status、rig env logs、rig env down三个核心命令，以及wait_for健康检查与checkpoints快照配置的完整玩法。

为什么需要 rig env 管理 Docker 服务环境？

AI 编码智能体干活时几乎离不开配套设施：数据库、缓存、消息队列……传统做法是你在一个终端手工docker compose up，再祈祷服务真的就绪了才让智能体开工。

OpenRig 的思路是让 rig 自己声明依赖（Services Block），然后由守护进程在任何智能体节点启动之前完成服务拉起。官方文档 rig-spec.md 明确说明：

When present, services boot before any agent node launches. If service health checks fail, agent launch is blocked.

也就是说，健康检查不过，智能体就不会带病上岗——这是 rig env 最核心的价值。

配置 services 块：让 rig 声明自己的依赖

在 rig 规格文件中添加可选的services块（v1 目前仅支持 Docker Compose 后端）：

services: kind: compose compose_file: docker-compose.yaml project_name: my-product profiles: [core] down_policy: down wait_for: - url: http://127.0.0.1:5432/health - service: redis condition: healthy checkpoints: - id: postgres export: "docker compose exec -T postgres pg_dump -U app > {{artifacts_dir}}/postgres.sql" import: "cat {{artifacts_dir}}/postgres.sql | docker compose exec -T postgres psql -U app"

关键字段一览（完整字段表见 docs/reference/rig-spec.md）：

三种健康检查探针：wait_for 的三种写法

wait_for的每个目标必须三选一，分别对应三种探测方式：

• HTTP 探针（url）：请求该地址，期望得到 2xx 响应。适合有/health端点的应用服务；
• TCP 探针（tcp: "host:port"）：尝试建立 TCP 连接。适合数据库这类没有 HTTP 接口的服务；
• Compose 健康检查（service: xxx+condition: healthy）：直接读取 Docker 容器的 health 状态，要求 Docker 报告healthy。

这套探测逻辑实现在 services-readiness.ts 中，统一服务于启动时的健康门禁与按需的状态刷新。

⏱️等待是有限制的：默认超时 60 秒、每 3 秒轮询一次（见 service-orchestrator.ts）。全部通过 → 环境标记healthy；部分通过 →degraded；全部失败或超时 → 智能体启动被阻断，并得到明确的目标名称提示。

rig env status：查看 Docker 服务环境实时状态

服务跑起来之后，一条命令看清全貌：

rig env status my-rig

输出示例：

Env: compose (my-product) redis: running (healthy) postgres: running (healthy)

这个命令不只是读缓存。它会通过守护进程主动做一次"诚实探测"，响应里带有probeStatus字段——fresh（刚刚实测）、stale（探测失败，展示的是缓存）或no_orchestrator（编排器不可用），方便你区分"当前真相"和"历史快照"。加--json可拿到完整机器可读输出，供脚本消费。

相关实现：CLI 侧在 env.ts，守护进程路由在 env.ts。

rig env logs 与 rig env down：看日志、拆环境

查看服务日志——排查"服务起了但行为不对"最直接的武器：

rig env logs my-rig # 全部服务，默认最近 100 行 rig env logs my-rig redis --tail 50

日志由守护进程代理docker compose logs返回，不用自己拼项目名。

停止环境：

rig env down my-rig --volumes # --volumes 强制清理数据卷

不带--volumes时遵循你配置的down_policy；带上则覆盖策略、直接执行docker compose down --volumes。注意down_policy: leave_running的 rig 在rig down时不会动容器，适合服务被多个 rig 共享的场景。

checkpoints：把服务状态纳入快照与恢复

checkpoints为每个状态源定义一对 Shell 命令：

• export：快照时导出状态（如pg_dump数据库），{{artifacts_dir}}会被替换为守护进程管理的产物目录；
• import：恢复（restore）时执行，把状态导回去。

这样当 rig 从快照恢复时，智能体的上下文和它依赖的数据库状态一起回到同一时刻，避免"代码是新的、数据是旧的"这种错位。字段语义详见 rig-spec.md 的 Checkpoint Hooks 一节。

💡 顺带一提：OpenRig 的健康诊断体系里还有一个同名概念的checkpoint子命令（rig health checkpoint，见 health.ts），那是用于提交结果边界普查的审计记录，与本文的服务状态checkpoints钩子是两回事，注意区分。

上手步骤与故障排查清单

四步跑通服务化 rig：

1. 准备docker-compose.yaml，在 rig 规格中写入services块；
2. rig up <rig>启动，观察服务先于智能体就绪；
3. rig env status <rig>确认所有目标healthy；
4. 需要时用rig env logs排障，rig env down收尾。

状态不对时的排查顺序：

• probeStatus: stale→ 先确认 Docker 守护进程与 compose 文件是否存在；
• wait_timeout错误 → 检查wait_for里的 URL/端口与容器实际暴露是否一致；
• 智能体没启动 → 按设计这就是健康门禁在起作用，先修服务再等下一轮启动。

更多命令细节（含probeStatus语义说明）参考 cli-reference.md。

小结

rig env把"Docker 环境管理"从手工仪式变成了 rig 规格的一部分：wait_for三种探针保证智能体只在依赖就绪后开工，rig env status/logs/down覆盖了日常运维闭环，checkpoints则让服务状态随快照一起可恢复。对于同时管理多个 Claude Code 与 Codex 智能体的团队，这是让整支队伍"带环境一起交付"的关键一步。

【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrig