平等建议。

摘要

AI 编程智能体正被大规模采用，然而我们缺乏关于人们实际如何使用它们、以及它们的输出在实践中有多大用处的实证证据。我们提出了 SWE-chat，这是首个从开源开发者真实环境中收集的大规模编程智能体会话数据集。该数据集目前包含 6,000 个会话，涵盖超过 63,000 条用户提示词和 355,000 次智能体工具调用。SWE-chat 是一个动态数据集；我们的收集流程能够自动且持续地从公共代码仓库中发现并处理会话。借助 SWE-chat，我们对现实世界中编程智能体的使用模式和失败模式进行了初步的实证分析。我们发现编程模式呈双峰分布：在 41% 的会话中，智能体撰写了几乎所有提交的代码（“氛围编程”），而在 23% 的会话中，人类自己编写了所有代码。尽管能力在快速提升，编程智能体在自然环境中仍然效率低下。在所有智能体生成的代码中，只有 44% 最终被保留在用户的提交中，并且智能体编写的代码比人类编写的代码引入了更多的安全漏洞。此外，用户在 44% 的交互轮次中，通过纠正、报告失败和中断等方式，对智能体的输出进行了抵制。通过捕获带有“人类 vs. 智能体”代码作者归属的完整交互轨迹，SWE-chat 为超越精心策划的基准测试、转向基于证据理解 AI 智能体在真实开发者工作流中表现如何，提供了实证基础。

1 引言

AI 编程智能体已经席卷全球。通过为大语言模型（LLM）增加一组简单的、用于自主与编程环境交互的操作——即所谓的编辑文件、执行终端命令以及调用子智能体的工具调用——极大地加速了它们完成长周期、高难度编程任务的能力（Yang 等人，2024a）。近期，有报道称 AI 智能体在人类需要 12 小时才能完成的编程任务中，有 50% 能够成功完成（METR，2026；Kwa 等人，2025）。因此，开发者越来越多地将编程工作委托给智能体（Mürtz 和 Müller，2025；Anthropic，2026），这对全球劳动力产生了前所未有的影响（Peng 等人，2023；Demirci 等人，2025；Massenkoff 等人，2026）。

尽管 AI 编程智能体已被大规模采用，但我们对人类与 AI 编程智能体如何交互的理解在很大程度上仍停留在传闻层面。虽然近期已有研究开始在真实场景中评估代码补全模型（Chi 等人，2025），但对于完整的智能体编程会话，尚不存在类似的研究工作。目前没有任何公开数据集能够捕捉开发者如何向智能体提供提示词、引导其方向、覆盖其输出，并最终提交（或丢弃）智能体生成的代码。在软件工程（SWE）任务方面，大多数 AI 基准测试仅包含一组相当有限的、经过精心策划的问题，这些问题具有明确且可验证的解决方案（Jimenez 等人，2024；Yang 等人，2024b；Deng 等人，2026；Kottamasu 等人，2026）。即使是更新的基准测试也仅关注任务难度（Merrill 等人，2026），但仍然忽略了人机交互这一维度（Wang 等人，2026b）。然而，在带有详尽说明的、精心策划的 GitHub issue 上表现优异，并不能转化为现实世界中迭代式的使用场景（Pan 等人，2025；Wang 等人，2026a）。人们越来越认识到，下一个前沿领域在于评估智能体在体现实际开发特征的协作工作流中的表现（Patwardhan 等人，2025；Cursor Research Team，2026；Anthropic，2025；2026）。理解开发者如何在实践中使用编程智能体，是构建真正有用的智能体的前提。收集真实世界中的实际使用数据是弥合这一差距的唯一途径：

1. RQ1

   用户在真实世界的编程任务中是如何与编程智能体交互的？

编码智能体正越来越多地被部署为自主问题解决者，尽管我们没有任何经验证据表明开发者实际使用了其多少输出、它们失败的频率有多高，或者当它们失败时用户如何应对。

1. RQ2

   编码智能体在实践中是如何失败的，用户又是如何应对的？

1.1 我们的贡献

我们提出了 SWE-chat，这是首个来自真实用户在真实仓库上的大规模真实编码智能体会话数据集（图1）。SWE-chat 包含了人类与 AI 编码智能体之间的完整交互轨迹，包括完整的工具调用路径以及带有作者归属（人类 vs 智能体）的代码差异（表1）。这使得研究人员不仅能够研究代码智能体产生了什么，还能研究用户如何提示、引导和覆盖它们。我们在第2节中描述了数据收集流程和汇总统计数据。

我们借助 SWE-chat，首次系统性地梳理了真实编码智能体使用中的实证洞察，总结于图 2。第 3 节（针对研究问题 1）对交互行为的分析表明，人类依赖编码智能体完成的任务范围远超编写补丁修复缺陷或实现功能：理解现有代码是最常见的用户意图，而智能体在工具调用中约有三分之一用于执行 bash 命令，而非编辑文件（图 19a 和 19b）。这表明，仅聚焦于补丁生成的评测基准严重低估了真实智能体工作流的操作多样性与复杂性。用户的编码模式呈现极端双峰分布：在大多数会话中，AI 智能体要么完全不写代码，要么写出全部代码（图 5）。然而，尽管“氛围编码”趋势正在兴起（图 25），完全自主的一次性问题解决仍远未成为现实。事实上，交互通常涉及多轮对话，用户对于智能体该做什么以及如何做，往往非常挑剔（图 4 和图 24）。

我们在第 4 节（针对研究问题 2）对失败模式与用户反馈的分析揭示了大量改进空间。我们识别出成功率较低的会话，发现智能体未能恰当完成用户请求的案例（图 6）。此外，我们发现智能体生成的全部代码中，最终被用户提交采纳的不足一半（表 3）。氛围编码尤其低效，每提交一行代码所消耗的 token 和费用远高于协作编码（图 7 和图 29）。氛围编码生成的代码安全性也显著更差。每提交一行代码，其引入的安全漏洞数量大约是人类自行编写代码的倍数，也大约是人类与智能体共同编写代码的倍数（表 4）。智能体自主运行的时间越来越长——第 99.9 百分位的单轮对话时长现已超过 100 分钟——但它们极少主动向用户请求澄清（图 30）。用户通过以下方式加以补偿：在 5% 的轮次中打断智能体，并在 39% 的轮次中对智能体输出提出异议，通常提供修正意见和失败报告（图 8）。

在第 5.1 节中，我们概述了 SWE-chat 如何帮助缩小其中一些差距的路线图——无论是通过更真实的基准测试、更好的交互设计，还是基于真实会话数据评估的开源用户模拟器。

媒体内容 · 前往原文查看

数据集	人类提示词	智能体工具使用轨迹	代码差异	代码归属
SWE-smith-trajectories (Yang 等人, 2025)	✗	✓	✓	✗
CoderForge-Preview (Ariyak 等人, 2026)	✗	✓	✓	✗
SERA (Shen 等人, 2026)	✗	✓	✓	✗
nex-agi-agent-sft (Cai 等人, 2025)	✗	✓	✓	✗
SWE-rebench-openhands-trajectories (Trofimova 等人, 2025)	✗	✓	✓	✗
Agent Trajectories (Bouzenia 和 Pradel, 2025)	✗	✓	✓	✗
Multi-SWE-bench_trajs (Zan 等人, 2025)	✗	✓	✓	✗
Agent Data Protocol (Song 等人, 2025)	✗	✓	✓	✗
AIDev (Li 等人, 2025)	✗	✗	✓	✗
AgentPack (Zi 等人, 2025)	✗	✗	✓	✗
SWE-chat (本文)	✓	✓	✓	✓

2 SWE-chat

2.1 数据收集

我们从公开的 GitHub 仓库构建数据集，这些仓库的开发者已选择加入 Entire.io 的 CLI 检查点日志记录，该功能会在专用分支上记录编码智能体的会话记录。每个检查点都关联到一个提交，并带有行级代码作者归属。当开发者启用该功能时，Entire 会自动记录各种编码智能体（Claude Code、OpenCode、Gemini CLI、Cursor 和 Factory AI Droid）的会话记录。这些会话日志捕获用户提示词、智能体响应、工具调用（文件编辑、Shell 命令、代码搜索等）以及 token 使用量。我们在附录 C.1 中提供了关于数据收集流程及其快速增长轨迹的更多细节。

媒体内容 · 前往原文查看

