从「各自为战」到「协作交付」：多Agent系统的组织困境与Google Teamwork的解法

当「更多Agent」不再等于「更强系统」

过去一年，大语言模型驱动的Agent正在快速进化。它能调查代码库、修改文件、调用终端、运行测试，也能连续工作很长时间。然而，当任务从「帮我改一段代码」升级为「帮我完成一次跨数十个文件的系统迁移」时，问题就不再只是模型聪不聪明。

一个Agent既要规划、执行、检查，又要判断自己是否真正完成，很容易陷入一个根深蒂固的困境：它会不断证明自己的第一版方案是正确的。增加更多Agent也未必能解决根本问题。如果一群Agent缺少明确的分工和独立验证机制，它们往往会接受最早出现的错误，并围绕这个错误补充越来越多看似合理的细节。最终得到的不是更可靠的答案，而是一个被集体完善的错误。

Google在8月底发布的Antigravity Teamwork更新，正是在回应这个核心问题。它的定位是一个面向复杂长期任务的多Agent编排框架：不同Agent可以在数小时甚至数天内提出方案、相互批评、继续修正，共同完成研究与工程任务。这次更新真正值得关注的地方，不是某个新功能的上线，而是Google开始回答一个更难的问题：怎样把多个Agent组织成一支不会互相放大错误的团队？

多Agent系统的三大顽疾

错误放大与共识偏差

我们通常会直觉地认为，多一个Agent就多一个视角。但现实可能恰恰相反。如果多个Agent使用相近的模型、相似的上下文和同一套任务描述，它们很可能拥有相似的盲点。

第一个Agent提出一条错误路线，第二个Agent没有推翻它，而是在这条路线下增加一个实现方案；第三个Agent再根据已有内容补充测试和解释。参与者越来越多，错误反而显得越来越完整。这种现象被Google在官方文档中直接承认：松散组织的多Agent系统很容易跑偏，Agent会认同其他Agent早期出现的错误，并自信地在错误基础上继续推进。

自我验证的天然缺陷

让一个Agent同时承担开发方和验收方的角色，本质上相当于让施工方同时负责验收工作。它未必会故意作弊，但很容易选择最有利于证明自己正确的检查方式。当任务周期变长，大量代码、日志、工具返回结果和中间讨论不断涌入上下文，最初的约束逐渐被执行细节淹没。即使上下文窗口足够大，将所有信息放在一个对话里，也不代表模型能够始终正确判断哪些内容最重要。

状态管理的失控

聊天记录天然适合信息交流，但不适合充当项目状态记录。当这些信息全部混在自然语言对话中，后续Agent很难稳定地恢复任务状态。一个长期任务至少需要区分：什么是原始需求、什么是当前计划、什么已经完成、什么仍然失败、哪些结论已经被验证、哪些只是某个Agent的猜测。当这些边界模糊时，团队协作就会退化成多轮无意义的讨论。

Teamwork的核心思路：分工而非堆砌

Teamwork的设计哲学不是继续扩大上下文容量，而是把长任务拆成多个阶段，让Agent通过结构化产物进行交接，避免所有状态永远堆积在一段不断增长的对话中。

换句话说，多Agent系统真正缺少的不是更多「脑力」，而是分工、边界和交接机制。

三种责任的彻底分离

Teamwork把一项复杂任务拆成三种明确的责任：

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

第二类：完成任务。 Explorer只负责调查代码库、追踪调用关系和评估方案，不能修改源文件；Worker才拥有文件和终端工具，负责真正的开发、重构和测试。这种分离确保了调查与执行的专业性。

第三类：验证任务。 Critic检查逻辑、接口和代码质量；Challenger主动寻找极端输入和失败路径；Auditor核验测试是否真实运行，防止Agent跳过测试、伪造输出或只搭建一个表面可用的空壳。最后还有一个没有参与前面开发过程的Success Auditor，负责完整的端到端检查。

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

结构化产物的交接机制

Teamwork还有一个容易被忽视但至关重要的设计：它不依靠某个Agent记住全部事情。系统会保存三类核心产物。

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

Agent之间交接任务时，读取的是这些结构化产物，而不是简单翻阅前一个Agent留下的长对话。这看起来只是一个工程细节，实际上决定了多Agent能不能处理真正的长任务。这些产物更像是人类团队使用的需求文档、项目计划、进度记录和验收报告，它们不是为了写得好看，而是为了让一项工作在更换执行者以后仍然能够继续。

