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 版本发布，官方当时强调，这是一个“原生运行在终端的命令行开发工具”，并且优先在个人本地机器上运行，也就是所谓的 local-first。

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

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

几天前，一位名为 @cereblab 的安全研究员发布了一篇长文，标题为《xAI 的 Grok Build CLI 究竟向 xAI 发送了什么？一次网络传输层分析》。他没有直接翻看源码，而是用 Agent 抓包，将 CLI 与 xAI 服务器之间传输的每个数据包都记录下来，目标直指两个核心问题：你的代码到底有多少数据真正离开了本地？这个主打本地运行的工具，究竟是否可靠？

测试结果令人震惊。

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

第一，它会将读取到的文件内容，包括 .env 这类包含密钥的配置文件，原封不动地发送给 xAI 服务器，且不做任何脱敏处理。

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

第二，它会上传整个代码仓库，而不仅仅是 AI 实际读取过的几个文件。

无论 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 实际传输了 5.10GiB 数据（传输过程中被截断，但所有请求均返回 HTTP 200）；而用于模型推理的 /v1/responses 通道仅传输了 192KB 数据，两者相差约 27800 倍。这个差异足以证明，大规模上传的数据来自整个代码仓库，而非模型实际读到的上下文。

值得注意的是，整个测试过程中，没有任何一次存储上传失败。唯一出现的非 200 响应，只是 /v1/responses 接口因模型调用额度不足返回的 402/429 状态码，以及一次无关的 404 错误——并非因上传数据过大而被限制。

第三，上传数据的目的地是 Google Cloud Storage，而非 AWS S3。

@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 最后特别强调，以上发现并不能证明 xAI 会拿这些数据去训练模型——那是数据使用政策层面的议题，而非这次技术分析能得出的结论。本次研究能确认的，只是这些数据确实被传输了，服务器成功接收并存储了。

这份调查报告一经发布，迅速登上 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 的加载与运行机制。

相比单纯开放代码，更受关注的是 Grok Build 已支持完全本地运行。开发者可以自行编译源码，通过 config.toml 配置连接本地推理模型，让整个 Agent 在本地执行。这意味着数据无需再经过 xAI 官方服务器，用户可以自主控制模型、工具调用和数据流转过程。

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

与此同时，xAI 还取消了服务器端的使用限制。过去高频使用者容易触碰到调用额度，影响体验；如今选择本地部署后，限制更多来自用户自身的硬件性能，而非平台配额。

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