OpenRig 是一个开源工具，用来基于 Claude Code、Codex、Pi 等编码 Agent 搭建自有的 Agent 网络。它把多个编码 Agent 组成有角色分工、共享上下文、各管一块工作的持久化团队，而不是一次性调用。项目上线一周多即在 GitHub 获得 6.7k star，本周新增 2,068 star。 定价：开源免费（GitHub 开源项目，具体以官方说明为准）。编辑评分：⭐ 4.6。
OpenRig是什么？
如果你用过 Claude Code、Codex、Pi 这类编码 Agent，大概会有同一个体感：它们都是"一次性"的。你提需求，它干活，干完这一轮就结束了，上下文散在对话里，下次还得重新交代一遍。
OpenRig 想解决的就是这个问题。它是一个开源工具，做的事情不是再造一个编码 Agent，而是把你手里已有的编码 Agent 组织成一个团队——有角色分工、共享上下文、各管一块工作，而且是持久化运行的，不是用完即走的临时调用。
打个不那么精确的比方：以前你是在单独指挥几个外包，现在你在带一个小团队。
项目在 GitHub 上开源（github.com/mvschwarz/openrig），上线一周多就拿到 6.7k star，本周新增 2,068（数据来源：GitHub Trending）。这个增速在工具类项目里算相当猛的，说明"多 Agent 协作"确实是很多人在盯的方向。
核心功能
1. 基于 Claude Code、Codex、Pi 搭建自有 Agent 网络
OpenRig 本身不是 Agent，它是编排层。这一点挺关键——你不用换掉已经用顺手的编码 Agent，它负责把这些 Agent 串成一张网。对已经在用 Claude Code 或 Codex 的人来说，迁移成本几乎为零。
2. 给多个 Agent 分配角色与职责
每个 Agent 可以设定明确的角色，比如谁负责写业务逻辑、谁负责测试、谁负责文档。实际使用中，角色定得越清楚，Agent 之间互相"踩脚"的情况越少。这其实和带人一样，职责模糊是混乱的源头。
3. Agent 之间共享上下文
这是多 Agent 方案最容易翻车的地方。各自为战、信息不通，最后合到一块就是一锅粥。OpenRig 把上下文做成团队共享的，避免了每个 Agent 都要从头理解项目。
4. 每个 Agent 各管一块工作，分工协作
除了角色，还有工作边界的划分。多个 Agent 可以并行推进各自负责的部分，而不是排队等一个 Agent 从头做到尾。
5. 以持久化团队形式持续运行
不是"提问—回答—结束"这种一次性调用，团队是长期存在的。对需要反复迭代的项目来说，这个差别很实际：不用每次都重新交代背景。
另外，开源代码本身也是功能之一——可以自行部署和二次开发，这对团队内部有定制需求的场景很重要。
版本/套餐对比
说实话，目前没有可对比的版本或套餐。上下文信息里也没有价格资料，所以这里不硬凑。
| 项目 | 说明 |
|---|---|
| 获取方式 | GitHub 开源仓库，可直接查看与使用 |
| 定价 | 开源项目，暂未公开收费版本信息 |
| 首发时间 | 2026 年 10 月 |
| 依赖 | 需要自备 Claude Code、Codex、Pi 等编码 Agent |
需要提醒一句：项目较新，功能和文档都还在快速演进中，别指望现在就有成熟的商业化版本矩阵。现阶段它更像是给愿意动手折腾的人准备的。
值不值得用？
优点：
- 开源，代码透明，能自己部署也能改
- 不绑定某一个 Agent，Claude Code、Codex、Pi 都能接进来，这点比很多"全家桶"式方案舒服
- 多 Agent 角色分工 + 共享上下文，思路是对的，也确实解决了单 Agent 做复杂项目时上下文断裂的问题
- 持久化团队的设计，比一次性调用更贴近真实工程场景
- 社区热度摆在那儿，一周多 6.7k star，本周 +2,068，说明有人在认真用、也有人愿意贡献
缺点：
- 项目太新，文档和功能都在变，今天能跑通的配置明天可能就调整了
- 不是开箱即用。你得先有 Claude Code、Codex 或 Pi 这类编码 Agent，它才有意义
- 多 Agent 持久化团队的配置和协作调优是有门槛的。角色怎么分、上下文怎么共享、边界怎么划，这些没有标准答案，得自己摸
总体结论： 方向值得关注，但适合动手能力强的人先试。如果你的日常工作本身就重度依赖编码 Agent，OpenRig 能帮你把零散调用升级成有组织的协作；如果你只是偶尔用 AI 写写代码，现在上手可能有点杀鸡用牛刀——建议先观望，等文档和生态再成熟一点。
使用建议
- 先跑通最小案例。 别一上来就搭五六个 Agent 的完整团队，先用两三个角色跑一个真实的小项目，摸清共享上下文和分工的机制。
- 角色划分从职责出发，不要从 Agent 出发。 先想清楚这个项目有哪几块活、需要什么视角，再决定配几个 Agent。反过来做很容易配出一堆重叠的角色。
- 别把它当自动化流水线。 持久化团队的价值在于持续协作，不是一次性批处理。如果你的任务是"跑一次拿个结果"，单次调用反而更快。
- 盯紧仓库更新。 项目还在快速迭代期，配置项和 API 可能变。建议固定一个能跑通的版本，同时关注上游的更新说明。
- 要有调优的心理准备。 多 Agent 协作的收益不是自动出现的，上下文怎么共享、边界怎么切，都需要按你自己的项目反复调。
适合谁用？
推荐：
- 已经日常使用 Claude Code / Codex / Pi 的开发者
- 手上有需要长期迭代、涉及多个模块的中大型项目
- 愿意折腾配置、能接受项目早期不稳定的人
- 想研究多 Agent 协作机制、或打算基于它做二次开发的团队
可考虑：
- 对多 Agent 协作感兴趣，但目前还没有固定编码 Agent 工作流的个人开发者
- 中小团队里想试点 AI 协作流程的技术负责人
- 想先读代码学习编排思路、暂不实际部署的人
不推荐：
- 只想"装上就能用"、不希望花时间调配置的用户
- 平时只是偶尔用 AI 补几行代码、没有复杂项目场景的人
- 需要稳定商业支持、完整文档和 SLA 的企业级场景（现阶段明显不满足）
- 完全不使用编码 Agent、指望 OpenRig 提供 Agent 能力的人——它不提供，它只做组织
