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

发布日期：2026-09-06 07:23:45 浏览次数： 1724

作者：Agent进化论

微信搜一搜，关注“Agent进化论”

过去一年，Agent 已经越来越会做事。

它能调查代码库、修改文件、调用终端、运行测试，也能连续工作很长时间。

但任务一旦从“帮我改一段代码”，变成“帮我完成一次跨几十个文件的系统迁移”，问题就不再只是模型聪不聪明。

一个 Agent 既要规划、执行、检查，又要判断自己是否完成，很容易陷入同一个问题：

它会不断证明自己的第一版方案是对的。

增加更多 Agent 也不一定能解决。

一群 Agent 如果缺少明确的分工和独立验证，往往会接受最早出现的错误，再围绕这个错误补充越来越多看起来合理的细节。

最后得到的不是更可靠的答案，而是一个被集体完善过的错误。

Google 在 8 月 27 日公布了 Antigravity Teamwork 的一系列更新。官方对它的定义，是一个面向复杂长期任务的多 Agent 编排框架：不同 Agent 可以在数小时甚至数天内提出方案、相互批评、继续修正，最终共同完成研究和工程任务。Teamwork 最早在 Google I/O 上公开，这次更新则进一步披露了它的运行机制和实际结果。

这次更新真正值得关注的地方，不是谷歌又增加了一个 Agent 功能。

而是它开始回答一个更难的问题：

怎样把多个 Agent 组织成一支不会互相放大错误的团队？

多个 Agent 最大的问题，是太容易达成共识

我们通常会直觉地认为，多一个 Agent，就多一个视角。

但现实可能恰恰相反。

如果多个 Agent 使用相近的模型、相似的上下文和同一套任务描述，它们很可能拥有相似的盲点。

第一个 Agent 提出一条错误路线，第二个 Agent 没有推翻它，而是在这条路线下增加一个实现方案；第三个 Agent 再根据已有内容补充测试和解释。

参与者越来越多，错误反而显得越来越完整。

Google 在 Teamwork 的官方介绍中也直接承认，松散组织的多 Agent 系统很容易跑偏：Agent 会认同其他 Agent 早期出现的错误，并自信地在错误基础上继续推进。

另一个问题来自自我验证。

让一个 Agent 自己写代码、自己设计测试、自己判断测试是否充分，本质上相当于让施工方同时承担验收工作。

它未必会故意作弊，但很容易选择最有利于证明自己正确的检查方式。

任务越长，这个问题越明显。

大量代码、日志、工具返回结果和中间讨论不断进入上下文，最初的约束逐渐被执行细节淹没。即使上下文窗口足够大，信息都放在一个对话里，也不代表模型能够始终正确判断哪些内容最重要。

Teamwork 的核心思路不是继续扩大上下文，而是把长任务拆成多个阶段，让 Agent 通过结构化产物进行交接，而不是让所有状态永远堆在一段不断增长的对话中。

换句话说，多 Agent 系统真正缺少的不是更多“脑力”。

而是分工、边界和交接机制。

Teamwork 把一项任务拆成三种责任

Teamwork 的运行并不是用户输入一句话，几十个 Agent 就立即开始工作。

它首先要求把任务说明白。

在正式执行前，Antigravity 会围绕任务目标、使用场景、核心要求、验证方式和验收标准，与用户进行一次结构化确认。

Google 把这个阶段概括为：

说明要什么，而不是逐步规定怎么做。

用户负责定义最终目标和完成标准，系统负责决定需要多少 Agent、如何拆分任务、哪些工作可以并行，以及每个阶段如何验收。

确认完成后，系统会生成一份可审阅的任务说明。只有用户修改并批准，Agent 团队才进入自主执行。

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

第一类是组织任务。

Sentinel 负责接收已经批准的任务、记录目标并汇报进展；Project Orchestrator 则负责把大型任务拆成里程碑，安排并行工作，处理任务依赖，为每一部分分配执行者。

第二类是完成任务。

Explorer 只负责调查代码库、追踪调用关系和评估方案，不能修改源文件。Worker 才拥有文件和终端工具，负责真正的开发、重构和测试。

第三类是证明任务真的完成了。

Critic 检查逻辑、接口和代码质量；Challenger 主动寻找极端输入和失败路径；Auditor 核验测试是否真实运行，防止 Agent 跳过测试、伪造输出或者只搭建一个表面可用的空壳。

最后还有一个没有参与前面开发过程的 Success Auditor，负责完整的端到端检查。只有它确认结果满足要求，系统才会把结果交还给用户。

这些角色的名字并不是重点。

真正重要的是，Teamwork 把三件事分开了：

谁负责安排任务。

谁负责完成任务。

谁负责证明任务已经完成。

只要这三种责任仍然集中在同一个 Agent 身上，多 Agent 系统就很容易变成一场角色扮演。

Agent 团队的“记忆”，不应该只存在于聊天记录里

Teamwork 还有一个容易被忽视的设计：它不依靠某个 Agent 记住全部事情。

系统会保存三类核心产物。

第一类记录用户最初的目标、限制条件和验收标准。

第二类记录里程碑、任务依赖、当前工作流和任务分配。

第三类记录每个阶段的进度、执行命令、测试结果、审查意见和失败原因。

Agent 之间交接任务时，读取的是这些结构化产物，而不是简单翻阅前一个 Agent 留下的长对话。

这看起来只是一个工程细节，实际上决定了多 Agent 能不能处理真正的长任务。

聊天记录适合交流，但不适合充当项目状态。

一个长期任务至少需要区分：

什么是原始需求。

什么是当前计划。

什么已经完成。

什么仍然失败。

哪些结论已经被验证。

哪些只是某个 Agent 的猜测。

当这些信息全部混在自然语言对话中，后续 Agent 很难稳定地恢复任务状态。

Teamwork 的产物机制，更像人类团队使用的需求文档、项目计划、进度记录和验收报告。

它们不是为了写得好看，而是为了让一项工作在更换执行者以后仍然能够继续。

Teamwork 还为不同 Agent 分配独立工作目录，并通过文件所有权减少多个 Worker 同时修改同一文件造成的冲突。命令、状态变化、审查意见和验证日志也会被记录下来，方便用户查看任务究竟是怎样完成的。

因此，Agent 团队并不是多个模型同时出现在一个聊天窗口里。

它至少还需要外部状态、工作边界和证据记录。

没有这些基础设施，所谓 Agent 协作很容易退化成多轮讨论。

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 数量。

而是从一开始就把执行和验收分开，把状态放到对话之外，把证据作为交付的一部分。

Google Teamwork 还没有证明，一支 AI 团队可以替代一个真实组织。

它目前仍是 Antigravity 中面向软件工程、系统模拟和研究任务的预览能力，公开案例也主要集中在能够被测试、对照或形式化验证的领域。

但它已经说明了一件事。

当 Agent 开始承担数小时甚至数天的任务，限制它的就不再只有模型能力。

一群 Agent 怎样分工，怎样保留状态，怎样相互质疑，怎样提交证据，怎样接受人类验收，会和模型本身一样重要。

Agent 的下一道分水岭，不是谁能同时启动更多模型，而是谁能把一群不完全可靠的 Agent，组织成一支能够可靠交付的团队。

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业