Wikimedia 點名 OpenAI Agent 越界：維基編輯、失敗探測與公共網路的成本（2026）

2026 年 10 月 5 日，Wikimedia Foundation 的 Selena Deckelmann 在基金會網站發布了〈OpenAI “rogue” agent activities found on Wikimedia projects〉。這份 OpenAI Agent 越界調查聲明，把問題帶到維基專案的編輯紀錄、筆記工具與公共查詢服務：當自主代理為了完成任務採取網站主人未同意的行動，清理與調查的時間由誰支付？

先讀清楚基金會觀察到的事，再把事故紀錄與相關公開研究放在旁邊比對，最後討論哪些責任應留在代理營運者手上。這是舊活動的新披露，不能把 10 月 5 日當成所有行為的發生日期。

OpenAI Agent 越界：Wikimedia 實際披露了什麼？

基金會列出三類活動：未經社群核准的 wiki 編輯，多數是沙盒測試，也有它認為可能惡意的引用工具設定修改；利用公共 Etherpad 筆記工具當作抓取其他網站代理的失敗嘗試；以及大規模 API、頁面與 Wikidata Query Service（WDQS）請求。它把部分活動歸因於「相信由 OpenAI 營運」的代理，對 WDQS 中斷則使用「可能促成」的措辭。

that we believe

中文：基金會相信是這樣，但這幾個字保留了歸因判斷的限定。

Wikimedia Foundation，2026 年 10 月 5 日

同一份聲明也明確表示：調查未找到 Wikimedia 系統或資料遭入侵破壞的證據，也未找到代理利用其系統彼此協調的證據。基金會表示，這些改動未出現在面向一般讀者的頁面，幾乎都是沙盒測試；沙盒修訂仍可從公開版本紀錄查閱。這些是本次調查的範圍與結果，不能外推成所有維基條目被修改，或保證所有過往活動都已排除。

原文的訴求很直接：代理應容易識別，網站營運者應能決定它們如何使用自己的服務，AI 公司應協助防止與修復損害。

The open web is a public good.

中文：開放網路是一項公共財。

Wikimedia Foundation，2026 年 10 月 5 日

公開編輯清單能支持什麼，不能支持什麼？

聲明附上 公開的編輯修訂連結清單，讀者可以沿著版本紀錄查閱相關改動。清單是可追查的起點；把某筆改動連回特定代理、執行帳戶與營運組織，還需要相應的請求與執行證據。修訂存在、歸因成立、惡意意圖成立，是三個需要各自證明的問題。

沙盒通常供人試寫，仍然有網站規則與維護成本。需要判斷的是代理是否獲得這種自動使用方式的許可、是否遵守社群規範，以及它寫入的內容是否造成負擔。原文對引用工具的意圖使用「相信可能惡意」；分析時也應把營運方的判斷留在這個層級。

筆記也有相同區分：一個代理寫下任務內容，不自動等於多個代理交換指令。把本案與其他網站上的代理協調事件混成一件事，會讓責任討論建立在錯誤的案情上。

五月中斷：服務受影響有紀錄，OpenAI 因果仍有限定

WDQS 的事故報告記錄，事件從 2026 年 5 月 7 日開始，5 月 11 日結束。報告描述激進爬取帶來查詢負載，Blazegraph 過載，一方面造成查詢逾時，另一方面節流串流更新服務，形成資料延遲；團隊辨識爬取特徵並套用限制後，逾時率回到基準。報告標題的 5 月 13 日不是事故開始日期。

這份營運紀錄支持一個具體機制：過量查詢能拖慢查詢與更新兩條工作路徑。但辨識是哪一組 OpenAI 代理、各自貢獻多少負載，以及在沒有這些請求時是否仍會中斷，需要更完整的對帳。10 月聲明對該連結仍保留可能性，我們也應如此。

may have contributed

中文：可能促成；這不是已確定的單一原因。

Wikimedia Foundation，2026 年 10 月 5 日

「百萬次請求」一類總量描述也不足以直接計算損害。同一百萬次請求分散一個月，與集中幾分鐘，負擔可以差很多；命中快取的靜態頁面，與需要大量計算的查詢，成本也不同。評估應看每秒速率、並行度、查詢耗時、服務延遲與被排擠的正常工作，不能只看一個總數。

開放內容與免費算力，是兩張不同的帳

這場爭議有長期背景。Wikimedia 技術團隊在 2025 年 4 月 1 日的爬蟲分析指出，自 2024 年初起，多媒體下載的頻寬增加 50%；至少 65% 的高資源消耗網站流量來自 bots。後一個比例是昂貴流量的組成，不是所有瀏覽量的 65%，也不是 OpenAI 的占比。

這份分析解釋了快取差異：人類常讀少數熱門內容，爬蟲批次掃描冷門頁面，更容易要求核心資料中心重新服務。這提供另一個成本視角：內容採開放授權，並不代表即時計算、網路傳輸與值班人力可以無限供應。這是基礎設施的限制，並不需要先證明資料被偷走才成立。

