openrig 🤝 把 Claude Code 和 Codex 塞进同一副挽具的多智能体 harness
先讲一个大概每个 AI 编程工具重度用户都经历过的场面：
你左手一个终端跑着 Claude Code，右手一个终端开着 Codex。你在左边让它帮你重构那个该死的 OrderService，然后切到右边，让它基于"最新代码"写配套测试。二十分钟后你回来一看——左边的 Agent 已经把文件挪到别的目录了，右边的 Agent 还在对着旧路径疯狂 import 报错，两个终端各自自信地告诉你"任务已完成 ✅"。
那一刻你大概会想：这两个家伙要是能认识彼此，会不会好一点？
今天 GitHub Trending 上出现的 mvschwarz/openrig，试着回答的正是这个问题。它的项目描述短得几乎像一句口号：
Multi-agent harness that runs Claude Code and Codex together as one system
翻译过来就是：一个多智能体"挽具"，把 Claude Code 和 Codex 当作同一个系统来运行。
🛠️ 先抠一个词：为什么是 harness，而不是 framework
很多人看到这类项目，第一反应是"又是一个 Agent 框架"。但作者选的词很讲究——harness，挽具。
框架是你从零开始搭东西的地基，你得按它的世界观写代码；而挽具是套在已经能跑的马身上的那套绳子和皮带。马还是那两匹马，脾气、步频、力气都没变，变的只是——它们现在被拴在同一辆车上了。
这个区别很关键。Claude Code 和 Codex 本身都是成熟、独立、能自洽运行的命令行 Agent。openrig 没有试图去重写它们、替换它们，也没有重新发明一套 Agent 循环。它做的是外挂一层协调结构：在两者之上加一套共同的运行契约，让它们从"两个各自干活的进程"变成"一个系统里的两个角色"。
🚦 "一起跑"和"一个系统"，差着十万八千里
同时开两个终端也叫"一起跑"。但"一个系统"意味着一些更硬的东西：
- 共享的上下文前提——两个 Agent 对"当前任务是什么、做到哪一步了"要有同一份认知，而不是各持一个过期快照；
- 清晰的角色划分——谁负责提案、谁负责执行、谁负责挑刺，而不是两个都抢着改同一个文件；
- 统一的产出归属——最终的改动应该被看成"这个系统干的活"，而不是两堆互相打脸的 diff；
- 可收敛的决策——两个 Agent 意见不一致时，系统得有办法让讨论结束，而不是无限互相 review。
这些问题听起来像工程细节，其实每一个都是产品设计的十字路口。openrig 把命题直接压缩成"as one system"这几个字，态度是明确的：它不打算做一个"多开管理器"，它要做的是一个协作单元。
🔍 概念层面，这层挽具大概要管什么
抛开具体实现（项目还年轻，很多细节值得去仓库里自己翻），一个多智能体 harness 抽象下来，绕不开的就是下面这套骨架：
┌───────────────┐ ┌───────────────┐
│ Claude Code │ │ Codex │
└───────┬───────┘ └───────┬───────┘
│ │
└────────────┬─────────────┘
▼
┌─────────────────┐
│ openrig │ ← harness 层
│ (multi-agent) │
└────────┬────────┘
▼
同一个工作区 · 同一个任务 · 同一份状态
而一个任务从进入到落地，harness 需要回答的无非是四件事：
任务进来
├─ 谁来主导？（分派 / 编排）
├─ 谁来动手？（执行 / 工具调用）
├─ 谁来验收？（交叉检查 / 复核）
└─ 改动怎么记账？（共享状态 / 冲突消解）
这四个问题里，最容易被低估的是最后一个。两个 Agent 共享一个文件系统，本质上就是一个并发写入问题——只不过冲突的不是线程，而是两套语言模型的判断。谁先写、谁后读、谁的改动算数，这些在单人使用 Agent 时从没出现过的问题，在"一个系统"里全都会冒出来。
🎭 为什么值得把两个模型放一起？
一个很自然的怀疑是：为什么不干脆选一个更强的用？
从项目定位本身来看，openrig 押注的不是"某个模型更强"，而是差异化本身就是资源。不同的编程 Agent 在长上下文保持、指令遵循、代码风格偏好、探索欲上往往各有脾气。你让一个写、另一个挑毛病，得到的往往不是"两份方案里更优的那个"，而是第三种、双方都没单独想到的方案——这一点在任何做过 code review 的团队里都能找到共鸣：最好的 review 意见，通常来自那个和你思路不太一样的同事。
把这种"认知差异"工程化、自动化，就是多智能体 harness 有意思的地方。它要解决的不是模型能力问题，而是协作结构问题。
📦 谁该盯一下这个项目
如果你属于下面这几类人，openrig 值得你花十分钟翻一翻仓库：
- 已经在日常使用 Claude Code 或 Codex，并且受够了"两个终端各说各话"的割裂感；
- 对 multi-agent 编排感兴趣，但不想从零搭一套 Agent 运行时；
- 关注 AI 编程工具从"单点助手"走向"团队化协作"这条演进路线的人。
反过来说，如果你只是想让 AI 帮你写个正则，那这个项目的复杂度远超你的需求——挽具是给拉车的马准备的，不是给遛弯的狗准备的 🐕。
🌟 真正常识性的收获：Agent 的下一站是"组织"
回看过去两年 AI 编程工具的演进，主线其实很清晰：
第一代比的是补全得多准；第二代比的是能不能自己跑完一个任务；而现在，像 openrig 这类项目暗示的是第三代命题——多个 Agent 之间怎么组织起来。就像软件工程的历史一样，当单个程序员的产出触到天花板之后，真正带来数量级变化的东西不是"更厉害的程序员"，而是版本控制、CI、code review 这些协作基础设施。
openrig 现在还只是一个 harness，一个把两匹马拴在一起的挽具。但"as one system"这五个字的野心不小：它在尝试给 AI 编程补上那块一直缺失的拼图——让 Agent 从孤独的天才，变成能配合的同事。
至于这副挽具拉不拉得动车，最好的验证方式永远是自己套上试试 🚀。
项目地址：github.com/mvschwarz/openrig —— 如果你也曾在两个终端之间来回横跳，不妨去看看它打算怎么把这件事做得更体面一点。
