SWE-Together：在交互式用户会话中评估编码代理

基于真实用户交互会话重建的多轮编码代理评估基准

前置知识

编码代理

编码代理是能够自主完成软件开发任务的AI系统，包括读取代码、运行命令、编辑文件、执行测试等操作。它通过工具调用与环境交互，能够处理复杂的代码库级任务，如bug修复、功能实现等。现代编码代理通常基于大语言模型构建，具备理解代码逻辑、推理问题和生成解决方案的能力。

本文核心就是评估编码代理在真实交互场景中的表现，理解编码代理的能力边界和评估方法对把握论文贡献至关重要，同时编码代理也是当前AI在软件工程领域应用的核心形态

用户模拟器

用户模拟器是基于LLM构建的系统，用于在评估过程中模拟真实用户的行为。它能够根据编码代理的进展和任务状态，决定是否发送反馈、澄清、纠正等消息。与固定脚本不同，状态条件模拟器会根据代理的轨迹动态调整干预时机，同时保持与原始用户意图的一致性。

这是本文的核心创新之一，使多轮交互评估成为可能。理解用户模拟器的工作原理对掌握论文的方法论至关重要，它解决了如何将真实会话转化为可重现评估任务的关键技术挑战

行为完整性评估

行为完整性评估关注代理是否实现了任务要求的功能，而不是其代码是否与参考补丁相似。不同的代理可能用不同的辅助函数、控制流或集成点满足同一请求。评估通过确定性验证器和代理rubric评分器结合，使用冻结的、实现无关的标准来判断完成度。

本文采用的评估方式区别于传统的补丁相似度评估，理解这一点有助于理解为什么reference score不是100%。行为完整性评估更符合实际应用场景，因为不同的正确实现应该都被接受

用户更正指标

用户更正指标量化了编码代理在完成任务过程中需要多少纠正性指导。计算公式为 $\text{UserCorrection} = N_{\text{correction}} + 0.2 N_{\text{nudge}}$，其中correction是明确指出错误的纠正，nudge是暗示或鼓励重新考虑的温和纠正。这个指标独立于任务正确性，衡量交互成本。

本文的关键发现是这个指标与模型能力呈强负相关，表明更强的模型需要更少的用户干预。理解这个指标对把握论文的核心贡献和评估编码代理的用户体验价值至关重要

研究动机

现有的编码代理基准主要采用静态协议：在开始时呈现完整的任务描述，通过运行可执行测试评估代理提交的代码。这种方法推动了编码代理开发的实质性进展，但随着主流编码基准接近饱和，越来越难以区分前沿模型。问题存在两个方面：任务设计和评估。首先，大多数基准将任务构建为固定的单轮指令，而现实世界的编码协助本质上是交互式的——用户往往逐步揭示意图、澄清不完整的请求、细化需求，并在多轮中纠正先前的输出。其次，评估主要测量最终任务成功，但很少捕捉代理如何有效整合不断演变的指令以及需要多少用户努力。两个代理可能获得相同的最终任务分数，但施加的负担却非常不同：一个可能从粗略的初始请求就成功，而另一个可能需要详细规范、反复提醒和大量纠正性反馈。

本文的目标是本文的目标是构建一个能够评估编码代理在真实多轮交互场景中表现的基准。具体来说，SWE-Together旨在：1）从真实的用户-代理编码会话重建可验证的、可重现的软件工程任务；2）开发一个状态条件的LLM用户模拟器，在保持原始用户意图的同时适应每个被评估代理的轨迹；3）设计联合评估协议，同时测量最终仓库正确性和交互轨迹质量，通过User Correction和Intent Coverage等指标表征交互过程。最终目标是推动编码代理评估从单次静态任务测试转向更接近真实用户体验的多轮交互评估。

