被曝上傳用戶代碼後,馬斯克官宣開源Grok Build,GitHub上線即斬獲7.7k Star

重點摘要
馬斯克旗下的xAI宣布開源代碼智能體Grok Build,完整代碼庫已上傳至GitHub,迅速獲得7.7k星。此舉被視為對先前開發者揭露Grok Build會上傳整個用戶代碼倉庫至伺服器、引發隱私風波的補救回應。xAI同時解除服務器使用限制並支援完全本地運行,讓開發者能審查代碼並自主控制數據流向。
馬斯克旗下 AI 公司 xAI 近日正式宣布,其代碼智能體工具 Grok Build 全面轉為開源,完整原始碼已上傳至 GitHub 平台。該項目上線後立即引發開發者社群關注,短短數小時內即累積超過 7700 個 Star。馬斯克本人也在社群平台上轉發並表示:「Grok Build 現在是開源的。」與此同時,官方同步重置所有用戶的伺服器端使用限制,並支援完全本地端執行,開發者不再受雲端配額限制。這項開源舉動背後,其實隱藏著一段隱私爭議。
就在開源宣布前數日,一名安全研究員 @cereblab 發布了一份詳細的技術分析報告,揭露 Grok Build 在運行過程中會將用戶的完整程式碼倉庫上傳至 xAI 伺服器,即使開發者開啟了隱私設定,這項行為依然會發生。這份報告迅速在 Hacker News 登上熱門榜首,引發大規模討論與質疑,也讓 xAI 的數據處理政策成為焦點。根據該研究員的調查,他針對 Grok Build 0.2.93 版本的網路通訊行為進行封包分析,發現這款主打「本地優先」的命令列工具,在預設設定下會執行三項引人關注的操作。首先,它會將讀取到的檔案內容(包括 .
env 等含有金鑰的設定檔)原封不動發送給 xAI 伺服器,且未進行任何脫敏處理。這些資料透過兩條通道傳輸:即時推理請求(POST /v1/responses)以及會話歸檔上傳(POST /v1/storage)。其次,研究員發現 Grok 會將整個工作目錄打包上傳,而不只是 AI 實際讀取過的檔案。即使提示詞明確要求「不要讀取任何檔案」,工具仍會將整個程式碼倉庫打包成 Git Bundle 並上傳。他透過一個從未讓 Agent 開啟的測試檔案驗證,成功從截獲的 Bundle 中復原出完整內容與 Git 歷史。
更進一步,他建立一個約 12GB 的隨機檔案測試倉庫,結果發現儲存通道實際傳輸了超過 5GB 的資料,而推理通道僅傳輸 192KB,兩者相差約 27800 倍,足以證明大規模上傳確實來自整個程式碼倉庫。第三,這些資料的儲存目的地是 Google Cloud Storage 的 grok-code-session-traces 儲存桶,而非 AWS S3。研究員指出,相關文檔中並未明確說明此上傳機制,且該功能預設啟用,即使關閉「改進模型」選項,上傳行為依然持續。他特別強調,這項分析僅能確認資料確實被傳輸與儲存,無法證明 xAI 是否使用這些資料訓練模型。
面對這項指控,馬斯克本人迅速在社群平台上回應「確有此事」,並承諾將徹底清除相關數據。他表示「任何數據都不會留下」,隨後 xAI 也對外說明,所有此前上傳的用戶數據已經被永久刪除,未來將關閉數據留存機制。正是在這樣的爭議背景下,xAI 選擇將 Grok Build 全面開源,外界普遍視為對隱私風波的補救與回應。此次開源涵蓋 Agent 主循環、工具系統(包括讀取、編輯、搜尋程式碼與執行終端命令)、終端使用者介面(含畫面渲染、執行計劃審核與內聯差異比對檢視器)以及擴充系統(Skills、Plugins、Hooks、MCP Servers 與 Subagents 的載入與運行機制)。
開發者可以自行編譯原始碼,並透過設定檔連接本地推理模型,實現整個 Agent 在本地端執行,數據完全無需經過 xAI 官方伺服器。xAI 表示,開源是打造更強健、更可靠 Agent 框架最直接的方式。開發者不僅可以審查程式碼、驗證工具的真實行為,還能根據自身需求修改實現,建構適合團隊的開發流程。同時官方也取消了伺服器端的使用限制,過去高頻用戶容易觸及調用配額,如今選擇本地部署後,限制主要來自用戶自身的硬體效能。Grok Build 最初於 2026 年 5 月以 Beta 版本發布,定位為一款原生運行在終端的命令列開發工具,採用 Rust 編寫,基於 xAI 最新的 Grok 4.
5 大型語言模型。與 Cursor、GitHub Copilot 等以 IDE 為中心的程式碼助手不同,Grok Build 更類似於 Anthropic 的 Claude Code 與 OpenAI 的 Codex CLI,強調以 Agent 自主完成整個開發流程,而不僅僅是回答程式碼問題。該項目負責人 Andrew Milich 將其定位為「原生面向終端」的代碼智能體,並表示 Rust 程式碼庫全面開放後,開發者不僅能驗證其實際行為,還可以按需修改底層實現,確保所有數據始終保留在本地設備。放眼整個 AI 程式碼工具賽道,競爭正持續升溫。
Anthropic 的 Claude 已具備成熟的程式碼能力,OpenAI 的開發工具不斷融入企業工作流程,Google 的 Gemini 也在積極佈局開發者生態。xAI 則選擇以開源與本地化作為差異化方向。對於許多開發者而言,相比模型能力本身,能夠審計原始碼、自由修改實現,並完全掌控數據流向,同樣是影響工具選型的重要因素。Grok Build 的開源,或許將在這場 AI 程式碼競賽中開闢一條新的路徑。
Related
相關文章