由此产生的 SWE-chat 数据集提供了对真实世界人机协作的全面观察，包含来自 200 多个代码仓库的近 6000 次编码会话（图 1）。截至撰写本文时，该数据包含超过 13,000 个检查点、63,000 条用户提示词以及 355,000 次智能体工具调用。完整数据集包含 270 万个记录事件——这些事件还包括流式进度事件、工具调用的返回值，以及来自 200 次启用扩展思考的会话中的少量推理轨迹。这一趋势在图 1 所示的陡峭曲线中清晰可见。我们计划在持续收集新数据的过程中频繁更新我们的网站和数据。图 3 展示了一个 SWE-chat 会话示例，以说明会话结构。由于 SWE-chat 仅捕获主动选择加入 Entire 公开检查点记录的开发者，因此该数据集反映的是早期采用者群体，可能无法推广至所有编码智能体用户；我们将在附录 A 中讨论这一局限性及其他限制。

2.2 数据统计

SWE-chat 由多轮编码智能体会话组成，这些会话收集自数百名真实用户（图 4）[注 1：在我们的数据分析中，我们过滤掉了任何看似由自动化机器人生成的数据。]，他们与五种广泛使用的编码智能体进行交互。[注 2：实际上，数据主要来自 Claude Code 的使用数据，因为它是目前使用最广泛的编码智能体之一，也是 Entire.io 的 CLI 工具最早支持的智能体。] 智能体通常会针对任何用户请求进行多次工具调用（图 4b），并与多种编程语言交互，这反映在会话期间涉及的文件类型中（图 4c）。我们在附录 D.1 中提供了更详细的数据集统计信息，并在附录 D.2 中探讨了任务主题分布。

2.3 数据分析方法

SWE-chat 的真正价值在于能够大规模地理解复杂的人机智能体行为，超越总体统计数据，深入刻画开发者如何与编码智能体在长尾场景中交互，以及会话成功或失败的原因。为此，我们通过添加标注来丰富数据集，这些标注既为研究人机协作的研究人员（研究问题1）提供信号，也为致力于构建更有用智能体的模型开发者（研究问题2）提供信号。我们使用表2中列出的标注规则对会话和用户提示词进行分类，每条规则旨在捕捉真实世界智能体使用的特定维度。

我们为每项任务制定了清晰的标注编码手册，并评估了标注者间的一致性，所有任务的一致性均达到中等至高水平（详见附录E）。我们依赖大语言模型评判员来标注整个数据集。需要指出的是，大语言模型可能会出错，因此并非可靠的数据标注工具（Baumann 等人，2025）。然而，我们选择这种方法是因为其可扩展性，能够在收集新数据时持续进行标注。对于每项任务，我们使用多种提示词改写，评估了各种开源和专有大语言模型在零样本条件下与人类专家黄金标签的对比表现，然后用表现最佳的模型和提示词对完整数据集进行标注。我们在附录E.1中详细描述了完整的大语言模型作为评判员的验证方法。

此外，我们利用了来自原始会话日志和代码归属数据的丰富信息，这些数据捕获了所有智能体事件——它们调用了哪些工具、生成了多少代码以及花费了多长时间。为了量化其效率，我们定义了一套指标（详见附录C.2），用于衡量智能体生成的代码最终被用户采纳并提交的比例（代码存活率）、智能体自我重写的开销（编码效率），以及每行被提交代码所需的token、成本、时间和用户工作量。为了评估代码安全性，我们还对每次提交变更的提交前后快照运行了静态分析工具Semgrep（https://github.com/semgrep/semgrep），并统计了该提交引入的安全问题数量。这使我们能够比较不同编码模式下每行提交代码引入漏洞的比率（见第4.3节及附录D.5的详细说明）。这些指标使我们能够回答研究问题2（RQ2），揭示智能体在哪些方面浪费了精力，以及它们的输出在哪些方面未能达到开发者实际提交代码的标准。

媒体内容 · 前往原文查看

等级 任务描述 分类 输入 重要性 会话 会话成功率 每次会话在0–100分尺度上的整体成功率。 完整对话及所有工具调用的摘要。 能够识别失败模式，有助于作为奖励建模的训练信号。 用户画像 为每次会话分配四种行为画像之一（专家挑剔者、模糊需求者、反复修改者或其他）。 按时间顺序汇总会话事件，并附有描述（对话与工具调用）。 描述开发者如何与智能体交互，这有助于设计更具适应性的智能体界面。 用户提示词 提示词意图 标注提示词的主要用户意图：创建新代码、重构、调试、理解、连接、git操作、测试或其他。 不带上下文的原始提示词文本。 揭示真实工作流程的操作多样性。 用户反馈 将非打断性提示词分类为反馈类别：纠正、拒绝、失败报告或非反馈。 提示词之前的完整对话记录。 直接衡量降低用户体验的摩擦点，指示智能体在哪些方面存在不足。

3 人类在真实环境中如何与编码智能体互动？（研究问题1）

3.1 任务类型：智能体协助完成的任务范围广泛，远不止编写代码

用户请求多种多样

图19a展示了用户意图的分布。虽然很大一部分提示词（26.6%）属于宽泛的“其他”类别，但最常见的具体请求是理解现有代码或行为，占所有提示词的19.0%。创建新代码是另一个常见意图，占比13.4%。日常开发任务，如git操作（13.4%）和调试（13.0%），也很普遍，而代码重构、编写测试和建立连接则出现频率较低。

编码智能体不仅需要针对代码生成进行优化，还必须针对代码理解和日常开发任务进行优化。现有基准测试主要聚焦于补丁生成，对这些能力的体现不足。

智能体在单次交互中会调用多种工具

在所有智能体工具调用中，有三分之一是 bash 命令——主要是 git 操作——其次是文件读取、编辑和 grep 搜索（见图 19b 和表 5）。智能体的运行轨迹通常以读取和搜索工具开始，随后过渡到文件修改和构建命令（图 21(a)）。

3.2 编码模式：氛围编码正日益普遍

所有已提交代码行中有 55.8% 由编码智能体编写，但这种分布呈现极强的双峰特征——见图 5。因此，我们引入了三种不同的编码模式：

• 纯人工编码（占 22.7% 的会话）：所有提交的代码均由人类编写。智能体仅作为代码理解、调试或 git 操作的辅助工具。

• 协作编码（占 36.5% 的会话）：人类和智能体共同贡献提交的代码，智能体编写的代码行占比在 0% 到 99% 之间。

• 氛围编码（占 40.8% 的会话）：超过 99% 的提交代码由智能体编写。

氛围编码正变得越来越普遍：在我们三个月的观察窗口内，其占比已从 20% 翻倍增长至超过 40% 的会话（图 25）。

3.3 用户类型：专家吹毛求疵行为占主导

为了描述用户如何超越单次提示词与智能体交互，我们根据完整的对话记录将每次会话归类为一种行为画像（表 2）：专家吹毛求疵者——在保持目标稳定的同时细致地纠正智能体输出；模糊需求者——任务说明不充分，将决策权委托给智能体；以及中途变卦者——在会话中途改变目标。大多数用户表现为专家吹毛求疵者（图 24）。即使在氛围编码会话中也是如此（占 47%）。中途变卦在氛围编码期间较少见（5%，而其他模式为 10%）。这与当前的评测基准形成鲜明对比，后者会预先提供完整的指令。在现实中，用户会在看到智能体的输出后迭代地完善他们的指令。

4 编码智能体如何失败，用户又如何应对？（研究问题 2）

4.1 大多数编码智能体会话成功完成了用户请求

图 6 显示，90% 的会话获得了 50 分以上的成功度评分，表明编程智能体通常能够满足用户的需求。纯人工会话的平均成功度评分略低于协作编程和氛围编程会话。

分布中成功度评分较低的尾部更有趣，因此我们手动检查了成功度评分最低的 50 个会话（评分 2–15）。这些会话中最常见的失败模式是：用户在智能体交付有意义的输出之前中断会话，以及智能体产出的工作或提交内容与用户的实际需求完全无关。我们在图 B.1 中提供了一个此类示例。

4.2 编程智能体效率低下

用户丢弃了大部分 AI 编写的代码

智能体产出的所有代码中，只有不到一半（44.3%）最终被用户提交（表 3）。在氛围编程会话中，用户接受度更高，平均提交了 59% 的 AI 编写的代码行。然而，这种更高的存活率很难进行因果解释：它可能反映了智能体输出更精准地切中需求，也可能反映了用户审查力度较低。

