Gemini 4 Carbon 更难的承诺：第一天之后仍能做出有用工作

困难的软件错误很少以简洁的编码练习的形式出现。它表现为一份报告、间歇性故障或与其原因相距数层的症状。有用的工作可能包括阅读历史、测试相互竞争的解释以及丢弃一个小时前看起来很有希望的补丁。

Google 于 2026 年 10 月 28 日公布 Gemini 4 Carbon，强调长远工程和网络安全防御。 Google DeepMind 表示，其内部团队已经看到该模型在复杂的工作中持续了数天，包括大型代码库中的细微错误。这是内部观察，而不是承诺每个客户任务都会成功运行几天。 Google的公告 它还使访问边界变得清晰：最初的可用性是针对选定的网络防御者，计划通过 Fairwind 向更多受信任合作伙伴开放，并在之后扩大供应。

实际问题是长时间运行的模型应该留下什么。本指南解释了新模型的地位、如何阅读已发布的比较，以及工程团队如何准备一项在工作数小时后仍可审查的任务。

2013 年的 Scrumban 任务板示例，说明了持续项目中的可见工作状态。这不是 Gemini 接口或模型结果。图片：ian mitchell 博士，CC BY-SA 3.0；已缩放并添加留白。 图片来源 · 许可与图片说明. 官方产品参考。

仅当任务保留其意义时，持续时间才有用

编码智能体可能会保持忙碌而无法使问题变得更清晰。它可以搜索更多文件、尝试更多补丁并运行更多命令，同时摆脱最初的故障。较长的执行时间会增加取得进展的机会以及积累错误假设的机会。产品的挑战是通过该活动保持任务的目的。

我们的看法是，长时间运行的任务需要持久的约定。约定规定了问题、确定修复的证据、允许的范围以及仍然需要人员采取的行动。它应该能够经受住假设和实施的变化。否则，模型可以通过解决比用户分配的问题更简单的问题来达到令人信服的结局。

考虑一个说明性的同步错误。一份报告称，某个项目似乎已保存，但刷新后就消失了。有用的智能体任务是重现行为、识别所有权或持久性故障、提出范围修复并验证相同的用户可见路径。一个不太有用的结果是大规模重构，并伴随着从未执行过刷新的通过测试。

随着时间的推移，这种区别变得更加重要。几个小时后，审查人员需要记录最有力的证据和剩余的不确定性，而不是每个命令的记录。该记录应该告诉队友，如果运行停止，该在哪里继续，以及依据什么接受结果。

原创任务图：持续的工作应该产生可追踪的修复，并在探索过程中保留原始的验收标准。

Carbon 的比较描述了几种不同类型的工作

Google DeepMind的模型比较页面，11月2日查看，列出了 Carbon 和 Argon 的多项评估。例如，它报告 Terminal-Bench 4.0 为 65.2% 对比 57.1%， 和 FrontierSWE 2 上的比例为 61.2% 与 55.0%。这些是已发布的比较结果，具有不同的基准名称和条件；它们不应该被添加到单一产品的成功率中。

编码团队应该从类似于其自己的工作流程的任务开始。终端交互、代码仓库修复和基于浏览器的工作对智能体提出了不同的要求。在一次评估中表现良好的模型仍然可能需要不同的工具设置或生产代码仓库中更多人工协助。基准测试有助于选择实验；代码仓库自身的行为决定了实验是否成功。

此表是一个评估框架，而不是 Google 测试方法的重述。它将广泛的能力主张转化为团队可以回答的一系列问题。强大的本地结果应该包括失败和受阻的步骤，以便团队了解模型在哪里有帮助以及周围的工作流程在哪里仍然需要工作。

比较还需要一个稳定的基线。比较模型配置时，保持代码仓库修订、工具权限、任务语句和测试环境相同。如果一次运行收到现成的复现案例，而另一次运行必须从头开始发现它，则完成时间的差异就不能单独归因于模型。在解释结果之前记录条件。

网络防御需要从发现到验证修复的链条

Google 10 月 28 日公告报告 Carbon 得分为 SEC-bench Pro 上为 88.2%, 54.8% 在 ExploitGym 上 和 CWE 基准上为 71.0%，并指出这些外部基准评估是在未启用防护措施的情况下进行的。这些数字对应查找、验证和修补漏洞等不同任务。 Google的公告 是这些供应商发布的结果的来源。

对于防御者来说，有用的序列从授权目标和可以检查的发现开始。验证应在商定的环境中确定相关风险。然后，修复需要解决原因并保留合法行为。这些阶段有不同的证据要求，即使一名智能体可以帮助完成所有这些阶段。

一个说明性的内部代码库审查显示了其中的区别。该团队为智能体提供了库的独立副本以及有关输入处理的明确关注点。期望的结果是特定的发现、测试环境中的有限再现以及具有回归覆盖的补丁。智能体不应仅仅因为发现项目材料中的链接或凭证而将该分配扩展到不相关的系统。

第二个说明性场景是现有报告的分类。智能体可以帮助将报告连接到代码路径，并确定哪些测试可以区分真实问题和错误假设。一个有用的“无需修复”结论仍然需要证据。通过自信的解释来结束报告比说明为什么其声称的路径不适用于评估的代码修订版本要弱。

最终所有者仍然是负责系统的工程或安全团队。提议的补丁需要根据实际的服务边界、部署过程和兼容性要求进行审查。成功的隔离测试是该决策的一部分，而生产部署和监控仍然是独立的步骤。

模型的安全评估结果不能代替部署权限

