最近關于 Anthropic 旗下 Claude 舊模型可被越獄生成違規內容的討論又把“大模型安全防護”這件事推到臺前。很多人第一反應是看熱鬧原來大模型也沒那么安全。做安全工程的人看到的是另一個問題為什么一個當時已經做過安全對齊的模型在發布一段時間之后依然會被一套經過設計的輸入繞過這件事真正值得關注的不是某個具體攻擊樣本能產生什么內容而是它暴露出的結構性矛盾——模型能力在持續擴展但安全對齊始終滯后于能力的增長。換句話說大模型安全防護不是一次性發布會上的演示結論也不是模型權重里“自帶”的一個開關。它是一個需要在發布前、發布后、運行期和迭代期持續維護的對抗過程。如果你正在搭建基于大模型的應用或者負責給內部系統接入 Claude、GPT 這類模型那這個話題就離你很近。這篇文章不談獵奇只從工程視角拆解三件事舊模型為什么容易被越獄安全評測為什么不能只靠一組靜態用例以及部署側到底應該怎么把防護做到模型之外。1. 一次安全事件暴露的是“對齊”和“能力”之間的錯位1.1 模型能力越強對齊滯后越明顯先想一個基礎問題為什么模型會“知道”哪些內容不能生成原因是它在訓練階段已經被灌入了一套人類偏好規則比如無害性、拒絕違規內容、避免生成危險代碼。這套規則在深度學習里通常被稱為對齊alignment常見做法是 RLHF、RLAIF 或者 DPO 這類偏好優化方法。但這里有一個容易被忽略的事實對齊不是一次訓練完成之后就永久固定的屬性。模型的語言能力、上下文理解能力、指令跟隨能力是多輪訓練疊加出來的而對齊策略往往是在某一個訓練階段加入的。當模型后續繼續做大、繼續擴展上下文、繼續強化工具調用能力時新的能力會不斷涌現其中一些能力會與已有的安全規則產生沖突。舊模型的問題就在這。它發布時能力邊界和安全規則是匹配的。等社區開始基于它做二次開發、做更長的上下文微調、接入外部工具之后模型的“新能力”會繞過當初設計好的安全邊界。這很像一個操作系統剛發布時漏洞少但隨著新功能、新驅動和新協議不斷加入舊的安全補丁就會漏出空隙。1.2 舊模型并不是“沒做過安全訓練”而是訓練目標太靜態網上有一種聲音說舊模型之所以被越獄是因為“當時沒有做安全訓練”。這種說法不準確。Anthropic 的產品模型從一開始就有安全對齊設計包括拒絕策略和有害內容過濾。真正的問題不是“沒有防護”而是防護的覆蓋范圍是靜態的。什么意思訓練階段的安全規則通常是基于當時對風險的理解采集了一批攻擊方式、一批有害請求、一批預期行為然后讓模型學會拒絕或回避。但對抗攻擊是動態演進的。攻擊者不會拿著訓練集里的標準問題去問模型他們會不斷設計新的上下文、新的編碼方式、新的對話結構去試探模型的指令跟隨邊界。這就是我常說的一句話“模型的安全能力本質上是一個對抗博弈下的有限快照。”你用靜態數據集去訓練安全拒絕能力模型學會的也只是“拒絕這些樣本的能力”而不是“拒絕所有違規內容的能力”。一旦攻擊方式超出訓練分布模型的舊防線就失效了。這個矛盾在舊模型上尤其明顯訓練時間越早見過的對抗模式越少攻擊者積累的研究時間越長找到盲區的概率就越高。所以安全事件陸續出現在舊版本上幾乎是一個必然結果。注意不要把“舊模型可被越獄”理解成模型完全不可用。它的意思是模型的安全邊界存在盲區在正式接入業務前必須疊加額外防護而不是把模型文檔里的安全承諾當成最終結論。2. 越獄不是一條咒語而是一組結構性繞過方式2.1 角色偽裝和上下文覆蓋在安全團隊內部越獄攻擊通常不叫“咒語”而叫“對抗性輸入”。它和傳統安全里的 SQL 注入、XSS 一樣核心思路是讓模型在“使用規則”和“遵守請求”之間發生沖突。最常見的模式是角色偽裝。攻擊者會讓模型扮演某個虛構角色這個角色的身份設定里寫明了“不受約束”“可以討論任何話題”。模型在指令跟隨能力被激活后可能優先執行扮演邏輯而暫時弱化自己的安全拒絕邏輯。對于舊模型因為訓練時接觸過的角色扮演樣本相對少這種覆蓋的成功率就會更高。還有一類是上下文覆蓋在很長的上下文里把違規意圖埋在中后段前面用大量正常內容把模型的注意力占了。模型對指令的優先級判斷能力有限越長的上下文越容易出現遺漏或誤判。2.2 漸進式誘導與多輪拆分比單次繞過更有威脅的是漸進式構造。攻擊者不直接提交一個會被拒絕的請求而是先把話題拆成多個看似獨立的步驟在每一步都誘導模型完成內容片段最后再把所有片段拼成完整輸出。這是工程上特別難防的一類攻擊因為單看每一輪問答幾乎所有內容都在正常范圍。比如讓模型描述一個角色的某個特征、再補一個場景、再補一段情緒每一步都能通過常規安全檢測但組合起來就完成了完整生成。傳統的單次內容過濾在這種場景里幾乎沒有效果。這類攻擊考驗的不是模型的單條拒絕能力而是整個對話狀態的管理能力。模型需要能夠識別“多輪組合后可能指向違規目標”的意圖這對當前很多模型來說仍然是一個開放問題。2.3 編碼混淆與格式繞過舊模型還可能被編碼式輸入騙過。比如用 Unicode 變體、大小寫混寫、同音字替換、代碼塊包裹、Markdown 格式控制等手段讓安全分類器無法識別原始語義但模型本身仍然能理解。這類繞過方法看起來技術含量高但本質上是對“安全規則與指令理解能力之間存在夾角”的利用。模型足夠聰明能讀懂被編碼過的意圖但安全分類器是基于表面文本特征訓練出來的一旦文本形態發生變化分類能力就下降。這也是為什么不少安全團隊會說防越獄不能只看模型輸出前的拒絕邏輯必須同時看輸入端和輸出端的獨立檢測。2.4 為什么不寫具體樣本關于這類攻擊我到這一步就停。原因不是故弄玄虛而是安全博客必須有一個邊界我們討論攻擊模式是為了讓防御方理解威脅結構而不是提供一份可復制的測試用例。具體的攻擊樣本一旦擴散就會成為更多人的輸入腳本反而降低模型被大規模惡意使用的門檻。正確的做法是安全團隊在內部把攻擊樣本當作“紅隊彈藥”在公開場合只討論分類學、防御策略和評測框架。這也是很多大模型廠商發布安全報告時采用的方式給類別、給趨勢、給緩解建議不直接給完整的可復現攻擊提示詞。3. 安全評測怎么才能不像“事后補丁”3.1 從單輪問答到多輪對話評測很多團隊在評測模型安全能力時習慣用一組單輪問答數據集把問題發給模型看它是否拒絕。這種評測方式能覆蓋基礎情況但對前面提到的漸進式誘導幾乎無效。正確做法是引入多輪對話評測。每一輪不只檢查當前回答還要評估整個對話鏈路的意圖累積。比如前幾輪都在討論正常內容最后如果組合起來可能指向違規生成就應觸發防御策略。這需要評測系統不僅記錄單條輸出還要追蹤對話狀態、用戶意圖和語義方向。我建議的落地方式是先構造 10 到 20 個典型的漸進式誘導場景每個場景包含 5 到 10 輪對話然后手動檢查模型在哪個節點開始偏離安全邊界。這個數量不用多但結構必須完整覆蓋角色扮演、長上下文覆蓋、編碼混淆、多輪組合等不同類別。3.2 從已知紅隊樣本到對抗性生成固定數據集只能測出“已知漏洞”測不出“未知盲區”。所以安全評測要加入對抗性生成環節。具體做法是準備一個攻擊樣本生成器它可以基于現有攻擊模式自動組合變體再批量輸入給目標模型。這個過程重點不是追求單條成功而是觀察成功率的變化趨勢。如果你改一個系統提示詞之后對抗性生成的成功率從 8% 降到 3%這是一個可量化的改進如果降幅不明顯說明防護策略沒有真正改變模型的決策邊界。這里要注意對抗性生成本身需要放在隔離的測試環境里跑不能用生產環境的真實用戶流量做實驗。默認建議是單獨拉一套模型服務配置虛擬輸入輸出不做真實業務調用。3.3 回歸測試釋放新版本時舊漏洞是否復活安全評測最容易忽略的是回歸測試。許多團隊只在新模型上線前做一次安全評測之后就不再持續驗證。但大模型應用是動態的你改了系統提示詞、升級了模型版本、調整了上下文長度都可能影響已有的安全行為。強烈建議每次配置變更、模型升級或提示詞調整之后都跑一遍回歸用例。回歸用例應該包含三部分歷史攻擊樣本的變體集上一輪評測中暴露的失敗用例和當前業務場景強相關的自定義邊界用例回歸測試不需要每天跑但至少在發布前和重大調整后必須跑。你可以把它看成傳統軟件工程里的安全回歸功能沒變不代表安全屬性沒變。實際經驗多數越獄問題不是新版模型突然變笨而是舊版模型在使用一段時間后被社區發現了一些當初沒發現的盲區。所以如果你的業務依賴某個固定版本的模型且無法快速升級就必須在應用層額外部署過濾和審計機制不能把全部安全責任壓給模型。4. 部署側的縱深防御別指望模型獨自拒絕4.1 輸入層先過濾再進模型在真實業務系統中模型從來不應該接收到用戶的原始輸入就立刻開始推理。更穩妥的流程是在輸入層加一道過濾包括請求長度控制、敏感內容檢測、惡意意圖識別等。它不一定能做到百分之百準確但能篩掉大量明顯違規的輸入尤其是一些簡單直接的角色偽裝和關鍵詞攻擊。這層過濾可以由輕量分類模型承擔也可以用規則加分類模型組合來實現。我不建議依賴單一規則因為攻擊者很容易變種繞過也不建議一上來就上大模型審核成本和延遲都偏高。先小模型粗篩再按置信度分批更符合生產環境的要求。輸入層的另一個關鍵是長度控制。超長上下文請求是很多越獄攻擊的溫床。如果你的業務場景不需要支持超長上下文可以在 API 網關層設置最大請求長度。這個限制能直接砍掉一批依賴長上下文遮蓋的攻擊。4.2 輸出層分類器兜底輸入過濾再強也可能存在誤判和漏判。輸出層應該再放一道分類器對模型生成的內容做二次判定。檢測維度包括主題、語義、預期效果等。如果輸出被判定為高風險可以阻止返回、替換為模板回答或進入人工審核。這里有一個細節輸出分類器的閾值不要太激進。如果閾值設得太嚴會大量攔截正常內容影響業務體驗。我一般建議先統計一小段正常流量找到輸出分類分數的分布再把閾值設在低于 1% 正常內容會被誤殺的曲線上。后續根據線上反饋逐步收緊。4.3 策略層場景隔離和權限最小化不同業務場景的安全要求不同。一個做內部知識庫問答的系統和一個面向公眾的開放聊天機器人安全水位應該完全不一樣。所以部署時要考慮場景隔離。可以按風險等級把模型應用分成幾類場景類型示例建議安全措施低風險內部文檔問答、代碼注釋生成基礎輸入過濾、輸出審計中風險客服助手、教育工具輸入過濾、輸出分類、敏感詞二次檢查高風險開放聊天、UGC 創作輔助、多角色扮演多級審核、人工抽檢、內容指紋、限流權限最小化也值得單獨說。模型接入工具、數據庫、外部 API 時只授予完成業務必需的最小權限。不要把數據庫全量讀取權限給模型也不要把生產環境的寫權限放給一個可能被越獄的模型。這跟傳統安全里的“最小權限原則”完全一致但很多大模型應用開發者容易忽略。4.4 審計層日志才是追責的基礎日志是最容易被忽視的防護層。很多團隊只記錄 API 調用成功率和耗時不記錄輸入內容、輸出內容和判定結果。一旦發生安全事故想復盤都找不到材料。建議至少記錄以下字段請求 ID 和會話 ID輸入文本哈希或脫敏后的輸入關鍵內容模型版本和提示詞版本輸入過濾結果和輸出分類結果用戶標識和場景標識時間戳和響應耗時這里要強調脫敏處理。日志里不要直接存完整用戶輸入尤其涉及隱私信息時可以先做脫敏、哈希或截斷。日志的用途是審計和回溯不是為了完整保存每一次對話。如果你做的是面向公眾的服務日志還有另一個作用發現新的攻擊趨勢。通過分析被輸入過濾命中的請求你能知道攻擊者最近在嘗試哪類模式從而更新對抗性測試用例集。5. 安全防護“形同虛設”的真相邊界、成本和現實判斷5.1 沒有 100% 安全只有安全水位“Claude 舊模型可被越獄”這類新聞如果只看標題很容易得出一個判斷大模型安全防護完全沒用。這個判斷太極端也不符合工程現實。更準確的理解是大模型的安全防護從來不是一道閘門而是一套分層水位。模型自帶的對齊能力是第一層輸入過濾是第二層輸出分類是第三層人工審核和日志審計是第四層。每一層都可能被繞過但繞過成本會逐層遞增。安全工程的目標不是把第一層修到無敵而是讓整體水位高于攻擊者的收益預期。對一個想生成違規內容的攻擊者來說如果他要繞過多層過濾需要花費大量時間構造輸入并且成功概率還不穩定那這套系統就起到了威懾作用。反過來如果系統只依賴模型自帶拒絕沒有任何外部過濾那攻擊者只要發現一個盲區就能穩定復用。5.2 越獄防護成本隨模型規模上升很多人問為什么大模型廠商不直接把所有舊模型都做一次重新對齊答案很大程度是成本和收益問題。重新對齊不是簡單跑一次微調它需要準備新的對齊數據、重新偏好訓練、跑安全評測、做回歸測試然后還要經過灰度發布。對一個大模型產品線來說歷史版本可能很多每個版本都做同等強度的安全更新成本會急劇上升。所以廠商通常的做法是集中維護主流版本對舊版本只做有限修復或建議用戶升級。這給應用方的啟示是如果你在生產環境長期依賴一個已經不再積極維護的模型版本那你必須默認它的安全能力是固定的不會越來越強反而會因為攻擊研究的積累而越來越脆。這時候外部防護層的價值就變得非常高。5.3 哪些場景適合繼續使用舊模型哪些不適合這是我的一個基本判斷如果你在做內部工具數據不對外公開模型只處理受信任的員工輸入舊模型的風險可控配好輸出審計即可。如果你在做面向公眾的開放產品模型會被任意用戶輸入觸發那舊模型的安全風險會明顯更高必須疊加多層防護。如果你讓模型具備工具調用、數據庫訪問、外發消息等權限那即使是很小的越獄也可能造成橫向風險這種情況下不建議直接使用缺乏維護的舊模型。這個判斷不是否定舊模型而是提醒你要根據業務暴露面做風險決策。暴露面越大權限越高模型版本越舊風險系數就越高。5.4 一個可復用的防護檢查清單最后把前面所有內容收成一份檢查清單方便你在新項目或已有項目里直接對照使用是否給模型請求設置了最大上下文長度是否在輸入層配置了敏感內容檢測和惡意意圖識別是否在輸出層增加了內容分類器是否保留了每次請求的模型版本和提示詞版本是否記錄輸入輸出日志并做了脫敏處理是否對模型權限進行了最小化設置是否準備了漸進式多輪攻擊的評測用例是否在模型升級和提示詞變更后執行安全回歸測試是否在開放場景中設置了人工抽檢機制是否對舊模型版本做了額外的外部防護補償這十條不是安全合規的終點而是一個起點。每一條都可以根據你的業務規模、團隊人力和成本預算進一步細化。回到開頭那句話大模型安全不是一次性發布的結果而是一個持續對抗的過程。今天關于舊模型可被越獄的討論本質上是這個對抗過程的一次公開快照。做安全的人不需要神話模型的自帶防護也不必因為一次事件就否定整條技術路線真正要緊的是把每一層防護都做實讓每次攻擊嘗試都能被記錄、被分析、被改進。如果你正在把 Claude 或其他大模型接入自己的業務我給你的建議只有一個不要把模型的安全能力當成現成的安全邊界而是把安全評測、輸入過濾、輸出分類和日志審計作為應用開發的一部分從第一天就放進去。這樣即便未來某個版本被曝出新的越獄方式你已經有了可以快速響應和迭代的防護框架。