开源不是终点，而是信任重建的起点

Grok Build 正式宣布全面开源，完整 Rust 代码库已发布至 GitHub。这不是一次常规的功能更新，而是一次面向开发者主权的技术承诺：所有核心模块——Agent 主循环、工具系统、终端 UI、扩展机制——全部开放可查、可编译、可定制。

本地运行成为默认能力，而非宣传话术

此前宣称的 "local-first" 定位，如今真正落地。用户可通过 config.toml 配置接入本地部署的大模型（如 Ollama、LM Studio 或自托管 Grok 实例），整个 Agent 流程——上下文构建、工具调度、文件编辑、命令执行——均在本地完成。数据不再出离设备，模型调用、代码读写、Git 操作全程可控。服务器端配额限制同步取消，使用边界回归硬件性能本身。

争议源于行为，回应始于代码

数日前，安全研究员 @cereblab 通过网络抓包证实：旧版 Grok Build CLI 在默认配置下，会将整个工作目录（含 .env 等敏感文件、全部 Git 跟踪文件及完整提交历史）打包上传至 Google Cloud Storage 的 grok-code-session-traces 存储桶，且该行为不受「改进模型」开关影响。这一发现引发广泛质疑。

开源即审计，代码即契约

此次开源不设保留项。开发者可直接验证：上下文是否仅加载必要文件？工具调用是否真实限于声明范围？上传逻辑是否存在隐式通道？Agent 是否真如文档所述“不上传未读内容”？每一个判断，都不再依赖声明或截图，而取决于可运行、可调试的源码。

重构信任的方式，是把控制权交还给用户

xAI 并未回避此前的数据传输事实，亦未以“合规”或“匿名化”作模糊解释。其回应简洁明确：已永久删除所有历史上传数据，并彻底关闭服务端数据留存路径。开源不是补救姿态，而是将技术决策权、安全验证权、流程改造权，完整移交至每个使用者手中。

这不只是一个 CLI 工具，而是一种开发范式的转向

当多数代码助手仍在云端闭环中优化响应速度与准确率时，Grok Build 选择将复杂性下沉至终端——用 Rust 保障执行效率，用模块化设计支持深度定制，用零外部依赖实现真正的本地自治。它不试图替代 IDE，而是成为开发者命令行工作流中可信赖的协作者：可知、可控、可塑。