企业官网建设流程全解析

OpenRig implementation-pair 与 research-team 模板：开箱即用的 Agent 协作形态完全指南

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

OpenRig 是一个多 Agent 编排工具（multi-agent harness），可以把 Claude Code 和 Codex 两个编码助手装进同一套"机甲"（Rig）里协同工作。它内置了多个现成的协作模板，其中implementation-pair（开发配对）和research-team（研究团队）是最适合新手起步的两套 Agent 协作形态：一条命令启动，角色、技能、通信关系全部预配置好，你只需要下达任务。

什么是 OpenRig：给 AI 编码助手建一个"团队"

单独运行 Claude Code 或 Codex 时，它们只是一条条终端会话；OpenRig 则把它们组织成一个持久化、有地址、可恢复的Agent 团队。核心能力包括：

• YAML 定义拓扑：用 RigSpec 声明式地描述"谁和谁在一起、谁向谁汇报"
• 一键启动：rig up自动创建 tmux 会话、注入身份与环境、执行就绪检查
• 可视化拓扑：TUI 里以表格和图的形式查看每个席位（Seat）的运行时、模型、上下文与状态
• 跨 Agent 通信：rig send、rig broadcast让 Agent 之间互相交接任务
• 快照与恢复：重启后按名字恢复整个团队，工作不丢

implementation-pair：开发 + QA 的双人小组

implementation-pair是一个 2 席位的开发 Pod，一个写代码、一个做验证，正好对应"信任但验证"的工程文化。它的完整定义见 rig.yaml：

两个席位之间有一条delegates_to边：实现完成后可以直接委托 QA 验证。角色行为由各自的技能包（如test-driven-development、verification-before-completion）和启动时注入的角色说明（role.md）共同约束——implementer 的开工动作是先rig whoami解析任务上下文，再"复现缺陷、最小修改、运行对应检查"。

💡 注意模板的设计哲学：没有配置独立的检查环节时，走的是轻量验收路径，而不是每次提交都触发审批循环——这让小改动保持高效。

research-team：编排者 + 分析师 + 综合者的三人研究组

research-team适合"调研一个技术选型""对比多个方案"这类需要分头深入、再汇总输出的任务。定义见 rig.yaml，结构分为两个 Pod：

orch（编排 Pod） └─ lead → orchestrator（Claude Code）：协调任务、监控进度、桥接通信 research（研究 Pod） ├─ analyst → analyst（Claude Code）：深挖调查、收集证据 └─ synthesizer → synthesizer（Codex）：把发现整合成可执行的摘要

两条delegates_to边从orch.lead分别指向research.analyst和research.synthesizer，形成一个典型的星型编排拓扑：你只跟 lead 说清楚要什么结论，由它分派调查与汇总。对应 Agent 定义分别位于 analyst/agent.yaml、synthesizer/agent.yaml 和 orchestrator/agent.yaml。

此外，研究类 Rig 会自动获得探索型 Culture（协作规范文件），而实现类 Rig 获得保守的"信任但验证" Culture——协作气质也是模板的一部分。

三步快速启动你的第一个协作团队

前置要求：macOS 或 Linux，Node.js 22/24，tmux，以及已登录的 Codex。

# 1. 全局安装 CLI npm install -g @openrig/cli # 2. 在你的代码仓库目录启动模板 rig up implementation-pair --plan # 先预览启动计划 rig up implementation-pair # 确认后启动 # 或者启动研究团队 rig up research-team # 3. 打开共享 TUI 面板查看团队 rig tui --shared

📌 启动前建议先用rig setup --dry-run查看安装计划，再用rig doctor体检环境。启动完成后用rig ps检查每个席位的就绪状态，再发第一条任务消息，例如：

rig send dev.impl@implementation-pair "实现 <一个明确的小改动>，完成后委托 dev.qa 验证并记录结果。"

用 TUI 拓扑图看懂团队协作关系

rig tui --shared打开的终端界面是理解团队协作形态最好的入口：拓扑视图把 Pod、席位和委托边画成一张图，表格视图则列出每个 Agent 的运行时、模型、上下文占用与当前状态。

按Ctrl-b后按d可脱离面板但保持团队运行；想回到面板随时重新执行rig tui --shared。

想自定义？从两份 YAML 入手

两套模板的"配方"就是仓库里可读可改的 YAML 文件，学习它们的写法即可搭建自己的协作形态：

• Rig 层（团队结构）：implementation-pair/rig.yaml —— 声明 Pods、成员、运行时与edges委托关系
• Agent 层（角色能力）：如 implementer/agent.yaml —— 声明技能包、插件、运行时资源与启动时注入的角色文件
• 角色行为：guidance/role.md决定 Agent 的开工流程与交付契约

修改时建议只动两类字段：edges（改汇报关系）和 Agent 的skills（改能力装载），其余保持默认即可。更多内置模板（adversarial-review、secrets-manager、conveyor等）可用rig specs ls浏览，rig specs preview <名字>查看细节。

小结：为什么选这两个模板起步

• implementation-pair：2 席位、一写一验，覆盖"改代码 + 自动 QA"的最常见诉求，且刻意避免了过度的审批链
• research-team：3 席位、星型编排，覆盖"深挖 + 汇总"的研究型任务，lead 单一入口降低指挥成本
• 两者都是声明式 YAML，改起来就是改配置文件，配合 README.md 中的快照/恢复能力，团队协作形态可以版本化、可复制

从一条rig up命令开始，把散落的终端会话升级成一支有名字、有地址、可恢复的 Agent 团队——这就是 OpenRig 开箱即用的价值所在。

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