谷歌 DeepMind 在 2026 年 9 月 30 日发布 Gemini 4 Argon，距离上一代旗舰 Gemini 3 系列接近十个月，由高级副总裁兼首席 AI 架构师 Koray Kavukcuoglu 亲自撰文介绍。官方博客把它的定位压缩成一句话：在真实世界软件工程、法律与金融等企业知识工作，以及网络安全防御这些复杂工作流中，交付前沿级别的性能表现。CEO Sundar Pichai 亲自在社交媒体上宣布，强调这不是一次常规的跑分升级，而是面向长周期任务的重新设计。整篇发布稿里最值得拆解的不是某个基准分数，而是一个被大多数讨论带偏的数字------单次输出 Token 上限从此前的 6.4 万直接拉到 100 万。注意，是输出，不是输入，一字之差决定这次升级的性质和它对工程实践的真实影响。这件事对 Agent 工程的意义，比跑分表上那 77.9% 深刻得多。大多数媒体报道把焦点放在 DeepSWE 刷新了纪录，却很少有人解释为什么输出上限的提升才是这一切的前提。本文把这个数字背后的成本结构、工程含义和发布策略逐层拆开，帮助工程师理解这次升级究竟改变了什么，以及自己的 Agent 系统应该如何适配与演进。
先把输入和输出这两个方向分清楚。过去两年厂商卷的是输入上下文窗口，从 100K 卷到 1M 再到 10M，Llama 4 Maverick 号称支持 1000 万 Token 输入，Gemini 2.5 系列也早就把输入窗口推到百万级。但输入窗口解决的是「能看多少」的问题，输出上限解决的是「能连续干多久」的问题。这是两条完全不同的能力轴。一个 Agent 在执行软件工程任务时，每一轮都要生成计划、写代码、读编译错误、改代码、再跑测试，这些中间产物全部是输出 Token，而不是输入 Token。读 80 万行代码用的是输入窗口，但「翻译 80 万行代码」这个动作本身产生的中间推理、每一版翻译稿、每一次编译错误分析，全部是输出。输出上限 6.4 万意味着模型在单次推理轨迹里最多吐出 6.4 万个 Token 就必须停下，把控制权交还给外层调度循环。外层循环拿到这段不完整的输出，决定下一步是继续、重试还是换路。这个交接动作本身要消耗一轮完整的输入上下文------把之前的对话历史、工具调用记录、中间结果全部重新喂进去，模型才能想起来「我刚才干到哪了」。任务越长，交接次数越多，每一次交接都是一次完整的输入计费，外加一次状态重新加载的延迟，外加一次上下文重建时不可避免的细微信息损失。输入窗口决定了 Agent 一次能记住多少背景，输出上限决定了 Agent 一次能连续推进多少工作。过去两年前者被堆得很高，后者一直停在几万 Token 的水平，这导致长周期任务的瓶颈从来不在「看不够」，而在「干不长」。
Gemini 4 Argon 把输出上限抬到 100 万，等于允许模型在单次调用里连续生成数十万甚至上百万 Token 而不中断。官方说明里专门强调这是输出上限层面的提升，不是输入上下文窗口，这两件事容易被混为一谈。这意味着一个足够复杂的任务------比如把 80 万行 C/C++ 代码迁移到 Rust------理论上可以在一次推理轨迹里完成规划、逐模块翻译、编译、修错、再编译的完整循环，中间不需要把控制权交还给外层调度器。谷歌披露的内部案例里，Argon 确实参与了这类大规模代码迁移，处理超过 80 万行核心代码，分析编译器输出，进行性能优化，甚至协助数据中心和量子运算研究。这种任务形态在过去是不成立的，因为 6.4 万输出上限会在翻译到第几个模块时就强制截断，剩下的工作要靠外层循环一段段拼接，而拼接处恰恰是错误率最高的地方------模型在续接时对「为什么上一段这样翻译」的理解，永远不如它在同一条推理轨迹里的理解连贯。拼接次数越多，风格漂移和逻辑不一致就越严重，最终交付物需要大量人工对齐。
DeepSWE v1.1 的 77.9% 为什么重要，原因也在这里。DeepSWE 衡量的是真实世界长期软件工程能力，不是单函数补全，也不是算法题。一个典型的 DeepSWE 任务要求模型读懂一个大型仓库的 issue 描述，定位到具体文件，理解跨文件依赖关系，写出能通过测试的补丁，还要处理各种边界情况和回归风险。这种任务的完整解决路径通常需要数万到十几万 Token 的连续输出------定位问题要输出分析，写补丁要输出代码，跑测试要输出诊断，修 bug 要再输出新代码。输出上限 6.4 万的模型在做到一半时就会被截断，截断点之后的推理链断裂，外层调度器要么让模型从头再来，要么想办法续接------续接本身又引入新的错误，因为模型需要重新理解之前生成的所有中间产物。77.9% 对 74.2%（Claude Opus 5.5）和 74.1%（GPT-6 Astra）的领先幅度看起来只有三个多百分点，但考虑到 DeepSWE 任务的平均输出长度，这三个百分点里有相当一部分可能就来自「不用中途截断」这一项能力差异。这不是推理能力的差距，而是推理连续性的差距。
再来看经济账，这是本次拆解的核心。推广期定价是每百万输入 Token 2 美元、输出 10 美元，缓存输入再省 95%。推广期结束后恢复到输入 4 美元、输出 20 美元，常规期价格整整翻一倍，做长期预算要按常规价算。表面看输出比输入贵五倍，直觉反应似乎是应该多压输出、少让模型说话。但长周期 Agent 任务的成本结构恰恰相反------真正烧钱的不是输出，而是每一次任务交接时被迫重复支付的输入。用一个简化模型算这笔账：假设一个软件工程任务的完整解决需要 30 万 Token 的连续输出，当前工作目录和对话历史约 20 万 Token。输出上限 6.4 万的模型至少需要 5 次交接才能完成 30 万输出，每次交接要把 20 万 Token 的上下文重新输入，总输入消耗是 100 万 Token，总输出消耗 30 万 Token。按 Argon 推广期价格算，输入成本 2 美元，输出成本 3 美元，合计 5 美元。如果用缓存输入，第一次之后的 4 次交接里输入可以走缓存，输入成本降到 0.1 美元加首次 0.4 美元，合计约 3.1 美元。而输出上限 100 万的模型一次完成，输入只付一次 20 万 Token 即 0.4 美元，输出 30 万 Token 即 3 美元，合计 3.4 美元。两者接近，但前者多了 5 次交接的失败风险、5 次状态重建的延迟，以及拼接处的错误率。任务越长，交接次数线性增长，而单次完成的成本不变。当任务需要 100 万 Token 输出时，6.4 万上限的模型要交接 16 次，输入成本按缓存算也要 1.6 美元，总成本 11.6 美元，而单次完成是 0.4 加 10 等于 10.4 美元------更重要的是 16 次交接的累积失败概率会显著拉高实际重试成本，这部分隐性成本在账单上是看不见的，它体现在工程师盯着失败日志重跑半天的工时里。
下面这段代码把这个成本模型落成可运行的计算，输入任务输出需求、上下文大小、输出上限、推广期价格，直接对比两种模式的成本与交接次数。演示参数取上面讨论的量级，实际使用时可替换为自己的任务规模与平台报价。函数返回四个指标：交接次数、截断模式总成本、单次完成总成本、交接失败风险系数，足以支撑工程决策。把这段代码存成 team 内部的评估脚本，每次接到新需求时跑一遍，就能在动工之前量化「这个任务值不值得为单次完成模式重构」，避免凭直觉做决定，让架构评审有一个量化起点。
def compare_cost(total_output_tokens, context_tokens, output_cap,
price_in_per_m, price_out_per_m, cache_discount=0.95):
"""对比截断交接模式与单次完成模式的成本。"""
# 模式一：受 output_cap 限制，需要多次交接
handoffs = -(-total_output_tokens // output_cap) # 向上取整
# 第一次全价输入，后续交接走缓存
input_cost_mode1 = (context_tokens / 1e6) * price_in_per_m * (
1 + (handoffs - 1) * (1 - cache_discount))
output_cost = (total_output_tokens / 1e6) * price_out_per_m
mode1_total = input_cost_mode1 + output_cost
# 模式二：单次完成（output_cap >= total_output_tokens）
input_cost_mode2 = (context_tokens / 1e6) * price_in_per_m
mode2_total = input_cost_mode2 + output_cost
return {
"交接次数": handoffs,
"截断模式总成本(美元)": round(mode1_total, 2),
"单次完成总成本(美元)": round(mode2_total, 2),
"交接失败风险系数": round(1 - 0.98 ** handoffs, 3),
}
# 30 万输出任务，20 万上下文，Argon 推广期价格
result = compare_cost(300_000, 200_000, 64_000, 2.0, 10.0)
for k, v in result.items():
print(f"{k}: {v}")
运行结果是：交接次数 5，截断模式总成本 5.0 美元，单次完成总成本 3.4 美元，交接失败风险系数 0.096。风险系数的含义是假设每次交接有 2% 的概率导致任务失败需要重来，5 次交接后至少有 9.6% 的概率整体失败一次。把失败重试的成本摊进去，截断模式的期望成本会进一步高于单次完成。这个模型忽略了外层调度循环本身的工程复杂度------要实现可靠的续接，需要维护状态快照、处理幂等、设计回滚策略，这些工程量在真实项目里往往比 Token 成本更难控制。快照要存什么、续接时如何验证上下文一致性、失败后回滚到哪个检查点，每一个问题都足以让工程师开一个 sprint 来讨论，而单次完成模式下这些问题全部不存在。
输出上限提升带来的第二个结构性变化，是 Agent 从「完成一个任务」走向「持续经营一个工程项目」。过去的 Agent 设计默认模型是无状态的短工，每次调用干一小段，工程状态由外部系统（文件系统、数据库、版本控制）维护，模型本身对「这个项目上周改了什么」没有记忆，一切状态依赖外层系统重建。Argon 级别的输出上限允许模型在单次调用里维持数小时甚至数天的连续工作记忆------不是通过上下文窗口记住，而是通过持续生成的工作日志、中间代码、测试输出本身构成一条完整的推理轨迹。这条轨迹天然就是可审计的：所有决策依据、所有中间产物、所有错误修正都记录在输出里，不需要额外的可观测性系统去还原模型当时「为什么这么做」。审计一份金融尽调报告时，合规团队要看的不只是最终结论，而是从原始数据到结论之间的每一步推理依据，过去这需要复杂的日志系统和链式追踪，现在一条连续的输出轨迹本身就是完整的审计证据。这对金融、法律、医疗这类强合规场景尤其关键，审计要求的是完整决策链，而不是最终结论。同样地，软件工程领域的代码审查也能从中受益------一段 50 万 Token 的迁移输出，完整记录了模型为什么把某个 C++ 的裸指针翻译成 Rust 的 Box 而不是 Rc，为什么某个模块选择了 unsafe 块而另一个没有，这些决策依据在拼接模式下会随着交接而丢失，在单次完成模式下完整保留。这对大型代码库的长期维护意义重大------五年后接手项目的工程师可以沿着输出轨迹回溯每一个翻译决策的理由，而不是面对一堆风格不一的拼接代码猜测当初的意图。
Fairwind Program 的设计值得单独拆解。Argon 没有全面开放，而是先向受信任的网络安全防御方和参与美国政府预发布流程的机构开放，待安全防护加固后再逐步扩大到付费 API 客户和 AI Ultra 订阅者，官方没有给出具体的公开时间表。这个分阶段发布策略的背后是 CWE-bench v1 上 68% 的漏洞修复能力，与 GPT-6 Astra 并列第一------一个能自主发现、验证并修复关键软件漏洞的模型，同样能自主发现并利用漏洞。同样一段代码分析能力，在防御方手里是补丁，在攻击方手里是武器。给一个 100 万输出上限的模型配上漏洞挖掘能力，理论上它可以连续数天对目标代码库做系统性审计，输出完整的攻击链推演报告，这种规模的自动化攻击分析在过去需要一整个安全团队数周的工作量。谷歌的选择是先把这种能力交给防御方，让蓝军先用起来，再考虑一般商用。这种「防御优先」的发布顺序在前沿模型里是第一次出现，过去的安全审查通常是发布前的内部流程，而不是发布节奏本身------审完就全量放，风险靠使用条款约束。Fairwind 承认了一个现实：某些能力一旦开放就无法收回，使用条款挡不住真正的恶意使用者，发布顺序本身就是一种安全机制，而且可能是唯一有效的那种。这对整个行业是一个先例------未来其他厂商发布类似能力级别的模型时，是否跟进分阶段策略，会成为衡量其安全承诺的一个可观察指标。
Vals Index 企业知识工作排名第一、AutomationBench 商业流程自动化第一、LVBench 长视频理解领先，这些成绩共同指向同一个判断：Argon 的优化目标不是聊天体验，而是多步骤、长周期、有明确交付物的工作流。法律合同审查需要通读数百页文档并交叉引用条款，金融尽调需要把财报、公告、行业数据串成一条证据链，网络安全响应需要从告警到补丁的完整闭环。这些任务的共同特征是输出长度决定了任务能否一次完成，而不是输入长度决定模型能看多少。一份 200 页合同的审查意见可能本身就有几万字，一次完整的尽调分析加上引用证据可能超过十万字。把输出上限从 6.4 万抬到 100 万，本质上是把「单次推理可以经营的项目规模」抬高了一个数量级，让这些过去必须拆分多次调用的任务第一次有了单次完成的可能。
对正在设计 Agent 系统的工程师，这次发布有几个可操作的启示。第一，重新评估任务拆分粒度。过去因为输出上限被迫把任务切得很碎，现在要反过来问：这个任务能不能在一次调用里完成？能就不切，拆得越碎，交接成本越高，拼接处错误越多。第二，重算成本模型。不要只看单价表，把交接次数、失败重试、状态重建的工程成本都算进去，单次完成往往是总成本更低的那条路，即便单次调用的账单看起来更贵。第三，关注输出轨迹的审计价值。长输出天然形成完整决策链，这在合规场景里是免费的可观测性，不需要额外搭建链路追踪系统。第四，注意推广期与常规期的价格差。输入 2 美元输出 10 美元是推广价，常规期翻倍到 4 和 20，做长期成本规划时按常规价算，把推广期当折扣而不是基准，避免推广期结束后预算失控。第五，别急着迁移。Fairwind 阶段普通用户拿不到，等 API 全面开放后再做真实任务压测也不迟，内部基准和真实负载之间永远有差距，跑分表上的领先不等于你的业务场景里的领先。最后一个更宏观的判断：当单次推理可以经营一个完整工程项目，Agent 系统的竞争焦点就会从「怎么拆任务」转向「怎么设计让模型一次跑完的任务形态」，这要求产品经理和架构师重新学习一种能力------把业务问题翻译成一条连贯的、可以从头走到尾的推理轨迹，而不是一张需要频繁人工介入的流程图。这种翻译能力在未来一两年里会成为 Agent 落地的核心竞争力。
定价层面还有一个容易被忽略的细节：缓存输入便宜 95%。这意味着长周期任务里重复出现的系统提示、工具定义、项目背景这些固定上下文，实际成本只有标价的 5%。一个 20 万 Token 的固定上下文，缓存后每次交接只要 0.02 美元。这个折扣力度实际上在鼓励一种架构：把所有可复用的上下文沉淀为缓存前缀，让每次调用只新增必要的增量内容，而不是每次都把完整历史重发一遍。配合 100 万输出上限，最优架构可能是「超长缓存前缀加超长单次输出」------上下文一次付清（且打 5% 折扣），输出一次完成，中间零交接、零重试、零状态重建。这种架构在 6.4 万输出时代不成立，因为交接不可避免，缓存只能省交接的钱，省不了交接的失败率和工程复杂度；在 100 万输出时代，它成为成本与可靠性同时最优的选择。
Gemini 4 Argon 这次发布真正改写的不是跑分表，而是 Agent 工程的成本函数。输出上限从 6.4 万到 100 万的跨越，把「单次推理可以经营的项目规模」抬高了一个数量级，让长周期任务从「拼接多次调用」变成「一次调用完成」。交接次数减少带来的不只是 Token 成本下降，更是失败率、延迟、工程复杂度的系统性改善。Fairwind 的分阶段发布则提示，前沿能力的安全边界正在从发布前审查转向发布节奏本身。对工程师来说，现在该做的是重新拿出任务清单，把那些因为输出上限被迫切碎的任务找出来，问一句：在 100 万输出的时代，这个任务还需要交接吗？过去两年我们为输出上限妥协设计的所有调度框架、续接逻辑、状态快照方案，都值得拿出来重新审视------它们解决的是一个正在消失的问题，而维护它们的成本是真实存在的。那些专门用于缝合多次调用的编排代码、为对抗截断而设计的检查点协议、为恢复上下文而搭建的快照存储，在单次完成范式下都会逐渐变成历史包袱。及时清理这些包袱，把工程资源投到「如何把任务定义得更连贯」这个新的瓶颈上，才是对这次能力跃迁最务实的回应。