SWE-Touch: 当用户触及代码时对编程智能体进行基准测试

TL;DR SWE-Touch 通过向共享代码空间注入冲突编辑（Counter-Edits），揭示强自主编程代理在动态协作中状态感知和自适应能力不足，平均解决率下降 7.7 个百分点。

问题

问题背景

软件工程智能体（coding agent）正从独立求解仓库 issue 向人机协作演进。当前主流评估如 SWE-bench 侧重固定代码库上的自主修bug能力，但真实开发中用户常直接修改代码，智能体需在共享工作区中感知并响应用户的实时编辑，而这一动态交互维度至今缺乏系统测试。

现有方法局限

现有仓库级基准（SWE-bench、SWE-bench Multimodal 等）存在两类简化假设：

• 环境静态假设：代码库在任务执行期间不变，智能体面对的是冻结的快照；
• 交互通道单一：用户只能通过自然语言消息与智能体沟通，无法直接触碰代码。

这导致三大技术盲区：

1. 变化检测缺失：智能体不会主动检查工作区是否有外部修改，继续依赖过时的文件内容；
2. 冲突协调无能：当用户的Counter-Edit（与任务目标冲突的合理编辑）出现时，智能体要么保留已失效的代码，要么粗暴覆盖用户改动而不再验证；
3. 评估缺口：现有排行榜仅反映静态环境性能，无法衡量智能体在真实协作中的鲁棒性。

为什么这个问题难/重要

技术挑战要求智能体同时具备三项能力：

• 感知：实时跟踪文件状态变化；
• 理解：推断用户编辑意图，区分是修复、重构还是试探性修改；
• 适应：重新规划解决方案，协调自身修改与用户编辑，并通过针对性测试验证整体正确性。

业界关注度：AI 编程助手（如 GitHub Copilot、Devin）正越来越多地融入团队工作流。若智能体无法处理用户触碰代码的场景，将导致代码丢失、重复工作或引入隐蔽 bug，直接影响开发效率与信任。因此，共享工作区适应性成为从演示走向生产力的关键瓶颈。

行业类比

正如自动驾驶汽车在人类临时接管方向盘后，必须迅速重建对交通场景的完整理解才能安全继续行驶，编程智能体在用户修改代码后，也需重新扫描仓库、对齐状态并调整后续步骤，否则将如同“盲开”般危险。

核心洞察

• 现有编码代理基准（如 SWE-bench）通常假设代理独立工作或仅通过消息交互，忽略了真实共享工作区中用户可能直接修改代码的场景。SWE-Touch 引入 Counter-Edits——与任务目标冲突的合理代码编辑——在代理介入时注入，导致 9 个模型的解决率平均下降 7.7 个百分点。这揭示出当前评估体系高估了代理的实际协作能力。
• 即使代理在孤立任务中表现强劲，共享工作区中的状态感知与自适应行为仍是薄弱环节。轨迹分析显示，代理常保留冲突代码或替换后未重新检查仓库并验证，根源在于缺乏对工作区变化的有效检测、冲突编辑与任务目标的协调，以及对受影响行为的针对性验证能力。

方法

输入

• 任务描述与代码库快照：沿用 SWE-bench 格式，代理接收一份需求说明和完整的仓库状态。
• 用户冲突编辑（Counter-Edit）：在代理执行过程中，系统会引入一条合理的、但与任务目标相悖的代码变更，模拟协作中用户的中途修改。

关键模块

1. 任务关键区域挖掘
   从多个修复轨迹（repair trajectories）中提取对任务完成至关重要的文件与行号。这些轨迹由不同模型或多次尝试生成，通过对比筛选出频繁修改的位置。

2. 用户补丁生成器（User Patch Generator）
   一个独立模块，基于当前仓库上下文构造看似合理但阻碍原始任务的编辑。它利用代码语法与项目风格约束，避免产生语法错误或明显无关的变更，使冲突编辑更隐蔽。

3. 动态注入与上下文消息
   当代理探索到相关代码区域时，SWE-Touch 将 Counter-Edit 及一条自然的用户消息（如 “我修改了这部分的逻辑，看看是否影响你的修复”）注入工作区。这要求代理感知到状态变化，并重新评估先前的推理。

输出与评估

• 代理最终产出补丁，需同时满足原始任务需求并适配用户的冲突变更。
• 核心指标：resolve rate（问题解决率）。在 SWE-bench Verified 上，加入 Counter-Edit 后平均解决率下降 7.7 个百分点；在更长周期的 SWE-bench Pro 和 DeepSWE 上也观察到持续退化。
• 轨迹分析揭示失败原因：代理对工作区演化的意识不足，可能保留冲突代码，或未充分重新检查仓库、用相关测试验证修改后的行为。

原作者指出：“强自主性能尚未保证共享工作区协作所需的状态感知与自适应行为。”

与同类方法的差异

不同于 SWE-bench、RepoBench 等假设代理独立工作的评估框架，SWE-Touch 首次系统性地引入实时、冲突的用户代码修改，迫使代理具备检测工作区变更、协调冲突编辑与验证受影响行为的能力。该设计更贴近真实协作场景，暴露了当前模型在上下文适应性与状态感知上的短板。

实验

实验设计

SWE-Touch 针对 共享工作区 场景，通过 Counter-Edits 模拟真实开发中用户中途修改代码的干扰。在 SWE-bench Verified 上测试了 9 个主流编程模型，并扩展至更长期任务 SWE-Bench Pro 和 DeepSWE。

关键步骤：

