Google 在其开发环境 Antigravity 中新增了一个名为 /boost 的命令。调用它会启动一个多智能体推理流水线，而不是单个编程助手：编排器读取问题并将其拆分为任务，分派给在隔离范围内工作的专门智能体，然后让结果经过独立的验证轮次，这些轮次会在任何内容到达您之前真正运行测试。真正的重点不是 AI 写代码更快了，而是编程工具已经开始把验证内置到工具本身之中。

Google 实际宣布了什么

根据 Antigravity 官方文档，/boost 专为高难度软件工程而设计：并发缺陷和竞态条件、算法优化、时隐时现的细微回归，以及跨多个文件的复杂重构。这些恰恰是传统单轮助手会失败的问题，因为解决它们需要实验和回溯，而不是直接生成。

该命令分三个清晰的阶段运行：

  • 规划：主编排器接收您的提示词，检查工作区上下文，制定执行策略，并将挑战拆解为离散的、可验证的子任务。
  • 分布式执行：编排器将这些子任务分派给专门的智能体。实现工作流编写代码和单元测试。调查工作流进行根因调试并追踪调用图，不修改任何文件。本地验证智能体运行构建目标和测试套件，在汇报之前验证假设。
  • 交付前验证：编排器汇总发现，并针对完整的测试套件和边界情况运行回归检查。如果某个断言失败，错误诊断会输入下一次迭代以进行自动修正，只有在全部通过后，您才会收到已验证更改的摘要。

所有这些都在临时的、隔离的 worktree 中运行，这意味着智能体不会在您的项目工作副本上做实验。

三种模式，而不是一种

Google 记录了三种不同的执行模式，而它们之间的差异才是实际有用的部分：

  • 默认智能体：交互式编程、代码库导航和一般重构。任务时长从几秒到几分钟，单智能体循环，单次验证。所有方案均可使用。
  • /boost：深度推理和顽固缺陷。任务时长从几秒到几小时，三阶段层级结构，多轮独立验证。付费方案可用。
  • /teamwork-preview：智能体团队连续数天处理大型迁移或整个子系统的构建，设有 Explorer、Worker、Critic 和 Auditor 等命名角色，并设有验证关卡，在里程碑获批之前刻意尝试破坏代码。

注意其中的梯度：任务越大，投入就越多地流向审查而不是速度。对于任何负责软件项目的人来说，这都是一个值得关注的信号。

为什么这对企业主很重要，而不仅仅是对开发者

过去两年里，关于 AI 编程的讨论一直是关于速度的讨论：每分钟能生成多少行代码。问题在于，在真实项目中，速度并不是瓶颈。信任才是。这段代码在没人测试过的情况下真的能正常工作吗？

/boost 的架构隐含表明，业界也得出了同样的结论。如果交付后要花两周时间调试，那么更快到来的代码一文不值。因此，这个工具围绕三条规则构建，这些规则适用于任何技术团队，无论是否使用 AI：

  • 作者不能给自己的工作打分：负责验证的一方与负责实现的一方是分开的。几十年来，这一直是代码审查背后的原则。现在它在工具内部被强制执行。
  • 证据意味着执行，而不是声明：测试被真正运行，并检查其真实输出，而不是接受"测试已通过"的说法。
  • 隔离保护原件：实验在单独的副本中进行，因此失败的尝试永远不会泄漏到项目中。

如果您在采购软件开发服务，这正是应该向供应商提出的三个问题：谁来审查，测试通过的证据是什么，实验在哪里进行？

什么没有改变

人们很容易把这样的新闻解读为不再需要工程师的宣告。文档却相当明确地说了相反的话：智能体继承为您的工作区配置的文件访问规则和命令权限策略，任何受保护的命令或可信范围之外的编辑都会向用户弹出授权请求。链条的末端始终有一个负责的人。

而权限只是较小的那一半。智能体解决的是您所描述的问题，它无法知道描述本身是错误的。它不知道您的计费周期在 25 日而不是 30 日结束，不知道某个字段绝不能让销售代表看到，也不知道当您的客户说"订单"时，他指的和您理解的是不同的东西。定义需求、理解业务领域并对决策负责，仍然完全是人的工作。

我们在 Origami 如何看待这一点

我们对待多智能体工具的方式与对待任何生产力工具相同：它们加速执行，但不转移责任。在我们这里，一个项目在上线生产之前，仍然要经过书面规格说明、人工审查、测试套件和预发布环境，无论代码是人写的还是智能体生成的。一个能运行自身测试的工具是这条链条上受欢迎的补充，但它只是其中的一环，而不是替代品。

给企业主的实际建议：预期交付周期会缩短，尤其是在复杂工作上，但不要接受没有测试、没有文档、没有人工负责人的交付。能够自我审查的工具提高了可达到的质量上限，但并不能免除您对这样一个人的需求：由他来保证所构建的正是您所要求的。

来源