7 月 16 号，Elon Musk 宣布 grok-build 开源，xAI 把内部的 grok-build 扔上了 GitHub。8 小时内，10000 颗星，1558 个 fork。
README 第一行写着：「Grok Build is xAI's terminal-based AI coding agent.」语气很平。
但往下翻到「Repository layout」，事情就不一样了。40 多个 Rust crate，TUI 渲染、沙箱隔离、子 Agent 协调、工具链，全塞在一个仓库里。README 末尾还补了句「External contributions are not accepted」。这是 xAI 内部 monorepo 的同步镜像，不是社区项目。
这大概是 2026 年最受关注的编码 Agent 开源之一。不过关注度跟它能做什么关系不大，人们 star 它是因为「xAI 内部用什么工具写代码」这件事本身就够有看头。
不过，Grok Build 的故事里还有一个不能绕开的前情。就在开源公告前三天，研究人员发现它会默认上传整个 Git 仓库。这个问题先记在这里，后面拆完架构再展开。毕竟，对编码 Agent 来说，代码怎么执行是一回事，代码有没有在你不知情的情况下离开本机，是另一回事。
定位：xAI 内部的 Claude Code
Grok Build 是一个全屏终端 TUI 编码 Agent，可以理解成 xAI 版的 Claude Code。但它不是复刻版，是 xAI 从零开始用 Rust 写的完整工具链。
核心能力跟 Claude Code 差不多：理解代码库、编辑文件、执行终端命令、搜索网页、管理长时间任务。但架构设计走的是自己的路。
翻了它的 crate 列表，xai-grok-pager（TUI 渲染）、xai-grok-shell（Agent 运行时）、xai-grok-sandbox（沙箱隔离），加起来 40 多个 crate，每个都有自己的职责边界。这不像一个刚起步的 MVP，更像一个内部跑了好几年的产品，被拆出来同步到了 GitHub。
三层架构：Pager、Shell、Workspace
读源码的时候，三个 crate 构成了主干：xai-grok-pager、xai-grok-shell、xai-grok-workspace。
Pager 层基于 ratatui 构建，负责 TUI 渲染：全屏滚动回退、语法高亮、Markdown 渲染、Mermaid 图表行内渲染。所有终端交互都在这一层。
Shell 层是 Agent 的大脑。会话生命周期、LLM 采样循环、工具调度、子 Agent 协调，全归它管。src/session/acp_session_impl/run_loop.rs 里的 run_session 函数是整个系统的核心循环。
Workspace 层管理文件系统、VCS、权限、工具集。xai-grok-workspace/src/file_system/ 下有一套文件系统抽象，支持本地 FS、客户端 FS（通过 ACP 协议）、扩展 FS 三种模式。xai-grok-workspace/src/permission/ 下的权限子系统处理工具调用审批、自动模式、bash 命令拆分。
三层通过 xai-grok-shell 的 session 模块串联。src/session/acp_session_impl/ 目录下，tool_dispatch.rs 调度工具、prompt_build.rs 构建 prompt、run_loop.rs 驱动主循环。每个文件管一件事，读起来很舒服。
工具系统：三代并存
xai-grok-tools crate 里同时存在三套工具实现。
grok_build（当前世代）基于 NewTool trait，是正在迁移的目标架构。src/implementations/grok_build/ 下每个工具一个子目录。
codex（遗留兼容）从 OpenAI Codex 移植过来，包括 apply_patch、grep_files、list_dir、read_file。THIRD-PARTY-NOTICES 文件里标注了来源。
opencode（遗留兼容）从 sst/opencode 移植，包括 BashTool、EditTool、GlobTool 等。
三套通过 mod.rs 的 register_all() 统一注册。它没有上来就重写所有东西，而是让新旧工具平缓过渡，这种做法挺务实。src/implementations/grok_build/tool/ 下的 grok_build_hashline 和 grok_build_concise 看起来还在迭代中。
具体实现也有细节值得看。web_fetch 工具有完整的 SSRF 防护层（src/implementations/grok_build/web_fetch/ssrf.rs），bash 工具设了输出截断（DEFAULT_TOOL_OUTPUT_CHARS = 20_000），search_replace 工具有三个版本并存。
沙箱：默认开启，不可逆
xai-grok-sandbox crate 基于 nono（一个 Rust 沙箱库），支持 Landlock（Linux）和 Seatbelt（macOS）。默认是开启的，Cargo.toml 里 default = ["jemalloc", "sandbox-enforce"]，sandbox 是默认 feature。
src/lib.rs 里的 SandboxManager 先 apply() 再 install()，一旦应用就不可逆。ProfileName 定义了四种模式：Off、Workspace、Strict、Devbox，外加 Custom 自定义。
Linux 上还用 bwrap（bubblewrap）做了一层额外 mount namespace 隔离。src/lib.rs 里那段 bwrap_reexec_command 的实现写得挺扎实：先检查是否已经在 bwrap 内，不是就重新 exec 自己，把进程塞进受限的 mount namespace。
src/deny/ 下有一套路径拒绝系统，支持 glob 匹配。deny/glob.rs 实现路径通配符解析，在 macOS 上通过 Seatbelt 的运行时正则生效，Linux 上则在启动时展开为具体路径列表。
子 Agent 协调：Task 工具背后的架构
Grok Build 支持长时间运行的后台任务。TaskTool 创建子 Agent 执行独立任务，TaskOutputTool 查询结果，KillTaskTool 取消任务。
src/implementations/grok_build/task/backend.rs 里定义了一个 SubagentBackend trait：
rust
#[async_trait]
pub trait SubagentBackend: Send + Sync + 'static {
async fn spawn(&self, request: SubagentRequest) -> Result<SubagentResult, ToolError>;
async fn query(&self, id: &str, block: bool, timeout_ms: Option<u64>) -> ...;
async fn cancel(&self, target: SubagentCancelTarget) -> ...;
}当前只有 ChannelBackend（基于 in-process tokio::mpsc），注释里写了 RemoteBackend 是未来计划。先抽象再实现，接口稳定了再扩展。不算新鲜，但很实用。
src/agent/mvp_agent/subagent_coordinator.rs 是子 Agent 协调器。src/agent/subagent/ 下还有 coordinator_lifecycle.rs、coordinator_query.rs、handle_request.rs，分别管生命周期、查询、请求分发。子 Agent 之间通过 SubagentRequest/SubagentResult 消息通信，每个子 Agent 有自己的会话状态。
Agent 协议：ACP，不是 MCP
Grok Build 实现了一个叫 ACP（Agent Client Protocol）的协议，跟 MCP（Model Context Protocol）不是一回事。
xai-acp-lib crate 实现了 ACP 的客户端和服务端。src/channel.rs 定义消息通道，src/gateway.rs 做网关转发，src/message.rs 定义消息格式。ACP 让外部工具（比如编辑器）能通过这个协议跟 Grok Build 的 Agent 通信。
src/session/acp_session.rs 把 ACP 会话转接到内部会话系统。src/session/acp_session_impl/extensions.rs 实现了 ACP 扩展点，包括空闲提示、目标规划、模型切换、记忆系统等。
MCP 支持由 xai-grok-mcp crate 提供，src/session/acp_session_impl/mcp.rs 管理和调度 MCP 服务器。
目标导向的 Agent 行为
Grok Build 有一个「目标系统」（Goal System），不是简单的对话式 Agent。
src/session/goal_classifier.rs 判断用户意图是否需要规划。src/session/goal_planner.rs 制定执行计划。src/session/goal_strategist.rs 在遇到障碍时调整策略。src/session/goal_summarizer.rs 完成后总结。
src/session/templates/ 下有一堆 Markdown 模板文件：goal_planner_prompt.md、goal_strategist_prompt.md、goal_summarizer_prompt.md，每个阶段对应一套系统提示词。
Agent 不是「你问一句我答一句」，而是能理解复杂任务的目标，自主规划执行步骤，遇到问题能调整策略。
一些工程细节
逛源码的时候注意到几个点。
版本号是 0.1.220-alpha.4。220 次迭代才到 0.1，内部用了很久了。
bus factor = 1，gh api 显示只有 1 个贡献者。monorepo 同步镜像会把所有提交归到同一个账号下，但也意味着外部社区对项目的了解完全依赖 xAI 的同步节奏。
仓库创建两天，既没有 open issue 也没有 release。可能是内部问题跟踪系统不一样，也可能是 xAI 还没想好怎么管社区。
bin/protoc 是一个 dotslash launcher，不需要手动装 protoc。
README 里写了「The root Cargo.toml is generated --- treat it as read-only.」依赖管理在各 crate 自己的文件里。
third_party/ 下有一个完整的 Mermaid 图表渲染栈，是 dagre 的 Rust 移植版，本地渲染，不调外部 API。
适用边界
Grok Build 有几个明显的限制。
第一次启动会打开浏览器让你登录 xAI 账号。它不是离线工具，也不是「自带 LLM」的工具。
README 写了「Windows builds are best-effort and not currently tested from this tree.」Windows 用户可能体验不会太好。
README 说「External contributions are not accepted.」只能读代码，不能提 PR。这是公开的代码镜像，不是开源社区项目。
10000 星是好奇心驱动的。这个星数跟它的当前成熟度不成正比。人们 star 它是因为「xAI 开源了内部工具」这件事本身，不是因为它功能已经比 Claude Code 强。它的 README 甚至没有完整的命令列表，只有一句「See the documentation at docs.x.ai/build/overview」。
反转：开源前三天的代码上传争议
7 月 13 号，开源公告前三天，研究人员在 Grok Build CLI 上做线级分析，发现它在静默上传整个 Git 仓库到 Google Cloud。
目标存储桶是 grok-code-session-traces。一个 12 GB 的测试仓库里，有 5.1 GB 的数据被传了上去，而实际的编码任务只需要 192 KB。工具抓取的是它运行所在的整个仓库，不是它需要的文件。私有代码、未脱敏的密钥，都在这批上传里。
「改进模型」这个 opt-out 选项并不能停止上传。真正能关掉它的，是一个隐藏的服务器端开关 disable_codebase_upload: true，而这名研究人员花了一天做线级分析才定位到它。
当天晚上 23:37，xAI 给出了官方回应。核心几点：启用了零数据保留（ZDR）的团队，任何痕迹和代码数据都不会被保留，API 密钥的使用也尊重 ZDR；如果 ZDR 被禁用，可以在 CLI 里用 /privacy 命令关闭数据保留，/privacy 会同时删掉之前同步过的数据，也可以随时查看或更改设置。
但社区很快补上了一个容易被忽略的前提：ZDR 不是所有用户都能打开的开关。Vincent 转发的 xAI 文档截图写得很清楚，ZDR 仅适用于企业账户，需要联系 sales@x.ai 为组织启用；启用后，团队的 API 请求会自动套用 ZDR，控制台里会显示「Zero Data Retention」标签。
这会直接改变普通开发者对那段官方回应的理解。对企业账户来说，ZDR 是一条明确的合规路径；对个人账户和普通开发者来说，它并不是安装 CLI 后就能自行获得的默认保护。不能把「ZDR 团队不会留存数据」读成「所有用户都不会留存数据」。
另一个追问是 /privacy 到底删除什么。Farhan Ali Shah 直接问：运行 /privacy 开启 ZDR 后，是只停止未来数据收集，还是会追溯删除已经同步的数据？SpaceXAI 账号回复得很明确：运行 /privacy 并更改设置后，所有此前同步的数据都会被删除。
这条回复回答了「怎么删」，但仍没有回答「已经上传过什么」。在 /privacy 和隐藏开关被发现之前，非 ZDR 用户已经被默认上传的数据，范围多大、留了多久、是否都能被清理，文章发布时仍缺少公开的清单或审计说明。研究人员的线级分析花了一天，意味着在那一天里，不知情的用户仓库还在往 grok-code-session-traces 里送。
社区的情绪也没有停在技术细节上。Nathan Wilbanks 认为，不应该默认替用户同意抓取自己的文件，并表示自己不会再使用这套工具；RTK 则进一步追问，这究竟是 Cursor 团队、Grok 团队，还是双方都参与了设计，并质疑这种做法在不同国家可能涉及的合规问题。
这些评论不能替代法律结论，也不能证明 Cursor 团队参与了实现，但它们准确暴露了用户真正介意的地方：不是有没有一个可以关闭的命令，而是为什么第一次运行时默认开启、为什么关闭方式藏在不显眼的配置里，以及用户能不能在数据离开电脑之前被清楚告知。
这件事给前面所有架构分析的分量都重新打了个折。沙箱做得再扎实、分层解耦做得再漂亮，如果默认行为是把你整个仓库打包送走、要靠用户自己挖出隐藏开关才能止血，那「架构设计」和「能不能放心用」就是两个问题。
对任何把 AI 编码 Agent 指向专有代码库的人来说，数据线上实际发生了什么，比设置页面写了什么更重要。好消息是 /privacy 现在是公开的、可逆的入口；坏消息是，得先知道它存在。
值得带走的设计思路
读完 Grok Build 的源码，最值得借鉴的是它的分层解耦。但 7/13 的代码上传争议提醒一件事：架构再干净，也得配上透明的数据行为。
Pager / Shell / Workspace 三层，各管各的。Pager 不管 LLM 怎么采样，Shell 不管 TUI 怎么渲染，Workspace 不管上面两层怎么运作。工具系统用 NewTool trait 做接口抽象，允许新旧工具共存。子 Agent 系统用 SubagentBackend 抽象，虽然目前只有 in-process 实现，但接口已经为远程扩展预留了位置。
「先分层再抽象」这套做法，220 次迭代到 0.1 版本，不是光靠堆功能堆出来的。
如果你对 Agent 架构设计感兴趣，Grok Build 的源码值得翻一翻。它展示了 xAI 内部对「编码 Agent 应该怎么组织」的真实答案------至少是答案中值得公开的那一面。要不要把私有代码库交给它，是另一个问题。