当规划与执行走向分工，真正值得关注的不是系统中出现了几个模型，而是控制权如何在不同模型之间流动，任务状态又能否在交接中保持完整。 11月12日，谷歌发布Gemini 4 Hydrogen。如果只看响应速度与工具调用能力，它很容易被理解为Gemini 3.8 Flash之后的新一代高速模型。 这个理解并不错误，但并不完整。 官方开发者文档给出了双重定位：Hydrogen既能独立运行，也能与Gemini 4 Carbon、Gemini 4 Argon组成多模型工作流。它并非只能嵌入多模型链路，却在其中承担了一个十分清晰的角色，接收计划、修改代码、运行测试并核验结果。 因此，Hydrogen更值得讨论的不是它又快了多少，而是智能体系统中的执行环节开始被单独抽象出来。规划与执行逐渐被视为两种不同的计算负载，也开始拥有不同的模型配置与评价标准。 许多智能体系统采用单模型闭环。同一个模型既负责任务拆解、依赖分析与方案判断，也要完成文件修改、工具调用、测试重试和结果检查。 这两类工作对模型的要求并不一致。 规划需要理解全局约束，处理模糊信息，判断不同方案之间的长期影响。执行更强调指令遵循、局部修改、工具使用与异常恢复。前者关注方向是否正确，后者关注计划能否被稳定转化为结果。 从系统状态的角度看，规划更接近开放问题的求解，执行则是一系列受约束的状态转换。计划给出目标与边界，执行层通过工具和操作改变环境，再把结果反馈给规划层。 当同一个模型承担全部环节时，资源错配很容易出现。简单执行可能消耗过多推理，复杂判断也可能因为上下文被大量操作记录占据而逐渐偏离目标。执行层产生的文件内容、工具输出和测试日志，还会持续挤占规划所需的有效上下文。 将两类负载分开，首先是一种系统资源的重新组织，其次才是模型名称的变化。 Orchestrator提供了一种更明确的拆分方式。 按照官方文档，每条用户消息首先进入只读规划阶段，由Carbon或Argon检查代码库、处理歧义并生成实施计划，同时写明应当触发重新规划的条件。计划形成后，Hydrogen接手文件编辑、代码编写、构建、测试与结果核验。遇到计划未能覆盖的问题，控制权再交回规划模型。 传统模型路由通常在任务开始时判断请求难度，然后把整个请求交给一个模型。Orchestrator的差异在于两个模型可以在同一任务轨迹中多次交接控制权，而不是各自处理一个完全独立的请求。 这使分工的对象发生了变化。系统不再只是决定由谁回答整个问题，而是决定任务进行到当前阶段时，谁更适合接管。 官方文档列举了几种典型的控制权回退情况。验证步骤连续失败，接口行为与预期不一致，或者实施过程中出现计划未曾确定的设计选择，Hydrogen都可以把任务交回规划模型。规划模型检查当前状态、修正计划，再将任务交还执行层。较长任务中，规划模型还会检查执行进度与原计划是否一致。 因此，这套机制的关键并不是把任务一分为二，而是允许系统从执行返回规划。计划不再是任务开始前的一次性产物，而成为可以根据环境反馈持续修正的控制结构。 谷歌在Antigravity官方博客中披露，Orchestrator在Terminal-Bench 4.1上取得了接近Carbon的任务成功率，平均配额消耗减少24%，完成速度提高19%。这组数据说明规划与执行分工已经具备可测量的系统收益，但配额变化不能直接等同于实际账单变化。 Hydrogen提供low、medium、high和xhigh四档思考级别，默认使用high。在Antigravity界面中，最高档显示为Extra。单独选择Hydrogen时，用户可以根据任务需要调整推理投入。 向左滑动查看四个思维级别 但最新文档同时明确道Orchestrator采用固定配置，用户不能为其选择思考档位。需要指定推理强度时，必须直接选择Carbon、Argon或Hydrogen。现有公开资料也没有表明Orchestrator会在每个子任务中自动调整Hydrogen的思考级别。 因此，Hydrogen为执行模型提供了可配置的推理预算，Orchestrator则实现了规划模型与执行模型之间的自动交接。这两个能力同时存在，却不能合并成逐子任务自动调档的既成功能。 从系统设计看，它们代表两个不同的资源分配维度。一个决定当前阶段由哪类模型接管，另一个决定单个模型在一次调用中投入多少推理计算。前者已经在Orchestrator中形成自动回路，后者仍需要产品配置或上层策略显式控制。 这个边界并不削弱Hydrogen的意义，反而帮助我们看清当前智能体工程的真实进度。模型之间的交接开始自动化，更细粒度的推理资源调度仍有大量问题等待解决。 如果Hydrogen承担执行单元，就不能只用高阶推理能力的标尺评价它。 执行模型首先要遵守上游计划划定的边界，不能随意扩大修改范围。它需要在工具报错、搜索返回空结果或测试失败时采取合理动作，而不是直接偏离任务。它还要把执行结果转化为可检查的证据，让规划模型能够判断计划是否真正完成。 对规划者而言，错误可能主要表现为方案不合理。对执行者而言，错误则可能表现为越界修改、误用工具、虚构验证结果，或者在关键假设已经失效后继续推进。 谷歌在发布资料中特别强调，Hydrogen能够在工具调用失败或搜索无结果时调整行为，并支持批量文件读取与并行搜索调用。减少捏造声明、任务越界和跳过必要步骤，也被列为此次改进的重要方向。 搜索功能正大幅提升 这些能力共同指向三个更具体的工程属性，可预测、可检查、可恢复。 可预测意味着模型不会频繁做出计划之外的动作。 可检查意味着每次修改都有明确结果，能够通过测试、日志或其他验证手段确认。 可恢复则意味着局部失败不会直接演变为整条任务链的失控。 适合规划的模型未必适合高频执行。适合执行的模型也不必在所有复杂推理任务上超过规划模型。两类模型开始承担不同的系统责任，评价体系自然也应随之分化。 多模型分工并不会自动降低系统复杂度。它只是把一部分难题从模型内部转移到了模型之间。 首先是计划的信息密度。规划必须以足够明确的形式传递给执行层。过于抽象，执行模型需要自行补充大量判断。过于细碎，规划模型又会陷入执行细节，失去分工的意义。 更难的问题是重新规划的触发边界。 局部报错如果过于容易触发控制权回退，系统会在规划与执行之间反复切换，增加状态传递、重复规划与响应时延。如果执行层对异常过于迟钝，又可能带着错误假设持续修改，直到任务后段才暴露计划本身的问题。 分工架构因而把模型选择问题进一步变成了控制策略问题。什么属于执行层可以自行恢复的局部异常，什么意味着原始计划已经失效，并不存在适用于所有任务的固定答案。 执行结果返回规划层时，还存在信息压缩问题。完整保留所有工具输出会迅速膨胀上下文，过度摘要又可能丢失异常原因、环境状态和验证证据。任务链越长，状态一致性就越难维护。 控制权交接还会增加故障定位的难度。一次错误究竟来自原始计划、执行偏差、工具异常，还是重新规划时对状态的误判，需要完整的决策轨迹才能回答。模型调用记录、任务状态快照、工具日志与验证结果，都会成为智能体可观测性的一部分。 Orchestrator采用单主任务会话，在每轮任务内部完成规划与执行交接。它解决的是控制权如何在同一任务轨迹中流转，而不是同时启动多少智能体。需要多个智能体并行工作或相互检查时，官方文档指向subagents、Swarm、Boost或Teamwork等其他机制。 多模型交接解决的是当前阶段由谁负责，多智能体并行解决的是多少工作可以同时推进。两者可以组合，却有着不同的工程难点。混为一谈，会低估状态同步、结果合并与任务协调的复杂性。 Hydrogen的执行角色并不限于代码仓库。 官方列出的工作负载还包括文档、表格、图表、音频与录制视频处理，并展示了从视频和设计模板生成演示文稿、自动检查排版等案例。 这意味着规划与执行分工并不只是软件工程中的局部方案。它同样可能进入研究、内容生成和业务流程等多步骤任务。 但不同场景对可校验、可恢复的要求并不相同。 代码可以通过构建、测试和静态检查建立相对明确的验证闭环。文档与多模态任务则需要引入引用检查、事实一致性、结构约束、版式检查和人工复核。执行结果是否正确，往往不能只由一个通过或失败的信号决定。 因此，执行单元进入更多知识工作场景后，验证器的重要性会进一步提高。模型能够生成结果，不等于系统已经具备确认结果的能力。规划、执行与验证之间如何形成证据链，会比单纯增加生成步骤更加关键。 Hydrogen与Orchestrator并不意味着单模型路径已经失效。 谷歌仍然保留了完整的单模型选择。需要所有中间步骤都保持较高推理深度时，可以直接使用Carbon或Argon。对于依赖升级、样板代码、文档修改等不需要独立规划阶段的任务，也可以直接使用Hydrogen，并选择相应的思考档位。 谷歌没有把多模型分工写成唯一答案，而是将它做成了一种可以直接调用的产品能力，与单模型闭环并存。 智能体系统的能力上限不再只由单个模型决定，任务边界如何划分，计划如何表达，异常何时触发控制权回退，执行结果如何验证，都开始影响最终结果。 单模型基准通常关注最终结果，难以直接呈现规划与执行交接中的状态丢失、摘要压缩和异常回退。随着多模型协作进入产品内部，评估对象也需要从一次模型输出扩展到完整任务轨迹，进一步观察状态一致性、控制权转移和最终验证之间的关系。 这些问题过去往往隐藏在应用开发者的编排代码中，Orchestrator将它们前移为产品内置能力，Hydrogen则成为这套机制中明确承担实施与验证工作的模型。 Hydrogen真正值得记录的不是Agent里又多了一个更快的模型，而是执行开始成为可以被独立设计、配置与验证的系统层级。 当规划与执行分离之后，决定系统可靠性的，往往不是哪一次调用最强，而是交接发生时任务状态是否完整，异常是否被识别，控制权是否回到正确的位置。 Agent工程除了关注单个模型能否独立走完任务，还需要检验规划、执行与校验之间的契约能否稳定运行。规划与执行是两种不同的计算负载
关键变化是控制权，而不是模型数量
四档思考不等于子任务自动调档
执行模型需要另一套评价标准
分工真正的难点在交接边界
从代码到多模态，验证方式随之变化
智能体评测需要伸向完整任务轨迹
本文来源于DOIT传媒，文章内容仅供参考，不构成投资建议。
评论列表