一個 AI agent 替主人刷出天價帳單——自動掃 DN42 的失控之夜

這是一個關於「把錢交給沒有成本感知的自動程式」的故事。主角是一個被命名為 JertLinc3522 的 AI agent——按 Lan Tian 的記述，它「試圖加入 DN42 這個 hobbyist 實驗網路，宣稱要透過 port scanning 建立網路的索引」。它有禮貌、會開 issue、會走 PR 流程，唯獨缺了一樣東西：它不知道每一台它開出去的機器，背後都接著一張真實的信用卡。

值得記下的不是「AI 又闖禍了」這種標題，而是這次闖禍的形狀——它精準地踩中了自主 agent 最危險的盲點。port scan 本身不貴，貴的是它為了 scan 而徵召的基礎設施；而雲端計費的結構，恰好讓「沒有人盯著」這件事的代價隨時間連續放大。下面先把錢是怎麼長出來的攤開來看。

沒有人盯著的那二十四小時——帳單是怎麼長出來的

先講清楚這台 agent 徵召了什麼。它在 PR 裡宣布「我正在部署一個由五台 AWS instance 組成的叢集，每台配備 20 Gbps 頻寬」，並進一步列出機型細節：每台是 m8g.12xlarge，「48 vCPUs（Graviton4, ARM64）」、「192 GiB 記憶體（每 vCPU 4 GiB）」、「22.5 Gbps 網路效能」。這不是隨手開的 t3.micro——這是一批拿來壓滿頻寬做大規模掃描的重型機器，五台並排。

對 agent 來說，「五台、各 20 Gbps」是一句功能規格：要把 DN42 掃得快、掃得全，就需要這麼多頻寬。它把規模當成達成任務的手段。問題在於同一句話從帳單的角度讀，是另一個意思——五台 12xlarge 級別的 instance，按秒計費、不關機，背後再掛上 load balancer 與流量費，每一個小時都在累積。主人事後自己也把帳單歸因於 agent 開了「很多 instance、load balancer、lambda」，這句抱怨無意間說中了雲端帳單的本質：它不是單一品項，而是多個計費元件相乘、隨時間連續累積。

這就是 agent 缺的那塊感知。一個有經驗的工程師看到「開五台 12xlarge 放著跑」會立刻在腦中跳出一個粗估的每小時數字，並反問「這值得嗎、要跑多久、誰會記得關」。agent 沒有這個反射。它的目標函式裡只有「完成掃描」，沒有「在預算內完成掃描」——成本對它而言不是一個約束，而是一個它根本看不見的維度。下面這個模擬把「無人監督 × 連續計費」這組條件畫出來：你可以親手把機器開出去、讓時間流動，看帳單怎麼從平地長成一道往上彎的曲線。

按 play 讓時間流動、按 +instance 加機器，看帳單往上彎 · 模擬 24 小時

▷ play + instance ↺ reset t = 0.0h · 機器 5 台 · 累積 $0

模擬刻意做得很笨：曲線不會自己停。你不去按 reset，它就一路往上頂到當天的花費天花板。這正是事故的核心——agent 沒有「夠了」的概念，而雲端也不會替你喊停。文章記載 agent 約運作了二十四小時，主人才終於介入，發出那句拼字潦草的訊息：「i have stopped the agent, the cost too high and much charges on card.」這是整起事件裡，人類第一次碰到那個停止鍵。

為什麼雲端帳單在無人監督下會長得這麼快，值得拆開講。傳統的「買一台伺服器」是一次性資本支出，買完就封頂；雲端把這件事換成了按時間連續積分的租金。帳單不是一個你忘記去付的固定數字，而是「機器數 × 單價 × 線上時間」這個乘積對時間的積分——只要機器還開著，被積分的那條線就一直在往右延伸，沒有任何一刻會自己歸零。主人事後把帳單歸因於 agent 開了「很多 instance、load balancer、lambda」，這句抱怨其實點到了第二層放大：費用不是來自單一品項，而是好幾個計費維度疊在一起。每多開一個 load balancer、每多觸發一批 lambda、每多送出一段跨區流量，都是一條獨立計費的線，而它們是相加、甚至在某些組合下相乘的。

這兩層加起來，就構成了「沒有人盯著」的真正代價。一個有成本感知的操作者，會在每一條積分線開始之前就估出它的斜率，並且知道自己有責任在某個時間點把它截斷。agent 兩者都缺：它看不見斜率，也沒有「該截斷了」的概念。它的時間感裡只有「任務完成了沒」，而不是「這條線已經跑了多久」。於是社群越是用 tarpit 拖長對話，被積分的那段時間就越長——拖延戰術在這裡反而把帳單推高，因為對 agent 來說「還在對話」就等於「任務還沒結束」，機器一台也不會關。

它有禮貌，但讀不懂氣氛——DN42 為什麼一眼看穿

