Google Teamwork：多个 Agent，不等于一支团队

多 Agent 的共识陷阱

过去一年，Agent 已经越来越会做事。它能调查代码库、修改文件、调用终端、运行测试，也能连续工作很长时间。但任务一旦从“帮我改一段代码”，变成“帮我完成一次跨几十个文件的系统迁移”，问题就不再只是模型聪不聪明。一个 Agent 既要规划、执行、检查，又要判断自己是否完成，很容易陷入同一个问题：它会不断证明自己的第一版方案是对的。增加更多 Agent 也不一定能解决。一群 Agent 如果缺少明确的分工和独立验证，往往会接受最早出现的错误，再围绕这个错误补充越来越多看起来合理的细节。最后得到的不是更可靠的答案，而是一个被集体完善过的错误。

Teamwork 的核心命题

Google 在 8 月 27 日公布了 Antigravity Teamwork 的一系列更新。官方对它的定义，是一个面向复杂长期任务的多 Agent 编排框架：不同 Agent 可以在数小时甚至数天内提出方案、相互批评、继续修正，最终共同完成研究和工程任务。Teamwork 最早在 Google I/O 上公开，这次更新则进一步披露了它的运行机制和实际结果。这次更新真正值得关注的地方，不是谷歌又增加了一个 Agent 功能，而是它开始回答一个更难的问题：怎样把多个 Agent 组织成一支不会互相放大错误的团队？

分工、边界与交接机制

多个 Agent 最大的问题，是太容易达成共识。我们通常会直觉地认为，多一个 Agent，就多一个视角。但现实可能恰恰相反。如果多个 Agent 使用相近的模型、相似的上下文和同一套任务描述，它们很可能拥有相似的盲点。第一个 Agent 提出一条错误路线，第二个 Agent 没有推翻它，而是在这条路线下增加一个实现方案；第三个 Agent 再根据已有内容补充测试和解释。参与者越来越多，错误反而显得越来越完整。Google 在 Teamwork 的官方介绍中也直接承认，松散组织的多 Agent 系统很容易跑偏：Agent 会认同其他 Agent 早期出现的错误，并自信地在错误基础上继续推进。

三类责任分离

Teamwork 把一项任务拆成三种责任。它首先要求把任务说明白。在正式执行前，Antigravity 会围绕任务目标、使用场景、核心要求、验证方式和验收标准，与用户进行一次结构化确认。Google 把这个阶段概括为：说明要什么，而不是逐步规定怎么做。用户负责定义最终目标和完成标准，系统负责决定需要多少 Agent、如何拆分任务、哪些工作可以并行，以及每个阶段如何验收。确认完成后，系统会生成一份可审阅的任务说明。只有用户修改并批准，Agent 团队才进入自主执行。

进入执行阶段后，Teamwork 把工作大致分成三类责任：

• 第一类是组织任务。Sentinel 负责接收已经批准的任务、记录目标并汇报进展；Project Orchestrator 则负责把大型任务拆成里程碑，安排并行工作，处理任务依赖，为每一部分分配执行者。
• 第二类是完成任务。Explorer 只负责调查代码库、追踪调用关系和评估方案，不能修改源文件。Worker 才拥有文件和终端工具，负责真正的开发、重构和测试。
• 第三类是证明任务真的完成了。Critic 检查逻辑、接口和代码质量；Challenger 主动寻找极端输入和失败路径；Auditor 核验测试是否真实运行，防止 Agent 跳过测试、伪造输出或者只搭建一个表面可用的空壳。最后还有一个没有参与前面开发过程的 Success Auditor，负责完整的端到-end检查。只有它确认结果满足要求，系统才会把结果交还给用户。

这些角色的名字并不是重点。真正重要的是，Teamwork 把三件事分开了：谁负责安排任务；谁负责完成任务；谁负责证明任务已经完成。只要这三种责任仍然集中在同一个 Agent 身上，多 Agent 系统就很容易变成一场角色扮演。

结构化产物替代聊天记忆

Agent 团队的“记忆”，不应该只存在于聊天记录里。Teamwork 还有一个容易被忽视的设计：它不依靠某个 Agent 记住全部事情。系统会保存三类核心产物：

• 第一类记录用户最初的目标、限制条件和验收标准。
• 第二类记录里程碑、任务依赖、当前工作流和任务分配。
• 第三类记录每个阶段的进度、执行命令、测试结果、审查意见和失败原因。

Agent 之间交接任务时，读取的是这些结构化产物，而不是简单翻阅前一个 Agent 留下的长对话。这看起来只是一个工程细节，实际上决定了多 Agent 能不能处理真正的长任务。聊天记录适合交流，但不适合充当项目状态。一个长期任务至少需要区分：什么是原始需求；什么是当前计划；什么已经完成；什么仍然失败；哪些结论已经被验证；哪些只是某个 Agent 的猜测。当这些信息全部混在自然语言对话中，后续 Agent 很难稳定地恢复任务状态。Teamwork 的产物机制，更像人类团队使用的需求文档、项目计划、进度记录和验收报告。它们不是为了写得好看，而是为了让一项工作在更换执行者以后仍然能够继续。Teamwork 还为不同 Agent 分配独立工作目录，并通过文件所有权减少多个 Worker 同时修改同一文件造成的冲突。命令、状态变化、审查意见和验证日志也会被记录下来，方便用户查看任务究竟是怎样完成的。因此，Agent 团队并不是多个模型同时出现在一个聊天窗口里。它至少还需要外部状态、工作边界和证据记录。没有这些基础设施，所谓 Agent 协作很容易退化成多轮讨论。

可变的协作 Pattern