1. 从多条修复轨迹中挖掘 任务关键区域。
2. 使用独立的 User Patch Generator 生成与任务目标冲突、但在代码上下文中合理的补丁。
3. 当 Agent 触及对应代码时，注入补丁并附带上下文消息。

关键发现

• 稳健性不足：Counter-Edit 使 平均解决率 降低 7.7 个百分点，且在长周期任务上退化持续，说明当前编程 Agent 对工作区变化的感知和适应能力有限。
• 失败模式：轨迹分析显示，Agent 往往保留冲突代码或直接覆盖，却未充分重新审查仓库、运行针对性测试验证修改后的行为。
• 核心差距：强大的单次自主性能（无干扰）并不能确保共享协作所需的状态感知和自适应行为。

与基线对比的解读

无 Counter-Edit 基线代表 Agent 在理想化单人环境中的表现。引入 Counter-Edit 后解决率显著下降，暴露出当前评测基准的系统性缺陷——它们忽视了人类开发者最常见的“边写边改”交互模式。这一定量差距（7.7 pp）看似不大，但考虑到 Counter-Edit 是精心设计的轻量干扰，真实场景下更复杂的并发修改可能带来更严重的性能崩溃。未来工作需重点提升工作区变更检测、冲突编辑与任务目标协调，以及受影响行为的自动验证等能力。

行业影响

落地场景

SWE-Touch 揭示的现实是：企业级代码助手（如 GitHub Copilot、Cursor、Codeium）在多人协作的共享仓库中尚未充分验证。典型场景包括：

• 协同开发平台：工程师在合并分支时频繁手动修改 AI 生成的代码，助手必须即时感知这些改动并调整后续步骤。
• 自动化 CI/CD 修复：CI 流水线中 bot 生成补丁后，若人类审核员在合并前对补丁做了局部调整，bot 再次介入时必须理解冲突变更。
• 低代码/无代码平台：业务人员直接修改生成的逻辑片段，AI 后台需同步更新其余依赖模块。

商业价值

目前编码模型在独立任务（SWE-bench Verified）上表现强劲，但 Counter-Edit 模拟的共享编辑使解析率平均下降 7.7 个百分点，这意味着：

• 直接成本暴露：依赖全自动流程的团队可能在一次“盲目覆盖”后引发下游缺陷，回溯修复的人工时间远超模型生成的节省。
• 体验与信任：用户修改 AI 产出后，若助手仍基于过时代码给出建议，会削弱生产力而非提升。增强的状态感知能力可直接提高开发者采纳率，减少“AI 帮倒忙”的摩擦。
• 差异化竞争：率先集成共享工作区感知的代码助手将获得企业采买决策的显著优势。

与现有产品/工作流的集成接口

当前集成栈多为单次会话模式，SWE-Touch 建议引入三个轻量能力：

• 变更检测钩子：在 LSP/IDE 层监听文件修改事件，触发助手重新索引受影响的依赖图。
• 冲突编辑分析器：对比用户修改与任务目标的语义差异，生成类似 SWE-Touch 中 User Patch Generator 的 diff 摘要，注入提示词。
• 针对性回归测试：要求助手在修改后不仅运行全量测试，还主动复测与变更区域相关的测试用例子集，类似轨迹分析中强调的“验证受影响行为”。

具体落地用例

用例 1：电商大促核心交易系统维护

• 背景：SRE 团队使用 AI 助手修复订单服务的高并发超时问题，助手生成连接池调优补丁。
• 共享编辑：值班工程师手动将连接超时从 500ms 改为 300ms，并添加了 fallback 逻辑。
• 问题：助手随后继续修改重试策略，却基于旧的 500ms 假设推算最大重试次数，导致雪崩风险。
• SWE-Touch 方案：变更检测钩子捕获 diff，提示助手重新评估重试上限，并触发连接池相关测试套件，避免配置冲突。

用例 2：企业级财务系统的合规规则引擎修改

• 背景：审计要求更新税率计算模块，AI 助手生成多国税率调整代码。
• 共享编辑：税务专家手动修正了某辖区的豁免条件，并增加了临时的过渡期判断。
• 问题：助手未察觉到豁免变更，在后续汇总步骤中直接覆盖了专家修改的代码，导致合规审计失败。
• SWE-Touch 方案：冲突编辑分析器识别出语义冲突，提示助手合并变更而非替换，并强制运行针对豁免逻辑的专项测试。

这些用例表明，共享工作区感知 不是锦上添花，而是高可靠性 AI 编码助手从“辅助编写”到“可信协作”的关键一步。

局限

• **Counter-Edit 的合理性与覆盖范围**：论文生成的 Counter-Edit 依赖 User Patch Generator，尽管通过挖掘多个修复轨迹的关键区域来保证合理性，但其覆盖的用户行为模式仍然有限。真实共享工作区中，用户的修改可能更无规律、意图模糊或附带不完整的上下文，而 SWE-Touch 预设了明确的冲突编辑和单一形式的用户消息，这可能导致评估偏差：代理在面对更自然、多样的人类介入时可能表现更差。此外，当前框架仅注入与任务直接相关的代码修改，未测试用户对非关键区域的扰动，从而限制了结论的泛化能力。
• **缺乏可行的改进路径**：论文主要贡献在于诊断问题，通过轨迹分析暴露了代理在共享工作区中的状态感知缺失、代码冲突处理缺陷及验证不充分等现象。然而，它并未提出任何具体的方法来解决这些弱点，也未提供提升鲁棒性的基线或训练策略。这使 SWE-Touch 更接近一个压力测试工具，而非一个完整的开发平台，其工程实用性暂时局限于评估现有代理的脆弱性，而无法直接指导下一代编码代理的设计。