SWE-Touch：当用户也在改代码，编程智能体还可靠吗？

导语

现有编程智能体评测大多默认一个前提：智能体独自面对一个静态代码库，按任务说明修复问题即可。但真实软件开发并非如此。开发者可能一边观察智能体的修改，一边手动调整文件、补充临时修复，甚至改动智能体正准备处理的关键代码。SWE-Touch 关注的正是这个更棘手的问题：当用户“触碰”了代码，编程智能体是否还能理解当前仓库状态，并做出正确应对？

论文作者指出，对 SWE-chat 数据的分析显示，59% 的会话包含用户亲自写入的仓库改动。这意味着，协作式代码环境不是边缘场景，而是未来编程智能体落地时必须面对的常态。

核心要点

• 评测目标从“单独修复”转向“共享工作区协作”：SWE-Touch 不再只看模型能否在静态仓库中完成任务，而是测试它在用户同时修改代码时的适应能力。
• 引入 Counter-Edit 机制：框架会从多条修复轨迹中挖掘任务关键区域，再由独立的 User Patch Generator 生成小规模、看似合理但会与任务完成相冲突的代码改动。
• 在关键时刻注入用户修改：当智能体运行到相关代码区域时，系统将这些用户改动连同上下文消息一起注入，模拟真实协作中用户临时更改代码的情况。
• 性能下降并不轻微：在 SWE-bench Verified 上，九个编程模型的平均解决率下降 7.7 个百分点；在 SWE-Bench Pro 和 DeepSWE 等更长任务中，退化现象仍然存在。
• 失败常来自“没看见变化”：轨迹分析显示，失败运行中有 63.3% 直接保留了用户的冲突代码，没有有效识别或处理这些改动。

研究发现

SWE-Touch 的价值不只是制造更难的测试集，而是揭示了当前编程智能体能力结构中的短板。许多模型在自动化修复排行榜上表现强劲，但一旦代码库在执行过程中发生变化，就可能继续沿用旧的心理模型，忽略已经被用户改写的文件状态。

论文还提到，性能下降主要由代码改动本身驱动，而不是伴随的用户消息。这一点很关键：问题不在于模型没有“听懂用户说什么”，而在于它没有充分重新检查仓库、识别冲突，并用针对性测试验证新的行为是否满足任务目标。

在模型对比中，素材提到 Claude Opus 4.8 和 GPT 5.5 显示出较强韧性，而一些在自主修复基准上具备竞争力的开源模型下降明显，最高退化达到 16.5 个百分点。这说明静态基准排名并不能直接代表协作开发可靠性。

意义与影响

SWE-Touch 提醒行业：编程智能体的下一阶段评测，不能只衡量“能不能独立写出补丁”，还应衡量它是否能维护对工作区状态的持续认知。真正可用的协作智能体需要知道哪些文件被改过、这些改动是否与任务目标冲突、是否需要与用户意图协调，以及修改后是否通过针对性测试得到验证。

对产品开发者而言，这可能意味着更强的文件变更监控、更精细的上下文刷新策略、更明确的冲突处理流程，以及将测试验证嵌入智能体决策循环。对模型研究者而言，SWE-Touch 提供了一个新的压力测试方向：从“静态代码理解”走向“动态协作环境中的状态感知”。

来源：Hugging Face Daily Papers