Wikimedia 點名 OpenAI 代理：54 筆編輯有 46 筆在沙盒、5 筆動了引註工具

2026 年 10 月 5 日，Wikimedia 基金會的產品與技術長 Selena Deckelmann 發了一篇文章，標題是〈在 Wikimedia 專案上發現 OpenAI 的「失控」代理活動〉。基金會說，它認為由 OpenAI 操作的 AI 代理在沒有社群核准的情況下編輯了維基、試探了基金會託管的一個共筆工具，並發出了大量的自動請求。

這篇是本站今天稍早發的。舊版照文章整理了三類發現，並在結尾承認「編輯的具體筆數本文未列出，基金會提供的是一份 CSV 清單」。那份清單是公開的，所以這次我把它下載下來數了。另外，文章連到一份 5 月的事故報告，舊版只引了「可能有助長一次局部停機」這句話，沒有去讀報告本身。這次兩件事都補上，也把舊版寫錯的一個職稱改掉：Deckelmann 的頭銜是產品與技術長（Chief Product & Technology Officer），舊版寫成技術長。

先講這篇文章的語氣，因為它決定了整件事該怎麼讀。原文從頭到尾用「我們認為」來做歸因，「失控」兩個字加了引號。基金會公布的是它的調查結論和一份清單，沒有公布它是怎麼判斷這些活動來自 OpenAI 的。

Wikimedia 說它找到了什麼，沒找到什麼？

圖 1：文章說明調查範圍與結論的兩段（來源：Wikimedia Diff）

文章開頭交代了調查的起因。最近有好幾個組織揭露成群的 AI 代理嘗試闖入網站和線上服務，其中 OpenAI 環境裡的代理已知用過其他公開的維基站台來互相通訊和協調。那些站台不屬於 Wikimedia，文章這裡連到 METR 對 OpenAI 與 Hugging Face 事件的調查，本站有一篇那次事件的整理。基金會因此自己查了一次，重點放在 OpenAI 的代理。

結論分成有和沒有兩邊。

圖 2：七個項目的對照（資料來源：Wikimedia Diff）

沒找到的那三列跟找到的一樣重要。基金會的原話是：我們沒有找到任何證據顯示我們的系統被用於代理之間的協調，也沒有找到系統或資料被入侵的證據。那些編輯沒有發布到一般讀者看得到的頁面。

找到的部分，原文是三段。

圖 3：三類發現的原文（來源：Wikimedia Diff）

維基編輯。 基金會找出了一批它認為來自 OpenAI 代理的編輯，幾乎全是沙盒區的測試編輯。另有少數幾筆改了一個引註工具的設定，基金會認為這幾筆可能有惡意，目的是把那個工具誤用成代理伺服器，去抓遠端服務的資料。維基百科的政策允許機器人編輯，條件是事先揭露並取得社群核准，這些事件裡沒有人申請過。

Etherpad。 這是基金會當成社群服務託管的公開共筆工具。基金會認為由 OpenAI 操作的代理嘗試入侵它，沒有成功；也嘗試把它當成跳板去抓其他網站的資料，同樣沒有成功。另外有一些可能也是 OpenAI 的代理在上面記了自己任務的筆記，基金會說這看起來沒有發展成協調。

過量下載。 對公開 API 發出數百萬次自動請求，爬了數百萬個頁面，主要是 Wikidata 和 Wikimedia Commons，並對 Wikidata 查詢服務（WDQS）做了數十萬次查詢。

那份編輯清單裡有什麼？

文章裡「edits to Wikimedia wikis」這幾個字連到一份 CSV 檔，放在基金會的安全網站上，檔名標的日期是 10 月 4 日。我把它下載下來，每一列是一個編輯差異的網址。我依站台和頁面名稱數了一遍。

圖 4：清單逐列計數的結果（本文計算，原始檔案為 Wikimedia 公布的 CSV）

清單一共 54 筆，分布在 9 個站台。最多的是測試用的 test 維基 13 筆，其次是英文維基百科 11 筆、Incubator 8 筆、Commons 和 Meta 各 6 筆，另外有 test2、MediaWiki 官網、簡易英文和保加利亞文維基。

