重启前，你数不清自己开了几个 agent

凌晨两点，机器开始换页，系统更新提示你按了三次稍后，但你就是不重启。

因为手上开着五个 agent：一个在重构，一个在评审它一小时前提交的 PR，还有两个在别的仓库里翻资料。它们正干得热火，你只是不太确定哪个终端窗口对应哪个。

这段焦虑写在 OpenRig 作者 mvschwarz 今年 4 月那篇《Why I Built OpenRig》的开头。他的解法很干脆：把整支 agent 团队写进一个 YAML 文件，要用的时候 rig up 一把全拉起来，重启之后还能照原样恢复。

我把 OpenRig 装在自己机器上拆了一遍。先说最有用的那句：它第一次运行会改你的 Claude Code 和 Codex 配置，所以别在主力机器上随手 npm i -g 试。

它管的那一层，叫拓扑

先把名词摆清楚。Claude Code、Codex CLI 这类东西叫 harness，一个 harness 包着一个模型。OpenRig 不替换它们，它包着它们。

A harness wraps a model. A rig wraps your harnesses. Define your agent team in YAML, boot it with one command. Claude Code and Codex in the same rig, managed as one system.

作者把这套做法叫 distributed context management。大家平时聊的上下文工程，是盯着一个 agent 的窗口，什么时候压缩、什么时候丢给子 agent。他的做法反过来：让每个 agent 待在自己那份窄而专的上下文里别乱跑，用队形去协调，而不是用一个窗口装完所有信息。

同一支队伍共用一份 CULTURE.md。作者说那是群体的宪法，相当于 OpenClaw 里给单个 agent 定人格的 SOUL.md，只不过作用范围是整支队伍。

具体到这个 CLI，我数了 --help 里的子命令，一共 86 条。除了 up、down、ps、tui 这些猜得到的，还有队列、workflow 运行时、看门狗、成本遥测、快照恢复、把散落的 tmux 会话认领回队形。这不太像一个 tmux 包装器，更像一套小型的作业系统。

实测第一步：先过环境闸门

OpenRig 要求 Node 22 或 24，还要有 tmux。我把包装在临时目录里，没动全局：

npm i @openrig/cli          # 0.6.4，110 个依赖包
./node_modules/.bin/rig preflight

体检结果很干脆：

✓ node_version
✗ tmux: tmux was not found in PATH.
  Why: OpenRig uses tmux to create and control agent sessions.
  Fix: Install tmux (brew install tmux on macOS, apt install tmux on Debian/Ubuntu).
✓ writable_home
✓ port_available

1 check(s) failed.

四项里三项过，卡在 tmux。顺便说个容易踩的坑：这台机器的 node 是 25，而 OpenRig 只支持 22 和 24，npm 12 自己都会警告不支持 node 25。我是借 Homebrew 里已有的 node@22 才把它跑起来的。所以动手之前这一步别跳，先让它告诉你缺什么。

装之前，先看它要动你哪几个文件

rig setup 是准备环境那一大步：装 tmux、装 cmux、装 agent CLI、配鉴权。我不想让它真动手，就先跑了 --dry-run。

它没有含糊，直接把会改的文件列了出来：

[global]  claude-code  ~/.claude.json                预信任托管工作区、标记引导完成
[project] claude-code  .claude/settings.local.json   写入 statusLine 与 acceptEdits 下限片段
[project] claude-code  .mcp.json                     写入选定的 MCP 资源片段
[global]  codex        ~/.codex/config.toml          预信任 + 配置片段
[global]  cmux         ~/.config/cmux/settings.json  把 cmux 的 socket 控制切成兼容模式

（上面的清单是我译的，原文是英文。）

有两处让我挺意外。一是它明说不内置权限策略，原话是 OpenRig bakes NO allow/ask/deny permission policy，说 harness 原生的权限才是控制面。二是轮到「要不要免确认」这个问题时，它把决定权交回给你，正式拉起团队前你的 agent 会问你一次：

