Cognition SWE-2 推进编码 Agent 帕累托前沿：前沿级分数，成本低 64%

2026 年 9 月 10 日，Cognition 发布 SWE-2，并把它定位为「推进帕累托前沿」——不再只是刷分，而是让能力与成本的整条曲线一起前移。官方数字很直接：在 FrontierCode 1.1 Main 上拿到 50.0%，距 Claude Fable 5.1 仅差 1 分，而成本低 64%。对每天为 Agent 账单头疼的团队来说，真正的看点不是那 1 分之差，而是「同样接近前沿，价格却只要一小部分」，以及它为整个行业定下的新性价比基准。

1. SWE-2 到底发布了什么

SWE-2 是 Cognition 迄今最先进的编码模型。官方称它首次把强化学习扩展到数万亿参数规模，建立在 SWE-1.7 的训练基础设施与配方之上。关键新增是一个能在「单次训练」中同时训练所有推理档位（effort level）的 RL 算法，因此整条成本-性能前沿会一起前移，而不是一次只优化一个点。它在 FrontierCode 1.1 Main 与 DeepSWE 1.1 上同时击败 SWE-1.7 和 Grok 4.6（分数与成本双赢），在价格的一小部分上追平 GPT-5.6 Sol 与 Fable 5/5.1，并在四分之一的成本下逼近 GPT-6 Astra 几个点的差距。SWE-2 已在 Devin Desktop 与 CLI 上线，随后铺开到 Devin Web 与 Fusion。

# Route each task to the cheapest effort level that clears the bar.
EFFORT_COST = {"low": 0.4, "medium": 1.0, "high": 2.3, "xhigh": 4.8}

def pick_effort(task, success_curve):
    for level in ("low", "medium", "high", "xhigh"):
        if success_curve[level] >= task["min_pass_rate"]:
            return level, EFFORT_COST[level]
    return "xhigh", EFFORT_COST["xhigh"]

task = {"min_pass_rate": 0.80}
curve = {"low": 0.42, "medium": 0.81, "high": 0.93, "xhigh": 0.96}
print(pick_effort(task, curve))   # ('medium', 1.0)

2. 成本惩罚：把「花钱」直接写进训练目标

SWE-2 最有意思的技术细节，是它如何把成本变成训练信号。团队对每个 effort 档位施加一个「线性成本惩罚」，且每个惩罚都按基础模型帕累托前沿的局部斜率来调校。这样做的目的是：在推进整条前沿的同时保持它的形状，并让训练中反映的成本尽可能贴近用户的真实成本。换句话说，模型不只是在「答对」上被奖励，还在「用更少的钱答对」上被奖励。配合自 SWE-1.6 起使用的「长度加权奖励基线」来稳定训练，这套组合让 RL 在多参数规模下依然可控。这正是 2026 年 Agent RL 的主流思路：把业务成本直接变成梯度的一部分。

# Compare models on cost per RESOLVED task, not cost per token.
def cost_per_resolved(score, avg_cost):
    if score <= 0:
        return float("inf")
    return avg_cost / score

models = {
    "swe-2-medium": {"score": 0.50, "avg_cost": 0.36},
    "fable-5.1":    {"score": 0.51, "avg_cost": 1.00},
}
for name, m in models.items():
    print(name, round(cost_per_resolved(m["score"], m["avg_cost"]), 3))

3. 从 Kimi K3 后训练：开源权重再加一轮 RL 仍有空间

SWE-2 是从 Kimi K3 后训练而来——一个 2.8 万亿参数、已经针对 Agentic 编码做过大量 RL 的模型。Cognition 表示，即便基础模型已经过强化，他们的 RL 仍能找到可观空间：在许多基准上再加 5 到 6 分，并整体移动了 K3 的成本-性能前沿。为了支撑这种规模，团队改进了 RL rollout 的服务调度，训练了一个在线草稿模型来提升解码吞吐，并用 NVFP4/FP8 内核与量化感知训练降低内存占用，使得基础模型参数量差不多是 SWE-1.7 的三倍，却在相近吞吐下取得更低的训练-推理不匹配。训练数据上，他们把 RL 环境数量扩大到三倍，加入指令遵循叠加（instruction-following overlays），并用 SWE-2 的历史 checkpoint 构建飞轮来持续加固验证器。

