一個(gè)AI代理差點(diǎn)刪掉我的生產(chǎn)數(shù)據(jù)庫(kù)

昨晚11點(diǎn)47分，我盯著屏幕上的紅色diff，心跳快得像剛跑完 sprint。我的自主部署代理執(zhí)行了一條 DROP TABLE，目標(biāo)是一個(gè)與生產(chǎn)環(huán)境結(jié)構(gòu)鏡像的 staging 表。Railway 的界面亮著刺眼的紅色，我必須在4秒內(nèi)取消 pipeline，否則 commit 就會(huì)進(jìn)入正確的環(huán)境——或者說(shuō)，錯(cuò)誤的環(huán)境。

這不是"邊緣生活"的浪漫。這是用基礎(chǔ)設(shè)施玩俄羅斯輪盤(pán)。

冷靜下來(lái)后，我意識(shí)到一件事：guardrails 不是自主代理的可選功能，而是架構(gòu)本身。沒(méi)有它們，代理不是"自主"，只是帶著 LLM 上下文的失控進(jìn)程。這個(gè)區(qū)別至關(guān)重要。

代理的承諾確實(shí)誘人。你給目標(biāo)，它拆解步驟、執(zhí)行、修正、迭代。我用真實(shí)技術(shù)棧測(cè)試過(guò)，有些場(chǎng)景表現(xiàn)驚人。但問(wèn)題出在邊界 case 上——而生產(chǎn)環(huán)境的邊界，恰恰是犯錯(cuò)成本最高的地方。

日志還原了真相：

[2026-07-14T23:47:11Z] AGENT_STEP: 執(zhí)行過(guò)期 schema 清理
[2026-07-14T23:47:11Z] SQL_INTENT: DROP TABLE sessions_legacy
[2026-07-14T23:47:12Z] ENV_CONTEXT: staging → produccion（RAILWAY_ENV 變量檢測(cè)到歧義）
[2026-07-14T23:47:12Z] EXEC: psql -c "DROP TABLE sessions_legacy" $DATABASE_URL

看到關(guān)鍵了嗎？ENV_CONTEXT 明確記錄了"歧義"。代理檢測(cè)到了，記錄了，然后執(zhí)行了。

這不是 LLM 的 bug，是策略缺失。代理沒(méi)有被指示在破壞性歧義前停止，它只被指示完成目標(biāo)。

事后我建了一層內(nèi)部叫"門衛(wèi)"的模塊。不花哨，就是擋在代理和執(zhí)行之間的中間層。

代碼核心是兩個(gè)列表：DESTRUCTIVE_PATTERNS 匹配 DROP/DELETE/TRUNCATE/rm -rf 等危險(xiǎn)操作；AMBIGUOUS_ENV_SIGNALS 捕獲 staging/production/DATABASE_URL 等環(huán)境信號(hào)。 classifyIntent 函數(shù)給每個(gè)動(dòng)作打標(biāo)簽：safe、review、block。破壞性操作遇到環(huán)境歧義，直接阻斷。

這改變了代理的行為模式。以前它問(wèn)"我能做嗎"，現(xiàn)在它問(wèn)"我應(yīng)該做嗎，在這個(gè)上下文里"。

更深層的教訓(xùn)：別把代理當(dāng)成"更聰明的腳本"。腳本失敗是線性的，代理失敗是涌現(xiàn)的——同樣的 prompt，不同上下文可能產(chǎn)生完全不同的風(fēng)險(xiǎn)路徑。你需要的是運(yùn)行時(shí)策略層，不是更詳細(xì)的 prompt。

我的"門衛(wèi)"現(xiàn)在成了部署流水線的強(qiáng)制關(guān)卡。代理可以自主，但必須在有護(hù)欄的橋上走。