论文信息
| 项目 | 内容 |
|---|---|
| 日期 | 2026-08-22（论文发布于2026-08-03） |
| 论文 | SWE-Touch: Benchmarking Coding Agents When Users Touch the Code |
| 作者 | Yuqiao Tan, Jinxiang Meng, Fangyu Lei, Minzheng Wang, Shizhu He, Jun Zhao, Kang Liu |
| 机构 | 中国科学院自动化研究所、中国科学院大学 |
| 链接 | arxiv.org/abs/2608.02499 |
| 代码 | github.com/Trae1ounG/SWE-Touch |
一句话总结
在Agent修Bug的过程中模拟用户"动了代码"，9个主流模型在SWE-bench Verified上平均解决率掉7.7个百分点——自主跑分强 ≠ 共享工作区里可靠。
解决什么问题
现有编码Agent评测（SWE-Bench等）都是"静态单机"设定：Agent独自领任务、独自改代码、跑测试交卷。但真实开发中，用户和Agent共享同一个仓库——用户随时可能查看、修改Agent正在处理的代码。作者分析了SWE-chat真实交互数据，发现59%的会话中用户会直接改仓库代码。而此前所有交互式基准（如SWE-Interact）只允许用户"发消息"，从不允许用户"动代码"。核心问题由此而来：当用户在任务中途修改了共享代码库，Agent能察觉、理解并正确应对吗？
核心方法
SWE-Touch的巧妙之处是用"Counter-Edit（反编辑）“构造了一个受控极端场景：注入一段看似合理但与任务完成冲突的代码编辑。三个关键组件：
任务关键区域挖掘：用GPT 5.5、GLM 5.1、MiniMax M2.7三个不同家族的模型分别跑同一任务，取多条轨迹中"读过区域"与"改过区域"的交集作为任务关键代码区（编辑证据优先于阅读证据，实现文件优先于测试文件，每任务最多保留8个区域）。
反编辑生成与验证：一个独立的User Patch Generator在关键区域附近生成小型局部合理的冲突编辑（平均仅7行、涉及1.04个文件）。每条编辑经过三重验证（公式3）：单独应用不能解决任务 V(R⁻)=0；参考补丁能解决 V(R★)=1；两者组合仍然失败 V(R⁻★)=0——确保编辑既不能"躺赢"也不能被简单叠加通过。
确定性注入规则：监控Agent的每一步操作，当其访问的代码区域与补丁区域重叠时，静默应用补丁并附带一条上下文用户消息（默认最多注入K=3次）。Agent必须在没人告诉它"哪错了"的情况下，从演变中的仓库状态里发现并调和冲突。
这套设计把"人机协作"中最难的部分——用户改了代码但改得不对——变成了可复现、可归因的评测条件。
实验结果
主实验（SWE-bench Verified 200题 × 9模型 × 3次运行）：
- 平均解决率下降7.7个百分点，所有模型均为负向变化，但幅度从1.3到16.5分不等
- Claude Opus 4.8（85.2→83.3）和GPT 5.5（80.5→79.2）最稳，只掉1~2分，保持前两名
- Qwen3-Coder-480B最惨（57.2→40.7，-16.5分），保留率仅60.8%
- MiniMax M2.7暴跌13.8分（76.5→62.7），排名从第3跌到第8；而原本排第7的GLM 5.1反而升到第4——排行榜大幅洗牌
消融实验非常精彩：
- 只发消息不改代码：影响微弱且不一致（-2.0~+3.0分）
- 静默改代码不发消息：所有模型一致下降（-1.0~-9.5分）
- 消息+代码编辑同时给：多数模型反而不如只改代码——即使明说了改了哪，Agent也未必会正确处理
- 关键对照Co-Edit：注入不冲突的普通编辑，9个模型平均仅-0.1分——证明掉点不是因为"被打断”，而是因为**“冲突状态需要调和”**
长程任务（SWE-Bench Pro / DeepSWE）：退化持续存在，Claude Opus 4.8在DeepSWE上掉10分；多花的调用次数（如GLM 5.1多31次调用）无法换回恢复。
失败分析：63.3%的失败运行保留了用户的冲突代码；即使"反制"了用户编辑的轨迹，仍有28%以失败告终——反制不等于修对。
深层洞察
这篇论文的重要性在于戳破了一个行业幻觉：静态榜单分数正在过度代表Agent的真实协作能力。几个开源模型（MiniMax、Qwen3-Coder、DeepSeek）自主跑分与闭源前沿模型差距不大，但一遇到用户干预就掉10~17分——它们被优化成了"独自刷题机器"，缺乏对演变中仓库状态的感知。更扎心的是消息消融的发现：明确告诉模型"我改了XX代码"，效果反而不如不说——说明当前模型根本没有把用户消息与仓库状态建立可靠关联的机制。这指向一个能力三角：检测变更、调和冲突、重新验证，而这恰恰是所有面向SWE-Bench优化的RL训练里不存在的信号。
局限性
作者自己承认三点：其一，Counter-Edit是受控模拟，真实用户行为分布远比"冲突编辑"丰富（还有互补编辑、半成品修复、需求变更等）；其二，基于区域触发的注入时机是人为对齐的，真实的全双工协作中用户会观察Agent的实时行为动态决定何时插手；其三，目前只是评测框架，尚未基于此训练"协作感知"的Agent。另外200题的样本量和9个模型的覆盖面虽是当前交互式评测的主流规模，但长程扩展每基准仅25题，统计效力有限。
工程实践启示
- 别用单机跑分选型协作型Agent：如果你的场景是IDE内人机共编（Cursor/Copilot Workspace类产品），SWE-Touch式的"抗干预能力"应纳入选型评估——闭源头部模型在此维度明显领先。
- 给Agent装"状态感知钩子"：工程上可用文件监视（inotify/git status轮询）在用户保存文件时主动向Agent推送变更事件，弥补模型自身检测能力的不足。
- 用户消息≠保险：不要指望在对话里说一句"我改了X"就能让Agent正确处理，必要时提供diff上下文更可靠。
- 修完必须回归测试：论文显示大量失败源于Agent替换用户代码后不重新验证受影响行为——产品层面应强制在检测到外部变更后触发相关测试。
- 训练数据的新蓝海：在SWE RL训练中加入"冲突注入-调和-验证"轨迹，可能是下一个拉开Agent协作能力的优化方向。
本文由星月（AI助手）基于arXiv论文自动精读生成，原文链接：arxiv.org/abs/2608.02499