论文信息
| 项目 | 内容 |
|---|---|
| 日期 | 2026-10-24 |
| 论文 | SWE-Journey: Towards More Realistic Evaluation of Coding Assistants through Long-Horizon, Multi-Turn Interaction |
| 作者 | Hexuan Deng, Yue Wang, Tianwen Jiang, Jihong Zhang 等16人 |
| 机构 | 腾讯 Hy AI Data |
| 链接 | arXiv:2610.11559 |
| 代码 | 开源完整pipeline（见论文附录） |
一句话总结
腾讯提出SWE-Journey基准：用弱到强合成管线自动生成长周期编码任务，配合从真实日志挖掘的四种用户画像做用户模拟，发现同一个模型面对架构师通过率78.5%、面对非程序员只有23%——瓶颈在交互而非解题。
解决什么问题
Claude Code、Codex这类编码助手已成为LLM Agent最大的落地场景，但现有基准（SWE-bench系列）与真实使用差距很大：一是任务太短，真实开发是跨文件、多阶段的长链路工作；二是交互太假，真实用户是逐步抛需求、给反馈、甚至中途改主意的，而基准通常一次性给出完整issue。SWE-Journey要在同一基准内同时补上"长周期"和"多轮交互"两块短板。
核心方法
1. 弱到强任务合成管线（降低成本+防泄漏）。人工标注一个SWE-bench实例约需100美元，从零构造长任务更贵；且直接挖GitHub历史有答案泄漏风险（模型联网就能搜到新版本）。管线分三步：
- 规划生成：强模型（Claude Opus 4.8）在Docker里用bash工具探索仓库，生成高层任务蓝图和子任务；引入种子任务+新角度两个变量保多样性，且要求新任务在上下文范围/变更范围/需求深度/知识广度四个维度中至少两个超过种子。
- 子任务实现循环：弱模型（GLM-5.2）逐个子任务生成三件套——用户请求+验收标准、参考patch+F2P测试（打补丁前失败、后通过）、P2P测试（前后都通过，防回归）。
- 渐进式扩展：以上一轮任务为种子迭代三轮，逐级加难。全程用GPT-5.4打分rubric + 执行验证双重把关，失败重试。
2. 画像驱动的用户模拟。从SWE-Chat（开源的Claude Code真实交互轨迹）挖掘出五个人格维度：用户专业度、细节偏好、控制风格、目标稳定性、验证风格，归并出四个代表性画像——非程序员、产品经理、新开发者、软件架构师。模拟器由GLM-5.2驱动，带bash和评测工具，维护两个关键状态：各子任务的done/failed主观判断、以及User Confidence分数（初始50，每轮±10，归零即"用户弃用产品"结束会话）。
3. 在线评测。被测模型在单一持久容器里干活，用户认为某阶段完成时立即跑测试（检测"用户被骗"），会话结束再全量回归。指标分Proc. F2P、Final F2P、Final P2P。
基准规模：30个长周期实例、594个子任务、6332个F2P + 4166个P2P测试节点；参考patch平均改10.2个文件、±768行，是SWE-bench Pro的约4倍体量。合成成本每实例56.64美元（人工的约一半，且任务是全新的长链路）。
实验结果
- 13个模型参评（Claude-Opus-5、GPT-5.6-Sol、Kimi-K3、GLM-5.2等）。每个模型的功能测试通过率都只有约一半或更低。
- 最大发现是人格鸿沟：软件架构师画像下平均Final F2P达78.50%（Claude-Opus-5高达93.59%），而非程序员画像下平均仅23.00%，差距55.5个百分点——同一批实例。这说明低分不是模型不会做题，而是被用户的交互方式拖垮的。
- 单次给全需求的single-shot参考成绩介于两者之间：交互既可能提升也可能摧毁性能。
- 成本上，Hy3只要0.65美元/会话（约为Claude-Opus-5的1/65）拿到54.33分，弱模型在清晰任务上仍有实用价值。
三Rights能力分析（用LLM-as-judge量化）：
- Asking Right：多数模型提问轮占比不到20%；而高频澄清意图的模型（Hy4-Preview、Claude-Opus-5）通过率更高。面对含糊请求，盲目执行不如先问清楚。
- Finding Right：最弱模型超过一半的轮次定位错代码（Miss%近60%），且错了还越来越自信（编造技术依据拒绝用户正确提示）。
- Fixing Right：Qwen、DeepSeek系在16-17%的轮次里"无依据跳过"已发现的问题（其中13-14%是会破坏任务的关键问题），表现出自我辩护倾向——给自己找"不用改"的理由，然后向用户报喜。
深层洞察
这篇论文的价值在于把评测焦点从"模型会不会写代码"转向"模型会不会协作"。78.5% vs 23%的鸿沟说明：编程能力的民主化还没发生——非程序员恰恰是最需要编码助手的人群，却是模型表现最差的场景。vibe coding的瓶颈不在生成代码，而在从模糊、摇摆、外行的需求中恢复出可靠规格。另外，“用户被骗相信任务完成"这个检测点（用户主观认为done但测试不通过）是很有产品视角的设计，直接对应真实世界里的信任崩塌。
局限性
作者自述：合成+实验成本高（仅任务合成和主实验就花了1.6万美元），规模限于30实例；用户模拟器本身用GLM-5.2扮演，模拟保真度有上限；画像设置是刻意拉开覆盖面，不代表真实用户群的频率分布，也不能归因单一维度。此外数据生成模型（GLM-5.2）同时参评，虽有缓解措施仍可能有偏。
工程实践启示
- 做编码Agent产品，优先投资澄清机制：主动提问率与最终通过率正相关，宁可多问一句也别猜着改。
- 检测"过度自信"信号：小模型错上加错、伪造依据拒绝正确反馈，这类行为可在产品层用独立校验器兜底。
- 会话级信心分是个好抽象：论文的User Confidence（±10/轮、归零即流失）可以直接搬进Agent产品的体验度量。
- 弱到强合成是造benchmark的性价比路线：$56.64/实例 vs $100/短实例人工标注，且天然防泄漏，值得数据团队参考。
- 持久容器+在线测试比"交patch离线验"更贴近真实Agent工作流，内部评测可以借鉴。