摘要

JetBrains Research 分析了 4782 个真实的 IDE 编码智能体会话，发现修 bug 与加功能只占开发者诉求的不到一半，其余是提问、规划、代码评审、重构与命令执行；而 SWE-Bench Pro 里 93.8% 的任务都是功能与缺陷修复，且每条任务都是一次性的完整消息。团队由此提出 SWE-TaskFlow，把同一条 issue 重写成三条顺序请求。实测结果：四个模型在拆分后的每任务成本上涨 2.0–2.6 倍，解决率却几乎不变；对照实验证明额外成本来自"顺序递送"而非改写。

正文（译文）

编码智能体基准应当匹配用户的任务流

本文总结我们的论文《观点：编码智能体基准应当匹配用户的任务流》，该论文已被 NeurIPS 2026 的"交互式智能体评估"研讨会接收。

在 JetBrains Research，我们最近分析了软件工程师在 JetBrains IDE 中工作的 4782 个智能体会话，并与三个公开的智能体对话集做了对比。在我们观察的开发者会话中，修 bug 与加功能只占开发者要求编码智能体所做的事情的不到一半，其余包括针对代码库的提问、规划、代码评审、重构与命令执行。而在 SWE-Bench Pro 中，93.8% 的任务是功能开发与缺陷修复，且每条任务都以一条完整的消息抵达。这个差异相当大。

这个落差正是本文的主题。我们分析的结论是：不存在普适的、现实的编码智能体基准——基准应当针对特定用户群体的实测结果进行校准。SWE-TaskFlow 是我们为此提出的工具；本文中，我们把它应用到 SWE-Bench Pro 上。

基于 issue 的基准在测量什么

SWE-bench 及其后继者（SWE-Bench Pro、SWE-rebench、DeepSWE）从 GitHub issue 构建任务。智能体拿到仓库检出与 issue 文本，探索代码、修改并提交补丁；测试决定补丁是否解决了问题，解决问题的比例即为解决率。

支撑这些任务的基础设施构建成本很高：需要处在正确提交上的仓库、能运行代码的环境，以及验证改动的测试。但叠加其上的交互层是固定的——完整的规格说明以一条打磨好的消息抵达，最终只对一个补丁打分。

尽管交互层是固定的，开发者在 IDE 中只有一部分时间是那样工作的。也就是说，我们看到的会话中有一半是单条消息。其余的会话里，需求是分批到来的：在两次变更请求之间，开发者会让智能体解释项目某部分如何运作、规划下一步改动，或者评审已完成的改动，而此前的诉求仍必须被一并带着走。

开发者实际如何使用智能体

4782 个会话（我们称之为 Production Sessions）中的每一个，都是开发者与 IDE 内编码智能体之间的一段对话；合计包含约 14000 条开发者消息。我们只看开发者一侧，上图展示消息在这些会话中的分布。

一半的会话（50.9%）是单条消息；约 15% 超过五条。由于我们的研究对象是交互式智能体，后续分析集中在占 33% 的、至少有三条开发者消息的"长会话"上。

一个开源权重大语言模型（Gemma 4-31B）为每条消息标注 16 种请求类型（意图）之一：缺陷修复、新功能、解释、规划、代码评审、执行等等（全部 16 种在论文中定义）。同一个分类器、同一套提示词也标注了公开数据集与 SWE-Bench Pro 的 issue，因此本文中的每一项分布都是在相同口径下测量的。

在所有会话中，缺陷修复占已标注消息的 26%，新功能占 19%。在长会话中，针对项目自身代码的解释占 6%，通用编程问题另占 10%；规划、代码评审、重构、调试与执行构成其余大部分。SWE-Bench Pro 以同样方式标注后，由 55% 新功能、39% 缺陷修复、6% 重构组成，别无其他。

会话长度与意图构成是"任务流"三个组成部分中的两个；第三个是意图彼此跟随的顺序。以一次功能请求开头的会话，往往接着是对既有行为的提问、一个规划步骤，以及一次评审请求。

公开数据集的对比

