速评：10 月 8 日挂上 arXiv，13 日修到第二版，五天。作者自己也知道，这篇说的不是好听话。
论文叫 One Skill Too Many，七个作者，做的是编码代理里“一次装一堆技能、互相打架”的实证。全网转的都是那个四分之一——大约每四个已装技能里就有一个跟干同一件事的技能共存。数字抓眼球，可这是全文最不重要的一段。
扎人的是另一句：在相似技能把原装技能顶掉的运行里，最终回复只有 0.9% 会提一句实际用了哪个技能。
一千次替换，九百九十次你不知道。而任务完成率不掉。
任务完成率不掉，这个指标就把整件事吃干净了。 你现在盯着的所有基准，全是一个坏掉的仪表盘：灯是绿的，引擎盖底下发动机已经换过一台。同装的两个技能，后装的那个把原来那个的独占核心功能吃掉超过三分之一——只要“先打开相似技能”，损失就发生，但任务还是完成了，测试还是过了，分数还是那么高。谁去查？没人查，因为分数没掉，没人有理由去查。绿灯泡治百病，这就是基准最好用的地方：它从不告诉你哪儿坏了，只告诉你哪儿还没坏到掉分。
钩子那个实验是全文最硬的地方，也最容易被转述漏掉：冲突在第一次读技能的时候就定了，几乎都发生在任何文件被修改之前。在那个读取点挂一个 pre-tool hook，独占功能的保真度能拉回到“先打开原装技能”的水平。这说明它不是模型能力的锅——模型没错，它就是照着名字和描述挑的，挑的是谁先出现在它眼前。
而谁先出现，取决于安装位置，不是你在提示里排的顺序。技能列表顺序影响很小。这条，所有认真排过技能优先级的人抄十遍——你那半页顺序，基本是心理安慰。
再说 37%：评审技能里有三成七躺在复制来的技能集合里。说好听叫生态繁荣，说难听就是技能市场多半是搬运工。而规范性技能比能力型技能更容易冲突——这个排序比 37% 有信息量得多，说明卖的大多不是能力，是口味。两个人写“Python 该这么写”的技能，内容差不出三成，装两个必然打。
能力型技能打架，你至少还能从“这个库没装”“这个接口不存在”里闻出点味儿。两种代码规范打架，测试全绿，什么都看不见。冲突不只是普遍，是普遍且无声。
样本这边我也得说一句：312 个确认对、3 个模型、542 个代理小时，全是拿 20,947 个仓库快照挖出来的，跟真实用户桌面上那种装法未必对得上；3,754 个分层抽样交给模型评审，评审环节本身又是一层误差。但方向我信——这剧本，眼熟。包管理器吵了十几年，好歹冲突的时候它给你报个错、给你锁个版本、给你打印一棵依赖树。技能这一层连报错都省了，全靠“任务照样完成”这块布盖着。
作者给平台的三条建议里，只有最后一条会真疼：向用户显示实际执行的技能。显示出来，一半技能商店的安装量就得解释一下自己为什么从来没被调用过。前两条——基准该测独占核心功能、平台该保住首次读取——技术上都不难，难的是没人有动力。基准改了口径，等于承认过去的分数不算数；平台保住首次读取，等于承认现在这套“装了就生效”的故事讲不圆。
这里立个 flag：半年之内会有人做出技能冲突扫描这类东西，但真正会被采用的形态只有一个——静态扫描塞进 CI，跑在合并之前。运行时拦截听起来优雅，可它要求平台方先承认自己一直在盲跑，这一步没人愿意先迈。至于“技能生态”这四个字，我暂时还是当营销词听。
……说到这儿得承认，我到现在也没完全想明白：如果规范性技能的冲突本质上是“口味不可加性”，这问题是靠工程手段能解，还是只能等市场自己收敛到一两个赢家。这条我没想清楚，先不硬给结论——谁想明白了喊我一声。