Google Antigravity 中的 Claude：Opus 5.5 和 Sonnet 5.5 扩展企业模型选择

Google 已将 Claude Opus 5.5 和 Claude Sonnet 5.5 加入面向 Google Cloud 客户的 Antigravity，使 Anthropic 与 Gemini 一同进入企业开发工作流。Google Antigravity 中的 Claude 为开发者在 Google 的编码环境内提供了另一类模型选择，也让模型选择、支出以及生成工作成果的责任进入同一条决策路径。

最直接的益处在于实用性：团队可以评估不同模型，而不必将每一次比较都变成独立的工具项目。矛盾则存在于开发者选择权与企业管控之间。模型出现在菜单中，并不能解决谁有权批准其使用、用量如何计费，或哪个系统负责处理辅助任务等问题。

Anthropic 获得了另一条分发渠道，而即使客户选择竞争对手的模型，Google 仍保留开发者界面。对工程负责人而言，更有意义的问题是这种安排是否能改善已完成工作的质量。可用性开启了比较；可靠的代码、可控的审查工作量和可理解的支出，决定其价值。

Google Antigravity 中的 Claude 扩展企业模型菜单

已得到验证的变化是，Anthropic 最新的 Opus 和 Sonnet 模型现可在 Google 的企业开发环境中使用。 Google 的 Antigravity 模型公告指出，管理员授权是开发者进行选择的前提条件。

Google 列出了 Antigravity 2.0、其命令行界面，以及适用于 VS Code、JetBrains IntelliJ 和 Visual Studio 的扩展作为支持入口。命令行界面让开发者可以通过终端命令进行交互。IDE 扩展则将服务带入集成开发环境，即用于构建软件的编辑器及相关工具中。

这种覆盖范围很重要，因为开发团队很少只通过单一界面工作。调查构建失败的工程师可能偏好终端；修改应用行为的人则可能留在编辑器中。在这些环境中持续提供模型选项，可减少评估过程中的一项摩擦来源。

公告还列出了 Gemini 3.8 Flash 和 Gemini 4 Argon 等 Google 可用模型。这在开发工作流本身内形成了比较。开发者可以在继续使用 Antigravity 的同时，检验不同模型是否能更有效地处理特定问题。

这一范围需要谨慎理解。Google 的公告面向 Google Cloud 客户，企业访问权限取决于组织设置。它不应被解读为承诺每个 Antigravity 账户都能获得相同的可用性、限制或商业条件。

访问权限与采用之间也存在差异。新启用的模型可能始终无人使用，可能成为专用选项，也可能成为团队的常规起点。公告确立了第一个条件，却没有提供有关其他情形的证据。

以一个说明性的维护任务为例：工程师需要修改一项验证规则，并更新相关测试。团队可以让不同模型处理相同要求进行比较。真正有意义的结果在于，每项建议的修改是否既保留现有行为，又满足新规则。

另一项迁移任务则提出不同要求。工程师必须识别依赖关系、安排变更顺序，并说明兼容性决策。验证修复任务中的成功，并不能证明其能胜任这一更广泛的工作。

这种差异赋予此次发布实际意义。Antigravity 现在提供了另一种在既有环境中比较任务适配度的方式。其价值来自于让这些比较足以影响工程决策。

对采购方而言，这比泛泛承诺模型选择权更具体。新增选项必须有助于回答一个运营问题：在这个代码仓库中、在这个团队的约束下，哪种模型能够产出可接受的工作成果？

工程负责人承担模型选择决策

更多选择会将责任转移给那些批准、资助和审查 AI 辅助开发的团队。 Google 的集成为工程负责人提供了另一项可评估的选择，也使仅凭熟悉程度来为默认模型辩护变得更困难。

开发者偏好具有参考价值，但只是决策的一部分。响应速度快的模型仍可能生成需要大量审查的修改。另一个模型可能清晰说明其推理，却忽略隐藏在内部文档中的某项要求。

压力首先落在维护共享开发工具和实践的平台工程团队身上。他们需要为启用额外提供商建立可辩护的依据。这个依据应将模型访问与实际工作联系起来，而不是把更长的模型列表当作成果。

