--- layout: post.njk source: https://yage.ai/share/grok-build-open-source-boundary-20260719.html speaker: yage.ai title: Grok Build 开源了，到底开源了什么？ date: '2026-07-19' summary: xAI 公开了 Grok Build 的源代码，主要开源了负责本地操作的客户端 harness。该代码覆盖了从模型推理结果到实际文件操作、命令执行和工具调用的整个流程，使得开发者可以对高权限的本地行为进行逐行检查和审计。然而，核心的模型、云端服务以及官方构建链仍保持闭源状态。 area: tech-engineering category: ai-application tags: - agentic-workflow - client-harness - source-code-open - local-execution people: [] companies_orgs: - xAI products_models: - Grok Build media_books: [] draft: true status: evergreen --- 7 月 16 日，xAI 公开了 Grok Build 的源代码。但我下载官方最新的 0.2.102 macOS 版本后，先看到一个奇怪的细节：二进制报告的 commit 是 ab5ebf69acec，这个 commit 在公开仓库里不存在，也不等于仓库记录的 SOURCE_REV。 这不代表官方二进制有问题，却说明了一个容易混淆的区别：看到源码，和确认电脑上运行的程序就是这份源码，仍是两件事。 我的结论是，xAI 这次公开了相当实质的代码。它覆盖 Grok Build 在本地运行的客户端 harness，远不止一个 TUI 界面。但 Grok 模型、云端服务和官方二进制的构建链仍然没有公开。Grok Build 的一部分从此可以检查，整个产品还没有变成白盒。 ## 公开的是掌管本地操作的客户端 让 Grok Build 修改一个仓库，它要先在本地寻找相关文件，组织发给模型的上下文。模型返回下一步动作后，客户端再决定哪些命令可以直接运行，哪些需要用户批准，然后调用工具、修改文件或执行命令。MCP 连接和用户配置的 hooks 也从这里进入执行过程。 这套客户端代码决定 agent 能在电脑上做什么，也决定人在什么时候介入。终端里看到的对话框只是表面，真正握有本地权限的是后面的 harness。 模型和 harness 在这里扮演的角色不同。模型根据上下文提出计划，harness 才把计划变成电脑上的实际操作。同一个 Grok 模型接进另一套客户端，能读哪些目录、能调用哪些工具、危险命令是否要停下来询问，都可能不同。反过来，同一套 harness 也可以连接不同模型。把两者分开以后，这次开源的意义就清楚了：xAI 没有公开负责推理的模型，公开了负责把推理结果落到开发环境里的执行层。 xAI 公开的 Rust 仓库包含 agent runtime、文件和命令工具、权限管理、sandbox 支持、MCP、hooks 等部分。README还提供本地构建方法，也允许客户端连接本地模型。代码采用 Apache-2.0 许可，任何人都可以阅读、修改、自行构建和 fork。对于一个能够读取项目、修改代码和运行命令的工具，这部分公开并不只是姿态，它让高权限的本地行为第一次有了可以逐行检查的依据。 公开范围也不只覆盖人在终端里逐步操作的场景。仓库中还有用于脚本和 CI 的 headless 模式，以及让编辑器等外部程序接入 agent 的 ACP 支持。也就是说，xAI 公开的是能够嵌进自动化工作流的客户端基础，而不只是一款终端应用的显示部分。 ## 模型、云端和官方构建链仍未公开 仓库没有包含 Grok 模型。使用 xAI 服务时，模型怎样推理、服务端怎样处理和保留数据、账号与远端服务怎样工作，也不在这次发布范围内。客户端源码可以告诉我们它准备发送什么，无法独自回答服务器收到以后做了什么。 项目的开放方式也有一层限制。README 说明，这个仓库由 xAI 的私有 monorepo 定期同步而来；CONTRIBUTING则明确表示不接受外部 Pull Request。Apache-2.0 让代码在法律上可以 fork，官方仓库仍由 xAI 单向发布。这是开放源码，不是社区共同开发。 开头那个对不上的 commit 暴露了另一处缺口。公开历史从首次发布的 commit 开始，无法映射到官方二进制使用的内部 commit。仓库目前也没有把正式安装包绑定到公开源码的 release tag、完整可复现构建配方、公开 CI、SBOM 或 source-to-binary 证明。macOS 签名能证明程序由 xAI 发布，不能证明它对应哪一个公开 commit。 这会产生一个很实际的差别。开发者可以选定公开 commit，自己编译并审计那一份程序；如果直接安装 xAI 提供的版本，就只能另外检查这个二进制的运行行为。前一份程序与后一份程序版本号相同，也不能在缺少构建证明时自动共享审计结论。源码公开解决了“有没有代码可看”，发布链还要回答“下载到的是否就是看过的代码”。 下图概括了这条边界：客户端已经可以查看和自行构建，模型、云端服务以及官方安装包如何对应公开源码，仍要分别验证。 Grok Build 这次开源覆盖的客户端层，以及仍留在闭源系统中的模型、云服务和官方构建链 ## 开源也没有替旧版上传争议结案 7 月初的上传争议发生在另一个版本。原始抓包分析测试的是 0.2.93 (f00f96316d4b)。在研究者测试的 consumer 账号和环境中，客户端上传了完整的已跟踪 Git 仓库及历史，连模型没有读取过的测试文件也包含在内。 这份实验没有证明当前版本仍有相同行为，也没有覆盖所有账号、未跟踪且列入 .gitignore 的文件或训练用途。反过来，当前公开仓库也无法替旧版澄清，因为 f00f96316d4b 不在公开 Git 历史中，外界不能比较争议发生前后的代码变化。 因此，旧版抓包和当前源码回答的是两个问题。前者记录一份特定二进制在当时做了什么，后者展示今天公开的客户端按照怎样的设计工作。把两份证据混在一起，会得到两个相反的错误结论：看到旧实验就认定当前版本仍然如此，或者看到当前代码就宣布旧争议已经消失。 开源真正改变的是今后的验证方式。开发者现在可以固定一个公开 commit，自行构建客户端，检查它怎样选择文件、请求批准和执行工具，再把这些结果与官方二进制的实际网络和文件行为比较。模型与服务端仍要靠独立的政策、抓包和运行测试来验证。 所以，Grok Build 这次开源的准确说法是：xAI 公开了掌管本地文件、命令和工具的客户端 harness，没有公开模型、云端系统和完整的官方发布链。它没有自动建立信任，但把其中一部分信任问题变成了可以阅读代码、运行测试并复查结果的工程问题。