Grok Build 开源后，我翻了翻源码：Coding Agent 真正难的部分，已经不在模型里

看点

2026 年 7 月 16 日，SpaceXAI 开源了 Grok Build 的终端界面和 Agent Runtime。

很多人看到这条消息，第一反应大概是：马斯克也开源 Coding Agent 了。

这个说法不能算错，但容易让人误解。

这次公开的不是 Grok 4.5 模型。模型权重、训练代码和推理服务都不在仓库里。真正被放出来的，是模型外面的那套系统：它负责组织上下文、调用工具、执行命令、管理权限、保存会话、压缩历史，以及在任务没做完时继续推动模型往下走。

在 Agent 领域，这套东西通常被叫作 Harness。

过去大家谈 Coding Agent，注意力往往集中在模型上：谁的代码能力更强，谁的上下文更长，谁在 Benchmark 上分数更高。

但真正用过 Claude Code、Codex、Cursor 或其他 Coding Agent 的人，通常会有另一种感受：

模型聪不聪明当然重要，可一个 Agent 最后好不好用，往往取决于模型之外的那些细节。

• 它会不会读错文件？

• 执行失败后能不能恢复？

• 上下文快满了怎么办？

• 改到一半会不会突然宣布任务完成？

• 多个子任务同时修改代码时，会不会互相覆盖？

• Shell 命令到底能访问哪些目录？

这些问题，模型本身并不会自动解决。 Grok Build 这次开源，最值得看的也正是这些部分。

开源的到底是什么

官方仓库是：

https://github.com/xai-org/grok-build

仓库采用 Apache 2.0 许可证，主体是 Rust。安装之后，命令名是 grok。

按照官方文档的描述，Grok Build 可以：

• 理解代码仓库；
• 读取和修改文件；
• 执行 Shell 命令；
• 搜索网络；
• 管理持续时间较长的任务；
• 运行在终端 TUI、Headless/CI 和 ACP 编辑器模式下。

仓库的大致结构如下：

xai-grok-pager-bin
        │
        ├─ xai-grok-pager       TUI、输入、回滚、渲染
        ├─ xai-grok-shell       会话调度和采样循环
        ├─ xai-grok-agent       Agent 定义、Prompt、工具配置
        ├─ xai-grok-tools       内置工具和 MCP
        ├─ xai-grok-workspace   文件、Git、执行和 Checkpoint
        ├─ xai-grok-sandbox     系统级沙箱
        └─ xai-acp-lib          ACP 协议

从这个目录划分就能看出来，它并不是一个简单的命令行外壳。

交互界面、会话、Agent 配置、工具执行、工作区和沙箱被拆成了不同模块。也就是说，同一套 Runtime 可以挂在终端、CI 或编辑器下面。

另外，官方文档支持配置自定义模型服务。用户可以指定模型 ID、API 地址和密钥，再把它设成默认模型。

因此，Grok Build 并不完全依赖 Grok 模型。更准确地说，它是一套可以驱动模型工作的 Agent Runtime，只是官方默认接的是 Grok。

一个 Coding Agent 是怎么跑起来的？

看 Coding Agent 的源码，最值得先看的不是工具列表，而是一次任务的主循环。

Grok Build 的核心会话逻辑由 SessionActor 驱动。把遥测、UI 更新和认证恢复等细节暂时拿掉，一次任务大致会经历下面这些步骤：

用户输入
  ↓
加载项目指令、Memory、Skills 和 MCP 状态
  ↓
检查上下文是否需要压缩
  ↓
拼接历史消息、System Prompt 和工具定义
  ↓
请求模型
  ↓
模型返回文本或 Tool Call
  ↓
检查权限并执行 Hook
  ↓
运行工具
  ↓
把结果写回会话
  ↓
继续请求模型

这个过程会反复执行。

模型读文件，工具返回内容；模型修改代码，工具返回 Diff；模型运行测试，工具返回报错；模型再根据报错继续修改。所以，一个 Coding Agent 并不是“模型加几个函数”，它更像一个长期运行的状态机。模型每次只负责决定下一步做什么，Runtime 负责把这一步可靠地执行出来。

真正麻烦的地方，也都在这个循环里。

例如：

• 用户可能在执行过程中追加新要求；
• 某个工具可能运行超时；
• 模型可能同时发出多个工具调用；
• Shell 输出可能非常长；
• 权限请求可能被用户拒绝；
• 模型输出可能不符合结构化 Schema；
• 会话可能快要超过上下文上限；
• 某次调用可能因为认证问题失败；
• 用户可能中途取消任务。