与已有工作不同的是，本文的独特切入点在于直接从真实的人类-代理编码会话构建基准，而不是从静态问题合成或从GitHub issue人工构建。现有的工作要么提供真实的代码库环境但固定用户请求（如SWE-bench），要么提供用户反馈但交互循环是合成的（如MINT、CodeAssistBench），要么收集真实的编码会话但不提供可重现的任务重放（如SWE-chat）。SWE-Together首次结合了repository-level的agent-environment交互、交互式用户纠正重放和真实任务来源三个要素。通过从11,260个记录的会话中筛选出109个高质量任务，构建了能够验证原始会话意图的可重放多轮交互基准。

核心方法

SWE-Together的核心方法是将记录的多轮编码会话转换为可重现的交互式软件工程任务。方法论包含三个组件：首先，任务构建管道过滤和规范化原始会话，筛选其编码目标是否可以在本地复现，将可行的会话转换为带有固定环境、可执行检查和任务特定用户模拟提示的沙箱化repository-level任务。其次，用户模拟器以轨迹条件的方式重放原始用户意图，仅在满足从记录会话导出的条件时才干预。第三，评估框架分别测量代理最终仓库状态的正确性和重放过程中的用户模拟器行为。正确性通过使用仓库检查和可执行证据的代理rubric评分器评估，而用户模拟器行为通过User Correction和Intent Coverage表征。这三个组件使评估能够同时控制代理完成演变指令的能力以及它从模拟器获得的纠正性指导。

核心创新点是构建一个锚定的、状态条件的LLM用户模拟器，它保留原始用户的意图和干预顺序，同时适应每个被评估代理的演变轨迹。模拟器遵循两个原则：干预是轨迹条件的而不是按计划的，并且锚定到原始会话而不是通用的。它基于最近的代理活动、代理的最新响应、经过的时间、观察到的仓库更改以及其自身先前的决策来做出干预决策。同时，每个任务特定的模拟器都基于从原始用户-代理交互重建的会话分析进行条件化。这避免了两种失败模式：固定重放当被评估代理遵循不同路径时可能错时，而通用模拟可能偏离原始任务。在评估时，这些锚点定义了一个状态条件决策策略：当实时轨迹保证反馈时模拟器说话，否则返回no-op。

方法步骤详情

方法分为三个主要步骤：第一步是会话到任务构建，包含三个阶段：确定性资格筛选使用基于规则的过滤器，要求候选会话必须包含多个真实用户消息、具体代理操作或代码编辑、足够的仓库信号，并筛选出主要由编码代理执行的实质性实现工作的会话；可行性筛选由LLM判断者评估会话中的实质性编码工作是否可以重建为自包含的本地可执行任务，拒绝主要可交付成果依赖于外部状态的会话；任务构造为每个候选启动隔离的沙箱，克隆目标仓库在固定提交，识别本地设置和测试命令，编写任务工件，产生的包包含原始会话记录、初始用户指令、固定的执行环境、确定性验证器工件和任务特定的用户模拟提示。第二步是用户模拟器实现，在每次代理回合完成后，重放过程总结实时轨迹并咨询模拟器一次，模拟器做出结构化决策：发送面向用户的消息或保持沉默。模拟器动作空间包含no-op、question、redirect、new-requirement和check-external。第三步是评估方法，任务正确性评分行为完整性而不是与原始参考补丁的相似性，通过结合确定性验证器和代理rubric评分器，rubric评分器分两个阶段：阶段1每个任务运行一次以导出加权任务rubric，阶段2将相同的rubric应用于每个候选仓库状态。用户模拟器行为通过两个诊断：Intent Coverage审计模拟器对原始用户意图的忠实度，User Correction测量被评估代理引发的纠正性指导。

技术新颖性

技术新颖性体现在多个方面：首先，数据构建方面，从11,260个真实会话中筛选出109个高质量任务，转换率仅0.97%，确保了任务的可验证性和可重现性。其次，用户模拟器采用状态条件策略而非固定脚本，基于实时轨迹条件做出决策，同时通过会话分析锚定到原始用户意图，在适应性和保真度之间取得平衡。第三，评估协议结合了行为完整性和交互诊断，使用冻结的rubric确保跨代理可比性，同时引入User Correction指标量化交互成本。第四，进行了图灵测试风格的用户研究，结果表明人类注释者无法可靠地区分模拟用户和真实用户（Turing通过率46%，95% CI [40.5, 51.6]%），验证了模拟器的真实性。最后，使用了四个不同的上游数据源（DataClaw、Pi-staging、Hyperswitch、SWE-chat），确保了任务的多样性。

