跳轉到主要內容
當一個模型回覆時,它不只是傳回文字——它發出 tool_calls:帶有真實、 模型所選引數的具體呼叫。代理防火牆的 response 介面正好審查那些,就在它們離開模型的那一刻、在它們 抵達你的代理迴圈之前。它是你以模型實際挑選的引數,過濾模型實際 決定要做什麼的那個介面。 本頁涵蓋在 response 介面上過濾的使用情境——何時要選它而非 inbound、它加上的那一個 裁決轉折,以及它在一個串流上如何行為。關於完整的規則詞彙與裁決 語意,參見規則綱要與 裁決。

​
1. 過濾 LLM 工具 response 呼叫，引數在範圍內

inbound 介面看見你公告的工具 ——僅名稱,尚無呼叫時引數。response 介面看見模型發出的 tool_calls,它們攜帶模型所選的引數。那正是要在這裡過濾的全部 理由:它是唯一看見一個客戶端執行（非 MCP）工具的實際呼叫 + 引數 的介面,所以引數子句、 序列與執行狀態規則全都落在 response 上。 一行說明這個區別：
介面看見用它來
inbound公告的工具定義讓一個工具對模型隱形
response發出的 tool_calls + 引數過濾模型實際做出的呼叫
所以 inbound 回答哪些工具存在;response 回答模型對其中一個 做了什麼。當一個工具在某些請求中正當出現、但它的某一個特定呼叫 危險時——或當你只控制代理迴圈而非被公告的工具集時——去拿 response（或將 stage 留空以涵蓋兩者）。
一條沒有 stage 的規則會在每個介面上執行,包括 response。只有 當一條規則應該只審查發出的呼叫時才固定到 response——例如一個在 inbound 介面上無論如何都沒有東西可匹配的引數子句。參見 介面。

​
2. 一個具體範例

一般允許 shell.exec,但在它的 command 引數看起來具破壞性的那一刻 就把它從模型的回覆中剝除。在你的工作區主控台中,開啟一個政策（或 建立一個）並加入一條固定到 response 介面的規則： 
{
  "label": "block destructive shell calls",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
引數匹配器存在於 args_match_json 中——一個持有 {"clauses":[…]} 的 JSON 字串,每個子句是一個 path / op / value 三元組（op 是 eq、contains、regex、gt、lt 之一）。主控台表單會為你建構它; 這裡顯示的原始形狀是為了讓欄位名稱明確無誤。 該工具仍被公告——模型仍能提議 shell.exec——但當發出的呼叫攜帶 一個破壞性的 command 時,防火牆會在你的代理看見它之前從回覆中 移除那個 tool_call。一個良性的 shell.exec（譬如 ls -la）會原封 不動地通過。這就是 response 介面存在的目的——「允許工具、把關呼叫」 模式;引數子句是讓它成為可能的東西。
規則按優先順序評估,第一個匹配者勝出。把一個窄的 allow 例外放在 比一個寬泛的 deny 更低的 priority 數字,這樣例外先執行。參見 規則優先順序。

​
3. 一個裁決在 response 介面上做什麼

response 介面審查每一個發出的 tool_call,並就地改寫回覆。被保留的 呼叫會逐位元組轉送;只有一個匹配到的呼叫會改變：
匹配到的 tool_call 會在它抵達你的代理之前從模型的回應中被移除。 與一個 inbound deny 不同——後者傳回 HTTP 400、代碼 firewall_blocked——一個 response 介面的 deny 不會使請求失敗;回覆 的其餘部分（其他工具呼叫、任何文字）會流過,而違規的呼叫就是 不存在。
呼叫引數中匹配到的子字串會被替換為引擎遮罩後的引數,而清理後 的呼叫會被轉送——當工具沒問題但模型在一個引數中放了一個密鑰或 PII 值時很有用。Sanitize 只遮罩工具呼叫引數;它絕不觸及工具 回傳的內容。如果引擎沒有東西可替換,該呼叫會被剝除（失敗 關閉）。參見淨化回應。
人工介入（HITL）的保留在 inbound 介面上開啟,而非 response。 因此一條首先在一個發出的呼叫上匹配的 pending_approval 規則會被 剝除（失敗關閉）——保留它會轉送一個未經審查、無人類決策的呼叫。 將 HITL 保留撰寫為在 inbound 觸發;參見 審批。
allow 與 audit 都會轉送該呼叫;audit 是常見的 default_verdict ——記錄一切、封鎖無物,直到你準備好強制執行為止。
cap_cost 與 pending_approval 在這個介面上是 inbound 概念。 cap_cost 在 response 上是惰性的（模型已經執行了）,而 pending_approval 會解析為一個剝除而非一個保留。把成本上限與 HITL 保留放在 inbound 介面上——參見 成本上限與 審批。

​
4. 串流：先保留,然後過濾

在一個非串流回覆上,整個回應會被一次解析並過濾。在一個串流上, 一個模型的 tool_calls 會作為跨許多 SSE 框格的每索引差量抵達——而 一旦一個差量被轉送,你的代理已經有了它且它無法被撤回。所以閘道會 保留工具呼叫框格:它們絕不在串流中途被轉送。在串流結束時, 防火牆會組裝每一個呼叫（名稱 + 完整引數）、評估它,並只發出 倖存的呼叫。
內容框格仍正常串流——文字權杖在抵達時觸及你的客戶端。只有 tool_call 框格會被保留以待評估,所以一個被拒絕或被淨化的呼叫會在 被組裝的工具呼叫被交付之前被過濾掉。裁決與規則語意與非串流介面 完全相同。關於框格層級的細節,參見 串流內部機制與 供應商串流。

​
5. 安全地推出

主控台 Test 分頁會對照一個樣本工具呼叫執行一個政策,並傳回 裁決、匹配到的規則與原因——不派發、不持久化任何東西。在綁定一個 金鑰之前,確認你的 glob 與引數子句匹配你意指的呼叫。參見 測試規則。
開啟影子模式,每個強制 執行的裁決——包括一個 response 介面的 deny——都會被降級為 audit,原因加上前綴 [shadow] would …。你能在它改變任何一個 回覆之前,精確衡量該規則對照真實流量會剝除什麼。
每一次評估都會寫入一個帶有裁決、介面、工具與匹配規則的防火牆 事件。按介面 response 篩選 事件記錄,以看見你的規則在 你預期的發出呼叫上觸發。參見分析。

​
6. 綁定政策以及誰能設定它

一個政策在某個金鑰解析到它之前什麼都不做。在主控台中透過在 金鑰上設定 firewall_policy_id 來綁定,或將該政策設為工作區預設值。解析:金鑰 綁定的政策（當它存在且已啟用時）,否則是工作區預設值——而一個 已停用的綁定政策會回退到工作區預設值。參見 管理政策。 所有設定都在主控台中於你的工作階段下執行 （/api/workspace/firewall/*）：
動作角色
讀取政策、預設集、discovered tools、SimulateMember
乾跑（Test）、讀取事件記錄與執行彙整Developer+
建立／編輯／刪除規則與政策Developer+

​
相關

驗證引數

讓 response 介面過濾變得精確的引數子句。

淨化回應

從一個呼叫的引數中遮罩密鑰,而非剝除它。

防火牆介面

response 如何與 inbound、mcp 與 egress 比較。

封鎖工具

inbound 對應物:在模型被提供一個工具之前拒絕它。

危險的工具呼叫

response 過濾處理的威脅。

防火牆參考

完整的規則 + 匹配參考。