Coding-Agent Benchmarks Should Match Their Users’ Task Flows

编码代理基准测试应与用户任务流程匹配 - JetBrains 博客

JetBrains 研究

研究对于进步和创新至关重要，这也是为什么 JetBrains 对科学和市场研究都充满热情。

关于 JetBrains 研究

研究

编码代理基准测试应与用户任务流程匹配

Igor Slinko

左图：SWE-Bench Pro，每个任务对应一个用户消息，几乎总是新功能或错误修复。右图：JetBrains IDE 中软件工程师工作会话的前五条开发者消息（仅统计至少包含三条消息的会话）。每个列代表消息位置，彩色方块表示请求类型，带宽显示某种类型请求后跟随另一种类型的频率。

本文总结了我们的论文《观点：编码代理基准测试应与用户任务流程匹配》，该论文已被 NeurIPS 2026 交互代理评估研讨会接受。

在 JetBrains 研究中，我们最近分析了 4,782 次 JetBrains IDE 中软件工程师的代理会话，并将其与三个公开的代理对话集合进行了比较。在我们观察到的开发者会话中，修复错误和添加功能仅占开发者向编码代理提出请求的不到一半。其余请求包括关于代码库的提问、规划、代码审查、重构和命令执行。而在 SWE-Bench Pro 中，93.8% 的任务是功能添加和错误修复，每个任务都以一条完整消息的形式出现。这种差异非常明显。

本文将探讨这一差距。我们的分析结论是：不存在通用的现实编码代理基准测试：基准测试应根据特定用户群体的测量数据进行校准。SWE-TaskFlow 是我们为此提出的解决方案，可以用于任何基于问题的基准测试；在本文中，我们将它应用于 SWE-Bench Pro。

基于问题的基准测试衡量什么

SWE-bench 及其后续版本（SWE-Bench Pro、SWE-rebench、DeepSWE）从 GitHub 问题中构建任务。代理会收到仓库的代码库和问题描述，探索代码、修改代码并提交补丁。测试决定补丁是否解决了问题；解决的问题占比即为解决率。

这些任务的基础设施构建成本很高：需要正确的提交版本的仓库、代码运行环境以及验证更改的测试。然而，其上的交互层是固定的。完整的任务描述以一条精心打磨的消息形式一次性提供，最终补丁会被评分。

尽管交互层是固定的，但开发者在 IDE 中的交互方式并不总是如此。我们观察到的会话中，有一半仅包含一条消息。在其余会话中，需求是分阶段提出的：在一次修改请求和下一次请求之间，开发者可能会要求代理解释项目某部分的工作原理、规划下一次修改或审查已完成的工作，而早期的需求仍需持续跟进。

50.9%的会话只包含单条消息；约15%的会话消息数超过五条。由于我们的研究对象是交互式智能体，其余分析将聚焦于包含至少三条开发者消息的33%长会话，具体如下。

一个开源权重的LLM（Gemma 4-31B）将每条消息标注为16种请求类型（意图）之一：错误修复、新功能开发、解释说明、规划、代码审查、执行等（所有16种类型详见论文）。使用相同分类器和提示词对公开数据集和SWE-Bench Pro问题进行标注，因此本文所有分布数据均基于统一标准。

所有会话中，标注消息中26%属于错误修复，19%属于新功能开发。在长会话中，项目自身代码的解释占6%，通用编程问题占10%；规划、代码审查、重构、调试和执行占剩余大部分。采用相同标注方式的SWE-Bench Pro数据中，55%为新功能开发，39%为错误修复，6%为重构，无其他类型。

会话长度和意图组合是任务流程（Task Flow）的三个组成部分中的两个，第三个是意图之间的顺序关系。以功能请求开头的会话通常会继续询问现有行为、进行规划，然后提出审查请求。

公共数据集对比

我们的生产会话数据来自特定用户群体。为观察结果对人群的依赖程度，我们对下方每个公开数据集的1000个会话运行分类器并保留长会话。下文为每个数据集的桑基图，本文的桑基图即任务流程图，每列代表消息位置，列间色带表示转换关系。

SpecStory包含公开的IDE会话导出数据，即《Programming by Chat》分析的数据。其1000个会话中有521个为长会话。三个数据集中，它与我们的会话最接近，规划占比更高。

DataClaw收集了社区共享的编码代理会话。其1000个会话中有585个为长会话。该数据集以执行请求和简短操作消息为主。

SWE-chat是真实用户在聊天场景中的编码代理对话集合。其1000个会话中有698个为长会话。执行和规划是其主要意图。

