企业官网建设流程全解析

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 也需要。

我把这五类问题整理成了一张速查表，方便你遇到问题的时候直接对照。

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 不再单打独斗的时代确实来了，但站在团队中心的，仍然得是你。