每日论文精读 #069：任务做到一半环境变了，所有编码Agent都扛不住

📌 系列导航：🔥 日报 · 📚 周报 · 📡 技术雷达 · 📄 论文精读 · 📮 情报站

论文信息

一句话总结

SWE-Shift 用「同一执行状态分叉出干净/被干扰两条续跑路径」的配对实验设计证明：当前所有主流编码 Agent 在任务执行中途遭遇环境或需求变化时成功率大幅崩塌——最强的 GPT-6 Astra 从 67.35% 掉到 24.79%，配对成功率仅 20.34%。

解决什么问题

现有仓库级基准（SWE-bench 系列）都默认一个隐含假设：任务开始后，代码、依赖、运行时状态、需求都保持冻结。但真实软件开发是动态的——同事改了代码、依赖升了版本、用户中途补充需求、日志里的信息已经过时。这些「执行中途的变化」会让一个本来能成功的 Agent 全盘崩溃，而传统基准完全测不出来。更关键的方法论问题是：如果只在「变化后的任务」上测失败，你分不清是 Agent 本来就做不出这道题，还是变化毁掉了一次本可成功的执行。

核心方法

配对续跑协议 是全文最漂亮的设计。Agent 先正常执行任务，到预定检查点时保存全部可见状态（历史、工作区、控制器状态、工具、系统设置），然后从同一前缀分叉成两条续跑：

• Clean 续跑：不加干预，作为该中间状态下「能否成功」的配对基线；
• Shifted 续跑：在分叉点注入一个任务相关更新。

两条路径共享完全相同的动作前缀，唯一差异就是那个变化，从而把「任务能力」和「抗干扰能力」干净地解耦。

基准包含 120 个场景 × 12 类变化族 × 9 个干预时点（T10–T90，按参考解进度 10%~90%），变化分为三组：World Shift（F01–F07，用户/协作者编辑、接口变更、运行时会话状态、外部效应）、Goal Interaction（F08–F10，新增约束、纠正反馈、目标修订）、Observation Shift（F11–F12，过期证据、证据错绑）。

每个变化必须同时满足相关性（忽略它会使本可成功的续跑失效）和可恢复性（变化后至少存在一条经工具可达的正确完成路径）。判定是合取式的：不仅要做完任务，还要通过保留（不破坏仍有效的工作）、恢复、证据（对当前状态有效）等检查。主指标 PSR = 配对成功率（两条续跑都成功，或干预前已完成），辅以 CRR（Clean 成功中被 Shifted 保留的比例）。

实验结果

• 17 个编码 Agent 系统（GPT-6 Astra、Claude Opus 5、Claude Fable 5.1、GPT-5.6 Sol、Kimi-K3、DeepSeek-V4-Pro 等）无一例外 Shifted 成功率低于 Clean。
• GPT-6 Astra：Clean 67.35% → Shifted 24.79%，PSR 20.34%，CRR 30.20%——即它的干净成功中只有不到三分之一能在变化后保留。
• 工具/会话状态变化（F04）和过期证据（F11）对所有 17 个系统 PSR 均为 0.00%——全军覆没。
• Clean 高不代表稳健：Kimi-K3 Clean 31.41%、PSR 8.20%；DeepSeek-V4-Pro Clean 更低（29.37%）但 PSR 更高（8.83%）。
• 干预时点的影响不单调：晚时点 PSR 对部分系统更低、对另一些更高，说明鲁棒性不是「越早/越晚变化越难」的简单规律。

深层洞察

这篇论文真正的贡献是给「Agent 可靠性」提供了一个新维度：静态任务成功 ≠ 动态环境下的可用性。一个 Agent 可以完美通过所有原有测试，但同时弄丢了仍然有效的旧工作、没恢复运行时状态、引用了过期证据——这些失败在传统基准上完全隐形。配对续跑的设计把「能力」与「稳健性」分离，也解释了为什么榜单排名和实际落地体验经常背离。工具/会话状态变化全员归零尤其值得警惕：Agent 普遍把会话内缓存的世界模型当成真理，从不怀疑自己的记忆可能已经失效。

局限性

• 场景构建依赖人工设计的授权变化和参考解前缀，规模（120 场景）相对 SWE-bench 仍小；
• T10–T90 是按参考解进度定义的，被测 Agent 走的路径不同，同一标称时点的实际状态可能差异很大；
• 干预是单次的、可恢复的，未覆盖多次连续变化或不可恢复的恶意变更；
• 评测 17 个系统的成本不低（每续跑 100 万 token 预算），复现门槛偏高。

工程实践启示

• 设计长时编码 Agent 时必须假设环境会变：定期重新校验关键假设（文件 mtime、依赖版本、任务描述哈希），而不是信任会话内缓存。
• 完成判定要对「当前状态」取证，不能拿旧观察当证据——这在论文里是所有系统的共同死穴。
• 「保留已有效工作」应成为显式检查项：变更后重写整个文件/重置环境往往会摧毁本可保留的成果。
• 内部评测可以借鉴分叉协议：在 Agent 执行中途注入变更，是性价比很高的鲁棒性回归测试。