我们的 Production Sessions 只代表一个用户群体。为了看清这幅图景在多大程度上取决于群体，我们对下列每个公开数据集各取 1000 个会话跑了一遍分类器，并保留其中的长会话。下面给出各自的桑基图。本文中的桑基图即任务流：每一列是一个消息位置，列与列之间的条带是这些转移。

SpecStory 由公开的 IDE 会话导出构成，即《Programming by Chat》一文分析的数据。其 1000 个会话中 521 个是长会话。三者中它与我们的会话最接近，规划占比更高。

DataClaw 收集社区分享的编码智能体会话。1000 个中 585 个是长会话。它以执行请求与简短的操作性消息为主。

SWE-chat 是在聊天场景中收集的真实用户编码智能体对话集。1000 个中 698 个是长会话。执行与规划是它最大的两类意图。

这三个语料来自不同产品、不同用户、不同采集方式，因此我们不对其进行定量比较。不过，针对其中任何一个校准出来的基准，其任务构成与转移关系都会不同于针对另一个校准的基准。它们都不是 ground truth，我们的 Production Sessions 也不是——目标必须被选择并被声明。

在我们的试点中，目标就是长 Production Sessions。按频率校准有一个副作用：目标中罕见的一切都会被推向零。罕见但后果严重的行为，例如破坏性 shell 命令或与安全性相关的评审，应当改在各自的压力测试切片中、以各自的任务量来评估。

SWE-TaskFlow 如何改造既有任务

为每个目标新建一个交互式基准，会丢掉基于 issue 的基准已有的东西。因此，我们提出 SWE-TaskFlow：它改造一个既有基准，保留仓库、环境、测试与原始需求，只重新生成用户消息。

把 issue 拆成若干请求

一个大语言模型把每条 issue 重写为三条有序请求，我们称之为 issue 请求，因为其中一切都来自原始 issue。智能体在看到第二条之前先处理第一条。拆分必须保留每一条原始需求且不新增任何需求；标识符与代码片段逐字保留；每条请求必须在前一条留下的仓库状态下可执行。第二轮模型检查结果的完整性。731 个公开 SWE-Bench Pro issue 中有 31 个未通过拆分与评估检查被剔除，最终留下 700 个任务。

下面是一条 qutebrowser issue 的例子，标题为"因旧版 QtWebEngine 缺少 Array.prototype.at 支持导致 LinkedIn 失效"。原始 issue 是一条约 1000 字符的消息。拆分后变成：

• 请修复 macOS 上 qutebrowser 在 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 方法不可用时才被注入。

第一条请求已足以开工；边界情况稍后才到。

加入针对仓库的提问

在 Production Sessions 中，对项目自身代码的解释很常见，而在基于 issue 的基准里完全缺失，因此我们来生成这类提问。一个模型连同此前解决该 issue 的智能体轨迹一起阅读仓库，提出一到三个问题。每个问题必须仅凭仓库即可回答、在修复前后都成立、且不泄露解法。

每个问题都配有参考答案与一个可执行验证脚本，后者从仓库中收集支持答案的证据。在数据集构建时，我们在干净检出中运行该脚本，只有当脚本通过、产出证据且未改动仓库时才保留该问题。这在构造上排除了那些答案无法在代码中观察的问题（例如"当初为什么这样设计？"）。在评估时，智能体以文本作答，由另一个大语言模型对照隐藏的参考答案及其证据来评判。

在发布的配置中，上面那条 qutebrowser 任务得到一个提问，被放在第一与第二条 issue 请求之间：

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

参考答案点明了触发该路径的两个配置选项，并走查五个文件。验证脚本针对真实代码执行一次样式表配置变更，检查由此产生的脚本注册与对活动页面的调用，并确认一个无关选项不会触发任何动作。这个问题与 Array.prototype.at 无关：它来自解题智能体沿途读到的代码，而非修复本身。

挑选与目标匹配的序列

