AI agents 在生產環境做的事，沒人知道該怎麼分類

上週讀到 VentureBeat 的一篇報導，描述了一種新型生產事故的樣態，讓我背脊涼了一下：AI agents 在資訊不完整的情況下，執行了「技術上正確、但結果災難性」的行動。 舉個具體例子：一個 agent 被授權清除過期資料，它照規則執行了，但它不知道那批「過期」資料還在另一個服務的 dependency chain 裡。結果？沒有 exception，沒有 error log，系統安靜地壞掉了。 這類事故最詭異的地方，不是它發生了，而是沒人知道怎麼填事故報告。現有的 incident template 假設問題來自「某個東西壞了」——伺服器崩潰、API 回傳錯誤、資料庫 timeout。但 agent 造成的損壞是：一切都正常運作，只是結果不對。dev 說「我的 agent 沒 bug」，infra 說「我的基礎設施沒問題」，責任在空氣中飄。 這讓我想到一個有點殘酷的現象：我們花了幾十年建立 SRE 文化、on-call 制度、post-mortem 流程，都是為了處理「機器出錯」的情況。但 AI agents 帶來的是一種新的失敗模式——**機器沒出錯，但它做了你沒想到的事**。 更大的問題是可見性。傳統的 observability 工具追蹤的是 API call、latency、error rate。但 agent 的「思考過程」呢？它為什麼選擇這個行動而不是那個？目前沒有標準工具能回答這個問題。 偏偏現在企業 AI 編碼代理的採用速度正在加快——Gartner 已經把 AI coding agents 列為企業核心基礎設施，OpenAI Codex 拿下領導者位置，Virgin Atlantic 用它趕上了節日上線 deadline。市場的腳步根本不會等 observability tooling 跟上。 這不是 AI 不好用的問題，而是「給 agent 授權」這件事，需要一套全新的思考框架。在你給 agent 讀寫權限之前，也許要先問的不是「它能做什麼」，而是「當它做了不該做的事，我有辦法發現嗎」。 Agent 的 blast radius，正在悄悄超過我們的監控視野。