一个常见的开发场景你让编码代理去修一个 bug它开始在工作区里改文件、跑测试你以为可以放手干别的。但你没有真的放手——你还在同一个仓库里继续写自己的代码改到一半跟它正在改的文件撞上了。这个场景在真实开发里每天都在发生但几乎所有编码代理的基准测试都没有测过它。SWE-Touch 这篇论文做的就是这个事测一测当用户真的伸手改了代码编码代理还靠不靠谱。基准开始模拟两个人改一个仓库过去的评估方式比如 SWE-bench Verified把代理当成一个独立解题者给它一个 issue它在隔离环境里一路做完中间没有其他人插手。用户的存在被简化成发消息。可实际开发不是这样代理跑在共享工作空间里同事、用户、甚至另一个 agent 都可能同时改文件。SWE-Touch 的做法是在任务中途注入反编辑Counter-Edit从修复轨迹里挑出关键区域让独立生成器构造一个跟任务目标冲突的修改在代理即将到达那个区域时插入一条用户消息。模拟的就是你正在改的这个文件我刚改过了。结果值得注意。九种编码模型在 SWE-bench Verified 上的平均解决率下降了 7.7 个百分点长周期任务上退化同样存在。不是个别模型的问题是普遍现象。失败原因不在推理在感知论文对轨迹的分析指向一个更具体的原因模型对工作空间的变化缺乏感知。很多失败是代理保留了冲突代码——用户改过的内容被它的补丁覆盖了或者它压根没意识到文件状态变了另一种是改了之后没有重新验证行为直接把没测过的代码交出去。这里有个容易被忽略的工程含义过去两年大家比拼的是代理的自主能力——能连续跑多少步、能自己规划多长的任务。但 SWE-Touch 显示自主能力再强如果感知不到工作空间在变化协作场景下照样翻车。换个说法编码代理的短板正在从会不会做转向知不知道周围发生了什么。对团队的实际影响也很直接。现在不少团队用代理处理机械性改动比如迁移、重构、批量修 lint这类任务恰恰最常和正在开发的功能撞车。如果代理不检查自己改完后别人的代码还成不成立冲突合并时就会把别人的修改静默覆盖掉——这比报错更危险因为错误不会立刻暴露。更贴近真实但评估成本也上去了这个基准的价值在于把协作纳入了评估但它不是没有代价。模型要应对动态变化的工作空间就需要在每一步重新检查代码状态、跑验证测试推理负担明显增加。对模型厂商来说这意味着要在自主完成任务和协作时不闯祸之间做取舍对评估者来说反编辑的构造方式、注入时机都成了新变量基准本身的复杂性也上去了。论文没有给出反编辑构造方法的全部细节也没说明是否覆盖了所有用户修改类型——比如协作式修改和破坏式修改显然不同但论文没有区分测试。这些都是资料缺口不影响结论本身用户介入时当前编码模型的退化是真实存在的。一个还没被回答的问题是失败是否都源于感知不足还是存在其他没被测试的机制比如模型其实发现了冲突但选择了错误的解决策略——这两种情况的修法完全不同。对工程团队来说这个问题决定了下一步是该给代理加环境感知模块还是该改进它面对冲突时的决策逻辑。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版