# Cap agent turns; SWE-2 medium reaches its first real edit at ~18 steps,
# versus a median of 48 steps for SWE-1.7 on the same benchmark.
def run_with_budget(agent, task, max_turns=25):
    for turn in range(1, max_turns + 1):
        step = agent.next(task)
        if step["type"] == "edit":
            return {"status": "edited", "turn": turn, "patch": step["patch"]}
    return {"status": "budget_exceeded", "turn": max_turns}

4. 行为差异：更聪明的「少走弯路」

SWE-2 的效率提升和智能提升是连在一起的。更强的工程判断力意味着它能写出更完整的方案，同时少走弯路、少做冗余读取。官方观察到的行为模式有三点值得注意：一是测试覆盖更好，能写出端到端检查实现的测试，更可靠地抓住回归与边界情况；二是「在边界内足智多谋」，当显而易见的路径被堵住时，它更愿意寻找另一条通往同一答案的路——例如某个 MCP 集成不可用时，它直接从已有的 Slack 频道历史中重建了所需数据；三是「验证纪律」，被质疑时它会重新推导结论而不是重复断言，会去验证用户假设、运行产物来取证。这些特性直接决定了它的输出能不能被信任。

5. 效率账：轮次少 58%、成本低 81%

最该被编码团队记住的数字来自 FrontierCode 1.1 Main：SWE-2 的 medium 档位比 SWE-1.7 分数更高，同时平均少用 58% 的轮次、成本低 81%。具体到行为上，SWE-2 medium 在 median 18 步就做出第一次真正的编辑，而 SWE-1.7 需要 48 步。团队指出，最大的效率增益来自「聚焦探索」——更高的智能让模型能判断代码库里哪部分对任务真正重要，于是能更早进入实现阶段。同时不同档位的行为差异是真实存在的：medium 会更快采取行动，这对简单任务尤其划算。这意味着「按任务难度选档位」不再只是省钱技巧，而是质量与延迟的调节旋钮。

# Require re-derivation, not agreement, before accepting a claim.
def verification_gate(claim, evidence):
    required = ["ran_artifact", "reproduced_bug", "checked_edge_cases"]
    missing = [r for r in required if not evidence.get(r)]
    return {"claim": claim, "accept": not missing, "missing": missing}

ev = {"ran_artifact": True, "reproduced_bug": True, "checked_edge_cases": False}
print(verification_gate("fix resolves the regression", ev))

6. 落地建议：把新前沿写进你的路由策略

面对又一个「更便宜且更接近前沿」的模型，正确的动作不是无脑切换，而是更新路由与评测。建议三步：第一，把「每个已解决任务的成本」而不是「每 token 成本」作为主指标，否则你永远看不清真实性价比；第二，为不同任务难度建立档位路由与轮次预算，让 medium 处理大多数 PR 级任务、高难重构才升档；第三，用你自己的仓库和历史任务做回归评测后再切流，因为官方基准和你代码库的语言、框架、测试密度都不同。评测脚手架要经得起推敲：用差异对比工具核对 Agent 补丁、用 JSON 格式化工具校验运行报告、用 API 测试工具检查评测服务的请求。把「便宜」真正变成你的纵深防御，而不是又一次月底账单惊吓。

# Quantify the efficiency win from fewer turns and cheaper effort.
def savings(old, new):
    turn_cut = 1 - new["turns"] / old["turns"]
    cost_cut = 1 - new["cost"] / old["cost"]
    return {"fewer_turns_pct": round(turn_cut * 100),
            "cheaper_pct": round(cost_cut * 100)}

old = {"turns": 100, "cost": 1.00}
new = {"turns": 42,  "cost": 0.19}
print(savings(old, new))   # 58% fewer turns, 81% cheaper