SWE-Together

为什么重要

SWE-Together 代表了代码 Agent 评测从”一次性交卷”向”多轮协作”的范式转移。传统基准（SWE-bench、Terminal-Bench 等）将任务描述一次性交给模型，仅评估最终代码正确性。但在真实编程场景中，用户与 Agent 的交互是动态的——用户逐步澄清意图、提出约束、纠正错误。SWE-Together 首次将这种交互成本量化为”用户修正次数”（U-Corr），回答一个核心问题：Agent 在协作中需要多少次人工纠正才能到达终点？

这一追问的时机恰逢其时：SWE-bench Verified 上 Claude Mythos 5 已达 95.5%，传统静态基准正逼近天花板；OpenAI 已停止报告 SWE-bench Verified 成绩，理由是剩余任务中大量测试用例拒绝功能正确的方案——“交卷打分”范式正在走向疲态。

构建方式

数据来源：从 DataClaw、Pi-staging、Hyperswitch、SWE-chat 四个上游数据集的 11,260 次真实用户-Agent 编程会话中筛选
三阶段筛选流水线：
- 确定性规则过滤：会话含多轮用户消息、Agent 实际代码编辑行为、公开且成熟的仓库
- LLM 可行性判断：判断核心编码目标是否可在本地沙箱中重构
- 沙箱构建：克隆仓库到固定 commit、识别测试命令、生成用户模拟提示词
最终数据：11,260 → 109 任务（0.97% 通过率，反映真实编程会话的嘈杂本质）
用户模拟器：基于 LLM 的响应式模拟器，锚定原始用户意图，仅在 Agent 轨迹触发特定条件时提供反馈——既保留原用户的干预逻辑，又适配不同 Agent 的执行路径

评估指标

pass@1：单次运行成功率
SSR（Stable Solve Rate）：两次运行平均 Judge 分 ≥ 0.85 视为成功
pass²：两次运行同时成功——最严格的一致性指标
Mean Judge：连续 LLM Judge 分数（0-1，不设阈值）
U-Corr（User Correction）：用户修正次数 = N_correction + 0.2 × N_nudge，衡量 Agent 引发的纠正性反馈量

关键发现

Claude Opus 4.8 综合最优：所有正确性指标和 U-Corr 均排名第一（pass@1 63%, U-Corr 1.38）
GPT-5.5 效率第一：Token 消耗 29.9k/task（Opus 4.8 的 40%），运行时间 10.7min/task（Opus 4.8 的 46%），同时能力排名第二
能力与纠正强负相关：U-Corr 与 pass@1 的 Pearson 系数为 -0.92——模型越强，需要的纠正越少
参考基准未达 100%：原始人类补丁的 pass rate 约 78%，约 35% 未满足的目标是”过程要求”（诊断根因、解释变更等），这些是纯代码评测无法捕获的协作维度
OpenAI 已不报 SWE-bench Verified：SWE-Together 的出现恰逢 SWE-bench Verified 饱和争议

关联基准

SWE-bench Pro：静态单次评测标准
SWE-bench Verified：前代标准，已饱和
ChainSWE：链式 Bug 修复评测
SWE-Lancer：真实付费任务

不足与展望

109 题规模有限，接近的名次（如 GPT-5.5 和 Opus 4.6）差距可能在误差范围内
题目来自特定来源的会话，不等于你的语言/框架/代码库场景
用户模拟器的保真度依赖 LLM 能力，与真实用户之间仍有 gap
参考基准 ~78% 的 pass rate 表明仍有约 22% 的真实解决方案无法被基准完美还原

考察能力

构建信息

资源链接

模型效果排行