SWE-Touch：用户触碰代码场景下编码智能体基准评测 SWE-Touch: Benchmarking Coding Agents When Users Touch the Code
SWE-Touch 注入用户冲突编辑评测编码智能体共享工作空间的鲁棒性。
前置知识
SWE-bench（仓库级修复任务）
SWE-bench 把修复真实开源项目的 issue 做成端到端任务：给定初始代码库 $R^0_i$、问题描述 $q_i$ 和验证器 $V_i$（含 fail-to-pass 与 pass-to-pass 测试）。智能体执行读/编辑/测试轨迹 $\tau$ 得到最终仓库 $R^\tau_i$，当 $V_i(R^\tau_i)=1$（原先失败的测试全通过、原先通过的仍通过）即算解决。
本文所有任务、指标（resolve rate）以及验证条件式(3)都建立在这个框架之上，不熟悉它就无法理解评测设定。
编码智能体与轨迹
编码智能体通过 shell 接口对仓库执行一系列动作 $a_t$（读/编辑/测试）并观察输出 $o_t$，形成轨迹 $\tau=((a_1,o_1),\dots,(a_T,o_T))$，其动作作用域记为 Scope($a_t$)。SWE-Touch 正是监控这条轨迹、在动作作用域与编辑区域 $U_i$ 行重叠时注入用户编辑。
理解区域触发投递规则、以及基于轨迹历史 $H_t$ 生成上下文消息 $m_j$ 的机制，都需要先掌握轨迹这一基本表示。
反向编辑与共享工作空间
共享工作空间指用户与智能体操作同一仓库与可执行状态。反向编辑 $p^-_i$ 是与任务冲突但局部合理的统一 diff，经三条件验证：$V_{F_i}(R^-_i)=0$（单独不解）、$V_{F_i}(R^*_i)=1$（参考补丁可解）、$V_{F_i}(R^{-*}_i)=0$（合用仍失败），从而迫使智能体调和冲突。
这是全文核心机制，不理解它就无法理解评测设定、Co-Edit 对照以及所有结果解读。
统一 diff 与补丁操作
统一 diff 描述对源文件的增删改并作为补丁作用于代码库。文中 Apply($R,p$) 表示把补丁 $p$ 作用到 $R$，Compose($R,p_1,p_2$) 表示顺序作用两个补丁；$R^-_i$、$R^*_i$、$R^{-*}_i$ 分别对应单独应用反向编辑、参考修复、两者合用后的仓库。
方法的补丁构造、验证与运行时投递都基于补丁操作，读懂式(3)(4)与验证流程的前提是补丁概念。
解决率与保留率
resolve rate 是通过完整验证器 $V_i$ 的任务百分比；retention 是在 Vanilla（自主）下多数解决的任务中、在 Counter-Edit 下仍多数解决的比例；二者结合分别刻画绝对性能与抗干扰稳定性。
论文几乎所有表格都用这两个指标，是读懂主结果表3、长程结果表4和各消融结论的钥匙。
研究动机
现有编码智能体基准（如 SWE-Bench、Terminal-Bench）几乎都采用静态设定：智能体拿到任务描述与初始代码库后独自完成修复，再用可执行测试对最终仓库状态打分。较新的交互式基准（Ambig-SWE、HiL-Bench、SWE-Interact、SWE-Together）虽引入多轮对话，但用户影响完全通过自然语言消息传递，并未触及一种更真实的交互形态——用户在任务进行中直接改动智能体赖以工作的可执行代码库。作者对 SWE-chat 数据的分析显示，59.0% 的真实会话存在归因于用户的代码库变更，说明动手改代码是与消息并列的重要交互通道。然而当时没有任何基准评测：当用户在共享工作空间改动代码时，智能体能否感知、理解并正确应对这一变化。
本文的目标是本文目标是构建一个可控、可复现的评测框架，专门用来压力测试共享工作空间场景下编码智能体的状态感知与适应能力。作者设计反向编辑（Counter-Edit）机制：注入一处与任务相关、局部合理、却与任务完成相冲突的代码编辑，迫使智能体检查改动后的代码并调和冲突，而非默认某一方一定正确。SWE-Touch 旨在回答中心问题——编码智能体如何理解并响应对共享代码库的修改——并把对演变中工作空间的鲁棒性确立为独立于自主修复能力的评测维度，从而揭示当前前沿模型在这方面的真实水平与差距。
与已有工作不同的是，本文独特切入点在于：它是首个在任务进行期间、向可执行代码库注入用户主动发起修改的编码基准。如表1所示，已有交互式基准虽允许多轮消息或共享环境动作，但用户影响都被限制在消息层；SWE-Touch 同时允许代码编辑加消息加共享环境状态变更。它把评测焦点从听懂用户的话推进到读懂并调和用户改动的代码状态，并用受控的冲突编辑而非泛化协作行为来保证可归因、可比较，恰好填补了消息式交互与直接代码修改之间的空白。
核心方法
整体思路是在已有 SWE 修复任务之上叠加经过验证的、与任务冲突的编辑，并在智能体执行过程中以受控方式注入。技术路线分三步。第一步挖区域：让 GPT 5.5、GLM 5.1、MiniMax M2.7 三个不同家族模型各跑完整修复轨迹，对每条轨迹抽取 Read(τ) 与 Edit(τ) 两类证据并按 $C^X_i = \bigcap_{\tau \in Z_i, X(\tau)\neq\emptyset} L(X(\tau))$ 取交集得到核心区域，再按编辑证据优先于读取证据、实现文件优先于测试的确定性优先级选出每任务至多 8 个关键区域 $C_i$。第二步用独立的 User Patch Generator 在区域附近造小而聚焦的反向编辑。第三步在评测运行时按区域触发规则投递。主实验在 SWE-bench Verified 上对 200 个任务做随机采样评测，每条件三次独立运行。
核心创新是反向编辑及其严格验证。Counter-Edit 由独立的用户补丁生成器产出，是与任务冲突但局部合理的代码补丁，验证条件为 $V_{F_i}(R^-_i)=0$（编辑单独不解）、$V_{F_i}(R^*_i)=1$（参考补丁可解）、$V_{F_i}(R^{-*}_i)=0$（两者合用仍失败），从而保证编辑既不能独自解决任务、也不能与参考修复简单拼接后通过验证。这与已有方法本质不同：此前基准把用户影响局限在消息里，而 SWE-Touch 直接扰动智能体观察到的仓库状态，并设计 Co-Edit（任务对齐、非冲突的外部修改）作为对照来隔离冲突调和这一真正的难点。
方法步骤详情
步骤一挖区域：用三个模型对每个任务生成轨迹集合 $Z_i$，分别计算 Read/Edit 两类核心区域，按优先级（编辑证据>读取证据、实现文件>测试/元数据）合并相邻区域、保留至多 8 个 $C_i$。步骤二造补丁：User Patch Generator 依据问题 $q_i$、代码库 $R^0_i$、$C_i$、参考补丁 $p^*_i$ 与任务本地测试命令，在 $C_i$ 附近产出候选 $p^-_i$，且只能改实现代码、不能改测试或基准元数据。步骤三验证：用 fail-to-pass 测试集 $V_{F_i}$ 回放，须同时满足式(3)三条件才保留，最终在 Verified 上平均改动仅 7.0 行/1.04 文件。步骤四投递：评测时监控智能体动作，当动作作用域与编辑区域 $U_i$ 行重叠即触发，按式(4) $R'_{t_j}=\text{Apply}(R_{t_j},p^-_i)$ 并配上下文消息 $m_j=\text{User}(H_{t_j},p^-_i,j)$，最多 K=3 次、每任务三次独立运行。
技术新颖性
新颖性有三点。第一，首次把用户在任务中修改可执行代码库纳入编码评测，并给出可复现的形式化（修复实例 $I_i=(R^0_i,q_i,V_i)$ 加运行时投递规则）。第二，引入独立的 User Patch Generator 而非直接复用参考补丁，使冲突编辑携带位置与意图信号却又与任务相悖，更贴近真实且具有破坏性的用户改动。第三，设计了 Co-Edit 对照（任务对齐、非冲突的外部修改）以及消息/代码编辑分离消融，把性能下降精确归因到冲突调和而非被外部修改打断；这种因果归因设计在交互式编码基准里相当少见。
实验结果
主结果（表3，9 模型、SWE-bench Verified、3 次独立运行）：反向编辑使平均解决率下降 7.7 个百分点，每模型均为负向，但幅度差异巨大——GPT 5.5 仅 -1.3、Claude Opus 4.8 -1.8 最稳，而 Qwen3-Coder-480B 57.2→40.7（-16.5）、MiniMax M2.7 76.5→62.7（-13.8）、DeepSeek V4 Pro 74.8→63.8（-11.0）跌幅最大。排名大幅重排：MiniMax M2.7 从第 3 跌到第 8，Qwen 3.7 Max 从第 5 升到第 3。7/9 模型调用与 token 均增加，但更多预算未必更少损失。消融（表5）：仅发消息影响有限且不一致（-2.0~+3.0），仅静默改代码则一致下降（-1.0~-9.5），说明难点在冲突本身。Co-Edit 对照（表6）平均仅 -0.1，证实冲突调和是主因。失败分析（图4）显示 63.3% 的失败仍保留冲突代码，修改率与性能变化 Spearman $\rho=0.80$；在 SWE-Bench Pro 与 DeepSWE 上退化持续存在。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| SWE-bench Verified（短任务，200 任务） | 平均解决率变化（9 模型，Counter-Edit vs Vanilla） | 平均下降 7.7 pp；模型损失区间 -1.3 ~ -16.5 pp | Vanilla 自主修复（无用户干预） | 提出新维度——共享工作空间鲁棒性，揭示排名重排 |
| SWE-Bench Pro（长程，25 任务） | 解决率变化（Counter-Edit vs Vanilla） | GLM 5.1 43.1→32.8（-10.3）、Qwen 3.7 Max 36.0→26.0（-10.0）；Claude/GPT 5.5 持平 | Vanilla | 证明冲突退化在更长程多文件任务中持续 |
| DeepSWE（长程，25 任务） | 解决率变化（Counter-Edit vs Vanilla） | Claude Opus 4.8 56.0→46.0（-10.0）、GPT 5.5 64.0→56.0（-8.0） | Vanilla | 在另一长程分布上复现退化现象 |
| Co-Edit 对照（SWE-bench Verified） | 解决率变化（任务对齐、非冲突的外部修改） | 7 模型平均 -0.1 pp，多数在 ±1.2 内 | Counter-Edit 同 7 模型平均 -7.2 pp | 因果证据：大幅下降来自冲突而非被外部修改打断 |
局限与改进
作者承认的局限：SWE-Touch 采用受控的、区域触发的反向编辑，刻画的是对受控冲突编辑的鲁棒性，而非完整协作用户行为的分布；基于区域的触发为可比较性把干预放在可比位置，未建模用户观察智能体实时动作后动态决定何时干预。此外它只是评测框架，未提出优化方法。我补充观察：样本规模偏小（主实验 200 任务、长程各 25 任务、2-3 次运行），个别长程退化结论（如 DeepSWE 上多模型接近 0%）统计上较脆弱；Counter-Edit 只构造冲突一种方向，未覆盖互补/部分正确编辑，可能高估或低估特定模型的协作能力；用户消息由提示词生成，其说服力差异也可能干扰模型表现。
独立分析的弱点
弱点一，交互空间窄。只测冲突编辑，真实协作还包括互补编辑、部分正确修复、需求变更等，应扩展为分层、可复现的多类干预；改进方向是构造带标签的干预类型集合并按类型分别报告鲁棒性。弱点二，用户模拟器是开环的，不观察智能体实时动作，与真实全双工协作差距大；改进方向是做自适应用户模拟器，根据智能体实时 diff/测试结果动态决策是否、何时、如何干预。弱点三，纯评测无优化信号，难直接指导训练；改进方向是把检测外部变化、推断用户意图、调和冲突、重新验证显式纳入奖励，做 collaboration-aware 训练。弱点四，样本规模与运行次数偏小，长程结论方差较大，需扩大评测规模并报告置信区间。
未来方向
作者提出三个方向：在保留分层可复现条件的前提下扩展交互空间，纳入互补编辑、部分正确修复、需求变更等更多干预类型；走向全双工协作的自适应用户模拟器，由其观察智能体实时动作后动态决策干预；从评测迈向优化，训练能检测变化—推断意图—整合兼容贡献—必要时澄清—解决冲突—重新验证的协作感知编码智能体，并跨 helpful/incomplete/ambiguous/conflicting 干预做校准训练。基于该成果可延伸：把 SWE-Touch 的冲突编辑作为课程或对抗样本用于强化学习；研究模型修改率与解决率权衡下的干预频率 K 自动调度；把修复率与协作鲁棒性联合纳入排行榜。
复现评估
复现性较好：作者公开了项目页（github.com/Trae1ounG/SWE-Touch）与数据集（huggingface.co/datasets/Trae1ounG/SWE-Touch），智能体通过 Mini-SWE-Agent 的 shell 接口交互，评测使用确定性的区域触发规则与 K=3 默认预算、每条件 3 次独立运行，补丁规模与验证统计在附录给出。但完整复现需大量算力：要跑 9 个前沿闭源/开源大模型在数百任务上的多轮自主与反向编辑条件，外加三个挖掘模型的轨迹生成；虽然具体提示词、完整轨迹与失败审计细节在附录，但排名重排部分依赖随机种子，且部分长程结论在 25 任务/2 次运行下方差较大，独立复现时需谨慎对待小幅差异。
论文图表
分(a)(b)两部分。(a)示意用户与智能体共享同一仓库：用户编辑改变仓库状态，进而影响智能体后续读取/编辑/测试所观察到的代码。(b)是对已发布 SWE-chat 数据的统计，发现 59.0% 的会话包含归因于用户的代码库变更。
它直接论证了动机——用户动手改代码是真实开发中高频却被现有基准忽视的交互形态，59.0% 这一数字是全文问题陈述的核心证据。