SWE-2 发布：Kimi K3 基座加 RL 后训练，距离 Fable 5.1 只差 0.9 分

预计阅读时间：9 分钟

Cognition 发布了 SWE-2，一个以 Kimi K3 为基座、通过强化学习后训练得到的编码 Agent 模型。它在 Cognition 自家维护的 FrontierCode 1.1 Main 上取得 50.0%，与 Fable 5.1 的 50.9% 只差 0.9 个百分点，同时超过 GPT-5.6 Sol 的 47.5%。更值得关注的是，SWE-2 的价格比 Fable 5.1 低 64%，这让编码 Agent 的模型选择开始从“谁的榜单最高”转向“效果、成本和任务稳定性如何组合”。

关键变化：基座模型不是全部

SWE-2 的路线可以概括为：使用 Kimi K3 作为大规模基座，再针对编码 Agent 场景进行 RL 后训练。这里的重点不只是参数规模，而是后训练目标是否能让模型更稳定地完成真实软件工程任务。

编码 Agent 与普通代码补全模型的工作方式不同。它通常需要阅读仓库、定位问题、修改多个文件、运行测试，再根据失败信息继续迭代。模型在单轮生成代码时表现不错，并不意味着它能在完整任务链路中可靠交付补丁。因此，RL 后训练的价值可能体现在任务分解、工具调用、失败恢复和测试驱动迭代等环节。

不过，50.0% 的成绩仍然应被理解为特定评测条件下的结果。FrontierCode 1.1 Main 是 Cognition 自家维护的 SWE-bench 升级版，和其他公开基准之间不能简单横向换算。实际选型时，还需要确认任务集合、执行环境、工具权限、超时设置和评分规则是否一致。

50.0% 与 50.9% 的差距意味着什么

从数字看，SWE-2 距离 Fable 5.1 只有不到一个百分点，说明两者在该评测上的总体能力已经接近。这个差距不足以单独决定生产环境的选型，因为平均分可能掩盖几类关键差异：

模型是否擅长定位跨文件问题。
修改后是否更愿意主动运行测试。
遇到测试失败时，是否能区分代码错误、环境错误和测试本身的问题。
在长上下文仓库中，成本和延迟是否可接受。
同一个任务重复运行时，结果是否稳定。

成本差异则更加直接。摘要显示，SWE-2 的价格比 Fable 5.1 低 64%。对于每天运行大量 issue 修复、代码审查或自动化迁移任务的团队，价格优势可以转化为更高的重试预算、更长的上下文窗口，或者更低的单任务成本。但如果低价模型需要更多轮工具调用或人工接管，端到端成本仍然可能上升。

一个实用的判断公式是：

单任务总成本 = 模型调用成本 + 工具执行成本 + 重试成本 + 人工接管成本

因此，不要只比较每百万 Token 的价格。应当用同一批真实任务测量“成功交付一个可合并补丁”需要多少 Token、多少轮工具调用和多少人工时间。

可以这样接入和评估

下面的示例假设 SWE-2 提供 OpenAI 兼容的 HTTP 接口，接口地址、模型标识和鉴权方式需要按实际服务调整。它适合快速验证模型在一个具体编码任务上的行为，不代表 Cognition 已公布了完全相同的 API 形式。

先设置环境变量：

export SWE2_BASE_URL="https://api.example.com/v1"
export SWE2_API_KEY="replace-with-your-api-key"
export SWE2_MODEL="swe-2"

发送一个带有仓库约束的编码任务：

curl -sS "$SWE2_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $SWE2_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<JSON
{
  "model": "$SWE2_MODEL",
  "temperature": 0.2,
  "messages": [
    {
      "role": "system",
      "content": "You are a coding agent. Inspect the repository, make the smallest correct change, run relevant tests, and report the files changed and test results."
    },
    {
      "role": "user",
      "content": "Fix issue #123 in the checked-out repository. Do not change public APIs unless the issue requires it. Before finishing, run the narrowest relevant test command and explain any remaining failure."
    }
  ]
}
JSON

要把一次请求变成可比较的评测，建议固定以下条件：

使用相同的仓库提交版本和初始工作区。
给每个模型相同的工具集合、网络权限和超时时间。
记录输入 Token、输出 Token、工具调用轮数、总耗时和最终测试结果。
把“测试通过但修改范围过大”单独标记，而不是只统计退出码。
对关键任务重复运行多次，观察成功率和方差。

可以用一个简单的 shell 记录器包住调用命令：

#!/usr/bin/env bash
set -Eeuo pipefail

: "${SWE2_BASE_URL:?set SWE2_BASE_URL}"
: "${SWE2_API_KEY:?set SWE2_API_KEY}"
: "${SWE2_MODEL:?set SWE2_MODEL}"

started_at=$(date +%s)
response=$(curl -fsS "$SWE2_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $SWE2_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$SWE2_MODEL"'",
    "temperature": 0.2,
    "messages": [{
      "role": "user",
      "content": "Inspect the repository and fix the assigned issue. Run relevant tests before you finish."
    }]
  }')
finished_at=$(date +%s)

printf '%s\n' "$response" > "swe2-response-${started_at}.json"
printf 'model=%s elapsed_seconds=%s output_file=%s\n' \
  "$SWE2_MODEL" "$((finished_at - started_at))" \
  "swe2-response-${started_at}.json"

生产环境还需要加上仓库沙箱、命令白名单、补丁大小限制和密钥隔离。编码 Agent 能够执行命令时，模型输出就不再只是文本，任何文件修改和命令执行都应当纳入审计。

采用建议

SWE-2 的信号很清晰：通过针对软件工程流程的 RL 后训练，后发模型也可以在专门的编码 Agent 评测上逼近领先结果；64% 的价格差则使它具备实际部署吸引力。

但是否替换现有模型，不能只看 50.0% 和 50.9% 的榜单差距。建议按下面的顺序落地：

先挑选团队过去一个月中具有代表性的 issue、回归修复和重构任务。
用相同工具链对 SWE-2、当前生产模型和一个高性能基线做盲测。
以可合并补丁率、人工接管率、每个成功任务成本和平均延迟作为核心指标。
对高风险仓库保留人工审批，对低风险、测试覆盖充分的任务逐步扩大自动化范围。

SWE-2 更适合被看作一个新的成本性能点，而不是单凭一次基准成绩就能证明全面领先的模型。真正值得关注的，是它在你的代码库、测试体系和 Agent 工作流中，能否用更少的成本稳定交付可验证的修改。

SWE-2 发布：Kimi K3 基座加 RL 后训练，距离 Fable 5.1 只差 0.9 分

关键变化：基座模型不是全部

50.0% 与 50.9% 的差距意味着什么

可以这样接入和评估

采用建议

相关推荐

建议反馈