最近我把自己的 AI 编码工作流彻底重排了一遍。主力环境换成了 Antigravity 这款面向多智能体协作的 IDE同时在项目里挂上 Claude Code 负责架构评审、Codex 负责快速编码三个角色各干各的活我大部分时间只做裁决和验收——而且这个验收动作现在在手机上就能完成。这套多智能体协作模式我实际跑了两三周期间踩了不少坑也摸索出一套相对稳定的流程。今天这篇就把从安装配置、角色分工、日常操作到问题排查的完整过程写出来想上手的人可以直接照着抄。这套方案解决的是一个很现实的问题单一智能体在复杂项目里总是顾此失彼。让一个 Agent 既做深度的架构思考、又做高频的代码产出往往要么思考过重导致迟迟不动手要么动手太快缺乏全局把控。把“评审”和“编码”拆给两个擅长各自方向的智能体再通过 Antigravity 做统一调度整体效率和体验完全不一样。适合正在用或准备用 Claude Code、Codex 做日常开发的人尤其是经常需要在非工位环境下跟进研发进度的朋友。1. 为什么我把研发工作拆成“评审”和“编码”两件事先说一个我踩过的坑。最开始我也像大多数人一样拿到需求就丢给同一个编码 Agent让它“先想清楚再写”。结果要不就是它想得太多光给方案不动手我在旁边干着急要不就是想得不够埋头写了一堆代码回头一看结构全错了返工成本比人写还高。后来我意识到问题不在 Agent 不够聪明而是我把两种性质完全不同的任务塞给了同一个执行通道。架构评审这件事本质上是“慢思考”。它需要长时间上下文、需要充分理解既有代码的结构和意图、需要对改动影响面做推演。这类任务对延迟不敏感但对推理深度和上下文长度要求极高。而编码执行这件事本质上是“快执行”。它需要在明确的约束下快速产出代码、快速跑测试、快速根据报错迭代。这类任务对吞吐敏感如果一个环节的思考拖太久整体节奏就被拖垮。单个 Agent 很难同时做好这两件事就像你不能要求同一个工程师既当整天写文档的技术专家、又当闷头刷代码的交付主力。多智能体协作的正确姿势是把这两类任务拆开让最擅长慢思考的模型去做评审让最擅长快执行的模型去做编码中间用统一的调度中枢串起来。我选的组合是Claude Code 负责架构评审Codex 负责编码执行Antigravity 作为承载这两个 Agent 的工作区和管理面板。这套组合跑下来最直观的感受是评审环节真正起到了把关作用Codex 在拿到清晰约束后编码速度飞快而我作为人类只需要在关键节点上做确认就行。2. 三个核心角色Antigravity、Claude Code 与 Codex 如何各司其职2.1 Antigravity多智能体的调度中枢Antigravity 在这套流程里的角色可以理解成项目工地上的总包方。它本身不直接替你做业务判断而是管理“哪些人在哪个区域干活、用什么资源、按什么顺序推进”。具体到使用层面Antigravity 提供的是基于工作区的多 Agent 管理能力。你可以在同一个工作区里注册多个智能体每个智能体绑定不同的模型后端或 CLI 工具然后给它们布置任务、设定边界。工作区里的文件、终端、运行结果都是共享的这意味着评审 Agent 产出的方案文档执行 Agent 可以直接读取使用不需要人工搬来搬去。这一点非常关键。多智能体协作最怕的就是信息孤岛。如果两个 Agent 各自持有项目的局部视野协作就无从谈起。Antigravity 把共享工作区作为协作底座Claude Code 写完的评审结论落在工作区的文档里Codex 直接读这份文档就能开工整个交接过程链路很短。2.2 Claude Code技术评审官我让 Claude Code 做架构评审不是因为“Claude 名气大”而是它的能力分布确实匹配这个岗位。Claude 系列模型在长上下文理解和代码结构分析上的表现比较突出给一段完整的项目代码它能指出模块之间的耦合风险、数据模型的潜在问题而且给出的建议通常带着充分的理由不只是泛泛而谈。在实战中我让 Claude Code 负责三类工作需求可行性分析、变更方案设计、代码合入前的评审。它的产出物是一份结构化的评审结论包括风险点、建议方案、分步实施计划。这么做还有个附带好处Claude 的思考过程被显式地沉淀成了文档。以前用单个 Agent 的时候它的“思考”是不可见的出了问题只能靠猜。现在评审结论白纸黑字写在工作区里Codex 照着执行我按照结论验收每一环都有据可查。这其实也是多智能体协作对比单 Agent 的隐性优势——过程资产变多了。2.3 Codex执行工程师Codex 的定位是执行工程师负责把评审结论变成真实代码。OpenAI 家在代码生成和 Agent 自主行动方面的积累确实硬Codex 在拿到明确任务约束后可以连续做多文件修改、跑测试、根据报错自愈迭代速度很快。而且它对 Git 仓库的操作很利落提交、分支、回滚这类动作几乎不用人操心。我实测的体感是在任务边界清晰的前提下Codex 的产出速度比传统人工编码快出一个量级很多时候是“肉眼可见地往文件里填代码”。但它也确实需要评审环节给它划定边界否则它容易在实现细节上自由发挥做出一些看起来能跑、实则不符合整体设计的东西。所以这三个角色的关系是一条明确的生产线Antigravity 负责提供场地和协调Claude Code 负责想清楚Codex 负责写出来。人类负责在入口给需求、在出口做验收中间偶尔处理异常。维度AntigravityClaude CodeCodex角色定位多智能体 IDE 与调度中枢架构评审与方案设计编码执行与测试迭代运行形态图形化工作区终端 CLI Agent终端 CLI Agent核心优势多 Agent 编排、共享工作区、手机端可查长上下文推理、代码结构分析高吞吐代码产出、多文件修改典型场景统一管理评审与编码流程需求拆解、方案评审、代码审查按方案实现功能、跑测试修问题3. 环境准备从安装到两个智能体成功联动3.1 Antigravity 安装与登录Antigravity 的安装本身不复杂从官网下载对应系统的安装包一路默认安装就行。真正容易卡住的是登录环节这个后面单独讲。安装完成后首次启动会引导你登录账号并创建工作区。工作区概念建议一开始就建立清楚每个项目一个工作区不要把所有项目塞进同一个工作区否则多 Agent 协作时上下文会很混乱。创建工作区时可以指定本地目录也可以新建一个空目录。我建议选一个已有的真实项目目录让两个 Agent 一开始就在真实代码上跑而不是先建演示项目再迁移省得后面路径混乱。3.2 安装并登录 Claude CodeClaude Code 目前的安装方式很成熟走 npm 全局安装即可。先确保本地有 Node.js 18 以上的环境然后执行npm install -g anthropic-ai/claude-code claude --version第一次执行claude会走一遍登录流程在浏览器里完成账号授权。如果你习惯用 API Key 方式也可以设置ANTHROPIC_API_KEY环境变量来跳过浏览器登录export ANTHROPIC_API_KEYsk-ant-xxxxWindows 上现在也有独立的 Claude Code 桌面版安装包下载后直接装体验和终端版基本一致。我在日常使用中还是更喜欢终端版因为和 Antigravity 工作区集成更顺滑。3.3 安装并登录 CodexCodex 的安装同样是 npm 全局安装命令很直接npm install -g openai/codex codex --version codex login这里有个关键选择你用 ChatGPT 账号登录还是用 OpenAI API Key。两者权限和可用模型并不完全一样。ChatGPT 账号登录方式在部分模型上会有限制比如某些模型会提示“当前模型在你的账号类型下不可用”API Key 方式更自由但要按量付费。我的建议是如果只是个人项目实验先用 API Key 方式跑通链路成本可控而且模型选择灵活如果是体验最新模型能力可以再切换到 ChatGPT 账号方式试试。3.4 在 Antigravity 中注册 Agent 与配置模型安装完两个 CLI 工具后回到 Antigravity在设置或 Agent 管理面板里把这两个工具注册成工作区里的智能体。注册时需要指定三件事Agent 名称比如 review-claude、dev-codex、调用的命令或工具分别指向claude和codex、运行时的 API Key 或认证信息。一个非常实用的技巧是给每个 Agent 配置独立的配置文件或环境变量避免两个 Agent 共享同一套密钥体系。比如 Claude Code 的配置写在~/.claude/下Codex 的配置在~/.codex/下两者天然隔离。如果你需要给某个 Agent 指定不同的模型也可以在注册时就写好模型参数后面切换项目时不用反复改。还有一个步骤容易被忽略全局规则。Antigravity 支持在工作区层面写全局规则类似.claude/rules或AGENTS.md的作用这些规则两个 Agent 都能读到。我会在全局规则里写清楚项目的语言栈、代码风格、禁止修改的目录、提交规范等内容。这两份规则是给多智能体立规矩的关键写得好能省掉后面大量的扯皮。4. 一套可落地的工作流评审→编码→验收4.1 需求拆解写出一份“及格”的任务说明多智能体协作的起点不是让 Agent 干活而是把需求本身写清楚。我在实践里发现任务说明的清晰程度直接决定最终产出质量。模糊的需求到了评审 Agent 那里产出的方案会模棱两可到了编码 Agent 那里代码就会跑偏。一份“及格”的任务说明至少包含四个要素业务背景、期望结果、约束条件、验收标准。业务背景告诉 Claude 为什么要做这件事期望结果描述交付物形态约束条件说明技术栈、兼容性要求、不许动的模块验收标准写明什么样的状态算完成。我通常的表现形式是这样的背景当前登录模块使用固定 Token安全性不足需要引入短期会话机制。 期望结果用户登录后获得短期 Access Token 与长期 Refresh TokenAccess Token 过期后自动刷新。 约束沿用现有 FastAPI 框架不得改动用户表结构兼容现有前端调用方式。 验收集成测试覆盖登录、刷新、过期场景现有用例全部通过。4.2 让 Claude 先做架构评审任务说明写好后先把它交给评审 Agent——Claude Code。这一步的关键词是“先想明白再动手”。我在给 Claude 的任务描述里会明确要求不要直接写代码只输出评审结论与实施方案。给 Claude Code 的评审提示词我常用的模板长这样请以资深架构师身份评审以下需求 [贴入任务说明] 请输出 1. 当前项目结构中与该需求相关的模块清单 2. 需求实现方案的可选路径以及各自的优缺点 3. 推荐方案的分步实施计划标注步骤间的依赖关系 4. 需求实现涉及的风险点与规避措施。 约束本轮只输出评审结论不修改任何源代码。Claude 会读取项目结构、关键文件然后给出相当扎实的分析。有一次它直接指出我的缓存模块存在循环依赖隐患这在之前单一 Agent 流程里根本没人提醒过。评审结果落成一份docs/review.md放进工作区这就是给下游执行 Agent 的“施工图”。4.3 把评审结论交给 Codex 执行评审完成后轮到执行 Agent 上场。给 Codex 的指令要尽量贴合评审结论减少它的自由裁量空间。我惯用的做法是直接告诉它“按照工作区根目录下的docs/review.md实施方案”并附上验收约束。请阅读 docs/review.md按照其中的实施计划完成任务。 要求 - 严格按方案的步骤顺序执行 - 实现后补充必要的单元测试 - 运行测试命令确保通过 - 不要修改计划之外的文件 - 中途遇到阻塞时记录日志并继续尝试无法解决时报告。Codex 拿到这份指令后就会进入快速编码模式。它的执行速度确实快多个文件的新增和修改几乎是一气呵成测试失败也会自己查日志修正。这里有个细节codex 默认会对当前目录做 Git 检查如果项目不在 Git 仓库里会提示错误。所以记得先把项目git init这也是给执行 Agent 留一条安全的退路。4.4 人工验收与回滚策略Codex 执行完毕后我不会马上信它“完成了”。验收这一步必须人来把关。首先看它提交的 diff确认改动范围没有超出评审方案其次看测试结果确认没有破坏现有功能最后把关键功能在本地手动跑一遍。验收不过的情况下回滚策略要提前想好。最稳妥的就是依赖 GitCodex 每次开工前先建一个分支比如feature/xxx-codex验收不通过就整体回退分支重新给评审 Agent 补充反馈再次走评审—编码循环。这个过程因为有多智能体参与迭代一轮的成本很低基本也就是几分钟的事。5. 手机端掌控研发进度不再绑在工位上5.1 手机端能查看和操作什么Antigravity 的移动端能力是这套工作流里最让人觉得值回票价的部分。通过手机浏览器访问 Antigravity 的 Web 控制台或者打开配套的移动端入口可以实时看到工作区内各个 Agent 的运行状态Claude 评审到哪一步了、Codex 正在改哪个文件、测试日志有没有报错这些信息在手机上都是可读的。更重要的是手机端不只是“看板”还可以做轻量操作。比如确认评审结论、给执行 Agent 追加补充说明、对阻塞任务触发重试。我在实际使用中最常用的三个动作查看进度、确认节点、追加指令。这三个动作覆盖了绝大多数移动场景下的需求。5.2 一个具体场景上午下发任务下午手机验收举一个我上周的真实例子。上午我在地铁上把一个新的需求描述整理好到公司后把它贴进 Antigravity 工作区让评审 Agent 先启动。整个上午我正常开例会、处理其他事情中间瞄一眼手机确认 Claude 已经给出了评审结论。午休时我在手机上直接点击确认顺便给 Codex 追加了一条指令要求它在实现时额外兼容旧版接口。下午外出办事的路上手机推送显示 Codex 已完成编码并通过测试。我在地铁上把 diff 大概过了一遍改动范围符合预期晚上回到家只用了十分钟做最终验收和合并。整个过程我没有专门为这个需求坐在电脑前等过一分钟。这种体验的关键是异步协作评审和编码这两个阶段天然存在先后依赖却不需要人在中间“陪着”。人只需要在两个阶段交接的节点上出现一次而移动端让这个“出现”变得随时随地。5.3 手机端介入的边界什么该干预什么不该管手机端虽然方便但不是所有事情都适合在手机上决策。我的经验是流程性确认比如评审完成、测试通过可以放心在手机上做涉及代码细节的决策比如某个实现方案要不要改、某段逻辑怎么写最好回到电脑前看清楚再定。还有一点要提醒不要让移动端成为你的“远程看监控”依赖。多智能体协作的价值是减少人工介入而不是让人更频繁地盯着状态刷屏。我给自己定的规矩是只在任务卡住或者收到明确的完成通知时才打开手机看其余时间让流程自己跑。这套模式能成立的前提是你愿意在入口把需求写清楚、在出口认真验收中间过程敢于放手。6. 高频问题排查实录6.1 Antigravity 登录不上或者打开失败这是我被问得最多的问题我自己也遇到过。常见表现是点击登录后页面一直转圈或者打开 IDE 直接闪退。排查路径按顺序来先确认网络环境是否稳定最简单的方法是换一个网络环境比如 Wi-Fi 切到手机热点看是否能恢复这能快速把问题定位到网络还是软件本身。网络没问题的话再清一遍本地登录缓存把 Antigravity 的配置文件目录备份后删除重新登录。还是不行就彻底卸载重装记得把用户数据目录一起清掉否则残留配置会导致同样的问题再现。6.2 Windows 下 Claude Workspace 启动报错虚拟机平台很多 Windows 用户会碰到 Claude 的 Workspace 启动失败提示要求启用 Windows 的虚拟机平台。这个问题的原因是 Claude 的某些隔离运行环境依赖 Windows 的虚拟化功能默认没开。解决办法是打开“启用或关闭 Windows 功能”勾选“虚拟机平台”和“Windows 虚拟机监控程序平台”重启电脑后再试。命令行方式更快用管理员权限打开 PowerShell 执行dism /online /enable-feature /featurename:VirtualMachinePlatform /all重启后再启动 Antigravity 里的 Claude Workspace 通常就能正常工作了。我还在虚拟机里遇到过一版 BIOS 没开虚拟化的情况那个得进固件设置打开 CPU 虚拟化选项属于另一个层面台式机用户如果命令行启用后仍然报错可以去检查一下。6.3 Codex 提示上下文溢出ran out of roomCodex 在高强度连续编码时偶尔会提示codex ran out of room in the models context。这个报错的意思是当前会话的上下文窗口已经被填满了。大型多文件任务特别容易出现。解决思路是把大任务拆小。让 Codex 一次只做一个完整的小模块做完提交再开新会话做下一个模块。另外不要在一个会话里反复重试同一段错误错误日志会飞快吃占上下文。如果已经触发了这个错误最佳做法是直接结束当前会话用codex resume或者新开会话把评审结论和已完成进度重新交代一遍。6.4 Codex 报模型不支持gpt-5.6-sol用 ChatGPT 账号登录 Codex 时有时候会看到类似the gpt-5.6-sol model is not supported when using codex with a chatgpt account的提示。这类问题的核心是账号类型和模型可用范围不匹配——某些特定后缀的模型版本只对特定订阅级别或 API 方式开放。解决办法很直接要么切换到 API Key 方式认证要么在 Codex 配置里把模型改成当前账号能用的版本。我个人倾向于在配置文件里显式指定模型不要依赖默认值这样切换项目时行为可预期。6.5 Agent 中途终止agent terminated due to error这个提示看起来吓人实际大多数情况是可恢复的。Agent 在调用工具、访问文件或者网络请求时遇到异常会终止当前执行并提示你可以提示模型重试。我的处理方式是先看工作区里的运行日志确认终止原因。如果是临时性错误网络抖动、文件被占用直接在对话里回复“请重试”即可。如果是任务本身的问题比如依赖安装失败就把错误信息补充给评审 Agent让它调整方案再让执行 Agent 重跑。6.6 想把模型接到其他兼容 API 服务上怎么配有些场景下你可能想把 Claude Code 或 Codex 接到其他提供兼容接口的模型服务上比如手头有 DeepSeek 等服务的 API Key想让工具走这些服务来降低成本或匹配特定模型。这本质上就是改环境变量的事Codex 认OPENAI_BASE_URL和OPENAI_MODELClaude Code 认ANTHROPIC_BASE_URL和ANTHROPIC_MODEL把地址指向兼容服务的官方接口把模型名改成对方提供的标识重启进程即可生效。需要注意一个坑并非所有兼容接口都完整实现了官方 SDK 依赖的全部能力。尤其工具调用这块不同服务实现差异很大轻则报错重则 Agent 以为自己能调用工具、实际调用失败却不明原因。我接第三方兼容服务前一定会先跑一个小项目验证工具调用链路确认稳定后再放上正式任务。常见问题典型报错/表现主要解法Antigravity 登录失败登录转圈、打开闪退换网络排查、清缓存、重装Claude Workspace 启动失败提示需要虚拟机平台启用 Windows 虚拟机平台功能并重启Codex 上下文溢出codex ran out of room in the models context拆分任务、新开会话、精简日志Codex 模型不可用gpt-5.6-sol is not supported切换认证方式或显式指定可用模型Agent 执行中断agent terminated due to error查看日志、重试或反馈评审 Agent 调整方案第三方兼容 API 异常工具调用失败、行为不一致小项目先验证链路再上正式任务7. 用了三周的一点真心话这套 Antigravity 联动 Claude 和 Codex 的多智能体协作流程我实际跑下来最深的体会是工具链本身并不复杂真正难的是调整自己的工作习惯。过去写代码人在键盘前思路跟着手指走现在人更像是一个项目的导演和制片人把“想清楚”交给一个 Agent把“写出来”交给另一个 Agent自己把控节奏和方向。如果你准备尝试我给三条最实际的建议。第一不要在项目初期就追求全自动先把“评审—编码—验收”三个环节都人肉走通再逐步放手。第二全局规则和工作区隔离一定要重视这是多智能体协作里投入产出比最高的一项准备。第三手机上确认流程很爽但代码合入前请务必回到电脑前认真看一次 diff这一眼能省掉后面无数的麻烦。最后再分享一个小技巧我一般会让评审 Agent 在每次评审结束时顺带产出一份“给执行 Agent 的交接说明”里面写清实施步骤和禁忌事项。这份交接说明如果能做到让一个不相干的人不读其他文档也能照着执行那么整个流水线的稳定性就非常高了。这一步做扎实了后面的编码阶段基本是行云流水。