被曝上传用户代码后，马斯克官宣开源Grok Build，GitHub上线即斩获7.7k Star

AI 竞赛正打得火热，马斯克这边却突然搞了个大动作——旗下 xAI 的代码智能体 Grok Build 全面开源了，完整代码库已经挂上 GitHub。项目一上线，短短几小时就拿下 7.7k Star，速度相当惊人。官方还顺便重置了所有用户的服务器端使用限制，支持完全本地运行，云端额度这事儿从此跟你没关系。

马斯克本人也第一时间转发了消息，干脆利落四个字：“Grok Build 现在是开源的。”

不过，这次开源并没有收获清一色的叫好声。一方面，有用户觉得这是 xAI 向开放生态迈出的重要一步，值得点赞；另一方面，也有人直言，与其说这是“慷慨”之举，不如说是对几天前那场隐私风波的紧急补救。毕竟就在前几天，有开发者曝光 Grok Build 在运行过程中，会把整个用户代码仓库上传到 xAI 服务器，即便你刻意关掉了隐私设置也没用。这一发现让开发者社区炸了锅。

Grok Build 被曝上传用户代码

先简单说下 Grok Build 是什么东西。跟 Cursor、GitHub Copilot 这些以 IDE 为核心的编程助手不同，Grok Build 更像 Anthropic 的 Claude Code 和 OpenAI 的 Codex CLI——命令行是主角，Agent 自主跑完整个开发流程。这款工具最早在 2026 年 5 月以 Beta 版本发布，官方当时强调，这是一个“原生运行在终端的命令行开发工具”，而且优先在个人本地机器上运行，也就是所谓

。

它用 Rust 编写，底层用的是 xAI 最新的 Grok 4.5 大模型，能在本地项目里直接读取代码、修改文件、执行终端命令、调用各类工具和插件，完成复杂的开发任务——不是光回答代码问题那么简单。

本来 Grok Build 发布那会儿，xAI 内部正经历动荡，已经自带流量。但真正让它站上风口浪尖的，还是一名安全研究员的最新发现。

几天前，一位叫

的安全研究员发布了一篇长文，标题叫《xAI 的 Grok Build CLI 究竟向 xAI 发送了什么？一次网络传输层分析》。他没有直接翻源码，而是用 Agent 抓包，把 CLI 和 xAI 服务器之间传输的每个数据包都记录了下来，目标就两个问题：

测试结果出乎意料。

@cereblab 发现，针对普通消费者账号，Grok Build CLI（grok）在默认配置下，会执行三项值得重点关注的操作：

这些敏感信息通过两条通道传输：一条是发送给模型进行推理的实时请求（POST /v1/responses）；另一条是通过 POST /v1/storage 上传并成功存储（HTTP 200）的 session_state 会话归档。根据二进制程序分析，这些数据最终会写进一个叫 grok-code-session-traces 的 Google Cloud Storage（GCS）存储桶。

无论 Agent 有没有访问过某个文件，Grok 都会把整个工作目录打包，通过 POST /v1/storage 上传，包括所有 Git 已跟踪文件的内容和完整的 Git 提交历史。@cereblab 用自己一个真实项目做了验证：他在提示词中明确要求“只回复 OK，不要读取任何文件”，结果 Grok 依然把整个仓库打包成 Git Bundle 并上传（POST /v1/storage 返回 HTTP 200）。随后，他用 git clone 恢复了截获的 Bundle，成功找回了一个 Agent 按要求从未打开过的测试文件 src/_probe/never_read_canary.txt——里面唯一的标识字符串与原文件完全一致，还恢复了完整的 Git 历史。

不仅如此，@cereblab 还进一步测试了上传规模。在一个约 12GB、全部由 Agent 从未读取过的随机文件组成的测试仓库中，/v1/storage 实际传输了

