当 AI 不再单打独斗：Google Antigravity Teamwork 深度解读
主题：Google 最近发布的 Teamwork 多智能体协作框架
发布时间：2026 年 8 月下旬（Antigravity/teamwork-preview开放）
官方资料：
- Teamwork: When AI Becomes a Research Partner
- Gemini Multi-Agent Teams in Antigravity
- Teamwork 官方文档
配图来源：官方博客与 Google Blog；部分示意图为笔者整理，案例中的工程示例为教学演示。
一句话读懂 Teamwork
Teamwork 不是“多开几个 Agent”，而是一套面向长周期、高不确定性任务的协作编排框架。
它让多个 Agent 在数小时甚至数天内：
- 提出候选方案；
- 互相质疑和证伪；
- 组合更强的解法；
- 在里程碑处接受独立审计；
- 最终把可验证结果交还给人类验收。
Google 的表述很直接：
人类负责定目标和最终验收，Agent 负责自主提出、对抗式检验、再构建更好的方案。
1. 它解决的是什么问题？
很多研究和工程任务，并不是“模型不够聪明”，而是单个 Agent 会话扛不住任务结构：
| 任务类型 | 单 Agent 常见失败点 |
|---|---|
| 大规模重构 | 改到一半上下文爆炸，前后不一致 |
| 系统仿真 | 局部实现看似正确，整体无法对齐 |
| 开放数学问题 | 早期错误思路被继续放大 |
| 跨天项目 | 没有里程碑交接，状态丢失 |
Teamwork 针对的，就是这类 too large / too uncertain / too open-ended 的问题。
2. Teamwork 到底是什么？
2.1 它属于 Google Antigravity，不是一个独立产品
Teamwork 运行在 Google Antigravity 中，通过命令：
/teamwork-preview
调用。
- 首次在 Google I/O 上预告；
- 2026 年 8 月下旬正式以 research preview 形式开放；
- 当前面向 Antigravity 付费套餐 用户；
- 底层主要搭配 Gemini 3.7 Flash 做高频 agentic 执行，必要时结合 Pro 模型做更深推理。
2.2 它不是固定 Agent 团队，而是 Pattern 蓝图
这是 Teamwork 最关键的设计之一。
Google 把不同任务对应的团队结构称为 Pattern。它不是写死的 orchestration 代码，而是一种“规格说明”：
- 定义有哪些角色；
- 各自负责什么；
- 什么条件下工作才能前进；
- 需要多少 Agent，由运行时动态决定。
官方当前公开的 Pattern 包括：
| Pattern | 适合什么 |
|---|---|
| Iterative Coding | 小范围、不可拆分的编码任务 |
| Distributed Coding | 多文件工程、系统仿真、大规模重构 |
| Long Proof | 开放数学/理论计算机科学问题 |
| Self-Verification | 深度数学推理、逐步自校验 |
| Document Review | 论文、RFC、设计文档评审 |
图源：Antigravity 官方博客 — 同一套框架可实例化为不同 Pattern
也就是说，你输入一个任务后，Gemini 会先判断“这是小修小补、还是跨天工程、还是数学证明”，再自动选团队结构。
3. 多智能体架构：不是分工，而是“分工 + 对抗”
Teamwork 和普通多 Agent 最大的差别，不是“一个写代码、一个写测试”这么简单，而是引入了对抗式验证门。
3.1 编排与执行层
- Sentinel：总协调者。记录需求、路由任务、发布进度，并在最后触发 Success Auditor。
- Project Orchestrator：项目经理。把目标拆成里程碑，协调并行工作流，并在里程碑之间交接给新的 orchestrator，避免上下文退化。
- Explorers：只读调研 Agent，负责看仓库、追调用链、评估候选方案，但不改代码。
- Workers：真正写代码、重构、补测试的执行 Agent。
3.2 对抗验证层
- Critic：独立代码审查，看正确性、完整性、接口一致性、风格。
- Challenger：主动构造对抗测试、边界条件、失败路径。
- Auditor：检查测试证据是否真实，防止“假通过”。
- Success Auditor：最终端到端验收，确认项目真的完成。
Google 特别强调：松散的多 Agent 团队很容易过早认同早期错误，然后在错误想法上自信地继续盖楼。Teamwork 用 Challenger / Auditor 机制，尽量把错误拦在里程碑之前。
4. 两阶段工作流：先对齐，再自治
Teamwork 不会你一敲命令就立刻乱改仓库，而是分成两个阶段。
图源：Antigravity 官方博客 — Distributed Coding 模式的线性编排流程
Phase 1：Prompt Crafting（范围访谈）
主 Agent 会先做一轮结构化访谈，原则是：
Specify What, Not How
你说清楚要什么，不要过早规定怎么做。
访谈通常覆盖：
- 目标与范围；
- 真正关心的需求；
- 每个需求如何独立验证；
- 验收标准；
- 项目工作目录。
最后会生成一个可审阅的 prompt artifact。你确认后，团队才开始真正执行。
Phase 2：Autonomous Execution（自治执行）
批准后，Sentinel 把项目交给 Project Orchestrator。此后团队会：
- 拆里程碑；
- 并行推进；
- 在每个阶段接受 Critic / Challenger / Auditor 检查；
- 把状态写入结构化 artifact。
常见 artifact 包括：
request artifact # 你的目标、约束、验收标准
project plan # 里程碑路线图
progress artifact # 实时进度与完成轨迹
默认工作目录：
~/teamwork_projects/{PROJECT_NAME}
5. Integrity Modes：同一框架，不同严格度
Teamwork 会根据你的要求选择不同的“诚信模式”：
| 模式 | 用途 | 特点 |
|---|---|---|
development | 快速迭代 | 默认模式，允许复用库和框架 |
demo | 可复现演示 | 不允许抄开源核心逻辑、不允许偷看测试源码 |
benchmark | 严格评测 | 要求更独立、更从零的实现，标准库为主 |
这意味着 Teamwork 既能做“尽快做出能跑的东西”，也能做“尽量公平、可审计的 benchmark 级任务”。
6. Google 公布的代表性成果
Google 在 2026 年 8 月底集中展示了 Teamwork + Gemini 3.7 Flash 的成果，覆盖数学、系统工程和开源工程三个方向。
6.1 数学与理论计算机科学
官方称，Teamwork 的 Long Proof pattern 已帮助解决多个开放问题，并在 TCSBench 上达到 71%。
代表性结果包括：
| 问题 | 结果 |
|---|---|
| Coresets for Lp Subspace Approximation | 改进 FOCS 2025 开放问题相关界 |
| Sparse Convex Optimization | 建立条件下界 |
| Maximal Inner Product Embeddings | 接近复杂度差距 |
| Provable Hadamard Quantization | 减少量化阶段与常数项 |
| Prefix-Matrix Factorizations | 给出近最优下界 |
| Knuth’s Cycles Conjecture | 给出 40+ / 70+ 页证明，并在 Lean 中形式化验证 |
这里最值得注意的不是“又解了一个题”，而是：
Flash 级模型 + 正确编排，也能做出 PhD 级研究。
其中部分结果最初由 Gemini 3.1 Pro 完成，但 Google 表示，有 3 个问题已经能用 Gemini 3.7 Flash 在 Teamwork 框架下复现。
图源：Antigravity 官方博客 — Long Proof 模式的锦标赛式协作网络
6.2 系统工程：RISC-V CPU 模拟器
Teamwork 还从零构建了一个 cycle-accurate、out-of-order RISC-V CPU simulator，并做到：
- 能启动
xv6到 shell； - 能跑 100+ RISC-V benchmark；
- 与硬件 ground truth 的平均周期误差仅 0.71%。
难点在于“静默执行差距（silent execution gap）”：微架构状态可能在几百个周期内悄悄偏离，最后才暴露。Teamwork 通过 lockstep co-simulation 和持续对齐来解决。
图源：Antigravity 官方博客 — Teamwork 模拟器与 BOOM 硬件的周期对齐
图源：Antigravity 官方博客 — 模拟器成功启动 xv6 内核
图源：Antigravity 官方博客 — 微架构验证统计（平均周期误差 0.71%）
6.3 开源工程：真实上游贡献
Teamwork 不是只在自家 benchmark 里好看，还做出了真实开源贡献：
- Eigen：为 GeMV 单行/单列矩阵实现 SIMD fast-path，已合入上游；
- ParlayHash / Swiss Parlay：多线程插入吞吐提升约 2 倍，单线程整体提升约 1.5 倍，内存占用降低约 25%。
这说明 Teamwork 的目标并不只是“生成看起来对的代码”，而是尽量产出能被外部维护者接受的结果。
图源：Antigravity 官方博客 — Eigen / ParlayHash 优化成果
图源：Google Blog — Gemini Multi-Agent Teams in Antigravity
7. 它和单 Agent、/boost、/goal 有什么区别？
Antigravity 里其实有多条不同“深度”的命令：
| 命令 | 适合时长 | 适合任务 |
|---|---|---|
| 普通对话 | 分钟级 | 小修小补、问答 |
/goal | 分钟到小时 | 明确目标下的持续执行 |
/boost | 秒到小时 | 复杂 bug、竞态、算法推理 |
/teamwork-preview | 小时到数天 | 跨天工程、仿真、研究 |
可以把它理解成：
- 单 Agent：一个很强的同事；
- /boost：请来几个专家一起深挖一个问题；
- /teamwork-preview：拉起一支项目组，带里程碑、审计和交付。
8. 怎么用？一个完整例子
例子 1：后端框架迁移
在 Antigravity Desktop / Web 或 CLI 中输入：
/teamwork-preview Migrate our REST API service from Express to Fastify,
including full test coverage, TypeScript typing, and benchmark validation.
可能发生的流程：
-
Phase 1 访谈
- 是否保留现有路由结构？
- 中间件如何迁移？
- 基准测试用什么数据集？
- 验收标准是不是“测试全绿 + QPS 不低于旧版”？
-
生成 prompt artifact
- 目标：Express → Fastify
- 范围：路由、中间件、错误处理、测试
- 验收：测试通过、类型检查通过、benchmark 报告
-
Phase 2 执行
- Explorers 先摸清现有路由和调用链；
- Workers 分模块迁移；
- Challenger 构造异常请求和边界测试；
- Auditor 检查测试是否真的执行成功；
- Success Auditor 做端到端验收。
-
最终交付
- Fastify 服务；
- 测试覆盖；
- benchmark 对比；
- 项目 plan / progress artifact。
例子 2：复杂仿真任务
/teamwork-preview Design and implement a cycle-accurate memory controller
with lockstep simulation tests.
这类任务适合 Teamwork，因为：
- 需要功能正确性；
- 需要时序对齐；
- 需要独立 oracle；
- 很难靠一次对话完成。
例子 3：数学证明任务
/teamwork-preview Prove theorem X and verify the bounds using adversarial counterexample search.
如果问题足够难，你还可以明确要求：
Use a very large team of agents.
系统会倾向选择 Long Proof (Large Team) pattern。
9. 一个更贴近普通开发者的“文档审查”例子
Teamwork 并不只适合“解数学题”或“写 CPU 模拟器”。
假设你刚写完一份内部 RFC：
/teamwork-preview Review this design doc for our new retrieval pipeline.
Focus on correctness, failure modes, evaluation methodology, and operational risks.
Teamwork 可能走 Document Review pattern：
- 一个 Agent 从“系统正确性”角度审；
- 一个 Agent 从“评测是否公平”角度审；
- 一个 Agent 从“线上故障与回滚”角度审；
- 最后合成一份结构化评审意见。
这比“让模型读一遍文档然后说一句看起来不错”强得多，因为它强制了多视角对抗。
10. 为什么 Teamwork 现在才变得可用？
Google 自己把关键原因说得很明白：Gemini 3.7 Flash。
3.7 Flash 的定位是：
- 面向 agentic workflow 的“日常主力模型”；
- 在工具调用、指令遵循、多步执行上更强；
- 成本与速度更适合长时间、多 Agent 并发。
也就是说，Teamwork 并不是突然想出来的新产品，而是：
长周期任务编排框架
+
足够便宜且足够强的 Flash 执行模型
+
对抗式验证工程
三者叠加后的结果。
11. 优点与局限
优点
- 适合长周期任务：能跨小时、跨天运行。
- 有明确角色分工：不是简单多开几个聊天窗口。
- 有对抗验证：Challenger / Auditor 降低“看起来很对”的风险。
- 人类仍在环：你先批准目标，最后再做验收。
- 已展示真实成果：数学、仿真、开源上游都有案例。
局限
- 仍是 preview：
/teamwork-preview说明还在研究预览阶段。 - 需要付费套餐：不是所有用户都能直接用。
- 成本高：多 Agent + 长时运行，token 和算力都不便宜。
- 不适合所有任务：改一个函数、查一个报错，用 Teamwork 反而过重。
- 结果仍需人类判断：尤其在数学和科研场景，最终接受仍应经过专家审查。
12. 谁应该尝试 Teamwork？
很适合
- 架构师：做大规模重构、框架迁移、子系统重写；
- 研究员：开放问题探索、论文证明、实验设计；
- 系统工程师：仿真器、内核子系统、复杂验证任务；
- 技术负责人：希望把“长任务”变成可审计、可交付的项目。
不太适合
- 只想快速改几行代码；
- 没有清晰验收标准；
- 不能提供测试、基准或独立验证方式；
- 希望完全无人值守直接上线生产。
13. 给开发者的实践建议
如果你准备第一次用 /teamwork-preview，建议遵循下面 6 条：
1. 目标写得像项目 brief，不要像聊天
坏例子：
帮我把项目搞好一点
好例子：
将 auth 模块从 session 改成 JWT，保持所有现有 API 兼容，
测试覆盖率不低于 85%，并提供迁移说明文档。
2. 一定写清验收标准
例如：
- 测试全绿；
- benchmark 不低于旧版；
- 文档包含迁移步骤；
- 关键路径有集成测试。
3. 明确 integrity mode
如果你要的是严格评测，就直接说：
Use benchmark integrity mode. No copying core logic from open source.
4. 大任务要允许里程碑
不要要求“一次性全做完且中途别问我”。Teamwork 的优势正是里程碑和审计。
5. 用 artifact 看过程，而不是一直打断
重点看：
- project plan 是否合理；
- progress 是否卡在某个子问题；
- Auditor 是否发现假测试或假通过。
6. 把 Teamwork 当“研究/工程合伙人”，不是“自动打工人”
它最强的地方不是替你拍板，而是替你高强度迭代。
14. 我如何理解 Teamwork 的真正价值？
如果只把它看成“Google 又发布了一个多 Agent 功能”，其实低估了它。
它真正代表的是一种工程范式变化：
从「一个更强的模型」
走向
「一个能长期协作、互相质疑、可审计的智能体系统」
对开发者来说，最重要的启发可能是：
- 长任务能力 increasingly 是工程问题，不只是模型参数问题；
- 对抗式验证比“多生成几个答案”更重要；
- Prompt artifact、里程碑、审计链，正在成为 Agent 项目的标准件；
- Flash 模型 + 好的 orchestration，可能比单个大模型更接近实际生产力。
15. 快速上手命令
Desktop / Web
/teamwork-preview Migrate our REST API service from Express to Fastify,
including full test coverage, TypeScript typing, and benchmark validation.
CLI
/teamwork-preview Design and implement a cycle-accurate memory controller
with lockstep simulation tests.
适合尝试的任务类型
/teamwork-preview Refactor our monolithic payment service into three bounded modules with integration tests.
/teamwork-preview Review this RFC and identify correctness, testing, and rollout risks.
/teamwork-preview Prove and verify the bounds for theorem X with adversarial counterexample search.
总结
Google Teamwork 的核心，不是“更多 Agent”，而是：
目标对齐
→ 模式选择
→ 并行执行
→ 对抗验证
→ 里程碑交接
→ 人类验收
它把很多研究者和工程师本来就会做的事情——提方案、互相挑错、做实验、再组合——做成了可配置、可审计、可长时运行的 Agent 系统。
如果你的任务是：
- 太大，
- 太开放，
- 太不确定，
- 或者太依赖验证，
那么 Teamwork 值得认真试一次。
但如果只是改一个小 bug，继续用普通 Agent 或 /boost 就够了。
参考资料
- Google Antigravity Blog: Teamwork: When AI Becomes a Research Partner
- Google Blog: Gemini Multi-Agent Teams in Antigravity
- Google Antigravity Docs: Teamwork agent teams (/teamwork-preview)
- Google Antigravity Docs: Slash commands overview
- Google AI Studio: Gemini 3.7 Flash Developer Guide
