SWE-2 把少走弯路写进训练目标，便宜不能只看一个榜单

作者：林岚｜OC 开发者生态编辑

据 Cognition 9 月 10 日公告，SWE-2 在 Kimi K3 基础上进行后训练，把任务成功率与执行成本同时纳入优化。厂商报告其 FrontierCode 1.1 Main 成绩为 50.0%，但不同基准的相对表现并不一致。

一句话结论：SWE-2 值得关注的不是“又一个第一”，而是把少读无关代码、减少重复尝试也变成训练目标；是否便宜，最终仍要以你自己的任务验收来结账。

编程 Agent 为什么会贵在“还没动手”

让 Agent 修一个小错误，最让人无奈的场面往往不是它不会改，而是它一直在准备改。目录看了一遍又一遍，同一份文件重复读取，计划越来越完整，代码却迟迟没有变化。

这些步骤不是天然浪费。陌生项目中的依赖、约束和历史行为，确实需要调查。问题在于调查是否改变了下一步决策。如果一个动作不会减少不确定性，它就可能只是把谨慎演成了过程。

Cognition 给出的观察是，新模型可以更早聚焦相关代码。在其 FrontierCode 测试中，medium 档首次实质修改的中位步骤由旧模型的 48 步降到 18 步。这是特定测试下的行为统计，不代表任何项目都应该在第十八步开始写代码。来源：模型公告

工程上值得借鉴的是换一个衡量单位：不是问模型读了多少，而是问每次读取排除了什么可能。快速定位真正相关的文件，比盲目缩短上下文更有价值；后者可能省下输入，却在漏掉约束后付出返工成本。

惩罚成本，不等于奖励草率

公告介绍的训练思路，可以理解为“完成任务的收益，减去执行成本的惩罚”，不同推理档位采用不同权重。

这里有一个容易忽略的陷阱：如果只把成本惩罚调高，模型当然可能更便宜——因为它少做了必要工作，成功率也一起下降。这只是沿着原来的取舍曲线移动，并没有得到更好的工具。

真正有意义的进步，是在差不多的预算下完成更多任务，或者以更低预算达到原来的完成水平。对购买方而言，这比一个脱离费用的最高分更接近实际决策。

可以用一个不涉及厂商数据的例子理解：两个方案每次运行的费用不同，但便宜的方案如果经常需要重试和人工重做，平均每个合格补丁的成本未必低。反过来，昂贵模型如果只是让简单任务多想一会，也未必值得默认用于所有工作。

榜单名字相近，也不能拼成一个结论

SWE-2 的发布表中，Terminal-Bench 2.1 和 Terminal-Bench 4 是不同测试，结果不能跨版本直接比较。公告的评估说明还写明，部分成绩采用公开结果，其他使用相应工具框架测得，并选择各模型的最佳推理档位。

因此，榜单既受到模型能力影响，也受到任务分布、执行框架、预算和工具条件影响。“在一个测试接近某模型”不能扩写成“所有软件工程任务都已追平”。

这并不让测试失去价值。公开方法至少允许读者知道该问什么：是否同一套任务？是否同样允许重试？工具失败算不算失败？收费是否采用同一时期的价格？只有这些条件对齐，性价比数字才有可比性。

给团队的更实用做法：先分任务，再分模型

一个内部验收集不必很大，但应该包含真实差异：有明确错误日志的小修补、跨模块行为变更、旧代码兼容任务，以及需要查清业务语义的问题。

对每类任务同时记录通过率、总费用、等待时间和人工接管原因。某模型如果总在数据库变更上漏掉迁移约束，即便平均分很好，也不适合直接承担这类工作；如果它处理重复性修补非常稳定，就可以在这个范围扩大使用。

还应保留“拒绝自动完成”的空间。模型发现需求互相矛盾并停下来提问，可能比迅速提交一份错误补丁更省钱。验收体系如果只奖励完成数量，会把这种正确的谨慎算成失败。

关键事实

• 发布方：Cognition，SWE-2 为 Kimi K3 衍生后训练模型。
• 方法重点：同时优化任务完成与执行成本，区分推理档位。
• 证据边界：主要为厂商披露，不同基准和框架不能混成统一排名。

OC 判断

编程模型的竞争正在从“能不能解决”进入“能否以合理过程解决”。但减少步骤只有在保留必要验证时才是进步。对开发者最有意义的，不是看着 Agent 忙得更少，而是用更少的总投入得到可信的修改。

为什么重要

• 对开发者：定位质量和验证质量应与代码生成速度一起评估。
• 对企业：按合格任务成本选型，而非只按 token 单价。
• 对用户：更快开始编辑，不自动等于更快交付可用结果。

参考来源

• Cognition：Introducing SWE-2