效率低下的主要来源是智能体编写但用户决定不提交的代码（见表 3 中的“用户删除”）。如果用户自己直接修改了代码，则归入“用户覆盖”。请注意，智能体的自我覆盖通常发生在用户提出反对意见并指示智能体在提交前重新实现某些功能时。

媒体内容 · 前往原文查看

编程模式	编程	代码存活率	详细归属明细
	效率	比率
所有模式	44.3%	50.3%
协作模式	38.2%	44.1%
氛围编程	59.0%	64.6%

XX 存活 XX 智能体自我覆盖 XX 用户覆盖 XX 用户删除

氛围编码成本高昂且速度缓慢

虽然在氛围编码模式下，智能体输出有更大比例存活到提交中，但这是以每行提交代码成本显著更高为代价的。氛围编码会话每 100 行提交代码消耗的中位数为 204K 个模型 token——大致高于协作会话，也高于纯人工会话。换算成美元成本，氛围编码每 100 行提交代码的中位成本为 0.13 美元，而纯人工模式为 0.07 美元，协作模式为 0.05 美元。此外，用户在氛围编码时投入了更多精力来编写提示词（图 7 和图 29）。

在时间方面，协作会话效率最高，每 100 行提交代码的中位时间为 4.8 分钟，而氛围编码（12.6 分钟）和纯人工会话（8.6 分钟）则相对较慢。智能体运行时间指标（不包括等待用户输入的时间）在所有模式下与会话运行时间高度吻合。然而，需要注意的是，时间和智能体运行时间都是不完美的代理指标，因为它们没有考虑用户在编码会话之前或之后花费的编码时间。

4.3 氛围编码每行代码引入更多安全漏洞

表 4 报告了每种编码模式引入安全漏洞的比率。对于每次提交，我们都在提交前和提交后的仓库快照上运行静态分析工具 Semgrep，并统计在提交后出现但提交前未出现的结果，且仅限于提交所修改的文件（详见附录 D.5）。氛围编码提交引入漏洞的比率约为每 1000 行提交代码中若干，大致比纯人工编码（）高，比协作编码（）也高。氛围编码提交修复漏洞的比率也更高（每 1000 行代码中若干，而纯人工编码为，协作编码为），这反映出总体上与安全相关的代码变更更多。但在每种模式下，引入的漏洞都多于修复的漏洞，而氛围编码的差异最大。

媒体内容 · 前往原文查看

	已修复的漏洞	引入的漏洞
编码模式	（每 1000 行）	（每 1000 行）
纯人工	0.04	0.08
协作	0.08	0.14
氛围编码	0.52	0.76
总体	0.06	0.11

我们观察到一系列漏洞类型，包括路径遍历、命令注入、不安全的格式字符串和 SQL 注入（参见附录图 26 和图 27）。如果氛围编码在实际开发中的占比继续增长（图 25），新引入的安全问题的绝对数量可能会增加，从而使生产代码的安全性降低。

4.4 智能体自主运行时间更长，但用户频繁干预

现在我们来看由智能体或用户发起的会话终止。为了与 McCain 等人（2026 年）的研究结果具有可比性，图 8 中的结果我们仅包含来自 Claude Code 的数据。

智能体自主运行时间更长

大多数 Claude Code 交互都很简短。中位数轮次持续时间不到一分钟，即使是第 90 百分位也保持在七分钟以下（图 30）。这与 McCain 等人（2026 年）报告的趋势基本一致。虽然第 99.9 百分位的轮次持续时间远低于 METR 估计 Claude Code 能以 50% 成功率解决的 12 小时人类等效任务难度（Kwa 等人，2025 年），但我们在数据收集期间观察到了一个明显的上升趋势。

人类经常打断智能体并予以反驳

图 8 按编码模式细分了智能体主动停止、用户打断和用户反驳的情况。在所有模式下，Claude Code 很少主动向用户请求澄清（1.1%–2.6%）。氛围编码会话中更高的智能体自主性体现在智能体提问次数更少。令人惊讶的是，智能体主动停止的比例远低于 McCain 等人（2026 年）报告的数据。

相比之下，用户打断智能体的频率更高（3.3%–6.0%）。这种效应在时间上（见图 31）和不同编码模式间（图 8）都保持稳定。当用户打断正在进行的轨迹时，打断最常发生在智能体退出计划模式、执行 git 操作或编辑文件时（图 21(c)）。

比硬性用户打断更常见的是软性用户反驳，其形式是在智能体轮次结束后给出纠正性提示词。总体而言，无论编码模式如何，用户在 39% 的轮次后都会进行反驳。观察到氛围编码会话仍然表现出相当高的反驳率，这表明用户并非完全被动，即使完全依赖 AI 智能体编写代码也是如此。

5 讨论

综合来看，我们的研究结果表明，编程智能体尽管潜力巨大，但在效率和人机协作方面仍有很大的改进空间。我们对 SWE-chat 的分析为这一理解提供了实证基础：我们揭示了在受控评估中不可见的交互模式、效率差距和失败模式。这些发现并非定论。相反，它们为围绕野外智能体评估和人机交互研究这一更广泛的研究议程提供了一个起点。

自主性正在超越监督

氛围编程正成为新常态。在超过 40% 的案例中，智能体编写了超过 99% 的已提交代码（图 5）。与此同时，像 Claude Code 这样的智能体仅在 1.4% 的交互轮次中会停下来向用户提出澄清性问题。而用户方面，则在约 44% 的交互轮次中频繁地打断和提出异议（图 8）。这种不对称性表明，智能体获得自主性的速度可能快于它们学习何时寻求指导的速度，从而使用户不得不通过人工监督来弥补。

智能体功能强大但脆弱

智能体独立工作的时间更长，编写的代码也更多（图 30），但更高的自主性并未转化为更高的交付效率。智能体编写了超过一半的已提交代码，然而它们总输出中只有不到一半最终被保留在提交中（表 3）。智能体很少表示不确定，错误通常只有在用户主动检查输出时才会被发现（章节 E.2.4）。这与更广泛的观察结果一致，即 AI 模型常常会无声地失败（Potts 和 Sudhof，2026）。值得注意的是，人类与智能体共同编写代码的协作会话是我们观察到的最具成本效益的模式（图 29），这表明当前追求完全自主性的方向可能适得其反。重要的是，这些发现并非反对使用编程智能体。相反，它们揭示了智能体的效率尚未达到其应有的水平。

智能体编写的代码引入了更多安全漏洞

先前研究已表明，大语言模型即便在良性提示词下也可能生成不安全的代码（Pearce 等人，2025；Bhatt 等人，2023；Fu 等人，2025）。使用 AI 助手的开发者更有可能产出不安全的代码，同时却对其安全性更有信心（Perry 等人，2023）。SWE-chat 将这一现象延伸至开发者使用编码智能体的真实工作流程：通过“氛围编码”提交的代码中，由 Semgrep 检测出的漏洞出现率大致与纯人工编码相当，也与协作编码相当（表 4）。结合我们关于智能体极少表达不确定性的发现（图 8），这表明随着自主性增强，捕捉不安全模式的负担完全转移到了用户身上。现有的缓解措施，如安全微调和系统提示词加固（He 和 Vechev，2023；He 等人，2024；Xu 等人，2025），大多是在合成基准上评估的。SWE-chat 为检验这些干预措施在真实编码智能体任务中是否有效，提供了一个天然的测试平台。

5.1 展望：对构建更优编码智能体的启示

基于真实工作流程的务实基准

当前基准在孤立、精心策划的任务上评估智能体，奖励一次性补丁生成。但我们观察到的最常见真实意图是理解现有代码，而非编写代码，并且大多数会话涉及迭代的多轮交互，而非单次问题求解。SWE-chat 使得构建基于实际开发者工作流程的基准成为可能（Zhou 等人，2026）。例如，会话轨迹可用于评估智能体在给定真实对话上下文时，是否能提出恰当的后续行动。

设计更具适应性的智能体-人类交互

用户几乎每隔一轮就会对智能体的输出提出异议，但他们极少完全放弃会话。他们会迭代地纠正、重定向和引导智能体，直到结果可接受。与此同时，智能体在 2% 的轮次中会主动请求澄清。SWE-chat 大规模捕捉了这些纠正-响应循环，为研究人员提供了所需的数据，用以研究人类监督在实际中究竟如何展开，以及当前智能体交互设计在哪些方面存在不足（Guan 等人，2025）。