这三个语料库来自不同产品、不同用户群体和不同采集方式，因此我们不进行定量对比。但基准测试若针对其中任何一个进行校准，其任务组合和转换关系将与针对其他语料库校准的基准不同。这些数据集都不是绝对真相，我们的生产会话数据也是如此，目标需要明确选择并声明。

在我们的试点中，目标是长生产会话。按频率校准会产生副作用：目标中罕见的行为会被压缩至零。像破坏性shell命令或安全相关的审查这类重要但罕见行为，应通过独立的压力测试切片进行评估，每个切片有独立的任务计数。

SWE-TaskFlow如何适配现有任务

为每个目标构建新的交互式基准将浪费现有基于问题的基准已有的成果。因此我们提出SWE-TaskFlow，它通过转换现有基准实现适配：保留仓库、环境、测试和原始需求，仅重新生成用户消息。

LLM 将每个问题重写为三个有序请求；我们称它们为“问题请求”，因为其中的所有内容都源自原始问题。代理在看到第二个请求之前先处理第一个请求。拆分必须保留所有原始需求且不添加任何内容；标识符和代码片段保持原样；每个请求都必须在前一个请求留下的仓库状态中可操作。第二个模型遍历检查结果的完整性。731 个公开的 SWE-Bench Pro 问题中有 31 个未通过这些拆分和评估检查，因此被排除在外，剩下 700 个任务。

以下是一个标题为“LinkedIn 因旧版 QtWebEngine 缺少 Array.prototype.at 支持而失败”的 qutebrowser 问题的示例。原始问题是一条约 1000 字符的消息。拆分后，它变为：

• 请修复 qutebrowser 在 macOS 上使用 QtWebEngine 5.15.2 时的 LinkedIn 兼容性问题。LinkedIn 的前端 JavaScript 使用了 Array.prototype.at，但该方法在旧版引擎中缺失，导致 JavaScript 执行失败，LinkedIn 页面卡住或无响应。请添加必要的 qutebrowser JavaScript 兼容性支持，使 LinkedIn 能正常加载和运行，并通过 polyfill 透明地解决此问题。

• 兼容性支持应在 QtWebEngine 6.3 之前版本中提供 Array.prototype.at 方法（当该方法原生不可用时），并且必须在 LinkedIn 域名页面和 qutebrowser 测试域中处于活动且可用状态。对于数组实例，正整数索引应返回指定位置的元素，负索引则从末尾倒数，-1 指向最后一个元素。

• 完善行为，使超出数组边界的索引（无论是正数还是负数）都返回 undefined。polyfill 仅在 JavaScript 环境中原生 Array.prototype.at 方法不可用时注入。

第一个请求已足够开始工作；边缘情况会在后续出现。

添加关于仓库的问题

生产会话中常见对项目自身代码的解释，而问题基准中则没有这些内容，因此我们生成了这些问题。模型会与之前解决该问题的代理轨迹一起阅读仓库，并提出一到三个问题。每个问题必须仅从仓库中回答，修复前后都有效，并且不能泄露解决方案。

每个问题都附带参考答案和一个可执行的证明脚本，该脚本从仓库中收集答案的证据。在数据集创建时，我们会在干净的仓库克隆中运行该脚本，仅保留通过检查、生成证据且不修改仓库的提问。这通过构造排除了答案无法在代码中观察到的问题（例如“为什么这样设计？”）。在评估时，代理以文本形式回答问题，另一个独立的 LLM 将其答案与隐藏的参考答案及其证据进行对比。

在发布的配置中，上述 qutebrowser 任务会获得一个问题，放置在第一个和第二个问题请求之间：

简洁答案：追踪相关样式表配置更改如何同时更新未来 QtWebEngine 文档和已加载文档，包括 CSS 组装、脚本替换、执行环境、子框架行为以及与无关选项的无操作路径。

参考答案列出了触发此路径的两个配置选项，并逐步讲解了五个文件。证明脚本对真实代码执行样式表配置更改，检查生成的脚本注册和对实时页面的调用，并确认无关选项不会产生任何影响。该问题与Array.prototype.at无关：它来源于求解代理在阅读过程中看到的代码，而非修复本身。

选择与目标匹配的序列

问题可以出现在问题请求之前、之间或之后，因此每个任务都有多个候选序列。我们为每个任务选择一个序列，使整个基准测试与长期生产会话相似，通过任务流程对齐分数（TaskFlow Alignment Score, TFAS）进行衡量。TFAS通过Jensen-Shannon散度比较目标与基准测试之间的三个分布（会话长度、意图、转换），并将其合并为0-100的分数。纯拆分方式对目标得分为59.6。在固定位置添加问题可将其提升至75.6-77.1；让优化器选择每个任务保留的问题数量及位置可进一步提升至77.8。结果是255个700个任务中有454个问题（113个任务含一个问题，85个含两个，57个含三个），其中67个任务仅在问题请求前放置问题，86个仅在之后放置，102个任务交错放置。其余445个任务保留了原有的三个问题请求。