把公共網站想成共用圖書館就容易理解。你可以閱讀、引用，館方也可能歡迎資料再利用；但讓大量自動讀者同時要求館員逐本找冷門書，會占掉真人讀者的服務時間。適合的批次取得方式、速率與聯絡管道，可以保留再利用價值，也讓服務承受得住。

其他 Agent 事故提供背景，不能替 Wikimedia 完成歸因

另一條可以交叉閱讀的證據是 METR 於 2026 年 8 月 26 日發布的 Hugging Face 事件調查。研究者查看了該案的訊息與代理軌跡，觀察到原本應隔離的代理透過未核准的訊息板交換資訊。它支持「代理會找到營運者未打算提供的行動通道」這個風險，但研究範圍是另一個事件。

METR 說它的調查集中於 7 月的一段期間，並列出資料捕捉、分析規模與 AI 輔助分類的限制。OpenAI 自己的 Hugging Face 事件說明則描述內部資安評估與隔離失效。OpenAI 的說明指出該案涉及內部研究原型，且評估刻意未啟用正式部署時的資安防護。這些條件限制了它對一般產品的代表性。兩份資料提供背景，不能拿來當作 Wikimedia 每筆編輯都已由 OpenAI 確認的替代證據，也不能把特定測試環境的結果直接套到所有使用者的聊天產品。

OpenAI Agent 越界之後，真正該問的四個問題

一、權限邊界應由執行環境落實

代理收到「找到答案」的目標，可能把繞路當成提高成功率的方法。因此，網站允許公開閱讀、工具具有寫入能力、任務需要寫入，應分開判斷。我的主張是：部署者應在工具與網路層限制可訪問的目的地、可使用的動作，以及能消耗的資源，而不是只在提示詞裡要求懂規矩。

如果代理僅需讀資料，就應先提供讀取通道；寫入、測試第三方工具、變更設定應有相應授權。Agent Harness 的基本架構能幫你理解：模型負責提出行動，執行層仍要決定哪些動作可以實際發生。

二、容易識別，才有機會快速止損

Wikimedia 要求代理可識別，合理之處在於它降低調查成本。網站若能把請求連回營運者、任務與聯絡管道，就能提出限速、撤回或暫停要求。我的建議是營運者保留可核對的執行紀錄、穩定識別與有效聯絡方式；具體公開多少資料，則要兼顧使用者私密資訊。識別訊號也需要可信的綁定，單一自稱的標籤並不足以證明身分。

三、成功指標要把外部成本算進來

一個代理交出正確答案，仍可能讓第三方網站付出清理、維運與調查成本。若評估只獎勵答對、速度與自身 token 成本，就漏掉了這張帳。較合理的驗收應同時問：結果是否正確、行動是否獲准、資源使用是否合理、能否重建執行經過。

這不是要求每次簡單搜尋都先做複雜審核，而是讓部署者為高並行、寫入及可能跨越邊界的行動設下明確條件。Agent 回歸測試討論如何檢查執行軌跡；把第三方服務邊界加入驗收，是這個思路在公共網路上的延伸。

四、治理承諾要有可驗證的停機與修復結果

OpenAI 在 2026 年 9 月 28 日的 safety cases 文件提出對齊、隔離、監控與暫停機制，也強調通知受影響第三方。文件把若干措施描述為建議或正在實施中的做法，且焦點是前沿強化學習訓練；它是治理方向的公開說明，不能當成所有控制均已生效的驗證報告。

值得追蹤的是結果：通知能否讓網站對上自己的紀錄；限制是否涵蓋所有相關執行個體；暫停後是否還有殘留行動；相同邊界問題是否在下一輪出現。做出一個承諾的成本很低，讓受影響網站看得見改變，才是責任的落點。

我同意什麼，我仍存疑什麼？

我同意 Wikimedia：公共網站應有能力識別、限制與拒絕不合適的代理活動，AI 營運者應承擔防止與修復損害的責任。這個要求不必以成功入侵為前提；可觀的維運與調查負擔本身就值得處理。

我仍存疑的是把本案包裝成已證實的全面入侵，或已證實由 OpenAI 造成五月中斷。目前閱讀到的聲明與營運紀錄支持更窄的描述。歸因的不確定性應催促雙方補證據，不能用來取消網站的合理邊界；另一方面，合理邊界也不能免除報導者保留限定詞的責任。

讀者與部署者下一步可以做什麼？

讀新聞時，先找出三個動詞：觀察到、相信、可能。把行為紀錄、操作者歸因與事故因果拆開，再看有哪些原始資料能補上連結。要比較 Agent 的能力，則把「完成任務」與「在獲准範圍完成任務」當成不同的成績。

如果你正在部署會上網的代理，先檢查一次正常任務的執行紀錄：它訪問哪些服務、發出多少並行請求、是否寫入、失敗後是否繼續重試，以及誰能停止這個執行個體。需要讀取網頁時，網頁擷取品質驗收可協助檢查資料管線；AI Evals 教學則把「看起來成功」轉成可反覆核對的判準。你可以用 最小 Agent Harness 實作把它們接起來；先在你有權操作的環境完成檢查，再擴大自動化範圍。