Google重磅发布Teamwork，最新的多智能体研究！

多智能体不是简单把任务分给几个 Agent 就行，怎么让它们协作而不是互相强化错误，是个更难的问题。Google 最近开源的 Teamwork 框架给了个答案，它在数学、硬件仿真、开源优化这些前沿领域都有实测成果，我看了它的设计思路，觉得对做 Agent 的人挺有启发。

这篇文章主要拆解它的设计原理，看看它到底怎么解决多智能体协作的问题。

原文链接：https://antigravity.google/blog/teamwork-when-ai-becomes-a-research-partner

一、问多 Agent 难的不在分工，而在组织

常规任务用基础多智能体方法通常够用，但碰到困难的研究和工程问题，麻烦就来了。松散组织的 Agent 很快会偏离轨道，一个 Agent 早期犯的错，其他 Agent 会跟着认同，然后在有缺陷的想法上继续构建。

核心矛盾不是"用几个 Agent"，而是"怎么组织它们"。Anthropic 之前做过一个实验，对比了协调 swarm 和独立并行 agents 在找软件漏洞上的效果。结果显示，协调 swarm 能找到更多漏洞，而且这种差距在复杂任务上更明显。

这说明松散组织的 Agent 会偏离轨道，是多 Agent 系统的通病。Teamwork 解决的问题是：让多个 Agent 在数小时甚至数天里，互相挑战对方的工作，在进一步构建前先找缺陷，把最强的部分组合成可用的解决方案。

二、Teamwork 如何让 Agent 互相纠错？

Teamwork 把很多研究和工程问题通用的结构变得具体且可配置：生成候选方案、压力测试、把最佳想法组合成更强的方案。围绕这个循环，它做了三个关键设计。

从生成方案到测试、组合，再进入下一轮

这个循环是 Teamwork 的基础。不是简单的任务分发，而是让候选方案经过测试后，把好的想法提取出来，形成更强的下一轮候选。人类负责定目标和做最终验收，Agent 负责执行整个迭代过程。

把协作模式和 Agent 本身分开

模式是规格，不是可执行程序。它不包含编排代码，框架读取模式后自动启动合适的 Agent。这样专门的机制（比如对抗性批评循环）可以跨领域移植，不用改代码。

这个设计的价值在于：协作逻辑和每个 Agent 具体干什么分开了，你写好的编排策略可以复用到完全不同的领域。

团队规模不预设，边做边调整

框架根据任务需求动态决定生成多少 Agent，不是预设数字。Agent 数量和团队结构可以在运行过程中随着问题的展现而改变。每次任务执行是一个活的过程，不是固定管道。

这个设计解决了一个常见问题：很多框架要求你事先想好要用几个 Agent，但复杂问题的结构往往在做的过程中才清晰。

三、五种问题，需要五种不同的协作方式

不同问题需要不同的协作方式。问题的结构决定了该怎么组织 Agent，Teamwork 针对不同类别的问题提供了专门模式。

不可拆的任务，在测试中反复迭代

有些问题没法拆成独立子任务，需要反复试错和精炼。这个模式通过紧密的 Agent-测试-精炼循环逐步改进，每个测试结果直接反馈给下一轮修改。

能拆开的任务，交给多个 Agent 并行推进

对于能拆成多个独立部分的工程任务，这个模式把工作扇出到多个并行工作者，同时安排批评者审查每个工作者的产出。

编排器根据问题决定部署多少 Agent、跑多少轮，核心角色固定，但执行规模动态调整。

数学开放问题，让不同路线先接受挑战

数学和理论计算机科学的开放问题有个特点：很多有希望的方法最终会失败，而且缺陷往往要到深入尝试后才可见。这个模式让每个候选方案在推进前必须经过压力测试。

每走一步，都先验证这一步是否成立

深度优先的数学推理需要在每一步都严格自检，这个模式把验证嵌入到推理过程中，而不是等完整答案出来后再检查。

审查论文，用固定维度组织批评意见

对论文和技术文档的审查需要结构化的分析，这个模式用固定的审查维度来组织 Agent 的批评意见。

四、失败的证明路线，也能留下有用的东西

长证明模式值得单独拆解，因为它处理的是最难的开放问题。它的设计不只是"生成然后验证"，而是一个完整的"生成、对抗、综合、学习"循环。

给每个候选方案安排一个专门的反驳者

多个候选策略并行生成，每个策略配一个伪造者，伪造者的唯一工作是打破这个策略。综合树把候选策略和它们的报告组合起来。

被驳倒的路线留在过程中，附带反对意见。一个破碎的路线可能仍包含有用的想法，这是这个设计的关键洞察。

把长证明拆成带依赖关系的子问题

选定的策略扩展成证明计划，子问题有明确的目标和显式的依赖关系。依赖图让独立子问题并行运行，依赖子问题按拓扑顺序执行。

这样长证明被拆成可管理的部分，同时保持整体逻辑的连贯。

让不同方案在锦标赛中逐层合成

在综合树中，每个节点读取候选样本及其批评，产生改进的解决方案。如果综合解决方案失败，网络会用累积的反对意见重新运行。

JOTO 企业落地观察

• Teamwork 提出的“生成-测试-组合”闭环，对企业部署多智能体系统意味着需重构传统流水线式编排思维，转向以质量门禁和持续反馈为核心的动态协作流程。
• 其“协作模式与Agent解耦”设计，使企业可在不重写Agent能力的前提下，快速适配新业务场景的协作逻辑，显著降低智能体工程中的模式迁移成本。
• 动态团队规模机制表明，面向真实复杂任务的RAG知识工程不应预设固定检索路径，而应允许系统依据查询难度与上下文冲突度自主伸缩检索粒度与验证深度。
• 将失败路线及其反对意见作为中间产物保留，为企业AI安全治理提供了新思路：对抗性反馈本身即构成可审计的决策证据链，而非仅用于修正最终输出。