**Figure 1**: SWE-Together reframes coding-agent evaluation from one-shot SWE-Bench-style tasks into replayable, multi-turn sessions

**Figure 2**: Overview of the session-to-task construction pipeline

**Figure 3**: Task-construction workflow

**Figure 4**: Context consulted by the user simulator

**Figure 5**: Correctness plus interaction diagnostics

实验结果

在包含109个任务的完整SWE-Together基准上评估了7个前沿模型，使用opencode组件和k=2复制的实验设置。Claude Opus 4.8取得了最强的整体性能，在pass@1（63%）、SSR（59%）、pass2（52%）和mean judge score（0.801）上均领先，同时需要的纠正性指导最少，平均User Correction为1.38。GPT-5.5在mean judge score上排名第二（0.763），pass@1为58%，SSR为55%，pass2为48%；在pass2上更高但在SSR上略低于Claude Opus 4.6。Claude Opus 4.6紧随其后排名第三（mean judge 0.755）。GLM-5.2和GLM-5.1形成下一个梯队：它们的SSR值几乎相同（48%和49%），但GLM-5.2实现了更高的pass@1（55%对52%）和明显更高的pass2（42%对35%），表明跨复制的性能稳定性更高。DeepSeek-V4-Pro和MiniMax-2.7排名最后，MiniMax-2.7在所有四个正确性指标上获得最低值，并且需要最多的纠正性指导。关键发现是User Correction与能力高度相关：在七个模型中，它与pass@1呈强负相关（Pearson -0.92），与stable solve rate（-0.84）和mean judge score（-0.93）也呈负相关。User Correction模型间的变化主要是代理依赖的，作为任务正确性的配套度量。效率方面，GPT-5.5在两个成本轴上都是最有效的队列（每任务29.9k输出token和10.7分钟），同时在能力上排名第二，而opus-4.8以最高token成本（74.0k）但中等wall-clock（23.3分钟）达到顶端。Reference baseline获得mean judge score 0.90，pass率≈78%（73/93），在τ=0.85阈值下评估，在109个任务中有93个可提取参考补丁。

**Table 1**: Upstream sources used to construct SWE-Together

**Table 2**: Results on the full 109-task SWE-Together benchmark using the opencode harness and k = 2 replicates

**Figure 6**: Capability (pass@1 left, stable solve rate right) versus User Correction per trial across the seven models

**Figure 7**: Stable solve rate versus cost for the seven opencode cohorts

查看结构化数据

任务	指标	本文	基线	提升
SWE-Together 109任务评估	pass@1	Claude Opus 4.8: 63%	Reference: ~78%	Claude Opus 4.8达到原始参考补丁准确率的约81%，仍有约15个百分点的提升空间
SWE-Together 109任务评估	Stable Solve Rate (SSR)	Claude Opus 4.8: 59%	Reference: ~78%	Claude Opus 4.8达到原始参考补丁SSR的约76%
SWE-Together 109任务评估	pass2	Claude Opus 4.8: 52%	Reference: ~78%	pass2是最严格的度量，Claude Opus 4.8达到原始参考补丁的约67%
SWE-Together 109任务评估	Mean Judge Score	Claude Opus 4.8: 0.801	Reference: 0.90	Claude Opus 4.8达到原始参考补丁mean judge的约89%
SWE-Together 109任务评估	User Correction (越低越好)	Claude Opus 4.8: 1.38	MiniMax-2.7: 2.17	最强模型比最弱模型需要的纠正性指导少36%，User Correction与能力呈强负相关

局限与改进

