谷歌 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 再到 10MLlama 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_discount0.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 万输出的时代这个任务还需要交接吗过去两年我们为输出上限妥协设计的所有调度框架、续接逻辑、状态快照方案都值得拿出来重新审视——它们解决的是一个正在消失的问题而维护它们的成本是真实存在的。那些专门用于缝合多次调用的编排代码、为对抗截断而设计的检查点协议、为恢复上下文而搭建的快照存储在单次完成范式下都会逐渐变成历史包袱。及时清理这些包袱把工程资源投到「如何把任务定义得更连贯」这个新的瓶颈上才是对这次能力跃迁最务实的回应。