整理 | 屠敏出品 | CSDNIDCSDNnews在 AI 竞赛愈演愈烈的当下马斯克旗下的 SpaceXAI 做出了一件并不寻常的事其官宣自家的代码智能体 Grok Build 全面开源完整代码库现已上传至 GitHubhttps://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 CLIgrok 在默认配置下会执行以下三项值得重点关注的操作第一它会将读取到的文件内容包括 .env 等包含密钥的配置文件原封不动地发送给 xAI 服务器且不会进行任何脱敏处理。他表示这些敏感信息会通过两条通道传输一是发送给模型进行推理的实时请求POST /v1/responses二是通过 POST /v1/storage 上传并成功存储HTTP 200的 session_state 会话归档。根据二进制程序分析这些数据最终会被写入名为 grok-code-session-traces 的 Google Cloud StorageGCS存储桶。第二它会上传整个代码仓库而不仅仅是 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 Bucketgs://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-sourcehttps://news.ycombinator.com/item?id48877371https://news.ycombinator.com/item?id48926590