Terminal Bench 4.0 刚发布，榜单上 GLM-5.3 和 Fable 5 在误差范围内打成平手。但比起“谁第一”，更值得关心的其实是：这个结果怎么读、每完成一次任务要烧多少 token、以及普通开发者想给自家 agent 做客观评测时到底有没有负担得起的路径。

Terminal Bench 4.0 的发布重点

官方公告里最让人认可的一点是：他们强调要快速迭代 Terminal Bench，跟上新模型发布的节奏，以此对抗 benchmark 饱和。这个思路很实际，因为很多跑分在被模型“看穿”之后，区分度会迅速下降。作者原话是“大规模跑分单次要吃掉 5-10B token”，对绝大多数个人和中小团队来说，无论是经济成本还是算力成本都不可接受。所以作者希望找到更小的替代方案，能客观度量自己的 agent 框架、工具设计、提示词对 token 消耗和成功率的影响，哪怕只给出大致方向也行。

“同级”背后的统计争议

榜单显示 GLM-5.3 的分数和 Fable 5 很接近，但有人急着下结论说“Fable 在平均值上还是更好”。立刻有网友反驳：Fable 当前测得比 GLM-5.3 高，但差距在误差范围内，因此我们无法判断到底谁更好。这不是抠字眼，而是统计上的基本事实——在误差范围内说“平均更好”是过度解读。也有人提到实际使用中非常明显：Opus 5 并不比 Fable 5 强，尽管跑分可能相反。另外有人觉得新模型在 Terminal Bench 上的提升幅度“可疑”，不像单纯饱和问题，更像评测方法本身有未被解释的偏差。

成本与 token 效率：比跑分更值得看

真正让讨论跳出“谁更强”的是成本视角。有网友根据榜单中的任务成本算了一笔账：GLM-5.3 在 Terminal Bench 4.0 上的实际任务开销大约是 Fable 的 37%——这是根据该 benchmark 任务实际产生的费用算出来的。但同时，也有人指出 GLM-5.3 这次跑完花了近 $2.7k，比 GPT-5.6 Sol 的 $2.5k 更高，而且消耗的 token 数几乎是后者的两倍。奇怪的是，在 3.0 版本上两者要求的 token 数差不多，因此当时 GPT-5.6 Sol 比 GLM-5.3 贵了两倍多。这说明 token 单价低不一定意味着总成本低，模型要“多说多少废话才能完成任务”同样关键。

另一位使用者补充了一个被忽略的点：大家总盯着 token/s，却忽略了某些模型完成同一任务可能要多花 2-3 倍 token。成本/任务能部分反映这个问题，但不够全面，因为没算上速度。理想情况下本地推理应该衡量“tok/s + token 啰嗦度”，API 推理则是“tok/s + token 啰嗦度 + 定价”。否则一个跑得慢、但话特别多的模型，很容易在成本上被低估。

个人评测 agent 的轻量思路

面对 5-10B token 的大跑分，普通开发者不可能每次都跑。几位网友建议从具体任务集入手：先挑自己的 agent 经常失败的任务类型，构造 20-50 个代表性样本，固定 seed 和最大步数，记录每次的 token 消耗、成功率、重试次数。注意不要只跑一次——误差范围内的小差距根本说不清。另外，一个老问题是：别让“模型被误判误杀”污染数据。有网友提醒，如果某个模型在某些提示词下突然变笨，可能是触发了它的安全分类器，被透明地重新路由到一个弱模型上。这种情况在 Fable 上尤其明显，有人抱怨它大部分时间正常，但随机某个任务上会突然像换了 LLaMA 2 一样。

使用体验中的“主观但真实”信号

抛开跑分，几位实际使用者给出了自己的手感。有人说自己写代码主力是本地 DeepSeek Flash，但 GLM-5.3 已经成为他做 code review 的首选，能发现 GPT Sol 漏掉的问题。也有人从另一个角度提问：这模型适不适合当“互联网女友”？这就看个人需求了。另外，GLM-5.3 之所以能让人记住，Z.ai 的开源协议也功不可没——允许小公司和个人随便用，但年收入超 100 亿美元的大厂得先通过安全审查，不少人觉得这协议“很艺术”，等于明确说“小兄弟们先上，大公司排队”。

怎么看待这次发布

如果只想选一个模型来做 agent 后端，建议别只看 Terminal Bench 4.0 的总榜。先看误差范围，如果差距在误差内，就选便宜的那个（这里大概率是 GLM-5.3，任务成本仅 Fable 的 37%）。再实测自己的任务集，同时记录 token 消耗和失败模式。毕竟跑分只能给你一个大方向，真正改变生产力的，是“一次跑通、少说废话、稳定发挥”三个指标。