<!-- Canonical URL: https://ask.atlascloud.ai/zh-TW/set-hard-spending-limit-coding-agent-task -->

# 如何為編碼代理任務設定硬性支出上限？

> 硬性支出上限必須由掌管任務預算的閘道在每次模型或付費工具呼叫之前執行。先預留最壞情況下的成本，再按實際用量結算；無法容納下一次呼叫時直接拒絕，並讓代理留下可繼續執行的檢查點，而不是等錢花完後才發送提醒。

<!-- Canonical URL: https://ask.atlascloud.ai/set-hard-spending-limit-coding-agent-task -->

# 如何為編碼代理任務設定硬性支出上限？

硬性任務預算本質上是准入控制問題。在任何計費模型或工具呼叫開始之前，可信閘道必須證明允許的最壞成本仍可由任務剩餘餘額涵蓋。提醒和執行後報告很有用，但無法阻止已經發生的超支。

該設計應涵蓋輸入 token、最大輸出、重試、備援、子代理、嵌入、搜尋、沙箱，以及代理可以呼叫的其他任何付費工具。

## 區分硬限制和軟目標

使用三個數值：

| 控制項 | 目的 | 行為 |
|---|---|---|
| 目標 | 預期成本 | 警告或選擇更便宜的方案 |
| 軟限制 | 升級閾值 | 請求核准或降低品質 |
| 硬限制 | 最大授權支出 | 在下一次呼叫開始前拒絕 |

例如，一個任務可以把目標設為 $0.60，在 $0.90 時請求核准，並在 $1.00 時停止。硬限制必須位於伺服器端，而不能只寫在代理提示詞中。

## 讓所有付費操作經過一個閘道

為代理發放只能呼叫自有閘道的短期任務憑證。閘道附加 `task_id`，查詢預算，估算下一步操作，並決定預留資金或拒絕請求。

不要暴露可繞過記帳的供應商金鑰。網頁搜尋、託管沙箱、程式碼執行和付費檢索服務也應遵守相同規則。

## 呼叫前預留，呼叫後結算

對於模型呼叫，根據已知輸入 token 和設定的最大輸出估算上限。以原子方式預留該金額，發出請求，再用實際回報用量替換預留。

```text
remaining = hard_limit - committed_cost - open_reservations
worst_case = input_cost + max_output_cost + tool_allowance

if worst_case > remaining:
    reject("task_budget_exceeded")
else:
    reserve(worst_case)
    call_provider()
    reconcile(actual_cost)
```

原子預留可以防止兩個並行子代理同時花掉同一筆剩餘餘額。

## 使用帶版本的費率表計價

把每次估算採用的價格與事件一起保存。模型價格和計費規則可能改變，因此後續報告不應使用今天的費率重新計算舊用量。

如果供應商回傳權威成本，應同時保留估算值和最終費用。如果只回傳 token，則使用呼叫前選定的費率表版本計算。對未知工具費用加入保守餘量；如果無法確定最大成本，則拒絕呼叫。

## 確保串流回應安全

在開啟串流之前預留允許的全部回應成本。可用時統計接收的用量，但不要假設關閉用戶端連線會立即停止供應商計費。取消是一種最佳化，不是強制邊界。

為每次呼叫設定輸出上限和牆上時鐘逾時。任務硬限制仍然涵蓋所有串流、重試和備援的總和。

## 包含重試和子代理

每次嘗試都從同一個父任務帳本扣費。重試策略如果悄悄建立新預算，就會讓限制失效。

代理委派任務時可使用分層預算：

| 帳本 | 上限 | 規則 |
|---|---:|---|
| 父任務 | $1.00 | 絕對上限 |
| 實作子代理 | $0.55 | 不能超過父任務剩餘餘額 |
| 測試分析子代理 | $0.25 | 返還未使用預留 |
| 最終審查 | $0.20 | 僅在仍有餘額時執行 |

子限制是分配額，不是額外資金。

## 以有用的檢查點停止

下一步操作無法容納時，回傳編排器能理解的型別化錯誤。代理不應反覆重試被拒絕的呼叫。

讓它使用已有上下文產生不需額外費用的檢查點，其中包括：

* 已完成變更和測試結果；
* 剩餘工作與被阻塞操作；
* 目前儲存庫狀態；
* 繼續所需的估算預算；
* 恢復 token 或任務 ID。

這樣，預算停止就會變成受控交接，而不是損壞的半成品執行。

## 把供應商控制作為後備保障

供應商和閘道的帳戶限額可以降低影響範圍，但通常不是精確的單任務控制。它們可能彙總多個儲存庫、非同步更新，或者不包含工具費用。

使用 Atlas Cloud 等多模型閘道時，應把權威任務帳本放在自己的編排層，並記錄閘道用量識別碼用於對帳。即使任務切換模型，硬邊界也能保持不變。

## 像測試財務控制一樣測試上限

測試並行呼叫、長串流、供應商逾時、缺少用量欄位、重試、模型備援和帳本故障。預算服務不可用時預設拒絕。驗證已確認成本與開放預留之和永遠不會超過硬限制。

## 結論

真正的硬性支出上限必須在消費前執行，並使用原子預留以及涵蓋所有計費操作的統一帳本。如果系統只在用量產生後發出提醒，就應稱其為監控，而不是硬上限。

## FAQ

### max_tokens 是硬性美元上限嗎？

不是。它只限制單次回應長度，不限制任務總成本、輸入 token、重試、模型切換或付費工具。美元上限需要包圍所有計費操作的預算帳本。

### 編碼代理預算應在哪裡強制執行？

應在所有模型和付費工具呼叫都必須經過的伺服器端閘道或編排層執行。用戶端計數器可能被繞過，也可能在並行時發生競態。

### 如何為串流回應做預算？

在開啟串流之前預留允許的最大輸出成本，串流結束後再根據回報用量結算。供應商支援時可以取消請求，但不要把取消當作唯一的強制手段。

### 重試是否應共用原任務預算？

是。重試、備援、子代理和評估呼叫都應從同一任務帳本扣費，除非使用者明確核准獨立預算。

### 剩餘預算不足時應該怎麼做？

拒絕下一次計費呼叫，並讓代理利用已有上下文產生檢查點。檢查點應說明已完成工作、未解決事項以及繼續所需金額。

### 供應商帳戶限額能否代替單任務限額？

通常不能。帳戶限額保護整個帳戶，而且可能非同步更新。單任務閘道可立即實現隔離，帳戶級控制則可作為額外保障。