用于离线评估的用户模拟器

目前，评估编码智能体要么依赖精心设计的基准测试，要么需要进行真实用户研究，这两种方法都成本高昂且范围有限（Naous 等人，2025；Buening 等人，2026）。SWE-chat 为一种新的评估范式提供了原始素材：在真实交互轨迹上训练用户模拟器。该数据集捕获了现实模拟器需要复现的、广泛多样的行为模式。

基准测试在其创建之时是固定的，但开发者使用编码智能体的方式正在迅速变化。SWE-chat 被设计为一个动态数据集，与其所衡量的技术共同演进。通过提供持续更新，它支持纵向分析，并确保我们对智能体的理解始终扎根于它们的实际使用方式。

伦理声明

SWE-chat 中的所有数据均收集自公开的 GitHub 仓库，这些仓库的开发者已明确选择加入完整的 CLI 追踪，并将会话日志推送至公开分支。我们仅收录其许可证允许再分发的仓库。我们不收集附加在用户提示词中的图片。在发布前，我们遵循 WildChat 数据处理流程（Zhao 等人，2024），从数据集中的每条用户提示词和助手回复中移除个人身份信息（PII）。首先，我们在每一轮用户/助手对话中运行基于 SpaCy Transformer 模型的 Microsoft Presidio 命名实体识别器，以删除 PII（例如电子邮件地址、电话号码、人名）。其次，我们使用 TruffleHog 移除凭证（API 密钥、OAuth token、数据库 URI 等）。该研究程序已通过斯坦福大学机构审查委员会（IRB）的审查，并被认定为豁免。

致谢

我们感谢 SALT 实验室、STAIR 实验室、斯坦福 NLP 小组以及 MilaNLP 实验室成员提供的宝贵反馈，特别是 Chenglei Si、David Anugraha、Hao Zhu、Ricardo Dominguez-Olmedo 和 Steven Dillmann。本研究部分得到了开放慈善项目、ONR N000142412532、施密特科学基金会、NSF 2046795 和 2205329、IES R305C240046、麦克阿瑟基金会、斯坦福 HAI 以及瑞士国家科学基金会（SNSF 资助号 235328）的支持。

参考文献

