编程代理基准测试应匹配用户的任务流程
内容提要
JetBrains分析4782个IDE编程代理会话发现，修复缺陷与新增功能的请求不足开发者请求总量的一半，其余为代码解释、规划、审查等。SWE-Bench Pro中93.8%的任务是单一消息的功能或修复请求，与真实使用差距较大。作者提出SWE-TaskFlow，将现有基准的issue拆分为多条顺序请求并加入仓库问答，使任务流更贴近真实会话，但成本增加2至2.6倍，解决率变化不大。
延伸解读
基准测试与真实使用场景的错位
JetBrains分析4782个IDE会话发现，修复缺陷和新增功能仅占开发者请求的45%，其余为代码解释、规划、审查等。而SWE-Bench Pro中93.8%的任务是单一消息的功能或修复请求。这种错位意味着，仅用issue基准评估代理，可能高估其在真实交互中的表现，因为真实任务往往需要多轮澄清和上下文维护。
SWE-TaskFlow的改造思路与代价
SWE-TaskFlow将issue拆分为多条顺序请求，并插入仓库问答，使任务流更贴近真实会话。但拆分后每个任务成本增加2.0至2.6倍，解决率变化不大（部分模型下降4-5点）。这说明渐进披露要求会显著增加代理的交互开销，而最终成功率未必提升，评估时需权衡成本与真实性。
任务流对齐的量化与局限
作者提出TFAS分数，从会话长度、意图分布和转移顺序三个维度衡量基准与目标群体的相似度。优化后TFAS从59.6提升至77.8。但该方法仅覆盖issue请求和仓库问答，规划、审查、执行等意图仍需单独生成和验证，且消息固定无法模拟用户反馈，因此当前版本更适合静态评估而非动态交互。
Q&A
JetBrains 的研究发现开发者实际使用编程代理时，请求类型分布和 SWE-Bench Pro 有什么主要差异？
JetBrains 分析了 4,782 个 IDE 编程代理会话，发现修复缺陷和新增功能请求合计不足开发者请求总量的一半，其余为代码解释、规划、代码审查、重构、命令执行等。而 SWE-Bench Pro 中 93.8% 的任务是功能或修复请求，且每个任务以单条完整消息呈现，与真实使用差距较大。
SWE-TaskFlow 是如何把现有的 issue 基准改造成更贴近真实任务流的？
SWE-TaskFlow 保留原有仓库、环境、测试和需求，仅重新生成用户消息：用 LLM 将每个 issue 拆分为三条有序请求（issue requests），并加入基于仓库的问答（repository questions）。问题需仅从仓库可答、修复前后均有效且不泄露答案，并附带参考答案和可执行证明脚本。最后通过 TaskFlow Alignment Score 选择问题数量和位置，使整体任务流匹配目标用户群体。
使用 SWE-TaskFlow 拆分任务后，代理的成本和解决率有什么变化？
将 issue 拆成三条消息后，每个模型每任务成本增加 2.0–2.6 倍；解决率变化较小：GPT-5.6 Terra 持平，其他三个模型平均下降 4–5 个百分点，与同一设置多次运行的波动相当。加入仓库问答又在拆分基础上增加 4%–24% 的成本，问答准确率在 69.8% 到 83.0% 之间。
为什么说没有一个通用的真实编程代理基准？
因为不同用户群体的任务流差异很大。JetBrains 的生产会话与 SpecStory、DataClaw、SWE-chat 等公开集合在会话长度、意图混合和意图转移顺序上各不相同，且这些集合来自不同产品、用户和收集方法。因此基准应针对特定用户群体进行校准，而不是假设存在通用真实基准。
SWE-TaskFlow 目前还不能覆盖真实任务流中的哪些方面？
目前只生成 issue 请求和仓库问答两类消息，真实会话中的通用编程问题、规划、代码审查、重构、执行、无修复的调试等仍需各自的生成器和验证器，且多数难以自动检查。所有消息在运行前固定，无法模拟用户对代理行为的反馈；分类器缺乏人工标注准确率集，部分 issue 无法拆分，问题难度依赖生成模型，试点每个设置仅三次运行。
SWE-TaskFlow 在拆分 issue 时如何保证不改变原始需求？
LLM 将每个 issue 改写为三条有序请求，要求保留所有原始需求且不添加新需求，标识符和代码片段逐字保留，每条请求在上一请求留下的仓库状态下可执行。第二遍模型检查完整性。在 731 个公开 SWE-Bench Pro issue 中，有 31 个未通过拆分和评估检查而被排除，最终保留 700 个任务。
