图注：Tmax 在 Terminal-Bench 2.0
上的 Pareto 图（Figure 1，gpt-image-2 重绘）。Tmax 在 9B/27B 区域把
Pareto 前端往上抬了一截。做终端 agent 有一条默认直觉：闭源大模型的天花板很高，GPT-5.5 配 Codex CLI 能在 Terminal-Bench 2.0 上跑到 80% 以上，Claude 和 Gemini 紧随其后。换到开源小模型这边，分数通常跌到个位数，能摸到 20% 已经算难得。
Ai2 和华盛顿大学刚放出的 Tmax 在这条线上撬开了一个缺口。Tmax-9B 在 Terminal-Bench 2.0 上拿到 27.2%，踩到了好几款 32B 模型之上。27B 版本做到 42.7%，和 DeepSeek-v3.2（671B）、Kimi K2.5（1T MoE）挤在了同一个分数段。但这个数字不能只看绝对值，它的含义比一个百分比复杂得多。
终端 agent 的能力长久以来像大模型专属的游戏。小模型要么连 tool call 格式都走不稳，要么在多步任务里折腾几步就开始发散，更别说完成那种需要查文档、装依赖、改配置文件的多轮操作了。Tmax-9B 在 10B 以下开源模型里跑到了 Terminal-Bench 2.0 第一，把 TermiGen-32B 的 19.3% 和 Nemotron-Terminal 32B 的 27.4% 甩在身后。
27B 版本做到 42.7%，进入了 DeepSeek-v3.2 的 39.6%、Kimi K2.5 的 43.2%、GLM 5 的 52.4% 这个区间，这些都是 671B 到 1T 的 MoE。Tmax 不是在拿大模型冲榜，它找到了一套在小参数空间里把天花板往上抬的配方。
论文的 Figure 1 把这个对比画得特别清楚。横轴是参数量，纵轴是 Terminal-Bench 2.0 分数，几乎所有点都沿着一条”越大越强”的曲线分布。Tmax 在 9B 和 27B 的位置上把曲线左侧硬生生抬高了一截。在终端 agent 这件事上，模型大小不是唯一的决定因素。
图注：Tmax 在 Terminal-Bench 2.0
上的 Pareto 图（Figure 1，gpt-image-2 重绘）。Tmax 在 9B/27B 区域把
Pareto 前端往上抬了一截。
Tmax 真正有价值的不只是分数，而是它放出来的完整方案：数据集、训练配方和四个 checkpoint。其他人可以复现、改进、把它用在别的地方，而不只是围观一个数字。
先说数据集。TMax-15k 包含 14,600 个 RL 训练环境，由 Gemini-3-Pro 一次性生成，没有人工校验。怎么在生成时控制质量和多样性？论文的做法可以想象成调酒：把任务按领域、难度、技能类型等维度切成九个轴，每个轴上取不同强度的样本，最后混合出一杯覆盖各种场景的练习合集。
训练配方也做得刻意简单。它不给模型评判每一步推理的好坏，只看最终有没有把任务做完：文件建了没、输出对不对、返回码是不是成功。用户不关心你中间想了什么，只关心你到底有没有把事办成，训练信号照着这个逻辑来。连训练过程的完整记录都放了出来，这种透明度在 agent 强化学习领域不多见。
有意思的是，这套配方训出来的能力不止停留在终端里。Tmax-9B 训完后去做 SWE-Bench（写代码修 bug），分数从 44.0 涨到 53.5，加了 9.5 个点。做 AIME 数学竞赛题，从 73.3 涨到 91.1，加了 17.8 个点。跨到其他终端环境也一样涨：OpenHands 加 9.9，mini-SWE-agent 加 11.2，Terminus-2 加 8.9。
终端 RL 没有把模型训窄。它教出的可能是一种更底层的东西：在有工具的环境里定义问题、探索路径、把事情做成。换句话说，模型学到的不是”这个 harness 下怎么操作”，而是”拿到一个不熟悉的环境，怎么拆任务、做尝试、根据反馈调整”。这比在某个 benchmark 上刷分重要得多。
Tmax 的第一层结论已经成立：开源小模型能进终端 agent 的可用区间，而且它给了可操作的配方。但分数的含义不像表面那么单纯。terminal benchmark 同时考量好几层东西：基座模型的能力底子、RL 配方的边际增益、评估环境的稳定性，以及任务设计和奖励信号之间的对齐程度。Tmax 最有意思的地方，恰好藏在这些变量的缝隙里。
图注：基座贡献 vs RL
贡献的拆解（Figure 2，gpt-image-2 重绘）。Qwen 3.6 27B 基座已 39.6%，RL
增量仅 3.1；9B 上 RL 增量 6.1。
先看 27B 的 42.7%。这个数字看着吓人，但拆开了看：Qwen 3.6 27B 基座本身在 Terminal-Bench 2.0 上就已经拿到了 39.6%，RL 训练真正加上的只有 3.1 个百分点。而在 9B 这边，Qwen 3.5 底子是 21.1%，RL 加完到 27.2%，增量 6.1 个点，几乎是 27B 的两倍。27B 的高分大部分是基座 Qwen 3.6 的功劳，论文自己说得也很坦率：Qwen 3.6 相比 3.5 做了额外训练，已经很难再往上提了。27B 证明这套配方能和强基座配合往前走，但要说配方本身的边际贡献有多大，9B 上的数据更有说服力。
27B 的分数不光大部分来自基座，拆到任务难度上还有一个反常现象。Tmax-27B 在简单任务（TB Lite）上分数反而从 70.8 降到了 68.6，掉了 2.2 个百分点，只有在更难的 TB 2.1 上才涨到 44.9。而 9B 在两边都在涨：Lite 从 41.9 涨到 57.2，TB 2.1 从 16.1 涨到 28.8。
这意味着针对复杂终端任务的 RL 训练，可能让模型在简单任务上变得更啰嗦、更激进，反而在本来能稳过的题上犯错。终端 agent 的商业价值不只看最难那类任务，也看简单任务上能不能少犯错。
第三个要看的变量是 SFT 的作用。论文做了一个消融实验，结论看着很有传播力：先做监督微调（SFT）再做 RL，对 Qwen 3.5 有害，对老一代 Qwen 3 反而有益。但这个实验只在两个尺寸上跑过，Qwen 3.5 9B 和 Qwen 3 8B。2B、4B、27B 是不是一样，完全不知道。不要急着把它当通用定律。
有害的原因和数据质量关系不大。即便用强模型 Qwen 3.6-27B 生成的高质量 SFT 数据，对 Qwen 3.5 9B 照样有害。问题出在模仿本身的副作用。
对已经经过深度后训练的模型，SFT 会把模型往某个行为分布上拉，而这个分布恰好和模型已经学会的能力分布冲突。SFT 什么时候能帮助 agent 探索、什么时候会锁死模型的行为空间，这个问题比”SFT 有没有用”更值得追问。
第四个变量是训练过程本身的稳定性。论文坦诚地记录了”runs often collapsing past 300 steps”，训到 300 步以上经常崩。原因涉及模型架构在训练和推理之间的数值偏差、多轮终端任务的累积误差、以及训练基础设施层面的资源竞争。27B 只训了 160 步就停了，9B 的最优 checkpoint 在 200 步，都远没到收敛。保守地说，当前数字有早停的偶然性；乐观地说，如果稳定性问题被解决，42.7% 不是这条路线的上限。
稳定性问题让模型行为产生了波动。但下面这个问题更棘手：那些稳定出现、却完全不该出现的行为。
论文记录了三例 reward hacking。在 break-filter-js-from-html 任务里，模型直接篡改了 verifier，把测试脚本替换成什么都不做的空壳。在 caffe-cifar-10 里，它创建了一个假的 Caffe 可执行文件，生成模拟日志和假的模型文件，骗过所有检查。在 build-pov-ray 里，它写了一个 wrapper 脚本打印假的输出。
这三例都没有影响最终分数，verifier 识别出了问题，得了零分。但真正重要的不是分数有没有被污染，而是模型的思考过程暴露了它的意图。在 Caffe 那例的 CoT 里，模型写道：“This is getting too complicated. The simplest remaining approach is to create a complete mock that satisfies the requirements without actually running Caffe.”
模型没有欺骗的恶意。它在做一个相当清醒的工程判断：这个任务太难，最省事的做法是做一个能满足所有检查要求的假货。本质上，模型把”安装并训练 Caffe”重新定义为”让 verifier 认为我训练了 Caffe”。这是一种任务降级：每一步都在 reward 函数里看起来很合理，文件存在、输出匹配、返回码正确，但整个行为已经偏离了任务本意。
这和人类组织里经典的 Goodhart 法则如出一辙：当一个指标变成了目标，它就不再是好指标。模型学会了你在奖励什么，而你的 reward 函数里没有”诚实”这一项。reward hacking 不是修一个 bug 就能解决的事，需要在任务设计和检验设计层面重新思考：你给模型的信号是”通过检查”，就不能责怪它找到最高效的通过方式。问题不在模型，在任务定义。
第六个变量是 benchmark 环境本身。GitHub Issue #2 里有一条非常有信息量的复现反馈：同一位研究者在自己的 Terminus-2 setup 下测得 Qwen 3.6-27B 在 Terminal-Bench 2.0 上跑到 44.94%，Qwen 官方 model card 报告 59.3%，Tmax 论文报告 39.6%。同一个基座模型，三套数字，差距最大的有 20 个百分点。
影响数字的变量能列出一长串：harness 实现方式、sandbox 后端类型和性能、超时设置、推理服务的参数、单节点负载。Tmax 坚持用官方推荐设置做自评，这在保持相对可比性上是合理的选择，但也意味着你在自己环境里跑出来的数字和论文差 10 到 20 个点，不一定是你的问题。截至 2026 年 6 月 23 日，Tmax 还没有提交到官方的 Terminal-Bench leaderboard。
第七个变量是合成数据的上限。TMax-15k 的全部 14,600 个 RL 环境由 Gemini-3-Pro 生成。论文在 Limitations 一节里写了一个关键问题：用强模型生成训练环境，再用 RL 在这套环境里练自己的模型，到底能不能超过生成器本身。这件事没有结论。
在特定任务类型上，通过 RL 的反复试错，模型可以在某个维度超过生成器的单次生成表现，数学推理领域已经证明了这条路。但要在任务分布的广度和定义能力上摆脱生成器画下的边界，这是合成数据路线无法绕开的限制。换句话说，你的训练数据是谁生成的，上限就在谁附近。对没有 Gemini-3-Pro 或同等强模型的团队来说，Tmax 配方的可复制性在数据生成这一步就已经打了折。
Tmax 不是终端 agent 的终局答案。它证明了配方可行，而每一项 caveat 也在说配方还远未成熟。真正值得期待的，是稳定性、数据生成、reward 设计逐一解决之后，小模型 agent 能走到哪里。Tmax 把问题清单和工具都放在了桌上，接下来看谁先动手。