谷歌被曝内测新模型 Carbon：员工称编程接近 Opus 5.5

据 Business Insider 10 月 9 日报道，谷歌员工近期开始在内部编程平台 Jetski 中测试代号为 Carbon 的 Gemini 4 检查点。一名参与测试的员工认为，Carbon 的编程体验接近 Claude Opus 5.5，但同时表示还需要更多测试。谷歌对上述爆料拒绝置评。

这条消息的传播力来自“接近 Opus 5.5”这个说法，但它的证据等级必须被说清楚：这是内部体验反馈，不是公开评测结论。Carbon 也不是谷歌已经正式公布的产品名称，用户最终能否获得这一版本、通过什么产品使用它，都还存在空白。

把它放回谷歌近期的产品节奏里，意义就不止是“又一个模型代号出现了”。从已发布的 Argon，到 Antigravity，再到面向工作的企业智能体，谷歌正在同时推进模型能力、执行工具和工作入口三条线。Carbon 的潜在价值，在于能否为这套布局提供更可靠的编程能力。

谷歌于 9 月 30 日正式发布 Argon，最初仅向部分网络安全合作伙伴开放访问权限。根据 9 月 30 日的官方介绍，Argon 将输出上限由此前的 64K 提高至 100 万 tokens；谷歌报告其 DeepSWE v1.1 得分为 77.9%。模型先通过 Fairwind 计划向可信网络防御方开放，再逐步扩大使用范围。

这里有两个必须分开的边界。第一，100 万 tokens 是 Argon 公布的输出上限，不能与 Antigravity 测试界面中的上下文档位混为一谈。第二，Argon 的 DeepSWE v1.1 成绩不能移用来证明 Carbon 的表现——两者一个是已发布产品的官方数据，一个是未公开版本的内测传闻。

报道还称，内部版本 Barium-B 被选为对外使用 Argon 名称的模型，而 Carbon 最终如何发布仍未确定。这意味着连“Carbon 会以什么名字、什么形态出现”都还没有答案。

TestingCatalog 在 10 月 9 日的报道中指出，Antigravity 已出现 Argon 的模型选项及 256K、512K、900K 三档上下文配置；较大两档显示的额度消耗分别约为每轮 1.3 倍和 1.8 倍。与此同时，Gemini Web 现在支持所有可用模型的低、中、高三种思考难度设置。

这些变化可以被理解为平台在为 Gemini 4 的发布做准备，但需要克制：Antigravity 与 Concierge 的界面配置属于测试线索，不能直接视为最终产品规格。TestingCatalog 还发现尚未发布的 Concierge 智能体出现了 Chief of Staff 的新名称，同样只是测试界面线索。

如果这些配置最终落地，开发者面对的选择会更具体：一次任务需要携带多少信息，值得消耗多少额度？对大型代码库而言，更长的上下文可能减少反复补充材料的操作，但容量本身无法回答模型是否准确理解了依赖、保留了约束、找到了真正相关的代码。决定体验的仍是任务完成质量，而非窗口数字。

这组变化反映出谷歌希望解决的问题：让模型在更长的工作过程中持续推进任务。软件工程中的难点经常不在于写出某个函数，而在于理解已有系统、修改多个文件、运行测试，再根据失败结果调整实现。输出空间扩大，为更长的处理过程提供了条件，但它不是可靠性的保证。

长任务甚至会放大错误的代价。一个错误判断如果在早期没有被发现，后面的修改、测试和解释可能围绕错误前提继续展开。因而，评估下一代编程模型，除了看“能连续工作多久”，还需要看它何时能够识别方向错误、停止无效尝试，以及把哪些不确定性交还给人。

这也是“接近 Opus 5.5”这句话的局限所在。即便未来出现 Carbon 与 Opus 5.5 的公开对比，也不能只看两个模型名称。比较是否使用相同的任务、工具、重试次数和计算预算，直接影响结论。一个系统多尝试几轮后修复了问题，与另一个系统一次完成，其成本和使用体验并不相同。员工认为“接近”，可以是值得关注的信号，却还不足以回答这些问题。