这些情况都要由 Harness 处理。

自己写一个几十行的 Tool Calling Demo 并不难。难的是让它在一个真实仓库里连续工作几个小时，期间经历编译失败、测试报错、上下文压缩和用户插话，最后还能把任务收尾。

模型很容易”觉得自己已经做完了”

实际使用 Coding Agent 时，一个常见问题是：它经常提前结束。

比如用户让它完成五件事，它列出了计划，做了其中两件，修改了一个文件，然后就开始总结：

“问题已解决，主要改动如下。”

然后你想骂它，因为这个问题只解决了一半不到。就像我让它把初始实现和diffusers对比，看哪些地方有差异，会导致结果不一致。它才找完两个点就兴匆匆地告诉我怎么怎么了，我就感觉你怎么这么急着邀功呢。

这种问题很难只靠 Prompt 解决。

你当然可以在 System Prompt 里写：

必须完成所有事项后才能结束。

但模型是否真的完成了任务，不能完全依赖模型自己判断。

Grok Build 在 Runtime 里加入了类似 TodoGate 的机制。模型准备结束当前 Turn 时，系统会检查任务列表中是否还有 pending 或不合理的 in_progress 项。

如果状态显示任务没做完，Runtime 会继续提醒模型，而不是直接接受它的结束请求。

这个细节很有代表性。

现在不少 Agent 系统还在尝试通过更复杂的 Prompt 提高可靠性，但很多问题其实更适合直接写进程序。

例如：

• Todo 没清空，不允许结束；
• 测试没通过，不允许标记完成；
• 输出不符合 Schema，重新生成；
• 没有权限的工具，不暴露给模型；
• 达到最大循环次数，强制停止。

模型适合处理开放式问题，比如理解需求、阅读代码、设计修改方案。

那些可以机械判断的条件，还是应该交给程序。

长任务不是靠把上下文做得无限长

Coding Agent 一旦运行时间变长，上下文很快就会膨胀。

里面可能包括：

• 用户要求；
• System Prompt；
• 项目指令；
• 几十个文件的内容；
• 多轮工具调用；
• 编译日志；
• 测试输出；
• Git Diff；
• 子任务结果；
• 用户中途追加的需求。

如果每一轮都把所有历史原样传回模型，成本和延迟会越来越高，最后还会超过上下文窗口。

所以，长任务能力并不等于上下文窗口足够大。

更关键的是，系统能不能判断哪些内容要保留，哪些内容可以压缩，哪些工具输出只需要留下结论。

Grok Build 把上下文压缩当成了 Runtime 的正式能力。

官方实现中会根据上下文占用情况触发压缩，还包含 Memory Flush、预压缩、Checkpoint 和历史 Segment 等机制。

可以把它理解成：

原始会话历史
   ↓
提取当前任务、关键决策和未完成事项
   ↓
压缩已经完成的过程
   ↓
保留后续工作需要的信息
   ↓
进入下一段上下文

这里最难的不是“调用模型生成一段摘要”。

真正难的是，压缩之后不能丢掉关键状态。

例如：

• 用户最终想要什么；
• 哪些文件已经修改；
• 为什么做这些修改；
• 哪些测试已经通过；
• 哪些问题仍未解决；
• 当前 Todo 进展到哪里；
• 后续不能违反哪些约束。

如果只把历史压缩成一段泛泛的自然语言总结，Agent 很容易在后面忘记细节，甚至重复做已经完成的事情。

从这个角度看，Agent 的上下文管理更像内存管理，而不是聊天记录归档。

高频使用的信息留在当前窗口，已经结束的阶段被压缩，长期规则进入 Memory，大段工具日志只保留必要结果。

一个能持续工作的 Agent，必须学会有选择地忘记。

Subagent 不是换一个角色 Prompt

现在几乎每个 Agent 产品都在讲 Multi-Agent。

但有些所谓 Subagent，只是换一段 System Prompt，让同一个会话暂时扮演“测试专家”或“架构师”。

Grok Build 的子 Agent 更接近真正的独立任务单元。

按照官方文档，子 Agent 可以拥有独立会话，并行执行任务。源码和文档中还包含独立工具、模型配置和 Git Worktree 等设计。

例如，主 Agent 可以把一个任务拆成三部分：

