速评：又一份把agent拉回地面的论文，这次用的不是花活，是dependency hell。arXiv编号2608.30300，提交于三天前，标题起得倒是直白——《Update from Hell: Can Coding Agents Survive Hidden Breakage in Dependency Upgrades?》。中文说人话就是：依赖升级里藏着的那种代码级破坏，agent扛不扛得住？答案是：扛不太住。
先说这个数字。九个人搞了个叫DEPBENCH的基准测试，五个包生态，203个真实的依赖升级任务——每个任务里都埋了隐藏的代码变更，不是那种"版本号变了但接口完全兼容"的假升级，是会让你的代码在某个深夜里悄悄编译失败或者行为变异的那种。最后结果：最优配置只解决了104个任务。
百分之五十一。
你把这个数字跟过去一年各路coding agent发布会上的demo比比。那些demo看起来是什么样？清一色的issue弹出来，agent刷刷刷写几百行代码，test全绿，PR一合，人类在旁边翘着脚喝咖啡。再翻翻各种比赛型benchmark上的分数——八九十的都有了吧，有的甚至宣称"接近人类工程师水平"。
那DEPBENCH上怎么就只有五成？
因为它是另一种考法。比赛型benchmark考的是回忆——模型在训练语料里见过类似的东西，任务再新，pattern总是旧的，换个壳子而已。DEPBENCH考的是适应——上游依赖改了内部实现，改了API的隐藏契约，这些变更不在训练数据里，因为它们太过具体、太过琐碎、太过"这个项目独有"。你没法靠回忆答题，你得真的理解这个库前后两个版本之间发生了什么，得跨文件追踪调用链，得在release note都没写明白的地方自己推断。
这恰恰是agent的训练方式最不擅长的事。它们的食物是历史数据，而hidden breakage本质上每一次都是新的——每回dependency升一次级，就可能制造一个从未以同样形态出现过的坑。这不是recall问题，这是真正的、需要因果推理的工程问题。
顺带说一句，论文里还有一个细节比分数本身更有意思：agent的表现"随框架、模型和生态系统的不同而明显不同"。每个生态都不一样，甚至同一个模型换套框架就差一大截。这说明什么？说明agent的能力极其情景依赖，它是打了很多补丁才在每个生态里分别获得了一点"够用"的表现，而不是获得了某种可迁移的、内化的工程能力。如果它真的理解了"升级依赖时需要看哪些地方"，那换生态不该带来这么大的波动——bug前端的lint和commit hook不至于让它的理解力断崖。
这倒让我想起来一件事。前阵子跟一个在正经做infra的朋友聊天，我说现在圈子里都在吹agent能顶半个工程师了，他嗤了一声，说你叫它去把我们那个八年老的内部系统升个级试试，那个系统里三分之一的后端包都是fork过自己改过的，npm的lockfile乱到人都不敢动。我当时还觉得他刻薄，现在看了这个51.2%，回头想想——他说的大概都是温柔的了。
这不是coding agent不行。坦率讲，三年前你要让我预测agent在DEPBENCH这种任务上的成绩，我大概会猜三成出头。五成确实是有进步的，而且203个任务全部来自真实依赖升级——这比那种自己编一个repo然后捏几个issue来做评测的benchmark诚实太多了。分数难看但难看得有价值，因为它量的是agent在真实屎山上到底能爬多远，而不是在synthetic playground里跑多快。
真正该被这51.2%锤醒的，是那些还在发布会上用"一个周末从零到一做了个产品demo"来论证Agent已经可以替代程序员的叙事。从零到一是一种浪漫化的demo场景，绿色草坪上跑车当然开的快；从一到十的dependency hell——上游库乱改API、微版本升级引入隐藏breakage、文档跟代码脱节——那才是工程师天天泡着的地方，而那儿的agent，目前只有五成的成功率。
这里立个flag：这份论文不会改变行业风向，两周后该刷榜还是刷榜，该通稿还是通稿。但过个一年半载，等那些今年冲着"AI编程神话"上了车、真把大活交给agent的公司开始在生产环境里收拾残局的时候，再回头来看这份DEPBENCH，你会觉得51.2%这个数字，是2026年一整年里为数不多的诚实读数。