今年 5 月的 I/O 大会上，谷歌公布了独立桌面应用 Antigravity 2.0，支持多智能体并行任务和后台调度；同时推出 Gemini API 中的 Managed Agents，让智能体在隔离的 Linux 环境内使用工具、执行代码，并保留可恢复的文件和状态。官方强调，这些能力使用 Antigravity 的智能体运行框架，并与 Gemini 模型协同优化。

这一布局很关键。模型回答正确，只是编程产品的一部分；它还需要知道该读取哪些文件、何时执行命令、如何使用测试结果，以及任务中断后怎样继续。开发者最终感知到的表现，是模型和整套执行系统共同作用的结果。

而谷歌更大的动作发生在编程场景之外。谷歌云刚发布了面向工作的 Gemini Agent，覆盖问答、任务处理、内容生成和编程。根据谷歌云的官方说明，Gemini agent 可以在 Workspace 等入口中使用，在云端持续运行，跨设备保留上下文，并通过子智能体协作处理任务，公司同时强调模型选择、权限管理、沙箱以及成本控制。The Verge 则指出，该产品目前面向企业客户进行私有预览，尚不能理解为普通用户已经全面获得这些能力。

把这些动作连起来看，一种较清晰的战略方向正在形成：以模型承担复杂推理，以 Antigravity 等工具承担执行，再通过企业办公产品承接实际工作。这是基于已公布产品的分析，并不意味着 Carbon 已被确认用于新的企业智能体。

为什么编程能力会成为这条路线的重要支点？因为许多办公任务，一旦超出简单问答，就会涉及数据清洗、信息转换、调用业务接口或生成可重复执行的脚本。用户提出的可能是“解释这次销售下滑”，系统需要完成的却是一连串读取、计算、核验和呈现工作。代码在这里成为完成任务的一种手段。

这也解释了为什么谷歌同时强调编程和通用工作能力：如果模型能够更稳定地编写和运行代码，受益范围可能超出专业开发者。但这种能力的扩张也提高了交付要求。代码运行成功，不代表取用了正确数据；报表生成完毕，不代表业务解释成立。一个能够行动的智能体，需要让用户看清它依据什么材料、做过哪些操作、哪些结论尚待确认。

从竞争角度看，谷歌的竞争目标很明显，就是日常任务开始的那个入口。企业已经使用的文档、邮件、表格和云端系统，为智能体提供了接触业务的机会；能否把这些入口转换成持续使用，最终取决于产品是否减少了交接、核查和返工。产品之间接得越多，不代表用户管理它们的负担就越小。如果任务状态不清楚、权限难以理解、失败后需要人工重新拼接流程，整合所承诺的便利就可能被抵消。更强的底层模型能缓解一部分问题，却不能替代产品和工程设计。

围绕 Gemini 4 的接连爆料，社交平台上出现了两种截然不同的反应：有人认为谷歌正在找回竞争力，也有人对“模型还没用上，下一版又开始预热”的节奏失去了耐心。

支持者更关注模型迭代释放的信号，试图用内部测试反馈回应“刷榜”质疑。不过，网友对成绩的解读和员工的初步体验，仍不能替代公开、可复现的实际测试。科技博主对迭代节奏的乐观判断，更多体现的是对谷歌执行速度的期待，尚不是对模型能力的独立验证。

另一些讨论则集中在产品何时真正可用。有网友汇总了 Antigravity 中隐藏的 Argon 配置，以及 Gemini 网页端低、中、高三档推理强度的界面变化，将其视为扩大开放前的准备，并追问是否即将上线。但同样的发布节奏也引发了明显的不满：一名国内用户在 x 上批评称，Argon 公布后迟迟没有“端上来”，内部又出现了 Carbon，并传出达到 Opus 5.5 水平的说法，他讽刺道：“建议 Google 接下来直接宣布 AGI，反正大家也用不上，没人能打它的脸。”

这些评论呈现出的分歧，并不只是“看好还是看衰谷歌”。双方实际上在等待不同的证据：支持者从内部迭代和测试线索中看到了追赶的可能，质疑者则要求谷歌先把产品交到用户手中。截至目前，Carbon 仍是一条值得跟踪的内部测试消息。“接近 Opus 5.5”带来了关注，但谷歌这一系列动作提出的是一个更大的问题：当模型、工具与办公入口被放到同一套系统中，AI 能否真正承担一段可以验收的工作？