Grok 4.6 跳票，Musk 先甩出 Grok Build V1.0

北京时间 8 月 7 日下午 1 点 12 分，："Grok Build V1.0 is now released. Try it out!" 帖子发布后数小时内获得超过 6700 次点赞和 240 万次浏览。同一天，，列出一长串修复与功能改进。

但社区真正在等的不是这个。

多位 X 用户指出，Musk 此前曾承诺 Grok 4.6 模型"around August 7"发布。8 月 7 日真正到站的，是终端编程代理 Grok Build 的 V1.0 版本号。科技博主 Eyisha Zyer 在她的分析中指出，底层模型仍是 5 月起就在跑的 Grok 4.5，V1.0 的 changelog 里"没有新模型，没有新 benchmark"。

模型跳票的质疑，与"比 Claude Code 更轻"的实测

最先点出这个落差的是 X 用户："Musk promised Grok 4.6 'around August 7'. That's today. Grok 4.6? Still not in xAI's docs. What shipped instead: Grok Build V1.0 — their terminal coding agent. The model slipped. The harness didn't."

拥有 12.7 万关注者的科技博主逐条读完官方 changelog 后给出了更细致的拆解："Every item is UI polish and reliability fixes — dashboard summaries, table rendering, session handling. No new model, no new benchmark."

她指出，Grok Build 在 SWE-Bench Verified 上的唯一公开成绩仍是发布时的 70.8%，且为 xAI 内部数据；第三方测试中落后 Claude Opus 4.7 和 GPT-5.5 约 15-18 个百分点。

开发者则从实际体验出发给出了不同的衡量维度。他对比了三款终端编程代理的内存占用：Grok Build 180MB、OpenAI Codex 200MB、OpenCode 800MB。"Grok Build v1.0 by far is the most efficient + less buggy harness I know," 他写道，并称 Codex 的 API 格式与其工具链不兼容，Grok Build 是 OpenCode 的最佳替代品。

从 0.2.111 到 V1.0：一个终端工具的日常发育

V1.0 版本号容易让人联想到重大升级，但 Grok Build 的实际发育节奏更接近"持续交付，某天挂上里程碑"。

根据 changelog 记录，该工具最早的可追溯公开发布约在 7 月 22 日的 v0.2.111 版本，此后几乎每天都有新版本推送：v0.2.112（7/24）新增 /tutorial 引导流程和 /doctor 诊断命令；v0.2.113（7/28）支持 MCP 服务器动态开关和自动循环恢复；v0.2.115（7/29）修复了聊天历史损坏这一严重 bug；v0.2.120（8/3）优化了模型切换响应和后台任务内存。

到 8 月 7 日的 v1.0.0，仅 changelog 可查的公开版本已有至少 10 个。Eyisha Zyer 提供了一个更长的视野：据她统计，Grok Build 自今年 5 月首次亮相以来已累计超过 100 个 pre-release 版本。她还指出，当时 xAI 宣布将工具"开源"，但实际开源的只是 CLI 前端框架（harness），底层模型从未开放。此后三个月的密集更新，本质上是对这个框架的持续加固。

这个背景解释了为什么 V1.0 的 changelog 里没有新模型、没有新 benchmark——它从来就不是一个模型发布，而是一个工具的成熟度宣言。

权限透明化、大目录沙盒、远程恢复：这次不只是修 bug

尽管没有模型层面的突破，V1.0.0 的更新日志里有几个变化直接触及了终端编程代理在真实工作流中的痛点。

权限提示现在展示完整脚本。此前 Grok Build 在执行 bash 命令前会弹出权限确认，但只显示命令摘要。V1.0 改为展示完整脚本正文，长命令可按 Ctrl-F 展开。这一改动直接回应了开发者对代理"偷偷执行了什么"的信任焦虑。

MCP 图像工具不再丢图。MCP（Model Context Protocol）服务器返回的截图此前可能被丢弃或损坏，v1.0.0 修复了这一缺陷。对于依赖 MCP 接入浏览器自动化、设计稿审查等图像密集场景的团队，这是一个阻塞级的修复。

沙盒在大目录上不再卡死。当目录包含大量 deny-glob 匹配规则时，沙盒化 Grok 的启动曾严重延迟。v1.0.0 优化了启动路径，让安全隔离在实际项目中可用。

远程恢复行为变更。remote resume 现在默认只恢复对话历史，除非显式传入 --restore-code 参数。这个行为变更减少了意外恢复代码库状态的风险，属于那种改了一行就能救一下午的修复。

此外还有自动主题检测在 SSH/tmux 下正常工作、Markdown 表格在窄终端自适应换行而非截断、CJK 文字鼠标选中不再丢字符等多项体验改进。

180MB 内存的终端代理，正在咬下 Claude Code 和 Codex 之间的缝隙

终端编程代理赛道目前大致是三方格局：Anthropic 的 Claude Code 以模型能力见长，OpenAI 的 Codex 走 API 集成路线，开源社区的 OpenCode 靠可定制性吸引高级用户。

Grok Build V1.0 选择了一条差异路线：用更少的内存、更高的迭代频率和免费可用策略，切入了"不想折腾开源工具、又觉得 Claude Code 太贵"的中间地带。

Kim Hudaya 的实测数据提供了一个直观参照：同样跑在本地终端里，OpenCode 吃 800MB 内存，Grok Build 只需 180MB。对于同时开着浏览器、IDE、Docker 的开发者来说，这个差距在实际使用中可感知。

但 Eyisha Zyer 的提醒同样成立：Grok Build 目前唯一的公开 benchmark 成绩——SWE-Bench Verified 70.8%——来自 xAI 内部测试，未经独立复现。第三方实测将 Grok Build 排在中游：落后于 Claude Opus 4.7 和 GPT-5.5，领先于 Opus 4.6 和 Gemini 3.1 Pro，但比开源方案快得多。她总结道："The actual pitch here isn't 'smarter' or 'open,' it's cheaper and faster."

Grok Build 中更深的 agentic 功能，Eyisha Zyer 指出，仍锁在每月 300 美元的 SuperGrok Heavy 订阅层级之后。免费层用户能体验到的，是一个运行快速、UI 稳定的终端编程工具，但未必能触达它的全部能力边界。

V1.0 是一张成熟度标签，不是一张能力成绩单

Grok Build V1.0 的发布本质上是一次版本号策略动作：在经历了三个月的每日迭代之后，xAI 告诉开发者社区——这个工具已经足够稳定，可以用于正式项目了。

V1.0 标注的是工具的成熟度，不是模型能力的跃升。Grok 4.6 模型何时到来，以及届时 Grok Build 能否带着一套独立验证的 benchmark 成绩与 Claude Code、Codex 站在同一张桌上，才是下一段故事的开头。