SWE-Bench Pro的任务流程（左）与TFAS优化选择（右，TFAS 77.8）对比。每个问题转化为最多六个不同类型的连续提示。仓库、请求的更改和最终测试保持不变。

在右侧面板中，问题请求携带了任务类型，这些类型已存在于问题中：错误修复、新功能和部分重构，与左侧SWE-Bench Pro包含的全部三种类型（错误修复、新功能和重构）一致。当问题拆分后，较小的意图也会出现：调试、转换、测试、规划和一些其他类型。这些并非新增内容，而是原始问题中被分类器合并到主导意图中的部分（例如，一个同时要求回归测试的错误修复问题），在拆分后以独立消息形式显现。唯一来自问题之外的意图是"解释"，由仓库问题携带。

试点结果：四个模型，三种设置

为评估SWE-TaskFlow，我们通过mini-swe-agent在相同700个任务上运行了GPT-5.6 Luna、GPT-5.6 Terra、GPT-5.4 Mini和Gemini 3.7 Flash，每种设置进行三次运行：

• 单次：原始问题以单条消息呈现。
• 拆分：三个请求按顺序在单次对话中依次发送。
• 拆分+问答：TFAS选择的序列，包含仓库问题。

三次运行的平均值；须状线表示观察到的最小-最大值。颜色代表模型，形状代表设置。

将问题拆分为三条消息使每个模型每任务成本增加2.0-2.6倍。由于仓库、测试和需求未发生变化，额外成本衡量了需求分段到达时代理需要付出的额外努力。解决率变化较小：GPT-5.6 Terra保持稳定，其他三个模型平均下降4-5分，这与相同设置下单次运行之间的差异相当。每种设置进行三次运行后，这些结果并未对模型进行排名，但表明逐步披露可靠地改变了工作量，仅对结果产生微弱影响。

LLM重写本身，而非任务顺序，也可能使任务难度增加。对照条件Concat将三个重写部分粘贴到一条消息中。对于三个GPT模型，每个模型运行一次后，其成本和解决率与Single相近，因此Split的额外成本来自顺序交付，而非重写操作。

添加仓库问题会使成本在Split基础上再增加4%–24%，具体取决于模型。在包含问题的255个任务中，评委标记为正确的答案占比（答案准确率）从69.8%（GPT-5.4 Mini）到83.0%（GPT-5.6 Terra）不等。

实心圆圈：答案准确率。空心圆圈：在相同255个任务中的解决率，因此这些解决率数值与上方图表存在差异。

拆分轨迹也允许中间验证。每次提出问题请求后，我们可以对仓库进行快照并重新运行测试，仅针对目前已揭示的需求进行评分。在64个任务的消融实验中，随着每次问题轮次推进，解决率和测试通过率均呈增长趋势，问题位置不会改变曲线形态。每个任务会产生多个验证检查点，而非单一最终评分。这对诊断和潜在的训练都有价值；我们尚未尝试后者。

SWE-TaskFlow尚未覆盖的领域

目前SWE-TaskFlow仅生成两类消息：问题请求和仓库问题。真实会话中的任务流（通用编程问题、规划、代码审查、超出问题范围的重构、执行、无修复的调试）仍需各自独立的生成器和验证器，而大部分内容尚不清楚如何自动验证响应。已测量的任务流至少能告诉我们缺失哪些增强功能及其比例。

所有消息在运行前均为固定内容。这确保了精确的可重放性和配对比较，可衡量渐进披露、记忆和适应能力，但无法体现代理如何处理反馈："用户"无法对代理的操作做出反应。带有模拟用户的反应型基准测试可通过轨迹方差实现该功能；完整的评估套件应结合校准的静态核心与针对性的反应切片。除此之外，分类器没有人工标注的准确率数据集；某些问题无法拆分，问题难度取决于编写它们的模型，试点测试每个配置仅进行三次运行。

亲自尝试

Hugging Face上的SWE-TaskFlow-SWE-Bench-Pro数据集包含12个配置作为独立分割：原始提示、拆分提示、Split+QA变体以及仅包含QA的会话。每个问题均附带参考答案和证明脚本。仓库、黄金补丁和测试均保留于原始SWE-Bench Pro发布版本中。

基准测试

任务流程

• 分享

• Facebook

• Twitter

• LinkedIn

上一篇

开发者对AI的情感和态度动态