11月13日，彭博报道xAI发布了命令行编码智能体Grok Build的早期测试版，这是它第一个专门面向智能体编码市场的产品，目前只对每月300美元的SuperGrok Heavy档开放。与多数竞品相比，它对"一条会话"的定义不太一样。
一条会话里跑八个方向
Grok Build允许在单条会话内同时启动最多8个并行子代理，分别在不同模块、分支或技术方案上工作。Claude Code、Codex、GitHub Copilot这类产品目前仍以单推理线程顺序处理任务，遇到需要权衡的改动时，通常是人先做决定再让模型执行。
并行带来的不是单纯的速度。同一道题让8个代理各做一遍，产生的是8份不同的取舍：有人拆得更细，有人绕开了某个旧接口，有人干脆重写了测试。这8份结果本身就是一次方案空间的采样，价值在于它把决策从"想清楚再动手"变成"先做出来再比较"。
底座是xAI自家的grok-code-fast-1，SWE-Bench Verified上70.8%，上下文256K词元。这个分数在当下的第一梯队里属于有竞争力但不领先的位置，也解释了为什么产品要把力气放在编排而不是单次通过率上。
Arena Mode把选择题变成排序题
第二个差异点是Arena Mode。当多个并行代理产出多份代码时，系统会按开发者指定的标准做锦标赛式自动排序，把"人工逐份对比8份代码"压缩成"审查一份已经排好序的短名单"，最终选择权仍然留给人。
这个设计的副作用比功能本身更值得注意。开发者在Arena里的每一次选择都会成为隐式偏好数据，反过来喂给grok-code-fast-1训练。等于在产品内部造了一个持续运行的私有基准，样本来自真实工程决策，频率远高于任何公开榜单。
代价也在这里。自动排序的标准如果不透明，开发者看到的"前三名"其实是被一套未公开的偏好筛过的结果，长期会塑造他们对"好代码"的判断。产品文档里是否给出排序维度、是否允许导出完整候选集，会决定这个功能是辅助还是收窄。
70.8%这个分数该怎么读
SWE-Bench Verified测的是在真实仓库里修掉指定问题的能力，题目来自开源项目的issue与合并记录，评分靠测试是否通过。70.8%意味着大部分中等难度的问题能独立解决，但它不测需求是否被理解对、不测改动是否引入了新的维护负担。
厂方口径没有给第三方复测，任务分布也没有披露。工程团队真正要看的往往是另外几个数：一次通过后需要人改多少行、改动触及的文件数是否收敛、失败时给出的诊断是否有用。这些指标不在榜单上，却决定了一个智能体能不能进日常流程。
还有一个门槛是订阅价格。每月300美元把产品锁在小众高付人群，早期阶段这未必是坏事，反馈密度比用户规模更重要。但如果8路并行真的成为默认工作方式，token成本会随并行数线性上升，这笔账xAI目前没有公开。
对使用方来说，更实用的判断是设一个对照实验：同一个缺陷，分别用单线程与8路并行各做一次，比较最终改动的行数、review时发现的问题数和总体耗时。如果并行只是把等待时间换成挑选时间，那它带来的收益就是有限的。
本地优先是给采购的一张入场券
Grok Build在策略上最值得注意的是严格本地优先：源码、凭据与项目数据不离开开发者本机，配套细粒度文件访问权限、脚本执行限制，以及可配置的网络请求控制，能限制到指定域名，也能完全阻断，支持气隙环境。
这条对金融、政企、涉及专有代码与受监管数据的团队几乎是决定性的。这类客户采购编码智能体时最大的阻力从来不是能力，而是"代码要不要上云"。把源码留在本地，等于把反对意见的前提拆掉了，剩下的才是能力比较。
但本地优先也会限制产品形态。云端能做的事，比如跨项目索引、团队共享记忆、集中审计，在本地模式下要重新设计。xAI给出的折中是团队插件市场与子代理协调，把共享放在组织自己的边界内，代价是部署与运维的活落到了客户身上。
另外，气隙环境里没有联网检索，模型对最新框架版本的认知会停在训练截止日期，团队需要自己准备文档与示例喂进去。这条限制在宣传里通常不写，但它决定了本地模式更适合改已有系统，而不是起新项目。
与谷歌编排路线的两种哲学
同一周，谷歌在Antigravity里放出了swarm预览，一条指令协调多个智能体、隔离工作区与对抗性校验器；更早一天，它的Orchestrator按任务阶段分派贵的模型与便宜的模型。两条路线放在一起看，差别是编排的切分维度。
谷歌按阶段切：先规划、再执行、再验证，每个阶段用不同档位的模型，追求的是单位任务成本最低。xAI按方案切：同一阶段并行跑多个候选，再用排序收敛，追求的是在不确定问题上不漏掉更好的解。前者适合流程清楚的工程任务，后者适合方向本身就要试错的任务。
两种路线共同的结论是，编码智能体的主战场已经从模型能力转到编排架构。模型分数会继续涨，但涨到某个位置之后，决定交付质量的是怎么拆任务、怎么给上下文、怎么合并结果、怎么在出错时回滚。
代价与还没答的问题
第一笔代价是评审负担。8份候选即使排好序，人仍要读，读的目的是确认排序没有偏。如果团队没有能力快速判断代码好坏，并行只会把噪声放大。第二笔是合并冲突，多个子代理改同一批文件时，冲突解决的成本随并发数上升，这一点在任何并行系统里都一样。
还没答的问题有三个：Arena的排序标准是否会公开，8路并行的账单在真实项目里是什么量级，以及本地优先模式下团队协作与审计怎么做。这三个问题决定它是极客玩具还是团队工具。
第三笔代价常被忽略，是上下文的一致性。8个子代理各自持有独立上下文，它们在同一个仓库里工作时，对"当前代码是什么样"的理解会分叉。谁先合并、合并后要不要让其余代理重新读一遍文件，这些规则如果没有定好，并行就会变成互相踩踏。
从产品节奏看，xAI选择先服务一小批愿意付高价的人，再向大众铺开，这个顺序与它在推理侧的模型迭代节奏一致。真正的观察点不是它能否在榜单上追平，而是并行编排这套方法在半年后会不会被其他厂商抄过去，以及抄走之后，本地优先这条护城河还剩多少。
