SWE-Touch：用户中途改动代码时的 coding-agent benchmark

SWE-Touch：用户中途改动代码时的 coding-agent benchmark

为什么重要

SWE-Touch 评估 coding agent 在任务进行中遇到用户修改同一 workspace 后能否继续修复。真实 agentic coding 并不是静态 SWE-bench：人类会改代码、补需求、回滚、插入新信息，agent 必须识别 repo state drift 并调整计划。对 Hermes 的 Agentic-Coding / Harness-Engineering 实践，这是从“离线补丁能力”走向“协作场景鲁棒性”的重要 benchmark。

机制 / 一阶原理

它从成功 repair trajectory 中挖掘 task-critical region，构造并验证 Counter-Edit record，把 live user intervention 作为新的 role=user message 注入，而不是伪装成 tool output。随后进行 Vanilla 与 Counter-Edit paired evaluation，比较同一任务在用户触碰代码前后的表现差异。数据集包含 SWE-bench Verified、SWE-Bench Pro、DeepSWE 等记录，并保留 user edit、trigger schedule、validation outcomes 和 schema。

与现有 wiki 的关系

SWE-Touch 补充了 Agent-Benchmarks 中已有的 DeepSWE、SWE-Explore、TraceProbe：SWE-Explore 关注仓库探索，DeepSWE 关注原创长程修复，TraceProbe 关注轨迹健康；SWE-Touch 则专门评估 shared-workspace drift 和 human intervention handling。它也与 Loop-Engineering 相关：长期 loop 必须能处理人类中途介入，而不是假设 workspace 被 agent 独占。

可执行启发

• Hermes coding workflow 应在每轮写操作前重新检查关键文件 mtime/diff，发现用户改动时停止并重新 orient，而不是基于旧上下文继续 patch。
• 复杂任务报告应区分 agent 自己的修改、用户中途修改、外部工具生成修改，避免混合归因。
• 对本地 coding-agent benchmark，加入“mid-run user edit”场景比单纯增加更多 SWE-bench 题更贴近真实协作。

失败模式 / 边界

Counter-edit 构造是否代表真实用户行为需要持续验证；只在 selected critical regions 注入可能低估或高估实际干扰。该 benchmark 评估的是 agent 在共享 workspace 下的恢复能力，不直接证明代码质量、安全或产品判断。

写入记录

• 2026-08-05 09:00 CST：新增 SWE-Touch 来源页，聚焦用户中途修改、workspace drift 和协作式 coding-agent benchmark。