Agent A：查找性能瓶颈
Agent B：补充测试
Agent C：检查接口兼容性

如果三个 Agent 共用一个工作目录，它们很容易修改同一批文件，导致状态混乱。

Git Worktree 可以给每个 Agent 分配独立工作区：

主仓库
 ├── worktree-agent-a
 ├── worktree-agent-b
 └── worktree-agent-c

每个 Agent 在自己的 Worktree 中修改代码，最后再由主 Agent 汇总结果。

这比“让模型扮演三个专家”复杂得多。

真正的 Subagent 需要处理：

• 独立上下文；
• 独立生命周期；
• 工作区隔离；
• 权限继承；
• 结果回传；
• 失败处理；
• 并行任务之间的冲突。

其中权限继承尤其重要。

如果父 Agent 没有某项权限，却可以创建一个拥有更高权限的子 Agent，那么整个权限系统就形同虚设。

所以，子 Agent 不能突破父会话的权限边界。

从这些设计可以看出，Multi-Agent 做到最后，其实越来越像任务调度系统，而不只是 Prompt 技巧。

权限系统和沙箱是两回事

Coding Agent 可以执行 Shell、修改文件、访问网络，它的安全边界必须比普通聊天产品严格得多。

Grok Build 的安全设计可以分成两层。

第一层是工具和权限控制。

它负责判断：

• 当前 Agent 能看到哪些工具；
• 某个操作是否需要用户确认；
• Hook 是否允许执行；
• 子 Agent 能否继承这项能力。

这一层解决的是“Agent 被允许做什么”。

第二层是操作系统级 Sandbox。

它负责限制：

• 进程能访问哪些目录；
• 是否允许联网；
• 能否启动其他进程；
• 哪些系统调用可用；
• 是否能读取用户的其他文件。

这一层解决的是“进程实际上能做什么”。

两者不能互相替代。

只做权限弹窗不够，因为 Shell 脚本、第三方程序或工具实现本身，都可能产生超出预期的行为。

只做 Sandbox 也不够。如果每次读文件、运行测试都需要人工确认，Agent 基本没法正常工作。

比较合理的做法是：

• 上层权限控制正常工作流程；
• 底层沙箱限制最坏情况下的影响范围。

这也是 Coding Agent 想进入企业开发环境必须解决的问题。

Grok Build 直接吸收了 Codex 和 OpenCode 的实现

Grok Build 的第三方声明中提到，部分工具实现来自 OpenAI Codex 和 OpenCode。

其中包括文件读取、补丁应用、Shell、编辑、搜索和 Todo 等能力。

这个细节很有意思。

它说明 Coding Agent 的基础工具正在逐渐标准化。

不管是 Codex、OpenCode，还是 Grok Build，底层都绕不开这些功能：

• 读取文件；
• 搜索代码；
• 修改文件；
• 应用 Patch；
• 执行命令；
• 管理任务；
• 裁剪过长输出。

这些工具没有必要每家公司都重新发明一遍。

以后不同 Coding Agent 的差异，可能更多体现在工具之上的部分：

• 什么时候调用什么工具；
• 如何组织上下文；
• 如何处理工具失败；
• 如何判断任务完成；
• 如何管理多个子 Agent；
• 如何做权限和隔离；
• 如何适配不同模型。

工具逐渐变成公共基础设施，Harness 才是产品真正需要长期打磨的部分。

它也在主动兼容现有 Agent 生态

Grok Build 没有要求用户重新建立一套完整配置。

官方文档显示，它支持或兼容：

• AGENTS.md；
• MCP；
• Skills；
• Plugins；
• Hooks；
• ACP；
• Claude Code 的部分配置；
• Cursor 的部分 MCP 配置。

这是一个很现实的选择。

已经使用 Claude Code、Cursor 或其他 Agent 工具的用户，通常已经积累了项目指令、MCP 服务、Skills 和 Hooks。

如果换一个 Agent 就要全部重写，迁移成本会非常高。

Grok Build 选择尽可能读取现有配置，而不是从头建立一个封闭体系。

从目前的发展看，Coding Agent 领域可能会逐渐形成几种事实标准：

• 用 AGENTS.md 保存项目指令；
• 用 MCP 接外部工具；
• 用 Skills 封装可复用流程；
• 用 Hooks 扩展生命周期；
• 用 ACP 连接编辑器；
• 用兼容接口切换模型服务。

未来 Agent 产品之间的竞争，未必是谁定义的配置文件更多，而是谁更好地兼容这些已有习惯。

