SWE-Touch：当人类中途修改代码，大模型解决率平均下滑7.7分！

SWE-Touch: Benchmarking Coding Agents When Users Touch the Code

论文原文 ↗ 论文发布 2026-08-03 解读发布 2026-10-02 解读：AI前沿分享

在各大模型竞技场与代码基准榜单上，自主软件工程智能体（Coding Agent）展现出的解题能力看似已经逼近资深工程师。只要给出一份 GitHub Issue、一个完整的代码仓库和一套测试用例，大模型就能在封闭沙盒中自主定位错误、修改文件并跑通测试。然而，当这些工具被真正接入日常开发工作流时，开发者却经常产生一种强烈的断裂感：模型在独立解题时算无遗策，一旦人类中途动了哪怕几行代码，它就会陷入逻辑混乱甚至原地打转。

ArXiv URL：https://arxiv.org/abs/2608.02499

这种断裂感的根源在于评测设定与真实场景的严重脱节。现实中的协同编程从来不是单纯的“人类提需求、模型闭门造车”，而是两个人机共存的共享工作区（Shared Workspace）。最新的真实交互分析显示，在涉及多轮人机交互的编码会话中，高达 59.0% 的场景都包含人类用户直接修改工作区代码的行为。以往的交互式基准测试往往把人类的参与严格限制在“自然语言消息”层面，完全忽视了代码库状态本身就是最具破坏力、也最关键的交互通道。

为了打破这种“单打独斗”的虚幻评估，评估框架 SWE-Touch 应运而生。它系统性地检验了一个核心问题：当人类在协作过程中中途修改了正在运行的代码，大模型智能体能否感知工作区的演变并正确化解冲突？在一系列严格的受控测试中，这一看似微小的外部扰动让主流模型的平均问题解决率暴跌了 7.7 个百分点，最大单项降幅高达 16.5 个百分点，且直接引发了榜单格局的剧烈震荡。这表明，在静态榜单上名列前茅的单机性能，根本无法自然延伸为共享工作区中的稳健协作力。

为什么人类“动一下代码”，大模型就容易抓瞎？

要理解这一现象，首先必须审视大模型在仓库级任务中的推理机制。典型的 Coding Agent 往往依赖长上下文来维护自己对代码调用链、变量定义和修改计划的心理表征（Mental Model）。如果人类的干预仅停留在发送一句提示词，如“请注意这里的异常处理”，模型只需要将其作为新增的对话 Token 拼接到上下文中即可。

但在真实的共享工作区中，状态的变化发生在模型身处的物理环境里。一旦人类修改了某个函数的返回值或改动了某处控制流，代码库的可执行状态就已经发生了不可逆的偏移。此时，后续的所有观察结果（如测试报错、语法分析、日志输出）都必须建立在全新状态之上。如果智能体缺乏持续的状态感知能力，依然机械地依赖早先对仓库的认知，或者对用户写出的有缺陷代码盲目信任，整个修复轨迹就会迅速崩溃。

以往的研究由于缺乏受控机制，很难在复杂的大型仓库中量化这种代码级冲突的破坏力。如果是完全无关的代码修改，智能体大可以直接忽略；如果是完全正确的协助代码，又无法测试智能体的辨别力。真正的压力测试，恰恰出现在那些“看似言之成理、位置极其关键、实则与最终任务目标相冲突”的人类修改上。SWE-Touch 正是围绕这一被称为 Counter-Edit（对抗性冲突编辑）的核心机制展开构建。

SWE-Touch 如何制造高逼真的“人机冲突”？

SWE-Touch 的核心设计理念不是随机向代码中投毒，而是通过系统化的管线，生成在工程逻辑上极度自然、但会导致最终修复失效的微小补丁，并在模型执行的关键节点精确注入。

整个评测框架分为三个紧密衔接的阶段：

