--- layout: post.njk source: https://yage.ai/share/tmax-terminal-agent-20260623.html speaker: yage.ai title: |- 别只看 42.7%：Tmax 背后的 RL 配方、基座红利和 Benchmark 陷阱 date: '2026-06-24' summary: 文章分析了Tmax模型在开源小模型领域如何通过特定的强化学习配方和基座红利，在终端Agent任务中实现性能突破。核心观点在于，模型表现的提升不仅依赖于绝对分数，更取决于数据集、训练信号设计、评估环境稳定性以及奖励函数对任务定义的精确对齐等多个变量的综合考量。 area: tech-engineering category: ai-application tags: - rl-training - model-scaling - benchmark-trap - agentic-workflow people: [] companies_orgs: [] products_models: - Tmax - GPT-5.5 - Claude - Gemini media_books: [] draft: true status: evergreen --- 做终端 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 前排 终端 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 把问题清单和工具都放在了桌上，接下来看谁先动手。