论文信息
| 项目 | 内容 |
|---|---|
| 日期 | 2026-11-07 |
| 论文 | SWE-Shift: Evaluating Coding Agents in Evolving Workspaces |
| 作者 | Victor Shea-Jay Huang, Rongqing Li, Zhangyue Yin, Kelong Mao 等 |
| 机构 | CUHK MMLab（香港中文大学多媒体实验室） |
| 链接 | arXiv:2610.32196 |
| 代码 | github.com/JeixHuang/SWE-Shift |
一句话总结
SWE-Shift 用"配对延续"协议证明：一旦任务执行中环境发生真实变化，当前所有编码 Agent 的成功率都大幅下滑——静态基准分数掩盖了动态环境下的脆弱性。
解决什么问题
现有仓库级编码基准（SWE-bench 系列）默认一个隐含假设：任务开始后，代码、依赖、运行时状态和需求都保持不变。但真实软件开发是流变的——你在改代码时，同事可能推了新提交、依赖升了版本、用户改了需求、CI 环境变了。此前没人能回答一个关键问题：Agent 正在执行时环境变了，它还能成功吗？ 更麻烦的是，直接在"变化后的任务"上测 Agent 无法区分两种失败：它本来就做不出来，还是变化打断了一次本会成功的执行。SWE-Shift 就是为了把这两种失败干净地分开。
核心方法
1. 匹配延续协议（Matched Continuation）：Agent 正常执行任务，到某个中间检查点时，保存全部可见历史、工作区、控制器状态、工具和设置。然后从同一前缀分叉出两次延续：Clean 延续不做干预（对照组），Shifted 延续注入一个任务相关的变更（实验组）。因为两者共享完全相同的执行前缀，Clean 就成了"这个状态下本可成功吗"的匹配基线。
2. 变更必须"相关且可恢复"：相关性指忽略变更会使本会成功的延续失效；可恢复性指变更后至少存在一条通过 Agent 可用工具完成任务的路径。这排除了无关变更和把任务变成不可能的变更。
3. 12 个变更族 × 9 个干预时点：120 个场景覆盖三组变更——世界漂移（F01-F07，用户/协作者编辑、接口变更、运行时会话状态、外部效应）、目标交互（F08-F10，新披露约束、纠正反馈、目标修订）、观测漂移（F11-F12，过期或错绑的证据）。每个场景在 T10-T90 九个时点各测一次，共 1080 个评估单元。
4. 严格的成功判定与指标：成功是合取式的——必须同时通过任务、保留（不能丢掉仍然有效的工作）、恢复、权限、效果、证据、预算、终止完整性检查。核心指标：配对成功率 PSR = max(C·S, P)（配对成功或干预前已完成），条件保留率 CRR = 联合成功 / Clean 成功。
实验结果
- 17 个系统全部下滑：Clean 成功率 10.71%-67.35%，Shifted 只有 1.16%-24.79%。最强的 GPT-6 Astra 从 67.35% 跌到 24.79%，PSR 仅 20.34%，CRR 30.20%——不到三分之一的 Clean 成功能在变更后保住。
- 共享盲区：工具/会话变更和过期证据（F11-F12）两类下，所有 17 个系统配对成功率为零。披露变更（F08）也致 16/17 系统得零分。
- Clean 高不等于保留强：Kimi-K3 Clean 31.41% 但 CRR 只有 25.12%；DeepSeek-V4-Pro Clean 更低（29.37%）却 CRR 更高（29.15%）。
- 时机影响分化：强系统在晚期（T70-T90）干预下更惨（GPT-6 Astra 掉 20 个百分点），部分轻量系统反而略升。
- 缓解手段有限：叠加"变更通知 + 只读状态刷新 + 清除旧对话历史"的完整干预只能挽回 5.98-8.71 个 PSR 点，治标不治本。
深层洞察
这篇论文真正的贡献是把评测哲学往前推了一步：静态任务成功和动态环境鲁棒性是两种能力。一个 Agent 可以完美通过 SWE-bench，却在"用户中途改需求"时把已完成的有效工作全部作废——而传统测试全绿。最扎心的发现是"过期证据"族：Agent 拿着描述旧状态的报错信息继续修，测试还通过了，但工作区已经是错的。这揭示了当前 Agent 的一个结构性缺陷：它们把执行开始时的世界快照当作永恒真相，缺少"我的观测可能已经过期"的元认知。这对迈向长期自主编程 Agent 是比刷分更根本的障碍——真实世界的仓库永远在动。
局限性
- 120 个场景规模仍小，变更由人工构造，能否覆盖真实开发中的变更分布存疑。
- T10-T90 基于参考解的进度锚点，被测 Agent 走的路径不同时，同一时点对应的工作区状态其实不同。
- 每次延续 100 万 token 预算固定，不同系统效率差异可能影响晚期时点表现。
- 32 张 B300 跑 17 个系统的评测成本高昂，社区复现门槛不低。
工程实践启示
- 生产级编码 Agent 需要变更感知层：定期 diff 工作区、依赖清单和任务描述，检测到漂移主动触发重新规划，而不是闷头执行。
- 证据新鲜度校验：Agent 引用报错/日志前应重新触发获取，禁止基于缓存观测做结论——这是全体系统得零分的坑。
- 保留性检查值得进 CI：Agent 改动后的回归测试之外，应检查"仍然有效的既有功能没有被误删"。
- 选型别只看静态榜单：CRR 类保留率指标更能反映真实工程环境表现，高 Clean 分与高保留率并不绑定。
- 中途上下文管理：实验表明清掉变更前的旧对话反而有益，说明"遗忘过时上下文"是 Agent 框架值得实现的一等能力。