AIREITER一次证明要写出 5000 万行 Lean 4 代码、两周内完成 80 万行安全 Rust、让 TPU 内核提速 4.09 倍——Google 在 11 月 13 日发布的研究更新，展示了 Antigravity Teamwork 的能力边界。不过，Teamwork 通常只适合需要持续数小时甚至数天、并且按里程碑推进的项目，因为单次运行就可能消耗每周配额中的很大一部分。
Antigravity Teamwork 到底是什么
Antigravity Teamwork 是 Google 面向大型、高度依赖验证的任务推出的多智能体编排工作流，运行在 Antigravity 内部。输入 /teamwork 后，系统会启动一支协同团队，由 Sentinel、Project Orchestrator、Explorers、Workers、Critic、Challenger、Auditor 和 Success Auditor 等角色组成。团队会按里程碑制定计划，在专用项目目录中工作，并在每个里程碑结束前进行独立验证。
Teamwork 分为两个阶段。第一阶段是范围确认访谈：主智能体会记录目标、需求、验证方式、验收标准和项目目录，默认目录为 ~/teamwork_projects/{PROJECT_NAME}。第二阶段是自主执行，过程围绕 request、project plan 和 progress 等结构化产物展开；每个 Worker 拥有独占的文件权限，交接前还要经过 Critic、Challenger、Auditor 和 Success Auditor 的层层检查（Teamwork 文档）。
访谈阶段设定的完整性模式，会决定整个流程的严格程度：
development（默认）：强调快速迭代，可以复用代码和框架，但会拒绝伪造输出和只做表面工作的门面实现。demo：面向可复现演示；禁止从开源项目复制核心逻辑、把核心工作交给外部完成，或通过阅读测试源码来猜答案。benchmark：最严格的模式；要求使用目标语言标准库从零实现，并通过独立的基准真值评估。
系统还会根据任务类型自动调整团队结构：
- 通用分布式编码（默认）：适合多文件工程任务和重构。
- 迭代编码：适合提示中明确要求“保持小范围”的单个、边界清晰的修复。
- Document Review：从多个角度审阅论文和设计文档。
- Math / Proof 和 Math / Proof Large Team：用于形式化推理和大型猜想验证项目。
在 Antigravity App 和 CLI 的付费套餐中，Teamwork 通常适合持续数小时到数天的任务（Teamwork 文档）。
Teamwork、Swarm、Boost 和 subagents 怎么选
只有当任务确实需要里程碑、审计关卡和独立项目目录时，才应该选择 Antigravity Teamwork。日常工作大多用更轻量的选项就够了，模式选错只会白白消耗配额。
| 工具 | 适用场景 | 启动方式 | 工作区 | 验证方式 | 典型时长 | 套餐 |
|---|---|---|---|---|---|---|
| Subagents | 聚焦型辅助任务：代码库调研、浏览器检查、运行测试 | 自动启动或使用 @subagent | 当前工作区 | 父智能体检查回复 | 几秒到几分钟 | 所有套餐 |
Boost（/boost） | 困难但范围较窄的问题：竞态条件、棘手 Bug、算法 | /boost <task>，立即启动 | 当前工作区，使用隔离上下文 | Worker 相互挑战并重新验证，编排器进行抽查 | 几秒到数小时 | 付费套餐 |
Swarm（/swarm） | 可清晰拆分的广泛任务：文件、软件包、测试套件 | /swarm <task>，立即启动 | 当前工作区或每个 Worker 的副本 | 专用的 @verifier 审查差异并运行测试 | 几分钟到数小时 | Google AI Pro 和 Ultra |
Teamwork（/teamwork） | 多里程碑项目：迁移、仿真、形式化证明 | /teamwork <goal> + 范围确认访谈 | 专用的 ~/teamwork_projects/{PROJECT_NAME} | 由 Critic、Challenger、Auditor、Success Auditor 设置关卡 | 数小时到数天 | 付费套餐 |
如果要跨几十个文件迁移 REST API 到 Fastify，并配套完整测试；构建一个根据硬件计时器验证、精确到周期的模拟器；或者编写并通过 Lean 4 检查的形式化证明，可以用 Teamwork。若只是给三个互不相关的 API 处理器增加校验，让每个文件由一个 Worker 负责，再由验证器运行 npm test，Swarm 更合适。单个竞态条件，或需要“挑战—修复—验证”连续推进、并不适合并行拆分的联动重构，应该用 Boost。至于在主对话继续进行时查资料等后台任务，交给 subagents 即可。
这种选择困难并不是错觉。一位 Antigravity 用户这样说：
“agy 现在的模式实在太多了，说真的，越来越让人困惑。现在我们有……/teamwork（带审计关卡的长期里程碑项目）……还有动态工作流……公平地说，我们其实不需要这么多模式。模式越少，困惑就越少……”
— @Heamanth_alturi（X）
一个简单判断标准是：如果任务只有一个完成标准，并且一次工作就能结束，Teamwork 就是杀鸡用牛刀。如果任务需要计划产物、进度产物，还需要由作者之外的其他角色为每个里程碑签字确认，那么 Teamwork 就很合适。
11 月研究更新究竟证明了什么
11 月 13 日发布的 Google Research 更新是一份成果报告，而不是产品发布公告。此前，付费套餐已经可以通过 /teamwork-preview 使用 Teamwork；这次更新记录的是基于 Gemini 4 Argon、Carbon 和 Hydrogen 的里程碑团队完成了哪些工作。人类仍然负责定义问题、约束条件和评估方案，新的 Critic 则会在干净的上下文中进行审查。
| 领域 | 项目示例 | 智能体规模 | 公布结果 |
|---|---|---|---|
| 数学 | Courtade–Kumar 猜想证明（Google、香港中文大学、南加州大学、卡内基梅隆大学） | 长期证明模式、Lean 4 形式化 | 完整证明约包含 5000 万行 Lean 代码 |
| 化学 | 根据 NMR 数据推断分子结构 | 30 个专用智能体 + 物理模拟器 | Top-1 精确匹配率 95%，Top-3 精确匹配率 100% |
| 系统 | Zircon 从 C++ 重写为 Rust | 为期两周的 Argon 项目 | 约 80 万行安全 Rust，并在 arm64 上启动 |
| 机器学习硬件 | TPU 内核优化（DuoDiscover） | 代理评估器（23 秒，相比之下为 7–32 分钟） | 在 17 个 JAXBench 内核上平均提速 4.09 倍 |
Google 还开放了申请，让 10,000 名学术研究人员获得为期六个月的顶级访问权限。文章中的部分工作流仍在向外部用户逐步开放，因此应把这张表看作能力证据，而不是每个项目都能复现同样收益的承诺。
官方页面没有告诉你的配额成本
Antigravity 的定价页面显示，Individual 套餐为每月 $0，提供不限量 Tab 补全和基础每周限制；Pro 和 Ultra 则提供更高限制以及灵活的 AI 积分池，但官方没有公布确切的请求数量。Pro 和 Ultra 的配额每五小时刷新一次，直到触及每周上限；超出部分可以使用购买的积分，并可将设置设为 Never 或 Always（套餐文档）。Teamwork 和 Boost 需要付费套餐；Swarm 需要 Pro 或 Ultra（Swarm 文档）。Google 自己发布的 OS 文章也提醒过，几个复杂的预览任务就可能消耗掉整周配额（Antigravity OS 文章）。
用户反馈只是个案，并不具有代表性，但从“可以接受”到“消耗严重”都有：
“天啊，这东西大概只用了 5 分钟就把我的配额全吸干了（3.5 Flash（high））。”
— u/Several_Bag_3665（Reddit）
“Ultra 套餐实际上非常好用。我用 Gemini Flash medium 跑了一个 Teamwork preview，整整运行了 50 分钟，只用了我五小时配额的大约 20%，而且确实完成了规模很大的重构。”
— u/ningkaiyang（Reddit）
两个机制可以解释这种差异。Antigravity 关于 /swarm 的文档说明，每个 Worker 都是独立智能体，等待中的 Worker 不消耗 token；配额耗尽的 Worker 会暂停，不会自动重试，除非出现新的 board 帖子、切换模型或收到直接消息（Swarm 文档）。Teamwork 文档没有发布同样的恢复说明，因此应把它视为需要根据自身套餐确认的多智能体共同行为。另一方面，Teamwork 会生成大量中间产物，包括 request、plan、progress 记录，以及每个智能体的临时笔记和验证日志（Teamwork 文档）。这些内容是预期的状态记录，不一定代表实际进展。
首次运行 Teamwork，别把一周配额烧光
启动 Teamwork 只需要一条命令，但范围确认访谈才决定最终账单。在 App 中打开项目对话，输入 /teamwork Migrate our REST API service from Express to Fastify, including full test coverage, TypeScript typing, and benchmark validation。在 CLI 中，从项目目录运行 /teamwork Design and implement a cycle-accurate memory controller with lockstep simulation tests。你可以通过 subagent 面板或 CLI 状态栏查看进度，使用 Alt+J 跳转到审批位置，并实时查看计划和进度产物（Teamwork 文档）。
把第一阶段当作成本控制环节。描述“要做什么”，而不是“具体怎么做”：明确目标、受众（演示、生产还是基准测试）、硬性约束，并为每项需求指定一个客观检查方式，例如测试套件或指标脚本。迭代开发选择 development；只有在确实需要可展示成果或从零实现证明时，才选择 demo 或 benchmark，因为越严格的验证通常意味着更多智能体工作。批准之前，先确认专用项目目录是否正确。
执行期间要把控方向。范围变更统一交给协调器处理；移除 Worker 前，先合并它的改动；判断进度时看里程碑关卡和测试证据，不要只数生成了多少文件。首次运行时，可以在 Settings 中把 AI 积分超额设置为 Never，让基础配额耗尽后直接停止工作，而不是悄悄消耗购买的积分（套餐文档）。在套餐文档允许的情况下，可以让更强的模型负责规划、更便宜的模型负责实现——Ultra 支持 Orchestrator（Carbon）和 Orchestrator（Argon），分别使用 Gemini 4 Carbon 或 Argon 进行规划，再由 Gemini 4 Hydrogen 执行实现（定价页面）；这也是Carbon 与 Argon 对比中体现的一种权衡。
常见问题
/teamwork 和 /teamwork-preview 有什么区别？
/teamwork-preview 是早期研究预览版的名称。目前Teamwork 文档在付费套餐中使用 /teamwork；Google 尚未发布单独的正式可用声明。
配额耗尽后，Teamwork 能暂停或恢复吗？
已记录的 /swarm 行为是：配额耗尽的 Worker 会暂停，直到出现新的 board 帖子、切换模型或收到直接消息（Swarm 文档）；Teamwork 文档没有确认相同的恢复路径。重新启动前，先检查 ~/teamwork_projects/{PROJECT_NAME} 中的套餐和进度产物，因为已经完成的部分里程碑会以文件形式保留下来。
Teamwork 会生成哪些产物？
包括 request、project-plan 和 progress 产物，以及每个智能体的临时笔记、辅助脚本和验证日志（Teamwork 文档）。生成大量 Markdown 属于正常现象；应根据里程碑关卡和测试证据判断进度，而不是看文件数量。
Teamwork 适合用于生产代码库吗？
Teamwork 会在专用目录中隔离工作，并通过独占文件权限和审计关卡降低冲突风险（Teamwork 文档）。但用于生产环境时，仍然需要人工检查验收标准和测试证据，并在合并前完成最终的 Success Auditor 检查。
输入 /teamwork 前的 30 秒检查清单
只有在以下五点全部满足时，才输入 /teamwork：任务跨越多个里程碑；每个里程碑都有客观检查方式；使用专用目录确实有帮助；独立审计关卡很重要；一次高配额消耗的运行，比数周人工工作更划算。否则，能并行拆分的广泛任务用 Swarm，困难但范围窄的 Bug 用 Boost，后台辅助任务用 subagents——把 Teamwork 留给真正需要一支团队的项目。