2026 年 10 月 1 日

1 / 3

Gemini 4 Argon：Google 把“长任务”从长上下文推进到了长输出和持续执行

9 月 30 日，Google 正式公布 Gemini 4 Argon。它目前还不是一次面向所有人的常规模型上线：首批访问对象是 Fairwind Program 中经过筛选的网络安全防御人员，Google 表示随后才会逐步开放给开发者、企业和消费者，计划首先覆盖付费 API 用户与 Google AI Ultra 用户。初始 API 定价为每百万输入 token 2 美元、输出 token 10 美元，缓存输入按输入价格的 5% 计费；优惠期结束后则分别变为 4 美元和 20 美元。Google

Argon 最显眼的规格并不是输入上下文，而是 单次输出上限提高到 100 万 token，此前为 64K。这个变化值得单独理解。过去所谓“长上下文”主要解决模型能读多少材料；但 coding agent、研究 agent 和长时间运行的企业工作流面临另一个限制：模型可能读得下整个代码库，却无法在一个持续轨迹里进行足够多轮推理、调用工具、检查结果和继续修正。把输出预算扩大一个数量级以上，实际是在给单次 trajectory 更大的计算和行动空间。Google 对 Argon 的产品描述也明显围绕 long-horizon workflow，而不是传统问答。

Google 给出的内部案例比单纯 benchmark 更能说明这种设计想解决什么问题。一组 Argon agents 分析 Google 数据中心的 profiling telemetry，寻找并应用内存优化；Google 称已实际释放超过 300 TiB 内存，并估计最终可达到 500 TiB—1 PiB。另一个项目是大规模 C/C++ 到 Rust 的迁移：任务规模从数万行代码一直延伸到 Fuchsia Zircon kernel 的 80 万行以上。针对视频解码库 libgav1，Argon agents 对原有 Rust port 中约 3.2 万行 SIMD 代码反复进行 profile-guided experiments，最终生成可以由编译器自动向量化的 safe Rust；Google 自报最终版本相较原 Rust port 快 2.7 倍，同时保持相同视频输出。需要注意，这些都是 Google 自己的内部工程结果，并非外部独立测试。

公开评测则提供了另一组观察窗口。Google 报告 Argon 在 DeepSWE v1.1 上达到 77.9%，在 Zapier 的 AutomationBench 上达到 51.3%，LVBench 长视频理解为 91.7%；它还声称模型在 Vals Index、Vals Finance Agent v2 和 Harvey Legal Agent Benchmark 等专业知识工作评测中处于领先位置。这些 benchmark 的任务定义和 harness 不同，因此数字不能简单横向拼成一个“综合能力分”，更适合看 Google 把模型能力押在哪些工作负载：真实软件工程、多步骤业务执行、专业研究以及长视频和文档处理。Google

网络安全则是 Argon 首发策略最特殊的一部分。Google 称模型可以自主发现、验证并修复漏洞；在 CWE-bench v1 上报告 68% 的修复成绩，并表示 Wiz 已经通过 Scan for Good 使用 Argon 寻找公共基础设施中的安全问题。对于经过筛选的防御团队，Google 准备提供不带通常 cyber guardrail 的版本，让他们使用完整网络安全能力；面向更广泛用户的版本则继续保留针对网络攻击和 CBRN 滥用的限制。

这也解释了为什么 Argon 没有直接全面发布。Google 描述了几层额外控制，包括针对 indirect prompt injection 的对抗训练、监控模型内部推理与行动并在越界时终止执行，以及在高风险训练和评测前进一步隔离 sandbox。这里出现了一个越来越实际的工程关系：模型拥有更长的行动轨迹之后，能力提升与 control problem 会同时被放大。100 万 token 的输出预算如果只是写文章意义有限；如果这些 token 对应数百次代码修改、shell 操作、浏览器行为和工具调用，运行时监控、sandbox 和权限控制就会成为模型能力的一部分。Google

2 / 3

SynthID Bio：水印第一次从 AI 内容进入了真正合成出来的蛋白质

Google DeepMind 9 月 30 日发布的 SynthID Bio 很容易被“AI 水印”这个熟悉标签低估。此前 SynthID 主要处理图像、音频、视频和文本等数字内容，而 SynthID Bio 想解决的问题更特殊：如果生成模型设计了一条新的蛋白质序列，水印能否跟着这条序列进入 DNA 合成、蛋白表达和实验环节，最后在真正存在于实验室里的分子上仍然可检测？Google DeepMind

