1. 从单打独斗到“一起上”AI 编程正在换打法先聊个现象。过去一年里AI 编程工具基本都在做同一件事把大模型塞进编辑器让它在对话窗口里替你写代码。这个模式用熟了以后你会觉得它像一个手脚麻利但脑子一根筋的实习生——你给它一个清晰到极点的指令它能干得漂亮可一旦任务稍微绕一点比如“帮我把这个模块重构了顺便把关联的测试补上再更新一下文档”它就开始丢三落四改着改着忘了最初的约束甚至会一本正经地告诉你它已经完成了其实跑都没跑过。这就是我今天想聊的 Antigravity Teamwork 想解决的问题。Antigravity 是 Google 推出的 AI 集成开发环境核心模型走的是 Gemini 这条线而 Teamwork 是它最值得琢磨的一个能力不再让一个 AI Agent 从头扛到尾而是让多个 Agent 像一支小团队那样分工协作各管一摊最后合到一起。这篇内容我会从原理、架构、实操、踩坑几个角度拆开讲适合两类人看一是天天和 AI 编程工具打交道、已经对单 Agent 模式感到力不从心的开发者二是做 AI 应用架构、关注多智能体系统怎么落地的技术管理者。看完你至少能明白三件事Teamwork 到底拆出了哪些角色、多个 Agent 并行跑的时候如何不打架以及什么项目值得上这种模式、什么项目千万别硬上。2. 为什么单个 AI Agent“再聪明也白搭”瓶颈不在智商在上下文很多人在评价 AI 编程工具时下意识会盯着模型的智商——代码写得对不对、算法选得好不好。但用久了你会发现单 Agent 模式的真正瓶颈根本不是智商而是一个工程问题上下文管理。2.1 单个 Agent 同时只能消化有限的信息大模型确实有一个很大的上下文窗口看起来能塞下一整个仓库。但现实是窗口大不代表它真的能“同时”关注所有信息。当任务链条拉长比如第一步改数据库表结构第二步改后端接口第三步改前端展示第四步跑测试第五步更新文档——每一步产生的中间结果都会挤占有限的注意力。Agent 往往改到第三步就忘了第一步定的字段命名规则甚至为了“完成任务”它会自作主张把某个方法签名给改了然后后续所有代码都在将错就错。我试过不少单 Agent 工具做跨模块需求最典型的翻车现场是它连续改了几十个文件编译倒是能过但一跑业务逻辑就崩原因是两个文件里用的是同一个数据模型的两套字段名它自己没意识到前后不一致。这不是模型笨而是它缺乏一种机制把“改到哪”“定过什么约定”“哪些文件已经被动过”这些状态持续地管理起来。2.2 单 Agent 天然做不了“并行”另一个硬伤是串行。一个 Agent 只能沿着一条思路推进一条路走不通就得回头这跟人类开发者的工作方式完全不一样。真实项目里前端、后端、测试、文档是可以并行推进的而单 Agent 模式里所有工作像一个流水线只能一节一节往前挪。任务稍微大一点耗时就成倍上涨。这也是为什么多 Agent 协作会成为必然方向。它的核心思路本质上是工程上的“分而治之”把一个大任务拆成多个子任务每个子任务由独立的 Agent 负责它们共享同一个工作区但各有各的目标和上下文。这样既解决了“一个脑子装不下所有事”的问题也天然具备并行能力。Antigravity Teamwork 走的正是这条路。它把一个项目任务拆给多个 Agent 并行去干并且在实际实现里加了几层我们稍后要细聊的机制角色分工、状态同步、变更审查。这套机制的成熟程度决定了它是“真团队”还是“多个单 Agent 的简单拼接”。3. Antigravity Teamwork 的架构思路不是“三头六臂”是“一支队伍”先给结论Antigravity Teamwork 最值得学习的地方是它把一个模糊的“多 Agent 协作”概念落地成了有明确分工、有状态管理、有审查环节的工程体系。我不打算逐行分析源码——公开资料也没给到那个颗粒度——而是把它当作一个“多智能体系统工程案例”来拆这套思路换到任何多 Agent 框架里都能用。3.1 角色分工从 Planner 到 Reviewer每件事都有人盯根据我实际使用的体感Teamwork 模式至少会拆出这几类角色虽然界面里不一定叫这个名字但行为上非常清晰规划者Planner负责理解需求把大任务拆成有序的子任务明确每个子任务的产出物和验收标准。这个角色是“大脑”它不直接写代码但它的拆解质量决定了整个协作的下限。执行者Worker/Builder真正动手写代码的 Agent。Teamwork 模式下会有多个 Worker 并行工作每个 Worker 领取一个或几个子任务在自己的工作线程里改动文件。审查者Reviewer检查改动是否符合任务要求、有没有明显 bug、是否引入了不必要的变更。它会输出审查意见要求对应 Worker 修改。命令执行者Executor/Terminal Agent负责跑命令比如安装依赖、执行测试、启动服务。独立出来的好处是跑命令的阻塞和失败不会拖住写代码的 Agent。这四类角色各有各的上下文。规划者看的是全局需求文档和任务拆分Worker 只关心自己负责的那几个文件Reviewer 关注的是变更 diff。这就是多 Agent 系统里常说的“上下文隔离”——每个 Agent 不需要也不敢把整个仓库塞进脑袋它只需要掌握跟当前任务相关的信息效率反而更高。3.2 状态同步靠“文件系统 任务清单”而不是靠互相聊天多 Agent 协作最容易翻车的不是单个 Agent 能力不行而是它们之间信息不同步。A 改了一个函数签名B 不知道还在用旧签名调它合到一半就冲突了。Antigravity Teamwork 处理这个问题的思路很有意思它不是让 Agent 们互相“对话”而是把状态沉淀在两个载体上。第一个载体是真实的工作区文件。每个 Worker 改动都是实际写到磁盘里的其他 Worker 读取文件时自然能看到最新状态这是一种最朴素的、也无处不在的状态同步机制。第二个载体是结构化的任务清单。规划者把任务拆开后每完成一个任务状态会更新其他 Agent 能看到哪些已完成、哪些还在进行避免两个 Worker 抢同一个文件。这两点结合起来非常像真实团队的工作方式代码以 Git 仓库为准进度以项目管理看板为准。Agent 之间不需要长篇大论地互相交流因为交流和对话是不稳定、不可追踪的而文件和任务状态是确定的、可审计的。3.3 审查与合并防止一个人的错误变成整个团队的灾难多 Agent 并行还有个隐性风险错误会被放大。三个 Worker 各自写的代码单独看都还行但合并到一起可能互相踩脚。所以必须有审查环节。在 Teamwork 模式里每个 Worker 的改动会先进入一个待审查状态Reviewer 会检查这些改动。我不确定它内部是不是所有场景都强制走完整审查链路但从实际使用来看至少关键任务的改动一定会经过一次审查而且最终合并权还在你手里。这个设计我非常认同——多 Agent 的价值是提升速度和覆盖面但绝不该用“让 AI 自己审自己”的方式牺牲交付质量。4. 实操体验我如何用 Teamwork 模式跑完一个带前后端的小型需求讲完架构说点实际的。我拿一个不算大但跨了多个技术栈的需求做了次完整试验给一个本地运行的 Todo 应用加上“按标签筛选 完成率统计”功能。这个需求涉及数据库字段、后端查询接口、前端 UI还有一套单元测试非常适合演示多 Agent 分工。4.1 任务描述怎么写决定协作质量的上限在 Teamwork 模式下启动任务之前最关键的其实是需求描述。单 Agent 模式下你可以甩过去一句话然后让它自己领会多 Agent 模式如果描述太模糊规划者拆出来的子任务大概率也是混沌的。我当时的描述大致结构是三层背景这个项目用什么技术栈、数据模型长什么样、目标要做哪几个功能点、用户操作路径是什么样的、约束必须保持原有接口兼容、测试必须通过、不改动与需求无关的模块。这一层写清楚之后规划者才开始拆分任务。这里有个技巧不要试图自己去拆得很细那是规划者的活。你要给的是“边界”和“验收标准”而不是“第一第二步做什么”。拆得过细反而束缚了 Agent 自己的发挥空间甚至会让后面的执行者因为任务描述太机械而失去对整体目标的把握。4.2 并行执行一个改数据库一个改接口一个改前端任务拆解完成后Teamwork 会启动多个 Worker。我那次观察到的并行情况大致是Worker A 负责新增数据库标签字段和数据迁移Worker B 负责扩展后端查询接口Worker C 负责前端筛选组件和统计面板Worker D 在它们仨基本写完第一批代码后开始补测试用例。这四个 Worker 不是同时动手的它们之间有隐性的先后依赖D 会等前三个有初步改动后再跑测试否则测了个寂寞。但这种等待是事件驱动的不需要我人工干预。我只需要偶尔切过去看一眼日志确认没有哪个 Worker 卡住。一个让我比较欣慰的细节是后端接口先改完前端还在写的时候复用旧接口的代码区域没有被误改。这说明“上下文隔离”起作用了——Worker C 知道自己只管前端不会被隔壁的接口签名变动带偏而真正需要知道新接口格式的改动又是通过读取文件变化来感知的。这种隔离与共享的平衡是 Teamwork 模式相对成熟的表现。4.3 “完成”不等于“能用”Reviewer 和人工审查缺一不可最终所有 Worker 都报告任务完成Reviewer 也给出通过意见后我并没有直接把结果拿过来就完事。我又做了一道人工审查逐个看关键 diff重点检查三件事——有没有改超出需求范围的文件、有没有删掉看似无关但实际被引用的代码、数据库迁移是否具备回滚能力。事实证明这道人工审查很有必要。Reviewer Agent 确实抓住了一个小问题前端统计面板里有一个除法可能出现除零提示 Worker 修掉了。但它没有发现另一个问题数据库迁移脚本在 SQLite 上能跑换到 MySQL 上会因为默认值语法不兼容报错。这类依赖具体部署环境的问题Reviewer Agent 一般也发现不了因为它们跑在同一个本地工作区里缺少真实生产环境的差异视角。这一轮实操下来我的体感是Teamwork 模式在处理“多文件、多技术栈、有明确结果物”的任务时效率确实比单 Agent 强不少实测时间大概是我手动拆任务、串行跑单 Agent 的 60% 左右。但它并没有消除审查成本只是把“写代码”的花的时间压缩了把“理解与审查”的时间拿到明面上来。5. 那些年我踩过的 Teamwork 模式的坑五类翻车现场与排查思路任何工具到了实战环节都会暴露问题。Teamwork 模式优点不少但坑也真不少。我整理了几类高频事故如果你在用的过程里遇到类似现象可以参考下排查方向。5.1 Agent 之间抢同一个文件这是最典型的冲突。两个 Worker 都觉得自己负责的部分需要改同一个工具函数然后同时写入后写的人把前面人的改动覆盖掉了导致功能上出现“灵异现象”——某个功能明明刚才还好好的跑了一圈回来就坏了。排查思路看任务清单里哪些子任务被标记为“相关文件重叠”这类任务在设计拆解时就应该避免。如果你手动调整任务分配尽量保证每个 Worker 拥有独立的文件集合如果冲突实在躲不开至少确保两个任务有明确的先后顺序。5.2 Agent 陷入死循环情况通常是这样Worker 修了一个 bug跑测试又冒出新问题继续修再跑测试……然后陷入无休止的修改循环甚至最后代码被改得面目全非测试还是红的。排查思路给执行者加任务的“完成定义”——比如“所有测试通过且无新增失败”或者设置修改轮次上限。如果发现 Agent 在同一个位置反复打转最有效的办法是打断它回到上一个稳定状态重新调整任务描述把那个问题的边界写得更清楚。5.3 任务描述前后矛盾Agent 直接摆烂我自己有一次写需求时又要求“保持现有接口返回结构不变”又要求“新增字段 X 必须返回”这两个要求如果项目里没有默认值设计就是天然矛盾。结果负责后端接口的 Worker 折腾半天最后抛了个 “terminated due to error” 就退出整个任务卡死。排查思路这不算工具 bug而是需求问题。规划者拆任务时如果发现子任务之间有逻辑冲突要么拒绝执行并列出冲突点要么选择一种默认方案推进。我观察到的 Antigravity 处理方式是倾向于“按字面意思执行”所以你写的描述必须前后一致。多读两遍你的需求比反复重试任务管用得多。5.4 审查逐步失灵低级错误被放行Reviewer Agent 也不是万无一失尤其是在任务量巨大的情况下它会更容易放过一些低级错误。比如我遇到过它没发现新增代码里有个未使用的变量也没发现某处引用了不存在的样式类名。排查思路重大改动不要只依赖工具内置 Reviewer可以自己再跑一遍 lint、编译、单测三件套或者把review阶段拆成两轮第一轮 Reviewer 审功能逻辑第二轮你自己审 diff 范围和风格一致性。再往深了说稳定的项目应该配置好 CI让机器帮你兜住最低层的错误。5.5 上下文污染上一个任务的记忆影响了下一个任务有几次我连续在一个工作区里做不同需求的实验结果新任务开始时Agent 还在沿用上一个任务里的约束决定导致新任务的方案明显不合理。这属于上下文没完全清理干净。排查思路切换任务需求时尽量开一个新的工作区或分支保留上一个任务的环境状态不要让多个需求混在一个 Agent 会话里。团队成员尚且在换任务时需要用思维导图理理思路Agent 也需要。我把这五类问题整理成了一张速查表方便你遇到问题的时候直接对照。现象可能原因优先排查方向功能改完就坏、出现灵异覆盖多个 Worker 同时改同一文件检查任务清单里文件重叠的子任务调整任务边界Agent 反复修同一问题、死循环任务边界模糊、缺少完成定义打断任务回退到稳定状态重新描述边界任务报告异常终止需求描述前后矛盾检查输入内容是否自洽手动简化任务再试Reviewer 漏审明显 bug任务量过大、审查覆盖不全人工复查 diff依赖 CI 补充底层检测新任务受旧任务影响会话上下文未清理隔离工作区或新建分支分开执行不同需求6. 什么项目该上 Teamwork什么项目别硬上工具用得好不好一半在工具一半在场景判断。Teamwork 模式虽然听起来全能但绝不是所有项目都适合。我按照实际经验给你排个优先级。6.1 适合用 Teamwork 的场景有一类项目的特征非常明确需求边界清楚、涉及多个技术栈或模块、产出物可以用测试来验证。典型例子包括老项目技术栈升级、给现有系统增加一组独立的功能模块、数据迁移脚本的编写与校验、大型重构中的机械性改动。这类项目最大的特点就是可以拆而且拆完以后每个子任务都能独立验证。另外如果你手头有一个多模块项目要统一改造比如把所有模块的日志格式换成结构化输出或者统一 API 错误码规范这种“重复性强、范围大”的任务Teamwork 模式几乎是量身定做的。多个 Worker 并行改几十个文件效率比人肉改高太多了。6.2 不适合用 Teamwork 的场景反过来有几种情况我建议别硬上。需求还在剧烈变化、探索阶段的活别上。Teamwork 模式更适合执行明确的任务而不是陪你在迷雾里找方向。变更范围和权限极其敏感、需要严格审计的单点修改别上。像改一个核心权限校验逻辑、动支付金额计算这种我自己会亲自动手这种改动价值不在速度而在确定性。还有一类要注意测试基础设施很弱的项目。如果项目基本没有自动化测试多 Agent 并行产生的改动就很难快速验证对错出错之后排查成本反而盖过了并行带来的效率收益。这种情况下我建议先把测试补起来再考虑引入多 Agent 协作。6.3 给团队落地的一点建议如果你们团队想引入 Teamwork 这类多 Agent 模式我的建议是分三步走。第一步挑一个低风险、可回滚的小任务试水培养对工具行为的直觉。第二步定义好自己团队的“任务描述模板”把业务背景、技术边界、验收标准固定成结构化的格式降低沟通成本。第三步建立人工审查制度明确哪些改动必须人工 double-check比如依赖升级、数据库变更、安全相关代码。工具负责跑得快人负责跑得稳。7. 写在最后你才是项目里不可替代的“规划者”最后分享一点个人的体会。Antigravity Teamwork 这种多 Agent 协作模式方向上肯定是对的它把 AI 编程从“提问—回答”的单线程交互推向了“委托—并行—验收”的工程化协作方式。这就像是从“雇了一个什么都会一点的全能实习生”升级到“带了一支各有所长的外包小团队”上限高了很多但对你的管理能力也提出了新要求。我在几个项目里反复试过之后最大的感悟是AI 协作工具的成熟度越高人对“需求定义”和“任务规划”的能力就越重要。以前我们是写代码的人代码是我们亲手敲出来的细节天然在脑子里。现在代码是 Agent 写的你的价值不再体现在“每一行都要自己写”而体现在——你能不能把需求边界画清楚把验收标准定明白在关键时刻识别出 AI 的盲目自信。所以如果你刚接触 Teamwork 这类模式我的建议很朴素先别急着追求并行和速度用一个小项目把它的脾气摸清楚看看它在什么任务上靠谱、什么任务上犯傻。用顺手了再慢慢把更大、更复杂的任务交给它。AI 不再单打独斗的时代确实来了但站在团队中心的仍然得是你。
多Agent协作编程实战：Antigravity Teamwork如何突破单Agent瓶颈
1. 从单打独斗到“一起上”AI 编程正在换打法先聊个现象。过去一年里AI 编程工具基本都在做同一件事把大模型塞进编辑器让它在对话窗口里替你写代码。这个模式用熟了以后你会觉得它像一个手脚麻利但脑子一根筋的实习生——你给它一个清晰到极点的指令它能干得漂亮可一旦任务稍微绕一点比如“帮我把这个模块重构了顺便把关联的测试补上再更新一下文档”它就开始丢三落四改着改着忘了最初的约束甚至会一本正经地告诉你它已经完成了其实跑都没跑过。这就是我今天想聊的 Antigravity Teamwork 想解决的问题。Antigravity 是 Google 推出的 AI 集成开发环境核心模型走的是 Gemini 这条线而 Teamwork 是它最值得琢磨的一个能力不再让一个 AI Agent 从头扛到尾而是让多个 Agent 像一支小团队那样分工协作各管一摊最后合到一起。这篇内容我会从原理、架构、实操、踩坑几个角度拆开讲适合两类人看一是天天和 AI 编程工具打交道、已经对单 Agent 模式感到力不从心的开发者二是做 AI 应用架构、关注多智能体系统怎么落地的技术管理者。看完你至少能明白三件事Teamwork 到底拆出了哪些角色、多个 Agent 并行跑的时候如何不打架以及什么项目值得上这种模式、什么项目千万别硬上。2. 为什么单个 AI Agent“再聪明也白搭”瓶颈不在智商在上下文很多人在评价 AI 编程工具时下意识会盯着模型的智商——代码写得对不对、算法选得好不好。但用久了你会发现单 Agent 模式的真正瓶颈根本不是智商而是一个工程问题上下文管理。2.1 单个 Agent 同时只能消化有限的信息大模型确实有一个很大的上下文窗口看起来能塞下一整个仓库。但现实是窗口大不代表它真的能“同时”关注所有信息。当任务链条拉长比如第一步改数据库表结构第二步改后端接口第三步改前端展示第四步跑测试第五步更新文档——每一步产生的中间结果都会挤占有限的注意力。Agent 往往改到第三步就忘了第一步定的字段命名规则甚至为了“完成任务”它会自作主张把某个方法签名给改了然后后续所有代码都在将错就错。我试过不少单 Agent 工具做跨模块需求最典型的翻车现场是它连续改了几十个文件编译倒是能过但一跑业务逻辑就崩原因是两个文件里用的是同一个数据模型的两套字段名它自己没意识到前后不一致。这不是模型笨而是它缺乏一种机制把“改到哪”“定过什么约定”“哪些文件已经被动过”这些状态持续地管理起来。2.2 单 Agent 天然做不了“并行”另一个硬伤是串行。一个 Agent 只能沿着一条思路推进一条路走不通就得回头这跟人类开发者的工作方式完全不一样。真实项目里前端、后端、测试、文档是可以并行推进的而单 Agent 模式里所有工作像一个流水线只能一节一节往前挪。任务稍微大一点耗时就成倍上涨。这也是为什么多 Agent 协作会成为必然方向。它的核心思路本质上是工程上的“分而治之”把一个大任务拆成多个子任务每个子任务由独立的 Agent 负责它们共享同一个工作区但各有各的目标和上下文。这样既解决了“一个脑子装不下所有事”的问题也天然具备并行能力。Antigravity Teamwork 走的正是这条路。它把一个项目任务拆给多个 Agent 并行去干并且在实际实现里加了几层我们稍后要细聊的机制角色分工、状态同步、变更审查。这套机制的成熟程度决定了它是“真团队”还是“多个单 Agent 的简单拼接”。3. Antigravity Teamwork 的架构思路不是“三头六臂”是“一支队伍”先给结论Antigravity Teamwork 最值得学习的地方是它把一个模糊的“多 Agent 协作”概念落地成了有明确分工、有状态管理、有审查环节的工程体系。我不打算逐行分析源码——公开资料也没给到那个颗粒度——而是把它当作一个“多智能体系统工程案例”来拆这套思路换到任何多 Agent 框架里都能用。3.1 角色分工从 Planner 到 Reviewer每件事都有人盯根据我实际使用的体感Teamwork 模式至少会拆出这几类角色虽然界面里不一定叫这个名字但行为上非常清晰规划者Planner负责理解需求把大任务拆成有序的子任务明确每个子任务的产出物和验收标准。这个角色是“大脑”它不直接写代码但它的拆解质量决定了整个协作的下限。执行者Worker/Builder真正动手写代码的 Agent。Teamwork 模式下会有多个 Worker 并行工作每个 Worker 领取一个或几个子任务在自己的工作线程里改动文件。审查者Reviewer检查改动是否符合任务要求、有没有明显 bug、是否引入了不必要的变更。它会输出审查意见要求对应 Worker 修改。命令执行者Executor/Terminal Agent负责跑命令比如安装依赖、执行测试、启动服务。独立出来的好处是跑命令的阻塞和失败不会拖住写代码的 Agent。这四类角色各有各的上下文。规划者看的是全局需求文档和任务拆分Worker 只关心自己负责的那几个文件Reviewer 关注的是变更 diff。这就是多 Agent 系统里常说的“上下文隔离”——每个 Agent 不需要也不敢把整个仓库塞进脑袋它只需要掌握跟当前任务相关的信息效率反而更高。3.2 状态同步靠“文件系统 任务清单”而不是靠互相聊天多 Agent 协作最容易翻车的不是单个 Agent 能力不行而是它们之间信息不同步。A 改了一个函数签名B 不知道还在用旧签名调它合到一半就冲突了。Antigravity Teamwork 处理这个问题的思路很有意思它不是让 Agent 们互相“对话”而是把状态沉淀在两个载体上。第一个载体是真实的工作区文件。每个 Worker 改动都是实际写到磁盘里的其他 Worker 读取文件时自然能看到最新状态这是一种最朴素的、也无处不在的状态同步机制。第二个载体是结构化的任务清单。规划者把任务拆开后每完成一个任务状态会更新其他 Agent 能看到哪些已完成、哪些还在进行避免两个 Worker 抢同一个文件。这两点结合起来非常像真实团队的工作方式代码以 Git 仓库为准进度以项目管理看板为准。Agent 之间不需要长篇大论地互相交流因为交流和对话是不稳定、不可追踪的而文件和任务状态是确定的、可审计的。3.3 审查与合并防止一个人的错误变成整个团队的灾难多 Agent 并行还有个隐性风险错误会被放大。三个 Worker 各自写的代码单独看都还行但合并到一起可能互相踩脚。所以必须有审查环节。在 Teamwork 模式里每个 Worker 的改动会先进入一个待审查状态Reviewer 会检查这些改动。我不确定它内部是不是所有场景都强制走完整审查链路但从实际使用来看至少关键任务的改动一定会经过一次审查而且最终合并权还在你手里。这个设计我非常认同——多 Agent 的价值是提升速度和覆盖面但绝不该用“让 AI 自己审自己”的方式牺牲交付质量。4. 实操体验我如何用 Teamwork 模式跑完一个带前后端的小型需求讲完架构说点实际的。我拿一个不算大但跨了多个技术栈的需求做了次完整试验给一个本地运行的 Todo 应用加上“按标签筛选 完成率统计”功能。这个需求涉及数据库字段、后端查询接口、前端 UI还有一套单元测试非常适合演示多 Agent 分工。4.1 任务描述怎么写决定协作质量的上限在 Teamwork 模式下启动任务之前最关键的其实是需求描述。单 Agent 模式下你可以甩过去一句话然后让它自己领会多 Agent 模式如果描述太模糊规划者拆出来的子任务大概率也是混沌的。我当时的描述大致结构是三层背景这个项目用什么技术栈、数据模型长什么样、目标要做哪几个功能点、用户操作路径是什么样的、约束必须保持原有接口兼容、测试必须通过、不改动与需求无关的模块。这一层写清楚之后规划者才开始拆分任务。这里有个技巧不要试图自己去拆得很细那是规划者的活。你要给的是“边界”和“验收标准”而不是“第一第二步做什么”。拆得过细反而束缚了 Agent 自己的发挥空间甚至会让后面的执行者因为任务描述太机械而失去对整体目标的把握。4.2 并行执行一个改数据库一个改接口一个改前端任务拆解完成后Teamwork 会启动多个 Worker。我那次观察到的并行情况大致是Worker A 负责新增数据库标签字段和数据迁移Worker B 负责扩展后端查询接口Worker C 负责前端筛选组件和统计面板Worker D 在它们仨基本写完第一批代码后开始补测试用例。这四个 Worker 不是同时动手的它们之间有隐性的先后依赖D 会等前三个有初步改动后再跑测试否则测了个寂寞。但这种等待是事件驱动的不需要我人工干预。我只需要偶尔切过去看一眼日志确认没有哪个 Worker 卡住。一个让我比较欣慰的细节是后端接口先改完前端还在写的时候复用旧接口的代码区域没有被误改。这说明“上下文隔离”起作用了——Worker C 知道自己只管前端不会被隔壁的接口签名变动带偏而真正需要知道新接口格式的改动又是通过读取文件变化来感知的。这种隔离与共享的平衡是 Teamwork 模式相对成熟的表现。4.3 “完成”不等于“能用”Reviewer 和人工审查缺一不可最终所有 Worker 都报告任务完成Reviewer 也给出通过意见后我并没有直接把结果拿过来就完事。我又做了一道人工审查逐个看关键 diff重点检查三件事——有没有改超出需求范围的文件、有没有删掉看似无关但实际被引用的代码、数据库迁移是否具备回滚能力。事实证明这道人工审查很有必要。Reviewer Agent 确实抓住了一个小问题前端统计面板里有一个除法可能出现除零提示 Worker 修掉了。但它没有发现另一个问题数据库迁移脚本在 SQLite 上能跑换到 MySQL 上会因为默认值语法不兼容报错。这类依赖具体部署环境的问题Reviewer Agent 一般也发现不了因为它们跑在同一个本地工作区里缺少真实生产环境的差异视角。这一轮实操下来我的体感是Teamwork 模式在处理“多文件、多技术栈、有明确结果物”的任务时效率确实比单 Agent 强不少实测时间大概是我手动拆任务、串行跑单 Agent 的 60% 左右。但它并没有消除审查成本只是把“写代码”的花的时间压缩了把“理解与审查”的时间拿到明面上来。5. 那些年我踩过的 Teamwork 模式的坑五类翻车现场与排查思路任何工具到了实战环节都会暴露问题。Teamwork 模式优点不少但坑也真不少。我整理了几类高频事故如果你在用的过程里遇到类似现象可以参考下排查方向。5.1 Agent 之间抢同一个文件这是最典型的冲突。两个 Worker 都觉得自己负责的部分需要改同一个工具函数然后同时写入后写的人把前面人的改动覆盖掉了导致功能上出现“灵异现象”——某个功能明明刚才还好好的跑了一圈回来就坏了。排查思路看任务清单里哪些子任务被标记为“相关文件重叠”这类任务在设计拆解时就应该避免。如果你手动调整任务分配尽量保证每个 Worker 拥有独立的文件集合如果冲突实在躲不开至少确保两个任务有明确的先后顺序。5.2 Agent 陷入死循环情况通常是这样Worker 修了一个 bug跑测试又冒出新问题继续修再跑测试……然后陷入无休止的修改循环甚至最后代码被改得面目全非测试还是红的。排查思路给执行者加任务的“完成定义”——比如“所有测试通过且无新增失败”或者设置修改轮次上限。如果发现 Agent 在同一个位置反复打转最有效的办法是打断它回到上一个稳定状态重新调整任务描述把那个问题的边界写得更清楚。5.3 任务描述前后矛盾Agent 直接摆烂我自己有一次写需求时又要求“保持现有接口返回结构不变”又要求“新增字段 X 必须返回”这两个要求如果项目里没有默认值设计就是天然矛盾。结果负责后端接口的 Worker 折腾半天最后抛了个 “terminated due to error” 就退出整个任务卡死。排查思路这不算工具 bug而是需求问题。规划者拆任务时如果发现子任务之间有逻辑冲突要么拒绝执行并列出冲突点要么选择一种默认方案推进。我观察到的 Antigravity 处理方式是倾向于“按字面意思执行”所以你写的描述必须前后一致。多读两遍你的需求比反复重试任务管用得多。5.4 审查逐步失灵低级错误被放行Reviewer Agent 也不是万无一失尤其是在任务量巨大的情况下它会更容易放过一些低级错误。比如我遇到过它没发现新增代码里有个未使用的变量也没发现某处引用了不存在的样式类名。排查思路重大改动不要只依赖工具内置 Reviewer可以自己再跑一遍 lint、编译、单测三件套或者把review阶段拆成两轮第一轮 Reviewer 审功能逻辑第二轮你自己审 diff 范围和风格一致性。再往深了说稳定的项目应该配置好 CI让机器帮你兜住最低层的错误。5.5 上下文污染上一个任务的记忆影响了下一个任务有几次我连续在一个工作区里做不同需求的实验结果新任务开始时Agent 还在沿用上一个任务里的约束决定导致新任务的方案明显不合理。这属于上下文没完全清理干净。排查思路切换任务需求时尽量开一个新的工作区或分支保留上一个任务的环境状态不要让多个需求混在一个 Agent 会话里。团队成员尚且在换任务时需要用思维导图理理思路Agent 也需要。我把这五类问题整理成了一张速查表方便你遇到问题的时候直接对照。现象可能原因优先排查方向功能改完就坏、出现灵异覆盖多个 Worker 同时改同一文件检查任务清单里文件重叠的子任务调整任务边界Agent 反复修同一问题、死循环任务边界模糊、缺少完成定义打断任务回退到稳定状态重新描述边界任务报告异常终止需求描述前后矛盾检查输入内容是否自洽手动简化任务再试Reviewer 漏审明显 bug任务量过大、审查覆盖不全人工复查 diff依赖 CI 补充底层检测新任务受旧任务影响会话上下文未清理隔离工作区或新建分支分开执行不同需求6. 什么项目该上 Teamwork什么项目别硬上工具用得好不好一半在工具一半在场景判断。Teamwork 模式虽然听起来全能但绝不是所有项目都适合。我按照实际经验给你排个优先级。6.1 适合用 Teamwork 的场景有一类项目的特征非常明确需求边界清楚、涉及多个技术栈或模块、产出物可以用测试来验证。典型例子包括老项目技术栈升级、给现有系统增加一组独立的功能模块、数据迁移脚本的编写与校验、大型重构中的机械性改动。这类项目最大的特点就是可以拆而且拆完以后每个子任务都能独立验证。另外如果你手头有一个多模块项目要统一改造比如把所有模块的日志格式换成结构化输出或者统一 API 错误码规范这种“重复性强、范围大”的任务Teamwork 模式几乎是量身定做的。多个 Worker 并行改几十个文件效率比人肉改高太多了。6.2 不适合用 Teamwork 的场景反过来有几种情况我建议别硬上。需求还在剧烈变化、探索阶段的活别上。Teamwork 模式更适合执行明确的任务而不是陪你在迷雾里找方向。变更范围和权限极其敏感、需要严格审计的单点修改别上。像改一个核心权限校验逻辑、动支付金额计算这种我自己会亲自动手这种改动价值不在速度而在确定性。还有一类要注意测试基础设施很弱的项目。如果项目基本没有自动化测试多 Agent 并行产生的改动就很难快速验证对错出错之后排查成本反而盖过了并行带来的效率收益。这种情况下我建议先把测试补起来再考虑引入多 Agent 协作。6.3 给团队落地的一点建议如果你们团队想引入 Teamwork 这类多 Agent 模式我的建议是分三步走。第一步挑一个低风险、可回滚的小任务试水培养对工具行为的直觉。第二步定义好自己团队的“任务描述模板”把业务背景、技术边界、验收标准固定成结构化的格式降低沟通成本。第三步建立人工审查制度明确哪些改动必须人工 double-check比如依赖升级、数据库变更、安全相关代码。工具负责跑得快人负责跑得稳。7. 写在最后你才是项目里不可替代的“规划者”最后分享一点个人的体会。Antigravity Teamwork 这种多 Agent 协作模式方向上肯定是对的它把 AI 编程从“提问—回答”的单线程交互推向了“委托—并行—验收”的工程化协作方式。这就像是从“雇了一个什么都会一点的全能实习生”升级到“带了一支各有所长的外包小团队”上限高了很多但对你的管理能力也提出了新要求。我在几个项目里反复试过之后最大的感悟是AI 协作工具的成熟度越高人对“需求定义”和“任务规划”的能力就越重要。以前我们是写代码的人代码是我们亲手敲出来的细节天然在脑子里。现在代码是 Agent 写的你的价值不再体现在“每一行都要自己写”而体现在——你能不能把需求边界画清楚把验收标准定明白在关键时刻识别出 AI 的盲目自信。所以如果你刚接触 Teamwork 这类模式我的建议很朴素先别急着追求并行和速度用一个小项目把它的脾气摸清楚看看它在什么任务上靠谱、什么任务上犯傻。用顺手了再慢慢把更大、更复杂的任务交给它。AI 不再单打独斗的时代确实来了但站在团队中心的仍然得是你。