• Anthropic (2025) Anthropic 团队如何使用 Claude Code。说明：https://claude.com/blog/how-anthropic-teams-use-claude-code 配套技术报告见 https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf。访问日期：2026-03-31 引用自：§1。
• Anthropic (2026) 2026 年代码智能体趋势报告：代码智能体如何重塑软件开发。说明：https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf 引用自：§C.1, §1, §1。
• A. Ariyak, J. Zhang, J. Wang, S. Zhu, F. Bianchi, S. Srivastava, A. Panda, S. Bharti, C. Xu, J. Heo, X. S. Wu, J. Zhou, P. Liang, L. Song, C. Zhang, B. Athiwaratkun, Z. Zhou, 和 Q. Wu (2026) CoderForge-preview：用于训练高效智能体的 SOTA 开源数据集。TogetherAI 博客。说明：项目核心负责人：Alpay Ariyak；Zhongzhu Zhou；Qingyang Wu 外部链接：链接 引用自：表 1。
• J. Baumann, P. Röttger, A. Urman, A. Wendsjö, F. M. Plaza-del-Arco, J. B. Gruber, 和 D. Hovy (2025) 大语言模型黑客攻击：量化使用 LLM 进行文本标注的隐藏风险。arXiv 预印本 arXiv:2509.08825。引用自：附录 A, §2.3。
• J. Becker, N. Rush, E. Barnes, 和 D. Rein (2025) 衡量 2025 年初人工智能对经验丰富的开源开发者生产力的影响。arXiv 预印本 arXiv:2507.09089。引用自：§C.1, 附录 E。
• M. Bhatt, S. Chennabasappa, C. Nikolaidis, S. Wan, I. Evtimov, D. Gabi, D. Song, F. Ahmad, C. Aschermann, L. Fontana, 等 (2023) Purple Llama CybersecEval：面向语言模型的安全编码基准。arXiv 预印本 arXiv:2312.04724。引用自：§5。
• I. Bouzenia 和 M. Pradel (2025) 理解软件工程智能体：对思考-行动-结果轨迹的研究。arXiv 预印本 arXiv:2506.18824。引用自：表 1。
• T. K. Buening, J. Hübotter, B. Pásztor, I. Shenfeld, G. Ramponi, 和 A. Krause (2026) 从用户交互中对齐语言模型。arXiv 预印本 arXiv:2603.12273。引用自：§5.1。
• Y. Cai, L. Chen, Q. Chen, Y. Ding, L. Fan, W. Fu, Y. Gao, H. Guo, P. Guo, Z. Han, 等 (2025) Nex-N1：通过用于大规模环境构建的统一生态系统训练的智能体模型。arXiv 预印本 arXiv:2512.04987。引用自：表 1。
• R. J. Campello、D. Moulavi 和 J. Sander（2013）基于层次密度估计的密度聚类。载于《太平洋-亚洲知识发现与数据挖掘会议论文集》，第 160–172 页。引用于：§D.2.1。
• W. Chi、V. Chen、A. N. Angelopoulos、W. Chiang、A. Mittal、N. Jain、T. Zhang、I. Stoica、C. Donahue 和 A. Talwalkar（2025）Copilot Arena：一个面向代码大语言模型的真实环境评估平台。arXiv 预印本 arXiv:2502.09328。引用于：§1。
• J. Cohen（1960）名义量表的吻合系数。《教育及心理测量》20（1），第 37–46 页。外部链接：文档，链接，https://doi.org/10.1177/001316446002000104。引用于：§E.1。
• Cursor 研究团队（2026）Composer 2 技术报告。外部链接：链接。引用于：§1。
• O. Demirci、J. Hannane 和 X. Zhu（2025）AI 在替代谁？生成式 AI 对在线自由职业平台的影响。《管理科学》71（10），第 8097–8108 页。外部链接：文档，链接，https://doi.org/10.1287/mnsc.2024.05420。引用于：§1。
• X. Deng、J. Da、E. Pan、Y. Y. He、C. Ide、K. Garg、N. Lauffer、A. Park、C. Rane、K. Sampath、M. Krishnan、S. R. Kundurthy、S. M. Hendryx、Z. Wang、C. B. C. Zhang、N. Jacobson、B. Liu 和 B. Kenstler（2026）SWE-bench Pro：AI 智能体能解决长周期软件工程任务吗？外部链接：链接。引用于：§1。
• Y. Fu、P. Liang、A. Tahir、Z. Li、M. Shahin、J. Yu 和 J. Chen（2025）GitHub 项目中 Copilot 生成代码的安全弱点：一项实证研究。《ACM 软件工程方法论汇刊》34（8）。外部链接：ISSN 1049-331X，链接，文档。引用于：§5。
• M. Y. Guan、M. Wang、M. Carroll、Z. Dou、A. Y. Wei、M. Williams、B. Arnav、J. Huizinga、I. Kivlichan、M. Glaese 等人（2025）监控可监控性。arXiv 预印本 arXiv:2512.18311。引用于：§5.1。
• J. He 和 M. Vechev（2023）面向代码的大语言模型：安全加固与对抗测试。载于《2023 年 ACM SIGSAC 计算机与通信安全会议论文集》，CCS '23，美国纽约州纽约市，第 1865–1879 页。外部链接：ISBN 9798400700507，链接，文档。引用于：§5。
• J. He、M. Vero、G. Krasnopolska 和 M. Vechev（2024）《面向安全代码生成的指令微调》。收录于第41届国际机器学习大会论文集，ICML’24。引用于：§5。
• C. E. Jimenez、J. Yang、A. Wettig、S. Yao、K. Pei、O. Press 和 K. R. Narasimhan（2024）《SWE-bench：语言模型能否解决真实的 GitHub 问题？》。收录于第十二届国际学习表征大会，外部链接：Link。引用于：§1。
• A. Kottamasu、A. Datta、A. Barthwal、C. Mahapatra、A. Arun、A. Hiremath、B. Foody 和 B. Vidgen（2026）《APEX-swe》。arXiv 预印本 arXiv:2601.08806。引用于：§1。
• T. Kwa、B. West、J. Becker、A. Deng、K. Garcia、M. Hasin、S. Jawhar、M. Kinniment、N. Rush、S. Von Arx 等人（2025）《衡量 AI 完成长任务的能力》。arXiv 预印本 arXiv:2503.14499。引用于：§1、§4.4。
• H. Li、H. Zhang 和 A. E. Hassan（2025）《软件工程（SE）3.0 中 AI 队友的崛起：自主编码智能体如何重塑软件工程》。外部链接：2507.15003，Link。引用于：表1。
• R. A. Martin 和 S. Barnum（2008）《通用弱点枚举（CWE）状态更新》。Ada Letters 期刊，第 XXVIII 卷第 1 期，第 88–91 页。外部链接：ISSN 1094-3641，Link，文档。引用于：§D.5。
• M. Massenkoff、E. Lyubich、P. McCrory、R. Appel 和 R. Heller（2026）。外部链接：Link。引用于：§1。
• M. McCain、T. Millar、S. Huang、J. Eaton、K. Handa、M. Stern、A. Tamkin、M. Kearney、E. Durmus、J. Shen、J. Hong、B. Calvert、J. S. Chan、F. Mosconi、D. Saunders、T. Neylon、G. Nicholas、S. Pollack、J. Clark 和 D. Ganguli（2026）《在实践中衡量 AI 智能体的自主性》。外部链接：Link。引用于：§4.4、§4.4、§4.4。
• K. O. McGraw 和 S. P. Wong（1996）《关于若干组内相关系数的推断形成》。《心理学方法》第 1 卷第 1 期，第 30–46 页。文档。引用于：§E.1。
• L. McInnes、J. Healy、S. Astels 等人（2017）《HDBSCAN：基于层次密度的聚类》。《开源软件期刊》第 2 卷第 11 期，第 205 页。引用于：§D.2.1。
• M. A. Merrill、A. G. Shaw、N. Carlini、B. Li、H. Raj、I. Bercovich、L. Shi、J. Y. Shin、T. Walshe、E. K. Buchanan 等人。(2026) Terminal-bench：在命令行界面中对智能体进行困难、现实任务的基准测试。arXiv 预印本 arXiv:2601.11868。引用于：§1。
• METR (2026) 时间跨度 1.1。注：https://metr.org/blog/2026-1-29-time-horizon-1-1/ 引用于：§1。
• C. Mürtz 和 M. N. Müller (2025) 野外智能体 - 仪表盘。注：交互式网页仪表盘。代码见 https://github.com/logic-star-ai/insightshttps://insights.logicstar.ai 外部链接：文档，链接 引用于：§1。
• T. Naous、P. Laban、W. Xu 和 J. Neville (2025) 翻转对话：训练和评估用户语言模型。arXiv 预印本 arXiv:2510.06552。引用于：§5.1。
• J. Pan、R. Shar、J. Pfau、A. Talwalkar、H. He 和 V. Chen (2025) 当基准测试会说话：通过交互式反馈重新评估代码大语言模型。收录于：计算语言学协会发现：ACL 2025，W. Che、J. Nabende、E. Shutova 和 M. T. Pilehvar (编)，奥地利维也纳，第 24672–24700 页。外部链接：链接，文档，ISBN 979-8-89176-256-5 引用于：§1。
• T. Patwardhan、R. Dias、E. Proehl、G. Kim、M. Wang、O. Watkins、S. P. Fishman、M. Aljubeh、P. Thacker、L. Fauconnet 等人。(2025) Gdpval：评估 AI 模型在现实世界中有经济价值任务上的表现。arXiv 预印本 arXiv:2510.04374。引用于：§1。
• H. Pearce、B. Ahmad、B. Tan、B. Dolan-Gavitt 和 R. Karri (2025) 在键盘前睡着了？评估 GitHub Copilot 代码贡献的安全性。《美国计算机学会通讯》68 (2)，第 96–105 页。外部链接：ISSN 0001-0782，链接，文档 引用于：§5。
• S. Peng、E. Kalliamvakou、P. Cihon 和 M. Demirer (2023) AI 对开发者生产力的影响：来自 GitHub Copilot 的证据。arXiv 预印本 arXiv:2302.06590。引用于：§1。
• N. Perry、M. Srivastava、D. Kumar 和 D. Boneh (2023) 用户在使用 AI 助手时会编写更多不安全的代码吗？收录于：2023 年 ACM SIGSAC 计算机与通信安全会议论文集，CCS '23，美国纽约州纽约市，第 2785–2799 页。外部链接：ISBN 9798400700507，链接，文档 引用于：§5。
• C. Potts 与 M. Sudhof（2026）《人机交互中的隐性失败》。arXiv 预印本 arXiv:2603.15423。引用于 §5。
• N. Reimers 与 I. Gurevych（2019）《Sentence-BERT：使用孪生 BERT 网络的句子嵌入向量》。载于《2019 年自然语言处理经验方法会议暨第九届自然语言处理国际联合会议论文集》（EMNLP-IJCNLP），K. Inui、J. Jiang、V. Ng 与 X. Wan 主编，中国香港，第 3982–3992 页。外部链接：Link, Document。引用于 §D.2.1。
• S. K. Sarkar（2025）《AI 智能体、生产力与高阶思维：来自软件开发的早期证据》。SSRN 工作论文 5713646。引用于 §C.1。
• E. Shen、D. Tormoen、S. Shah、A. Farhadi 与 T. Dettmers（2026）《SERA：软验证的高效仓库智能体》。arXiv 预印本 arXiv:2601.20789。引用于表 1。
• P. E. Shrout 与 J. L. Fleiss（1979）《组内相关系数：在评估评分者信度中的应用》。《心理学公报》第 86 卷第 2 期，第 420–428 页。外部链接：Document。引用于 §E.1。
• Y. Song、K. Ramaneti、Z. Sheikh、Z. Chen、B. Gou、T. Xie、Y. Xu、D. Zhang、A. Gandhi、F. Yang 等（2025）《智能体数据协议：统一数据集以实现 LLM 智能体的多样化高效微调》。arXiv 预印本 arXiv:2510.24702。引用于表 1。
• C. Spearman（1961）《两事物之间关联性的证明与测量》。第 45–58 页。引用于 §E.1。
• M. Trofimova、A. Shevtsov、B. Ibragim、K. Pyaev、S. Karasik 与 A. Golubev（2025）《使用 Qwen3-Coder-480B-A35B-Instruct 的 OpenHands 轨迹》。Nebius 博客。注：引用于表 1。
• Z. Z. Wang、S. Vijayvargiya、A. Chen、H. Zhang、V. A. Arangarajan、J. Chen、V. Chen、D. Yang、D. Fried 与 G. Neubig（2026a）《智能体开发在多大程度上反映了真实工作场景？》。arXiv 预印本 arXiv:2603.01203。引用于 §1。
• Z. Z. Wang、J. Yang、K. Lieret、A. Tartaglini、V. Chen、Y. Wei、Z. W. L. Zhang、K. Narasimhan、L. Schmidt、G. Neubig、D. Fried 与 D. Yang（2026b）《立场论文：AI 编程智能体研究中缺失的人类因素》。https://zorazrw.github.io/files/position-haicode.pdf。引用于附录 E、§1。
• X. Xu, Z. Su, J. Guo, K. Zhang, Z. Wang, 和 X. Zhang (2025) 《ProSec：通过主动安全对齐强化代码大语言模型》。载于第四十二届国际机器学习大会，外部链接：Link，被 §5 引用。
• J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, 和 O. Press (2024a) 《SWE-agent：智能体-计算机接口实现自动化软件工程》。外部链接：2405.15793, Link，被 §1 引用。
• J. Yang, C. E. Jimenez, A. L. Zhang, K. Lieret, J. Yang, X. Wu, O. Press, N. Muennighoff, G. Synnaeve, K. R. Narasimhan, D. Yang, S. I. Wang, 和 O. Press (2024b) 《SWE-bench 多模态：AI 系统能否泛化到视觉软件领域？》。外部链接：2410.03859, Link，被 §1 引用。
• J. Yang, K. Lieret, C. E. Jimenez, A. Wettig, K. Khandpur, Y. Zhang, B. Hui, O. Press, L. Schmidt, 和 D. Yang (2025) 《SWE-smith：为软件工程智能体扩展数据》。载于第三十九届神经信息处理系统年会数据集与基准测试轨道，外部链接：Link，被表 1 引用。
• D. Zan, Z. Huang, W. Liu, H. Chen, L. Zhang, S. Xin, L. Chen, Q. Liu, X. Zhong, A. Li, S. Liu, Y. Xiao, L. Chen, Y. Zhang, J. Su, T. Liu, R. Long, K. Shen, 和 L. Xiang (2025) 《Multi-SWE-bench：面向问题解决的多语言基准测试》。外部链接：2504.02605, Link，被表 1 引用。
• W. Zhao, X. Ren, J. Hessel, C. Cardie, Y. Choi, 和 Y. Deng (2024) 《WildChat：百万条真实世界 ChatGPT 交互日志》。载于第十二届国际学习表征大会，外部链接：Link，被伦理声明引用。
• X. Zhou, W. Sun, Q. Ma, Y. Xie, J. Liu, W. Du, S. Welleck, Y. Yang, G. Neubig, S. T. Wu, 等 (2026) 《关注智能体任务用户模拟中的仿真到现实差距》。arXiv 预印本 arXiv:2603.11245。被 §5.1 引用。
• Y. Zi, Z. Wu, A. Boruch-Gruszecki, J. Bell, 和 A. Guha (2025) 《AgentPack：一个由智能体与人类共同创作的代码变更数据集》。外部链接：2509.21891, Link，被表 1 引用。

