马斯克悄悄改了战场：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 不能只会生成，更要能稳定、连续、可恢复地完成工程任务。

01

Agent 工程化的三类关键修复

把这次更新浓缩来看，最值得关注的是针对三个痛点的优化：会话难恢复、长任务易卡住、工具输出容易污染上下文。而其余对命令补全、图表预览等功能所导致界面错乱现象的修复也都指向同一个目标：让 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 竞争“的迁移，或许已经开始了。