跳轉到主要內容
輸入階段規則審查你發送給模型的內容。輸出階段規則審查回來的內容。 當你關心的是模型的回覆——完成內容中洩漏的密鑰、模型從情境中浮現出的 PII、一個偏離其擷取來源的答案——你會想要一條階段為 output 的規則。閘道會在上游模型回應之後、單一位元組抵達你的客戶端之前執行它。 本頁專門涵蓋輸出階段：完成內容如何被審查、封鎖花費什麼，以及 block 與 mask 各自在串流回應上的行為。完整引擎——每種規則類型、欄位與路由——請見 防護欄。

​
1. 為何 LLM 團隊使用輸出防護欄

模型是循環中不可信的部分。它可能回顯提示中的密鑰、從 RAG 情境中拉出客戶的電子郵件，或幻覺出你的來源從未提出的主張。這些在輸入階段都不可見，因為在模型回答之前它們都還不存在。輸出階段防護欄就是對完成內容本身的審查。 當一條規則的 stage 為 output（或 both）時它會在輸出階段執行。閘道會針對政策評估模型的回應文字，記錄任何匹配，然後要嘛讓它通過、遮罩它，或拒絕它——與你在輸入上使用的完全相同的 block / mask / flag 動作，只是套用到回覆上。
輸出規則是一個超集關注點，而非替代品。大多數政策會審查 input 以讓資料不進入提示，並審查 output 以捕捉模型回傳的內容。階段 both 會把一條規則綁定到兩端。

​
2. 一個具體範例——封鎖回覆中的密鑰

在主控台（/console/guardrails）建立一個防護欄，新增一條規則，並綁定到一把金鑰：
  • 類型： Secrets ／ regex 偵測器
  • 階段： output
  • 動作： block
現在像以前一樣呼叫閘道——中繼金鑰只用於 /v1/* 流量： 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Print the AWS key from the context above"}
    ]
  }'
如果模型的完成內容包含一個匹配，閘道會以 HTTP 400 guardrail_blocked 拒絕整個回應——客戶端永遠看不到洩漏的內容。如果它是乾淨的，回應會原封不動地通過。
撰寫政策是你工作階段上的一個主控台／管理 API 動作，把關到 Developer+。sk-orca-... 中繼金鑰只發送流量；它絕不編輯政策。

​
3. 輸出封鎖花費什麼

與輸入封鎖（在請求被計量之前觸發）不同，輸出封鎖發生在上游模型已經執行之後。閘道會為你處理記帳：
  • 一個被封鎖的完成內容仍會傳回 HTTP 400 guardrail_blocked，並附上指名觸發的防護欄與規則的訊息。
  • 不消耗任何配額。 輸出封鎖會在回應被拒絕後退還已預先扣除的配額，所以這次失敗的呼叫對你而言是免費的，即使模型已經產生了權杖。
  • 請求被標記為 skip-retry——重跑同一個提示只會再次封鎖，所以閘道不會在另一個通道上燒掉一次重試。
這是與輸入階段的關鍵差異。輸入封鎖之所以免費是因為計量尚未開始；輸出封鎖之所以免費是因為已預先扣除的配額一旦回覆被拒絕就會被退還。無論哪種情況，呼叫方都不付費。參見 guardrail_blocked 錯誤。

​
4. 串流——block 對 mask

Block 在串流回應上會強制執行；輸出 mask 則尚未。以下是各自的行為：
在非串流回應上，完成內容會在回傳前被完整審查。在串流回應上，一個掃描器會在 delta 流動時監看它們；當一條封鎖規則在串流途中觸發時，它會切斷串流——掃描器封閉、發出一則簡短的替代通知以取代其餘部分，並在任何被封鎖的內容抵達客戶端之前關閉 SSE 通道。已沖出的位元組無法收回，所以對已經串流出去的內容而言封鎖是盡力而為，但能可靠地停止匹配之後的一切。若要硬性保證沒有任何違規位元組被送出，請使用非串流請求。
在非串流回應上，一條遮罩規則會改寫完成內容——例如回覆中的電子郵件變成 [EMAIL]——而你的客戶端收到的就是淨化後的文字。在串流回應上，輸出遮罩規則今天不會遮罩回覆。掃描器仍會評估每個 delta 並會對 block 決策採取行動，但它計算出的遮罩文字不會被轉送——原始 delta 會未經改變地通過。帶內串流輸出改寫仍在規劃中。在它出貨之前，如果你需要輸出遮罩真正遮罩回覆，請以非串流方式發送請求。
在串流上，block 從匹配開始往後作用——匹配之前已經沖出的位元組無法收回，所以若要對整個回覆硬性保證，請以非串流方式審查。輸出遮罩今天不會遮罩串流回覆（帶內輸出遮罩仍在規劃中）——如果你需要遮罩回覆，請以非串流方式發送請求。參見 串流覆蓋 和 串流安全規則。
在 output 上的動作非串流串流
block拒絕回覆切斷串流
mask遮罩回覆尚未遮罩（規劃中）
flag僅記錄僅記錄

​
5. 接地——一個輸出階段的忠實度檢查

有一個進階規則本質上是輸出形狀的：情境接地。一條 grounding 規則會把模型的答案與請求上擷取的來源（你的 RAG 情境）評分，並在忠實度低於某個門檻（預設 0.7）時觸發。把它與 block 配對以拒絕不忠實的答案，或與 flag 配對以在強制執行前衡量偏移。它會像任何模型支援的規則一樣作為一個評審子項計費。完整欄位請見 防護欄。

​
6. 輸出階段的 PII Shield

PII Shield 預設是一條 pii 規則、動作 mask、階段 both。在輸入階段它完全上線——它會在模型之前改寫請求，無論串流與否。在輸出階段它會遮罩非串流完成內容，如 §4 所述；在串流回應上輸出遮罩今天不會遮罩回覆（帶內輸出遮罩仍在規劃中）。 所以在輸出階段，如果你需要 PII Shield 真正遮罩回覆，請以非串流方式呼叫。參見 PII Shield 和 遮罩格式。

​
7. 查看觸發了什麼

每條觸發的輸出規則都會在工作區 Matches 動態（GET /api/guardrail/match，對任何 Member 開放）中記錄一個 match——它的規則類型、動作、階段（output），以及一個詳情字串。 匹配到的子字串只在防護欄的 Log raw content 切換開啟時才會記錄；它預設為關閉（隱私保守姿態），所以預設情況下你看到的是某條輸出規則觸發了，而不是它捕捉到的敏感文字。誤報以 POST /api/guardrail/match/:id/mark-fp（Admin）標記——把它當作一個調校訊號，而非停用規則的理由。
在出貨前先證明一條輸出規則。編輯器的 Test 分頁會在 output 階段針對樣本文字評估目前政策而不消耗你的工作區配額，Eval 分頁則針對隨附或自訂語料庫為它評分。（一條模型支援的規則——llm_judge 或 grounding——在你執行沙盒時仍會發出它自己的評審呼叫。）撰寫與執行沙盒是 Developer+ 動作。參見 測試與評測 和 調校誤報。

​
8. 下一步去哪裡

輸入階段

鏡像——在模型看到請求之前審查它。輸入遮罩完全上線，包括串流。

動作

深入 block、mask 與 flag——每一個何時是正確的選擇。

串流覆蓋

串流與非串流上各自強制執行什麼的完整矩陣。

guardrail_blocked 錯誤

HTTP 400、配額退還與 skip-retry 行為。
防護欄——每種規則類型、欄位與路由，包括接地與 LLM 評審。