Gemini 4 Hydrogen 主打编程代理提速

Gemini 4 Hydrogen 值不值得接进日常开发，不能只看榜单。原文给出的判断是：它有望缩短编码任务的执行时间，但每 token 更贵，最终是否省钱，要看完成一次真实任务的总成本。

文章更有用的部分，是把模型、Agent 工具和任务分工放在一起讨论。以下发布时间、规格和成绩均按原文转述；其中多数数据来自 Google，独立测试也还不足以支持全面切换。

Hydrogen 的定位是日常执行，推理深度可以按任务选

据原文，Google 于 2026 年 11 月 12 日正式开放 Gemini 4 Hydrogen，模型 ID 为 gemini-4-hydrogen。它接替 Gemini 3.8 Flash，也是这条产品线首次去掉 Flash 名称。

Hydrogen 是 Google DeepMind 的闭源权重模型，模型卡称其由 Gemini 4 Carbon 适配而来，只通过 Google 产品和 API 提供。Google 将它定位为 Agent 工作流的日常主力，更深、更长周期的推理交给 Carbon 和 Argon。

它支持文本、图片、视频、音频和 PDF，提供 1M tokens 上下文。不过，1M tokens 是输入、思考和输出共用的容量。 不能把整个窗口都理解成可上传的代码或文档。

推理档位有 low、medium、high 和新增的 xhigh，默认是 high。开发者可以按任务选择推理深度，控制成本和延迟；但原文没有给出各档位的具体耗时、价格差异，也没有证明简单任务降档后能保持多少质量。

接入渠道包括 Gemini API、Google AI Studio、通过 Gemini API 接入的 Android Studio，以及 Gemini Enterprise。Google Antigravity 面向 AI Pro 和 Ultra 订阅者提供，普通用户也能通过 Gemini app 和 Google Search 使用。

跑得更快，为什么还不能直接认定更便宜

Google 声称，Hydrogen 完成任务的速度是 Gemini 3.8 Flash 的 2.5 倍；在 Terminal-Bench 4.1 上，成绩从 18.2% 提高到 57%，编造事实的频率则降至前代的五分之一以下。这些都是厂商数据，原文没有展开测试配置。

独立测试提供了一点支持。Bito 在高难度编码任务中报告，Hydrogen 得分为 71.6%，3.8 Flash 为 42.2%，并称前者因为更快完成任务，单次会话成本更低。但这仍只是一项测试，不能推导出所有仓库都会得到相同收益。

价格尤其需要拆开看：Hydrogen 每百万输入 tokens 为 $1.50，每百万输出 tokens 为 $7.50，并提供免费层。由于 3.8 Flash 的促销价持续到 2026 年底，Hydrogen 当前每 token 价格是它的两倍。

每 token 的价格和完成一次任务的成本，是两笔账。

如果模型用更少轮次完成修改、少走几次错误路线，单价更高也可能省钱。但原文没有提供足够的调用明细，无法判断收益究竟来自减少 token、减少重试，还是其他执行差异。

它也并非全面领先。原文称，Google 模型卡显示，Hydrogen 在终端编码、计算机操作和一项科学工作流测试中落后于某个竞品，其余多数测试领先。竞品身份和具体差距没有交代清楚。

模型之外，Agent 工具和分工也会改变结果

Antigravity 新增的 Orchestrator 模式，把 Carbon 和 Hydrogen 分配到不同岗位：Carbon 负责规划和重新规划，Hydrogen 负责改代码、执行测试。

Google 称，这种组合接近 Carbon 单独工作时的任务成功水平，同时少用 24% 配额、快 19%。目前仅 Ultra 用户可用。这里的「配额」不能直接折算成 API 账单，原文没有提供换算依据。

这个方案适合观察：复杂任务的规划需要较强推理，反复编辑、运行测试则可能交给更快的模型。但规划与执行之间能否准确传递上下文，同样会影响结果。

工具也会改变表现。原文提到，一项第三方测试中，三个 Gemini 4 模型在 Gemini CLI 内的得分，都低于它们在其他编码 Agent 中的得分。文章没有说明原因，因此不能简单归结为 CLI 的某个缺陷。对开发者更直接的提醒是：模型必须放进实际使用的编辑器或 Agent 中测试。

另外，Google Cloud 将 Hydrogen 列为短期 GA 版本，退役通知期至少 45 天。模型名称放在集中配置里，有助于后续迁移。

我的判断

原文最可靠的建议，是用真实项目任务比较速度、质量和每任务成本。对日常 AI 编程而言，一次生成有多快，不如最终修改能否通过测试、需要人工修多少更有参考价值。

但文章提供的证据还不足以证明 Hydrogen 能普遍替代现有模型。Google 的成绩属于自报数据，Bito 的结果也有任务范围限制；作者没有给出自己团队的实测过程。

Carbon 规划、Hydrogen 执行的组合值得试，但还缺少与单模型方案在同等任务、预算下的完整对照。原文结尾关于美国移动开发服务的推荐，也没有承接前面的测试证据，不能作为技术选型依据。

能拿来做什么

• 从现有项目挑一个边界明确的 bug 修复、重构或测试补全任务，让 Hydrogen 和当前模型使用相同起点与验收条件，记录耗时、费用和人工返工量。
• 在实际使用的编辑器或 Agent 中完成对比，同时记录推理档位；不要把一个工具里的成绩直接套到另一个工具。
• 如果已有多模型 Agent 流程，可以试验由强模型规划、快模型执行，并观察交接是否增加误改和重试。
• 将模型 ID 集中配置，并为应用内助手、文档摘要等功能保留超时处理、费用限制和备用模型，方便应对版本退役。