附录 A 局限性

SWE-chat 是首个此类数据集（图 1）。然而，它仅包含那些在公开代码仓库中使用 Entire CLI 并选择加入检查点日志记录的开发者数据。这筛选出的是一批新型开源工具的早期采用者，并未涵盖企业专有代码库。在这些场景下，智能体的性能和交互模式可能存在显著差异（例如，智能体在处理无文档的遗留代码时可能更困难，而在应对结构良好的内部库时则可能更轻松）。在现阶段，基于 SWE-chat 得出的结论可能不具备普适性。此外，很大一部分数据来自 Entire.io 自身的代码仓库。不过，随着更多开源开发者采用该工具，数据集将变得越来越多样化（参见附录 D.1.4）。

大多数失败的会话并未被我们的数据捕获。如果用户完全放弃了智能体的输出，会话日志就不会被提交，因此也不会被我们的数据捕获。这很可能导致对会话成功率和智能体效率的高估。另一方面，我们将人类删除的智能体编写的代码视为低效输出。然而，其中部分代码可能在语义上得以保留，例如，当用户将智能体的建议重写到另一个文件中，或将其重构为不同形式时。我们的行级归因方法无法捕获此类情况，这可能会低估智能体贡献的真实效用。

我们数据的多样性使得评估所生成代码的质量变得困难。我们使用的一些指标（例如，提交的代码行数）应仅被理解为用户对 AI 生成输出满意度的代理指标。同样，我们的效率指标仅能捕获会话日志中可观察到的内容，可能无法反映全貌。例如，以每提交一行代码所需的提示词字符数来衡量的认知效率，并未考虑用户阅读和审查智能体输出，或规划其指令所花费的时间。未来的研究可以在此基础上，开发出更稳健的、可作为优化目标的度量方法。

大语言模型并非完美的数据标注工具（详见附录E.1）。对于基于大语言模型生成标签的结果，鉴于此类标注固有的不可靠性以及大语言模型被攻击的风险[Baumann et al., 2025]，我们不会据此得出确定性结论。相反，我们利用这些标注来方便地对所引入的大规模数据集进行筛选，例如，找出特定失败会话的案例，如附录B.1所示。我们提醒不要轻信这些标签的表面含义，并建议在将其用于下游分析之前进行进一步验证。

附录B SWE-chat示例

本附录展示了SWE-chat中具有代表性的示例，说明了用户与编程智能体之间的关键交互模式。每个示例均来自数据集中的真实会话。

B.1 低会话成功得分

媒体内容 · 前往原文查看

B.2 用户反驳

用户反驳指的是用户对智能体的输出进行引导、纠正或拒绝的时刻。我们将其区分为三种子类型：纠正（用户提供缺失信息或引导方法方向）、拒绝（用户明确撤销或拒绝智能体的工作）以及失败报告（用户报告智能体的输出存在故障或不正确）。

B.2.1 纠正

媒体内容 · 前往原文查看

B.2.2 拒绝

媒体内容 · 前往原文查看

B.2.3 失败报告

媒体内容 · 前往原文查看

B.3 强硬用户中断

媒体内容 · 前往原文查看

B.4 智能体停下来请求澄清（AskUserQuestion）

媒体内容 · 前往原文查看

B.5 提示词意图类别

每个用户提示词都根据其主要开发者意图进行分类。下面我们展示每个类别的一个代表性提示词，这些提示词来自 entireio/cli。

媒体内容 · 前往原文查看

B.6 用户画像类别

每个会话的用户根据其在完整会话中的交互模式被归类为一种行为画像。

媒体内容 · 前往原文查看

媒体内容 · 前往原文查看

媒体内容 · 前往原文查看

附录 C 实验细节

C.1 数据处理流程

来自 AI 智能体的原始会话日志数据存储在每个仓库的 entire/checkpoints/v1 分支上，包含检查点和会话元数据、用户提示词以及完整的对话记录。从每份对话记录中，我们提取结构化的对话轮次（用户提示词、助手回复、思考过程、工具调用和工具结果）、每轮次的 token 使用量以及工具调用元数据，包括文件路径和 shell 命令。

SWE-chat 数据增长轨迹

随着编码智能体让生成大量代码变得越来越容易，开发者在审查、理解和验证 AI 生成的贡献时面临着日益严峻的挑战 [Sarkar, 2025, Becker et al., 2025, Anthropic, 2026]。Entire 通过让开发者追踪其代码库的演变过程——不仅作为提交的函数，也作为提示词的函数——来满足这一需求，从而为每一次 AI 辅助的变更创建可搜索的记录。这一实用功能激励了持续采用，我们预计该数据集将继续增长，这一趋势在图 1 所示的陡峭增长曲线中已清晰可见。我们的流水线通过查询 GitHub Code Search API 来发现启用了 Entire 的公共仓库，对于每个仓库，从元数据分支下载所有检查点目录，并将原始记录解析为结构化表格。

C.2 指标

会话时长、工具调用时长、输入和输出 token 数量，以及智能体操作期间触及的文件数，均直接从编码智能体会话日志中测量得出。我们使用多种互补方法来量化编码智能体的效率，所有这些方法均基于原始数据计算，无需标注。

智能体编写的代码百分比

Entire CLI 在提交时使用影子分支上的临时检查点来计算代码归属。它构建存储在影子分支上的检查点，以获取所有已提交的人类编写行与智能体编写行。

(1)

智能体编码效率与代码存活率

为了衡量最终提交中由智能体生成的代码所占的比例，我们进行了一项事后分析，因为智能体编写的代码百分比并未记录每次工具调用的来源或智能体自身的覆盖行为。我们分析了所有变更文件的三种状态：基础版本（父提交）、智能体操作（按顺序的工具调用）以及提交版本。我们通过按时间顺序重放每个修改文件的工具调用（例如写入、编辑）来重建智能体的变更过程。每次工具调用后，我们使用 Python 的 `difflib.SequenceMatcher` 计算文件前后状态之间的行级差异。每一行都带有一个来源标签——要么是“基础”（在智能体操作之前就已存在），要么是“智能体”（由智能体引入）——随着我们沿着智能体的操作轨迹推进，该标签会不断更新。通过这种方法，我们可以追踪所有智能体的代码添加、编辑和删除操作，并计算哪些变更得以保留（以提交时的文件状态为准）。

我们根据每次提交的汇总计数得出两个比率：

	编码效率			(2)
	代码留存率			(3)

编码效率衡量的是智能体总工作量（包括它后来重写的行数）中最终进入提交版本的比例。代码留存率衡量的是智能体净输出（在自我覆盖之后）中，人类未作修改而保留的比例。请注意，当人类和智能体同时修改同一文件时，并发变更可能导致记录反映出不一致的文件状态和归属关系。

Token、成本与认知效率

我们还量化了若干每单位输出的成本指标，以捕捉生成每一行提交代码所消耗的资源。对于每个能够清晰映射到提交代码的会话（参见附录 C.3），我们计算：

	Token 效率			(4)
	成本效率			(5)
	认知效率			(6)
	时间效率			(7)
	智能体运行时效率			(8)