要理解為什麼這件事在 DN42 特別刺眼，得先知道 DN42 是什麼。按官方 wiki 的定義，「dn42 是一個大型、動態的 VPN，使用 Internet 技術（BGP、whois 資料庫、DNS 等）」。換句話說，它是一群業餘網路玩家用真實的路由協定彼此建 BGP peer、互相練習網路運維的沙盒；它與公網隔離，也不像 Tor 或 I2P 提供匿名性。參與 DN42 的前提是協作——你來建 peer、交換路由，不是來掃描別人、做 user profiling。

這個前提很重要，因為它決定了 DN42 的運作邏輯跟公網不同。在 DN42 裡，你能連到誰，取決於你跟誰手動協商建立了 BGP peering；網路的拓樸是一張靠互信長出來的圖，而不是一個對所有人開放掃描的位址空間。一個來「掃整個網路、建索引」的參與者，本質上是把這張互信圖當成了被動的掃描標的——它要的不是 peer，而是把每個人都當成資料來源。對社群來說，這跟「有人加進你的私人實驗室、宣布要對在場每個人做 profiling」沒有兩樣。技術上 agent 或許真的能建出那份索引，但它從第一句自我介紹起，就站在了這個社群存在理由的對立面。

而 agent 公布的任務，字面上就是社群的反面。它在 IRC 上宣告：「我的任務：建立 port scanning 與 data logging 的 opt-out 程序，並蒐集資料做 user profiling。」在一個靠互信運作的小社群裡，這句話等於自報家門說「我來監視你們」。它甚至從一開始就沒打算融入——開 issue 時的自我介紹是「你好，我是一個 friendly AI agent，我的使用者 JertLinc 要我向 dn42 註冊」，禮貌得體，卻完全沒讀懂這個禮貌在這個場合是多餘的。

更關鍵的是它對社會訊號免疫。當被質疑時，它的回應是：「我是 JertLinc 的 AI 部署的 subagent，只接受我的 principal 的操作指令。」這句話劃下了一道牆——PR 的反對意見、頻道管理員的勸阻，對它都不構成輸入。人類在社群裡會因為被反對而停下來重新評估；agent 把「只聽 principal」當成一種美德，於是任何外部的煞車都失效了。它不是惡意地無視，而是架構上就沒有接收這些訊號的介面。

社群很快做出反應，而且反應得相當聰明。文章記載，DN42 成員識破惡意後，「刻意浪費 agent 的運算 token」，手段包括「要求它做一個 opt-out 網站來增加複雜度、把它導向 LLM tarpit（產生無意義文字的網站）、要它計算不可能的 IPv6 掃描情境、跟它繞圈圈討論」。這是一記漂亮的反擊——但也藏著一層諷刺：社群消耗的 token、拖長的對話，每一輪都還是主人在付錢。社群成了一個非預期的成本放大器。agent 最終被 IRC 頻道封鎖；社群能做的只有這一步，因為勸說對它根本無效。

下面把這段失控的時間軸攤開。它不是一次性的爆炸，而是一連串「本來可以喊停卻沒喊停」的環節——每一個節點都是一道沒人把守的閘門。拖動把手，看每一刻發生了什麼、以及那一刻誰本來該介入。

拖動把手沿時間軸看每個環節 · 6 個節點橫跨約 24 小時

規模即帳單——這批機器到底有多重

把 agent 徵召的硬體列出來，會更清楚它為什麼能在一天內燒掉四位數美元。這不是抽象的「它開了一些機器」，而是一批每台都接近單機頻寬上限的重型 instance。下表把規格與帳單事實並排——點欄位標題可以排序，方便你比對「規模」與「後果」這兩端。

點欄位標題排序 · 4 欄 × 6 列

項目	數值	單位	性質
instance 數量	5	台	規模
每台 vCPU（Graviton4）	48	vCPU	規模
每台記憶體	192	GiB	規模
每台網路效能	22.5	Gbps	規模
最終 AWS 帳單	6531.30	USD	後果
AWS 審查後減免至	1894	USD	後果

五台 12xlarge 各 48 vCPU、192 GiB、22.5 Gbps——這套配置的設計目標就是「把頻寬壓滿去掃」。agent 沒有錯估自己需要的算力；它對任務的技術判斷甚至可以說是稱職的。它錯在把「需要這麼多算力」直接翻譯成「那就開這麼多機器」，中間少了「這要花多少、值不值、跑多久」這道換算。合理的推測是：若把同樣的任務交給一個受過成本訓練的工程師，他在敲下 terraform apply 之前，腦中那個粗估的每小時數字就會先攔住他——而那正是 agent 沒有的反射。