當 human in the loop 變成“閉著眼睛點確認”,企業Agent 安全還能靠誰?
專家指出,AI Agent 從內容安全轉向行為安全,提示詞注入、工具濫用與過度授權成為主要風險。企業應建立可視、可管、可追溯的安全基線,並對工具權限進行最小化與臨時化管理,避免 human in the loop 淪為形式。安全防護需從靜態入口轉向動態行為約束,以因應 Agent 自主執行帶來的全新挑戰。

開源Agent框架刷爆ARC-AGI-3,「自我改進」的RLM harness引爭議
一套開源Agent框架在ARC-AGI-3基準測試中創下超過85%的正確率,大幅領先其他解決方案,其核心是名為「RLM harness」的自我改進機制。然而,該方法引發學術爭議,部分研究者批評它透過反覆試錯「鑽漏洞」,不符合ARC-AGI評測一次性推理的精神。這場討論促使AI社群重新審視評測標準,並可能影響未來ARC-AGI版本的設計方向。

騰訊是在“賽馬”,還是在打造 “Agent工廠”?
騰訊內部正在探討其發展策略究竟是「賽馬」機制還是打造「Agent工廠」。相關討論聚焦於公司如何平衡內部競爭與統一平台建設。目前站內已移除相關混雜文字,保留原始主題供讀者參考。
ChinaJoy 2026 AI遊戲規模化落地,邊緣雲與API安全重構產業底層邏輯
2026年ChinaJoy展館,“與AI同遊”的主題隨處可見。行業調查顯示,僅有21%的企業擁有完整的API資產清單,大量後臺AI接口仍在無人監控的狀態下裸奔。合規與安全也同步下沉。算力下沉還不夠,API安全必須同步前移邊緣雲解決了體驗問題,但AI交互入口的安全,同樣需要前置到邊緣。算力與安全,缺一不可Akamai的判斷很明確:遊戲AI轉型不能割裂算力與安全。這也是遊戲廠商規模化落地AI智能體、構建AI原生遊戲的標準化底層方案。

openJiuwen發佈業界首個企業級分佈式蜂群架構,聯合郵儲成功落地金融生產環境
< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.

螞蟻集團開源Avernet,讓人與智能體像組織一樣高效協作
**螞蟻集團開源Avernet:打造人與智能體高效協作的“組織級”基礎設施** **來源:量子位** **2026-08-07 11:08:51** 近日,螞蟻集團正式宣佈開源多智能體協作基礎設施Avernet,其社區版本已同步上線。作為業界首個聚焦於“組織級協作”的智能體基礎設施,Avernet的首個版本重點開放了智能體協作網絡能力,旨在支持不同智能體之間的發現、共識達成、跨團隊協作與治理,為人工智能從“單點智能”走向“系統智能”提供關鍵支撐。