蛋白质序列允许这样做，是因为同一种功能往往不只对应唯一一条氨基酸序列。SynthID Bio 在模型生成序列时，对氨基酸选择施加很小的、有结构的偏置，把可统计检测的模式编码进去。对于三维蛋白结构，它采取另一条路线：微调 AlphaFold 3 diffusion network 的一小部分，使模型输出的原子坐标天然携带水印信号。也就是说，水印并不是生成结束后附加的一段 metadata；它被写进了生成过程本身。

真正困难的条件是：这种扰动不能把蛋白质弄坏。DeepMind 用 AlphaProteo 与启用 SynthID Bio 的 ProteinMPNN 设计 protein binders，并针对 VEGF-A、SARS-CoV-2 spike RBD 和 PD-L1 三个靶点进行了湿实验。团队报告，带水印设计与无水印设计在命中率、结合亲和力以及天然序列多样性上相当，并实际得到能够发挥生物功能的水印蛋白质。对于 AlphaFold 3 结构水印，团队则称预测精度基本保持，同时检测率接近 100%，而且经过数字噪声或轻微坐标修改后仍能检测。Google DeepMind

它的用途也和普通图片水印不同。生成式蛋白设计正在使“一个序列究竟来自自然界、人工设计还是某个生成系统”变得越来越难判断。与此同时，DNA synthesis screening 通常依赖已知危险序列和相似性匹配；真正新颖的 AI 设计可能天然位于已有数据库之外。SynthID Bio 提供的是 provenance 层：如果设计工具主动采用这套机制，之后可以验证某个蛋白序列或预测结构是否来自相应生成流程。

边界也很明确。它并不能给所有 AI 生成蛋白自动打上标签，更不能识别没有采用 SynthID Bio 的其他生成系统；攻击者如果从一开始就不用带水印的模型，水印本身不会提供保护。因此它更接近一项可以嵌入可信设计工具链的基础设施，而不是通用的生物安全检测器。DeepMind 此次最有价值的证据，是已经跨过了“数字模拟里能检测”的阶段，在三个靶点上实际合成并测试了带水印、仍有功能的蛋白质。Google DeepMind

3 / 3

Anthropic 的机器人工作暴露指数：能做 34% 的工作时间，与经济上值得做只有 0.3%，可以同时成立

Anthropic 9 月 30 日发布了一项关于机器人与就业的研究，试图把一个经常被混在一起的问题拆开：机器人在技术上“能做”一项工作，与企业今天“值得用机器人来做”并不是同一个变量。研究使用 O*NET 中约 900 个职业、约 1.9 万项工作任务，让 Claude 按身体、认知和人际要求识别物理任务，再结合现有机器人能力、工作环境以及成本估算，构建 robot exposure index。Anthropic

按照这套定义，今天已经存在的机器人能够以某种方式完成美国约 74% 的物理任务；这些任务折算后占全部工作时间约 34%。机器人和 LLM 的能力覆盖合并计算时，大约 80% 的工作时间至少暴露于其中一种技术。这个数字听起来非常接近“大规模自动化”，但它包含大量只能在高度结构化环境中工作的机器，也没有首先考虑部署价格。

研究进一步询问为什么这些技术能力没有直接变成现实中的自动化。Claude 对任务逐项估计后，Anthropic 得到的最大限制来自机器人能力本身和成本：约 70% 的物理任务仍存在能力障碍，其中最突出的不是语言推理，而是 manipulation——触碰、抓取、摆放和处理现实物体。约一半物理任务如果没有更好的操作能力就无法大规模自动化；相比之下，主要受 planning 和 reasoning 限制的只有约 8%。法规被估计会限制约 14% 的物理任务，人类偏好则影响约四分之一。

成本把数字进一步压缩。Anthropic 为每项暴露任务估算机器人购买、安装、维护、监督、能源等完整成本，再按照设备寿命和资本成本年化，与完成同等工作量的人类总薪酬比较。按这一口径，技术上机器人可以完成的任务占全部工作时间 34%，但今天真正达到成本竞争力的只有约 0.3%。

