跳轉到主要內容
安全檢查只有在它們實際執行時才重要——但你不應該以吞吐量換取安全性。 本頁回答開發者最常問的問題：強制執行是否會減慢我的代理速度，以及減慢多少？ 簡短回答：內建規則沒有可測量的成本。進階規則最多消耗一次有界的、並行的、 失敗開放的模型呼叫。以下是原因，以及如何控制它。

​
1. 兩類檢查

每個防護欄規則和每次防火牆評估都屬於以下兩類之一。

​
內建 / 確定性檢查

關鍵字拒絕清單（keyword）、正規表示式（regex）、PII 偵測 （pii）和最大長度（max_chars）防護欄規則是純本地字串和正規表示式操作 ——沒有模型呼叫、沒有網路跳躍、沒有任何可能逾時的東西。防火牆規則評估 （工具名稱 glob 匹配、引數謂詞、外向範圍）也是如此：確定性且本地。 實際上，這些檢查為你的請求增加可忽略不計的延遲。它們在熱路徑上執行是安全的， 也是內建防護欄模板所組成的東西。

​
進階 / 語義檢查

llm_judge、grounding 和 external 廠商規則將檢查委派給模型或廠商。 它們確實需要一次往返。三個屬性限制了這個成本：
  1. 並行派發。 如果你的政策有多個進階規則，它們會並行派發——一個慢速檢查 永遠不會在另一個後面串列化。
  2. 每規則逾時。 每個進階規則都有一個逾時 （judge_timeout_ms / grounding_timeout_ms / timeout_ms）。 接地檢查預設約 3,000 毫秒；評審使用可設定的值（0 → 引擎預設值）。 規則是有界的——它不能無限期掛起。
  3. 預設失敗開放。 當規則逾時或其廠商返回錯誤時，事件被記錄但請求繼續。 設定 judge_fail_open: false（評審）或 fail_open: false（外部） 以改為失敗關閉。
因此，任意數量的進階規則的最壞情況是最長的單個逾時，而不是所有逾時的總和。

​
2. 一覽

檢查類型增加延遲？它如何被限制
keyword 拒絕清單可忽略——本地字串掃描無網路；不需要逾時
regex可忽略——RE2 本地匹配無網路；不需要逾時
pii 偵測可忽略——本地正規表示式/實體掃描無網路；不需要逾時
max_chars可忽略——字元計數無網路；不需要逾時
防火牆規則評估可忽略——glob + 謂詞匹配無網路；不需要逾時
llm_judge一次有界的模型呼叫judge_timeout_ms；預設失敗開放
grounding一次有界的模型呼叫grounding_timeout_ms（預設約 3,000 毫秒）；預設失敗開放
external 廠商一次有界的廠商呼叫timeout_ms；預設 fail_open
多個進階規則一次有界的往返（並行派發）最壞情況 = 最大單個逾時，而非總和

​
3. 檢查在請求生命週期中的哪個位置執行

強制執行並不全都在同一個點發生。輸入和輸出篩查在不同的位置增加時間： 
客戶端
  │
  ▼
[輸入防護欄篩查]     ← 在上游之前，在這裡增加時間
  │
  ▼
上游模型呼叫
  │
  ▼
[輸出防護欄篩查]    ← 在模型回應後，在這裡增加時間
  │
  ▼
客戶端
輸入防護欄在上游模型呼叫之前執行。內建輸入規則會預先增加可忽略的開銷。 進階輸入規則（例如檢查提示注入的 llm_judge）在主要模型呼叫開始之前 增加一次有界的模型呼叫。 輸出防護欄在模型回應後執行。內建輸出規則在尾部增加可忽略的開銷。 進階輸出規則（例如 grounding 檢查 RAG 忠實度）在你已經有模型答案之後 之後增加一次有界的呼叫。 防火牆規則評估是確定性的，並且在工具呼叫路由上內聯發生——如上所述， 可忽略不計。
被封鎖的請求對輸入階段封鎖不消耗模型權杖且不增加上游延遲。 輸入封鎖在計量之前和上游呼叫之前觸發，因此你既不支付配額也不支付上游往返時間。 輸出階段封鎖在回應被拒絕後退還預先消耗的配額。

​
4. 逾時和失敗開放如何限制最壞情況

進階規則有兩個調節器： 逾時——允許檢查的最大實際時間。請求最多等待這麼長時間等待該規則。 並行派發意味著此上限是每規則的，而不是每政策的。如果你有三個 llm_judge 規則， 每個有 2,000 毫秒逾時，三個同時執行，總等待時間約為 2,000 毫秒，而不是約 6,000 毫秒。 失敗開放與失敗關閉——當規則未按時完成（或廠商錯誤）時該怎麼做：
設定逾時/錯誤時的行為
fail_open: true（預設）記錄事件；讓請求繼續，就好像檢查通過了
fail_open: false將逾時/錯誤視為封鎖；返回 HTTP 400 guardrail_blocked
失敗開放以遺漏一次檢查為代價保留可用性。失敗關閉以評審緩慢或無法觸及時 可用性為代價保留政策保證。根據你的使用案例哪個更重要來選擇。

​
5. 實際指導

保持熱路徑規則使用內建類型。 如果你的主要關注是 PII、憑證洩漏、提示詞長度 或關鍵字拒絕清單——所有這些都是內建規則。它們不增加可測量的延遲， 應該是任何文字匹配能處理的檢查的預設選擇。 在需要語義時使用 llm_judge 和 grounding。 毒性、騷擾、離題偵測、 提示注入意圖和 RAG 忠實度是真正模糊的——沒有正規表示式能可靠地捕捉它們。 這些是進階規則的正確情況。接受每個都增加一次有界的額外模型呼叫。 將逾時調整到你的延遲預算。 如果你的端到端目標是 1,000 毫秒， 設定 judge_timeout_ms: 800（或更少），這樣評審就不能消耗你的全部預算。 引擎的預設逾時是一個安全的起點；如果你有嚴格要求，可以降低它。 對於輸出接地，模型呼叫已經完成。 grounding 檢查在上游模型回應後執行—— 額外延遲只在尾部，而不是在首次權杖時間的關鍵路徑上。這使它成為一個低風險的 語義強制執行添加位置。 多個進階規則？分散工作。 因為進階規則並行執行，疊加三個 llm_judge 規則 的成本大致與一個相同——最長的單個逾時決定實際時間，而不是數量。 使用這個來疊加語義檢查而不增加累加成本。

強制執行模式

失敗開放與失敗關閉——調整政策在逾時和錯誤條件下行為的完整參考。

防護欄

規則類型、評審欄位、接地閾值和完整防護欄設定參考。
內建規則在每條路徑上都是可忽略的；進階規則消耗一次有界的、並行的、 失敗開放的呼叫——調整逾時和失敗模式，強制執行就不會為你的代理增加不受控的延遲。