Featured image of post 同一个 Grok 4.7,五款 AI CLI 只有两款能用:终端横评报告
深度研究

同一个 Grok 4.7,五款 AI CLI 只有两款能用:终端横评报告

把同一个自托管 Grok 4.7 端点分别接进 codex、grok CLI、opencode、Kimi Code、Claude Code 五款终端,用统一的延迟、智力、工具调用、兼容性四个科目实测。结果:codex 全胜,grok CLI 原生最稳,opencode 能用但肉,而 Kimi Code 和 Claude Code 因为系统提示词太大,直接把账号池打崩。

English

一句话结论:用 codex。它首答 7.4 秒、智力题全对、工具调用 6.9 秒完成,三项全优。亚军是官方 grok CLI(慢一点但稳)。Kimi Code 和 Claude Code 裸接 Grok 4.7 会当场翻车——它们塞给模型的"开场白"太大,网页版账号池物理上吃不消。(更新:发稿当晚已在代理层修复,两款都能用了,见文末"后续"。)

为什么要测这个

我手上有一个自托管的 Grok 4.7 端点(OpenAI 兼容协议,前面挡一层自建 LLM 网关做路由)。模型不错,但"在哪个终端里用它最顺手"一直靠感觉。终端这东西,体验差异不来自模型——同一个模型,换个壳可能从丝滑变成智障。与其猜,不如测。

选了机器上装着的五款:codex CLI(OpenAI)、grok CLI(xAI 官方)、opencode、Kimi Code、Claude Code(Anthropic)。

测试方法:四个科目,控制变量

所有终端走同一个网关、同一个模型、同一时段,题目完全一样:

  1. 延迟:发"只回复两个字:收到",测总耗时(含终端启动,这才是用户真实体感)。
  2. 智力:三道有标准答案的题——9.11 和 9.9 谁大、一元一次方程、古诗接下句。考的不是模型上限,是终端的系统提示词会不会把模型绕晕。
  3. 工具调用:让 AI 创建 hello.txt 并 cat 读回,验证 agent 循环是否完整跑通。
  4. 兼容性:流式输出、报错行为、协议适配,有啥记啥。

成绩单

终端短答速度智力(3题)工具调用结论
codex7.4s3/3 全对✅ 6.9s冠军,全项最快
grok CLI14.2s3/3 全对✅ 5.0s(单项最快)原生适配,稳
opencode14.1s3/3 全对✅ 但 120s能用,干活肉
Kimi Code❌ 死循环0/3—不兼容
Claude Code❌ 直接报错——不兼容

智力题三款可用终端全部满分——再次印证:同一个模型,智力没区别,区别全在终端给它套的那层壳。

关键发现:开场白大小定生死

为什么 Kimi Code 和 Claude Code 直接出局?拆开封包看:

  • Kimi Code 一次请求带 22.4 万字节系统提示词。模型当场死循环,输出"再忽略本句"复读了几百遍直到超时;更早一次还赶上账号池被撑到"全部耗尽",终端对 503 无限静默重试,挂了四分钟一声不吭。
  • Claude Code 更夸张,29.7 万字节。请求打过去,上游直接"token 生成内部错误",还触发了后端看门狗重启代理。
  • codex 的系统提示词约 1.3 万 token,池子毫无压力。

规律很直白:网页版账号池这类轻量后端,只吃得消小开场白。终端注入的系统提示词越大,模型越容易晕、后端越容易崩。grok CLI 自家终端提示词最小,所以它永远最稳;codex 控制得也不错;opencode 居中;Kimi 和 Claude 是为自家旗舰模型设计的,提示词体量根本不是一个量级。