一个具体例子是仓库包装工。研究估算完成相关任务所需的一组机器人购买和安装成本超过 200 万美元，但可以替代大约 14 名员工的年工作量；考虑约十年设备寿命、8% 资本成本以及维护、能源和监督后，每替代一名员工的年成本约 4.5 万美元，而该职业总薪酬约 4.9 万美元，因此已经接近经济可行。美国约有 56 万名 packers and packagers，过去十年该职业就业人数已经下降约 22%。这些成本数字大量依赖 Claude 对具体机器人和部署环境的估算，研究本身也把它们视为近似值。

把成本曲线往未来推，结论与常见的机器人叙事差别更明显。历史数据表明机器人价格大约每年下降 3%；如果这一速度持续，要让机器人在今天 10% 的人类工作上达到成本优势，需要总体成本下降约 70%，大约要四十年。Anthropic 的基准情景甚至要到 2085 年，机器人才能在一半物理工作上达到成本竞争力。研究也构造了更激进的情景：如果质量调整后的成本下降速度达到历史水平的四倍，同时新能力获得速度提高一倍，那么一半物理工作可能在 2050 年左右达到成本竞争力。

这项工作的价值因此不主要在预测一个自动化年份。它给出了一个更有用的分解框架：技术覆盖、操作能力、环境结构、法规与偏好、资本成本、单位工作成本分别决定机器人最终能否替代一项工作。LLM 让 planning 和 reasoning 快速变便宜，并不意味着物理自动化会以相同速度推进；如果最后卡住的是机械手无法可靠解开电线、清洁非标准环境，或者一套设备的资本成本仍远高于人工，那么“机器人已经会做”与“机器人会被部署”之间仍然可能隔着几十年。Anthropic

1 / 3

IFEval 的四种准确率：遵守一条要求与完成整份请求之间的距离

让模型写一篇摘要，同时要求超过 300 个英文单词、不使用逗号，并用指定的 Markdown 格式突出至少三个部分。模型可能写出了流畅的摘要，却漏掉其中一项要求。IFEval 把这类情况变成可以自动检查的评测：模型收到自然语言请求，生成回答，随后由程序逐项检查其中预先定义的约束。它不需要另一名模型先判断文章“整体上是否听话”。Inspect Evals 的官方实现说明就使用了上述摘要任务作为真实数据样例；本期关注的是这个已有 benchmark 的评分机制，不是新发布的测试。Inspect Evals 的任务样例与评分说明。

IFEval 原始论文于 2023 年提出，包含 541 条提示，覆盖 25 类可验证指令，包括关键词、长度、段落、格式、大小写和指定结尾等要求。它选择这些对象，是因为“是否出现某个词”“是否达到长度要求”通常能够交给明确的程序检查，而“是否幽默”“是否解释得恰到好处”很难获得同样清晰的判定。这个选择让评测易于重复，也限定了它的覆盖范围：分数主要反映这些约束的遵守情况，不能独自代表全部指令理解能力，更不能代替对内容正确性与写作质量的评价。IFEval 原始论文。

理解它的分数，首先要分清计数单位。指令级准确率把每项约束分别计入分母；提示级准确率则把一整条请求作为单位，只有其中所有约束都通过，才算这条请求成功。以前面的三项要求为例，假设长度和突出格式都合格，正文却出现了逗号，指令级结果就是三项通过两项，提示级结果则是失败。模型已经完成了大部分要求，与用户能否直接接受完整交付，是两个不同的问题。IFEval 用这两种计数方式分别观察它们。两种计数层级的定义。

可以用一个教学假设继续看清差异。某个测试集有十条请求，每条都包含三个约束。模型在每条请求中都漏掉一个约束，便得到约 66.7% 的指令级准确率，却没有任何一条请求完全合格，提示级准确率为 0%。另一个模型完整完成其中六条，对其余四条完全失败，指令级和提示级准确率都为 60%。前者在约束总数上表现更好，后者能交付的完整答案更多。这些数字不是实际模型结果，只用于说明：两个评分层级可能给出不同的排序，单独报告其中一个会隐藏失败的分布。

