Google Cloud提出跨模型互审与子代理分层两种agent工程模式
Google Cloud在Antigravity中引入Claude Opus 5.5和Sonnet 5.5后，给出了两种多模型工作流模式：用不同模型家族分别做实现和验证以规避同模型盲区，以及将高频机械任务分配给Flash级子代理以降低延迟和费用。模式附有具体配置示例，但均为厂商自述，未经独立验证。
在同一个agent框架里同时接入多个模型家族，能解锁两类实际工程模式。Google Cloud在将Claude Opus 5.5和Sonnet 5.5引入Antigravity时，给出了这两种模式的具体配置方式。
第一种是跨模型验证。当agent循环或多步图工作流中由同一个模型既写代码又审自己的输出时，该模型特有的盲区可能因此被强化。Google Cloud建议让一个模型家族负责规划和实现，另一个模型家族在提交前对实现结果做独立审查。在Antigravity中，这可以通过交互式切换模型或在CLI中调用一次性的/model检查来实现，也可以通过自动化的子代理完成。
第二种是将推理模型与Flash级子代理配对。复杂工程任务通常包含少量高推理决策和大量高频机械操作——搜索文件、grep日志、检查lint输出、分类测试失败。如果在前沿模型上运行每一次查找，延迟和花费都可能上升。Antigravity的子代理定制系统允许在.agents/agents/*.md文件中为专门子代理指定模型层级：inherit表示继承当前会话模型用于深度推理，flash表示将高速搜索、分类和分诊工作卸载给Gemini Flash模型。
Google Cloud给出了一个具体示例：在.agents/agents/test-triager.md中定义一个运行单元测试、按根因分类失败并返回结构化摘要给父代理的Flash子代理；在.agents/agents/gemini-judge.md中定义一个用Gemini Pro审查当前工作区diff、检查回归和边界用例的pro级子代理。这样，快速测试和分类循环交给test-triager，最终diff的验证交给cross-model-judge。
需要指出的是，这些模式来自Google Cloud自身的工程建议，文中没有提供独立基准测试或量化对比来证明跨模型验证确实减少了多少盲区、分层调用具体节省了多少延迟和费用。模式背后的机制论证——同模型自审强化盲区、前沿模型处理机械任务增加成本——在逻辑上合理，但实际收益取决于具体任务组合和团队工作流。