<mark id="oztn4"></mark>
0
作者丨樊天驕、鄭佳美
編輯丨鄭佳美
2026 年 6 月 21 日，Grok Build 悄悄發(fā)布了 0.2.60 版本更新。消息最早由 X 平臺技術(shù)博主 Mark Kretschmann 披露。
與常見的大版本發(fā)布不同，這次更新既沒有推出新的模型能力，也沒有刷新任何 Benchmark，而是將重心放在會話恢復(fù)、上下文壓縮、MCP 工具輸出等一系列 Runtime 細(xì)節(jié)上。
這些改動或許不如模型升級那樣引人注目，卻恰恰指向了 AI 編程工具競爭的新焦點(diǎn)。因?yàn)楫?dāng)模型能力逐漸趨同時(shí)，真正決定 Agent 體驗(yàn)的往往不再是它有多聰明，而是它能否穩(wěn)定、持續(xù)地完成工作。
而要理解這種變化為何重要，就需要先回顧 AI 編程工具競爭重心是如何一步步發(fā)生遷移的。
Coding Agent 的發(fā)展歷程總結(jié)來說分為三個(gè)階段。早期開發(fā)者的研究重心放在其寫代碼的能力上，大家更多關(guān)注的是 AI 是否能補(bǔ)全代碼和生成函數(shù)。隨后階段大家的關(guān)注點(diǎn)則轉(zhuǎn)向它是否可以獨(dú)自完成工作流，如理解項(xiàng)目結(jié)構(gòu)的，完成跨文件修改，并跑通測試。
到了 Agent 階段，開發(fā)者真正考驗(yàn)的是系統(tǒng)能否長時(shí)間穩(wěn)定接活：在多個(gè)倉庫之間正確恢復(fù)上下文，在任務(wù)執(zhí)行過程中保持可控，在調(diào)用外部工具后不被海量日志和結(jié)果拖垮，并能在半自動化甚至無人值守場景中持續(xù)運(yùn)行。
Grok Build 正是在這個(gè)背景下出現(xiàn)的。它不是一個(gè)單純的聊天式編程助手，而是運(yùn)行在終端中的 Coding Agent，目標(biāo)是參與真實(shí)且完整的軟件工程流程：理解倉庫、制定計(jì)劃、調(diào)用工具、修改文件、運(yùn)行命令、等待用戶確認(rèn)，再繼續(xù)推進(jìn)任務(wù)。
xAI 官方資料顯示，Grok Build 支持交互式使用、腳本化運(yùn)行、外部工具接入和多會話管理，這意味著 Grok Build 0.2.60 的價(jià)值并不在于讓代碼生成看起來更漂亮，而在于能不能把一個(gè)項(xiàng)目任務(wù)穩(wěn)定地執(zhí)行下去。
因此 Agent 處理的問題并非代碼錯(cuò)誤，而大多來源于人們工作的場景。比如開發(fā)者在多個(gè) Repo 之間切換時(shí)，需要恢復(fù)到正確的 Session；長任務(wù)跑久之后，需要上下文壓縮機(jī)制不拖垮流程；工具返回大量結(jié)果時(shí)，需要系統(tǒng)把信息整理好，而不是一股腦塞回模型。
總而言之，本次更新強(qiáng)調(diào)的是一個(gè)更現(xiàn)實(shí)的方向：AI Coding Agent 不能只會生成，更要能穩(wěn)定、連續(xù)、可恢復(fù)地完成工程任務(wù)。
01
把這次更新濃縮來看，最值得關(guān)注的是針對三個(gè)痛點(diǎn)的優(yōu)化：會話難恢復(fù)、長任務(wù)易卡住、工具輸出容易污染上下文。而其余對命令補(bǔ)全、圖表預(yù)覽等功能所導(dǎo)致界面錯(cuò)亂現(xiàn)象的修復(fù)也都指向同一個(gè)目標(biāo)：讓 AI 編程助手在真實(shí)開發(fā)工作流中更穩(wěn)定、更可控。
最典型的是會話恢復(fù)。對 Coding Agent 來說，一個(gè) Session 不只是簡單的聊天記錄，它往往包含倉庫結(jié)構(gòu)、用戶意圖、運(yùn)行過的命令、未完成的修改和后續(xù)計(jì)劃等關(guān)鍵信息。
如果開發(fā)者同時(shí)在多個(gè) Repo 之間切換，而 /resume 展示的仍是全局 Session 列表，用戶就需要自己判斷哪個(gè) session 屬于當(dāng)前項(xiàng)目。這個(gè)過程不僅麻煩，也容易接錯(cuò)上下文。
0.2.60 的修復(fù)方式很直接：/resume 會把當(dāng)前工作目錄所屬 Repo 的 Sessions 放在頂部。這個(gè)功能并不復(fù)雜，但非常符合開發(fā)者心智。使用者進(jìn)入某個(gè)項(xiàng)目目錄，通常就是要繼續(xù)這個(gè)項(xiàng)目的工作；Agent 如果也能以 Repo 為邊界組織記憶，就能顯著減少用戶在上下文恢復(fù)上的負(fù)擔(dān)。
另一個(gè)關(guān)鍵問題是長任務(wù)卡頓。Agent 運(yùn)行時(shí)間越長，積累的對話、工具調(diào)用、文件讀取和測試輸出就會越多。系統(tǒng)必須定期壓縮歷史信息，讓模型繼續(xù)在可控的上下文窗口內(nèi)工作。
xAI 官方文檔中的 Context Compaction 能力，目標(biāo)就是把長對話壓縮成可復(fù)用的 Opaque Item，以降低輸入成本并減少延遲，讓長 Agent Loops 保持可持續(xù)。但在實(shí)際 CLI 工作流中，Compaction 也可能成為新的阻塞點(diǎn)。如果負(fù)責(zé)生成摘要的 Summarizer 輸出流停住，壓縮過程就可能一直等待，導(dǎo)致整個(gè)任務(wù)無法繼續(xù)。
0.2.60 修復(fù)了 Compaction 在 Summarizer Stream Stalls 時(shí)無限掛起的問題。公開資料沒有披露具體機(jī)制，因此不能斷言它采用了超時(shí)、重試或 Fallback；但從結(jié)果看，這次修復(fù)至少避免了“維護(hù)上下文的機(jī)制反過來拖死任務(wù)”的情況。
Queued Prompts 的修復(fù)也屬于同一類可靠性問題。Agent 正在執(zhí)行任務(wù)時(shí)，開發(fā)者經(jīng)常會提前輸入下一步指令，讓系統(tǒng)排隊(duì)等待處理。如果用戶刪除了隊(duì)列里的最后一條提示詞，再重新添加新提示詞，系統(tǒng)卻不能可靠顯示，用戶就會懷疑自己的指令是否丟失。
0.2.60 改善了這種邊界狀態(tài)：當(dāng)隊(duì)列從有內(nèi)容變?yōu)榭眨僦匦录尤雰?nèi)容時(shí)，提示詞能夠穩(wěn)定地回到隊(duì)列里。對長時(shí)間使用 Agent 的開發(fā)者來說，這種穩(wěn)定性會直接影響他們是否敢把下一步工作放心交給系統(tǒng)。
MCP 相關(guān)優(yōu)化則更具工程化代表性。本質(zhì)上MCP 的作用是讓 Agent 能夠接入外部工具、數(shù)據(jù)源和服務(wù)，比如讀取文件、查詢?nèi)罩尽@取測試輸出或調(diào)用開發(fā)環(huán)境中的其他能力。
但問題在于，上述這些工具返回的內(nèi)容往往不可控：一次測試失敗可能產(chǎn)生幾百行日志，一個(gè)文件讀取可能帶回大量代碼，一次查詢也可能返回很長的結(jié)果。如果這些內(nèi)容被完整塞進(jìn)模型上下文，不僅會迅速占用上下文空間，還會讓模型在后續(xù)推理時(shí)被大量低價(jià)值信息干擾。
0.2.60 對這一點(diǎn)做了更穩(wěn)妥的處理：大型 MCP 工具結(jié)果不會再完整內(nèi)聯(lián)進(jìn)入上下文，而是先截?cái)嗾故荆淹暾Y(jié)果保存到磁盤。雷峰網(wǎng)(公眾號：雷峰網(wǎng))
這樣，模型仍然能看到必要的摘要或片段，知道工具調(diào)用發(fā)生了什么；完整原始材料也沒有丟失，只是從模型上下文中移到了外部文件里。它的意義在于把“模型需要立刻推理的信息”和“系統(tǒng)需要保留的完整資料”分開，避免工具輸出把上下文拖得過重，也減少不必要的 Context Compaction。
02
如果只把 0.2.60 視作一次普通版本更新，其實(shí)很容易忽略它真正的價(jià)值。它最重要的變化并非引入新的模型能力，而是在持續(xù)完善 Grok Build 的 Agent Runtime。無論是會話恢復(fù)、上下文壓縮還是任務(wù)狀態(tài)管理，這些更新都指向同一個(gè)目標(biāo)：讓 Agent 能夠穩(wěn)定地持續(xù)工作。
在記憶組織層面，/resume 會優(yōu)先顯示當(dāng)前工作目錄所屬 Repo 的 Sessions。其背后的邏輯并不復(fù)雜：AI 編程助手的工作記憶不應(yīng)僅按照時(shí)間排序，而應(yīng)圍繞項(xiàng)目本身組織。開發(fā)者進(jìn)入某個(gè)倉庫時(shí)，Agent 優(yōu)先呈現(xiàn)該項(xiàng)目相關(guān)的歷史任務(wù)和上下文，這是 AI 編程工具從聊天助手走向工程助手的重要一步。雷峰網(wǎng)
在狀態(tài)維護(hù)層面，Compaction 和 Queued Prompts 的修復(fù)解決的是同一個(gè)問題：Agent 在長時(shí)間運(yùn)行過程中，不能被自身機(jī)制拖垮。當(dāng)上下文持續(xù)增長時(shí)，壓縮本應(yīng)是一種保障任務(wù)連續(xù)性的能力，而不是新的阻塞源；同樣，用戶提前排隊(duì)的指令也不應(yīng)該因?yàn)闋顟B(tài)變化而丟失。兩項(xiàng)修復(fù)共同指向的是運(yùn)行穩(wěn)定性的提升。
在上下文治理層面，對大型 MCP 工具結(jié)果進(jìn)行截?cái)嗾故静⒙浔P保存，則體現(xiàn)出另一種工程思路：模型上下文應(yīng)服務(wù)于當(dāng)前推理，而不是承擔(dān)數(shù)據(jù)倉庫的職責(zé)。
早期 AI 工具往往將工具返回結(jié)果直接塞進(jìn)對話窗口，這種方式在簡單任務(wù)中足夠有效。但在真實(shí)開發(fā)場景里，日志、測試結(jié)果和文件輸出會迅速膨脹，占滿上下文窗口并干擾模型判斷。
將大體量數(shù)據(jù)存儲到外部介質(zhì)，只將必要信息保留在上下文中，本質(zhì)上是在建立計(jì)算與存儲的邊界，這也是 Agent 系統(tǒng)走向工程化的重要標(biāo)志。
從這個(gè)角度看，0.2.60 的意義并不在于新增了什么能力，而在于讓 Agent 更接近一個(gè)可靠的工作系統(tǒng)。當(dāng) AI 從展示智能走向承擔(dān)工作，評價(jià)標(biāo)準(zhǔn)也會隨之改變。決定工具價(jià)值的，不再只是模型有多聰明，而是它能否在高頻、復(fù)雜和長周期任務(wù)中持續(xù)穩(wěn)定地運(yùn)行。
03
縱觀市場上的同類產(chǎn)品，幾乎所有技術(shù)更新最終都要回到用戶體驗(yàn)。而 Grok Build 這次更新的核心目標(biāo)也不例外：開發(fā)者能否放心把任務(wù)交給 Agent，然后去做別的事情。并且這個(gè)目標(biāo)的完成度可以從三個(gè)使用節(jié)點(diǎn)得到驗(yàn)證。
第一個(gè)節(jié)點(diǎn)：重新開始。過去，開發(fā)者第二天打開 Grok Build，或從另一個(gè)項(xiàng)目切換回來時(shí)，往往需要在歷史記錄里翻找對應(yīng)的 Session。如今，/resume 會優(yōu)先展示當(dāng)前 Repo 相關(guān)會話，讓開發(fā)者進(jìn)入項(xiàng)目后能夠快速接續(xù)此前的工作，大幅度降低重新進(jìn)入任務(wù)的成本。Agent 不僅要記住問題，更要記住工作。
第二個(gè)節(jié)點(diǎn)：執(zhí)行過程中。長任務(wù)運(yùn)行時(shí)，開發(fā)者最擔(dān)心的從來不是速度，而是不確定性——任務(wù)究竟還在推進(jìn)，還是已經(jīng)卡死？
Compaction 修復(fù)解決了上下文壓縮過程中可能出現(xiàn)的無限掛起問題，而 Queued Prompts 的改進(jìn)則保證排隊(duì)指令能夠被穩(wěn)定保留和執(zhí)行。與此同時(shí)，運(yùn)行中的子任務(wù)也獲得了更細(xì)粒度的控制能力：取消主任務(wù)時(shí)，開發(fā)者可以自主決定并行子任務(wù)是立即終止還是繼續(xù)完成。
這些改動共同指向一個(gè)目標(biāo)：讓 Agent 的運(yùn)行狀態(tài)變得更可靠、更可預(yù)期。當(dāng)用戶能夠安心離開電腦，而不用時(shí)不時(shí)回來確認(rèn)任務(wù)是否還活著，Agent 才真正具備了承接工作的能力。
第三個(gè)節(jié)點(diǎn)：查看結(jié)果。過去，工具調(diào)用返回的大量日志、文件和查詢結(jié)果往往會被直接塞進(jìn)上下文窗口，不僅占用寶貴的上下文空間，也容易干擾后續(xù)推理。
現(xiàn)在，大型 MCP 工具結(jié)果會被截?cái)嗾故荆暾麅?nèi)容則保存到磁盤。模型只處理當(dāng)前任務(wù)真正需要的信息，開發(fā)者也能更高效地查看關(guān)鍵結(jié)果。這種變化看似細(xì)微，卻體現(xiàn)出 Agent 系統(tǒng)逐漸形成了計(jì)算與存儲分離的工程思路。
除了這些核心改進(jìn)之外，命令補(bǔ)全一致性、Mermaid 圖表展示、快捷鍵行為以及簽名提交等細(xì)節(jié)也都獲得了優(yōu)化。
單個(gè)改動或許并不起眼，但它們共同決定了一件事：開發(fā)者是否愿意每天打開這個(gè)工具。
當(dāng)模型能力逐漸趨同，用戶很少會因?yàn)槟硞€(gè)炫酷功能留下來，卻經(jīng)常會因?yàn)椴粩喑霈F(xiàn)的小摩擦而離開。對于 Agent 產(chǎn)品而言，真正建立競爭壁壘的往往不是一次能力躍遷，而是持續(xù)消除使用過程中的不確定性。
04
Grok Build 0.2.60 的意義，不在于發(fā)布了什么顛覆性功能，而在于它讓人們看到了 AI 編程工具正在發(fā)生的一種變化：行業(yè)關(guān)注的重點(diǎn)，正在從模型能力轉(zhuǎn)向 Agent Runtime。
縱觀這次更新，無論是會話恢復(fù)、狀態(tài)維護(hù)，還是上下文治理，解決的都不是“Agent 會不會寫代碼”的問題，而是“Agent 能不能持續(xù)工作”的問題。當(dāng) AI 開始承擔(dān)越來越復(fù)雜、越來越長周期的任務(wù)時(shí)，穩(wěn)定性、可控性和可靠性的重要性，正在迅速超過單純的模型能力。
這或許也是 AI 編程工具下一階段競爭的方向。過去幾年，行業(yè)拼的是參數(shù)規(guī)模、上下文長度和 Benchmark 排名；而未來真正拉開差距的，可能是任務(wù)是否能夠穩(wěn)定執(zhí)行、狀態(tài)是否能夠持續(xù)保存、系統(tǒng)是否能夠支撐開發(fā)者將工作放心交出去。
換句話說，Agent 的價(jià)值不在于偶爾展現(xiàn)驚人的智能，而在于能夠像一個(gè)可靠的同事一樣，把工作持續(xù)、穩(wěn)定地做完。而這場從“模型競爭”到“Runtime 競爭”的遷移，或許已經(jīng)開始了。
參考鏈接：
https://x.com/mark_k/status/2068776879767818628
https://x.ai/news/grok-build-cli
上車，帶你看遍全球 AI 頂會精華
可獨(dú)家暢覽：
專家演講PPT
大會報(bào)告全文
熱門論文解讀
學(xué)術(shù)新星訪談
掃描上方二維碼
或點(diǎn)擊「閱讀原文」關(guān)注專區(qū)。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
