TechCrunch 在 2026 年 9 月 10 日報導一項研究，討論 AI Agent 以高頻率替人們提交申訴、福利、住房、金融或其他公共服務請求的現象。研究作者整理出 11 個司法管轄區、84 起「潛在」agentic flooding 案例；這個詞描述的是自動化系統在短時間大量產生請求，可能讓服務機構承受額外負載。重點是「潛在」：研究不是宣稱 84 起都已證實由 AI 造成，也沒有把公共服務量增加直接歸因於 Agent。
研究到底發現了什麼？
論文《Characterizing Agentic Flooding of Government Services》建立了一套風險分類，用來觀察 Agent 大量操作政府或準公共服務的可能路徑。案例涵蓋各種申請、投訴與資訊請求；研究不是只數 API 呼叫，而是嘗試把請求的經濟誘因、流程複雜度、審核瓶頸與自動化可行性放在一起看。
作者認為，短期風險較高的情境通常同時具備兩個條件：請求對使用者有明顯財務誘因，而且流程本身複雜、人工處理能力有限。當 Agent 能低成本重複遞交表單或申訴，個別合法請求與大量策略性請求在入口處可能變得難以區分，機構就需要更好的節流、驗證與排序設計。
84 起案例不是 84 起定罪
研究與報導提到，英國住房申訴專員收到的申訴量從 2022 年超過 2,600 件，增加到上一年度超過 7,000 件；美國消費者金融保護局的投訴量也被描述為約成長五倍。這些數字值得關注，卻不能單獨證明增加的原因是 AI Agent，因為人口、政策、宣傳與分類方式也可能同時改變。
因此文章不應該寫成「AI 已經癱瘓政府」。比較準確的說法是：研究找到多個需要追蹤的高風險模式，並提醒公共機構不能只用傳統的人工排隊假設來設計入口。多數案例可能仍是人們使用自動化工具完成合法申訴，治理重點不是把所有 Agent 當惡意流量，而是判斷行為規模、重複度與真實需求。
查證缺口在哪裡？
這個題目的重要限制，是「潛在案例」與「已確認因果」不同。研究者必須從公開資料、機構說明與可觀察行為推測自動化可能性；許多服務不會公開完整的 user-agent、IP、帳戶關聯或代理執行紀錄。沒有這些資料，就無法把每一筆異常流量直接歸給某個 Agent。
另一個難題是防禦的副作用。若機構把速率限制設得太嚴，可能擋住網路不穩、需要協助或一次提交多份合法資料的人；若完全不限制，則容易讓低成本自動化擠壓人工審核。研究提出的風險框架比較適合用來設計分級驗證與人工接手，而不是直接變成一條封鎖所有自動化的規則。
為什麼一般 AI 使用者也要在意？
如果你用 Agent 幫忙填表、寄信或提交申訴，最基本的責任仍是確認內容、頻率與收件對象。一次自動化操作可能對你很方便，但對接收端來說，重複送出、缺少脈絡或無法驗證的請求會增加成本，也可能讓真正急迫的人排到後面。
對產品團隊而言，這則研究把 Agent 的成功標準拉出「完成任務」之外：還要問它是否尊重服務入口的速率、是否顯示使用者意圖、是否能在重複前停止，以及是否留下可供申訴與調查的紀錄。Agent 越接近真實世界的公共或金融流程，這些約束就越接近產品本身，而不是附加功能。