首先是关键区域挖掘（Mining Task-Critical Regions）。为了确保注入的代码能够击中要害，SWE-Touch 预先收集多个不同模型在没有干扰时的完整修复轨迹。系统会追踪模型在解决该任务时重点读取（Read）和修改（Edit）的代码行，通过集合求交与启发式优先级筛选，确定该任务的核心代码区间 $C_i$。这意味着模拟的用户干预绝非无的放矢，而是精确聚焦在模型无论如何都绕不开的业务中枢。

其次是冲突补丁生成与形式化验证（User Edit Construction & Validation）。系统配置了一个独立的辅助大模型作为用户补丁生成器（User Patch Generator）。该生成器会拿到任务描述、原始代码库、参考正确补丁以及前面挖掘出的关键区域代码。它的任务是生成一个微小且符合局部语法的补丁 $p_i^-$，平均修改规模仅为 7 行代码左右，最多涉及 1 个文件。为了保证评测的严谨性，每一个候选补丁都必须通过三道硬性测试：

单独应用该补丁，无法通过未修复测试；
原始标准修复补丁可以正常跑通测试；
将用户补丁与标准修复补丁叠加后，原有的测试必须失败（即 $V_i^F(\operatorname{Compose}(R_i^0, p_i^-, p_i^\star)) = 0$）。

这套验证确保了生成的补丁绝非语法噪点，而是真正构成了逻辑上的任务冲突，迫使智能体必须对其进行检查、质疑或重构。

最后是运行时区域触发注入（Shared Workspace Evaluation）。在正式评测过程中，Agent 在沙盒环境中自由执行读取、编辑与测试命令。运行时探针会实时监控智能体访问的代码行。一旦智能体触碰了预设的补丁重叠区域，系统就会在后台悄悄将补丁应用到文件系统中，同时模拟人类开发者的口吻，生成一条伴随该代码提交的上下文消息。智能体在下一步行动前，既能看到人类发来的文字解释，也身处已被实际改动的文件系统之中。

榜单大洗牌：静态高分不等于协作稳健

研究团队在包含 200 个高质量 Python 任务的 SWE-bench Verified 基准上，对来自主流阵营的 9 款代表性前沿模型进行了详尽评估，涵盖 Claude Opus 4.8、GPT 5.5、GLM 5.1、MiniMax M2.7/M2.5、Qwen 3.7 Max、Qwen3-Coder-480B-A35B、Kimi K2.6 以及 DeepSeek V4 Pro。

实验结果展现了极其明显的性能滑坡：在受到 Counter-Edit 干扰后，这 9 款模型的平均任务解决率直接下降了 7.7 个百分点。更值得警惕的是，这种性能折损在不同模型间表现出巨大的异质性。有的模型表现出相对较强的韧性，降幅被抑制在 1.3 到 3 个百分点以内；而另一些在自主单机榜单上名列前茅的模型，在人类插手后解决率竟暴跌了 16.5 个百分点。

这种非对称的下滑彻底打破了静态单机评测形成的固有梯队。在传统的单机跑分中，多个模型的解决率可能咬得非常紧，但在面对人类改动代码的真实扰动时，它们对动态环境的适应能力高下立判。一些过度针对静态测试用例进行微调的模型，暴露出严重的泛化短板：只要预想中的代码行号或变量命名被人类挪动了一点点，原本流畅的链式推理就会彻底中断。

为了验证这种现象是否仅局限于短流程任务，研究人员进一步在难度极高、交互步数往往达到数百步的 SWE-Bench Pro 和 DeepSWE 上进行了测试。在这类长视距任务中，人类干预被设定在模型推理进度的四分位点（25%、50%、75%）发生。如上图所示，随着任务复杂度和交互深度的上升，冲突代码带来的干扰不仅没有被漫长的调试过程稀释，反而引发了更为严重的资源空耗。模型为了尝试修复被人类搞乱的工程，往往会消耗更多模型调用次数和 Token，最终的解决率曲线却依然普遍向下漂移。

