Gemini 4 Carbon 发布:长任务需要的不只是更强推理

从漏洞发现到修复验收,分清厂商测试结果、分阶段开放范围与长任务真正需要保留的证据。

Buda Team
← 返回博客
Gemini 4 Carbon 发布:长任务需要的不只是更强推理

Google 将模型能力推进到持续数天的软件工程任务,团队也需要把验收从“回答是否正确”推进到“证据能否支撑下一步行动”。

2026 年 10 月 28 日,Google 发布 Gemini 4 Carbon,重点指向长周期工程任务与网络安全防御。Google 描述的典型工作,是在大型代码库和底层系统中定位隐蔽缺陷、尝试修复,并在遇到死路后继续寻找路径。

对于把 AI 用进真实工作的人,这次变化有一个具体后果:任务持续得越久,最终一段总结越不足以说明它做了什么。需要留下的是问题复现、判断依据、实际改动、验证结果,以及执行停在哪里。

发布已经确认,使用范围仍按阶段展开

Carbon 不再只是内部代号或社交平台上的猜测。Google 的正式公告确认了名称和发布方向,同时说明首批开放对象是一部分网络安全防御者,后续通过 Fairwind Program 扩展至可信合作伙伴,再逐步面向开发者、企业和消费者。

因此,阅读发布消息时应先区分两个问题:模型正式公布了什么能力,以及自己的工作环境实际能使用哪些入口。对计划采购或迁移的团队,后一个问题需要具体到账号、地区、工具环境和权限,而不是从新闻标题直接跳到替换现有系统。

Google 将 Carbon 描述为在 Argon 基础上的进一步提升。这并不要求所有轻任务立刻换模型。整理清晰材料、生成短文和定位跨仓库缺陷,对推理与验证的要求并不相同;选择应围绕任务失败会造成什么后果。

三项安全成绩分别回答三个问题

Google 公布的数字包括 SEC-bench Pro 88.2%、ExploitGym 54.8%、CWE-bench 71.0%。它们分别对应发现漏洞、验证可利用性和修补根因。公告明确说这些外部基准评估未启用 guardrails。

三项成绩,三个不同问题

这些成绩可以帮助理解能力方向,却不能拼成一个“安全准确率”。漏洞发现率不等于修复成功率,可利用性验证也不意味着某个生产系统应允许自动攻击测试。每一阶段需要的环境、授权和验收证据不同。

Google 还称,在内部基准中,生成安全代码的成功率较 Argon 提高超过两倍。这是厂商报告的结果;迁移到特定代码库时,仍需要用自己的测试、约束和审阅流程来判断收益。内部测试中的提升和外部基准得分也不应混在同一比较图中。

发现、验证、修复分别需要不同证据

连续运行数天,交接也要分阶段

Google 称其内部团队已看到 Carbon 持续数天处理复杂工程问题。长运行的价值在于能够跨过失败尝试、保留探索路径并继续推进;它也让中间状态变得更重要。

一个修复任务至少应留下四类可检查产物。第一是问题能否复现:输入条件、错误输出和受影响范围。第二是为什么选择当前修复:根因、排除过的解释和仍未解决的假设。第三是实际差异:修改了哪些文件,涉及哪些接口或行为。第四是验证:哪些测试执行过、结果是什么,还有哪些依赖生产环境才能确认。

当输入版本、权限或任务范围改变时,应在对应阶段重新核验,而不是让最初的一句授权覆盖整段长运行。尤其是从只读分析进入写文件、外部调用或生产操作时,动作边界必须具体。

这是一套建议的验收方式,不是 Carbon 在某个客户环境中的实测案例。团队可以直接拿现有任务记录检查自己缺少哪类证据,无需先编一套练习数据。

不只验收修复,还要验收停止

长任务常见的失败不是完全没有产出,而是把尚未验证的改动包装成已经完成。报告应同时回答:哪些结果已经由实际输出支撑,哪些只在局部环境通过,哪些因为权限、资料或依赖而停下。

Google 在公告中称,Carbon 在内部测试中减少了无依据断言,并更倾向于把方法限制和未完成条件写进交付。这值得关注,但团队仍应保留自己的完成标准。模型更愿意报告边界,不能替代工具侧的真实结果。

对软件修复,代码合并、测试通过和生产验证是三个不同状态。对研究或文档工作,同样要区分来源已读、草稿已成和正式记录已更新。把状态分清,接手的人才知道下一步是审阅、补证还是执行。

长任务交接,要交清停止位置

把验收条件放进工作空间

可以用 Buda 搭建围绕资料、执行和人工审核的工作流程:在承担任务的 Agent 中准备来源文件,说明允许执行的动作、交付文件和验收标准,再让 Agent 保存结果。具体的文件组织与上下文延续可参考 Drive 与记忆。

对于长任务,提示要求应明确到“交付什么证据”,例如保存修改说明、已执行验证及未完成项;不要仅要求“仔细检查”。接手者应打开实际文件与链接,再决定是否批准后续动作。Agent 工作空间可以承接这些材料和执行过程,模型能力与操作授权仍分别管理。

实际决策中的两个问题

现在是否应该替换现有模型?

先选一类现有模型反复失败、且结果能检查的任务。保留相同输入与验收条件,比较修复正确性、遗漏、人工返工和总等待时间。对已满足要求的轻任务,没有必要仅因为新模型发布就迁移。

安全能力增强后,能否直接自动修复生产漏洞?

从授权明确的隔离环境开始,要求可复现发现、根因解释、补丁差异和回归结果。生产变更继续走已有审核与发布流程。先决定谁有权批准动作,再讨论让模型连续运行多久。