Grok 4.6：智能体基准更强，速度与成本有所取舍

Grok 最近的发布速度让我印象深刻。Grok 4.5 是 Anthropic 和 OpenAI 之外，第一个让我觉得可能适合日常使用的模型，虽然它并不是我的默认选择。现在 Grok 4.6 宣称增强了长时间运行的智能体能力，我用它测试了演示任务和真实项目。

我的初步印象是，它能够处理长任务，也能协调子智能体而不偏离目标。但它也有不足。官方 Grok Build CLI 给我留下了好印象，而模型生成的部分视觉设计和游戏让我失望。我想把这些实际体验与基准测试的说法区分开。

发布公告称，Grok 4.6 在 4.5 的基础上改进，重点是长时间运行的智能体以及交互和视觉工作。Theo 起初把变化概括为后训练，但他后来阅读的公告还描述了监督微调和强化学习之前更长的补充训练。因此，这次发布涉及的内容比简单的概括更多。

公告中的图表显示，Grok 4.6 在 Artificial Analysis Intelligence Index 上得到 61 分，与 GPT-5.6 Sol 持平，高于该比较中 Grok 4.5 的 56 分。这类指数可以提供背景，但不能完整衡量模型在特定工作流中是否好用。我自己对模型的体验有时就与分数不一致。

图中 DeepSWE 的结果从 Grok 4.5 的 54% 升至 4.6 的 65.9%，FrontierCode 则从 56.6% 升至 61.3%。CursorBench 也有所提高。我提到早期基准可能受到训练数据污染，并表示不确定展示的版本是否解决了这个问题；解读比较结果时需要保留这种不确定性。

发布时，Grok 4.6 可通过 Cursor 和 Grok Build 使用，首周还提供了临时增加的使用额度。我一直使用 X 订阅包含的额度制作小游戏，也让它参与 T3 Code 的 Grok 集成工作。可用性、订阅权益和价格反映的是当时情况，之后可能变化。

公告介绍了使用精选的模型生成推理和工程数据进行补充训练，随后开展监督微调和智能体强化学习。任务涵盖编程、知识工作及专业环境。公司表示在长任务中观察到更多自检；但在我的游戏实验里，这一点并不稳定。

发布说明还提到了扩大的安全评估。为了尝试实际任务，我让模型审计 Lakebed 的安全状况，判断项目是否准备好发布。等待期间，我查看厂商给出的比较表：不同基准中的模型排名并不相同。

Artificial Analysis 报告称，Grok 4.6 的指数比 4.5 提高了 5 分，在这一指数上接近其他领先模型。Theo 还提到对未来 4.7 发布的预测，但那只是录制时的预期，并非已经证实的结果。基准、发布日期和排名都应视为当时的快照。

画面中的价格是每百万输入 token 2 美元、每百万输出 token 6 美元；在 Artificial Analysis 的特定评估中，估计每项任务花费 0.84 美元。这是基准测试的成本估计，不是订阅价格，也不能保证适用于其他工作负载。图中同一测试给出的 Grok 4.5 成本约为 0.36 美元。

虽然公布的输入和输出单价没有变化，但图中每项任务的成本上升了。我在自己的测试中也注意到 token 用量更高、完成时间更长：4.5 常常快得惊人，4.6 则更像是需要先把任务发出去、稍后再回来查看。Token 用量、缓存费用和速度都会影响实际成本。

画面中的模型资料列出 50 万 token 的上下文窗口。价格截图显示，4.6 的缓存输入每百万 token 为 0.50 美元，4.5 为 0.30 美元；这与我口述的数字不同。上述都是录制时的数字，实际成本取决于提供商、缓存使用情况和工作负载。

接下来我查看生成的界面设计，看看不同模型是否会产生不同的视觉风格。展示的未使用设计 skill 的例子，在我看来不够协调或过于普通：背景噪声重、卡片太多，而且布局有熟悉的模板感。

加入设计 skill 后，有些例子有所改善，另一些仍然不合我的口味。在这组样本里，我更喜欢 Fable 和其他模型生成的对照设计。这是对部分输出的主观评价，不是受控的设计基准，也不能代表所有提示词的结果。

我还让模型以旧代码库为参考，重新构建水族箱游戏 Fish Slop。这是我喜欢的个人测试，因为游戏结合了交互、节奏、视觉和多个系统。Grok 的 2D 版本在比例、控制、选中状态和游戏节奏上，都让我不太满意。

第一个 3D 尝试打开后是黑屏。我把截图发给模型并要求修复，同时也借此试用了 Grok Build CLI 的图片显示。之后它渲染出了场景，但我试玩的版本仍然存在控制方向和物体摆放错误。

我把结果与其他模型的 3D 尝试作了比较。它们也有缺陷，但在我的示例中，其他模型生成了功能更完整的场景和更好的鱼模型。这只是少量独立运行的结果，展示的是我在这个任务上的体验，不能据此得出普遍排名。

真实代码任务的表现更有希望。Lakebed 审计在 Git 历史中找到了先前的审计，并列出身份处理和生产环境隔离等发布风险。我认为它做得不错，尽管遗漏了更深层的问题。智能体审计是人工复核的起点，不能证明系统安全。

我让 Grok 检查 T3 Code 的 Cursor 集成，以及从旧 ACP 适配器迁移到 Cursor SDK 的可能方案。报告指出了几个与我们实际遇到的问题相符的情况，也列出功能和认证方面的取舍。这些是模型在特定调查中的发现，并不是对 SDK 当前能力的独立验证。

我还遇到了自己的集成问题：客户端在计划审批时断开连接，计划也没有出现在预期位置。这很烦人，也说明除了模型本身，周边的运行框架和界面同样重要。我需要改进 T3 Code 对 Grok 事件和计划模式的处理。

在另一个任务中，我询问 T3 Code 的 Grok Build 实现还有哪些缺口。模型制定计划、响应反馈并提交拉取请求，我又让它跟进审查。有些事件在界面中被不合适地折叠，但这个例子中的长流程基本遵循了我的指示。

接着我要求它检查我自己的会话历史，寻找更多事件处理缺口，并创建一个独立的堆叠拉取请求。这需要同时记住先前的改动、新的调查和项目专用指令。我发现 Grok 4.5 在串联多步骤工作方面出人意料地不错，因此也很关注 4.6 的这一能力。

我为成本、智能、速度、彻底程度和编排能力画了一张粗略的个人评分表。在我的体验里，Fable 的智能和编排最强，Sol 特别彻底，Grok 4.5 则以速度和成本突出。这些数字只是非正式的个人印象，并非标准化测量。

对于 4.6，我观察到智能更强、彻底程度有所改善，使用子智能体也还不错，但速度和成本评分低于 4.5。它仍会遗漏问题。由于速度快、任务成本低是 4.5 最吸引我的特点，优势减弱也影响了我对升级的兴趣。

总体而言，Grok 4.6 不是我最喜欢的模型，我预计这次评测后暂时不会大量使用它。我对后续版本很感兴趣，但那是期待，不是已经测得的结果。更多能力强的竞争者和更低的成本对整个生态都有好处，所以我会继续关注。