跳轉到主要內容
一個卡在重試迴圈、扇出一千個子任務,或單純在計畫中途失控的推理 代理,可能在任何人注意到之前花掉真金白銀。cap_cost 防火牆 裁決就是針對那個的斷路器:你撰寫一次每執行的分（cents）上限,而閘道 會在一個執行的累計花費跨越它的那一刻拒絕下一次工具呼叫——在那次 呼叫抵達模型或工具之前。 這是在閘道處強制執行的 AI 代理成本控制,而不是栓在你的代理迴圈 上的。像每個防火牆裁決一樣,一條 cap_cost 規則存在於一個工作區政策中、綁定到一個金鑰,並在下一次 呼叫時生效而無需重新部署。

​
1. 每執行的花費斷路器

cap_cost 是一個你以一個額外欄位撰寫的規則裁決——cap_cost_cents, 該執行以 USD 分計的花費上限。當規則匹配一次工具呼叫時,引擎會將 代理執行的累計花費對照那個上限比較：
  • 在上限之下 → 呼叫被允許;評估繼續。
  • 超過上限 → 呼叫被拒絕,原因會指名該執行的總額對比上限。那是 終端的、斷路器式的結果——該執行在一個全新執行之前無法發出另一個 受治理的呼叫。
該上限以代理執行為鍵,而非單一請求。一個已經燒掉它大部分預算的 長執行,會在它的下一次呼叫上被拒絕,即使那一次呼叫很便宜——斷路器 在運行總額上跳閘,而非在邊際成本上。
執行範圍,帶有一個每請求回退。 當請求攜帶一個代理執行 id 時, 該上限套用於該執行的累計花費。一個沒有執行關聯的呼叫（例如一個沒有 轉送工作階段的光禿禿 MCP 派發）會改回退到一個每請求的比較。無論 哪種方式,斷路器都在超預算的呼叫被派發之前跳閘。

​
2. 一個具體範例

將一個金鑰上的任何執行的累計花費設上限為 $5.00。一條單一的 萬用字元規則就辦到——cap_cost_cents 為 500（分）： 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
在你已建立的一個政策上於主控台規則編輯器中撰寫它（參見 建立與綁定政策）。撰寫一條 規則是一項 Developer+ 動作。透過 firewall_policy_id 將該政策 綁定到一個金鑰,或將它設為工作區預設值,而該金鑰驅動的每一個執行 現在都被限界。 你可以把上限限定得比「每個工具」更緊。收窄 工具名稱 glob,這樣只有一個 昂貴的呼叫家族才計入斷路器——例如在 *.search 上的 cap_cost 以 限界網頁搜尋扇出,同時讓便宜的本地工具不被計量。
用優先順序堆疊一個較便宜的警告層。一個更高優先順序（較低數字）上 較低上限的 audit 規則,讓你能在 強制執行的 cap_cost 規則跳閘之前,在 事件動態中觀察一個執行逼近 它的預算。第一個匹配者勝出,所以把觀察者排在前面。

​
3. 它在哪裡觸發——以及在哪裡不能

cap_cost 只在一次呼叫被派發之前才有意義——那是停止該呼叫仍能 防止花費的那一個點。所以它在兩個派發前的介面 上是即時的,而在派發後的介面上被拒絕：
介面cap_cost？
inbound（公告的工具）強制執行。
mcp（tools/call 派發）強制執行。
response（模型發出的呼叫）儲存時拒絕——已沒有東西可停止。
egress（外送目的地）儲存時拒絕——已沒有東西可停止。
一條固定到 response 或 egress 的 cap_cost 規則在儲存時被拒絕, 所以一條規則絕不會顯示為即時卻又永遠無法拒絕。將介面留空以涵蓋 兩個派發前介面,或將它固定到 inbound / mcp。
對一條 cap_cost 規則而言,cap_cost_cents 是必填且非負的。主控台 與 API 會拒絕一條沒有上限的 cap_cost 規則,所以一個設定錯誤的上限 不能靜默地讓每一次呼叫通過。

​
4. 斷路器跳閘時的樣子

一個超預算的呼叫是一個正常的防火牆 deny：
  • 在 inbound 上,中繼會傳回 HTTP 400,帶有錯誤代碼 firewall_blocked。該封鎖在上游模型呼叫之前觸發,所以它不耗費 任何模型權杖,而且它被標記為 skip-retry——重跑同一個呼叫只會 再次讓斷路器跳閘。
  • 在 mcp 上,它會以一個工具錯誤回來,這樣模型會看見該拒絕並能 停止或詢問使用者,而非崩潰。
該 deny 原因會指名數字,例如 cap_cost: estimated run cost $5.40 exceeds cap $5.00,所以一個讀取 事件動態的操作員會精確看見 斷路器為何跳閘。
事件絕不攜帶一個字面的 cap_cost。 你將裁決撰寫為 cap_cost,但 引擎會在事件被記錄之前將它解析為一個具體的 allow 或 deny。 動態顯示代理實際看見的 allow/deny——執行成本上限是原因,而非裁決 標籤。這呼應了裁決如何解析。

​
5. 安全地推出

由於一個跳閘的斷路器會硬停止一個執行,在你強制執行之前驗證它。在 政策上開啟影子模式:cap_cost 規則仍會評估,而一個會發生的 deny 會被降級為 audit,加上前綴 [shadow] would …。觀察事件動態以確認上限在你預期之處跳閘——且 只在你預期之處——然後關閉影子模式以開始強制執行。 你也可以在 Test 分頁（一個 Developer+ 沙盒）中對照一個樣本呼叫乾跑一個政策,以在任何東西 依賴它之前看見解析後的裁決與匹配到的規則。

​
6. 它如何契合防火牆的其餘部分

cap_cost 是六個裁決之一。它自然地與同一政策上的其他控制項搭配：

裁決

完整集合——allow、audit、deny、sanitize、pending_approval,以及 cap_cost 如何解析。

封鎖危險工具

直接拒絕破壞性 shell、刪除,以及其他高風險呼叫。

規則參考

完整的匹配語言——glob、引數子句、序列。

異常偵測

對照一個習得的週小時基線標記的成本飆升。
一個執行成本上限是一個靜態、確定的後盾;防火牆也會學習每個 工作區正常的成本形狀,並在一個 Member 可讀的異常動態上對照一個 14 天的週小時基線標記飆升。用 cap_cost 做硬停止,用異常做早期訊號。
金鑰本身上的配額限制（credit_limit_usd）限界跨所有執行的總花費; cap_cost 限界單一執行。它們會組合——一個失控的迴圈會在它能耗盡 金鑰的生命週期額度之前很久就讓每執行斷路器跳閘。參見 範圍：金鑰、政策、工作區。

​
接下來去哪裡

建立與綁定政策

製作一個政策、挑選一個預設裁決、將它綁定到一個金鑰。

影子模式

在一個上限改變流量之前衡量它。
關於一個花費上限作為後盾的失控代理威脅,參見 過度代理權與 危險的工具呼叫。