Google 描述了对齐方式的改进、对提示注入的抵抗以及减少不支持的主张。这些是旨在克服歧义的模型的相关领域。操作意义是在预期的工作流程中对其进行评估，而不是将总体安全结果视为连接每个可用工具的许可。

长时间运行的工作受益于分阶段授权。读取代码仓库、修改隔离签出和部署服务是不同的操作。团队可以让智能体收集证据并准备可审查的变更，同时保留对发布或生产效果的明确批准。边界应由环境强制执行并在任务中进行描述。

不可信的材料造成了另一个实际问题。源文件、问题描述或获取的页面可能包含与分配的工作冲突的指令。一个设计良好的智能体系统应该将任务权限与其读取的内容分开。审查证据应该使意外的范围变化可见，特别是当运行持续足够长的时间而没有人在观察每个动作时。

这同样适用于凭证。仅授予任务所需的访问权限，并且更喜欢意外操作产生有限影响的环境。有用的试点可以确定模型是否要求缺失的上下文并留下如实标明受阻状态。这种行为与停止之前可以更改的文件数量一样重要。

原创权限图：较长的执行不会自动扩展权限。每个阶段都有不同的所有者和不同的完成条件。

分阶段访问首先为大多数团队提供了准备任务

此次公开发布描述了选定的网络防御者访问权限，然后是其他值得信赖的 Fairwind 合作伙伴，以及一般开发人员、企业和消费者界面。模型发布和广泛的产品上市是不同的事件。规划Carbon交付工作前，请通过Google官方渠道查询当前接入路线。 10月28日公告，于 2026 年 11 月 2 日检查。

没有访问权限的团队仍然可以准备有用的工作。选择一项困难但有限的任务，保留相关的代码仓库代码修订版本并收集当前使其变得困难的证据。定义测试和审阅者期望。当访问到达时，该准备工作可以重复使用，并且使得与当前可用工具的比较更有意义。

避免将准备工作视为无人值守完成的承诺。一项好的任务可能会在任何新模型运行之前揭示测试基础设施缺失、所有权不明确或问题复现不可靠。无论哪个模型最终执行探索，解决这些条件都可以改善团队的工程流程。

第三个说明性用途是跨层应用程序缺陷。前端状态看起来正确，而服务器存储不同的值。该任务可能需要通过请求、持久性和刷新的 UI 进行端到端跟踪，然后进行缩小修复。持续推理的价值在于在调查时保持这些层的连接，而不是仅仅在每一层中生成更多代码。

长期任务的成本包括审查和恢复

发布的token 价格只是长时间运行工作的一部分。工具执行、重复上下文、测试基础设施和工程师审查都会影响实际成本。以可读、证据充分的补丁完成的任务可能比更便宜的运行更有价值，因为这会给审阅者带来数小时的不确定性。

对于第一个试点，尽可能在智能体系统中定义支出和时间边界。决定在延长运行之前应提供哪些证据。停滞的任务应该留下有用的检查点：最后确认的事实、最强的剩余假设和下一个测试。这使得继续的决定基于进展，而不是希望更多的时间会有所帮助。

审查负担也是可衡量的。跟踪队友是否可以理解原因、检查差异并重现相关检查，而无需重播整个会话。如果答案是否定的，请在扩大智能体权限之前改进交付格式。较长的任务应该压缩团队的不确定性，而不是将其转移到较长的审查文档中。

从有明确终点线的修复开始

1. 确认可用的访问路线和提供的确切模型。保持已宣布的 Carbon 推出与其他 Gemini 模型的访问不同。
2. 选择具有稳定代码仓库修订和可重现故障的授权、隔离任务。避免使第一次评估依赖于不受控制的生产状态。
3. 用用户可见或系统行为术语编写验收标准。包括必须保持完整的约定，并列出需要批准的外部行动。
4. 提供所需的工具和最低权限。保留更改、日志和测试产物，以便其他工程师可以检查它们。
5. 要求检查点区分已证实的证据、当前的假设和受阻的工作。在扩展范围或预算之前查看这些检查点。
6. 根据原始故障和受影响的回归套件评估建议的修复。检查生成的差异是否有不相关的更改和隐藏的合约迁移。
7. 让负责的审阅者决定补丁是否已准备好进行正常的发布过程。明确记录不完整的检查和所需的外部验证。

试点应包括一种故意造成不便的条件，例如失败的无关测试或不可用的可选服务。观察可交付成果是否将该限制与修复的实际证据区分开来。报告诚实验证差距的模型比将每个不确定状态转变为完成声明的模型更容易集成。

多日智能体应该留下更短的决策路径

Carbon 的声明指出了对 AI 编码的不同期望：遇到死路后仍能继续推进并产生值得审查的修复。周围的工程系统必须使这种持久性发挥作用。清晰的范围、保留的证据和有限的权限为模型提供了可以有意义地完成的任务。

我们期望最有价值的评估将集中在交接的质量上。该模型是否保留了原始问题？它是否确定了实际失败的原因？工程师可以验证结果并决定接下来会发生什么吗？这些问题将长时间运行与实际工程成果联系起来。

更长时间运行的人工智能的承诺是从棘手的问题报告到有依据的决策的更短路径。只有当接手者能够信任留下的成果，投入的时间才真正有价值。

来源

• Google：介绍Gemini 4 Carbon，2026 年 10 月 28 日； 2026 年 11 月 2 日检查。内部观察和基准结果归因于 Google。
• Google DeepMind：Gemini模型比较，于 2026 年 11 月 2 日检查。基准版本和条件必须保留在其分数中。

保持工程决策与其来源相关

Telli.sh 是保留授权源材料和工程决策背后的注释的一种选择。 创建笔记工作区。