剥离变量：到底是哪一步被击溃了？

为了彻底摸清大模型究竟是因为“看了人类的错误消息被误导”，还是因为“搞不定被修改的文件系统”，研究团队进行了一组极具启发性的消融实验。

测试设置了三种干预形态的对照：只发用户消息不改代码、只改代码不发任何消息、既改代码又发消息。结果显示，如果仅仅向智能体发送带有误导性质的人类消息而不动代码库，模型的解题率几乎没有显著变化，浮动仅在 -2.0 到 +3.0 个百分点之间。这表明当前的前沿大模型对于纯文本层面的“人类耳旁风”具备相当强的抵抗力，不会因为一两句外行指点就放弃自己的解题思路。

然而，一旦进入“只改代码、不发消息”的静默干预状态，所有模型的解决率全部发生断崖式下跌，降幅在 1.0 到 9.5 个百分点不等。当人类在后台动了代码却不打招呼时，智能体不仅要具备发现外部状态突变的嗅觉，还必须通过自己的执行反馈反推出代码被动过了。更令人啼笑皆非的是，在“既发消息又改代码”的完整场景下，绝大多数模型的表现甚至比完全不发消息还要差。这说明模型目前极其不擅长将人类的自然语言阐述与文件系统中的实际 Diff 进行对齐，人类给出的解释反而成为了干扰模型判断代码冲突的负面噪音。

针对那些原本在自主状态下能够成功解决、但在人类介入后失败的案例（即从 Solved 变为 Unresolved），深度的轨迹审计揭示了更加细致的失败谱系（如上图所示）：

绝对盲从与遗留冲突：在高达 63.3% 的失败轨迹中，智能体最终提交的补丁里完整保留了用户注入的错误代码。模型似乎天然对用户写下的代码抱有一种“权威偏见”，不敢推翻人类的修改，宁可在错误的地基上缝缝补补。
缺乏状态二次感知：很多智能体在人类修改了文件后，根本不会主动调用 cat、grep 或语言服务器去重新阅读被修改函数的外围上下文，依然使用几轮对话之前在内存中缓存的旧代码逻辑来编写新补丁。
推翻了代码，但验证失灵：在另外三分之一的失败案例中，智能体虽然敏锐地识别出了人类的代码不可行并予以删除或重写，但在随后的测试阶段，它们要么仅运行了局部的简易断言，要么没有针对被人类修改过的边缘分支构造有针对性的测试，导致最终的提交依然无法通过全量验证套件。

走向“全双工协同”的代码智能体

长期以来，AI 编程领域陷入了一种“单机打榜”的思维定势。研究人员倾向于将大模型打造成一个全知全能的闭门极客，只要提示词输入完毕，剩下的一切就交给它在沙盒里自娱自乐。然而，真实的工业级软件工程从来不是纯粹的自动化替换，而是一种全双工的人机协作动态。

SWE-Touch 的研究结论给整个行业敲响了一记警钟：静态代码基准的高分，无法兑现为共享环境中的协作稳健性。 当智能体走进真实的 IDE，面对不断按保存键、偶尔改几行变量、甚至经常写出 Bug 的人类队友时，仅仅懂得如何把空白文件填满是远远不够的。

未来的代码模型若想真正实现工程落地，必须在基础训练与强化学习对齐中补齐三大缺失能力：

工作区状态变化感知：能够主动且轻量地监听外部文件变动，及时失效陈旧的记忆缓存；
人机代码冲突调和：能够客观权衡人类的意图与任务的严谨约束，既不过度顺从人类的错误代码，也不盲目全盘回滚人类的有益修改；
受影响范围的针对性再验证：在工作区遭受扰动后，具备智能推导受影响调用链并自适应重跑关联测试的工程本能。

从单机自治走向工位协同，大模型不仅需要学会写代码，更需要学会与那个不完美但必不可少的人类队友，在同一个文件夹下从容共处。