马斯克悄悄改了战场：Grok Build 0.2.60 剑指 Agent Runtime

Grok Build CLI：一次不炫技、但很关键的更新。 作者丨樊天骄、郑佳美 编辑丨郑佳美 2026 年 6 月 21 日，Grok Build 悄悄发布了 0. 2. 60 版本更新。 消息最早由 X 平台技术博主 Mark Kretschmann 披露。 与常见的大版本发布不同，这次更新既没有推出新的模型能力，也没有刷新任何 Benchmark，而是将重心放在会话恢复、上下文压缩、MCP 工具输出等一系列 Runtime 细节上。 这些改动或许不如模型升级那样引人注目，却恰恰指向了 AI 编程工具竞争的新焦点。 因为当模型能力逐渐趋同时，真正决定 Agent 体验的往往不再是它有多聪明，而是它能否稳定、持续地完成工作。 而要理解这种变化为何重要，就需要先回顾 AI 编程工具竞争重心是如何一步步发生迁移的。 Coding Agent 的发展历程总结来说分为三个阶段。 早期开发者的研究重心放在其写代码的能力上，大家更多关注的是 AI 是否能补全代码和生成函数。 随后阶段大家的关注点则转向它是否可以独自完成工作流，如理解项目结构的，完成跨文件修改，并跑通测试。

到了 Agent 阶段，开发者真正考验的是系统能否长时间稳定接活：在多个仓库之间正确恢复上下文，在任务执行过程中保持可控，在调用外部工具后不被海量日志和结果拖垮，并能在半自动化甚至无人值守场景中持续运行。 Grok Build 正是在这个背景下出现的。 它不是一个单纯的聊天式编程助手，而是运行在终端中的 Coding Agent，目标是参与真实且完整的软件工程流程：理解仓库、制定计划、调用工具、修改文件、运行命令、等待用户确认，再继续推进任务。 xAI 官方资料显示，Grok Build 支持交互式使用、脚本化运行、外部工具接入和多会话管理，这意味着 Grok Build 0. 2. 60 的价值并不在于让代码生成看起来更漂亮，而在于能不能把一个项目任务稳定地执行下去。 因此 Agent 处理的问题并非代码错误，而大多来源于人们工作的场景。 比如开发者在多个 Repo 之间切换时，需要恢复到正确的 Session；长任务跑久之后，需要上下文压缩机制不拖垮流程；工具返回大量结果时，需要系统把信息整理好，而不是一股脑塞回模型。

总而言之，本次更新强调的是一个更现实的方向：AI Coding Agent 不能只会生成，更要能稳定、连续、可恢复地完成工程任务。 01Agent 工程化的三类关键修复把这次更新浓缩来看，最值得关注的是针对三个痛点的优化：会话难恢复、长任务易卡住、工具输出容易污染上下文。 而其余对命令补全、图表预览等功能所导致界面错乱现象的修复也都指向同一个目标：让 AI 编程助手在真实开发工作流中更稳定、更可控。 最典型的是会话恢复。 对 Coding Agent 来说，一个 Session 不只是简单的聊天记录，它往往包含仓库结构、用户意图、运行过的命令、未完成的修改和后续计划等关键信息。 如果开发者同时在多个 Repo 之间切换，而 /resume 展示的仍是全局 Session 列表，用户就需要自己判断哪个 session 属于当前项目。 这个过程不仅麻烦，也容易接错上下文。 0. 2. 60 的修复方式很直接：/resume 会把当前工作目录所属 Repo 的 Sessions 放在顶部。 这个功能并不复杂，但非常符合开发者心智。