对于时间效率，我们考虑完整的会话运行时间，但排除所有超过 2 分钟的空闲时段，即智能体和用户均未执行任何操作的时段。对于智能体运行时效率，我们累加所有智能体轮次的完成时间，其中一轮从用户提示开始，到智能体响应结束。

C.3 将会话级统计与提交级结果相结合

会话可能跨越多个提交，而多个会话也可能贡献于同一个提交（检查点）。为了将会话级统计与提交级结果相结合，我们将表 3 和图 29 中的分析限制在那些提交级代码行可以明确归因的会话上。这涵盖了 48.6% 的会话。

附录 D 其他结果

D.1 数据集统计

D.1.1 提示词语言

用户提示词主要以英语为主（图 20）。我们使用 lingua-py444https://github.com/pemistahl/lingua-py 检测每个用户提示词的语言，并保留至少出现在 100 个提示词中的语言。我们手动验证了 2,000 个检测器报告置信度较低或预测为极低资源语言的分类。在大多数此类情况下，提示词混合了代码片段与英语指令，导致分类错误，我们据此更正了标签。

D.1.2 工具调用

表 5 提供了智能体工具调用类型的完整细分。为简洁起见，我们将部分工具调用归入聚合类别。

媒体内容 · 前往原文查看

排名	类别	数量	百分比	包含
1	读取	60,855	19.8%	Read, read_file
2	搜索	31,238	10.1%	Grep, bash grep/rg
3	通配	4,318	1.4%	Glob
4	bash:文件	21,130	6.9%	cd, ls, cat, find, mkdir, rm, bd, echo, tail, wc, lsof, head, …
5	bash:构建	24,699	8.0%	mise, bun, go, npx, cargo, pnpm, uv, python, npm, xcodebuild, node, make, …
6	bash:网络	3,541	1.2%	curl, ssh, dig, scp, nc, rsync, nslookup, ping, nmap
7	bash	16,527	5.4%	sleep, gcloud, for, source, docker, agent-browser, sed, nix, vendor/bin/phpunit, which, ./gradlew, rtk, …
8	git/gh	36,537	11.9%	git, gh
9	写入	9,025	2.9%	Write, write_file
10	编辑	60,205	19.6%	Edit, MultiEdit
11	网页	1,435	0.5%	WebFetch, WebSearch
12	智能体	20,495	6.7%	Task, TaskCreate, TaskUpdate, Agent, TaskOutput, SendMessage, …
13	MCP	6,001	1.9%	mcp__*（用户安装的 MCP 服务器工具）
14	TodoWrite	3,217	1.0%	TodoWrite
15	ToolSearch	2,804	0.9%	ToolSearch
16	AskUserQuestion	2,171	0.7%	AskUserQuestion
17	技能	1,679	0.5%	技能
18	进入计划模式	300	0.1%	进入计划模式
19	退出计划模式	1,089	0.4%	退出计划模式
20	其他	511	0.2%	杂项（apply_patch、LSP、KillShell……）

D.1.3 智能体轨迹

图 21(a) 展示了用户发出请求后，智能体轨迹中每个顺序位置上的工具调用构成。在早期位置，智能体在代码库中定位自身时，经常使用研究工具（read、grep、glob 和 git/gh）。随着轨迹推进，edit、write 和 bash:build 等行动工具变得更加突出。

图 21(b) 从相反方向审视了相同的轨迹，展示了从一轮交互的自然结束（位置 = 智能体撰写文本回复前的最后一个工具调用，如最右侧柱状图所示）向前倒推计数的工具调用构成。在自然结束的轮次中，最后的工具调用最常见的是 git/gh 命令（提交或推送结果）、bash:build（执行 bash 命令）和 edit（最终代码修改）。值得注意的是，AskUserQuestion 很少出现在位置，因为它是非阻塞的，即一轮交互只有在智能体给出回复后才算完成。

图 21(c) 应用了相同的反向轨迹分析，但针对的是以用户强行中断结束的轮次。退出计划模式是最常见的最后一个工具调用（32%），这表明用户经常在从规划到执行的过渡时刻进行中断。在这种情况下，智能体刚刚敲定其计划，用户便在做出任何代码更改之前决定改变方向。

D.1.4 代码仓库类型

为了进一步说明这些交互发生的环境背景，我们对代码仓库的领域和目标受众进行了分析。我们根据仓库的名称、描述和 README 文件，将每个仓库划分为三个领域（应用、开发工具、其他）和四类受众（终端用户、开发者、研究人员、教育）。如图 19c 和 19d 所示，大多数仓库是面向用户的应用程序或开发者工具。这种分布表明，SWE-chat 主要反映的是以实际软件工程为中心的环境，而非纯粹的学术性或探索性编程任务。

D.1.5 数据集随时间变化的多样性

在 Entire.io 于 2026 年 2 月 10 日公开发布后，开源开发者们迅速开始使用该工具，并将其编码智能体会话数据推送到公开的 GitHub 仓库中。图 22 追踪了源自 Entire.io 自身仓库的会话累计占比。在撰写本文时，该仓库贡献的会话量不到 SWE-chat 中所有会话的 20%，并且随着该工具的持续被采用，这一份额还在下降。

D.2 主题分布

为了描述用户向 AI 编码助手提出的任务范围，我们对 SWE-chat 中所有英文用户提示词进行了主题分析。

D.2.1 主题聚类方法

从所有英文提示词开始，我们首先移除了中断信号（例如，“[请求被用户中断]”）、系统注入消息（通过诸如 和 等 XML 标签前缀识别）、Claude 技能调用以及图像引用。然后，我们从所有剩余的提示词中剥离了围栏代码块和内联代码块，并排除了剥离后文本长度短于 30 个字符或超过 1500 个字符的提示词。最后，我们对不区分大小写的剥离后内容进行了去重处理。

我们使用 SentenceTransformers [Reimers and Gurevych, 2019] 中的 all-mpnet-base-v2 模型生成句子嵌入向量。我们对去除代码后的提示词文本进行嵌入，而非原始文本，这样嵌入向量反映的是用户的自然语言意图，而非粘贴代码的句法结构。在聚类之前，我们使用 UMAP 将嵌入向量的维度从 768 降至 20。

我们使用 HDBSCAN* [Campello et al., 2013, McInnes et al., 2017] 对降维后的嵌入向量进行聚类，参数设置为 min_cluster_size=150 和 min_samples=5。这产生了 20 个聚类，覆盖了 57.4% 的提示词，聚类规模从 152 到 4,329 不等（中位数为 256）。剩余的 8,265 个提示词（42.6%）被归类为噪声，这反映了编程会话提示词的多样性，它们并未形成紧密的语义分组。

对于每个聚类，我们选取 HDBSCAN* 隶属概率最高的 100 个提示词来生成主题描述，如图 23 所示。这些描述由 gpt-5.4-2026-03-05 生成，使用的提示词如下：

D.2.2 发现

我们识别出 20 个主题聚类，覆盖了 57.4% 的提示词。结果展示在图 23 中。手动检查发现，聚类 12 包含大量相似的提示词，这些提示词似乎是自动生成的。大多数其他聚类都有较高的退回率。前端编码（聚类 3）的退回率最高（75%）。聚类 17 主要由非常长的提示词组成，这些提示词通常指定多个任务，这解释了较长的智能体交互时长。

D.3 用户画像分布

图 24 显示了所有会话中用户画像的完整分布。在大多数会话中，用户扮演着专家挑剔者的角色。

D.4 编码模式随时间分布

图 25 展示了编码模式的时间演变。自 Entire 的 CLI 工具发布以来，vibe 编码会话的占比大约翻了一番，从约 20% 上升至超过 40%。

D.5 使用 Semgrep 进行代码漏洞分析

我们使用 Semgrep（https://github.com/semgrep/semgrep），这是一款开源静态分析工具，能够将社区维护的规则模式与源代码进行匹配，并以默认的 `--config=auto` 规则集运行。该工具会根据每个快照中检测到的语言自动选择规则，包括通用弱点枚举（CWE），其中涵盖了已知类型的安全弱点 [Martin and Barnum, 2008]。对于每次提交，我们提取提交前后的仓库状态，对每个状态进行扫描，并仅保留提交实际修改的文件中的发现结果。