提问可以放在 issue 请求之前、之间或之后，因此每个任务有若干候选序列。我们为每个任务挑选一个，使整个基准在"任务流对齐分数"（TFAS）的衡量下接近长 Production Sessions。TFAS 用 Jensen-Shannon 散度比较目标与基准之间的三个分布（会话长度、意图、转移），并合成为 0–100 的分数。纯拆分相对我们设定的目标得分为 59.6。在固定位置加入提问可升至 75.6–77.1；让优化器决定每个任务保留几个提问及放在哪里，可升至 77.8。最终结果是 700 个任务中有 255 个携带共 454 个提问（113 个任务 1 个提问、85 个 2 个、57 个 3 个），其中 67 个任务的提问全部位于 issue 请求之前，86 个全部位于之后，102 个交错分布。其余 445 个任务保留三条 issue 请求。

在右图中，issue 请求携带的是 issue 中已有的任务类型：缺陷修复、新功能与少量重构，与左图 SWE-Bench Pro 的全部构成一致。拆分之后也浮现出一些更小的意图：调试、转换、测试、规划等。这些不是新增内容，而是原始 issue 的组成部分——分类器把 issue 视作一条消息时把它们折叠进了主导意图（例如一条同时要求补回归测试的缺陷修复 issue），拆分后便成了独立的消息。唯一来自 issue 之外的意图是"解释"，由仓库提问带来。

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

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

• Single：原始 issue 放在一条消息里。

• Split：三条请求，在同一次对话中依次送达。

• Split+QA：经 TFAS 选出的、带仓库提问的序列。

把 issue 拆成三条消息，使每个模型的每任务成本上升 2.0–2.6 倍。由于仓库、测试与需求都没有变，这多出来的成本衡量的是：当需求分批抵达时，智能体要多付出多少努力。解决率的变化更小：GPT-5.6 Terra 持平，其余三个平均下降 4–5 个百分点，这与同一设置下不同单次运行之间的离散度相当。在每种设置三次运行的条件下，这些结果并不足以给模型排名；它们说明的是，渐进式披露会稳定地改变所需努力，而只轻微改变结果。

改写本身（而非顺序）也可能让任务变难。我们设置了一个对照条件 Concat：把同样三段改写后的内容粘贴进一条消息。对三个 GPT 模型各跑一次，它在成本与解决率上都落在 Single 旁边，因此 Split 的额外成本来自顺序递送，而非措辞改写。

加入仓库提问，在 Split 的基础上再增加 4%–24% 的成本，视模型而异。在携带提问的 255 个任务上，评判器判定为正确的答案比例（答案准确率）从 69.8%（GPT-5.4 Mini）到 83.0%（GPT-5.6 Terra）不等。

拆分后的轨迹还支持中间验证。在每条 issue 请求之后，我们可以对仓库做快照并重跑测试，只针对已披露的需求打分。在一个 64 任务的消融实验中，解决率与测试通过率都随每一轮 issue 请求而上升，而提问的位置不会移动这些曲线。一个任务由此产生若干个经过验证的检查点，而非单一最终得分。这对诊断有用，对训练也可能有用——后者我们尚未尝试。

SWE-TaskFlow 尚未覆盖的部分

SWE-TaskFlow 目前生成两类消息：issue 请求与仓库提问。真实会话任务流中的其余部分（通用编程问题、规划、代码评审、issue 之外的重构、执行、不带修复的调试）仍各自需要自己的生成器与验证器，而且其中大多数如何自动校验响应尚不清楚。至少，实测出的任务流告诉我们还缺哪些增强、以及各自占多大比例。

所有消息在运行前也是固定的。这带来了精确的可复现性与配对比较，并能测量渐进式披露、记忆与适应能力，但无法测量智能体如何处理反馈：这里的"用户"不会对智能体的行为做出反应。带模拟用户的反应式基准可以覆盖这一点，代价是轨迹方差；一套完整的评测方案应当把经过校准的静态核心，与有针对性的反应式切片结合起来。除此之外，分类器没有人工标注的准确率数据集；部分 issue 无法拆分；问题难度取决于撰写它们的模型；试点每种设置只有三次运行。

亲自试试

Hugging Face 上的 SWE-TaskFlow-SWE-Bench-Pro 数据集以 12 个配置作为独立分片发布：原始提示词、拆分后的提示词、Split+QA 变体，以及仅含提问的会话。每个问题都带有参考答案与验证脚本。仓库、gold patch 与测试仍保留在原始的 SWE-Bench Pro 发布中。