源码开放了，但它不是社区协作项目

Grok Build 使用 Apache 2.0 许可证，开发者可以阅读、修改、构建和再分发代码。

不过，它目前并不是一个传统的社区驱动项目。

README 说明，公开仓库由 SpaceXAI 内部 Monorepo 周期同步。CONTRIBUTING.md 也明确表示，官方不接受外部 Pull Request 和主动提交的 Patch。

因此，这次开源更接近：

• 公开源码；
• 允许自行构建；
• 允许 Fork 和二次开发；
• 方便外部研究实现；
• 但官方开发仍然在内部进行。

换句话说，代码是开放的，上游协作仍然是封闭的。

这不影响它作为参考实现的价值，但需要区分“源码可见”和“社区共同开发”。

重新看 Coding Agent 的技术栈

看完 Grok Build 的结构，可以把一个 Coding Agent 粗略分成四层：

┌──────────────────────────────┐
│          产品与交互层          │
│   TUI / IDE / CI / Dashboard │
├──────────────────────────────┤
│          Agent Harness       │
│ Loop / Memory / Permission   │
│ Compaction / Subagent / Hook │
├──────────────────────────────┤
│           工具与环境层          │
│ Shell / Git / Files / MCP    │
│ Workspace / Sandbox          │
├──────────────────────────────┤
│             模型层             │
│ Grok / Claude / GPT / Others │
└──────────────────────────────┘

过去行业讨论最多的是最下面的模型层。

谁的代码能力更强，谁的上下文更长，谁的推理能力更好。

但模型接口越来越容易替换后，竞争会逐渐往上移动。

一个模型 ID 和 API 地址，改配置就能换。

Harness 中积累的那些边界情况，却很难在短时间内复制：

• 会话中断后如何恢复；
• 工具失败后如何继续；
• 上下文如何压缩；
• 用户插话如何合并；
• 子任务如何隔离；
• 权限如何继承；
• 什么情况下才允许结束；
• 如何避免危险命令越界。

这些都需要在真实使用中一点点补齐。

Grok Build 最值得研究的五个部分

如果只是想用一个新的 Coding Agent，Grok Build 提供了 TUI、Headless 和 ACP 模式。

但从开发者角度看，它更大的价值是提供了一份相对完整的 Agent Runtime 参考。

最值得看的大概有五部分。

1. Agent Loop

重点不是模型怎样发起工具调用，而是整个循环怎样处理：

• 结束；
• 取消；
• 重试；
• 用户中途追加输入；
• 工具失败；
• 最大执行轮数；
• 会话恢复。

2. Context Management

重点看它怎样组织：

• 项目指令；
• 用户要求；
• Memory；
• Todo；
• 文件内容；
• 工具结果；
• 历史摘要；
• Skills 和 MCP 状态。

3. Tool Runtime

一个成熟的工具系统不只是函数列表，还要包含：

• Schema；
• 注册；
• 权限；
• 超时；
• 输出裁剪；
• 错误分类；
• 并发控制；
• 可观测性。

4. Subagent

重点看：

• 会话怎样隔离；
• 权限怎样继承；
• Worktree 怎样管理；
• 结果怎样回传；
• 并行任务冲突怎样处理。

5. Sandbox

重点看上层权限和系统级隔离怎样配合，而不是只看有没有确认弹窗。

结语

Grok Build 这次开源，并没有公开 Grok 模型本身。

它公开的是模型外面的那套工程系统。

这套系统决定了模型：

• 能看到哪些信息；
• 可以调用哪些工具；
• 命令如何执行；
• 失败后怎么恢复；
• 上下文怎样压缩；
• 子任务怎样并行；
• 什么时候才算完成；
• 最多能访问到什么范围。

模型能力决定上限，这一点没有变。

但在真实的软件开发任务里，Harness 决定这个上限到底能发挥多少。

同一个模型，放进不同的 Coding Agent，实际体验可能差很多。原因往往不在模型本身，而在工具、上下文、权限、恢复和任务管理这些地方。

所以，Grok Build 开源后最值得关注的，并不是“又多了一个 Claude Code 的替代品”。

更值得看的，是 SpaceXAI 如何把一个模型组织成能够长期工作的 Coding Agent。

这套代码给出的答案并不神秘：

没有哪个单独的 Prompt 能解决所有问题。

真正可靠的 Agent，最后还是要靠一套扎实的运行时。