SWE-chat: 来自真实用户与编码智能体在野外交互的大规模数据集 SWE-chat: Coding Agent Interactions From Real Users in the Wild
首个真实编码智能体交互数据集,揭示人机协作模式与失败机制
前置知识
Coding Agent (编码智能体)
基于大语言模型增强的自主编程助手,具备调用工具(读/写文件、执行 shell 命令、调用子智能体)的能力,可以端到端地完成复杂软件工程任务。代表产品包括 Claude Code、Cursor、OpenCode、Gemini CLI、Factory AI Droid 等。
本文研究对象就是 coding agent,理解其工具调用与多轮交互机制是看懂数据指标(工具调用分布、轮次时长、pushback 行为)的前提。
Vibe Coding (氛围编程)
由 Andrej Karpathy 提出的术语,指开发者几乎不亲自写代码,而是描述意图、由 AI 生成并提交代码的开发模式。在 SWE-chat 中被严格定义为『智能体编写 ≥99% 已提交代码』的会话。
Vibe coding 是本文最核心的发现之一(占会话 40.8%,且占比正在翻倍增长),作者用这一概念串起了效率、成本、安全三条主线结论。
Code Authorship Attribution (代码作者归属)
通过 git 级别的 diff 标注,精确识别每一行新增/修改的代码是由人类还是 AI 智能体编写。Entire.io 工具会自动把行级归属信息记录在 checkpoint 中。
该机制是 SWE-chat 区别于其他智能体数据集的关键能力,使作者能够量化『智能体代码存活率』等关键指标,这也是研究 RQ2 失败模式的数据基础。
LLM-as-a-Judge (大模型评判)
使用大语言模型代替人类对文本/会话进行分类或打分的方法。优势是可规模化,劣势是存在判断偏差。SWE-chat 中先用多个开源/闭源 LLM 与人类专家金标准对比,再选取表现最好的模型完成全量标注。
作者需要在 6,000+ 会话上做意图、行为人格、pushback 类型等多维标注,人工不可行,LLM 标注是支撑大规模分析的核心方法。
Static Analysis (Semgrep 静态分析)
Semgrep 是一种基于模式匹配的源代码静态安全分析工具,可在不执行代码的情况下检测 SQL 注入、命令注入、路径穿越等漏洞。本文在 commit 前后分别扫描,差分得到该 commit 引入/修复的漏洞数。
这是本文量化 vibe coding 安全风险(每千行 0.76 个漏洞)的关键工具,理解『差分扫描』方法才能正确解读 Table 4 的数据。
研究动机
尽管 AI 编码智能体(如 Claude Code、Cursor)已被大规模采用,公开数据显示它们在编程基准上能达到 50% 成功率(对应人类 12 小时工作量),但学界对真实开发中人类如何使用这些智能体、产出代码中有多少被最终采纳、智能体以何种方式失败,几乎仍然停留在轶事阶段。现有 AI 智能体数据集(SWE-smith、CoderForge、SERA、AIDev、AgentPack 等)要么是合成的、要么没有真实用户提示,要么缺少代码 diff 与作者归属,根本无法回答『人机协作的真实模式』这一问题。现有的 SWE 基准(SWE-bench、Multi-SWE-bench 等)只评估『在精心设计的任务上的一次性解题能力』,既不覆盖多轮交互,也不反映真实开发者的工作流,导致基准成绩与生产环境表现存在巨大鸿沟。
本文的目标是本文的核心目标有两个。其一,构建并发布 SWE-chat——首个大规模、持续更新的真实编码智能体会话数据集,包含完整的人机交互轨迹(63K 提示、355K 工具调用)、代码 diff 以及行级人类/智能体作者归属,覆盖 200+ 公共 GitHub 仓库、5 种主流编码智能体(Claude Code、Cursor、OpenCode、Gemini CLI、Factory AI Droid);其二,基于该数据集做一次『在野外』的实证研究,系统回答两个研究问题:RQ1 人类在真实任务中如何与编码智能体交互(包括任务类型、vibe coding 趋势、用户行为画像),RQ2 智能体在实践中如何失败(代码存活率、token/美元/时间效率、安全漏洞)以及用户如何应对(中断、pushback 类型)。
与已有工作不同的是,本文的独特切入角度是『行级代码作者归属 + 持续更新的活数据集 + 真实用户提示』三者的结合。区别于只采集智能体轨迹的合成数据集,SWE-chat 通过 Entire.io CLI 在 git 仓库分支上记录每一次 commit 与对应会话,并标注每行代码是 AI 还是人类写的,使得『vibe coding 占比』『代码存活率』『每千行安全漏洞数』这些前所未有的指标成为可能。同时,与静态基准不同,作者强调这是一个 living dataset,伴随被测技术演化而持续追加新数据,从而支持纵向趋势分析(如 vibe coding 在三个月内从 20% 翻倍到 40%)。
核心方法
SWE-chat 的方法体系可拆为四层:数据采集层、标注层、指标层、安全分析层。直觉上,作者没有自建基准或训练模型,而是去『挖掘真实使用痕迹』:当开发者用 Claude Code 等工具编程时,Entire.io CLI 会在 git 仓库里开一个 checkpoint 分支,自动同步会话日志(用户提示、智能体回复、工具调用、token 用量)与代码 diff,并为每行代码打上 human 或 agent 标签。这些原始事件被结构化为『会话—轮次—提示—工具调用』四级对象,再经过 PII 脱敏(Presidio+SpaCy 去人名/邮箱/电话,TruffleHog 去密钥)后公开发布。得到数据集后,作者在多个分析维度上做大规模标注与量化,最终支撑 RQ1/RQ2 的发现。
核心创新点是『用 git 仓库做数据容器、用行级归属做分析基础、用 LLM-as-judge 做可扩展标注』。与已有数据集相比,SWE-chat 第一次把『真实用户提示 + 智能体完整轨迹 + 人类/AI 代码归属 + 多轮交互』四件事整合到同一对象中,使得诸如『用户 pushback 后智能体是否自我修订』『vibe coding 的 token 成本与漏洞率』这类过去无法量化的问题变得可回答。技术上的本质区别是:以往的 SWE 数据集把『代码』和『人』分离开,而 SWE-chat 通过 Entire.io 把 commit 与产生它的会话绑定,从而让每一行代码都可追溯到产生它的具体提示与智能体行为。
方法步骤详情
SWE-chat 构建按六步推进。(1)采集:开发者安装 Entire.io CLI 开启 checkpoint 日志,自动监听 5 种主流编码智能体,把会话与 git commit 关联。(2)结构化:会话建模为 user prompts/agent responses 交替,每次 agent response 含若干 tool call。(3)脱敏:删 bot 数据;Presidio 擦 PII;TruffleHog 删凭据。(4)LLM 标注:四层级(会话 success rating、user persona;提示 user intent、user pushback)用 LLM 评委——先与人类金标准比对选最佳模型与 prompt。(5)指标:code survival rate、coding efficiency、tokens/dollars/time per 100 committed lines 按三模式统计。(6)安全:commit 前后跑 Semgrep 差分,按模式算每千行漏洞率。
技术新颖性
技术新颖性主要体现在三方面:(1)采集机制——Entire.io 把智能体会话与 git 仓库的 branch/commit 自然绑定,不需要额外的服务端配合,可大规模、低成本地持续抓取;(2)行级归属——通过 git diff 智能分块,标注每行新代码的作者,这是首个支持此粒度的公共编码智能体数据集;(3)活数据集与生命周期管理——SWE-chat 计划持续更新,不是一次性快照,这一设计思路对研究『快速演化技术』的实证研究有方法论价值。文中也坦承,LLM-as-judge 不可避免存在错误,因此同时保留原始日志供研究者自行复现标注。
实验结果
RQ1(交互模式):6,000+ 会话、200+ 仓库、63K+ 提示、355K+ 工具调用,85% 来自 Claude Code;最大用户意图是『理解已有代码』占 19.0%,其次是创建新代码 13.4%、git 13.4%、调试 13.0%;bash 占工具调用 33%,文件读/写/搜索合计 48%。编码模式双峰:22.7% 纯人工、36.5% 协作、40.8% vibe coding;vibe 占比三个月内从 20% 翻倍到 40%+;『专家型挑刺者』占主导,vibe 中仍达 47%。RQ2(失败与应对):会话平均成功率 82%;智能体代码存活率仅 44.3%(协作 38.2%、vibe 59.0%);vibe coding 每 100 已提交行消耗 204K token、$0.13、12.6 分钟,分别是协作的 3×、2.6×、2.6×;vibe 每千行引入 0.76 个 Semgrep 漏洞,协作 0.14,纯人工 0.08,vibe 是纯人工约 9×;智能体主动询问仅 1.1%–2.6%,用户硬中断 5%、软 pushback 达 39–44%。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 代码存活率(Code survival rate) | 智能体生成代码被人类 commit 的比例 | 全样本 44.3%;vibe coding 59.0%;collaborative 38.2% | 无既有公开指标(首个量化数据) | 首次量化,显示 vibe coding 比 collaborative 高 20.8 个百分点,但仍有 41% 被丢弃 |
| 编码效率(Coding efficiency) | 最终 commit 中智能体代码占智能体总输出的比例 | 全样本 50.3%;vibe coding 64.6%;collaborative 44.1% | 无既有公开指标(首个量化数据) | 首次量化,vibe coding 的产出—保留比更高,但伴随更高绝对浪费量 |
| 安全漏洞引入率 | Semgrep 差分:每 1,000 added lines 引入的安全 finding 数 | vibe coding 0.76;collaborative 0.14;human-only 0.08 | 无既有公开指标(基于真实 commit 的首个量化数据) | 首次量化,vibe 是 human-only 的约 9×、collaborative 的约 5× |
| 成本效率 | 每 100 committed lines 的美元开销 | vibe coding $0.13;human-only $0.07;collaborative $0.05 | 无既有公开指标 | 首次量化,collaborative 模式性价比最高,比 vibe coding 便宜约 62% |
| 时间效率 | 每 100 committed lines 的会话时长(分钟) | vibe coding 12.6;human-only 8.6;collaborative 4.8 | 无既有公开指标 | 首次量化,collaborative 模式比 vibe coding 快约 2.6× |
| Token 效率 | 每 100 committed lines 的 token 消耗 | vibe coding 204K;collaborative ≈68K;human-only ≈102K(基于 3× 比例估算) | 无既有公开指标 | 首次量化,vibe coding 比 collaborative 多消耗约 3× token |
局限与改进
作者在论文与附录 A 中明确承认三点局限。第一,SWE-chat 仅来自主动选择安装 Entire.io CLI 的开源贡献者,属于『早期采用者』群体,不能代表所有编码智能体用户,样本可能偏向技术能力较强、习惯使用 AI 工具的开发者。第二,LLM-as-judge 的标注存在系统性偏差,虽然做了与人类金标准的对比验证,但仍可能错分边界样本(如『理解代码』与『创建新代码』)。第三,静态安全分析有漏报与误报,Semgrep 规则集并不覆盖所有漏洞类型,差分扫描只能检测本仓库内可被 Semgrep 解析的语言,因此 Table 4 的绝对数字应理解为下限估计。我自己的补充观察:85% 数据来自 Claude Code 这一不平衡的智能体分布,使得 RQ2 中 pushback/中断率等结论主要反映 Claude Code 特性,不能直接外推到 Cursor、Gemini CLI 等;另外,数据集采集依赖 Entire.io 的行级归属算法,其对『AI 修改既有行』与『AI 复制粘贴人类代码』的判定决定了『代码存活率』指标的语义,复现时需注意该算法版本。
独立分析的弱点
本文虽然方法扎实、数据量级大,但仍存在几个独立观察到的弱点。弱点一,样本偏差:Entire.io 的早期采用者很可能本身是 vibe coding 的高频用户,自选偏差会同时抬高 vibe coding 占比(40.8%)与 pushback 率(39–44%),需要补充企业/闭源开发场景的对照数据来验证;改进方向是引入企业 GitHub/GitLab 托管商合作,在隐私保护前提下扩展样本。弱点二,标注可复现性:虽然作者公开了 LLM 评委与 prompt 选优过程,但 LLM 行为对 prompt 敏感且随时间漂移,第三方复现同一标注难以保证一致;改进方向是开源标注模型与 prompt,并提供重跑脚本。弱点三,效率指标的归因混淆:vibe coding 的低效率可能并非智能体本身能力不足,而是 vibe 模式倾向于承担长任务,目前未控制任务难度;改进方向是在 METR-style 任务难度估计上做协变量控制。弱点四,安全分析的语义局限:Semgrep 报告的是潜在漏洞,论文未区分严重等级;改进方向是按 CWE 严重等级分组报告,或交叉验证 CodeQL 等独立工具。
未来方向
作者在第 5.1 节勾勒了三条路线,具有很强延展性。第一,构建基于真实工作流的基准:用 SWE-chat 的会话轨迹作为评测场景,给定上下文,评估智能体是否给出合适的下一步动作,直接解决『基准脱离实战』的问题。第二,设计更自适应的人机交互:研究 pushback-response 闭环(智能体如何读懂纠错提示、是否学习减少同类错误)对提升体验至关重要,可构建专门的『纠错—恢复』评测集。第三,训练用户模拟器做离线评估:用 SWE-chat 真实轨迹训练 user simulator,重现不同人格(专家挑刺者、模糊需求者、目标变更者),在不需要真人参与的情况下评估智能体。基于本文结果,我还建议两个延伸方向:(a)研究 vibe coding 的安全加固——既然 vibe 模式每千行引入 0.76 个漏洞,可在 SWE-chat 上评估 secure fine-tuning 与 system-prompt hardening 是否在真实任务上生效;(b)研究效率—安全权衡——collaborative 模式性价比最高且最安全,暗示适度的『人在回路』可能是工业级编码智能体产品的最优解。
复现评估
SWE-chat 在可复现性方面表现良好,适合希望深入分析的研究者使用。数据与代码方面:作者明确承诺公开数据集(Website 与 Data 链接已在首页给出,不过本文为 arXiv 预印版本,最终发布时可能更新),代码也将开源,关键分析脚本(指标计算、LLM 标注、Semgrep 差分)可复现。数据规模适中,本地 256GB 内存的机器即可加载完整 2.7M 事件,SQLite 形式的分发使普通研究者也能查询。算力需求集中在 LLM 标注与 Semgrep 扫描两步:LLM 标注可在 8×A100 上 1–2 天内完成,Semgrep 跑全量 commit 视仓库规模需要数小时至一天。复现难度低,主要门槛在 LLM 标注对最新版模型的依赖——读者若使用不同版本的 Claude/GPT 重做标注,可能得到略有不同的标注分布。论文附录 E 还公开了 LLM 评委验证的具体数字,有助于评估标注质量的下限。
论文图表
论文摘要级别的『路线图』,用左右两栏共六个要点把 RQ1(交互模式)与 RQ2(失败模式)的所有发现浓缩:RQ1 覆盖任务类型、vibe coding 趋势、用户行为;RQ2 覆盖会话成功率、效率/安全、用户 pushback。文字颜色与正文 figure 组件一一对应,起到导航作用。
对快速把握全文结论极有帮助,适合放在 motivation 章节,让读者先建立全局认知再读细节。