Teamwork 不是固定流程，而是一套可变的组织模板。传统工作流通常会提前写死步骤：先调查，再开发，然后测试，最后生成报告。这种方式适合稳定、重复的流程。但开放性的工程和研究任务，往往无法在开始时知道应该拆成多少部分、需要尝试多少条路线，也不知道哪条路线会在中途失败。Teamwork 为不同任务设计了不同的协作 Pattern。Pattern 不是一段写死的执行代码，而是一份团队蓝图：它定义哪些角色参与、各自承担什么责任，以及结果满足什么条件才能进入下一阶段。Gemini 会根据任务自动选择合适的 Pattern。执行过程中，Agent 数量和团队结构也可以继续变化，而不是在开始时固定下来。

例如：

• 大型软件工程可以采用分布式开发模式，把相对独立的模块交给不同 Worker，再由独立角色审查。
• 技术文档可以采用多角度评审模式，让不同 Agent 分别检查逻辑、证据和遗漏。
• 开放数学问题则可以同时生成多条候选路线，并为每条路线配备一个专门的反驳者。反驳者的工作不是帮助方案变得更完整，而是尽可能找出它为什么不成立。只有经受住反驳的路线才会继续向下分解。被推翻的方案也不会被简单删除，其中的失败原因和可用想法会被保留下来，进入下一轮综合。

普通工作流规定的是“先做什么，后做什么”。Teamwork 试图规定的是：什么样的方案有资格继续向前走。这个差别很重要。因为处理复杂问题时，系统最大的风险通常不是某一步执行得慢，而是一条错误路线在没有受到质疑的情况下不断消耗资源。

结果与边界

Google 为 Teamwork 公布了三类结果：

• 在数学和理论计算机科学任务中，Google 称 Teamwork 处理了七个开放问题，其中五项结果形成了公开的 arXiv 论文；与 Knuth’s Cycles Conjecture 相关的简化构造，还使用 Lean 进行了形式化验证。
• 在系统工程任务中，Teamwork 使用 Gemini 3.7 Flash 从零构建了一个周期级乱序执行 RISC-V CPU 模拟器。这个模拟器能够启动 xv6 操作系统，并在未见测试任务上与硬件参照保持较低的周期误差。
• 在开源软件任务中，Teamwork 参与生成的 Eigen 和 ParlayHash 性能优化，通过了外部维护者的正常审查，进入了上游项目。

三类结果里，最值得关注的或许不是某个内部 Benchmark 分数。而是它们都存在相对明确的外部验收方式：数学证明可以被专家或形式化工具检查；CPU 模拟器可以与参考实现对照；开源代码必须通过外部维护者的审查。这说明 Teamwork 当前最适合的，不是所有复杂工作，而是那些虽然执行路径开放，结果却能够被客观验证的任务。边界也恰恰在这里。Google 公布的多数结果仍然主要来自官方披露。部分论文已经公开，并不代表所有结论都完成了广泛的独立复核。Google 公布的 71% TCSBench 成绩使用了 Gemini 3.7 Flash 与 Gemini 3.1 Pro 的组合，而且 TCSBench 本身是 Google 内部开发的理论计算机科学评测。官方当时还表示，混合模型能力会在后续更新中提供。因此，这些结果更适合作为一种技术信号，而不是直接证明“AI 团队已经超过人类团队”。它证明的是：同样的模型，在不同的组织方式下，可以表现出明显不同的任务能力。

从个人能力到组织能力

Agent 的竞争，正在从个人能力走向组织能力。过去判断一个 Agent 强不强，主要看模型。模型能不能推理，能不能调用工具，能不能处理长上下文，能不能生成代码。Teamwork 把另一些问题推到了前台：目标是否能够被准确描述；长任务如何拆成可以交接的阶段；并行 Agent 如何避免相互冲突；错误方案由谁主动推翻；测试是否真实运行；过程是否留下可检查的证据；任务失败以后能否保留状态继续推进；最终结果由谁接受。这些问题，单靠换一个更强的模型解决不了。它们需要的是 Agent 运行时、任务状态、工作空间、验证机制和人类验收。这也是 Teamwork 比“多开几个 Agent”更重要的地方。它把人类团队里一些非常基础、却长期被 Agent 产品忽略的东西重新带了回来：分工不能只有角色名称，还要有权限边界；协作不能只有消息传递，还要有状态交接；审查不能只是再问一次模型，而要主动寻找失败证据；完成不能由执行者自己宣布，而要经过独立验收。模型决定一个 Agent 能想到什么；组织机制决定一群 Agent 最终能不能把事情做完。

开发者可验证的最小实践

开发者可以先验证一个最小版本。不需要一开始就搭建几十个 Agent。选择一个范围明确、能够客观验收的任务，就可以验证 Teamwork 背后的核心原则。例如，一次跨多个文件的小型代码重构、一份需要多角度审查的技术方案，或者一个带有固定测试集的数据处理任务。先由人写清楚目标、禁止事项和验收标准。然后设置一个编排 Agent，负责拆分任务和安排依赖；设置两个执行 Agent，分别调查和实施；再设置一个没有参与开发的验证 Agent，负责运行真实测试、寻找失败案例并检查执行证据。验证不通过时，不要只返回一句“存在问题”。它需要把失败输入、测试日志和具体原因交还给执行 Agent，让下一轮修改能够从真实证据出发。最终交付的也不应该只有一份结果。还应该包括：任务实际完成了什么；运行过哪些检查；哪些失败已经修复；还有哪些不确定性需要人判断。这里最重要的不是 Agent 数量。而是从一开始就把执行和验收分开，把状态放到对话之外，把证据作为交付的一部分。