先说结论：把这篇论文读完了，结论一句话——现在的编码智能体，根本没你们以为的那么靠谱。
SWE-Touch，arXiv 编号 2608.02499，八月三号挂出来的。做法不复杂：往智能体干活的工作区里塞点「冲突编辑」，看它会不会发现。什么叫冲突编辑？就是跟你正在写的任务直接打架的代码改动——你正写到一半，隔壁同事把你要用的函数顺手改了实现，还没告诉你。
官方口径：这类智能体「在真实场景中表现出强自主性」。
实测数据：九个模型，平均解决率掉了 7.7 个百分点。
数字不大是吧。我第一反应也是就这么点？但问题不在平均，在分布。有个模型遇到冲突编辑直接当场露馅，输出里保留着跟任务目标对着干的代码，自己根本没意识到。连「有人动过我的东西」都感知不到，谈什么协作。
SWE-bench Verified: 平均解决率变化 -7.7 points
SWE-Bench Pro: 进一步下降
DeepSWE: 进一步下降
越往长时程任务走，掉得越狠。这个才对——时间越长，工作区里被人动过的概率越大。智能体全神贯注执行自己的计划，旁边发生了什么，跟它无关。
轨迹分析里有一段我读完特别有共鸣：失败原因排第一的是「保留冲突代码」，第二是「未充分重新检查代码库」，第三是「未针对修改后的代码运行定向测试」。这哪是编码智能体的毛病，这说的就是我。我在这行这么多年，这种雷踩过不止一次：以为自己在正确方向上跑得飞快，实际上早就岔了路。人尚且如此，把这种模式塞进模型里，倒是原汁原味。
有个事我一直没想明白：为什么之前一堆基准没把这个测出来？现在回头看，答案很清楚——那些基准全是「一个人一杆枪从头跑到尾」，代码库从零建，没有外部干扰。这种环境本身是童话。真正的开发不是一个人在真空里写代码。SWE-Touch 是我见过的第一个把「共享工作区」这个变量认真往死里整的基准。
这波冤不冤——不冤。这论文至少把真问题定义出来了：检测工作区变化、协调冲突编辑与任务的关系、验证受影响的行为。这三条就是未来要啃的骨头。这种问题定义，比看十个「效率提升 100%」的通稿有营养得多。
但真冤。论文八月三号挂的，今天八月十三。这十天我盯着主流模型厂商的 changelog 翻来覆去地看——一字没提。明明是真实协作场景的命门，整个行业还在刷自己的 benchmark 榜，拿单机模式的数据当招牌。评测了个寂寞。
我最近也在琢磨自己是不是该改改工作方式——不是模型的问题，是人的问题。人都不太感知得到代码库是自己改的还是别人改的，模型感知不到，那是能力边界；人感知不到，那是工作习惯崩溃。
真正的结论是：编码智能体需要的不是更强的推理能力，是能「闻到」工作区里变化的嗅觉。这个能力不补上，别的堆再多也白搭。这波不冤，真冤的是那句「强自主性」——连隔壁同事动了你的代码都闻不到，自主个鬼。