能用三款的细节差异

  • codex(7.4s):启动快、响应快、工具链路干净。新版 codex 砍掉了 chat 协议、只认 Responses 协议,但我的网关能把 Responses 翻译成后端的 chat completions,意外成了最顺的一个。
  • grok CLI(14.2s):慢在 Node 启动和初始化,但一旦跑起来,工具调用全场最快(5.0 秒)——亲儿子毕竟最懂自家模型的脾气。重度干活场景它和 codex 其实打平。
  • opencode(14.1s / 工具 120s):都能跑通,但工具循环慢得离谱——创建个文件要两分钟。日常问答可用,agent 干活别选它。

顺手踩到的三个坑

  1. Claude Code 有模型名校验:模型名不以 “claude” 开头直接拒发请求,根本不给你试的机会。
  2. 网关的 model alias 是"改名"不是"加别名":我给 grok-4.7 设了个别名想绕上面那个校验,结果原名立刻从网关消失,正在用它的其他客户端当场 400。踩完秒回滚。
  3. Kimi Code 遇到 503 会无声无限重试:没有任何提示就干等,接不稳定后端时这是个雷。

codex 接法(照抄可用)

1
2
3
4
5

OPENAI_API_KEY=<你的网关密钥> codex exec --skip-git-repo-check \
  -m grok-4.7 \
  -c model_providers.custom.base_url="http://127.0.0.1:8317/v1" \
  -c approval_policy="never" \
  "你的任务"

要点:新版 codex 必须走 Responses 协议(网关负责翻译);--skip-git-repo-check 让它在非 git 目录也能跑;stdin 记得重定向,否则它会干等输入。

局限

单后端、单时段、题目偏小;账号池当时有别的负载在跑,延迟数字当区间看别当绝对值。但"开场白大小决定兼容性"这个核心结论,复测了多轮都成立。

后续:发稿当晚,我把它们修好了

文章上线后我没忍住,把暴露的问题挨个修了——改的都是自家代理那一层,没动终端本身。当天晚上复测,Kimi Code 和 Claude Code 都能正常对话了。

  1. 给代理加系统提示词截断器:单条请求的系统提示词总长超过 12,000 字符就从头截断(身份和核心规则都写在开头,砍的是尾巴),并打上"已截断"标记。Kimi Code 的开场白被压下来之后,死循环消失,乖乖答题。
  2. 4MB 请求体上限:超限直接拒收(413)。再野的终端也别想把账号池打到看门狗重启。
  3. Claude Code 挂起的真凶,比巨型开场白更黑:抓包发现,模型每轮其实都正常回答了"收到"——但它同时硬塞一个工具调用;终端执行完把结果发回去,模型下一轮再答再塞,12 轮下来消息数从 2 条涨到 35 条,死循环。根子在我代理的一段旧逻辑:它无条件强制模型"必须调用工具"(本是防它中途罢工的),连首轮纯回答也被逼着调工具。改成"首轮自由、任务中强制",再加个断路器兜底——同一个工具调用重复 4 次就剥掉工具、强制文本收尾。
  4. 顺手修了 Kimi Code 的 503 死等:官方配置里有个"每步最大尝试次数"(默认 10 次,每次等 60 秒),调到 3——以后后端再抽风,一分钟内就报错,不会无声挂四分钟。

修完的成绩单:Kimi Code 正常问答;Claude Code 短答 13.7 秒干净退出,让它读文件的 agentic 任务也完整跑通——唯一残留是收尾时把文件内容复读了一千多遍,那是 Grok 4.7 模型自己的复读毛病,不归设施管。

所以原文结论要修正半句:这两个终端不是"物理上接不了" Grok 4.7,是裸接接不了。给后端前面加一层会瘦身、会刹车的代理,五个终端全能用。但"日常主力选 codex"的建议不变——能跑和跑得稳,是两回事。

最后

选终端这件事,以前我看功能列表,现在我看开场白预算。尤其是接自托管小后端时,终端往请求里塞的东西,比它的 UI 好看与否重要一百倍。建议你也拆开自己终端的请求看一眼——那几百 KB 的系统提示词,可能就是你又慢又贵的元凶。