Allow your agents to run OpenRig commands without repeated permission prompts? Yes — recommended / No — keep prompts. No answer leaves settings unchanged too.

选 No 或者干脆不回答，它什么都不写。文档里还有一句我建议收藏：记录一个权限策略只是留个念想，不是关卡，rig up 没有它照样跑。

那 --dry-run 真不落盘吗？我事先给这几个文件拍了 SHA256，跑完之后哈希一模一样，skills 目录还是 93 项，~/.openrig 没生成。是真的干跑。

一支团队，就是一个 YAML

预演里那份清单只管到配置那一层。真正的队伍定义在 YAML 里，包里自带 19 个 rig 定义、16 个 agent 定义、6 个 workflow 定义。

最小的那个长这样：

version: "0.2"
name: first-project
culture_file: CULTURE.md
pods:
  - id: dev
    label: Project
    members:
      - id: owner
        agent_ref: "local:../../../agents/development/implementer"
        runtime: codex
        model: gpt-6-astra
        cwd: "."
      - id: check
        agent_ref: "local:../../../agents/development/qa"
        runtime: codex
        model: gpt-6-astra
        cwd: "."
    edges:
      - kind: delegates_to
        from: owner
        to: check

一个 pod 里两个座位，owner 和 check，后者是独立检查者，边是 delegates_to。这条边不是画着好看的，它有运行时的含义，是座位之间的通信路径。同一份定义还有 Claude 版和混合版，叫 first-project-claude 和 first-project-mixed。

还有个挺妙的：它第一次启动 daemon 时，会自动拉起一个叫 kernel 的常驻 rig。三个 pod，advisor 用 Claude Code 指挥，operator 里放一个给人类用的终端座位、再配一个 Codex 座位，queue 里一个 worker 负责把输入流分类进队列。

人类座位和 agent 座位之间有 collaborates_with 和 escalates_to 两条边，意思是 agent 干不了的事，升级给你。

一个工位里到底有什么

再往下拆一层，一个座位就是一份 agent 定义。开发岗的实现者是这样：

name: implementer
defaults:
  runtime: claude-code
profiles:
  default:
    uses:
      skills: [development-team, test-driven-development, systematic-debugging, verification-before-completion]
      plugins: [shared:openrig-core]
      runtime_resources: [shared:claude-default-settings, shared:claude-default-mcp, shared:codex-default-config, shared:claude-activity-hooks]
startup:
  files:
    - path: guidance/role.md
      delivery_hint: send_text

翻译一下：这个座位用什么运行时、带哪几个技能、挂哪些插件和资源、开场先把它自己的角色说明发进去。座位不是「开个终端再慢慢教」，它是一份可复用、能版本化的岗位说明书。工作流那层同理，roles 声明角色，steps 按声明顺序往下走，示例的意思就是让一个包依次经过 plan、build、prove 三个座位。

它现在的位置

OpenRig 是 Apache-2.0，第一个版本 4 月 6 日发出，到 10 月 2 日的 0.6.4 已经走过 54 个版本，仓库 4.2k 星、38 位贡献者，上周 npm 下载 4,560 次。版本号还在 0.6，规范版本是 RigSpec 0.2 和 AgentSpec 1.0。

作者拿它和 Anthropic 今年 4 月 8 日发布的 Claude Managed Agents 做了对比，云托管、只有 Claude、按会话小时计费；他这边本地跑、Claude 和 Codex 混搭、用你自己的订阅额度。他的比喻是 Terraform 和 AWS 的关系，一个管云里的资源，一个管本地的队形。

Terraform doesn’t compete with AWS. OpenRig doesn’t compete with Managed Agents.

要我把团队写成一个文件，我是愿意的。真正拦人的不是写法，是你得先接受一件事：为了让它管起你的 agent，它会先改你的 agent 配置，而且是全局的。你接受这个交换吗，还是觉得在 tmux 里手动开五个窗口也挺好？