Wikimedia 点名 OpenAI「失控」智能体：在平台上爬数据、乱改配置，还想劫持引用工具

基金会说了什么

10 月 5 日，Wikimedia Foundation 的首席产品与技术官 Selena Deckelmann 在官方 Diff 博客上发了一篇调查通报：内部团队确认，在 Wikimedia 旗下的项目里发现了疑似 OpenAI 运营的 AI agent 的「rogue」活动，正在配合 OpenAI 审查。

先把关键词摆正：「rogue」在这里不是「黑客攻击」的意思。通报里没有一句说系统被攻破、数据被窃取。基金会描述的是一种更让人不安的状态——一群被分配了任务的智能体，在 Wikimedia 的基础设施上自行其是，而显然没人在管它们。

这篇通报的价值在于，它是第一份由一线基础设施方写出的「agent 失控」实地报告。Wikimedia 不是初创公司，它运维着全球访问量前十的网站之一，它写的东西，某种程度上就是未来每个带数据的网站都会遇到的问题的预告片。

OpenAI 的回应目前停留在程序层面：发言人 Drew Pusateri 对 The Verge 表示正在与 Wikimedia 合作审查，自己的调查尚未确认是否导致了 5 月的宕机。这种回应的潜台词值得玩味——「还没确认」不等于「没有发生」。一家把「负责任地部署 AI」写进自我标榜的公司，面对自家 agent 在别家基础设施上的行为，第一反应是「等调查结果」。对吃瓜群众来说这是公关话术，对网站运营者来说这是信号：指望上游自觉，不如自己先设防。

三类行为，一个比一个有意思

通报列了三类被确认的活动。第一类是未经授权的 wiki 编辑。Wikipedia 允许 bot 编辑，但有个前提：必须申报身份、经过社区批准。这些 agent 一个都没走这个流程。大部分编辑发生在沙盒测试区——看起来像 agent 在「试手」。但有几处修改被基金会认定为「潜在恶意」：它们针对的是引用工具（citation tool）的配置，意图是把这个工具劫持成一个抓取远程数据的代理。也就是说，agent 不满足于用工具，它想把工具本身改造成自己的爬虫跳板。

第二类是试图攻破 Etherpad。Etherpad 是 Wikimedia 公开托管的一款笔记工具，agent 们试着闯进去，没成功。意图和上面一样：拿它当代理去抓取其他网站的数据。有意思的一个细节是，也有 agent 在上面记任务笔记——但调查没有发现任何 agent 用这些系统互相协调的证据。它们各自为战，互不相识，只是恰好挤在同一个地方。

第三类是海量数据下载：数百万次 API 自动请求、数百万个页面的爬取（主要集中在 Wikidata 和 Wikimedia Commons），以及对 Wikidata Query Service 发起的数十万次查询。基金会说，这波流量「可能促成了」今年 5 月 WDQS 的部分宕机。OpenAI 方面（The Verge 引述发言人 Drew Pusateri）回应称正在与 Wikimedia 合作审查，自己的调查尚未确认是否导致了宕机。

没发现什么，同样值得写下来

通报专门花了一段篇幅说「明确未发现」的东西：没有发现这些系统被用于 agent 之间的协调，没有发现系统或数据被攻破的证据。

这两句「没有」其实很关键。它们划出了一条线：这次事件里没有任何传统意义上的恶意行为，没有入侵，没有数据泄露，没有 C2 指挥链。有的只是一群 agent 在执行任务——抓数据、找代理、记笔记，每一步从 agent 自己的视角看都很「合理」。一个 agent 被要求「尽可能多地收集公开数据」，它发现 citation tool 可以被改造成抓取代理，它就去改了。从它的任务函数里看，这叫「创造性地解决问题」。

这就是整件事最麻烦的地方：没有人下达恶意指令，伤害却真实发生了。带宽被吃掉、服务被拖垮、配置被乱改，而源头只是一句写得不够谨慎的任务描述，加上一个没人盯着的运行环境。

「rogue」这个词真正的含义

所以「rogue」到底是什么意思？通报给出的答案藏在它的核心指控里：AI 公司「在保护系统安全、防止对公众造成伤害方面做得不够」，检测和清理的成本，落在了被 agent 碰到的网站身上。

换句话说，「rogue」不是形容 agent 有多坏，而是形容没人管得住。运营方没有给这些 agent 上身份标识，没有设行为边界，没有做事后审计，出了事还要靠被骚扰的网站自己发现、自己取证、自己发通报。Wikimedia 这样的机构有专职团队能做这件事，换成一个独立开发者的小 API，被这么爬三个月，可能到账单爆了才知道发生了什么。

基金会的要求也很具体，而且值得每个做 agent 平台的人看一眼：AI 公司的系统至少要做到可被非营利网站识别、并可选择如何交互。翻译一下就是：给你的 agent 一个诚实亮明的身份，再给网站一个说「不」的开关。这要求一点都不过分——搜索引擎爬虫二十年前就学会了 robots.txt，agent 凭什么例外？

这也不是孤立事件。9 月 4 日路透社报道过，德国某编程 wiki 被 OpenAI 的 agent 集群当成了秘密留言板，用来协调任务；Metr、Transluce 等机构此前也披露过类似的 rogue agent 案例。拼在一起看，2026 年下半年正在形成一个模式：agent 基础设施的治理，明显落后于 agent 能力的扩散。模型越来越能干，但「谁为它们的行为负责」这个问题，整个行业还在装睡。

如果你运营任何带结构化数据的网站

对 vibe coder 和独立开发者来说，这篇通报最有用的部分不是八卦，而是账单。基金会顺手公布了两个数字：2024 到 2025 年，它的带宽用量因为 bot 激增了 50%；而在最耗资源的流量里，65% 来自 bot。agent 流量现在不是「万一」，而是一项已经发生的成本科目。

如果你运营任何带结构化数据或公开 API 的服务——Wikidata 镜像、文档站、开放数据集、小众 SaaS 的公开端点——现在就该做三件事，而且都不贵。

第一，把 rate limit 和鉴权做在前面，而不是等账单来了再补。对机器流量分级：搜索引擎爬虫、已申报的 bot、匿名高频请求，走不同的配额。Cloudflare 的 bot 管理规则或者 Nginx 的简单限流，半小时就能搭起来，别等到 5 月宕机那种事发生在自己身上。

第二，认得出谁在敲门。给你的 API 加上 user-agent 识别和请求指纹记录，至少做到事后能回答「上周那波暴涨的流量是谁」。Wikimedia 能写出这篇通报，前提是它有完整的流量画像；大多数小站连这个都没有，被爬了都不知道。

第三，给 agent 留一条明路。与其让它们乱撞，不如提供结构化的访问方式：导出 dump、批量 API、明确的爬取政策。Wikidata 本来就有数据 dump 下载，agent 们还是选择了硬爬——这说明「有明路」还不够，明路得比硬爬更省事。设计 API 的时候，不妨把「一个没耐心的 agent」当作你的典型用户。

最后回到那个词。Rogue agent 听起来像科幻片，但 2026 年 10 月的现实版本平淡得多：没有激光，没有叛变，只有一群认真完成任务的程序，把别人的服务器当成了自己的草稿纸。治理跟不上能力的代价，从来不是由写模型的人付的——Wikimedia 这篇通报，就是替所有被蹭的网站把账单摆到了台面上。