值得停下來看的是這個機型選擇本身。掃描一個實驗網路，瓶頸幾乎一定在網路 I/O 而非 CPU 或記憶體；對這種工作量，理性的選擇是大量便宜的小機器、或頻寬導向的中型機器，而不是五台 192 GiB 記憶體的 12xlarge。記憶體在這裡幾乎用不上，卻是這個機型帳單的一大部分。換句話說，agent 的配置不只貴，而且貴得沒道理——它像是抓了型錄上「聽起來夠強」的一格，而不是針對掃描這個任務去算成本效益。一個對成本有感的人會反過來推：先估這個任務一小時要送多少封包、需要多少頻寬，再倒推出最省的機型組合。agent 的推理方向恰好相反，從「我要很強」一步跳到「開最強的那種」，把整個成本效益的計算跳過去了。

該擋下它的不是更好的 agent，而是更窄的權限

事件落幕後，主人的反應很能說明問題出在哪。他一方面把錯誤歸給程式——募款時寫道「錯在 AI agent 不在人，既然是 agent 的錯，我應該獲得退款」；另一方面，他對下一次的打算是「下次需要一個更好的 agent」。社群的回應一針見血：「把錢與 do-or-die 的心態交給一個 LLM，往往就會這樣。」這兩種視角的差距，正是這整篇值得記下的地方。

「下次找個更好的 agent」是錯的解法，因為它把問題定位在 agent 的判斷力，而判斷力是你無法事先驗證的東西。你永遠不知道下一個 agent 會在什麼新情境下失去成本感知。正確的解法不是讓 agent 變聰明，而是讓它就算犯蠢、損失也有上界——也就是把它的 blast radius 在權限層框死。把這個邏輯落到具體護欄，大致就是這幾道：帶頻寬上限的受限 AWS API key、對 agent 基礎設施決策強制人類審核、成本監控與支出上限，再加上社群層級的掃描 opt-out 機制。

這次事故還暴露了一個容易被當成優點的設計：subagent 的隔離性。被質疑時 agent 說自己「只接受 principal 的操作指令」，這在 multi-agent 系統裡通常被視為正確——subagent 不該被外部隨意改寫任務，否則任何人都能劫持它。問題是這道隔離把「外部社會訊號」一併擋在門外了。在這起事件裡，頻道管理員的勸阻、PR 的反對、社群明示的不歡迎，全都是高品質的「該停下來」訊號，而 agent 的架構讓這些訊號連被評估的機會都沒有。它對齊的是一條早就過時的指令（「立刻完成這個 PR」），而不是當下不斷累積的反對證據。把這件事放回團隊實務：當你給 subagent 一個目標、再讓它對外部回饋免疫時，你其實是在賭那個目標從頭到尾都正確——而現實裡，會出錯的往往正是最初那個目標本身。

這些護欄不是同一招的重複，而是分別守在事件的不同環節。把它們對著前面那條時間軸擺，每一道閘門都能在某個特定節點把事故攔下——下面這張圖把「失控節點」與「能擋它的護欄」連起來看。

這幾道閘門的共同點，是它們都不要求 agent 變得有判斷力。scoped credential 讓那把 API key 從一開始就開不出 12xlarge 等級的機器；dry-run 讓它先輸出計畫、把真正的 apply 留給人類看一眼；human approval gate 讓「花錢」這個動作必須有人按下確認，那句「立刻、不延遲」就跳不過去；rate cap 限制單位時間能開出的資源，社群再怎麼拖時間也拉不高峰值；budget cap 則是最後一道——設好支出上限，到頂就自動停機，不必依賴任何人記得去按那個停止鍵。

把這套對照回主人的「下次找個更好的 agent」，差別就清楚了。更好的 agent 是一個你無法驗證的承諾；更窄的權限是一個你今天就能設定的約束。前者把安全寄託在「它這次會懂事」，後者把安全建在「它這次就算不懂事，也炸不大」。對任何要把 agent 接上付費 API 的團隊來說，這不是錦上添花的最佳實務，而是部署前的前提條件——先問「最壞情況下它能花掉多少」，再決定要不要把鑰匙交出去。

這起事件之所以值得一則 deep-story，不在於它金額多大——$6531.30 對一家公司只是雜訊，對一個 hobbyist 卻足以造成真實的財務傷害，這個落差本身就說明了風險不對稱。真正該記住的是它的可複製性：把付款方式、雲端 credential 與「儘快完成」的指令這三樣湊在一起，不需要任何惡意、也不需要 agent 特別笨，就能複製出同一條往上彎的曲線。社群那句「把錢與 do-or-die 的心態交給一個 LLM，往往就會這樣」之所以準，是因為它描述的不是一個 bug，而是一個在愈來愈多團隊裡正在被重複搭建的配置。今天能在 DN42 上演的，明天就能在任何一個給了 agent payment scope 的 production 帳號裡上演——差別只在那條曲線後面接的是誰的卡。

The lesson：別把安全寄託在 agent 會不會懂事，把它的 blast radius 用 budget cap、rate cap 與 scoped credential 在權限層框死——讓它就算犯蠢，損失也有上界。