引入漏洞的分布

图 26 和图 27 分别按 Semgrep 规则和 CWE 类别细分了引入的发现结果。一条规则（未进行清理的 JavaScript 路径拼接）占据了大多数检测到的漏洞，但其余发现结果包含大量规则和 CWE 的长尾分布，包括外部控制的格式字符串（CWE-134）、缺失完整性检查（CWE-353）、操作系统命令注入（CWE-78）和 SQL 注入（CWE-89）。因此，引入的漏洞类型范围相当广泛。

漏洞示例

图 28 展示了一个具体的 Python 漏洞示例，该漏洞由我们数据集中的某个编码智能体引入，同时附带了标记该漏洞的 Semgrep 注释。

媒体内容 · 前往原文查看

⬇

1import subprocess

2

3def run_build(target: str) -> str:

4 """运行项目的构建步骤并返回标准输出。"""

5 cmd = f"make {target}"

6

7

8

9

10 result = subprocess.run(

11 cmd, shell=True, capture_output=True, text=True)

12 return result.stdout

D.6 智能体效率

图 29 从四个维度比较了不同编码模式下的效率。Vibe 编码会话的效率始终较低：与协作会话相比，它们消耗的 token 数量大约多出一倍，并且每提交 100 行代码所需的实际时间更长。协作编码在所有指标上实现了最佳权衡，表明人类指导有助于智能体更经济地生成代码。

D.7 智能体回合时长随时间变化

图 30 追踪了智能体回合时长随时间的变化。虽然回合时长中位数保持相对稳定，但自数据收集开始以来，长尾部分有所增长：第 99.9 百分位数现已超过 100 分钟。这一趋势表明，自主智能体运行正逐渐向更长时间段转变。

D.8 监督率随时间变化

在整个数据收集期间（2026 年 1 月至 3 月），智能体主动停止、用户中断和用户回退的比例保持相对稳定。我们在图 31 中使用 7 天滚动窗口，通过回合的平均占比来可视化这一情况。

D.9 开发活动

为了考察智能体行为在不同开发活动中的差异，我们将意图分为代码编写（创建、重构、连接）和代码审查（理解、测试）两类提示词。如图32所示，平均而言，代码编写提示词会触发更长的智能体交互轮次（平均4.1分钟对比2.4分钟），以及更多的文件写入（4%的工具调用是从零创建新文件）和编辑操作（24%的工具调用是编辑现有文件）。此外，编写提示词引发的摩擦也比代码审查提示词更多：智能体停下来提问的频率几乎是后者的三倍（占交互轮次的6.0%对比2.6%），用户打断和反驳的频率也更高（详见第4.4节）。

附录E 数据标注

此处提供最终数据集标注所使用的所有提示词。我们包含了自己设计的标注任务的所有验证细节和提示词。提示词意图任务受[Becker等人，2025]启发，用户画像任务受Wang等人[2026b]启发。

E.1 验证

标注编码手册制定与标注者一致性

为了制定标注编码手册并构建用于测试大语言模型标注性能的数据集，我们针对每个标注任务分三个阶段进行：

1. 首先，两位标注者迭代完善编码手册，直到他们对10个数据点的所有标签达成一致。

2. 其次，同两位人工标注者继续独立标注额外的数据点。我们根据此阶段的结果计算了标注者间一致性指标。表6和表7的结果显示，所有任务的一致性均为中等到较高水平。这包括提示词反驳任务的二值化版本，该版本将除"非反驳"类之外的所有分类类别合并。图33展示了所有任务的完整混淆矩阵。对于会话成功评分，我们讨论了所有人工标注者之间分歧超过20分的情况。

3. 最后，同两位人工标注者讨论了所有分歧，并为每个数据点确定了最合适的黄金标准标签。结合第一阶段中的10个数据点，这为评估大语言模型标注性能提供了黄金标准标签。

我们使用 Cohen's Kappa 来衡量多类别标注任务中人与人之间以及大语言模型与人之间的一致性，并在表 6 中额外报告了百分比一致性 [Cohen, 1960]。会话成功度采用 0–100 分进行标注，因此我们使用双向随机效应、单次测量的组内相关系数（通常称为 ICC(2,1)）来衡量绝对一致性 [Shrout and Fleiss, 1979, McGraw and Wong, 1996]。我们还在表 7 以及图 33–34 中报告了 Spearman 相关系数 [Spearman, 1961]。我们将两位人类标注员的会话成功度评分的平均值作为金标准，用于与大语言模型进行比较。如果人类评分相差 20 分，则人类标注员共同决定最合适的金标准评分。在大语言模型与人类金标准评分的比较中，我们额外使用双向混合效应、单次测量的 ICC（简称为 ICC(3,1)）报告了一致性 [Shrout and Fleiss, 1979]。

对于仓库级别的标注，我们采用了略有不同的方法。具体来说，在第二阶段，人类标注员 2 审阅了标注员 1 设定的 100 个仓库领域和仓库受众标签，并选择同意或覆盖这些标签。

所有标注员均为本文作者。

媒体内容 · 前往原文查看

任务		类别数	标注员数	一致性	Cohen's Kappa
提示词意图	90	7	2	68/90 (75.6%)	0.709
提示词抵触	90	4	2	80/90 (88.9%)	0.832
提示词抵触（二分类）	90	2	2	85/90 (94.4%)	0.888
用户画像	90	4	2	71/90 (78.9%)	0.662

媒体内容 · 前往原文查看

任务		评分范围	标注员数	Spearman 相关系数	ICC(2,1)
会话成功度	90	0–100	2	0.757	0.503

大语言模型标注性能

我们对每个任务测试了 9-11 个大语言模型和 2-4 个提示词改写版本，并对照 100 个人工标注的金标准标签进行了评估。表 8 展示了性能结果，仅列出每个模型-任务组合中表现最佳的提示词。随后我们选择了性能最高的模型。唯一的例外是提示词回推任务，在该任务中我们采用了性能排名第二的模型，因为 qwen-3.5-9b 相比 gpt-5.4-2026-03-05 提供了更好的成本-性能权衡。该任务成本高昂的原因在于上下文规模较大：对于每条提示词回推标注，我们不仅提供用户消息，还提供截至该时刻的完整会话记录（见表 2 和附录 E.2.4）。

图 34 展示了所有任务的完整混淆矩阵。

媒体内容 · 前往原文查看

模型	提示词意图（准确率）	提示词回推（准确率）	回推（二分类）（准确率）	用户画像（准确率）	仓库领域（准确率）	仓库受众（准确率）	会话成功度（ICC(2,1)）
gpt-5.4-2026-03-05	0.69	0.74	0.83	0.69	0.77	0.79	0.56
gpt-5-mini-2025-08-07	0.74	0.64	0.73	0.69	0.75	0.79	0.46
gpt-5-nano-2025-08-07	0.67	0.63	0.69	0.62	0.68	0.79	0.50
claude-opus-4-6	0.70	—	—	0.57	0.81	0.84	—
claude-sonnet-4-6	0.66	—	—	0.46	0.78	0.83	0.60
claude-haiku-4-5-20251001	0.69			0.60	0.72	0.79	0.56
gpt-oss-120b	0.71	0.66	0.74	0.63	0.66	0.75	0.51
gpt-oss-20b	0.73	0.63	0.71	0.59	0.63	0.69	0.49
qwen-3.5-27b	0.76	0.66	0.73	0.61	0.62	0.76	0.52
qwen-3.5-9b	0.72	0.67	0.79	0.60	0.55	0.76	0.47
olmo-3.1-32b	0.59			0.51	0.62	0.69	0.43
	100	100	100	100	100	100	100

E.2 标注提示词

现在我们列出应用于 SWE-chat 数据集的所有基于大语言模型的标注任务。

E.2.1 仓库类型分类器

模型：claude-opus-4-6。

我们将库和开发工具合并为一个称为开发工具的类别，因为人工标注者经常对如何分配存在分歧。

E.2.2 会话画像分类器

模型：gpt-5.4-2026-03-05。参数：。

E.2.3 提示词意图分类器

模型：Qwen/Qwen3.5-27B。我们使用建议的解码参数：

E.2.4 用户抵制分类器

模型：Qwen/Qwen3.5-9B。我们使用建议的解码参数：

E.2.5 会话成功评分

模型：claude-sonnet-4-6。