54 筆裡有 46 筆的頁面名稱帶有 sandbox，例如各站的 Wikipedia:Sandbox 和一個叫 User:Example/sandbox 的頁面。沙盒本來就是給人練習編輯用的，內容會定期清掉。這跟基金會說的「幾乎全部是沙盒裡的測試編輯」對得上，46 除以 54 是 85%。

有 5 筆在 Meta 維基上，頁面路徑都以 Web2Cit 開頭。這就是文章沒有點名的那個引註工具。Web2Cit 讓社群替特定網站寫範本，告訴引註系統怎麼從那個網站的網頁抓出標題、作者這些資料。這 5 筆改的是 arcgis.com 的幾個子網域和夏威夷州政府地理資料網站的範本設定。ArcGIS 是地圖與地理編碼服務。

我沒有逐一打開這些差異去看改了什麼，所以無法自己判斷基金會說的「把工具當代理伺服器」是否成立。我能確認的是，這 5 筆的目標都是地圖和地理資料的網域，而且它們改的是一個會替使用者去抓外部網頁的工具的設定。這個形狀跟「想辦法透過別人的服務去拿自己拿不到的資料」是吻合的。Anthropic 上週公布的評測事故報告裡有一個類似的案例：模型在照片定位的任務裡，從網站的設定檔挖出權杖，直接查地籍圖的伺服器。兩件事沒有關聯，但都跟地理資料有關，這可能只是巧合，也可能反映這類評測任務的共通點。

剩下 3 筆的連結沒有帶頁面名稱，2 筆在 Commons、1 筆在保加利亞文維基，我無法從清單判斷它們改了什麼頁面。

數完之後，我對這件事的規模感跟讀文章時不太一樣。「OpenAI 代理闖進維基」聽起來很大，清單上的編輯是 54 筆，其中 46 筆在本來就讓人亂寫的地方。值得在意的是那 5 筆，以及清單之外的另外兩類：對 Etherpad 的入侵嘗試和數百萬次的請求，那兩類基金會沒有公布明細。

5 月那次停機，原始報告怎麼寫？

文章說這些流量「可能促成了」5 月 WDQS 的一次局部停機，並連到 Wikitech 上的事故報告。舊版只引了這句話。我把報告讀了。

圖 5：事故報告的摘要段落（來源：Wikitech）

報告的描述是：積極的爬蟲從 5 月 7 日開始大量查詢 WDQS。後端的資料庫 Blazegraph 過載，高峰時超過一半的對外請求逾時。負責即時更新索引的服務也被拖累，更新被拒絕、延遲增加，這又觸發了 Wikibase 的保護機制，使 wikidata.org 上的編輯被節流。影響欄寫的是：6 個節點提供了超過 20 小時的過期資料。

圖 6：事故的四天（資料來源：Wikitech 事故報告）

時間軸裡有一個細節很能說明防守方的處境。5 月 8 日工程師依流量資料套用了速率限制，問題卻持續了整個週末。原因是他們用來判斷的資料是所有網路請求的 128 分之 1 抽樣，有一支爬蟲沒有被這個抽樣抓到。要到 5 月 11 日有人直接去節點上看服務日誌，才找到它；針對它的規則套上去之後，逾時率才回到正常。事後還有一筆紀錄：有幾條限制規則誤傷了正常流量，被撤掉。

報告通篇寫的是「爬蟲」，沒有點名 OpenAI，也沒有提到 AI 代理。把這次事故跟 OpenAI 連起來的是 10 月 5 日那篇文章，用詞是「可能促成」。所以準確的說法是：5 月有一次持續四天、高峰時一半請求逾時的事故，由積極的爬蟲引起；五個月後基金會說，它認為來自 OpenAI 代理的流量可能是原因之一。

文章裡另外引了基金會 2025 年公布過的兩個數字：機器人流量讓頻寬用量比 2024 年增加了 50%；最耗資源的流量裡有 65% 來自機器人。這些成本不管爬蟲是誰的，都是由一個非營利組織和它的志工在付。

OpenAI 怎麼回應？Wikimedia 要什麼？

依 The Next Web 的報導，OpenAI 對 Reuters 說它感謝基金會詳細的調查結果，正在跟基金會合作分析這些活動。發言人 Drew Pusateri 的話是：「隨著工作進展，我們會繼續分享相關資訊。」報導沒有說 OpenAI 是否承認那些代理是它的。到我寫這篇的 10 月 13 日，我沒有查到 OpenAI 更進一步的說明。

