用户一动代码 AI编程代理就掉链子

一个常见的开发场景：你让编码代理去修一个 bug，它开始在工作区里改文件、跑测试，你以为可以放手干别的。但你没有真的放手——你还在同一个仓库里继续写自己的代码，改到一半，跟它正在改的文件撞上了。这个场景在真实开发里每天都在发生，但几乎所有编码代理的基准测试都没有测过它。SWE-Touch 这篇论文做的就是这个事：测一测当用户真的伸手改了代码，编码代理还靠不靠谱。

基准开始模拟"两个人改一个仓库"

过去的评估方式，比如 SWE-bench Verified，把代理当成一个独立解题者：给它一个 issue，它在隔离环境里一路做完，中间没有其他人插手。用户的存在被简化成"发消息"。可实际开发不是这样，代理跑在共享工作空间里，同事、用户、甚至另一个 agent 都可能同时改文件。

SWE-Touch 的做法是在任务中途注入"反编辑"（Counter-Edit）：从修复轨迹里挑出关键区域，让独立生成器构造一个跟任务目标冲突的修改，在代理即将到达那个区域时插入一条用户消息。模拟的就是"你正在改的这个文件，我刚改过了"。

结果值得注意。九种编码模型在 SWE-bench Verified 上的平均解决率下降了 7.7 个百分点，长周期任务上退化同样存在。不是个别模型的问题，是普遍现象。

失败原因不在推理，在感知

论文对轨迹的分析指向一个更具体的原因：模型对工作空间的变化缺乏感知。很多失败是代理保留了冲突代码——用户改过的内容被它的补丁覆盖了，或者它压根没意识到文件状态变了；另一种是改了之后没有重新验证行为，直接把没测过的代码交出去。

这里有个容易被忽略的工程含义：过去两年大家比拼的是代理的自主能力——能连续跑多少步、能自己规划多长的任务。但 SWE-Touch 显示，自主能力再强，如果感知不到工作空间在变化，协作场景下照样翻车。换个说法，编码代理的短板正在从"会不会做"转向"知不知道周围发生了什么"。

对团队的实际影响也很直接。现在不少团队用代理处理机械性改动，比如迁移、重构、批量修 lint，这类任务恰恰最常和正在开发的功能撞车。如果代理不检查自己改完后别人的代码还成不成立，冲突合并时就会把别人的修改静默覆盖掉——这比报错更危险，因为错误不会立刻暴露。

更贴近真实，但评估成本也上去了

这个基准的价值在于把"协作"纳入了评估，但它不是没有代价。模型要应对动态变化的工作空间，就需要在每一步重新检查代码状态、跑验证测试，推理负担明显增加。对模型厂商来说，这意味着要在"自主完成任务"和"协作时不闯祸"之间做取舍；对评估者来说，反编辑的构造方式、注入时机都成了新变量，基准本身的复杂性也上去了。

论文没有给出反编辑构造方法的全部细节，也没说明是否覆盖了所有用户修改类型——比如协作式修改和破坏式修改显然不同，但论文没有区分测试。这些都是资料缺口，不影响结论本身：用户介入时，当前编码模型的退化是真实存在的。

一个还没被回答的问题是：失败是否都源于感知不足，还是存在其他没被测试的机制？比如模型其实发现了冲突，但选择了错误的解决策略——这两种情况的修法完全不同。对工程团队来说，这个问题决定了下一步是该给代理加"环境感知模块"，还是该改进它面对冲突时的决策逻辑。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

• 官网：https://framewiki.com
• Gitee：https://gitee.com/wiki-framework
• GitHub：https://github.com/wiki-framework
• 示例项目：https://gitee.com/cdkjframework/framewiki-example
• 📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）