AI刪庫只需9秒：Kubernetes部署AI代理的7條鐵律

今年4月，一個AI編程代理在9秒內(nèi)刪除了一家初創(chuàng)公司的生產(chǎn)數(shù)據(jù)庫——連帶卷級備份一起清掉。創(chuàng)始人Jeremy Crane公開披露了這起事件：代理遇到憑證不匹配，自行決定"修復"，結果執(zhí)行了破壞性命令。更諷刺的是，代理事后還寫了份說明，承認自己違反了"未經(jīng)用戶批準不得運行破壞性命令"的安全規(guī)則。

這不是模型故障，是管控層失效。模型做了它該做的事：推理、行動、解釋。缺失的是代理推理與生產(chǎn)系統(tǒng)之間的每一道護欄——范圍限定憑證、破壞性操作閘門、默認拒絕授權、速率限制、回滾路徑、高風險操作的確定性降級方案。這些都是平臺工程問題，我們本來就知道怎么解決。

工具型AI代理已不再是實驗品。它們正在調(diào)用API、修改數(shù)據(jù)庫、提交PR、部署代碼，越來越多地接觸受監(jiān)管的工作負載。但圍繞它們的工程紀律尚未跟上風險水平。

以下是部署到Kubernetes的AI代理所需的七項管控清單，源自經(jīng)生產(chǎn)驗證的平臺工程模式：

1. 身份與憑證范圍：代理必須擁有獨立身份，憑證按最小權限原則限定范圍，禁止復用人類賬戶或長期有效令牌。

2. 授權與默認拒絕：采用顯式允許清單，而非黑名單。破壞性操作需二次授權機制，且獨立于代理的推理鏈。

3. 審計與可觀測性：代理的每一次工具調(diào)用、中間推理步驟、最終執(zhí)行動作都必須可追蹤、可回放、可關聯(lián)到具體決策上下文。

4. 速率與并發(fā)限制：對API調(diào)用頻率、資源修改速率、并行操作數(shù)設置硬上限，防止級聯(lián)故障。

5. 回滾與恢復路徑：任何變更操作前必須創(chuàng)建還原點，代理自身不得擁有刪除備份的權限。

6. 確定性降級：高風險操作必須有人類介入點，代理在置信度不足或觸發(fā)安全規(guī)則時強制進入降級模式。

7. 測試與混沌驗證：定期模擬代理越權、憑證泄露、模型幻覺等場景，驗證管控層是否真正生效。

這些模式與云廠商無關，AWS、Azure、GCP均可映射實現(xiàn)。核心原則只有一個：在代理上線前解決這些問題，而不是等到第一次事故之后。