Grok Build CLI 上手体验
目前我正在同时使用 Claude Code CLI 和 Grok Build CLI，以便对两者之间的实际体验有一个直观的感受……
AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
这些是真正存在于我们工作场所中的 Agent Harness
大多数 AI 编码代理仍然感觉像是那些偶尔访问终端的人设计的，而不是那些在终端中生活的人设计的。
它们把命令行当作一个你偶尔会逃离去的地方，而不是一个进行严肃工程工作的主要环境。
Grok Build 可能是第一个让人觉得它是由理解终端不是约束、而是我们所拥有的最高杠杆率接口的人构建的……
这不是另一个附带一些文件编辑功能的聊天界面。
它更有趣：尝试将缺失的 Agent Harness 层直接构建在最高信号工作已经发生的环境中。
我这样说是因为过去几个月我一直生活在 Claude Code CLI 中……不仅仅是用于编写代码，还作为我 MacBook 的通用接口。
终端就是产品本身
1、模型
grok-build 不是人们在 grok.com 或移动应用上使用的通用 Grok 4.3。
它是 xAI 专门为重度代理工作流（大量工具使用、长时间运行任务）调优的专用变体。
还包括子代理和并行执行规划模式。
该模型还针对代码库探索和编辑进行了优化……
所有这些都旨在优化完整的 Grok Build TUI 体验。
它确实与普通聊天模型感觉不同，因为主要焦点是模型将要做的那种工作……
读取代码、运行命令、编辑文件、生成专业子代理等。
2、CLI 复兴是真实的！
在之前的一篇文章中我写过，命令行正在悄然成为 AI 代理最强大的接口。
不是因为它的老旧，而是因为它的老旧。
同样的论点在这里也适用。
CLI 的特点是：
- 在所有重要地方已经安装
- 深度嵌入在每个前沿模型的训练数据中
- 自文档化
- 无限可组合
- 低延迟，零 UI 装饰
当 Jensen Huang 谈论从预录制软件转向实时处理时，CLI是这种转变的自然交付机制。
代理不需要预先构建的集成层。它可以直接推理和行动。
大多数代理工具还没有内化这一点。它们仍然构建漂亮的 Web UI，或者在 VS Code 中嵌入聊天窗口，或者给你一个薄的包装器来流式传输文本，而你在五个不同的界面之间进行心理上下文切换。
Grok Build 是否从一个不同的前提出发——终端就是产品？
3、真正的 Agent Harness 是什么样的
在我最近关于 AI Harness Engineering的内容中，我描述了位于原始模型和可靠结果之间的组件：
- Context Engine（上下文引擎）
- Planner（规划器）
- Memory Manager（记忆管理器）
- Verifier（验证器）
- Tool Registry（工具注册表）
- Harness Config（配置管理）
大多数工具只很好地实现其中一两个。
Grok Build 实现了更多，并且它将它们实现在最有用的地方。
让我展示这在实践中是什么样的……
4、主界面
以下是当你生活在其中时实际看到的：
使用 Grok Build 时，没有会丢失关键细节的强制摘要。
没有"这是我做了什么的摘要"然后你需要展开。完整的追踪是可导航的、可折叠的，并且可以通过单次按键复制。
这就是 Context Engine 被可视化和可控化。
5、规划模式
当你给 Grok Build 一个真正模糊的任务时，它做了一件大多数代理不做的事情。
它提议进入规划模式。
在规划模式中，代理可以自由地读取、搜索和探索代码库。
它不能做的是编辑文件或运行破坏性命令。它唯一被允许写入的是会话中的结构化 'plan.md'。
只有在你批准计划后，执行才开始。
实现开始前的时刻。代理已经探索了代码库，在批准之前只能写入计划文件。
可以把这看作是 harness 的规划层被显式化。
如果一个代理过于急切是有危险的……它们在理解现有模式、故障模式、二阶后果等之前就开始编码。
规划模式强制执行一种高级工程师的纪律：思考、记录方法、获得对齐，然后才实现。
6、技能作为捕获的智能
代理系统中最困难的问题之一是将一次性成功转化为可重复的能力。
你可以尝试在每个提示中告诉模型始终遵循我们的提交约定。
或者你可以手动捕获实际的工作流一次并使其可调用。
但是，Grok Build 有一个叫 /skillify 的命令。
把它想象为一个捕获工作流的工具，这样你（和他人）可以重用它们，而无需每次都解释整个过程。
大多数工具遗漏的 harness 的最后一块是并行分解。
7、并行分解
Grok Build 让主代理生成独立的子代理，每个子代理都有自己的上下文窗口和定义的角色。
你可以有一个 reviewer（审查者）子代理读取你刚做的 diff，同时一个 implementer（实现者）子代理在编写下一部分。
或者一个 researcher（研究者，只读）在做深度调查，而你在父会话中继续工作。
这不是模拟的并行，这些是真正的独立会话。
它们消耗自己的上下文。它们可以被赋予受限的能力模式。
它们甚至可以在隔离的 git worktrees 中运行，因此它们的更改不会与你的冲突，直到你选择合并它们。
8、结束语
看起来 Grok Build 试图让终端成为 harness 为你做协调工作的单一界面……规划、记忆、验证、并行分解，同时你留在开发者曾经拥有的最高带宽环境中。
它并不完美。
TUI 还在发展中。一些 MCP 集成比其他的更成熟。但方向是正确的，这种正确性我在其他地方没有见过。
随着模型不断变得更好，harness 是将更好的模型转化为可靠地更好结果的关键。
原文链接：Grok Build CLI Feels Different to Claude Code CLI…
汇智网翻译整理，转载请标明出处
