1. 一次在地铁上完成的架构评审这套组合解决的真实痛点先说一个真实的场景。上个月我人在外出差项目组临时接到一个需求要给现有模块加一个独立的权限校验层。按以前的做法我必须回酒店开电脑、拉起 IDE、把代码过一遍、想清楚改动范围然后才敢动手。但那天我手边只有一部手机项目却在 Antigravity 的云工作区里跑了一整天。我就做了一件事打开手机上的 Antigravity 云控制台切换进 agent 会话给已经在工作区里待命的 Claude Code 发了一条指令——按 README 和入口模块梳理一下当前依赖方向评估加入独立权限校验层的改动面输出一份架构评审报告。二十分钟后评审报告出现在会话里同时保存到了工作区的 docs 目录。我在地铁上读完报告把结论转成任务书交给了同一个工作区里的 Codex 去执行。等我下车代码改完了测试也跑了我只剩下最后一步审 diff、点批准。听起来有点科幻但它不是概念演示。这套流程我稳定跑了两周核心就三个工具Antigravity 作为云工作区和移动端入口Claude Code 负责架构评审Codex 负责秒级编码。三个角色形成一个非常朴素的多智能体协作链。这篇文章就是把我从零搭起来的过程、踩过的坑、以及现在每天在用的协作节奏完整写出来适合想把手头 AI 编码工具从单点命令升级成多人协作式流水线的开发者参考。1.1 我为什么把 Antigravity 当成协作中枢先解释一下 Antigravity 是什么很多朋友可能刚接触。它是 Eden Research 出的 AI 原生 IDE底层是基于 VS Code 的分支但它和普通 IDE 最大的不同是它内置了 agent 运行机制工作区可以放在云上PC 上和移动端 Web 访问的是同一个环境。这直接解决了我一直以来的痒点——桌面开发环境和移动端监控环境之间的割裂。我把它当成协作中枢的原因有三个。第一agent 会话是可持续的。我上午在电脑上起的评审会话下午可以用手机继续聊下去上下文没有断工作区里的文件状态也没有断。第二Antigravity 本身支持接入不同的 agent 后端这意味着我不需要同时开三四个终端窗口只要让 Claude Code 和 Codex 都在同一套工作区里运行它们的产物评审报告、git diff、测试日志都落在同一个文件系统里彼此之间传递信息非常自然。第三手机端虽然不能完全替代电脑写完整个项目但用来读报告、发指令、看运行日志、审批 diff 是完全够用的这种人在回路里、但不需要人守在电脑前的节奏才是多智能体协作的价值所在。1.2 文章里会反复出现的三个角色为了后面读起来不混乱先把三个角色说清楚。第一个是 Antigravity它是工作台负责把云工作区、移动端入口、agent 会话和代码仓库粘在一起。它本身不是一个编码模型而是承载模型的容器。第二是 Claude Code它是 Anthropic 官方的命令行 agent擅长读代码、做推理、生成结构性结论。在整套流程里它承担的是规划者和评审者角色干的是架构评审、任务拆解、代码复审这种需要全局理解的活。第三个是 Codex它是 OpenAI 官方的命令行编码 agent擅长快速写代码、改文件、跑命令。在我的流程里它承担的是执行者角色拿到的是一份已经拆得很细的任务书按步骤完成编码和测试。这套搭配不是随便凑的。我在实际测试里发现让同一个模型既做架构评审又做海量代码落地要么评审深度不够要么执行速度偏慢。把规划和执行拆开反而各自都舒服。后面我详细说为什么。2. 分工设计为什么让 Claude 做架构评审、Codex 做秒级编码很多朋友一听到多智能体协作第一反应就是让两个 AI 互相对话自动把活干完。但实际跑下来你会发现如果两个模型没有明确分工结果就是一锅粥。Claude 和 Codex 各有各的脾气硬要让它们无缝对话反而会因为对代码风格、任务粒度、输出格式的理解不一致而互相污染上下文。所以我做的最重要的一件事不是选工具而是划边界。2.1 各自擅长什么硬凑在一起会怎样先说 Claude Code。它给我最深的印象是长上下文里的全局推理能力。面对一个几百个文件的中型项目它能沿着入口文件一路追到工具函数把模块间的依赖关系梳理成清晰的层次。我在让 Claude Code 做架构评审的时候它会主动指出循环依赖、模块边界模糊、数据流向不明确等问题并且会给出修改建议的优先级。这种先想清楚再动手的能力适合放在流程最前面。Codex 则完全是另一个风格它是典型的快枪手。给它的任务越具体它的执行效率越高。你告诉它把 auth 模块里的 validateToken 拆成独立的函数更新对应的测试文件不要动其他模块它能在几句话之内完成搜索、改写、运行测试这一整套动作产出速度明显比我在终端里手写快。但如果你丢给它一个空泛的任务说重构整个项目的权限体系它就容易陷入自由发挥改出一堆你没预期的内容。所以结论很简单一个做规划一个做执行两者硬要互换角色都会不顺手。之前我试过让 Claude 直接改大量重复性的样板代码速度跟不上也试过让 Codex 先做架构分析它给出的结论太碎缺少全局层次。现在这个分工是我跑了两个项目以后固定下来的。2.2 双模型协作的上下文边界设计分工明确了之后还有一个更隐蔽的问题两个模型之间怎么传递信息才不会出现鸡同鸭讲。我的做法是建立中间产物文档。Claude Code 完成架构评审后不直接口头告诉 Codex 要做什么而是把评审结论落成一份 markdown 文件例如docs/architecture-review.md。这份文件里包含三部分现状分析、问题清单、建议改动方向每一条都精确到模块和函数名。Codex 拿到这份文档作为输入再结合我补充的任务书来执行。任务书里规定得非常死允许改哪些文件、禁止改哪些文件、每条改动完成后要跑哪个测试命令、最终要输出什么格式的摘要。这个设计的本质是把模型之间的直接对话降级成通过文件系统交换结构化信息。好处非常明显不会因为两个模型对会话上下文的理解不一致导致信息丢失每个中间产物都有文件留档出问题可以追溯手机端查看评审报告和任务书非常容易因为都是普通 markdown 文件。2.3 成本与风险的账怎么算凡是引入多个模型的工作流必然要算成本和风险。成本方面我现在的使用量大概是每天 Claude Code 跑一到两次完整评审每次消耗的 token 比较多因为要读全量项目结构Codex 的执行任务也消耗 token但单次任务量小。合计下来比我一个人用 IDE 人工开发翻了两三倍成本但换来的是原本三四天的改造工作在几小时内出结果这笔账我个人认为很划算。风险方面主要集中在两个点第一是 Codex 可能在任务书没说清楚的地方自由发挥所以我要求它在每个步骤完成时运行对应测试一旦测试失败就停下来报告而不是继续硬改第二是 Claude 的评审意见不一定是全对的所以人的审批环节不能少。我所有的实验都保留了手机端审批这一关没有完全自动化到无人值守的程度。3. 环境搭建把 Claude Code 和 Codex 装进 Antigravity 工作区这套组合的搭建门槛其实不高真正的难点在于环境和工具链的兼容性。我把完整步骤写在这按顺序操作基本一遍能过。3.1 环境准备清单Node 版本、CLI 安装、登录首先Antigravity 云工作区基于 VS Code 内核实际上是一个 Linux 容器环境所以我建议直接在云工作区的终端里安装所有 CLI 工具而不是在本地 Windows 上装。云工作区的好处是环境干净不会带一堆本机历史残留。进入 Antigravity 云控制台新建一个 workspace选一个带 Node.js 的镜像至少 Node 18 以上。然后在云工作区的终端里执行两条安装命令npm install -g anthropic-ai/claude-code npm install -g openai/codex安装完成后分别验证版本claude --version codex --version登录环节有个细节Claude Code 需要通过 Anthropic 官方账号授权Codex 需要登录 OpenAI 账号或配置 API Key。终端里会输出登录链接在浏览器里完成授权后回到终端CLI 会写入本地凭证。这个过程每个工具只需要做一次之后在同一个工作区里会长期有效。3.2 Windows 上最常见的启动失败虚拟机平台功能未开启如果你是想在本地 Windows 上用 Claude Code Desktop 或 Claude Workspace而不是用云工作区那大概率会遇到一个卡壳点启动时提示 Claude 的工作区无法启动错误信息里能看到failed to start claudes workspace、RPC error、SDK version之类的字样。这个问题的根因通常是 Windows 的虚拟机平台功能没有开启。Claude 的本地工作区依赖 Windows 的虚拟化组件来隔离运行环境而新版 Windows 默认并不一定打开了这个功能。解决办法是打开 PowerShell管理员模式执行dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart然后重启系统。如果提示已经开启就检查一下 WSL 内核版本或确认 Windows 版本是否低于对方的 SDK 要求。这里我的建议是能走云工作区就走云工作区省掉本机虚拟化的所有麻烦这也是我为什么把整套流程都放在 Antigravity 云端的原因。3.3 Codex 账号与模型兼容性的坑Codex 配置好之后最容易遇到的问题不是装不上而是模型不兼容。例如在 ChatGPT 账号下使用 Codex 时如果你在配置里手动指定了gpt-5.6-sol这类不存在的或当前账号不可用的模型名终端会直接报错the gpt-5.6-sol model is not supported when using codex with a chatgpt account。这个报错其实是善意提醒Codex 通过 ChatGPT 账号登录时模型选项是受订阅级别限制的你只能使用官方支持列表里的模型不能随便填模型名。处理方式也很简单执行codex进入交互界面选择它列出的可用模型或者在命令行参数里明确指定一个支持的模型名。如果你需要特定的新模型能力建议通过 API 方式单独配置而不是硬怼到 ChatGPT 账号体系里。3.4 Antigravity 登录和工作区创建的注意点最后说 Antigravity 本身的登录。如果你在登录时卡住最常见的原因是账号凭证过期或者是云控制台里的工作区状态异常。我的处理顺序是先确认账号能正常打开官方控制台再回到工作区列表里看目标 workspace 的状态如果显示异常就点击停止并重新启动。移动端登录不上的时候先清一次会话缓存再重试大部分情况下都能解决不需要动工作区里的任何代码。另外手机端访问的方式是直接打开官方云的 Web 控制台不需要安装额外的 App也不需要在手机上再去配一遍 CLI。手机端和 PC 端访问的是同一个工作区所以环境只在电脑或云端配一次就行。4. 联动工作流架构评审到编码执行的完整链路环境配好之后真正的核心是工作流怎么设计。我现在的流程固定为四个阶段每个阶段有明确的输入输出和验收标准。下面按顺序展开。4.1 阶段一Claude Code 产出架构评审报告第一步是在云工作区里进入项目根目录启动 Claude Code然后发一个结构化的评审指令。我常用的 prompt 模板如下claude 请读取这个项目的 README、入口文件、核心模块和测试结构按以下维度输出架构评审 1. 当前分层是否清晰是否存在循环依赖 2. 核心数据流和状态管理是否存在缺陷 3. 关键接口抽象是否合理是否需要拆分或合并 4. 如果我要新增独立权限校验层改动会波及哪些模块 5. 每个问题标注严重级别P0/P1/P2和改动建议 报告保存到 docs/architecture-review.mdClaude Code 会进入 agent 模式自己翻代码、读文件、分析依赖最后生成报告。这个过程视项目大小需要几分钟到二十分钟不等。期间我完全不用盯着它它会实时打印正在阅读的文件和思考过程日志在手机端也能看到。评审报告保存为 markdown 文件是关键一步这保证了后续 Codex 拿到的不是一句模糊的按照 Claude 说的改而是一份结构化的依据文档。4.2 阶段二手机端审阅并生成任务书评审报告生成后我在地铁上或休息时打开手机切进 Antigravity 云控制台在文件树里直接打开docs/architecture-review.md阅读。报告里 P0 和 P1 级别的问题是重点P2 可以放到后续迭代。看完报告后我要做的是把报告转成任务书。这一步不建议让 Claude 或者 Codex 自动生成原因是任务书决定了后续 Codex 的执行边界必须经过人确认。我通常会在评审报告文件下方追加一个章节写成类似这样的任务清单## 执行任务书手机端审批后生效 1. 在 src/auth/ 下新建 permissionGuard.ts实现 checkPermission 函数签名参照 src/types/permission.ts 2. 修改 src/router/index.ts在路由跳转前调用 checkPermission 3. 禁止改动 src/models/ 下的任何文件 4. 每完成一个步骤运行 npm run test:unit -- --run path/to/test 5. 最终输出变更摘要列出改动的文件和新增测试这里的关键是禁止改动哪些文件一定要写清楚否则 Codex 有可能会顺手把不该动的文件也改了。审批后这份任务书就作为 Codex 的执行输入。4.3 阶段三Codex 依据任务书执行编码在同一个工作区里启动 Codex让它以这份任务书为唯一依据执行。Codex 支持非交互式的 exec 模式我用的命令大致是这样codex exec $(cat docs/architecture-review.md)或者只让它执行任务书部分codex exec 请严格按照 docs/architecture-review.md 中【执行任务书】章节执行。如果没有明确禁止的文件不要改动。每一步完成后运行对应测试并输出摘要。Codex 会自己读任务书、找文件、改代码、跑测试。它的速度确实配得上秒级编码这个说法单个任务通常几十秒到几分钟就会完成。期间它会把每一步动作输出到终端日志同样可以在手机端实时看到。这里有一个非常重要的经验任务粒度决定了成功率。Codex 适合执行任务书里的单条或两三条任务不适合一口气执行超过十条的大任务。任务一多它的上下文容易混乱步骤长了之后中间某步出错后面的步骤也会连带出问题。所以我现在习惯把任务书拆成执行批次先让 Codex 完成第一批 3 条等它跑完并输出摘要再让它继续第二批。这个节奏在手机端操作完全可行因为每批之间我只需要扫一眼摘要然后回复继续。4.4 阶段四Claude 复审 diff 并收敛冲突编码执行完之后不能直接提交必须有一个复审环节。我让 Claude Code 切到工作区对比评审报告和 git diff逐条核对 Codex 的改动是否真的落实了评审意见有没有引入新的问题。常用的复审 prompt 模板claude 请对比 docs/architecture-review.md 中的建议和当前 git diff逐条核对 1. 哪些评审意见已落实哪些未落实 2. Codex 的改动是否引入了新的循环依赖、类型错误或安全问题 3. 是否有任务书禁止改动却被改动的文件 4. 输出复审报告 docs/codex-review.md并给出提交建议Claude 复审完我再看一遍复审报告决定是合并提交还是让 Codex 返工。这个流程看起来多了一道工序实际上避免了很多低级 bug因为 Codex 的测试虽然通过了但测试覆盖不到的场景反而更容易被 Claude 这种全局视角发现。5. 手机端掌控实战哪些操作适合在手机上做哪些不行整套流程脱离电脑之后手机端到底能做什么、不能做什么我用一周时间摸清了边界。这里直接给结论。5.1 手机端的真实界面与操作边界Antigravity 的云控制台在手机浏览器里的体验和桌面端类似但受屏幕尺寸限制不能指望拿手机写大段代码。它能稳定支持的操作为查看文件内容、阅读 markdown 报告、发送 agent 指令、查看终端滚动日志、查看 git diff 摘要。它不太适合的操作是在复杂文件里定位代码、写长 prompt、处理大量文件冲突、长时间阅读终端日志。这其实就够了。我的定位是手机端做决策不做编辑。所有批量编辑任务都交给 Codex 在后台完成手机上只做读和批。5.2 我把掌控拆成四个动作读报告、下指令、看日志、批 diff第一个动作是读报告。Claude Code 生成的评审报告和复审报告都是 markdown手机上打开文件树直接点击就能看排版清爽。第二个动作是下指令。在 agent 会话里输入新指令例如回复按任务书第二批继续执行。这个动作不需要敲很多字会话会保留上下文所以手机上操作很轻松。第三个动作是看日志。Codex 执行过程中会输出大量动作日志手机上看起来可能有点吃力。我的经验是只看关键节点每个任务开始时有没有正确读取文件路径、测试命令有没有跑起来、最终摘要有没有生成。第四个动作是批 diff。Codex 跑完后会产生 git diffAntigravity 云控制台里能查看变更文件列表和逐行 diff。手机屏幕上逐行看 diff 确实费眼但看整体变更范围、确认没有动到禁止改动的目录这些完全够用。确认没问题后我在会话里发送合并并提交的指令即可。5.3 长时间离屏运行前要做的事如果你准备让 Claude 和 Codex 在后台跑一两个小时自己先去开会或通勤建议提前做好三件事一是确认工作区会话不会被超时回收云 IDE 通常有会话保活机制但长时间无操作可能被自动挂起二是把任务书和评审报告保存在项目内确保即使会话重新拉起agent 也能从文件里读取上下文三是给 Codex 设定一个测试失败就停止并报告的规则避免它一个人闷头改到底、越改越偏。这三点我在实际使用中都有切肤之痛尤其是第一条一旦会话被回收前面半天的评审结果虽然文件还在但会话里的临时状态会丢失还得重新起会话。6. 高频报错排查记录我在联动时踩过的坑工具链越复杂报错越五花八门。把这段时间遇到的高频问题整理成清单每个都给出排查链路。6.1 Claude Workspace 无法启动RPC 错误与 SDK 版本提示现象本地启动 Claude 桌面端时终端或工具窗提示failed to start claudes workspace有时还跟着RPC error -1或SDK version 2.1.260之类的细节。排查链路先看是否 Windows 虚拟机平台未启用这个原因占比最高再确认系统版本与 Claude 桌面端要求的 SDK 版本差距版本太旧也可能触发 RPC 失败最后检查工作区目录是否在云同步盘里比如挂在一网盘目录下会让 RPC 初始化异常。我的最终选择是放弃本地工作区全部搬到云端这个问题直接消失。6.2 Codex 上下文溢出任务做到一半说没地方了现象Codex 执行到一半终端出现error running remote compact task: codex ran out of room in the models context。这个报错的意思是模型上下文窗口满了Codex 尝试自动压缩历史但压缩也失败了。发生原因是任务书太长或前几次执行产生了大量日志把上下文堆满了。处理方式分三步先让 Codex 停止当前任务导出已完成部分的变更摘要保存到文档里再新开一个 Codex 会话把摘要和剩余任务书作为新上下文喂进去最后把剩余任务再拆小一点一次只做一两条。现在我在任务书设计时会有意识地控制单批次任务量这个报错基本不再出现。6.3 模型不支持ChatGPT 账号下被拒绝的模型名现象执行 Codex 时终端提示the gpt-5.6-sol model is not supported when using codex with a chatgpt account。排查链路非常简单先确认自己是不是在 ChatGPT 登录方式下手动指定了模型名如果是改成默认模型即可。默认的模型选择逻辑会匹配当前账号可用的模型列表不需要手动指定。如果确实想用更强大的新模型建议改用 API Key 方式并查官方文档确认模型白名单。6.4 Codex 本地端点对接失败agent 之间服务没通现象在想让 Claude Code 直接调度 Codex 时终端会报出一段错误大意是cc switch在处理 Codex 的本地端点.../responses时失败提示本地服务不可用。这个问题的本质是本地服务通信没有建立起来。Claude Code 试图通过本地端口访问 Codex 提供的服务但 Codex 进程没有正常启动或监听端口被占用。排查链路先单独启动一个 Codex 会话确认它本身能正常工作再检查是否有其他进程占用了该端口最后确认两个 CLI 的版本兼容性新版本接口路径变化可能导致旧版cc switch调不到。我的经验是不要依赖 Claude Code 直接调度 Codex而是通过工作区里的任务书文件间接联动两者保持独立进程可靠性高得多。6.5 Antigravity 登录不了凭证与工作区状态的处理顺序现象电脑或手机登录 Antigravity 云控制台时一直转圈或者提示会话失效。排查顺序第一步确认账号订阅和服务状态是否正常官方状态页有没有大面积故障第二步清理浏览器或移动端的登录缓存重新走一次授权第三步检查目标 workspace 是否处于异常状态异常就从控制台里强制停止再启动。这三个步骤按顺序走九成问题都能解决。如果还不行把错误信息里带的时间戳和工作区 ID 保存下来提工单时非常有用。7. 目前我在用的协作节奏与最终建议完整理解这套工作流之后最后分享一些实际操作中的节奏控制经验帮助你在自己项目里少走弯路。我把一天的工作切成三个大块。早上在电脑上起一个 Claude Code 评审会话让它处理最复杂的架构问题这段时间我做别的需求梳理。中午随手手机看一眼报告确认范围后拆任务书。下午让 Codex 分批次执行每跑完一批就刷一眼摘要下班前让 Claude 做一轮复审收尾提交。整个流程下来我是一个审批者不是一个编码员但项目的质量反而比我自己埋头写更高因为每一行改动都被至少一个评审视角看过。关于任务拆分我的原则是架构评审可以给大范围编码任务必须小步快跑。Codex 最稳定的表现是改两个文件、跑一次测试、输出摘要这种粒度超过五个文件的批改量成功率直线下降。任务书里不准动什么比要做什么更重要这条规则建议你宁可多写一点。关于双模型之间的信任边界我给 Claude 和 Codex 都保留了随时喊停的能力。任何一方只要发现上下文异常、任务偏离范围或者测试失败都会停下来写摘要而不是继续往下猜。停止本身不丢人停下来之后由人重新调整任务书再继续这个流程让整个系统保持了非常强的可控性。我最后想说的一点是这套东西一点也不玄乎。多智能体协作听起来像学术概念实际落地就是一个朴素的工程流程一个 agent 规划一个 agent 执行文件系统是它们之间的工单系统手机是工单系统的审批终端。我现在的开发速度大概是我一个人背电脑时的三倍最关键的是我在高铁上、咖啡馆里、任何只有手机的场合都能随时掌控项目进度。希望这篇文章能帮你也搭出这样一套顺手的工作流。
1. 一次在地铁上完成的架构评审这套组合解决的真实痛点先说一个真实的场景。上个月我人在外出差项目组临时接到一个需求要给现有模块加一个独立的权限校验层。按以前的做法我必须回酒店开电脑、拉起 IDE、把代码过一遍、想清楚改动范围然后才敢动手。但那天我手边只有一部手机项目却在 Antigravity 的云工作区里跑了一整天。我就做了一件事打开手机上的 Antigravity 云控制台切换进 agent 会话给已经在工作区里待命的 Claude Code 发了一条指令——按 README 和入口模块梳理一下当前依赖方向评估加入独立权限校验层的改动面输出一份架构评审报告。二十分钟后评审报告出现在会话里同时保存到了工作区的 docs 目录。我在地铁上读完报告把结论转成任务书交给了同一个工作区里的 Codex 去执行。等我下车代码改完了测试也跑了我只剩下最后一步审 diff、点批准。听起来有点科幻但它不是概念演示。这套流程我稳定跑了两周核心就三个工具Antigravity 作为云工作区和移动端入口Claude Code 负责架构评审Codex 负责秒级编码。三个角色形成一个非常朴素的多智能体协作链。这篇文章就是把我从零搭起来的过程、踩过的坑、以及现在每天在用的协作节奏完整写出来适合想把手头 AI 编码工具从单点命令升级成多人协作式流水线的开发者参考。1.1 我为什么把 Antigravity 当成协作中枢先解释一下 Antigravity 是什么很多朋友可能刚接触。它是 Eden Research 出的 AI 原生 IDE底层是基于 VS Code 的分支但它和普通 IDE 最大的不同是它内置了 agent 运行机制工作区可以放在云上PC 上和移动端 Web 访问的是同一个环境。这直接解决了我一直以来的痒点——桌面开发环境和移动端监控环境之间的割裂。我把它当成协作中枢的原因有三个。第一agent 会话是可持续的。我上午在电脑上起的评审会话下午可以用手机继续聊下去上下文没有断工作区里的文件状态也没有断。第二Antigravity 本身支持接入不同的 agent 后端这意味着我不需要同时开三四个终端窗口只要让 Claude Code 和 Codex 都在同一套工作区里运行它们的产物评审报告、git diff、测试日志都落在同一个文件系统里彼此之间传递信息非常自然。第三手机端虽然不能完全替代电脑写完整个项目但用来读报告、发指令、看运行日志、审批 diff 是完全够用的这种人在回路里、但不需要人守在电脑前的节奏才是多智能体协作的价值所在。1.2 文章里会反复出现的三个角色为了后面读起来不混乱先把三个角色说清楚。第一个是 Antigravity它是工作台负责把云工作区、移动端入口、agent 会话和代码仓库粘在一起。它本身不是一个编码模型而是承载模型的容器。第二是 Claude Code它是 Anthropic 官方的命令行 agent擅长读代码、做推理、生成结构性结论。在整套流程里它承担的是规划者和评审者角色干的是架构评审、任务拆解、代码复审这种需要全局理解的活。第三个是 Codex它是 OpenAI 官方的命令行编码 agent擅长快速写代码、改文件、跑命令。在我的流程里它承担的是执行者角色拿到的是一份已经拆得很细的任务书按步骤完成编码和测试。这套搭配不是随便凑的。我在实际测试里发现让同一个模型既做架构评审又做海量代码落地要么评审深度不够要么执行速度偏慢。把规划和执行拆开反而各自都舒服。后面我详细说为什么。2. 分工设计为什么让 Claude 做架构评审、Codex 做秒级编码很多朋友一听到多智能体协作第一反应就是让两个 AI 互相对话自动把活干完。但实际跑下来你会发现如果两个模型没有明确分工结果就是一锅粥。Claude 和 Codex 各有各的脾气硬要让它们无缝对话反而会因为对代码风格、任务粒度、输出格式的理解不一致而互相污染上下文。所以我做的最重要的一件事不是选工具而是划边界。2.1 各自擅长什么硬凑在一起会怎样先说 Claude Code。它给我最深的印象是长上下文里的全局推理能力。面对一个几百个文件的中型项目它能沿着入口文件一路追到工具函数把模块间的依赖关系梳理成清晰的层次。我在让 Claude Code 做架构评审的时候它会主动指出循环依赖、模块边界模糊、数据流向不明确等问题并且会给出修改建议的优先级。这种先想清楚再动手的能力适合放在流程最前面。Codex 则完全是另一个风格它是典型的快枪手。给它的任务越具体它的执行效率越高。你告诉它把 auth 模块里的 validateToken 拆成独立的函数更新对应的测试文件不要动其他模块它能在几句话之内完成搜索、改写、运行测试这一整套动作产出速度明显比我在终端里手写快。但如果你丢给它一个空泛的任务说重构整个项目的权限体系它就容易陷入自由发挥改出一堆你没预期的内容。所以结论很简单一个做规划一个做执行两者硬要互换角色都会不顺手。之前我试过让 Claude 直接改大量重复性的样板代码速度跟不上也试过让 Codex 先做架构分析它给出的结论太碎缺少全局层次。现在这个分工是我跑了两个项目以后固定下来的。2.2 双模型协作的上下文边界设计分工明确了之后还有一个更隐蔽的问题两个模型之间怎么传递信息才不会出现鸡同鸭讲。我的做法是建立中间产物文档。Claude Code 完成架构评审后不直接口头告诉 Codex 要做什么而是把评审结论落成一份 markdown 文件例如docs/architecture-review.md。这份文件里包含三部分现状分析、问题清单、建议改动方向每一条都精确到模块和函数名。Codex 拿到这份文档作为输入再结合我补充的任务书来执行。任务书里规定得非常死允许改哪些文件、禁止改哪些文件、每条改动完成后要跑哪个测试命令、最终要输出什么格式的摘要。这个设计的本质是把模型之间的直接对话降级成通过文件系统交换结构化信息。好处非常明显不会因为两个模型对会话上下文的理解不一致导致信息丢失每个中间产物都有文件留档出问题可以追溯手机端查看评审报告和任务书非常容易因为都是普通 markdown 文件。2.3 成本与风险的账怎么算凡是引入多个模型的工作流必然要算成本和风险。成本方面我现在的使用量大概是每天 Claude Code 跑一到两次完整评审每次消耗的 token 比较多因为要读全量项目结构Codex 的执行任务也消耗 token但单次任务量小。合计下来比我一个人用 IDE 人工开发翻了两三倍成本但换来的是原本三四天的改造工作在几小时内出结果这笔账我个人认为很划算。风险方面主要集中在两个点第一是 Codex 可能在任务书没说清楚的地方自由发挥所以我要求它在每个步骤完成时运行对应测试一旦测试失败就停下来报告而不是继续硬改第二是 Claude 的评审意见不一定是全对的所以人的审批环节不能少。我所有的实验都保留了手机端审批这一关没有完全自动化到无人值守的程度。3. 环境搭建把 Claude Code 和 Codex 装进 Antigravity 工作区这套组合的搭建门槛其实不高真正的难点在于环境和工具链的兼容性。我把完整步骤写在这按顺序操作基本一遍能过。3.1 环境准备清单Node 版本、CLI 安装、登录首先Antigravity 云工作区基于 VS Code 内核实际上是一个 Linux 容器环境所以我建议直接在云工作区的终端里安装所有 CLI 工具而不是在本地 Windows 上装。云工作区的好处是环境干净不会带一堆本机历史残留。进入 Antigravity 云控制台新建一个 workspace选一个带 Node.js 的镜像至少 Node 18 以上。然后在云工作区的终端里执行两条安装命令npm install -g anthropic-ai/claude-code npm install -g openai/codex安装完成后分别验证版本claude --version codex --version登录环节有个细节Claude Code 需要通过 Anthropic 官方账号授权Codex 需要登录 OpenAI 账号或配置 API Key。终端里会输出登录链接在浏览器里完成授权后回到终端CLI 会写入本地凭证。这个过程每个工具只需要做一次之后在同一个工作区里会长期有效。3.2 Windows 上最常见的启动失败虚拟机平台功能未开启如果你是想在本地 Windows 上用 Claude Code Desktop 或 Claude Workspace而不是用云工作区那大概率会遇到一个卡壳点启动时提示 Claude 的工作区无法启动错误信息里能看到failed to start claudes workspace、RPC error、SDK version之类的字样。这个问题的根因通常是 Windows 的虚拟机平台功能没有开启。Claude 的本地工作区依赖 Windows 的虚拟化组件来隔离运行环境而新版 Windows 默认并不一定打开了这个功能。解决办法是打开 PowerShell管理员模式执行dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart然后重启系统。如果提示已经开启就检查一下 WSL 内核版本或确认 Windows 版本是否低于对方的 SDK 要求。这里我的建议是能走云工作区就走云工作区省掉本机虚拟化的所有麻烦这也是我为什么把整套流程都放在 Antigravity 云端的原因。3.3 Codex 账号与模型兼容性的坑Codex 配置好之后最容易遇到的问题不是装不上而是模型不兼容。例如在 ChatGPT 账号下使用 Codex 时如果你在配置里手动指定了gpt-5.6-sol这类不存在的或当前账号不可用的模型名终端会直接报错the gpt-5.6-sol model is not supported when using codex with a chatgpt account。这个报错其实是善意提醒Codex 通过 ChatGPT 账号登录时模型选项是受订阅级别限制的你只能使用官方支持列表里的模型不能随便填模型名。处理方式也很简单执行codex进入交互界面选择它列出的可用模型或者在命令行参数里明确指定一个支持的模型名。如果你需要特定的新模型能力建议通过 API 方式单独配置而不是硬怼到 ChatGPT 账号体系里。3.4 Antigravity 登录和工作区创建的注意点最后说 Antigravity 本身的登录。如果你在登录时卡住最常见的原因是账号凭证过期或者是云控制台里的工作区状态异常。我的处理顺序是先确认账号能正常打开官方控制台再回到工作区列表里看目标 workspace 的状态如果显示异常就点击停止并重新启动。移动端登录不上的时候先清一次会话缓存再重试大部分情况下都能解决不需要动工作区里的任何代码。另外手机端访问的方式是直接打开官方云的 Web 控制台不需要安装额外的 App也不需要在手机上再去配一遍 CLI。手机端和 PC 端访问的是同一个工作区所以环境只在电脑或云端配一次就行。4. 联动工作流架构评审到编码执行的完整链路环境配好之后真正的核心是工作流怎么设计。我现在的流程固定为四个阶段每个阶段有明确的输入输出和验收标准。下面按顺序展开。4.1 阶段一Claude Code 产出架构评审报告第一步是在云工作区里进入项目根目录启动 Claude Code然后发一个结构化的评审指令。我常用的 prompt 模板如下claude 请读取这个项目的 README、入口文件、核心模块和测试结构按以下维度输出架构评审 1. 当前分层是否清晰是否存在循环依赖 2. 核心数据流和状态管理是否存在缺陷 3. 关键接口抽象是否合理是否需要拆分或合并 4. 如果我要新增独立权限校验层改动会波及哪些模块 5. 每个问题标注严重级别P0/P1/P2和改动建议 报告保存到 docs/architecture-review.mdClaude Code 会进入 agent 模式自己翻代码、读文件、分析依赖最后生成报告。这个过程视项目大小需要几分钟到二十分钟不等。期间我完全不用盯着它它会实时打印正在阅读的文件和思考过程日志在手机端也能看到。评审报告保存为 markdown 文件是关键一步这保证了后续 Codex 拿到的不是一句模糊的按照 Claude 说的改而是一份结构化的依据文档。4.2 阶段二手机端审阅并生成任务书评审报告生成后我在地铁上或休息时打开手机切进 Antigravity 云控制台在文件树里直接打开docs/architecture-review.md阅读。报告里 P0 和 P1 级别的问题是重点P2 可以放到后续迭代。看完报告后我要做的是把报告转成任务书。这一步不建议让 Claude 或者 Codex 自动生成原因是任务书决定了后续 Codex 的执行边界必须经过人确认。我通常会在评审报告文件下方追加一个章节写成类似这样的任务清单## 执行任务书手机端审批后生效 1. 在 src/auth/ 下新建 permissionGuard.ts实现 checkPermission 函数签名参照 src/types/permission.ts 2. 修改 src/router/index.ts在路由跳转前调用 checkPermission 3. 禁止改动 src/models/ 下的任何文件 4. 每完成一个步骤运行 npm run test:unit -- --run path/to/test 5. 最终输出变更摘要列出改动的文件和新增测试这里的关键是禁止改动哪些文件一定要写清楚否则 Codex 有可能会顺手把不该动的文件也改了。审批后这份任务书就作为 Codex 的执行输入。4.3 阶段三Codex 依据任务书执行编码在同一个工作区里启动 Codex让它以这份任务书为唯一依据执行。Codex 支持非交互式的 exec 模式我用的命令大致是这样codex exec $(cat docs/architecture-review.md)或者只让它执行任务书部分codex exec 请严格按照 docs/architecture-review.md 中【执行任务书】章节执行。如果没有明确禁止的文件不要改动。每一步完成后运行对应测试并输出摘要。Codex 会自己读任务书、找文件、改代码、跑测试。它的速度确实配得上秒级编码这个说法单个任务通常几十秒到几分钟就会完成。期间它会把每一步动作输出到终端日志同样可以在手机端实时看到。这里有一个非常重要的经验任务粒度决定了成功率。Codex 适合执行任务书里的单条或两三条任务不适合一口气执行超过十条的大任务。任务一多它的上下文容易混乱步骤长了之后中间某步出错后面的步骤也会连带出问题。所以我现在习惯把任务书拆成执行批次先让 Codex 完成第一批 3 条等它跑完并输出摘要再让它继续第二批。这个节奏在手机端操作完全可行因为每批之间我只需要扫一眼摘要然后回复继续。4.4 阶段四Claude 复审 diff 并收敛冲突编码执行完之后不能直接提交必须有一个复审环节。我让 Claude Code 切到工作区对比评审报告和 git diff逐条核对 Codex 的改动是否真的落实了评审意见有没有引入新的问题。常用的复审 prompt 模板claude 请对比 docs/architecture-review.md 中的建议和当前 git diff逐条核对 1. 哪些评审意见已落实哪些未落实 2. Codex 的改动是否引入了新的循环依赖、类型错误或安全问题 3. 是否有任务书禁止改动却被改动的文件 4. 输出复审报告 docs/codex-review.md并给出提交建议Claude 复审完我再看一遍复审报告决定是合并提交还是让 Codex 返工。这个流程看起来多了一道工序实际上避免了很多低级 bug因为 Codex 的测试虽然通过了但测试覆盖不到的场景反而更容易被 Claude 这种全局视角发现。5. 手机端掌控实战哪些操作适合在手机上做哪些不行整套流程脱离电脑之后手机端到底能做什么、不能做什么我用一周时间摸清了边界。这里直接给结论。5.1 手机端的真实界面与操作边界Antigravity 的云控制台在手机浏览器里的体验和桌面端类似但受屏幕尺寸限制不能指望拿手机写大段代码。它能稳定支持的操作为查看文件内容、阅读 markdown 报告、发送 agent 指令、查看终端滚动日志、查看 git diff 摘要。它不太适合的操作是在复杂文件里定位代码、写长 prompt、处理大量文件冲突、长时间阅读终端日志。这其实就够了。我的定位是手机端做决策不做编辑。所有批量编辑任务都交给 Codex 在后台完成手机上只做读和批。5.2 我把掌控拆成四个动作读报告、下指令、看日志、批 diff第一个动作是读报告。Claude Code 生成的评审报告和复审报告都是 markdown手机上打开文件树直接点击就能看排版清爽。第二个动作是下指令。在 agent 会话里输入新指令例如回复按任务书第二批继续执行。这个动作不需要敲很多字会话会保留上下文所以手机上操作很轻松。第三个动作是看日志。Codex 执行过程中会输出大量动作日志手机上看起来可能有点吃力。我的经验是只看关键节点每个任务开始时有没有正确读取文件路径、测试命令有没有跑起来、最终摘要有没有生成。第四个动作是批 diff。Codex 跑完后会产生 git diffAntigravity 云控制台里能查看变更文件列表和逐行 diff。手机屏幕上逐行看 diff 确实费眼但看整体变更范围、确认没有动到禁止改动的目录这些完全够用。确认没问题后我在会话里发送合并并提交的指令即可。5.3 长时间离屏运行前要做的事如果你准备让 Claude 和 Codex 在后台跑一两个小时自己先去开会或通勤建议提前做好三件事一是确认工作区会话不会被超时回收云 IDE 通常有会话保活机制但长时间无操作可能被自动挂起二是把任务书和评审报告保存在项目内确保即使会话重新拉起agent 也能从文件里读取上下文三是给 Codex 设定一个测试失败就停止并报告的规则避免它一个人闷头改到底、越改越偏。这三点我在实际使用中都有切肤之痛尤其是第一条一旦会话被回收前面半天的评审结果虽然文件还在但会话里的临时状态会丢失还得重新起会话。6. 高频报错排查记录我在联动时踩过的坑工具链越复杂报错越五花八门。把这段时间遇到的高频问题整理成清单每个都给出排查链路。6.1 Claude Workspace 无法启动RPC 错误与 SDK 版本提示现象本地启动 Claude 桌面端时终端或工具窗提示failed to start claudes workspace有时还跟着RPC error -1或SDK version 2.1.260之类的细节。排查链路先看是否 Windows 虚拟机平台未启用这个原因占比最高再确认系统版本与 Claude 桌面端要求的 SDK 版本差距版本太旧也可能触发 RPC 失败最后检查工作区目录是否在云同步盘里比如挂在一网盘目录下会让 RPC 初始化异常。我的最终选择是放弃本地工作区全部搬到云端这个问题直接消失。6.2 Codex 上下文溢出任务做到一半说没地方了现象Codex 执行到一半终端出现error running remote compact task: codex ran out of room in the models context。这个报错的意思是模型上下文窗口满了Codex 尝试自动压缩历史但压缩也失败了。发生原因是任务书太长或前几次执行产生了大量日志把上下文堆满了。处理方式分三步先让 Codex 停止当前任务导出已完成部分的变更摘要保存到文档里再新开一个 Codex 会话把摘要和剩余任务书作为新上下文喂进去最后把剩余任务再拆小一点一次只做一两条。现在我在任务书设计时会有意识地控制单批次任务量这个报错基本不再出现。6.3 模型不支持ChatGPT 账号下被拒绝的模型名现象执行 Codex 时终端提示the gpt-5.6-sol model is not supported when using codex with a chatgpt account。排查链路非常简单先确认自己是不是在 ChatGPT 登录方式下手动指定了模型名如果是改成默认模型即可。默认的模型选择逻辑会匹配当前账号可用的模型列表不需要手动指定。如果确实想用更强大的新模型建议改用 API Key 方式并查官方文档确认模型白名单。6.4 Codex 本地端点对接失败agent 之间服务没通现象在想让 Claude Code 直接调度 Codex 时终端会报出一段错误大意是cc switch在处理 Codex 的本地端点.../responses时失败提示本地服务不可用。这个问题的本质是本地服务通信没有建立起来。Claude Code 试图通过本地端口访问 Codex 提供的服务但 Codex 进程没有正常启动或监听端口被占用。排查链路先单独启动一个 Codex 会话确认它本身能正常工作再检查是否有其他进程占用了该端口最后确认两个 CLI 的版本兼容性新版本接口路径变化可能导致旧版cc switch调不到。我的经验是不要依赖 Claude Code 直接调度 Codex而是通过工作区里的任务书文件间接联动两者保持独立进程可靠性高得多。6.5 Antigravity 登录不了凭证与工作区状态的处理顺序现象电脑或手机登录 Antigravity 云控制台时一直转圈或者提示会话失效。排查顺序第一步确认账号订阅和服务状态是否正常官方状态页有没有大面积故障第二步清理浏览器或移动端的登录缓存重新走一次授权第三步检查目标 workspace 是否处于异常状态异常就从控制台里强制停止再启动。这三个步骤按顺序走九成问题都能解决。如果还不行把错误信息里带的时间戳和工作区 ID 保存下来提工单时非常有用。7. 目前我在用的协作节奏与最终建议完整理解这套工作流之后最后分享一些实际操作中的节奏控制经验帮助你在自己项目里少走弯路。我把一天的工作切成三个大块。早上在电脑上起一个 Claude Code 评审会话让它处理最复杂的架构问题这段时间我做别的需求梳理。中午随手手机看一眼报告确认范围后拆任务书。下午让 Codex 分批次执行每跑完一批就刷一眼摘要下班前让 Claude 做一轮复审收尾提交。整个流程下来我是一个审批者不是一个编码员但项目的质量反而比我自己埋头写更高因为每一行改动都被至少一个评审视角看过。关于任务拆分我的原则是架构评审可以给大范围编码任务必须小步快跑。Codex 最稳定的表现是改两个文件、跑一次测试、输出摘要这种粒度超过五个文件的批改量成功率直线下降。任务书里不准动什么比要做什么更重要这条规则建议你宁可多写一点。关于双模型之间的信任边界我给 Claude 和 Codex 都保留了随时喊停的能力。任何一方只要发现上下文异常、任务偏离范围或者测试失败都会停下来写摘要而不是继续往下猜。停止本身不丢人停下来之后由人重新调整任务书再继续这个流程让整个系统保持了非常强的可控性。我最后想说的一点是这套东西一点也不玄乎。多智能体协作听起来像学术概念实际落地就是一个朴素的工程流程一个 agent 规划一个 agent 执行文件系统是它们之间的工单系统手机是工单系统的审批终端。我现在的开发速度大概是我一个人背电脑时的三倍最关键的是我在高铁上、咖啡馆里、任何只有手机的场合都能随时掌控项目进度。希望这篇文章能帮你也搭出这样一套顺手的工作流。
