GitHub 周榜第一：手把手组建你的第一支 AI 智能体小队

GitHub 周榜第一：手把手组建你的第一支 AI 智能体小队

今天带你动手做一件事： 把 Claude Code 和 Codex 装进同一支"小队"，一条命令启动，让建造者写代码、审查者来挑刺 ——你只管跟"队长"说要什么结果。

读完这篇你会带走什么： ① openrig 的完整安装与环境检查流程（命令可复制）② starter 小队的团队定义长什么样、每个角色干什么 ③ 启动小队、派发第一个任务的完整命令链 ④ 三个真实踩坑点和快照恢复技巧。

openrig（mvschwarz/openrig）今天实拍仍是 GitHub 周榜第 1 ，5774 star、428 fork，一句话定位： 把"一堆散乱的终端 agent"变成"有角色、有地址、可恢复的团队" 。它用 YAML 定义团队拓扑， rig up 一条命令拉起 tmux 会话、harness、就绪检查；团队成员之间可以用 rig send 互相发消息协作。单开十个 Claude Code 窗口的人，值得花 20 分钟试试这个。

金句：一个 harness 包住一个模型，一个 rig 包住你所有的 harness。

动手前确认三样东西，缺一不可：

• Node.js 22 或 24

  （Ubuntu 自带的 Node 18 太老，用 nvm 装： nvm install 22 ）

• tmux

  （ tmux -V 能出版本号就行）

• Claude Code 或 Codex 二选一

  ，提前登录好（ claude auth login 或 codex login ）。注意： 不需要两个订阅 ，有一个就能跑；官方文档明确说"复用你已有的账号选择"。

金句：先有登录，再谈小队——agent 跑不起来，99% 是 provider 没登录。

一条命令，全局安装：

npm install -g @openrig/cli

装完验证版本号（我这台实测输出如下）：

rig --version
# 0.6.6 (2620dea8)

openrig 自带一个体检命令，先跑它，有问题早暴露：

rig doctor

我的实测结果：Node v24.20.0、tmux 3.4、daemon 发行包全部 [OK] ，只有一个 [WARN] cmux_shell: cmux not found —— 这个警告可以直接忽略 ，cmux 只是可选的终端管理增强，没有它 openrig 照样跑。

体检通过后启动 daemon（本地控制平面）：

rig daemon start
# Daemon started on port 7433

daemon 是整套系统的"大脑"：CLI、终端 UI、MCP 服务器都连它，团队状态存在它下面的 SQLite 里。

步骤三：看懂你的第一支小队

openrig 内置了几支"官方小队"，用下面这条命令看团队库：

rig specs ls

你会看到 starter （入门）、 workshop （持续开发）、 factory （7 人产品团队）等。今天我们只玩 starter ——一个建造者 + 一个审查者，干"一个有边界的小改动"。先预览它的定义：

rig specs preview starter --kind rig

这支小队的 YAML 定义（在 daemon/specs/rigs/launch/starter/rig.yaml ）我替你拆开了，核心就三行信息：

• build

  ：runtime 是 claude-code ，角色是 builder（建造者） ，负责写代码

• review

  ：runtime 是 codex （默认模型 gpt-6-astra），角色是 reviewer（审查者） ，负责挑刺

• edges

  ： build delegates_to review ——建造者完工后，自动把活儿递给审查者

第一次玩建议就从 starter 开始，别贪多：两个座位、一条协作边，出问题一眼就能定位。等你把"派任务→看队列→收结果"这个闭环跑顺了，再去碰 4 人的 workshop 或 7 人的 factory。团队库里的其他现成小队也值得了解一下，方便你按需升级：

• workshop

  ：lead + builder + QA + reviewer，适合"在一个仓库里持续干活"，从官方 pinned 列表安装

• factory

  ：7 个 agent（lead、advisor、build、QA、design、两个独立 reviewer），适合长期产品开发；你把想法告诉 advisor，lead 负责带队执行

• code-review

  ：两个独立 reviewer，适合只想找人挑刺的场景

• research

  ：analyst + synthesizer，适合调研类任务

金句：小队的本质是一个 YAML 文件：谁在队里、用什么模型、活儿怎么流转，全写死了。

进到你的项目目录，启动：

cd /path/to/your/repository
rig up starter --cwd . --plan # 先看计划，不真正启动
rig up starter --cwd . # 确认没问题，正式启动

--plan 是个好习惯：先看它要起哪些 tmux 会话、做什么就绪检查，再动手。

启动后检查每个"座位"是否就绪：

rig ps --nodes --rig starter

如果某个座位卡在登录或权限提示上， rig ps 会直接告诉你用 rig seat continue 接着走—— 先解决提示，再派活 。

然后，给建造者派第一个任务（地址格式是 角色@小队名 ）：

rig send dev-build@starter 'Implement <一个具体的小改动>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-review in this rig to check the exact candidate, and record the result and how I can try it.'

这条指令里藏着小队协作的精髓： 让 builder 自己把任务登记到队列、本地验证、主动请 review 座位的同事检查候选改动 。任务队列随时可查：

rig queue list --destination dev-build@starter --limit 1000

想看小队的实时状态，打开终端 UI 仪表盘：

rig tui --shared

官方演示里的 TUI 长这样——拓扑图、座位表（runtime、模型、上下文、状态）、单个座位详情：

金句：每个 agent 都跑在一个你能随时 attach 进去的 tmux 会话里——小队是"被管理的"，不是"黑盒"。

跑完上面四步，对照这个清单自查：

• 安装验证

  ： rig --version 输出 0.6.6 （或更新）

• 环境验证

  ： rig doctor 无失败项（WARN 的 cmux 可忽略）

• 团队验证

  ： rig specs preview starter --kind rig 能看到 build + review 两个成员

• 运行验证

  ： rig ps --nodes --rig starter 里两个座位都是就绪状态； rig send 发出去的任务能在 rig queue list 里查到

四个全绿，你的第一支多智能体小队就算正式开工了。日常收尾用快照—— rig down --snapshot 把整支小队的完整状态存下来，下次 rig up <名字> 一键恢复，连上下文都还在。

另外两个日常高频命令建议收藏： rig broadcast 可以给全队群发消息（比如统一换需求方向）， rig chatroom 则开一个多人聊天室让几个 agent 直接对话。对于长期项目，还可以用 rig grow / rig shrink 动态增减座位，不用推倒重来——小队是活的组织，不是起一次就定死的脚本。

常见坑（都是实测和文档里明确写的）

• 坑 1：Node 版本不对

  。Ubuntu 24.04 自带 Node 18，装完 CLI 会直接报错。必须用 nvm 或 NodeSource 装 22/24，我实测 v24.20.0 一次通过。

• 坑 2：provider 没登录就启动

  。 rig setup 最后一步会报 FAILED [4/4] ，别慌——这不是安装失败，是提醒你去 claude auth login 或 codex login 。登完继续就行。

• 坑 3：以为默认是"全自动 YOLO"

  。 YOLO 默认是关闭的 ：普通座位跑 rig up 这类生命周期命令时还会弹确认；真想全放开要显式选 full-bypass 策略。默认保守是好事，别一上来就关。

• 坑 4：Windows 用户

  。原生 Windows 不支持，走 WSL2。

openrig 解决的不是"agent 更聪明"，而是"agent 别乱"—— 当你同时开 3 个以上 coding agent 时，就该给它们一个 rig 了 。

明天继续：带你玩 openrig 的 7 人 factory 小队。