Antigravity 展示研究进展，验收标准比智能体数量更重要

2026 年 11 月 13 日，Google Research 公布了 Antigravity /teamwork 的新研究与工程成果，强调人工协作，以及证明检查器、未经修改的测试集等外部检验方式。这些是开发者公布的结果，并非我们独立复现的结论。Google Research 原文

这也不是产品首次发布：Google 在 8 月 27 日的文章中已经介绍过预览版本。此前公告 此时更值得讨论的，不是能够安排多少个智能体同时工作，而是一个团队凭什么接受它们生成的成果。以下是 Open Market Notes 对这一问题的分析，不代表我们掌握了未公开的产品实现。

答案需要自身之外的判定标准

一份逻辑连贯、解释充分的方案，可以降低理解难度，却不能因此成为正确方案。增加一个负责批评的智能体，可能发现原先遗漏的问题；但生成者之间达成一致，并不等于问题已经解决。多个评审也可能沿用同一项未经检查的假设。独立验收程序的重要性，在于它有能力否定一份在对话中仍然很有说服力的成果。

以一个假设的内部数据处理服务改写项目为例。正常输入得到相同输出只是基本条件，业务还可能要求异常输入处理稳定、内存占用可控，以及与下游系统兼容。一个在常见工作负载上运行更快的版本，可能违反其中一项约束。如果团队仅凭最显眼的基准成绩宣布成功，实际完成的就可能是一个被简化过的任务，而非最初委托的任务。

因此，验收条件应当属于任务本身，而不是在成果出现后补写的说明。一份有用的记录需要把被测试的具体版本、执行环境、判定条件和未覆盖范围联系起来。否则，“测试通过”的状态可能对应旧版本，而最终交付的已经是另一个文件。评审看到的结论与接收者拿到的成果不一致，即使没有任何人故意夸大，也会产生不可靠的交接。

形式化检验并不负责选择问题

Lean 的文档区分了“证明有效”与“被证明的命题是什么意思”，也介绍了将候选证明与另行信任的命题进行比较的方式。Lean 文档

这一区分有助于理解令人印象深刻的演示。解决形式化问题，与确定一个值得解决且表达准确的形式化问题，是两项不同的贡献。假设某个团队将可靠性定义为“在清洁数据集上顺利完成”，那么满足这个定义的证明或测试，并不能自动回答数据缺失时会发生什么，除非这些情况已经包含在约束之内。这不是否定形式化方法，而是要求说明业务需求与形式条件之间的对应关系。

对企业而言，批准任务定义的人不必亲自执行每一次实验，但必须有人对定义是否符合实际需求负责。将执行交给智能体，不会取消这项责任，只会改变人工工作的集中位置。特别是在不同部门共同使用结果时，技术团队理解的“完成”，未必包含运营团队关心的例外处理。越早把差异写清楚，越容易判断后来获得的证据究竟能支持什么。

更多尝试也需要停止条件

并行探索能够形成更多备选路径，其中可能包括单个执行者不会尝试的方案。不过，成本不只有模型调用。比较输出、调查相互矛盾的证据、维护测试环境，同样需要资源。一大批看起来都合理的答案，未必比少量具有明确否定理由的候选方案更有价值。后者至少能帮助团队知道哪些方向已经被检查过，哪些仍然只是猜想。

一个有用的评价角度，是在总成本中计入复核和失败尝试，再比较真正获准采用的工作。这是本文提出的分析方法，不是 Google 公布的指标。它能避免把系统持续运行的时间直接等同于客户节省的时间。运行越久，也不必然意味着更接近有效结果；如果验收程序无法区分改进与重复，新增计算可能只是增加待审材料。

团队还需要知道何时停止：目标已经达到，预算已经用尽，或者新证据说明原任务应当调整。为了获得一个成功结果而悄悄降低门槛，会使前后比较失去意义。合理修改任务当然可以发生，但修改的原因与时间应当保留下来，不能把新标准下的结果包装成对旧标准的满足。

最终检验不能完全变成探索过程的一部分

另一个问题出现在候选方案反复接收同一组测试的详细反馈时。它们可能越来越擅长这一组测试，却没有改善更广泛的任务。对于前述假设的改写项目，开发用例可以指导迭代，另行维护的一组用例则用于最终验收。这是本文提出的防护思路，并非对 Google 实现方式的描述。其目的，是保留一部分尚未被探索过程反复优化过的信息。

这种分离也有成本：保留的用例较难直接用于诊断，任何有限的测试集也不可能覆盖所有运行故障。因此，它不是普遍可靠的保证。团队需要区分发现失败与最终决定，让评估规则处于候选方案的修改权限之外，并调查异常显著的进步，而非自动奖励更漂亮的成绩。测试变简单而得到的改善，不等于实现本身变好了。

对多智能体研究，乐观解释是：在稀缺专家介入前，可以完成更多探索。谨慎解释则是：问题定义与复核可能成为新的限制因素。这两种判断并不矛盾。一个系统可以提高探索效率，同时使验收流程的质量更加重要。

11 月的更新值得作为开发者对研究进展的说明加以关注，但它不能确立适用于所有任务的成功率、客户总成本或部署成熟度。更实际的采用问题，是某个具体团队能否定义、保存并独立执行足够好的验收标准。在做到这一点之前，新增的智能体活动应被视为调查过程，而不是已经完成的业务结果。