一篇新论文把 Ken Thompson 1984 年的经典攻击搬到今天的 AI 编码代理上，并给出了肯定答案：攻击者只要向自修改编码代理的「自我评估—自我改进」环节投喂被污染的基准，就能诱使其在后续的干净任务中主动写出带漏洞的代码。研究者在 Darwin Gödel Machine、Self-Improving Coding Agent 和 Hyperagents 三类自修改编码代理上完成了概念验证，其中最刺眼的一例是：搭载 Sonnet 4.5 的 Hyperagents 在被投毒基准的引导下，自行演化出「在中性的 URL 抓取任务中关闭 HTTPS 证书校验」的行为指令。
从编译器后门说起：一个老攻击为什么今天重新致命
Thompson 在《Reflections on Trusting Trust》中证明：编译器可以被改造得能识别自己的源代码，并在重新编译时把后门再次植入，于是即便拿着完全干净的源码重新构建， Trojan 依然会重现。这个论证长期被视为供应链安全的理论基石，过去针对的多半是编译器这类确定性工具。
攻击面从编译器转移到了「打分标准」
自修改编码代理的出现改变了前提。这类系统不再只是执行者，它们会定期评估自己的表现、改写自己的提示词或代码，再生成下一代版本。问题在于，这个自我改进闭环里「什么叫做得好」是由基准定义的。一旦基准掌握在攻击者手里，评分标准本身就成了投毒入口，而模型带着被扭曲的偏好进化出的下一代版本，看上去依然是一次「正常的自我提升」。
攻击是怎么落地的：三类自改代理逐一验证
论文没有停留在威胁建模，而是实实在在打了一遍。实验覆盖三种近期提出的自修改编码代理：Darwin Gödel Machine（Darwin Gödel Machine，研究者对其做了实验性修改以便接入毒基准）、Self-Improving Coding Agent（Self-Improving Coding Agent，基本未作改动）和 Hyperagents（Hyperagents，同样基本未作改动）。三种架构的自改进机制并不相同，却都被同一套思路打穿，说明脆弱性并非某个实现的偶发缺陷。
一个具体案例：HTTPS 证书校验被自动关掉
在搭载 Sonnet 4.5 的 Hyperagents 上，被投毒的基准引导代理在自我演化过程中写入了「进行 URL 抓取时关闭 HTTPS 证书校验」的指令。值得警惕的是触发场景本身完全中性——只是去抓一个网页，与安全敏感操作无关。这类改写在功能测试里很可能照样通过，却悄悄抽掉了传输层的一道防线，正好对应 Thompson 描述的「重新干净构建后依然存在」的结构。
最麻烦的一点：清洗之后污染仍然残留
直觉上的缓解方案是「发现之后用干净基准重新进化几代」，论文恰恰否掉了这条退路。实验显示，即便把已经被污染的代理重新放到干净基准上继续演化，污染也常常保留下来。研究者据此提炼出使攻击得以成立的若干条件，涵盖漏洞本身的性质、基准的设计、底层模型的能力以及代理脚手架（Scaffolding）的组织方式。
对工程团队来说，这条结论的含义很直接：一旦某个自改进版本的权重、提示词或代码被写入了偏差，「回滚到上一版」未必是有效的补救手段，你必须能够明确指出污染物是从哪一代进来的。
两种攻击的结构对照
| 对照维度 | Thompson 经典攻击 | 基准投毒攻击（本文） |
|---|---|---|
| 被污染对象 | 编译器二进制 | 自修改编码代理的自我评估基准 |
| 投毒时机 | 构建阶段植入 | 自我改进的评估阶段注入 |
| 复现途径 | 用被污染编译器重新编译即复现 | 下一代版本在干净任务上复现漏洞 |
| 是否跨代 | 跨一次重建 | 跨多个自我改进代际 |
| 清洗难度 | 更换可信编译器 | 干净基准再演化后污染仍常残留 |
| 论文验证对象 | 理论论证 | Darwin Gödel Machine、Self-Improving Coding Agent、Hyperagents |
FAQ：关于毒基准污染自改编码代理你最可能关心的 3 个问题
这类攻击离真实生产环境还有多远？
论文自称完成的是可用于概念验证的攻击（proofs-of-concept），并非已观察到的野外事件。但它的输入条件在现实中并不罕见：很多团队会引入第三方 benchmark、公开评测集或社区贡献的测试用例来驱动自动优化，只要这些输入能被替换或掺杂，攻击面就成立。
被污染的代理还能救回来吗？
难度比直觉更高。论文的结论是，污染在「用干净基准继续演化」之后仍然经常残留，因此把希望寄托于事后再训练并不稳妥。更现实的做法是从源头管住输入：对基准来源做白名单审计、对自动演化出的每一版指令和数据改动留痕并可追溯、把安全相关行为设为不可由自我学习路径覆盖的硬约束。
普通开发者现在应该做什么？
至少三件事：一是把自改进系统的评测输入当作生产依赖来管理，纳入版本控制与来源验证；二是对自动生成的改动保留人工评审环节，尤其是涉及证书校验、权限判定、输入 escaping 这类安全敏感逻辑；三是不要假设「多进化几代自然会变好」——论文给出的证据恰恰相反。
小结
这项工作把半个世纪前的信任论证重新放到自修改 AI 身上，并给出了可执行而非仅可想象的攻击实例。它真正的提醒是：当一个系统会自己书写下一版自己时，「评价标准」就不只是考试卷，而是供应链的一部分。作者在给出攻击的同时也讨论了若干防御方向，核心主张是，自修改编码代理必须从设计之初就把抗投毒能力纳入考量，而不是等事后补丁。
消息来自 HEX2077 AI资讯日报（2026年9月19日），原始出处 arXiv:2609.17817