安全审查人员面临相关决策。他们需要了解请求中包含哪些信息，以及由哪项服务处理。熟悉的界面可能让新提供商显得稀松平常，即使组织仍需要审查这项安排。

工程经理必须评估其对交付的影响。更快的生成只有在缩短产出可接受修改所需时间时才有帮助。如果审查者花费更长时间发现错误，表面上的速度优势就会变得不那么有用。

财务团队还有另一项关切：用量是否可以关联到可识别的活动。与迁移工作相关的账单，与开发项目中无法解释的消耗，具有不同的解读方式。可见性有助于围绕价值开展有效讨论。

这些责任彼此重叠，但不应被压缩为一个单一的批准复选框。某个提供商可以满足组织的数据要求，却在其代码产出上表现不佳。技术能力强的模型也可能难以纳入预算。

对于已经使用 Antigravity 的团队，Claude Opus 5.5 和 Sonnet 5.5 提供了重新审视既有假设的机会。相关比较应包括 Gemini 以及团队当前的开发流程，也应包括审查和纠正每项结果所需的工作量。

因此，评估需要具有代表性的任务。具有严格兼容性要求的代码仓库，与实验性应用面临不同挑战。模型能够写出看似合理的代码，并不能说明它会遵守这些本地约束。

组织层面的影响还延伸至文档。如果一位工程师发现了有用的模型选择方案，这些知识需要在聊天会话之外持续保留。可搜索的工程知识库可以保存需求、评估记录和已采纳的决策。

结果是采购逻辑的变化。团队可以将开发环境及其可用模型视为相互关联的决策进行评估。如果 Google 的环境让这些决策更容易被共同管理，它就会更具吸引力。

Opus 和 Sonnet 面向不同类型的工程工作

Opus 与 Sonnet 之间有价值的比较，涉及任务形态、审查负担和判断能力。 它们的名称界定了产品系列，却无法决定特定工程团队应接受哪一种结果。

Anthropic 将 Opus 定位于需要持续判断的复杂工作。其 Opus 5.5 能力公告称，它在高要求编码任务中有所改进。这些仍属于供应商主张和示例，并非对 Antigravity 客户代码仓库表现的保证。

Anthropic 将 Sonnet 描述为更明确边界工作的一种补充。其 Sonnet 5.5 能力公告强调日常任务和迭代。该公司也提醒，基准测试结果只能反映能力的一部分。

这种区别支持一个合理的评估假设。定义清晰的缺陷修复可以测试模型是否遵循狭窄的要求，而不会引入无关修改。开放式迁移则可以测试它是否识别缺失信息并作出可辩护的权衡。

这些是假设，值得检验，而不是每个团队都应自动采用的任务分配。小改动可能包含困难的兼容性陷阱。大改动也可能主要由具有明确验收标准的重复编辑构成。

开发者对任务的描述同样会影响比较。精确的需求让模型需要解决的不确定性更少。不完整的简报则迫使它推断意图、提出问题，或基于假设继续执行。

因此，有价值的比较应保留相同的起始材料。每个模型都应获得相关需求和代码仓库上下文。否则，准备工作上的差异可能会被误认为能力差异。

审查应同时检查生成的修改和解释。看似有说服力的总结可能掩盖不完整的实现。简短的回答也可能伴随几乎无需修改的正确工作。任何一种写作风格都不能决定工程结果。

Claude Opus 5.5 和 Sonnet 5.5 还引出了升级决策。团队可能先使用适合边界明确任务的模型，并在不确定性增加时切换。只有当开发者能够识别触发条件时，这种策略才有用。

一个说明性的触发条件是应用组件之间存在相互冲突的需求。另一个是建议的修复改变了所报告缺陷之外的行为。在两种情况下，问题都是尚未解决的判断，而不是生成答案的篇幅。

Gemini 仍是同一环境中的竞争选项。它的存在让团队可以检验，在可比条件下，不同模型系列是否能取得更好的结果。这项集成并未确立一个普遍的赢家。

更广泛的含义是，模型选择可以成为工程实践的一部分。团队已会根据风险选择测试工具和审查方法。根据工作内容选择模型，引入了另一类同样的决策。