作者承认用户模拟器不能在代理回合期间中断编码代理，不能直接编辑文件，并且仅依赖文本轨迹和工具输出而不是来自界面的视觉信息。当前设计在用户目标和约束明确定义时效果最好，专注于具有可测量结果的任务，例如提交的补丁。因此，它对模糊的开放式任务和难以量化的定性用户行为的覆盖有限。我观察到还有一些其他局限性：首先，转换率仅为0.97%（109/11,260），虽然确保了高质量，但也可能限制了任务的多样性和规模；其次，reference baseline的pass率约为78%而非100%，作者解释了三个原因（35%的不满足目标是过程要求、一些参考补丁不完整、少数是真正不完美的人类解决方案），但这仍然可能影响基准的可信度；第三，评估主要关注提交的代码补丁，可能无法捕捉到编码代理在对话解释、推理过程等方面的价值；第四，所有模型使用相同的opencode组件，可能无法充分发挥某些模型的特定优势；第五，wall-clock时间受推理端点的服务位置或基础设施影响，可能不完全反映模型本身的效率。

独立分析的弱点

任务规模偏小，仅109个任务，相比SWE-bench系列（通常数百个任务）可能限制统计显著性和泛化能力，可以通过扩展更多数据源和改进自动化任务构造管道来增加任务数量；转换率过低（0.97%）导致大量原始会话被浪费，虽然这确保了质量，但可以放宽某些筛选条件或改进可行性筛选的LLM判断者来提高利用率；评估维度相对单一，主要关注最终代码正确性和交互成本，可以增加更多维度如代码质量、安全性、可维护性、文档完整性等；用户模拟器的动作空间有限（no-op、question、redirect、new-requirement、check-external），可能无法覆盖所有真实用户行为，可以扩展更多类型的用户干预如示例提供、部分实现、建议等；评估主要在沙箱环境中进行，可能与真实开发环境存在差异，可以增加在真实项目或IDE中的端到端评估；对模型能力的分析相对表面，主要比较最终指标，可以增加更细粒度的分析如不同任务类型的表现、错误模式分析等。

未来方向

作者提出的方向包括扩展任务规模、改进用户模拟器的表达能力、探索更多评估维度。基于成果可以延伸的方向包括：1）多模态交互评估，当前模拟器仅依赖文本，可以增加视觉信息如界面截图、图表等；2）多代理协作评估，评估多个编码代理之间的协作能力；3）长期项目跟踪，评估代理在长期项目中的持续贡献能力；4）领域专门化评估，针对特定领域如Web开发、数据科学、系统编程等构建专门化基准；5）用户个性化模拟，根据不同用户风格和偏好调整模拟器行为；6）跨语言评估，扩展更多编程语言的评估任务；7）教学能力评估，除了完成任务，评估代理解释、教学、知识传递的能力；8）错误恢复评估，专门测试代理在遇到错误时的诊断和恢复能力；9）可解释性评估，评估代理的决策过程和推理的可解释性；10）人机协同工作流，评估代理在真实开发工作流中的集成效果。

复现评估

论文提供了代码链接（https://github.com/Togetherbench/SWE-Together）和网站（https://togetherbench.com），表明作者致力于开源和可重现性。评估使用了固定的rubric和确定性验证器，确保跨代理的可比性。实验使用k=2复制来评估稳定性，这提供了可靠性保证。但是，论文没有详细报告硬件配置、具体的超参数设置、随机种子等复现细节。用户模拟器和rubric评分器的提示词没有在论文中完整披露，可能影响独立复现。计算资源方面，评估7个模型在109个任务上每个任务运行2次，总共需要1526次评估运行，如果每次运行需要几十分钟（wall-clock时间在10-38分钟之间），总计算量相当可观，复现可能需要显著的资源投入。数据方面，虽然基准是公开的，但上游数据源（DataClaw、Pi-staging、Hyperswitch、SWE-chat）的获取和使用可能需要特定的许可或访问权限。总体而言，项目具有较好的开源基础，但完全复现仍需要较多的资源和对细节的进一步披露。

SWE-Together：在交互式用户会话中评估编码代理 SWE-Together: Evaluating Coding Agents in Interactive User Sessions