昨天晚上我正准备关电脑，刷 GitHub trending 的时候看到一行字，愣了几秒。

xAI 把 Grok Build 开源了。

不是模型开源，是那个跑在你终端里的 coding agent——连同它的 TUI、agent loop、工具调度、扩展系统，整套源码。发布时间戳是 2026 年 7 月 15 日，仓库地址 github.com/xai-org/grok-build。

我盯着这行字想了一会儿。因为我用 Claude Code 快一年了，MCP Server 搭了一整套，skills、hooks、plugins 全配过。这套东西怎么运作，我一直是从文档和实际使用里"猜"出来的——官方从不公开 harness 的源码。

现在有人把一个几乎一模一样的 harness，连底裤都掀给你看了。

而且掀这一下的，是马斯克。

说实话，我第一反应不是兴奋，是警惕。开源一个 coding agent 听起来很美好，但闭源阵营（Claude Code、Codex）凭什么坐得住？这到底是 xAI 的技术自信，还是一步险棋？我花了大半个晚上把源码结构翻了一遍，也顺手把它和我天天用的 Claude Code 做了个正面对比。下面是我的判断——可能跟你想的不太一样。

---

先说清楚：Grok Build 到底开源了什么

很多人一看"开源"两个字就以为是把模型权重放出来了。不是。

Grok 4.5 模型本身还是闭源的，走 API。

开源的是 harness——也就是那个"外壳"。官方博客里把它拆成四块，我照着 GitHub 上的目录结构核对了一遍：

• Agent loop：上下文如何组装、模型响应如何解析、工具调用如何分发
• Tools：agent 如何读写、搜索代码，如何执行命令
• Terminal UI：渲染、输入处理、plan 审查、内联 diff 查看器
• Extension system：skills、plugins、hooks、MCP servers、subagents 的加载与调用

第四块是我最想看的。

因为 skills 和 hooks 这套机制，Claude Code 和 Grok Build 几乎长得一样——甚至连 AGENTS.md 这个约定文件名都一致。之前我只能靠行为反推它们怎么加载，现在能直接读代码了。

官方原话我贴一下，因为这句话信息量很大：

"if you're working with skills, plugins, hooks, MCP servers, or subagents, the source is the definitive reference for how each is loaded and invoked."

翻译过来就是：你想知道这类 agent 到底怎么工作的，读这份源码就是最权威答案。

还有一个容易被忽略的点——local-first。

你可以自己编译，指向本地推理引擎，配置全在 config.toml 里跑。也就是说理论上你能完全脱离 xAI 的服务器，把这套 agent 接到任意一个自己的模型上。

这一点，闭源阵营给不了。

我还特意翻了它的 agent loop 那部分。这是整个 harness 的心脏——决定了"模型收到什么、什么时候收到、收到之后怎么处理"。

它做了一件我一直好奇的事：把上下文组装、工具调用分发、响应解析拆成了三个清晰的阶段。

上下文组装负责决定这一轮把哪些历史、哪些文件、哪些工具描述塞给模型。工具调用分发负责把模型吐出的 tool call 路由到具体的函数。响应解析负责把模型的输出切成"文本"和"动作"两部分。

听起来是常识，但真正的门道在裁剪策略上。

当对话变长、上下文快撑爆的时候，harness 怎么决定丢掉哪些历史、保留哪些？这个决策直接决定了 agent 在长任务里会不会"失忆"。

Claude Code 也有这套裁剪逻辑，但我只能从它"什么时候开始丢上下文"的行为里反推。现在我能直接读 Grok Build 是怎么写的——哪怕两者实现不完全一样，思路上是相通的。

这就是开源 harness 最实在的价值：它把整个赛道的隐性知识，变成了可以逐行阅读的显性代码。

---

它和 Claude Code 正面刚，到底刚在哪

我用 Claude Code 的时间够长，长到形成肌肉记忆。所以看 Grok Build 的时候，我下意识就在做对照。

结论有点意外：两者的能力清单高度重合，重合到像是照着同一份规格写的。

先看一段 headless 调用的对比。Grok Build 的用法是这样：

# 交互式 TUI 直接跑
grok

# headless 模式，塞进脚本或 CI
grok -p "Explain this codebase"
grok -p "Explain the architecture" --output-format streaming-json

# 查看当前目录被识别到的所有扩展
grok inspect
# 输出：config sources、instructions、skills、plugins、hooks、MCP servers

用过 Claude Code 的人看到这个会有强烈既视感。-p 的 headless 模式、streaming-json 输出、inspect 扫描扩展——几乎是同一套心智模型。

我把两者的核心机制列了张表，这样比一段一段描述清楚得多：

能力维度	Grok Build（开源）	Claude Code（闭源）
底层模型	Grok 4.5（API，闭源）	Opus 4.8 / Claude 5（闭源）
Harness 源码	完全开源	不公开
约定文件	AGENTS.md	CLAUDE.md / AGENTS.md
Skills	支持，可 /skillify 捕获	支持
Hooks	支持	支持
MCP Servers	开箱即用	开箱即用
Subagents	最多 8 个并行 + 独立 worktree	支持并行 subagent
Plan 模式	三阶段 plan/search/build	Plan 模式 + ExitPlanMode
本地优先	可完全脱离云跑	依赖 Anthropic 服务
价格（模型）	$2 / $6 每百万 token	Opus $5 / $30

看出问题了吗？

能力上两者打平，甚至 Grok Build 在价格和开源程度上还占优。真正的差异只有一处——harness 到底透不透明。

Claude Code 的 harness 是黑盒。你信任它，是因为它好用、稳定，Anthropic 背书。但你不知道它内部怎么组装上下文、怎么裁剪历史、怎么决定调哪个工具。

Grok Build 把这层黑盒撕开了。

