馬斯克悄悄改了戰場：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大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。