Pattern机制：可变的工作组织模板

传统工作流通常会提前写死步骤：先调查，再开发，然后测试，最后生成报告。这种方式适合稳定、重复的流程。但开放性的工程和研究任务，往往无法在开始时知道应该拆成多少部分、需要尝试多少条路线，也不知道哪条路线会在中途失败。

Teamwork为不同任务设计了不同的协作Pattern。Pattern不是一段写死的执行代码，而是一份团队蓝图：它定义哪些角色参与、各自承担什么责任，以及结果满足什么条件才能进入下一阶段。Gemini会根据任务自动选择合适的Pattern，执行过程中Agent数量和团队结构也可以继续变化。

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

被推翻的方案也不会被简单删除，其中的失败原因和可用想法会被保留下来，进入下一轮综合。这种机制确保了错误本身也成为一种知识积累。

从Google结果看适用边界

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

这三类结果最值得关注的共同特征是：它们都存在相对明确的外部验收方式。数学证明可以被专家或形式化工具检查，CPU模拟器可以与参考实现对照，开源代码必须通过外部维护者的审查。这说明Teamwork当前最适合的，是那些虽然执行路径开放、结果却能够被客观验证的任务。

Agent竞争的新分水岭

过去判断一个Agent强不强，主要看模型本身的能力：能不能推理、能不能调用工具、能不能处理长上下文、能不能生成代码。Teamwork把另一些问题推到了前台：目标是否能够被准确描述、长任务如何拆成可以交接的阶段、并行Agent如何避免相互冲突、错误方案由谁主动推翻、测试是否真实运行、过程是否留下可检查的证据、任务失败后能否保留状态继续推进、最终结果由谁接受。

这些问题单靠换一个更强的模型解决不了。它们需要的是Agent运行时、任务状态、工作空间、验证机制和人类验收的系统性设计。这也是Teamwork比「多开几个Agent」更重要的地方。它把人类团队里一些非常基础、却长期被Agent产品忽略的东西重新带了回来：

• 分工不能只有角色名称，还要有权限边界
• 协作不能只有消息传递，还要有状态交接
• 审查不能只是再问一次模型，要主动寻找失败证据
• 完成不能由执行者自己宣布，要经过独立验收

模型决定一个Agent能想到什么。组织机制决定一群Agent最终能不能把事情做完。

企业级Agent开发的关键原则

对于计划在企业场景中应用多Agent系统的团队，可以先验证一个最小版本。不需要一开始就搭建数十个Agent，选择一个范围明确、能够客观验收的任务，就可以验证多Agent协作的核心原则。

例如，一次跨多个文件的小型代码重构、一份需要多角度审查的技术方案，或者一个带有固定测试集的数据处理任务。实施步骤可以包括：首先由人写清楚目标、禁止事项和验收标准；然后设置一个编排Agent，负责拆分任务和安排依赖；设置两个执行Agent，分别负责调查和实施；再设置一个没有参与开发的验证Agent，负责运行真实测试、寻找失败案例并检查执行证据。

验证不通过时，不要只返回一句「存在问题」。它需要把失败输入、测试日志和具体原因交还给执行Agent，让下一轮修改能够从真实证据出发。最终交付的也不应该只有一份结果，还应该包括：任务实际完成了什么、运行过哪些检查、哪些失败已经修复、还有哪些不确定性需要人判断。

这里最重要的不是Agent数量，而是从一开始就把执行和验收分开，把状态放到对话之外，把证据作为交付的一部分。

写在最后

Google Teamwork还没有证明一支AI团队可以替代一个真实组织。它目前仍是面向软件工程、系统模拟和研究任务的预览能力，公开案例也主要集中在能够被测试、对照或形式化验证的领域。但它已经说明了一件事：当Agent开始承担数小时甚至数天的任务，限制它的就不再只有模型能力。

一群Agent怎样分工、怎样保留状态、怎样相互质疑、怎样提交证据、怎样接受人类验收，会和模型本身一样重要。Agent的下一道分水岭，不是谁能同时启动更多模型，而是谁能把一群不完全可靠的Agent，组织成一支能够可靠交付的团队。

对于企业AI落地而言，这意味着的关注点需要从单点能力进化转向系统设计。从Agent开发平台的工作流编排能力，到任务状态管理机制，再到独立的验证与验收体系，每一个环节都将决定最终交付的质量。当潮水退去，才能看清谁在真正建造系统，谁只是在堆砌模型。