使用者进入某个项目目录，通常就是要继续这个项目的工作；Agent 如果也能以 Repo 为边界组织记忆，就能显著减少用户在上下文恢复上的负担。 另一个关键问题是长任务卡顿。 Agent 运行时间越长，积累的对话、工具调用、文件读取和测试输出就会越多。 系统必须定期压缩历史信息，让模型继续在可控的上下文窗口内工作。 xAI 官方文档中的 Context Compaction 能力，目标就是把长对话压缩成可复用的 Opaque Item，以降低输入成本并减少延迟，让长 Agent Loops 保持可持续。 但在实际 CLI 工作流中，Compaction 也可能成为新的阻塞点。 如果负责生成摘要的 Summarizer 输出流停住，压缩过程就可能一直等待，导致整个任务无法继续。 0. 2. 60 修复了 Compaction 在 Summarizer Stream Stalls 时无限挂起的问题。 公开资料没有披露具体机制，因此不能断言它采用了超时、重试或 Fallback；但从结果看，这次修复至少避免了“维护上下文的机制反过来拖死任务”的情况。 Queued Prompts 的修复也属于同一类可靠性问题。

Agent 正在执行任务时，开发者经常会提前输入下一步指令，让系统排队等待处理。 如果用户删除了队列里的最后一条提示词，再重新添加新提示词，系统却不能可靠显示，用户就会怀疑自己的指令是否丢失。 0. 2. 60 改善了这种边界状态：当队列从有内容变为空，再重新加入内容时，提示词能够稳定地回到队列里。 对长时间使用 Agent 的开发者来说，这种稳定性会直接影响他们是否敢把下一步工作放心交给系统。 MCP 相关优化则更具工程化代表性。 本质上MCP 的作用是让 Agent 能够接入外部工具、数据源和服务，比如读取文件、查询日志、获取测试输出或调用开发环境中的其他能力。 但问题在于，上述这些工具返回的内容往往不可控：一次测试失败可能产生几百行日志，一个文件读取可能带回大量代码，一次查询也可能返回很长的结果。 如果这些内容被完整塞进模型上下文，不仅会迅速占用上下文空间，还会让模型在后续推理时被大量低价值信息干扰。 0. 2. 60 对这一点做了更稳妥的处理：大型 MCP 工具结果不会再完整内联进入上下文，而是先截断展示，把完整结果保存到磁盘。

雷峰网这样，模型仍然能看到必要的摘要或片段，知道工具调用发生了什么；完整原始材料也没有丢失，只是从模型上下文中移到了外部文件里。 它的意义在于把“模型需要立刻推理的信息”和“系统需要保留的完整资料”分开，避免工具输出把上下文拖得过重，也减少不必要的 Context Compaction。 02新变化集中在 Agent Runtime 的可靠性层如果只把 0. 2. 60 视作一次普通版本更新，其实很容易忽略它真正的价值。 它最重要的变化并非引入新的模型能力，而是在持续完善 Grok Build 的 Agent Runtime。 无论是会话恢复、上下文压缩还是任务状态管理，这些更新都指向同一个目标：让 Agent 能够稳定地持续工作。 在记忆组织层面，/resume 会优先显示当前工作目录所属 Repo 的 Sessions。 其背后的逻辑并不复杂：AI 编程助手的工作记忆不应仅按照时间排序，而应围绕项目本身组织。 开发者进入某个仓库时，Agent 优先呈现该项目相关的历史任务和上下文，这是 AI 编程工具从聊天助手走向工程助手的重要一步。

雷峰网在状态维护层面，Compaction 和 Queued Prompts 的修复解决的是同一个问题：Agent 在长时间运行过程中，不能被自身机制拖垮。 当上下文持续增长时，压缩本应是一种保障任务连续性的能力，而不是新的阻塞源；同样，用户提前排队的指令也不应该因为状态变化而丢失。 两项修复共同指向的是运行稳定性的提升。 在上下文治理层面，对大型 MCP 工具结果进行截断展示并落盘保存，则体现出另一种工程思路：模型上下文应服务于当前推理，而不是承担数据仓库的职责。 早期 AI 工具往往将工具返回结果直接塞进对话窗口，这种方式在简单任务中足够有效。 但在真实开发场景里，日志、测试结果和文件输出会迅速膨胀，占满上下文窗口并干扰模型判断。 将大体量数据存储到外部介质，只将必要信息保留在上下文中，本质上是在建立计算与存储的边界，这也是 Agent 系统走向工程化的重要标志。 从这个角度看，0. 2. 60 的意义并不在于新增了什么能力，而在于让 Agent 更接近一个可靠的工作系统。 当 AI 从展示智能走向承担工作，评价标准也会随之改变。 决定工具价值的，不再只是模型有多聪明，而是它能否在高频、复杂和长周期任务中持续稳定地运行。

