Grok Build CLI 实测

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

目前我正在同时使用 Claude Code CLI 和 Grok Build CLI，以获得两者之间什么更适合我的直观感受……

这些是真正存在于我们工作场所的智能体框架。

大多数 AI 编码智能体仍然感觉像是偶尔访问终端的人设计的，而不是住在里面的人设计的。

它们把命令行当作一个偶尔逃到的地方，而不是严肃工程发生的主要环境。

Grok Build 可能是第一个感觉像是懂终端的人构建的——终端不是约束，而是我们拥有的最高杠杆率的界面……

这不是另一个附带一些文件编辑功能的聊天界面。

它更有趣：尝试直接在最高信号工作已经发生的环境中构建缺失的智能体框架层。

我这么说是因为过去几个月我一直生活在 Claude Code CLI 中……不仅仅是写代码，还把它作为我 MacBook 的通用接口。

终端就是产品

1、模型

grok-build 不是人们在 grok.com 或移动应用上使用的通用 Grok 4.3。

它是 xAI 专门为重度智能体工作流（大量工具使用、长时间运行任务）调优的专门变体。

还包括子智能体和并行执行规划模式。

该模型还针对代码库探索和编辑进行了优化……

所有这些都是为了优化完整的 Grok Build TUI 体验。

它确实与普通聊天模型不同，因为主要焦点是模型将要执行的那种工作……

阅读代码、运行命令、编辑文件、生成专业子智能体等。

2、CLI 复兴是真实的！

在我之前关于 CLI 是通往 AI 自主之路 的文章中，我写到命令行正在悄然成为 AI 智能体最强大的界面。

不是因为它的年龄，而是正因如此。

同样的论点在这里也适用。

CLI 的优势：

• 已经安装在每个重要的地方
• 深度嵌入在每个前沿模型的训练数据中
• 自文档化
• 无限可组合
• 低延迟，零 UI 装饰

当 Jensen Huang 谈到从 预录制软件转向实时处理时，CLI是这种转变的自然交付机制。

智能体不需要预构建的集成层。它可以直接推理和行动。

大多数智能体工具还没有内化这一点。它们仍然构建漂亮的 Web UI，或者在 VS Code 中嵌入聊天窗口，或者给你一个薄包装器，在你心理上在五个不同界面之间上下文切换时流式传输文本。

Grok Build 是否从一个不同的前提开始——终端就是产品？

3、真正的智能体框架是什么样的

在我最近关于 AI 框架工程 的内容中，我描述了位于原始模型和可靠结果之间的组件：

• 上下文引擎
• 规划器
• 内存管理器
• 验证器
• 工具注册表
• 框架配置

大多数工具实现了一两个。

Grok Build 实现了更多，并且它在它们最有用的地方实现了它们。

让我向你展示这在实践中是什么样的……

4、主界面

当你在其中工作时，你实际看到的是这样的：

使用 Grok Build 时，没有会丢失关键细节的强制摘要。

没有"这是我做了什么的摘要"然后你必须展开它。完整的轨迹是可导航的、可折叠的，可以通过单键击复制。

这就是可见且可控的上下文引擎。

5、计划模式

当你给 Grok Build 一个真正模糊的任务时，它会做大多数智能体不会做的事情。

它提议进入计划模式。

在计划模式中，智能体可以自由地阅读、搜索和探索代码库。

它不能做的是编辑文件或运行破坏性命令。它唯一被允许写入的是一个结构化的 plan.md。

只有当你批准计划后，执行才开始。

实现开始前的时刻。智能体已经探索了代码库，只能写入计划文件，直到你批准。

可以把它看作框架的规划层被显式化了。

如果一个智能体过于急切是有危险的……它们在理解现有模式、失败模式、二阶后果等之前就开始编码。

计划模式强制执行一种高级工程纪律：思考、记录方法、获得对齐，然后才实现。

6、技能即捕获的智能

智能体系统中最困难的问题之一是将一次性成功转化为可重复的能力。

你可以尝试在每个提示中告诉模型始终遵循我们的提交约定。

或者你可以手动捕获实际的工作流一次并使其可调用。

但是，Grok Build 有一个叫 /skillify 的命令。

把它想象成一个捕获工作流的工具，这样你（和其他人）可以重用它们而不必每次都解释整个过程。

大多数工具缺少的框架的最后一部分是并行分解。

7、并行分解

Grok Build 让主智能体生成独立的子智能体，每个都有自己的上下文窗口和定义的角色。

你可以有一个审查者子智能体在你刚做的 diff 上进行审查，同时一个实现者子智能体正在编写下一部分。

或者一个研究员（只读）在进行深入调查，而你继续在父会话中工作。

这不是模拟的并行，这些是真正的独立会话。

它们消耗自己的上下文。它们可以被赋予受限的能力模式。

它们甚至可以在隔离的 git worktree 中运行，这样它们的更改不会与你的冲突，直到你选择合并它们。

8、结束语

Grok Build 似乎正在尝试让终端成为框架为你完成协调工作的单一界面……规划、内存、验证、并行分解，而你留在开发者曾经拥有的最高带宽环境中。

它并不完美。

TUI 仍在演进。一些 MCP 集成比其他的更成熟。但它的方向是正确的，以我在其他地方没有见过的方式。

随着模型不断变得更好，框架是将更好的模型转化为可靠地更好结果的关键。

原文链接: Grok Build CLI

汇智网翻译整理，转载请标明出处