（传输过程中被截断，但所有请求均返回 HTTP 200）；而用于模型推理的 /v1/responses 通道仅传输了 192KB 数据，。这个差异足以证明，大规模上传的数据来自于整个代码仓库，而不是模型实际读到的上下文。

值得注意的是，

唯一出现的非 200 响应，只是 /v1/responses 接口因模型调用额度不足返回的 402/429 状态码，以及一次无关的 404 错误——并不是因为上传数据太大被限制。

@cereblab 在程序二进制文件和截获的 metadata.json 里都发现了 grok-code-session-traces 这个 GCS Bucket 名称（gs://grok-code-session-traces/...）。他查阅了 CLI 安装和快速上手文档，发现并没有关于这一上传机制的明确说明。更关键的是，该功能默认启用，就算你关闭了“改进模型（Improve the model）”选项，上传也不会停止——测试中 /v1/settings 接口依然返回 trace_upload_enabled: true。

不过，@cereblab 最后特别强调，

这份调查报告一发布，直接冲上了 HN 头条，引发大量讨论。随后不少技术人也验证了它的真实性，舆论直指马斯克和 xAI，担心这款工具的安全性。

马斯克回应：True

面对质疑，马斯克出面承认——“确有此事”。随后承诺将彻底清除相关数据，并表示“任何数据都不会留下”。这番表态几乎没留任何解释空间。根据 xAI 的说法，此前上传的所有用户数据已经被永久删除，未来也将彻底关闭数据留存机制。

回应争议，Grok Build 全面开源

眼下，Grok Build 选择开源，多少被外界视为对数据风波的一次回应。日前，代码智能体 Grok Build 及其终端用户界面的完整源码已发布至 GitHub。开发者不仅能直接阅读代码，还能弄清楚 Agent 如何构建上下文、解析模型响应、调度工具调用等核心流程。

具体来看，这次开源覆盖了以下几个部分：

Agent 主循环（Agent Loop）：展示上下文如何构建、模型响应如何解析，以及工具调用如何调度。

工具系统（Tools）：包括 Agent 如何读取、编辑、搜索代码，以及如何执行终端命令。

终端用户界面（Terminal UI）：涵盖界面渲染、输入处理、执行计划（Plan）审核，以及内联 Diff 对比查看器等功能。

扩展系统（Extension System）：包括 Skills、Plugins、Hooks、MCP Servers 和 Subagents 的加载与运行机制。

相比单纯开放代码，

。开发者可以自行编译源码，通过 config.toml 配置连接本地推理模型，让整个 Agent 在本地执行。这意味着数据无需再经过 xAI 官方服务器，用户可以自主控制模型、工具调用和数据流转过程。

xAI 表示，开源是打造更健壮、更可靠的 Agent 框架最直接的方式。一方面，开发者可以审查代码、验证工具的真实行为；另一方面，也能根据自身需求修改实现，构建适合团队的开发流程。

与此同时，

。过去高频使用者容易触碰到调用额度，影响体验；如今选择本地部署后，限制更多来自用户自身的硬件性能，而不是平台配额。

Grok Build 项目负责人 Andrew Milich 将其定位为一款“原生面向终端”的代码智能体。在 Rust 代码库全面开放后，开发者不仅能验证其实际行为，还可以按需修改底层实现，并确保所有数据始终留在本地设备。

放眼整个 AI 编程赛道，竞争正不断升温。Anthropic 的 Claude 已具备成熟的编程能力；OpenAI 的开发工具正不断融入企业工作流；Google 的 Gemini 也在积极布局开发者工具生态。各家都在强化模型能力和开发者生态，而 xAI 则选择以开源和本地化作为差异化方向。对不少开发者来说，相比模型能力本身，能够审计源码、自由修改实现，并完全掌控数据流向，同样是影响工具选型的重要因素。

参考：

https://x.ai/news/grok-build-open-source

https://news.ycombinator.com/item?id=48877371

https://news.ycombinator.com/item?id=48926590