GitHub 周榜第一：手把手组建你的第一支 AI 智能体小队|agent|daemon|login|小队|新模型|智能体

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 没登录。

步骤一：安装 CLI

一条命令，全局安装：

npm install -g @openrig/cli

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

rig --version
# 0.6.6 (2620dea8)

步骤二：体检 + 启动 daemon

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。