在 AI 竞赛愈演愈烈的当下，马斯克旗下的 SpaceXAI 做出了一件并不寻常的事，其官宣自家的代码智能体 Grok Build 全面开源，完整代码库现已上传至 GitHub（https://github.com/xai-org/grok-build）。
与此同时，官方还重置了所有用户的服务器端使用限制，并支持完全本地运行，不再受云端额度限制。
项目一经上线，迅速受到开发者的关注，短短几小时便斩获了 7.7k Star。
马斯克也第一时间转发表示：「Grok Build 现在是开源的」。
不过，这次 SpaceXAI 的开源举措也颇有一些争议。一方面得到部分用户的甚赞，认为这是 SpaceXAI 向开放生态迈出的重要一步；另一方面，也有网友觉得，与其说这是一次“慷慨”的开源，不如说更像是对前几天隐私风波的一次补救。
毕竟就在几天前，有开发者曝光 Grok Build 在运行过程中会将整个用户代码仓库上传至 SpaceXAI 服务器，即便开启了隐私设置，这一行为依然会发生，由此引发了开发者社区的广泛质疑。
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 发送了什么？一次网络传输层分析》 的长文，他对 Grok Build 0.2.93 的网络通信行为进行了逐项分析。
与直接阅读源码不同，他通过 Agent 抓包的方式，完整记录了 CLI 与 xAI 服务器之间传输的每一个数据包，希望回答两个简单的问题：开发者的代码究竟有哪些数据真正离开了本地电脑？这款主打本地运行的工具是否真的可靠？
测试结果出乎意料。
@cereblab 发现，针对普通消费者账号，xAI 官方推出的 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，不要读取任何文件（reply OK, do not read any files）”，结果 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 倍。@cereblab 认为，这一差异足以证明，大规模上传的数据来源于整个代码仓库，而不是模型实际读取的上下文。
值得注意的是，整个测试过程中，没有任何一次存储上传失败。唯一出现的非 200 响应，仅是 /v1/responses 接口因模型调用额度不足返回的 402/429 状态码，以及一次无关的 404 错误，而非因为上传数据过大触发的限制。
第三，上传数据的目的地是 Google Cloud Storage，而不是 AWS S3。
@cereblab 在程序二进制文件和截获的 metadata.json 中，都发现了 grok-code-session-traces 这一 Google Cloud Storage Bucket（gs://grok-code-session-traces/…）的名称。
他表示，在他查阅的 CLI 安装和快速上手文档中，并未发现这一上传机制有明确说明。更重要的是，该功能默认启用，即使关闭了 “Improve the model（改进模型）” 选项，也不会停止上传。在测试中，/v1/settings 接口依然返回 trace_upload_enabled: true。
不过，@cereblab 最后也特别强调，以上发现并不能证明 xAI 会使用这些数据训练模型——这属于数据使用政策层面的议题，而非此次技术分析的结论。本次研究能够确认的，仅是这些数据确实被传输、服务器成功接收，并进行了存储。
这份调查报告发布之后，直接冲上了 HN 的头条，也引发了大量开发者的讨论。随后，更有不少技术人验证了这份报告的真实性，舆论直指马斯克、SpaceXAI，并担忧这款工具的安全性：
马斯克回应：True
对此，马斯克出面承认——“确有此事”，随后也承诺将彻底清除相关数据。
他表示，“任何数据都不会留下（zero anything whatsoever will remain）。” 这番表态几乎没有留下任何解释空间。
根据 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