Rust 智能体框架之争：grok-build 与 codex
我们克隆了 xAI 的 grok-build 和 OpenAI 的 codex，逐行阅读双方各二十个子系统，探究两个实验室在构建同类编程智能体时究竟有何不同。
作者：Reason Machines
2026 年 7 月 23 日
世界上能力最强的终端编程智能体中，有两个都用 Rust 编写，以单一二进制文件发布，并在相隔几个月内开源：xAI 的grok-build，即 grok CLI，以及 OpenAI 的codex。我们克隆了两者，安排约一百个分析智能体逐行阅读二十个子系统，只为回答一个问题：两个实验室构建同一种工具时，设计取向究竟在哪里分道扬镳？
一个令人不太自在的起点，就在 grok-build 自己的THIRD-PARTY-NOTICES中。它移植了以下项目的工具实现：openai/codex和sst/opencode。这并非完全独立开发的竞争，而是后继者对前辈的重新组合，因此两者的差异反而更值得研究。
相同骨架，不同取向
并排阅读会发现，两者的骨架几乎相同。一个会话 actor 位于类型化消息边界之后。同一个二进制文件提供多种轻量入口：交互式终端界面、无界面执行模式以及编辑器服务器。核心循环也一样：调用模型采样，运行它请求的工具，重复直到停止。双方都将只追加日志持久化为可靠的事实来源，都在上下文窗口填满时压缩对话，都支持恢复会话和创建分支。
因此，有意思的不是架构形状，而是构建出这套骨架之后，各团队在哪些方面坚持不妥协。Codex 做减法，grok-build 向外扩展。
Codex 做减法
Codex 出自一个拥有自家模型、追求控制力、安全性和精简功能面的团队。它的本能是减少选项。它移除了旧的聊天通信协议，只保留一条通往模型的路径。它用单一的推理强度选项替代温度和 top-p 采样。它不打算成为服务商市场，只内置少数第一方后端。
这种专注换来了关键环节的深度：从源码构建、保证确定性的三平台沙箱；按轮次启用功能门控工具规划的策略引擎；包围模型每一条命令的审批与提权层；以及由审查强制执行、禁止改写模型可见历史的规则。阅读 Codex，就像在观察一个为大量从未见过的机器构建平台的团队。
grok-build 向外扩展
grok-build 在架构上更有野心，有些地方也更不成熟。它没有做减法，而是走得更远。机器级主进程通过智能体客户端协议服务多个热客户端。这一新兴跨厂商标准在这里是内部通信协议，而非外加适配。与服务商无关的采样器分发到三种不同的模型协议，新增服务商靠配置而非代码。记忆是一个真正的子系统：将 Markdown 文件建立索引用于检索，而非对历史轮次简单执行 grep。它还内置了tree-sitter代码图用于结构化导航，并提供能跨运行积累的会话记忆。
这套拓扑面向的是运行在他人环境中、生命周期超越任何单一模型的工具。grok-build 防范厂商锁定，正如 codex 防范不可信机器。
评分表
在我们比较的二十个子系统中，codex 在十一个方面的设计更强，八个方面各有千秋，一个方面打成平手。grok-build 没有在任何维度上明确胜出，原因也很实在：codex 是成熟的上游产品，grok-build 则是 v0.1 alpha 版本，源码清楚地反映了这一点。
但那八个难分高下的方面，恰恰体现了野心的回报。更广的模型支持、记忆检索、编辑器协议、云端执行和精确费用统计，都因为尝试得更远，给出了真正不同、有时更好的答案。纸面上的十一比零，实际上讲述的是成熟度与探索野心之间的竞赛。
11 项 Codex 占优 8 项 grok-build 各有千秋 1 项完全持平
子系统 | 结论 | 架构分析 |
沙箱与隔离 | Codex | Codex 提供从源码构建的三操作系统沙箱（macOS/Linux/Windows）。grok-build 覆盖两种操作系统。 |
安全与策略门控 | Codex | Codex 强制执行逐轮功能门控与审批升级提示。grok-build 的安全钩子失败时默认放行。 |
模型协议多路复用 | 各有千秋 | grok-build 清晰地在 OpenAI、Anthropic 和 xAI 之间分发。Codex 限定使用第一方通信协议。 |
智能体客户端协议（ACP） | 各有千秋 | grok-build 采用新兴标准 ACP，实现跨厂商的客户端—守护进程架构。 |
记忆与状态积累 | 各有千秋 | grok-build 为 Markdown 文件建立检索索引。Codex 则重放并压缩原始对话记录。 |
代码图与 Tree-Sitter | 各有千秋 | grok-build 包含原生 Tree-sitter AST 导航 crate，用于构建仓库结构图。 |
技能互操作性 | 各有千秋 | grok-build 可直接使用 Claude 和 Cursor 的 SKILL.md 文件夹，无需手动转换。 |
技能深度与能力 | Codex | Codex 技能是完整的可执行包，包含单元测试脚本和界面元数据。 |
工具治理中间件 | Codex | Codex 使用严格的平台策略防护与验证中间件包围执行过程。 |
对话记录完整性 | Codex | Codex 强制保持模型历史不可变、不可改写，以支持可复现的审计。 |
配置加固 | Codex | Codex 内置加密签名密钥。grok-build 的签名机制在 v0.1 中并未实际生效。 |
无界面执行引擎 | Codex | Codex 的无界面 CI 执行器具有确定性，并经过实战验证。 |
费用与 Token 统计 | 各有千秋 | grok-build 在混合后端间维护精确的逐轮 Token 与金额账本。 |
编辑器服务器集成 | 各有千秋 | grok-build 原生集成为 ACP 语言服务器。 |
错误恢复与继续执行 | Codex | Codex 具有完善的循环检测和自动熔断机制。 |
终端界面（TUI）安全性 | Codex | Codex TUI 完全使用安全 Rust。grok-build 使用原始指针转换。 |
发布打包与可移植性 | 持平 | 两者都编译为单一、静态、独立的 Rust 二进制文件，无需外部运行时。 |
提示裁剪与压缩 | Codex | Codex 的积极上下文压缩保留了推理轨迹。 |
云端执行通信 | 各有千秋 | grok-build 的守护进程拓扑支持向远程无界面工作进程交接任务。 |
遥测与可观测性 | Codex | Codex 的结构化事件追踪支持端到端回放验证。 |
技能、记忆与工具
在技能方面，两者采用相同的SKILL.md约定，并逐步披露信息：在真正打开技能前，上下文中只有名称和描述。grok-build 优先考虑互操作性，可原样读取 Claude 和 Cursor 的技能目录，让已有技能库直接可用。codex 则追求深度，将技能视为包含脚本、参考资料和界面元数据的文件夹，是更丰富的能力单元。
在记忆方面，codex 保留原始对话记录，并据此重建状态。grok-build 使用专用 crate，持久化可由人编辑的 Markdown 并建立检索索引。在工具方面，codex 将工具拆分为模型可见的规范和执行运行时，再叠加完整的治理中间件。grok-build 将工具建模为严格的三 crate 契约，职责分离清晰，但安全层更轻。相同模式反复出现：codex 构建更深入的系统，grok-build 构建更便携的系统。
Alpha 版本的代价
grok-build 的扩展野心也有代价，阅读源码就能看清。配置签名子系统带有两千行测试，却没有内置公钥，因此实际上未生效。钩子失败时默认放行，意味着安全钩子崩溃会悄悄停止执行约束。它的沙箱覆盖两个平台，而 codex 覆盖三个。终端界面中还有不安全的指针转换，靠人工约束而非类型系统保障安全。
对 alpha 版本而言，这些都并非致命问题。多数只是年轻项目的常见特征：威胁模型思考走在了已发布的安全加固之前。但这也是先追求更大架构野心、再补足成熟度的代价。
未生效的配置签名：安全缺口
拥有 2,000 行测试夹具，但发布的二进制中没有任何内置根公钥。签名约束形同虚设。
失败时放行的安全钩子：策略风险
如果外部安全前置钩子发生 panic 或崩溃，执行会继续而不经检查，而不是终止当前轮次。
两操作系统与三操作系统沙箱：覆盖缺口
仅覆盖 macOS 和 Linux。Windows 开发环境中无沙箱执行（Codex 提供 AppContainer 隔离）。
不安全的 TUI 指针转换：Rust 不变式
终端事件处理循环中手动转换指针，依赖开发者自律，而非借用检查器。
我们为什么关心
Reason 是一家围绕智能体框架构建的公司，因此深入阅读两个世界顶尖框架，并非出于无所事事的好奇心。我们不断重新认识到同一条经验：模型是你租用的商品，框架是你拥有的产品。Codex 和 grok-build 是对框架形态的两种可信选择：一个做减法、重安全，一个做加法、重可移植性。两者之间的差距，正是整个领域的关键。
这项分析如何完成
我们克隆了两个仓库，直接阅读源码，而非依赖文档或记忆。多智能体流程分派了约一百个分析智能体：架构绘图者、在二十个维度上分别阅读两仓库的四十个子系统阅读者、二十个一对一比较者，以及综合分析小组；每个智能体返回的数据都经过模式验证。成熟度和边界情况的判断基于所阅读的代码，而非厂商声明。grok-build 版本为 v0.1.220 alpha，codex 使用当时的 main 分支。