对独立开发者来说，这不是小事。我配 hooks 的时候踩过无数次坑，全靠试错。如果能直接读 Grok Build 的 hook 加载逻辑，很多坑根本不用踩——哪怕我最后还是用 Claude Code，这份源码也是免费的教科书。

---

五大扩展机制，读源码才看懂的门道

光说"能力重合"太虚。我挑扩展系统里最能说明问题的三个机制，讲讲读源码才看懂的门道。

第一个是 skills 的自动触发。

Grok Build 的 skill 有两种调用方式：任务匹配时自动触发，或者按名字显式调用。这跟 Claude Code 的 skill 触发逻辑是一个路数。

更有意思的是 /skillify——你可以把当前这次会话直接捕获成一个新 skill。这意味着 skill 不是提前写死的，而是可以从实际工作流里"长"出来的。

第二个是 plugins 的打包分发。

官方文档写得很清楚，plugin 能把 skills、agents、hooks、MCP servers 全部打包在一个安装单元里：

# ~/.grok/config.toml 里挂载自定义模型和扩展
[model.my-model]
provider = "local"
endpoint = "http://localhost:11434/v1"

# plugins 可以从 marketplace 装，也可以从任意 git repo 自托管
# 一个 plugin = skills + agents + hooks + MCP servers 的集合

这套"一个 plugin 打包一切"的设计，解决了我一直头疼的问题：扩展的可移植性。

我在 Claude Code 里配的那套 skill 和 hook，换台机器就得重配一遍。plugin 化之后，理论上一条命令就能把整套工作流搬走。

第三个是 MCP 的开箱即用。

这是我最关心的部分，因为我大半年的精力都在 MCP 上。

Grok Build 对 MCP 的支持是"零配置兼容 Claude Code"——你之前给 Claude Code 写的 MCP Server，几乎不用改就能挂到 Grok Build 上。Linear、Sentry、Postgres、浏览器，任何有 MCP 接口的东西都能接。

我特意去翻了它加载 MCP server 的那段逻辑。它和 Claude Code 一样，把 MCP server 的 tool schema 按需加载，而不是一次性全塞进上下文。

这个设计细节，你不读源码是看不出来的——但它直接决定了你挂 20 个 MCP server 会不会把上下文撑爆。

读到这里我基本确信：Grok Build 不是抄 Claude Code，而是这个赛道正在收敛成同一套事实标准。

AGENTS.md、skills、hooks、MCP——这些概念正在变成 coding agent 的"POSIX"。谁先开源谁定标准。

---

并行 subagent 和本地优先，我的真实判断

说了这么多好话，也得泼盆冷水。

Grok Build 最被吹的功能是 8 个并行 subagent，每个跑在独立的 git worktree 里。听起来很猛，但我用过类似的并行方案，有几句实话得说。

并行不是免费的。

8 个 subagent 同时跑，意味着 8 份上下文、8 份 token 消耗。任务如果拆得不好，并行只会放大混乱，不会加速。

它的执行流程是这样的：

• 主 agent 接收任务，制定计划
• 拆成子任务分给最多 8 个独立 subagent（"给模块 X 写测试"、"重构 /api 路由层"）
• 每个 subagent 在隔离的 worktree 里并行跑，避免文件冲突
• 完成后回报，主 agent 聚合，进入 plan-review 让你审查

关键在最后一步——plan-review。

还有一点值得单独说：每个 subagent 跑在自己的 git worktree 里。

这个设计解决了并行最致命的问题——文件冲突。

如果两个 subagent 同时改同一个文件，没有隔离就直接互相覆盖，结果谁都跑不通。worktree 让每个 subagent 有独立的代码副本，写完再合并回主分支。冲突在合并时暴露，而不是在执行时悄悄出现。

我之前用类似并行方案时，没做 worktree 隔离，结果两个 agent 同时改一个 API 路由文件，最后那个文件的改动被后写的覆盖掉，调了半天才发现是并行冲突。看到 Grok Build 把 worktree 当成一等公民，我第一反应是：这个坑他们替我踩过了。

---

并行 subagent 真正的价值不是"快"，是"你还留在环里"。8 个 agent 干完活，最后汇总到你面前让你审。如果去掉这一步，8 个 agent 并行就是 8 倍的失控风险。

再说 local-first。

能脱离云跑，听起来是隐私和成本的双赢。但现实是——你得有一个足够强的本地模型。

把 Grok Build 指向一个跑在 Ollama 上的小模型，harness 再精巧，也架不住模型本身能力不够。local-first 是给有本地算力的团队准备的，不是给所有人的免费午餐。

所以我的判断是：Grok Build 的开源，对"读源码学 harness"的人价值最大，对"日常干活"的人价值有限。

它不会让我立刻抛弃 Claude Code。但它让我第一次能把"coding agent 到底怎么工作"这件事，从猜测变成阅读。这个价值，比多一个能用的工具重要得多。

这周和一个做 infra 的朋友聊到这事，他说了句我很认同的话：模型在收敛，harness 在开源，真正稀缺的从来不是工具，是知道怎么用工具的判断力。

---

写在最后

如果你也用 coding agent，不管是 Claude Code、Codex 还是 Cursor，我建议你今晚做一个动作。

去 github.com/xai-org/grok-build，把 extension system 那部分的源码 clone 下来，读一读它怎么加载 hooks 和 MCP server。

你不需要切换工具，也不需要马上用 Grok Build。

你只是终于有机会，看清楚你天天在用的那个黑盒，里面到底装了什么。

对我来说，这比 xAI 又发了个模型重要多了。模型每个月都在变，但一个把 harness 彻底摊开的开源仓库，是能让你真正搞懂这个赛道的东西。

马斯克这步棋是不是险棋，我不知道。但对读代码的人来说，这是难得的好事。