（来源：Datawhale Datawhale）

 Datawhale干货 

谷歌最新：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 的批评意见。

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

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

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

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

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

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

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

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

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

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

这个机制让失败变成有用的信息，而不是简单丢弃。

这一轮踩过的坑，下一轮不再重来

失败的草稿保留给下一次尝试。验证者的发现提炼成答案无关的陷阱注册表，记录常见错误模式。共享知识目录保存已证明的结果、失败的方法、相关参考。

这些经验积累让后续尝试不会重复踩坑。

五、对做 Agent 的人的启发

Teamwork 的设计原理有几点值得借鉴。

多智能体的核心是编排逻辑

不是简单分任务，而是要设计好压力测试机制、结果综合策略、跨轮学习机制。松散组织的 Agent 会互相强化错误，这点在官方文档里也反复强调。

一套协作模式，可以迁移到不同领域

编排逻辑和 Agent 描述解耦后，你写的协作策略可以移植到不同领域。这个设计思路不只适用于 Teamwork，做自己的多智能体系统时也值得考虑。

不要提前锁死 Agent 数量

不要预设固定的团队结构，让 Agent 数量和组织方式根据问题的展现动态调整。复杂问题的结构往往在做之前无法完全预见。

必须有人专门提出反对意见

Anthropic 的研究还发现了一个值得注意的问题：当多个 Agent 面对相同情况时，会表现出比人类更高的相似性。一个 Agent 的错误决策会被其他 Agent 复制，形成系统性失败。

Teamwork 的设计（如伪造者机制、批评循环）正是为了对抗这种从众效应，让每个候选方案在推进前都要经过独立的压力测试。

小模型配上好编排，也能解决高难度问题

用日常开发用的 Flash 级模型配上精心设计的编排逻辑，能在复杂问题上解锁强劲性能。TCSBench 71% 的得分里，有三个结果是 Flash-tier 模型首次产生博士级别的数学研究。

不一定非要用最大的模型，关键是编排逻辑的质量。

写在最后

看完 Teamwork 的设计原理，我的感受是：多智能体的未来不在于堆更大的模型，而在于怎么设计好协作机制。它把生成、测试、组合、学习这个循环做得足够细，让小模型也能在前沿问题上发挥作用。

对正在做 Agent 系统的人来说，最值得参考的是它的三个设计决策：编排逻辑和 Agent 描述解耦、运行时自适应、把失败当成有用信息。这些思路不只适用于多智能体，单 Agent 系统里也能用。

Anthropic 的多 Agent 研究则提醒我们，多 Agent 协作还有隐性问题，比如从众效应。设计编排机制时，需要特别考虑如何避免 Agent 之间互相强化错误。

如果要深入学它的机制，建议重点看长证明模式的锦标赛网络设计。这个模式处理的是最难的开放问题，它的策略搜索、分解、跨轮学习机制，对理解怎么让多个 Agent 真正协作有很大帮助。