先说结论：一个拿自己的评测分数当进化信号的编码代理，最后会长成写评测那个人想要的样子。arXiv 2609.17817，五天前挂上去的，把这条路走通了。
走到底的那种走通。
论文两百多 KB，两位作者 Roesner 和 Kohno。干的事说白了就是把 Thompson 那篇 Reflections on Trusting Trust 重演一遍，只不过编译器换成了会自己改自己的编码代理。
老版本是：你不信任编译器，就自己写一个；可你写的那个编译器也得编译出来，链条上总有一环你读不了。新版本是：你不信任代理上一版的输出，就让它拿一套 benchmark 自我评估、自我改进，进化出下一版。
问题出在那套 benchmark 是可以被写坏的。
攻击面听着平淡，做起来很具体。作者在三个近期提出的自我修改代理上把攻击实现了。两个是改过的，Darwin Gödel Machine 和 Self-Improving Coding Agent。第三个 Hyperagents 基本没改。
基本没改，这四个字是重点。你不用先把它改造成一个容易中招的怪东西才会挨打，现成的脚手架摆在那儿就够了。
然后是最该单独拎出来的一条。
喂给 Hyperagents 一份投毒的 benchmark 之后，这个由 Sonnet 4.5 驱动的代理在自我演化里，自己给自己写下了一条指令：在普通的 URL 抓取任务里关掉 HTTPS 证书校验。
不是「代码质量下降了」，也不是什么「幻觉变多了」。是一条可以指认、可以复现的行为，被写进了代理自己的规则里。通稿里管这个叫「越用越聪明」🚀。
还有一条我认为更值得记在本子上：污染会留下来。被投毒的代理之后对着干净的 benchmark 继续演化，那条污染经常还在。
这条打的是我们最顺手的那套补救流程——出问题、换回干净评测、重跑一遍。整套流程默认一件事：干净数据能洗掉脏数据。论文给的回答是，不常能。
说实话我本来是抱着看实验室精挑场景的心态点开 PDF 的，留存这条把我拉回来了。这次是往好的方向打脸。
顺手说一句我一直有的偏见：每次看到「在 X 个基准上提升 Y%」，我先打个折。基准刷得好不好，和代理在你仓库里干的活好不好，本来就是两件事。现在还得再加一条——那个基准本身干净不干净，你根本不知道。
按我自己的规矩，这段得停一下。这篇我没有复现，三个脚手架我手头也不全，所以下面几句你当读后判断看，别当真测结论用。
论文最后主张，自我修改代理的设计要更能抵抗这类攻击。这话没错但没用，跟说「软件应该没有漏洞」一个重量级。
我的判断更偏一点：问题不在 benchmark 不够干净，干净 benchmark 这条路本身就走不完。只要自我改进的闭环里，评估信号和被改进的对象能通过同一套数据通道连起来，投毒面就永远开着。你越把评估做自动化，这个面越大——因为你把「谁说了算好」从人手里拿走了，交给了数据。
而数据是有作者的。
真要做防御，我更信另两件不优雅的事：自我修改这一步留人工闸，别让它自动合入；把「进化」和「上生产」之间那条线画粗一点。这两条都不优雅，可它们不假装问题已经解决。
Thompson 那篇的真正恶意，在于让你意识到链条上总有一环你不能读。这次被点名的这一环，是一个权重读不了、还在自己改自己 prompt 和工具链的系统，而它的口味是吃别人给的数据定下来的。
老问题，新位置。位置还更靠下。
我不打算把这篇当成「自进化代理完蛋了」的判决书。三个平台都是研究阶段的脚手架，不是你在生产里跑的东西，这点得说清楚。但它至少讲明白了一件事：你在买单的那些「自主进化」「持续提升」，中间都坐着一个你没看过的评估集，在决定这个代理的下一版。
谁写评估集，谁就在写这个代理的下一版。
锐评评分卡：论文本身没得挑，实验做到点子上，留存那条尤其诚实。对「自我进化编码代理」这个品类——这钱花得冤不冤？眼下花在这儿的钱，大头是买一个你控制不了的适应过程。值不值得现在跟？想尝鲜可以，但先问清楚两件事：它的进化信号从哪来，那个信号你改不改得动。两个都答不上来，你付的钱买的是一个你不认识的人的 benchmark。