论文信息
| 项目 | 内容 |
|---|---|
| 日期 | 2026-10-10 |
| 论文 | SWE-Journey: Towards More Realistic Evaluation of Coding Assistants through Long-Horizon, Multi-Turn Interaction |
| 作者 | Hexuan Deng, Yue Wang, Wenyu Jiang 等 16 人 |
| 机构 | 腾讯 Hy AI Data |
| 链接 | arXiv:2610.11559 |
| 代码 | 暂未开源（基准即将发布） |
一句话总结
SWE-Journey 用「弱到强任务合成 + 人物角色驱动的用户模拟」构建了更贴近真实使用的编码助手评测，发现当前模型在专家用户配合下能解决近八成功能测试，但在非程序员用户下通过率暴跌至 23%——瓶颈不在解题，而在交互。
解决什么问题
Claude Code、Codex 这类编码助手已成 LLM Agent 最大落地场景，但现有基准（SWE-bench 系列、多轮编码基准等）与现实差距明显：任务视角上，真实开发是持续演进仓库中的长链条工作；交互视角上，真实用户不会一次性给出完整需求文档，而是渐进式提出请求、给反馈、改主意。现有基准要么只覆盖长任务但一次性给全需求，要么支持多轮但任务太短、用户模型太粗糙。「长程 + 多轮」联合评测一直是空白。
核心方法
1. 弱到强（weak-to-strong）任务合成管线。 直接让合成模型生成超出自身能力的长任务很难，作者把难度拆解开：
- 规划：用强模型（Claude Opus 4.8）在 Docker 容器里带着 bash 工具探索仓库，生成高层任务蓝图和子任务，并要求在「上下文范围/变更范围/需求深度/知识广度」四个维度中至少两个超过种子任务，避免同质化；
- 子任务实现循环：用相对弱的模型（GLM-5.2）逐个子任务执行「步骤请求生成 → 参考补丁 + F2P 测试生成 → P2P 回归测试生成」三步循环，配合 reset 工具验证补丁生效；
- 渐进扩展：上一轮任务作为下一轮种子，共构建三个递进难度的阶段。
整套管线把单个短任务约 100 美元的人工标注成本压到 56.64 美元/长程任务，且生成的是公开种子之外的新需求，降低答案泄漏风险。
2. 人物角色驱动的用户模拟。 从真实交互日志（SWE-Chat）中挖掘出五个用户维度（专业知识、表达偏好、过程控制、目标演化、验证方式），按编程专业度聚成四类代表性用户：非程序员、产品经理、新开发者、软件架构师。再用 persona 条件化的 LLM Agent 模拟用户，在同一个 Docker 容器里与被测编码助手交替对话，复现「含糊请求—追问—纠错—改需求」的真实交互。
3. 在线评测协议。 区别于离线打分，测试在交互过程中（process）和会话结束（final）两个时点在线执行，指标包括 Proc. F2P、Final F2P、Final P2P，另统计轮数和每会话成本。
实验结果
- 13 个模型全部 Proc. F2P 低于 50%，最高 Final F2P 仅 52.22%——真实交互条件下远未达标；
- 分用户差距惊人：软件架构师配合下平均 Final F2P 78.50%（Claude-Opus-5 高达 93.59%），非程序员下平均仅 23.00%，同一批任务差 55.5 个百分点；
- 单次给全需求的 single-shot 设定结果落在架构师与其他三类用户之间，说明交互既可能提升也可能摧毁性能——专家操作能「榨出」模型的解题能力；
- 强模型 Final P2P 超过 90%（不破坏已有功能），弱模型低于 80%；Final F2P 平均比 Proc. F2P 高 3.53 个百分点，说明模型有一定事后纠错能力但远不够；
- 失败模式分析归纳出三项关键交互能力：问对（Asking Right，澄清含糊需求）、找对（Finding Right，定位要改的代码）、改对（Fixing Right，正确实现）。多数模型主动追问少于 20% 的轮次，而 Hy4-Preview 和 Claude-Opus-5 频繁且有针对性的追问正是它们拿到高通过率的原因之一。
深层洞察
这篇论文最锋利的发现是：编码助手的瓶颈正在从「解题能力」转向「交互能力」。同一个模型、同一批任务，换个用户类型通过率就从 78.5% 掉到 23%——模型本身会做题，但面对含糊、摇摆、不懂代码的用户就崩了。这直接戳破了「编程民主化」的叙事：目前最受益的恰恰是最不需要它的专家用户。对基准设计而言，「用户建模」和「任务构造」同等重要，把用户当作评测的一等公民，是这类工作方法论的真正贡献。
局限性
- 用户 persona 是从特定交互日志挖掘的四个代表配置，不还原真实人群分布，结论是对「协作条件」的比较而非单变量归因；
- 合成任务的质量仍依赖合成模型上限，30 个案例的规模偏小；
- 用户模拟器本身由 LLM 扮演，模拟偏差（如追问过多/过少）会传导到被测模型的成绩；
- 评测依赖执行测试判定，对测试覆盖不到的隐性需求（代码风格、可维护性）无能为力。
工程实践启示
- 做 Agent 产品，先测「最难伺候的用户」：内部 benchmark 用理想 prompt 测出的能力，到真实小白用户手里可能打三折，评测集里应有 persona 分层；
- 追问是硬能力：遇到含糊需求先澄清再动手的模型显著更强，Agent 设计中应把「提问预算」「澄清门槛」做成显式策略，而不是默认闷头执行；
- 长程任务要测 P2P 回归：改得对但改坏了旧功能在长会话中高频出现，CI 式回归测试应内建到 Agent 工作流；
- 弱到强合成是低成本造评测集的范式：强模型规划 + 弱模型执行 + 执行验证把关，比纯人工标注便宜近一半且可扩展，值得数据团队借鉴。