最近我在折腾一个有点“邪修”味道的工作流把 Claude Code 和 Codex CLI 同时挂到一个项目里让它们像两个不同工种的开发一样组队干活我本人只负责写需求卡片、看结果、偶尔骂两句“这里不对”。这个玩法圈内叫 vibecoding核心思想很简单——代码写得好不好不再是最重要的事能不能把 AI 的产出快速组装成可用产品才是。为了不让这两个 Agent 互相踩脚我找了个叫 OpenRig 的调度工具把整个过程理成了可复用的配置。这篇就当是踩坑记录加配置笔记写给那些已经烦透了“单 Agent 上下文越滚越长、改到后面连自己都忘了前面”的人。我自己试了一个礼拜结论是双 Agent 协作不是噱头是真的能把以前两小时的活压到二十分钟前提是任务边界画得够清楚。下面我会把环境搭建、核心配置、任务拆法、交接机制和踩过的坑全部拆开讲照做就行。1. 为什么我不再只开一个 Agent而是让两个 Agent 组队先说说动机。之前我一直用单 Agent 跑完整需求比如“给我做一个带后端的记账页面”。它确实能干但干到一半问题就开始冒出来上下文窗口撑不住前端样式还没完后端接口的设计已经被挤出了记忆改完前端改后端今天的 Agent 把昨天自己写的接口签名给忘了然后一脸自信地生成一套完全不匹配的代码。这个过程特别像让一个全能型选手同时负责方案设计、代码实现、测试验收最后所有人都知道他精力分散了。后来我把 Claude Code 和 Codex 分开跑一个终端管一个效果稍微好点但很快又崩了两个终端之间完全没有信息同步A 改了接口B 还在按旧签名写调用git 一合并全是冲突。我自己要来回切窗口、搬上下文这不叫协作叫传话筒。OpenRig 就是来解决这个问题的。它的思路特别朴素不要试图把整个仓库塞给一个大模型而是把这个仓库切成几个“工位”每个工位由一个 Agent 独立负责工位之间通过任务卡片、文件所有权和 git 分支来同步。Claude Code 和 Codex 各自有各自的优势场景有的擅长类型推导和重构类的后端逻辑有的在 UI 和状态管理上更顺手组队之后就能各干各的活互不干扰。如果你也遇到单 Agent 项目一复杂就“前面写得挺好后面开始胡说八道”的情况或者你手里有两个 API key 却不知道怎么用出效率这个玩法值得一试。它不要求你有多深的工程能力但要求你愿意把需求拆成小块——这恰恰是 vibecoding 最核心的动作。2. OpenRig 的定位编排层、任务卡与所有权地图OpenRig 不是模型也不太像传统的 CI/CD 工具。我更喜欢把它理解成一个“Agent 工头”它自己不写代码只负责把人两个模型安排到正确的工位上给他们发任务卡检查他们有没有越界然后在合适的时机让他们交接。2.1 三个核心设计调度器、任务卡、所有权地图第一个是调度器。它读一个 YAML 配置文件里面定义了每个 Agent 用哪个引擎、在哪个目录干活、拥有哪些文件、最多迭代多少轮。启动的时候执行openrig run --task ...调度器会把任务翻译成每个工位的子任务然后按顺序或并行发起。第二个是任务卡。每个工位工作时都会在.rig/tasks/目录下维护一个 markdown 文件里面写清楚目标、当前状态、已完成的工作、下一步建议。这看起来很像现在流行的“AI 规范文件”但区别在于它是动态更新的Agent 每做完一步就把状态推进一格另一个 Agent 在下一次开工前会先读最新的卡片。第三个是所有权地图。这玩意儿是防止冲突的关键。配置里每条 worker 都有ownership字段比如src/api归 Claude Codesrc/pages归 Codex。调度器会在启动时生成一把锁任何 Agent 要修改不属于自己所有权范围内的文件都会被 OpenRig 拦下来并提示“越界操作”。这从根本上解决了两个 Agent 同时改同一个文件的问题。2.2 为什么不推荐直接开两个终端各跑各的很多人会问我自己开两个终端手动分配活不也一样我试过差别非常大。手动模式的问题在于没有任何强制边界Agent A 不知道 Agent B 改了什么更不知道哪些文件不能碰。你靠嘴来协调最后你成了瓶颈。OpenRig 解决问题的角度不是“让 Agent 更聪明”而是“让傻 Agent 也不至于互相伤害”。它通过文件锁、任务卡、分支隔离把协作这件事从“靠模型自律”变成了“靠机制约束”。对于目前的大模型能力来说机制约束比自律靠谱得多。下面这张表是我自己体感上的对比方便你快速判断要不要入坑对比维度单 Agent 直接干手动双开终端OpenRig 编排双 Agent上下文压力全仓一个上下文后期必乱各自独立但没有同步各自独立且通过任务卡同步冲突风险无冲突但有逻辑不自洽极高合并时头大低所有权地图硬性兜底角色分工一个模型干所有活靠人肉分配配置里明确分工适合的项目小脚本、一次性任务中大型但容忍乱需要持续迭代的仓库心智负担低高你是协调者中前期配好后面省心3. 环境准备与最小配置半小时把两个 Agent 拉起来干活配置并没有你想象中那么玄学。整个环境准备加最小配置半小时内就能跑通。我假设你已经装好了 Node.js 18、Python 3.10 和 git并且电脑上已经能分别使用 Claude Code 和 Codex CLI 这两个命令行工具。如果你还没装先把它们各自的官方 CLI 搞定能单独跑通一个“修复这个 typo”的任务再回来。3.1 安装 OpenRig 与密钥配置我自己是直接用源码跑的因为 CLI 工具还处于快速迭代期用 npm 安装也能用但更新跟不上。建议这样git clone https://example.com/openrig openrig cd openrig npm install npm link这个npm link会把openrig命令挂到全局之后你就能在任何项目目录里调用了。密钥方面不要在配置文件里写 API key。OpenRig 会从环境变量里读export ANTHROPIC_API_KEY你的key export OPENAI_API_KEY你的key用环境变量的好处是配置文件可以安全地提交到 git 里别人 clone 下来只需要配自己的 key。千万别犯我犯过的错——第一次我图省事把 key 直接写进rig.config.yaml后来差点把仓库推到公共平台吓出一身汗。3.2 初始化项目与最小配置进入你的项目目录执行openrig init它会生成一个rig.config.yaml模板。我第一次看这个文件的时候以为是在写 K8s 配置后来发现没那么复杂。一个能跑通的最小配置长这样version: 1 team: - name: claude-worker engine: claude cwd: ./src ownership: [src/api, src/domain, src/lib] role: 后端接口、数据模型与核心逻辑 max_iterations: 30 exit_when: 任务卡中所有 todo 项均为 done - name: codex-worker engine: codex cwd: ./ui ownership: [src/pages, src/components, src/store] role: 前端页面、状态管理与交互逻辑 max_iterations: 30 exit_when: 任务卡中所有 todo 项均为 done每个字段都有实际意义别照抄就完事。cwd决定了 Agent 的默认工作目录ownership决定了它能改哪些文件role会作为系统提示词的一部分注入告诉 Agent 它在这个团队里是什么角色。exit_when是 Agent 判断自己什么时候该收工的条件没有这个限制的话它可能会一直“优化”下去你的 API 账单也会一直涨。3.3 跑通第一次协作配置好之后创建一张最最简单的任务卡openrig run --task 在 src/lib 下新增一个 readFileAsBase64 工具函数并在 src/api 中调用它这个任务的意图就是让 claude-worker 独立完成Codex 不掺和。跑完之后你会看到 OpenRig 的输出里有一个任务卡文件里面记着 Agent 每一步做了什么。第一次跑通之后再尝试跨工位任务也就是需要两个 Agent 配合的那种。一开始可以把任务写得非常小小到只有一个文件新增、一个文件调用跑通这个流程后面再放复杂需求。提示如果你的代码库很大第一次跑openrig init后建议先手动删掉.rig/tasks里的历史任务卡避免 Agent 被上一次的旧结论干扰。4. 任务拆解、上下文隔离与交接机制组队的隐藏骨架配置只是表面真正让双 Agent 协作成立的是任务拆解的思路和上下文隔离的手段。这一节可能是全文里最值得反复看的部分因为大多数双 Agent 项目跑崩不是工具不行是拆活和交接没做好。4.1 按“文件边界”拆不按“语言”拆我见过最典型的错误是把任务拆成“前端用 React 写后端用 Python 写”。听起来很合理但实际上前后端之间往往共享类型定义、接口文档、工具函数。一个改接口字段另一个就要跟着改调用边界完全没隔开。正确做法是按文件目录拆而且要选那种依赖关系少的目录边界。比如src/api和src/pages之间只通过接口文件交互那这两个目录就可以分别交给两个 Agent。拆任务卡的时候你要问自己一个问题如果这两个 Agent 之间完全没有实时通信各自做完各自的事最终能不能拼起来如果能这个拆分就是好的如果不能说明你们之间的隐性依赖太多了。4.2 上下文隔离让 Agent 只看自己该看的东西OpenRig 的上下文隔离是通过三层机制实现的。第一层是cwdAgent 默认只能看到这个目录下的文件不会一上来就扫描整个仓库。第二层是ownership即使 Agent 通过某些方式读到了其他目录的文件修改动作也会被拦截。第三层是 role 提示词告诉 Agent 你是谁、你在为谁工作、你的产出由谁消费。这三层隔离最大的价值不是减少 token 消耗而是减少“上下文污染”。单 Agent 项目里模型经常因为看到了太多无关代码然后在生成时把某些旧约定的风格带进来。隔离之后每个 Agent 看到的都是一个小而清晰的世界输出的一致性和稳定性能明显提升。我在实际项目里跑一个中型仓库时隔离后的代码修改行数比隔离前少了大概一半——因为 Agent 不再因为看到奇怪的历史代码而“画蛇添足”。4.3 交接不靠聊天记录靠任务卡两个 Agent 之间怎么交接很多工具的做法是把上一个 Agent 的对话记录直接塞给下一个 Agent。这个方案的问题在于对话记录里有大量的“尝试”“不对”“换一种思路”这类噪音真正有用的结论只占 10%。把 90% 的垃圾喂给下一个 Agent纯粹是在燃烧你的上下文预算。OpenRig 的交接机制是任务卡。每个 Agent 完成一轮之后必须更新.rig/tasks/task-id.md把状态推进到下一步。任务卡有约定格式模板长这样# 任务卡批量图片压缩功能 ## 目标 给 report 命令增加一个 --compress 选项支持对输出目录中的图片做批量压缩。 ## 当前状态 - [x] 确认现有 report 命令的输入输出格式 - [x] 在 src/lib 新增 imageCompressor.py 基础压缩接口 - [ ] 在 CLI 入口接入 --compress 参数待 codex-worker 处理 - [ ] 更新 README 中参数说明 ## 给下一个 Agent 的交接说明 CLI 入口在 src/cli/main.py 的 arg_parser 部分压缩接口已经暴露为 compress_image(input_path, output_path, quality85)直接调用即可。 不要在 src/lib 下再新建其他文件。这个格式的核心是“给下一个 Agent 的交接说明”必须具体到文件路径、函数名和禁忌。你写清楚这三个信息下一个 Agent 几乎不需要猜测就能继续干。写不清楚的话它大概率会重新读一堆代码而且可能读错方向。4.4 git worktree 和分支隔离的实践除了任务卡我在实际项目中还会给每个 Agent 开独立的 git worktree。这样即使它们同时改同一份代码也不会在物理上产生文件冲突。OpenRig 的配置里加一句branch_strategy: worktree-per-worker就能开启。每个 Agent 在独立的工作目录里干活完成后 OpenRig 把各自的改动 cherry-pick 回主分支或者生成一个合并请求让我手动审。这个机制最大的好处是即使某个 Agent 改崩了也不会污染另一个 Agent 的工作区。你在主分支该干嘛干嘛等它们产出稳定了再合并。这种“连坐都不坐”的隔离方式特别适合那些模型偶尔会抽风的任务场景。5. 实战给 demo-rig 项目加批量图片压缩功能的全程记录光讲理论没意思说一个我实际跑的完整例子。项目不重要随便起个名叫 demo-rig是一个用 Python 生成 HTML 报告的内部小工具。需求是加一个批量图片压缩功能用户希望在命令行里输入一个目录然后工具递归处理目录下所有图片输出压缩后的版本同时保留原文件的元信息。5.1 我作为“vibecoding 掌门人”只做了三件事第一件写需求卡片。第二件在rig.config.yaml里把任务拆给两个 Agent。第三件等它们干完我做 code review。整个过程我没写过一行代码。任务拆分的思路是压缩算法和文件遍历属于后端逻辑归 claude-workerCLI 参数解析和 README 文档更新属于用户交互层归 codex-worker。我创建任务卡openrig run --task 为 demo-rig 增加批量图片压缩功能 --plan-only--plan-only是 OpenRig 一个挺实用的模式只让调度器拆解任务并生成子任务卡不实际执行。拆出来的结果如果我觉得边界不合理可以直接改任务卡再放行。这个步骤强烈建议每次都用等于你先审一遍“施工图”再让 AI 进场。5.2 两个 Agent 的实际运行过程任务卡确认后我执行正式跑openrig run --task .rig/tasks/compress-image-task.md运行日志很有意思两个 Agent 几乎是并行开工的。claude-worker 先花了几轮探索src/lib下现有的文件结构然后开始写压缩模块codex-worker 同时在看src/cli/main.py的现有参数解析逻辑。大约两分钟之后claude-worker 更新了任务卡标注“压缩接口已完成”并给 codex-worker 留了交接说明函数签名是compress_image(input_path, output_path, quality85)CLI 入口需要加--compress参数。codex-worker 拿到任务卡后没有重新去看压缩模块的源码直接按照交接说明调用接口。这就是任务卡机制的价值——如果靠对话记录codex-worker 可能要花十轮去理解压缩模块的实现靠任务卡它一步就接上了。整个过程大概跑了 9 分钟两个 Agent 合计迭代了 28 轮产出了一个新增模块、一个 CLI 参数改动和一份 README 更新。5.3 最终产出与我的验收方式最后我打开.rig/workspace/demo-rig工作区里面是两个 Agent 的合并结果。我先跑了一遍测试cd demo-rig python -m pytest tests/一次通过。然后我手动跑了一下压缩命令确认生成的 HTML 报告里图片路径没有变化压缩后的图片也能正常打开。验收通过我把改动合并到了主分支任务卡归档到.rig/archive/。这次体验给我最大的感受是vibecoding 的掌控感不在于你写不写代码而在于你能不能把需求拆到“即使是最笨的 Agent 也能做对”的粒度。我全程没碰代码但每一步决策我都参与了。6. 踩坑实录文件冲突、请求风暴与上下文污染这个部分没有实操之外的侥幸全是真金白银换来的教训。我把这一个礼拜踩过的坑按严重程度排一遍希望你看到的时候能少交一点学费。6.1 坑所有权地图漏配两个 Agent 同时改一个文件第一次跑协作任务时我的配置里ownership只写到目录粒度没有精确到单个文件。没想到有一个公共的src/shared/constants.py两个模块都会用到claude-worker 和 codex-worker 几乎是同一时间对这个文件做了修改。结局非常精彩一个是改常量名一个是在文件末尾加新常量合并时 git 直接报冲突两个 Agent 都以为对方改坏了。后来我把ownership细化到这个公共文件只归 claude-worker 管并且要求 codex-worker 如果要改公共文件必须先在任务卡里提出“修改申请”由 claude-worker 执行修改。这样一来公共区域有了唯一主人冲突自然消失。记住所有权必须精确到文件而不是只到目录。6.2 坑任务拆得太碎Agent 之间互相等待有一次我为了追求“每个任务卡都很小”把一个需求拆成了六个子任务卡结果两个 Agent 频繁进入等待状态调度器空转整个流程比单 Agent 还慢。原因很简单任务之间的依赖太强A 的产出必须被 B 读取B 完成之前 A 又无法继续流水线被拉成了串行。正确的拆法应该是“尽量并行少搞流水线”。你要让每个 Agent 手里的任务都能独立推进到可验收的状态而不是一个接一个传接力棒。依赖无法避免时尽量把依赖点压缩到一两个明确的关键交接处比如“等 claude-worker 完成接口定义后codex-worker 一次性接入”而不是每改一个函数都要等对方。6.3 坑上下文污染Agent 遗忘了约定之前我提过上下文隔离但还有一类污染来自“规范性约定”比如“函数命名用 snake_case”“日志格式必须包含时间戳”“错误处理要返回结构化响应”。这些约定分散在仓库各处Agent 不会每次自动读全。OpenRig 提供的解决方式是AGENTS.md文件放在仓库根目录每个 Agent 启动时用--sync模式拉取。我的建议是所有只允许“人”决定、不允许“模型”自由发挥的规定都写进这个文件里。比如# AGENTS.md - 所有新函数必须附带 docstring说明输入输出 - 错误处理统一返回 { error: 消息 } 结构 - 不要修改 tests/ 以外的测试文件 - 改接口前先更新接口文档有了这份文件Agent 至少不会在第一天记住了约定、第三天忘记。我一开始没建这个文件结果 claude-worker 和 codex-worker 各自生成了风格完全不一致的日志格式光统一格式就花了我半天纯属自找麻烦。6.4 坑API 费用失控请求风暴双 Agent 意味着双份 token 消耗如果任务不设上限费用起来真的很快。我第一次跑没有配max_iterations一个 Agent 在一个简单任务上反复重试了四十多轮每轮都在读取大文件看着账单我血压直接上来了。后来我总结了一组保命配置配置项建议值说明max_iterations20-30单任务最大迭代轮数超出就标记失败request_timeout600单轮请求超时时间单位秒parallel_workers2同时跑几个 Agent别贪多burn_rate_limit0.1每秒 API 调用上限防突发风暴dry_runfalse调试阶段可以开只生成计划不执行另外小技巧每一轮迭代之间加cooldown_seconds: 5让两个 Agent 的请求错峰发送。虽然只差几秒但能明显减少 429 rate limit 错误而且两个 Agent 的 token 峰值不会同时顶到上限。省钱这件事本质上靠的是“限制和节奏”不是靠换更便宜的模型。写在最后的一点体会玩了一个多星期的 OpenRig 双 Agent 工作流我最直观的感受是以前写代码像自己下地干活现在更像包工头——只管派活、验收偶尔处理一下工人之间的矛盾。这个转变一开始有点不习惯总觉得不亲手写点什么就不踏实但后来想通了模型能干好的事就该让模型干我留着精力去确认“方向对不对”以及“合入的代码风格是否能长期维护”。如果你也想试别一上来就管理三个以上的 Agent先把一个后端 Agent 和一个前端 Agent 跑顺再把任务卡的粒度慢慢调大。等你有把握说清楚“哪些文件归谁管、什么算完成”的时候你会发现vibecoding 这种看似邪修的玩法其实比很多正统流程都更接近工程的本質。