03少找、少等、少被噪音打断纵观市场上的同类产品，几乎所有技术更新最终都要回到用户体验。 而 Grok Build 这次更新的核心目标也不例外：开发者能否放心把任务交给 Agent，然后去做别的事情。 并且这个目标的完成度可以从三个使用节点得到验证。 第一个节点：重新开始。 过去，开发者第二天打开 Grok Build，或从另一个项目切换回来时，往往需要在历史记录里翻找对应的 Session。 如今，/resume 会优先展示当前 Repo 相关会话，让开发者进入项目后能够快速接续此前的工作，大幅度降低重新进入任务的成本。 Agent 不仅要记住问题，更要记住工作。 第二个节点：执行过程中。 长任务运行时，开发者最担心的从来不是速度，而是不确定性——任务究竟还在推进，还是已经卡死？ Compaction 修复解决了上下文压缩过程中可能出现的无限挂起问题，而 Queued Prompts 的改进则保证排队指令能够被稳定保留和执行。 与此同时，运行中的子任务也获得了更细粒度的控制能力：取消主任务时，开发者可以自主决定并行子任务是立即终止还是继续完成。 这些改动共同指向一个目标：让 Agent 的运行状态变得更可靠、更可预期。

当用户能够安心离开电脑，而不用时不时回来确认任务是否还活着，Agent 才真正具备了承接工作的能力。 第三个节点：查看结果。 过去，工具调用返回的大量日志、文件和查询结果往往会被直接塞进上下文窗口，不仅占用宝贵的上下文空间，也容易干扰后续推理。 现在，大型 MCP 工具结果会被截断展示，完整内容则保存到磁盘。 模型只处理当前任务真正需要的信息，开发者也能更高效地查看关键结果。 这种变化看似细微，却体现出 Agent 系统逐渐形成了计算与存储分离的工程思路。 除了这些核心改进之外，命令补全一致性、Mermaid 图表展示、快捷键行为以及签名提交等细节也都获得了优化。 单个改动或许并不起眼，但它们共同决定了一件事：开发者是否愿意每天打开这个工具。 当模型能力逐渐趋同，用户很少会因为某个炫酷功能留下来，却经常会因为不断出现的小摩擦而离开。 对于 Agent 产品而言，真正建立竞争壁垒的往往不是一次能力跃迁，而是持续消除使用过程中的不确定性。 04从模型到 Runtime 的竞争Grok Build 0. 2.

60 的意义，不在于发布了什么颠覆性功能，而在于它让人们看到了 AI 编程工具正在发生的一种变化：行业关注的重点，正在从模型能力转向 Agent Runtime。 纵观这次更新，无论是会话恢复、状态维护，还是上下文治理，解决的都不是“Agent 会不会写代码”的问题，而是“Agent 能不能持续工作”的问题。 当 AI 开始承担越来越复杂、越来越长周期的任务时，稳定性、可控性和可靠性的重要性，正在迅速超过单纯的模型能力。 这或许也是 AI 编程工具下一阶段竞争的方向。 过去几年，行业拼的是参数规模、上下文长度和 Benchmark 排名；而未来真正拉开差距的，可能是任务是否能够稳定执行、状态是否能够持续保存、系统是否能够支撑开发者将工作放心交出去。 换句话说，Agent 的价值不在于偶尔展现惊人的智能，而在于能够像一个可靠的同事一样，把工作持续、稳定地做完。 而这场从“模型竞争”到“Runtime 竞争”的迁移，或许已经开始了。 参考链接：https://x. com/mark_k/status/2068776879767818628https://x.

ai/news/grok-build-cli上车，带你看遍全球 AI 顶会精华可独家畅览：专家演讲PPT大会报告全文热门论文解读学术新星访谈扫描上方二维码或点击「阅读原文」关注专区。