SWE-INTERACT：将SWE基准重新构想为用户驱动的长期编码会话 SWE-INTERACT: Reimagining SWE Benchmarks as User-Driven Long-Horizon Coding Sessions
首个模拟真实开发者工作流的多轮交互式编程代理评估基准
前置知识
SWE基准
软件工程基准是一套用于评估AI编程代理能力的标准化测试任务。通常包括一个预定义的问题描述、一个包含依赖项的Docker环境以及一个用于验证解决方案正确性的评估套件。传统的SWE基准如SWE-bench、SWE Atlas等都是单轮任务，即在开始时提供完整的需求规格说明，代理需要自主完成实现，然后通过单元测试或评分标准来评估正确性。
理解SWE基准的工作原理是读懂本文的基础，因为SWE-INTERACT正是对这些传统基准的创新性重构，将单轮自主实现任务转换为多轮交互式开发者工作流程。
用户模拟器
用户模拟器是一个由LLM驱动的模拟实体，用于在多轮交互评估中扮演人类用户的角色。它不仅仅是静态的API调用，而是具有特定角色、任务目标和工具调用能力的动态代理。在SWE-INTERACT中，用户模拟器基于真实编码会话数据构建，具有检查代理工作区、执行shell命令、渐进式揭示需求并提供针对性反馈的能力。它独立于最终验证器运行，确保评估的客观性。
用户模拟器是本文的核心创新，理解其设计和工作原理对于掌握SWE-INTERACT的评估方法论至关重要。它突破了传统简单、静态的用户模拟限制，提供了更真实的交互环境。
目标发现
目标发现是指代理在初始指令模糊或不完整的情况下，通过与用户的多轮交互，逐步识别、理解并最终实现完整任务目标的过程。SWE-INTERACT通过将原始任务指令分解为可独立验证的子目标来量化评估这一能力。评估模型会检查代理的初始计划和每个实现检查点，计算它们相对于完整任务目标集的覆盖率，从而提供从规划到实现的完整生命周期视图。
目标发现是多轮交互式编程的核心挑战，也是本文重点分析的能力维度。理解这一概念有助于深入解读论文关于代理在模糊初始条件下表现差异的实验结果。
研究动机
现有前沿SWE基准普遍采用单轮、完全预先指定的任务设置，即一次性提供所有需求和接口细节，评估代理的自主实现能力。然而，大规模真实编码会话分析显示，这种设置与实际开发者-代理工作流程存在显著差异。大多数真实任务并非一次性自主实现，而是从简短、不完整或模糊的初始指令开始，开发者会在审查代理实现时逐步提供批评、纠正、修订或改变需求。现有包含用户循环的SWE基准也往往从合理详细、规格明确的初始提示开始，这大大简化了代理的任务，测试重点仅是代理是否意识到需要从用户处收集某些缺失细节，而不是理解任务目标、澄清歧义、修订实现并随着新指令的到来构建自己先前的工作。
本文的目标是本文旨在创建一个测试平台，研究编码代理在多轮循环中与开发者协作的能力，使其能够从高层次的任务模糊描述开始，并在用户检查其工作并揭示更多信息时逐步改进其实现。具体目标是构建75个多轮任务，涵盖从流行SWE基准选择的复杂任务，开发一个能够模拟真实用户的交互式用户代理框架，并提供详细的代理能力分析，包括失败模式、轨迹分析和演变过程。
与已有工作不同的是，本文的独特切入角度在于将评估难度从任务复杂性重新构建为交互性。传统SWE基准通过增加任务复杂性和范围来提高难度，而SWE-INTERACT保持任务本身不变，但将需求揭示过程从一次性完整规格说明转换为渐进式、用户驱动的多轮交互。这种转换测试了一个正交的、现实世界的能力维度：交互式目标发现和与用户在循环中的迭代细化，而不仅仅是更长时间的自主编码。此外，本文将用户模拟器设计作为基准的一等公民，基于大规模真实编码会话数据构建，而非采用通用的、非协作的静态用户模型。
核心方法
SWE-INTERACT方法整体思路是将传统单轮SWE基准任务转换为多轮、用户驱动的交互式开发者工作流程。核心直觉是：真实的软件开发不是从完整规格说明到最终实现的线性过程，而是一个迭代循环，其中用户从模糊的初始描述开始，逐步揭示需求，检查实现，并提供反馈和修订。技术路线包括：从三个前沿SWE基准（SWE-bench Pro、SWE Atlas Refactoring、DeepSWE）各选择25个复杂任务，总共75个；为每个任务构建基于真实用户数据的用户模拟器，包含任务目标、用户角色和用户代理工具线束；在Harbor框架的容器化沙箱中执行任务，代理使用ask_user工具与模拟器交互；最终使用原始任务的验证器评估解决方案正确性。
核心创新点在于将SWE基准从一次性实现任务重新构想为交互式开发者工作流程，并通过角色驱动的动态用户模拟器实现。与已有方法的本质区别在于：传统基准将所有需求预先完全指定，评估重点在于实现能力；而SWE-INTERACT让需求保持潜在状态，通过角色条件化的用户模拟器渐进式揭示，评估重点在于目标发现、需求整合和跨轮次正确性保持。用户模拟器不是简单的静态LLM调用，而是具有工作区感知能力的动态代理，可以使用git、grep、sed、find等工具检查代理的变更并提供针对性反馈。这种设计确保了测试的是代理与用户协作的能力，而不仅仅是实现能力。
方法步骤详情
方法步骤的完整描述如下：第一步是任务选择和转换，从SWE-bench Pro、SWE Atlas（重构）和DeepSWE三个基准各选择25个具有复杂指令和分层需求的任务，将每个原始任务（包含完整的问题指令、Docker环境和验证套件）转换为多轮用户驱动任务。第二步是用户模拟器构建，包含三个模块：任务目标（从原始任务派生的完整问题指令和接口规格）、用户角色（基于SWE-chat数据集中数千条真实用户消息分析的Expert Nitpicker角色）和用户代理工具线束（具有shell访问代理工作区能力的工具调用框架，可以使用git、grep、sed、find等命令）。第三步是任务执行，所有任务在Harbor框架中执行，该框架在Modal上启动容器化沙箱，安装代理，并为其提供MCP托管的ask_user工具。在任务开始时，用户给代理一个简短概述，然后与代理迭代工作，检查其实现，并逐一引入额外需求，直到所有任务指令都已移交。代理被指示提交其初始计划和每个基于用户反馈的实现修订，以及最终测试补丁。一旦代理提交，Harbor在代理的最终解决方案上运行验证器并使用原始任务的评分设置对任务进行评分。第四步是目标发现评估，通过GPT 5.5将完整任务指令分解为可独立检查的具体子目标评分标准项，然后使用Sonnet 4.6高推理模型对代理保存的PLAN.md和每个实现检查点进行评分，给出从规划到实现的完整生命周期视图。
技术新颖性
技术新颖性体现在多个方面。首先，用户模拟器设计基于大规模真实编码会话数据（SWE-chat），采用最频繁的Expert Nitpicker角色和vibecoding交互模式，而非通用的或任意设计的用户角色。其次，用户模拟器具有工作区感知能力，可以使用工具检查代理的变更、搜索代码库、运行命令并提供针对性反馈，这是对传统静态LLM调用用户模拟器的重大改进。第三，评估设计遵循近期多轮代理评估文献的保守教训：模拟器是验证器盲的、角色条件化的、基于任务目标和代理工作空间的，确保了测试的真实性和客观性。第四，评估使用原始任务的验证器进行最终成功判断，而不仅仅是模拟器批准，这允许我们隔离当代理必须通过交互式开发者工作流程时，相同的实现任务会变得多困难。最后，方法提供了详细的失败模式分析和目标发现生命周期评估，而不仅仅是最终的解决率。
实验结果
核心发现显示，强劲的单轮自主编码性能在需求由用户在长轨迹中逐步揭示的相同任务设置下，并不能可靠地转移到多轮设置。Table 1显示，所有模型在多轮设置中的得分都低于其单轮基线，同时使用更多步骤、 substantially更多令牌和更高的每次试验成本。最佳模型在单轮版本的任务上达到约50%的解决率，但在多轮设置中下降到约25-27%。多轮任务轨迹使用显著更多的步骤，通常是其单轮基线的3-4倍。具体来看，GPT 5.5从单轮的48.0%下降到多轮的24.7%（下降23.3个百分点），步骤从108.6增加到424.8（3.9倍），令牌从0.14M增加到0.36M（2.6倍），成本从$2.78增加到$9.84（3.5倍）。Opus 4.8从50.7%下降到26.7%（下降24.0个百分点），步骤从56.1增加到180.9（3.2倍），令牌从0.17M增加到0.35M（2.1倍），成本从$5.09增加到$11.80（2.3倍）。Figure 3显示，试验平均约7个用户消息，平均每个试验约40个用户工具调用来探索代理的工作区并检查变更。最长轨迹有27个用户消息，用户对代理工作区进行了332次工具调用，代理超过1000步完成。目标发现分析显示，最佳模型在给定模糊初始描述时开始强劲，一些模型在规划期间就识别出大量潜在目标（>80%）。然而，几乎所有模型从其计划分数下降到第一个实现检查点。在用户反馈后，大多数模型在实现生命周期中恢复目标覆盖率。虽然GPT 5.5、Opus 4.8和Sonnet 4.6最终平均解决了>90%的任务目标，但Gemini 3.5 Flash得分较低，Kimi K2.6显著不足。值得注意的是，目标发现不等于准确的任务实现。几乎所有验证器正确的解决方案都有近乎完美的目标发现分数（90%+），但反之不成立，代理在发现所有任务目标后仍然失败。失败模式分析显示，287个失败轨迹中最频繁的标签是技术实现漏洞和遗忘需求，各约占分配语义标签的三分之一。误解/错误假设约占标签的14%，而缺失用户需求约占12%。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 单轮SWE基准 | 解决率 | N/A | 48.0-50.7% (GPT 5.5/Opus 4.8) | 基准对比 |
| 多轮SWE-INTERACT | 解决率 | 24.7-26.7% (GPT 5.5/Opus 4.8) | 48.0-50.7% (单轮基线) | 下降23.3-24.0个百分点 |
| 多轮SWE-INTERACT | 步骤数 | 180.9-424.8 (Opus 4.8/GPT 5.5) | 56.1-108.6 (单轮基线) | 增加3.2-3.9倍 |
| 多轮SWE-INTERACT | 令牌数 | 0.35-0.36M (Opus 4.8/GPT 5.5) | 0.14-0.17M (单轮基线) | 增加2.1-2.6倍 |
| 多轮SWE-INTERACT | 成本 | $9.84-$11.80 (GPT 5.5/Opus 4.8) | $2.78-$5.09 (单轮基线) | 增加2.3-3.5倍 |
局限与改进
局限性分析包括作者承认的和我们观察到的几个方面。作者指出，当前版本的用户模拟器在工具能力上有限，仅限于git、grep、sed、find等命令，未来工作可以探索用户可以修改代码、运行测试和采取其他行动的设置。此外，当前研究仅聚焦于一种用户角色（Expert Nitpicker）和一种交互模式（vibecoding），这是基于真实数据分析的最频繁设置，但未来的工作可以扩展到更多样化的用户角色和交互模式。我们还观察到，基准任务规模相对较小（75个任务），虽然涵盖了三个不同的SWE基准，但可能不足以代表全部软件工程任务的多样性。此外，用户模拟器模型的选择（GPT 5.5 vs Opus 4.7）对评估结果有显著影响，Table 3显示使用GPT 5.5作为用户模拟器时，代理轨迹通常在代理步骤和代理用户交互方面要长得多（1.5-2倍），这引入了评估结果的不确定性。最后，虽然作者声称模拟器是验证器盲的，但缺失用户需求失败模式（约占12%的标签）表明，模拟器有时未能提供必要的需求，这可能是基准的假阴性，识别了模拟器鲁棒性差距。
独立分析的弱点
独立分析的弱点包括几个具体场景和改进方向。首先，用户角色多样性不足是一个显著弱点。虽然Expert Nitpicker是最频繁的真实用户角色，但实际软件开发中存在多种用户角色（如新手开发者、产品经理、测试工程师等），他们的沟通风格、期望和反馈模式各不相同。改进方向是扩展到更多样化的用户角色，包括不同技术背景、沟通偏好和协作风格的用户，以更全面地评估代理的适应能力。其次，工具调用能力有限是另一个弱点。当前用户模拟器只能读取文件和搜索代码库，不能修改代码或运行测试，这限制了其提供更精确反馈的能力。改进方向是扩展工具调用能力，允许用户模拟器运行测试、应用补丁、提供代码示例等操作。第三，评估维度相对单一也是一个弱点。虽然SWE-INTERACT评估了最终解决率，但对于交互质量、沟通效率、需求理解准确性等中间过程的评估较少。改进方向是增加更多维度的评估指标，如用户满意度、沟通清晰度、需求覆盖率等。第四，任务类型相对集中也是一个弱点。当前任务主要来自三个SWE基准，可能不能覆盖所有类型的软件开发任务。改进方向是扩展任务类型，包括需求分析、架构设计、代码审查、调试、重构等不同阶段和类型的任务。
未来方向
未来研究方向可以从作者提出的和基于成果可延伸的方向展开。作者提出未来工作可以扩展到更多样化的用户角色和交互模式，探索用户可以修改代码、运行测试和采取其他行动的设置。基于成果可以延伸的方向包括：一是研究多代理协作场景，多个编码代理与多个用户在复杂软件开发任务中的协作模式和能力要求；二是探索支持任务和长期维护场景，评估代理在需求持续变化、代码需要长期维护的环境中的表现；三是开发更细粒度的评估框架，不仅评估最终解决率，还评估交互质量、沟通效率、需求理解准确性等中间过程指标；四是研究个性化和适应性用户模拟器，根据代理的表现动态调整用户角色和交互策略；五是探索跨文化和跨语言的用户模拟器，评估代理在不同文化和语言背景下的协作能力；六是开发更高效的用户模拟器，减少评估成本和时间；七是研究代理在多轮交互中的学习和适应能力，评估代理是否能够从用户反馈中学习并改进后续交互；八是探索真实用户与模拟用户的差异，通过对比研究验证模拟器的真实性和有效性。
复现评估
复现评估需要考虑多个方面。开源情况方面，论文提供了GitHub仓库（https://github.com/scaleapi/SWE-Interact），但未明确说明是否开源了完整的用户模拟器代码、任务转换脚本和评估框架。数据方面，论文使用了来自SWE-bench Pro、SWE Atlas（重构）和DeepSWE的75个任务，这些原始基准是公开的，但任务转换的详细过程和人工选择标准可能不完全透明。用户角色指令基于SWE-chat数据集，该数据集是否公开未明确说明。算力方面，评估需要在Modal上运行容器化沙箱，需要使用Harbor框架，这可能需要特定的基础设施和配置。评估成本高昂，多轮运行使用高推理设置的前沿模型，每次试验成本从$6.10到$11.80不等，完整评估可能需要数千美元。难度方面，完整复现评估需要理解用户模拟器设计、任务转换过程、Harbor框架使用等多个技术细节，且需要访问专有API（如GPT 5.5、Opus 4.8等）和特定的基础设施，这对普通研究者的复现能力提出了挑战。此外，用户模拟器模型的选择对结果有显著影响，不同的模拟器模型可能导致不同的评估结果，这增加了复现的不确定性。
论文图表
