OpenRig Rig Mission 与 Mission Control 详解：7个视图+7个写动词的完整任务控制面指南-二趣网

OpenRig Rig Mission 与 Mission Control 详解：7个视图+7个写动词的完整任务控制面指南

【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: long-running teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig

OpenRig（openrig）是一个把Claude Code 与 Codex 作为同一个系统协同运行的多智能体（multi-agent harness）框架。本文带你快速看懂它的两大核心概念：Rig（多智能体装配蓝图）与Mission Control（任务控制面）——包括 7 个只读视图、7 个写动词，以及如何用它们掌控一整个 AI 团队的日常运转。🎛️

一、OpenRig 是什么？为什么要 Mission Control？

OpenRig 的架构可以这样理解：

Rig：一份声明式的"团队装配图"，用 YAML 定义有哪些 pod、每个 pod 里有哪些智能体（seat），以及它们各自的启动上下文。
Seat：Rig 中的一个座位，对应一个真实运行的 AI 会话（如 Claude Code 或 Codex 会话）。
Queue：各座位之间流转的任务包（qitem），支持"热土豆"交接、优先级排序与阻塞处理。
Mission Control：面向操作者（你）的任务控制面——在网页 UI、手机浏览器或 CLI 中，用统一的视图和动作管理整个 Rig。

官方演示就是一份现成的 Rig 配置：demo/rig.yaml，以及配套的智能体定义，例如 demo/agents/lead/agent.yaml 与团队文化文件 demo/culture.md。跑一下 demo/run.sh 就能体验完整链路。

二、Rig：你的多智能体装配蓝图

Rig 的精髓是"一个文件描述整个团队"。一个典型的rig.yaml会声明name、culture_file（团队文化，物化到每个座位的提示文件里）以及pods（成员列表）。

CLI 提供了四个最实用的rig spec子命令（实现见 rig.ts）：

命令	作用	典型场景
`rig spec show <rig-id>`	打印能重建某个运行中 Rig 的规格	导出当前配置、生成模板（`--as-template`）
`rig spec validate <path>`	纯 schema 校验，秒级反馈	提交前快速检查
`rig spec audit <path>`	建议式审计（缺 culture、seat 重命名未同步等）	团队规范治理
`rig spec preflight <path>`	启动前诊断，检查环境与上下文就绪	上生产前体检

💡 小贴士：audit只会给建议、不阻塞启动；validate才是硬校验。日常开发建议"先 validate、再 audit、最后 preflight"三步走。

三、Mission Control 的 7 个视图：手机上也能掌控全局

Mission Control 的读侧由 mission-control-read-layer.ts 实现，HTTP 路由见 mission-control.ts。7 个视图分别回答 7 个不同问题：

#	视图	回答的问题	数据来源
1	`my-queue`	"现在轮到我处理什么？"	发给我（操作者座位）的 human-gate 任务
2	`human-gate`	"全系统有哪些待人工决策？"	所有 human-gate 层级任务
3	`fleet`	"哪些 Rig/节点在跑？"	聚合`rig ps`的舰队状态（含 CLI 版本漂移提示）
4	`active-work`	"哪些工作在推进/被阻塞？"	pending/in-progress/blocked 任务，按优先级排序
5	`recent-ships`	"最近交付了什么？"	最近完成的 10 条（done / handed-off）
6	`recently-active`	"最近谁在动？"	视图投影器（ViewProjector）聚合
7	`recent-observations`	"智能体们最近观察到了什么？"	流式事件存储（stream_items）

所有视图统一走同一套9 字段紧凑状态模型（rig/任务名、当前阶段、状态、下一步、待人工决策、阅读成本、最后更新、置信度/新鲜度、证据链接），保证在手机上浏览时"一行看懂一件事"——这是设计文档里明确标注为不可妥协的验收标准。

前端入口是 MissionControlSurface.tsx，审计历史视图见 AuditHistoryView.tsx。

四、7 个写动词：每个动作都是一笔原子事务

写侧由 mission-control-write-contract.ts 实现。每个动词 = 一次原子事务：校验目标 qitem → 修改队列 → 追加审计记录 → 发出事件，要么全成、要么全败。

动词	效果	一句话理解
`approve`	state → done	"同意，放行"
`deny`	state → done（closure: denied）	"否决，结案"
`route`	关闭当前任务，在目标处新建一跳任务	"这件事归它管"
`annotate`	不改队列，仅记录批注	"留个言"
`hold`	state → blocked	"先挂起"
`drop`	state → done（closure: canceled）	"丢弃"
`handoff`	源任务 → handed-off，同时在目标创建新任务包	"交接棒"（含可选唤醒通知）

📌 版本演进：早期契约是上述 7 个动词；后续版本（OPR.0.4.4.19）新增了第 8 个resolve动词，用于回应"卡在人工座位上的 leg-1 阻塞任务"——它不关闭任务（blocked → in-progress），而是把你的决策文本持久化到队列迁移记录中。完整动词清单定义在 mission-control-action-log.ts。

动词执行后，系统还会：

追加式审计：所有动作写入 append-only 的mission_control_actions表（只有record()，没有 UPDATE/DELETE），随时可通过GET /api/mission-control/audit按动词、操作者、时间范围回溯。
最佳努力通知：handoff等动词默认附带唤醒通知；通知失败不会回滚已落盘的状态变更——这是明确的设计不变量。
SSE 实时推送：GET /api/mission-control/sse（别名/watch）实时推送mission_control.action_executed等事件，UI 自动刷新，无需轮询。
安全边界：写动词挂载了 bearer token 鉴权中间件；跨主机操作时，同一个动词会转发到任务所在源主机的 daemon 执行，一条写入路径、一份动词白名单。

五、新手上手三步走

看演示：打开 demo/README.md，运行 demo/run.sh 启动一个 6 座位（lead/design/impl/qa/r1/r2）的示例 Rig。
看全局：在 Mission Control 中从fleet视图认识你的 Rig 拓扑，再切到active-work看任务推进。
做决策：当human-gate出现待办时，用approve/route/handoff等动词处置它，并到审计视图确认动作留痕。

六、核心文件索引

路由层（HTTP API）：packages/daemon/src/routes/mission-control.ts
读侧（7 视图）：packages/daemon/src/domain/mission-control/mission-control-read-layer.ts
写侧（动词契约）：packages/daemon/src/domain/mission-control/mission-control-write-contract.ts
审计日志（append-only）：packages/daemon/src/domain/mission-control/mission-control-action-log.ts
前端表面：packages/ui/src/components/mission-control/MissionControlSurface.tsx
CLI（rig spec）：packages/cli/src/commands/rig.ts
示例配置：demo/rig.yaml

总结

OpenRig 的设计哲学很清晰：Rig 负责"定义团队"，Queue 负责"流转工作"，Mission Control 负责"人来决策"。7 个视图让你在任何设备上一眼看清系统状态，7 个写动词（外加新增的resolve）让每个决策都原子、可审计、可回放。掌握这套"任务控制面"，你就从"盯着终端看日志"升级为"指挥整个 AI 舰队"的运营者。🚀

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析