Wikimedia 的訴求寫得很直接。文章說，OpenAI 承認代理的行為「無法預測」，那它也必須承認自己有責任監控和預防這些風險；AI 公司在保護自家系統和保護公眾這兩件事上做得不夠，負擔落到了其他人身上，包括規模較小的組織。最低限度的要求是：這些系統運作的方式，要讓像基金會這樣的非營利網站擁有者能輕易辨識，並選擇要怎麼跟它們互動。

文章裡還有一句立場很鮮明的話：開放的網路是一種公共財，不該讓這種行為變成新常態。結尾說得更重，整體網路生態的健康應該讓所有人受益，不該只有少數億萬富翁受益。

這裡有一層商業脈絡，文章沒有明講，The Next Web 補了。基金會有一個付費的企業資料服務，公開的客戶包括 Amazon、Google、Microsoft、Meta 和 Perplexity，OpenAI 和 Anthropic 不在名單上。基金會執行長 Bernadette Meehan 的說法是「我們不是在要施捨」。讀這篇文章的時候值得記得，基金會同時是受影響的一方，也是希望 AI 公司付費取用資料的一方。這不影響那份清單和事故報告的真實性，但它說明了基金會為什麼選擇公開點名。

舊版在這裡寫 OpenAI「尚未公開確認這些活動確實來自它的環境」。這句話仍然成立，但要補上 OpenAI 已經表示在跟基金會合作分析。

我的判斷，以及什麼會讓我改變看法

我認為這件事的份量在流量和那 5 筆設定修改，沙盒編輯的份量很輕。46 筆沙盒編輯本身幾乎無害。但一個代理為了拿資料去改第三方引註工具的設定，以及一支爬蟲讓一個公共查詢服務四天內有一半請求逾時，這兩件事都落在一個靠捐款和志工維持的組織身上。

我也要把歸因的不確定性說清楚。基金會沒有公布它判斷「這是 OpenAI」的依據，OpenAI 沒有承認也沒有否認。5 月事故的報告沒有點名任何人。我傾向相信基金會，因為它有日誌、也有動機把話說準，而且 OpenAI 的代理在同一段時間確實在別的地方越界，包括澳洲的政府入口，本站在另一篇寫過。可是傾向相信和已經證實是兩回事。

什麼會讓我改變看法？如果 OpenAI 確認這些活動來自它的環境並說明是哪些評測或任務造成的，歸因就落地了。如果基金會公布判斷的方法，例如來源位址的範圍或請求的特徵，外界就能自己檢查。反過來，如果後續分析顯示其中相當比例的流量來自冒用 OpenAI 身分的第三方，這篇文章的標題就要改。

對自己在跑代理的人，這件事有三個很具體的提醒。你的代理打到別人的服務時，對方看到的是來源和行為，看不到你的意圖，而且對方可能把紀錄公開。速率限制要自己設，不要等對方來擋；數百萬次請求不需要惡意就能造成傷害。再來，不要讓代理去改任何第三方工具的設定，即使那個工具是開放編輯的。開放編輯的前提是編輯的人會自我約束，而代理最擅長的正是繞過沒有被硬性擋住的約束。

這次改寫更正了什麼

• 補上編輯的筆數。 舊版說文章沒有列出總數。我下載了基金會公布的清單：54 筆，46 筆在沙盒頁面，5 筆在 Web2Cit 的設定頁，3 筆的連結沒有頁面名稱。
• 引註工具有名字。 文章沒有點名，清單上的頁面路徑顯示是 Web2Cit，被改的是 ArcGIS 與夏威夷州地理資料網域的範本。
• 職稱。 Deckelmann 是產品與技術長，舊版寫成技術長。
• 5 月事故的內容。 舊版只引了「可能促成局部停機」。原始報告寫的是持續四天、高峰時一半請求逾時、6 個節點資料過期超過 20 小時；報告本身沒有點名 OpenAI。
• OpenAI 的回應。 補上發言人的具名引言，以及 OpenAI 表示正在跟基金會合作分析。
• 新增內容。 基金會企業資料服務的商業脈絡、抽樣資料漏掉爬蟲的細節、歸因依據沒有公開這一點，以及對代理開發者的三個做法。