这种方法需要纪律。没有记录的结果，基于任务的选择可能会沦为个人偏好的集合。有了证据，它就能成为一种可重复的方法，用于分配困难工作并避免不必要的投入。

一个界面仍包含多种模型和计费路径

共享界面简化了访问，但底层执行和计费安排仍需要关注。 这是将这项集成理解为单一、统一服务时最明确的限制。

Google 的企业模型设置区分合作伙伴模型消耗与包含在内的 Gemini 额度。文档称，第三方使用量将通过组织的 Cloud Billing 账户按消耗量计费。

这种区别会影响采购方对现有承诺的理解。组织不应假定启用 Claude 会消耗与其包含的 Gemini 用量相同的额度。采购决策需要考虑实际的计费路径。

执行并不只由所选的推理模型构成，负责理解任务并决定如何执行的模型亦然。Google 的 混合执行架构 文档将主要工作交给 Claude，同时保留 Gemini 负责后台协调。

其实际含义比“供应商独立性”的说法更为有限。开发者是在 Google 管理的环境中选择一个主模型。工作流仍可能涉及通过该环境运行的辅助模型。

这种安排可能很有用。开发者通常希望上下文处理和协调能够顺畅运作，而无需管理每一个辅助组件。不过，企业采购方需要足够的可见性，才能了解系统正在做什么。

仅凭模型标签无法回答所有运营问题。团队需要了解一次会话的活动如何与用量记录和审查证据关联。否则，他们可能会基于不完整的工作图景进行评估。

例如，看似高效的一次编程会话，可能涉及大量辅助活动。所选模型的输出只能反映其中一部分。要理解整体消耗，必须审视工作流，而不能只看最终回复。

同样的推理也适用于责任归因。当生成的代码出现故障时，团队需要区分是需求被误解、上下文缺失，还是执行出了问题。这些原因需要采取不同的纠正措施。

需求被误解，意味着需要更好地界定任务，或选择不同的模型。上下文缺失表明准备工作存在问题。执行失败则意味着应检查权限、工具或周边环境。

将所有失败都视为模型失败，会掩盖这些差异；将每一次失败都归咎于用户错误，同样没有帮助。一个有用的企业集成方案，应让相关证据足够易于获取，从而支持调查。

这正是开发者便利性与企业治理的交汇点。便利性降低了尝试另一种模型所需的成本。治理则决定组织能否理解并管理由此产生的活动。

因此，Google Antigravity 中的 Claude 代表了既有平台内的一项受管理选择。采购方应在评估模型编程结果的同时，评估该平台的协调与核算能力。两者共同构成的体验，决定了这一新增选项是否实用。

跨模型审查可增加审视力度，但不能证明正确性

第二个模型可以质疑一项实现，但模型之间达成一致，并不能证明软件满足其需求。 这是对 Google 所建议跨模型审查模式的核心限定。

Google 描述了由一个模型实施变更、另一个模型进行审查的方式。这个提议可以理解：独立的模型可能以不同倾向处理工作。但该公告并未证明这种方式能为客户项目带来经过量化的可靠性提升。

不同视角与独立验证之间的区别至关重要。两个模型都可能收到同一份不完整的任务说明，都可能遗漏未记录的兼容性要求。它们的结论可能一致，仅仅是因为任务描述缺少同一个关键事实。

因此，有效的审查者需要的不只是实施者的说明。它还需要原始需求、实际变更，以及与行为相关的证据。否则，它可能是在评判关于实现的叙述，而非实现本身。

以一个说明性迁移为例：它改变应用存储日期的方式。该实现可能在内部看起来逻辑一致，却改变了既有记录的行为。只关注新代码的审查者可能会接受它。

真正相关的问题是，这项迁移是否保留了既有数据原本应有的含义。这需要明确的需求，以及覆盖受影响行为的测试。再自信的模型回复，也无法补足缺失的产品意图。

跨模型审查仍可帮助识别值得调查的问题。它可以标记假设、指出缺失的测试，或提示被忽略的失败条件。其价值取决于这些发现是否具体且有用。

审查流程还需要一种拒绝薄弱异议的方式。模型可能提出并不适用于该应用的假设性问题。调查每一项推测性担忧只会增加工作量，却未必改善变更。

