26K Star 的 Grok Build：与 Codex、Claude Code 差在哪？

GitHub 上一个 26000 多 Star 的终端编程 agent 项目 Grok Build，最近引起了不少开发者关注。它由 xAI 开源，打开代码仓库后可以让它读文件、改代码、跑命令、查网页，还能把任务拆给多个子 agent。问题在于——这些事情 Codex 和 Claude Code 也都能做，那 Grok Build 到底有什么不同？

这篇文章把三款工具放在一起对比，重点不是跑一次结果给模型排座次，而是看它们的工作方式、扩展能力和权限边界这三个维度上的差异。

Grok Build 的核心：全屏终端界面

Grok Build 最鲜明的特点是一套全屏终端界面。对话、命令、文件修改、任务进度和子 agent 状态，都能放在同一个窗口里。它同时支持键盘操作和鼠标点击，长输出可以展开，计划和代码差异也能直接检查。

以一个常见任务为例：先读项目规则、找到相关文件、给出修改方案，改完后跑测试再查看差异。Grok Build 可以先进入计划模式——这个阶段只允许它读代码和写计划文件，等你看过方案并批准后，它才开始真正改动项目。

如果任务能拆开，它可以启动多个子 agent。每个子 agent 可以共用当前目录，也可以进入独立的 Git 工作树，从而减少同时改代码造成的冲突。这套流程听起来很完整，但需要说明的是——Codex 和 Claude Code 也有对应能力。

ACP（Agent Communication Protocol） 是 xAI 提出的一套 agent 间通信协议，允许外部脚本、CI/CD 流水线或编辑器通过标准化接口向 Grok Build 发送指令并接收结果，而不必依赖交互式终端。与之对应的 MCP（Model Context Protocol） 则是 Anthropic 主导、已被多个工具采纳的更广泛标准，主要用于让模型访问外部工具和数据源。两者定位不同：MCP 更偏向「模型如何调用工具」，ACP 更偏向「agent 如何被外部系统调度」。理解这一区别有助于判断 Grok Build 是否适合嵌入你已有的自动化流程。

功能清单相似，差别在于「重心」

三款工具都能读项目、改文件、执行命令、跑测试，也都能连接 MCP、加载 skills、调用子 agent。单看功能清单，很难分出高下。真正影响使用感受的，是它们把这些能力放在了什么位置。

Grok Build 的重心在全屏终端界面，适合一直盯着任务进度，也能把命令送到后台继续运行。它还提供无界面模式和 ACP 协议接入，可以对接脚本、持续集成，或支持该协议的编辑器。

Codex 的入口更分散：你可以在命令行工作，也可以用桌面端、IDE 和云端任务。桌面端能把不同任务放进独立工作树，完成后再交接回本地目录。已经在 ChatGPT 和 Codex 生态里工作的人，切换成本会比较低。

Claude Code 仍然很强调终端工作流。它的 CLAUDE.md 自动记忆、Hooks、子 agent 和 agent teams 已经形成一套完整的配置体系。当你需要在改文件、跑命令或提交代码前后自动插入检查时，Hooks 会非常有用。

项目规则与迁移兼容

项目规则的文件名值得注意。Grok Build 和 Codex 都会读取 AGENTS.md，而 Claude Code 主要读取 CLAUDE.md。它们都支持从个人配置到仓库目录逐层补充规则。换工具时，原来的项目规范不一定能直接通用，需要先检查文件名和兼容范围。

Grok Build 在这方面做了一些迁移兼容：它的 skills 除了读取自己的目录，也能扫描 Claude Code、Cursor 和通用的 agents 目录。已经积累了一批 skills 的人，可以少搬一些文件。

AGENTS.md 和 CLAUDE.md 本质上都是放在项目仓库中的纯文本「系统提示补充文件」，用于告诉 agent 该项目的编码规范、禁止操作、常用命令等背景信息。支持「逐层补充」意味着可以在用户主目录放全局规则，再在子目录放针对该模块的规则，agent 会按路径层级合并读取。这种机制的价值在于：同一套规则可以约束所有协作者使用 agent 时的行为，把团队共识固化为版本可追踪的文件，而不是散落在每个人的本地配置里。

权限与沙盒：Windows 用户要留意

在权限和沙盒方面，三款工具的思路一致，都是把「审批」和「沙盒」分开处理，但覆盖平台有差异。

Grok Build 默认会在执行命令或编辑文件前询问，可以配置允许、询问和禁止规则，也可以加 Hooks 做拦截。它还提供可选的系统级沙盒，不过官方文档目前列出的实现重点是 Linux 和 macOS，且沙盒默认不开启。

Codex 同样把审批和沙盒分开，常用的工作区模式允许它在项目里编辑和运行命令，越过边界时再请求批准。官方提供原生 Windows、WSL2、Linux 和 macOS 对应的隔离方案。

Claude Code 也是全线加沙盒。需要注意的是，它的 Bash 沙盒支持 macOS、Linux 和 WSL2，原生 Windows 暂不支持这层隔离。Windows 用户如果在意完整沙盒，最好放到 WSL2 里运行。

WSL2（Windows Subsystem for Linux 2） 是微软在 Windows 10/11 上提供的 Linux 内核兼容层，能运行完整的 Linux 二进制程序。对于 Claude Code 这类依赖 Linux 沙盒机制（如 namespace、seccomp）的工具，WSL2 提供了在 Windows 上获得等效隔离能力的最直接路径。需要注意的是，WSL2 环境与宿主 Windows 文件系统之间的路径映射和权限规则与原生 Linux 有所不同，在配置项目根目录和 agent 工作区时应提前确认路径是否正确映射，避免 agent 意外访问或修改宿主系统文件。

账号与费用

客户端开源不代表模型调用免费。Grok Build 首次启动默认打开浏览器登录，无浏览器环境可以用 xAI 的 API Key。Codex 可以用 ChatGPT 登录，也有适合自动化的 API 认证。Claude Code 可以走 Claude 订阅、Anthropic API 或云平台账号。

正式使用前，最好先确认自己的套餐用量和数据要求。

三款工具怎么选

• 如果你已经经常使用 ChatGPT、Codex 桌面端和云端任务，Codex 的多入口会更顺手。
• 如果你的项目已经围绕 Claude Code 搭了很多 Hooks、CLAUDE.md 和子 agent，继续用它通常最省迁移成本。
• 如果你想用 Grok 模型、喜欢全屏终端界面，或者需要后台任务循环监控和 ACP，Grok Build 值得装起来试试。

最后补充几个关键信息：截至 2026 年 9 月 9 日，Grok Build 有 26592 个 Star，使用 Apache 2.0 许可证。官方更新日志显示最新版本是 1.0.13，最近仍在修复 Windows、MCP、子 agent 和绘图稳定性相关问题。

三款工具的差异不在「能做什么」，而在「把能力放在哪里、给谁用最顺手」。选型时结合自己的现有生态和平台，比单看跑分更实用。