两者之间的差距也有诊断价值。在上述假设中，第一个模型的失误散落在所有答案里，第二个模型的失误集中于部分请求。但仅凭两个汇总分数，还不能判断失误是否来自同一类约束，或是否由少数复杂题目造成。需要继续查看逐题结果和约束类别。这里的分析是由计数方式推导出的解释：提示级分数越低，完整合格交付越少；它并不自动告诉我们具体该修哪一种能力。

2 / 3

严格评分与宽松评分怎样改变成功条件

第二条分界涉及评分器如何处理回答。严格评分直接检查原始输出；宽松评分还会检查若干经过处理的版本，例如去掉 Markdown 星号、删除第一行或最后一行，以及这些处理的组合。如果其中一个版本满足约束，就把相应指令判为通过。这形成了常见的四个结果：提示级严格、指令级严格、提示级宽松、指令级宽松。宽松处理与四项指标。

设想模型在规定的结尾句中加入了加粗标记，文字仍然相同，简单字符串匹配却可能把它判错。去掉星号能够减少这种漏判。不过，删除首尾行也可能删掉真正违反要求的文字，例如超出长度限制的寒暄。宽松结果因此表示“经过允许的处理后能够通过”，不能直接解释为原始输出完全符合要求。对严格与宽松之间差距的判断，还需要结合具体任务：如果下游必须直接接收原始文本，额外的一行说明可能就是实际失败；如果只关注正文内容，同一行说明的影响便不同。这是对评分设计适用条件的分析。论文对宽松评分误判风险的讨论。

“严格”也不等于所有格式都按原始字节匹配。具体检查器本身仍可能允许某些变化。当前官方代码中的 JSON 检查器会去掉首尾空白和指定的 Markdown 代码围栏，再调用 JSON 解析器。因而，一个放在代码块中的有效 JSON 也可以通过这项检查。它检测的是能否解析为 JSON，并没有在这个检查器中进一步验证业务字段、类型或内容是否正确。只看到“JSON 格式通过”，便推断“结构化交付已经正确”，会把检查范围扩大到程序没有验证的部分。官方 JSON 检查器。

再用一个教学假设说明：用户要的是包含 name 和 year 两个字段的对象，模型却返回了一个合法的 JSON 数组。数组能被 JSON 解析器接受，但字段要求没有完成。若一次评测只检查 JSON 是否可解析，这个答案会在该项上通过；要测字段完整性，就需要另一个相应的检查条件。这里没有运行官方代码，例子也不是原数据样本；它用于解释“语法有效”和“满足特定结构要求”之间的测量差别。

检查代码还决定了自然语言要求如何落到边界上。官方的段落检查器使用两个换行字符划分段落；长度检查器调用专门的计数函数。这意味着，段落和词数并非由评分者凭阅读印象判定。更换分段或计数方式，可能改变边缘样本的结果。相同名称的约束若迁移到另一种语言或输出环境，也需要确认这些实现是否仍然表达原来的要求。官方段落与长度检查器。

3 / 3

同名 benchmark 的汇总分数仍可能采用不同口径

读结果时，还有一层容易忽略：运行框架可能把四个分数再次汇总。Inspect Evals 的当前文档定义了一个 Final Accuracy，取四项准确率的平均值。这个汇总方便展示，但会同时混合完整交付、单项约束，以及宽松处理带来的通过情况。因此，一张表只写“IFEval 80%”，仍不足以判断模型究竟在哪一种口径上达到 80%。这个平均值是该实现明确规定的汇总方式；比较其他报告时，需要先核对对方的字段。Inspect Evals 的汇总定义。

即便分数字段相同，比较仍依赖同一批提示、相同检查器，以及能够对照的生成条件。多次采样后挑选一个合格答案，与单次生成得到的通过率，回答的也不是同一问题。这个差别尤其会影响含有多项要求的请求：允许重试或筛选，可能提高完整通过比例，但同时增加了运行过程与成本。这里是实验设计上的推论，不能在未说明尝试次数与选择规则时，把这种提升全部归于模型本身。

IFEval 适合让“漏掉了哪条明确要求”成为可观察、可重复的结果。它也保留了一个值得认真阅读的限制：检查器通过，只能证明它所检查的条件成立。完整任务是否有用，还取决于未被这些条件覆盖的事实、语义和质量。四项准确率、逐题失败记录与检查器实现放在一起，才能说明一份看似听话的回答，究竟完成了哪些要求，又留下了哪些缺口。