有用的标准是证据。审查者应将异议与需求、代码路径或可复现的失败关联起来。随后，人类审查者便可判断该担忧是否值得修正。

这也带来了比较模型时的另一项考量：它们提出可执行批评的能力。更长的审查不一定更好。一项与实际缺陷相关联的简短发现，可能更有价值。

重复交接也有成本。每次审查都会增加活动量，并要求下一位参与者理解任务。这些额外投入必须产生足够有价值的审视，才能证明其合理性。

对于某些任务，常规测试和人工审查仍然足够。对于另一些任务，第二个模型的批评可能发现值得解决的问题。该集成让试验更容易，但并未免除评估结果的必要性。

同样的谨慎也适用于模型专业化。将边界明确的任务分配给一个模型、将需要大量判断的任务交给另一个模型，听起来很合理。实际收益取决于这些边界在实践中是否成立。

工程结果应始终是核心。被接受的变更、发现的缺陷、审查者投入以及后续修正，比模型之间的一致性提供更有用的证据。这一标准可避免一个看似吸引人的工作流模式，变成缺乏依据的可靠性主张。

接下来关注采用情况、被接受的工作与运营可见性

下一批有价值的证据，将显示团队如何使用这些新选项，以及它们产出的工作结果如何。 该公告确认了可用性。其更广泛的意义取决于公告尚未证明的结果。

第一个信号是管理员启用访问权限后，是否出现持续使用。偶尔的试验能说明兴趣，但在常规项目中的反复使用，才表明更强的契合度。公开的客户案例应区分试验与持续的开发工作。

使用模式与使用本身同样重要。若 Opus 成为迁移任务的专业选项，其含义不同于 Sonnet 成为维护工作的常用选择。这两种结果都比笼统的采用主张更具信息价值。

放弃使用的证据同样重要。团队可能因为结果不佳、审查开销或运营摩擦而停止使用某个选项。缺少这些背景时，单独的使用数据无法说明原因。

第二个信号是关于被接受工作的证据。有价值的客户报告应将模型使用与通过审查、满足需求的变更联系起来。它也应描述修正与失败，而不只是展示令人印象深刻的演示。

可信的案例应说明任务、起始条件和验收标准。这样的背景让读者能够判断结果是否适用于自己的工作。缺少这些细节的成功故事，指导价值有限。

比较还应认识到代码库之间的差异。一个能很好处理熟悉框架的模型，可能会在内部约定上遇到困难。当发布者描述这些限制条件时，证据会变得更有价值。

如果团队记录了通过有意选择模型而取得的更好结果，这一信号将增强多模型开发的理由。如果切换模型主要只是增加活动量，却没有改善被接受的工作，则会削弱这一理由。

第三个信号是整个会话的运营可见性。采购方需要能够帮助他们关联所选模型、辅助活动和消耗情况的报告。更清晰的证据会使这种企业安排更容易评估和管理。

可见性也支持技术决策。如果某一工作流反复需要大量审查与修正，团队可以调查原因。他们可以根据比偏好更具体的依据，调整任务、模型或流程。

这些信号应结合解读。没有可接受结果的持续使用，是价值薄弱的证据。孤立演示中的强劲结果，对于常规采用几乎没有说明力。易于理解的运营情况，让两者都更容易评估。

对 Google 而言，机会在于让 Antigravity 成为比较和协调模型的有用场所。对 Anthropic 而言，机会在于在另一家公司的开发环境中赢得持续性工作。这两种结果都不会因集成而自动发生。

对开发者而言，更切近的实际机会在于，他们可以针对自己已经了解的工作，评估另一个模型系列。该比较应保留需求，并以一致的方式评判由此产生的变更。

在团队范围内扩展使用 Google Antigravity 中的 Claude 之前，选择一个验收标准明确的真实任务。记录模型接收了什么、它做了哪些变更，以及审查者修正了什么。将结果与现有方法比较，包括达到可接受结果所需的投入。将需求和评估记录保存在团队日后可以检索的地方。当证据发生变化时重新审视这一选择，尤其是在模型对维护工作和开放式工作表现不同时。带入下一次评估的问题应当具体：哪种组合能帮助团队以最少的不必要工作，交付正确且可审查的变更？