OmniRoute Auto Combo 怎麼設預算？2026 Agent 路由教學

遇到的症狀通常是：Agent 明明設了「最便宜」模式，供應商一異常，請求仍然被送到超出預期成本的模型。

最快解法是：先建立候選模型白名單，再設定單次請求預算，並把 X-OmniRoute-Budget-Fallback 設為 strict；完成四類故障模擬後，才讓第一個測試客戶端灰度接入團隊規則。

這篇適合三類讀者：想用 OmniRoute Auto Combo 控制單次 Agent 請求成本的開發者；需要為多個 AI 編程工具建立統一路由規則的平台工程師；以及準備把本地閘道遷移到持續在線環境的遠端團隊。

先把三種預算拆開，否則規則一定會失真

OmniRoute 的預算控制不是只有一個數字。實際配置前，應把以下三個控制層分開：

1. 單次請求預算：限制一個 Agent 請求可以接受的最高估算成本，適合阻止單一長上下文、工具呼叫或重試鏈突然放大支出。
2. API Key 的 Token 限額：限制某個金鑰在指定時間窗內可以使用的 Token，並可按 model、provider 或 global 範圍套用。官方 API Reference 說明，符合多條限制時會採用最嚴格的一條，達到上限後預期回應 429 Too Many Requests。(github.com)
3. 團隊週期預算：用於月度或週期性財務控管，不能取代請求級阻擋，因為它通常在累積用量後才看得出問題。

這三層解決的是不同風險。單次預算防止一次請求失控，Token 限額防止金鑰被長時間消耗，團隊預算則用來做成本分攤與管理報告。若只設定其中一層，仍可能出現「單次沒有超支，但長任務連續重試後突破團隊上限」的情況。

此外，先定義超預算後的失敗策略：

• 阻斷：不能接受超支，請求直接失敗，適合生產 Agent。
• 降級：只允許白名單中的低成本候選，沒有符合者就停止。
• 提醒：允許成本較高的候選繼續，但必須留下告警與人工接管入口。

目前文件將 cheapest 列為預設回退行為；當所有候選都超過預算時，它仍可能選擇全域最便宜者。strict 則會拒絕選擇，文件示例預期使用 HTTP 402 快速失敗。這也是為什麼「cheapest」不能被當成嚴格預算控制。(github.com)

提醒：官方文件的欄位名稱、別名與預設行為可能隨版本更新。本文引用的文件頁標示版本包括 3.8.40 與 release/v3.8.49，上線前應再次核對當前 Schema、發佈記錄與實際回應。(github.com)

第一個時間點：只建立能被驗證的候選池

Auto Combo 可以使用 auto 或 auto/<variant> 前綴建立虛擬組合，也可以透過一般組合 API 保存 strategy: "auto" 的設定。文件描述，虛擬組合會按每次請求重新建立候選池，並從目前啟用、憑據有效且具備模型資訊的連線中挑選候選。(github.com)

這種便利性同時帶來一個平台風險：只要新增一個有效供應連線，預設 auto 可能就會把它納入可選範圍。預算敏感的 Agent 不應直接把「所有已連線模型」當作生產候選池。

首次配置可按以下順序處理：

1. 為每個候選確認憑據有效，至少完成一次基礎文字請求。
2. 檢查候選是否支援目標 Agent 所需的串流輸出、工具呼叫與長上下文。
3. 為每個候選記錄用途，例如編程、摘要、規劃或故障分析。
4. 為每個候選寫下不可用時的替代項，避免故障時臨時擴大候選池。
5. 將未完成驗證、用途不明或成本資料不完整的模型排除在生產組合之外。

配置時不要把真實金鑰、內部地址或團隊專案名稱貼進教學檔案。可先用以下占位符保存組合：

{
  "id": "<COMBO_ID>",
  "name": "<AGENT_COMBO_NAME>",
  "strategy": "auto",
  "config": {
    "auto": {
      "candidatePool": [
        "<APPROVED_MODEL_A>",
        "<APPROVED_MODEL_B>"
      ]
    },
    "budgetFallback": "strict"
  }
}

這裡的關鍵不是候選數量，而是每個候選是否有明確責任邊界。對 AI Agent 而言，工具呼叫、長任務和多輪對話比一般問答更容易讓路由規則失效；候選池越大，驗收矩陣也會跟著擴張。

第二個時間點：把請求級預算與 strict 寫成可覆核規則

目前 Auto Combo 文件列出的請求級控制包括：

• X-OmniRoute-Mode：覆蓋本次請求的模式或權重組合。
• X-OmniRoute-Budget：設定本次請求的最高美元估算成本。
• X-OmniRoute-Budget-Fallback：決定所有候選都超出上限時，是選最便宜候選還是直接拒絕。

其中，請求標頭只影響帶有該標頭的單次請求；若沒有標頭，則使用已保存組合中的 modePack、budgetCap 或 budgetFallback。這表示平台團隊可以讓不同 Agent 使用不同預算，不必修改同一份共享組合。(github.com)

測試請求可以使用以下形式，數值維持占位符：

curl -sS "<OMNIROUTE_BASE_URL>/v1/chat/completions" \
  -H "Authorization: Bearer <AGENT_API_KEY>" \
  -H "Content-Type: application/json" \
  -H "X-OmniRoute-Mode: <MODE>" \
  -H "X-OmniRoute-Budget: <MAX_USD_PER_REQUEST>" \
  -H "X-OmniRoute-Budget-Fallback: strict" \
  -d '{
    "model": "auto",
    "messages": [
      {
        "role": "user",
        "content": "<TEST_PROMPT>"
      }
    ],
    "stream": false
  }'

預期結果應分成兩類記錄：

• 有至少一個候選低於預算：請求正常選擇符合條件的候選。
• 所有候選都高於預算：strict 應阻止選擇，而不是改用較昂貴模型。

若實際結果仍然成功返回，先不要把問題歸咎於路由器。依序檢查請求是否真的使用 model: "auto"、標頭是否被反向代理移除、數值是否為正數，以及保存的組合策略是否真的是 auto。官方文件也提醒，未知的模式值可能被忽略，因此測試時必須保存「送出的標頭」與「解析後的設定」，不能只看客戶端畫面。(github.com)

第三個時間點：用四種故障把回退邏輯逼出來

只測一個正常請求，無法證明 OmniRoute 的預算路由安全。至少要模擬以下四種結果：

所有候選都超過預算

把預算設定在低於所有候選估算成本的範圍，並使用 strict。預期是快速失敗，保存 HTTP 狀態、錯誤內容、請求識別與路由解釋。

如果結果變成成功，代表目前實際套用的是 cheapest 或其他覆蓋規則；這時不能直接進入灰度。

首選供應不可用

暫時停用首選連線或讓它進入不可用狀態，確認路由是否切換到白名單中的替代候選。Auto Combo 文件描述了健康分數、斷路器狀態與候選排除機制，供應處於 OPEN 時會被排除；但實際版本仍應以請求記錄核對。(github.com)

憑據失效

替換一組已失效的測試憑據，確認系統不會把認證失敗反覆重試成成本放大器。預期結果可以是切換到其他有效候選，也可以是明確失敗，但不能出現無限重試。

限流或 Token 限額觸發

對測試 API Key 設定較低的 Token 限額，確認達到限制後是否回應 429，以及 Agent 客戶端是否自行重試。官方 API Reference 指出，Token 限額可按模型、供應商或全域套用，並會在請求路徑內執行。(github.com)

路由驗收至少應保存以下資料：

• 原始請求識別與 Agent 名稱；
• 使用的預算值與回退模式；
• 被評估的候選及排除原因；
• 最終模型與供應連線；
• HTTP 狀態、錯誤內容與重試次數；
• 路由解釋是否能指出成本、健康、配額或延遲因素。

API Key 的 model、provider 與 global 限額，以及不同 Agent 的權限，應分別記錄在團隊的金鑰管理規範中；不要把「可使用的模型範圍」與「單次請求預算」合併成一個欄位。

第四個時間點：先接入一個非生產 Agent

第一個客戶端不應直接選團隊最重要的工作流。比較穩妥的做法是先選一個非生產 Claude Code、Cursor 或自建 AI Agent，檢查四個邊界：

1. 模型映射：客戶端送出的模型名稱是否確實被解析成 auto 或保存的組合。
2. 串流輸出：串流中途切換或失敗時，客戶端是否能正確結束連線。
3. 工具呼叫：工具參數是否在回退後仍保持相同格式，避免 Agent 把模型切換誤判成工具失敗。
4. 長任務與重試：客戶端本身是否會在收到 402 或 429 後自動重試，造成預算控制被外層重試繞過。

所有測試設定使用占位符：

export OMNIROUTE_BASE_URL="<OMNIROUTE_BASE_URL>"
export OMNIROUTE_API_KEY="<AGENT_API_KEY>"
export OMNIROUTE_MODEL="auto"
export OMNIROUTE_COMBO_ID="<COMBO_ID>"

測試時應把 Agent 的重試政策暫時調低，或至少在日誌中標記每次重試。否則一次原本被 strict 阻斷的請求，可能被客戶端重新送出多次，平台看到的只是多筆失敗請求，卻無法判斷是否存在預算繞過。

兩組決策表：什麼情況應該阻斷，什麼情況可以回退

以下不是用來取代實測，而是用來決定測試順序與失敗處理。

第一週灰度：把路由規則交付給團隊前先建立可退回點

灰度不宜按「全員開啟」處理，而應按客戶端、成員或專案逐步放量。第一週至少觀察：

• 實際單次任務成本是否經常貼近上限；
• strict 阻斷比例與阻斷原因；
• 各候選的實際路由分布；
• 供應故障、限流與憑據失效的回退比例；
• Agent 自身重試是否增加重複請求；
• 工具呼叫與長任務是否集中落到某一個候選。

配置變更也要留下版本記錄，包括修改者、時間、候選增刪、預算變更、回退策略與驗收結果。若團隊準備從本地環境轉到持續在線的遠端閘道，應先完成 雲端 Mac 租用環境的連線與交付說明，再把 OmniRoute 的地址、金鑰與監控設定分開交付；不要把本機測試用金鑰直接複製到共享環境。

當遠端成員需要穩定使用同一套開發工作流時，還要評估持續在線環境的斷線恢復、權限分層與操作入口，可再參考 Mac 遠端桌面與 VDI 使用方案。這一步的重點不是把所有 Agent 都搬上雲，而是確保規則、憑據與日誌能被同一個團隊維護。

長期維護：模型價格變了，候選池就不能視為永久有效

Auto Combo 的評分會參考成本、延遲、健康、配額與任務適配等因素；文件也列出不同模式，例如 cost、latency、sla-aware 與 lkgp。因此，歷史上最便宜的模型不代表日後仍然最適合，尤其當上游價格、可用性、Token 限額或憑據狀態改變時。(github.com)

平台團隊至少應在以下事件後重新模擬四類路由：

• 上游價格或計價方式變更；
• 模型名稱、上下文能力或工具支援變更；
• OmniRoute 版本更新；
• 新增或刪除供應連線；
• API Key 限額或重設週期變更；
• 某候選連續出現限流、憑據失效或高錯誤率。

若生產規則要求可預測性，應保存一個已驗收的回退組合，而不是只依靠動態虛擬候選池。需要持續在線運行時，還應把路由日誌、配置備份與人工接管入口納入部署設計；自建伺服器或遠端環境的資源成本，可先評估是否符合長期工作流，再決定是否採用專用 Mac VPS。

結論：把 Auto Combo 當成預算政策，不只是便宜模型選擇器

OmniRoute Auto Combo 的價值在於把候選模型、健康狀態、成本與回退規則放進同一條請求路徑，但它不會自動替團隊決定「超支時應否失敗」。對預算敏感的生產 AI Agent，正確順序是白名單、請求預算、strict 失敗策略、四類故障模擬，最後才是多成員灰度。

如果目前方案是每台開發電腦各自保存金鑰與模型設定，常見缺點是成本規則不一致、故障回退無法集中追蹤、成員離線後沒有統一入口，長任務也容易因本機環境差異而重複執行。若需要讓多個遠端成員共享同一套 Agent 路由規則，租用 Zilmac 的 Mac 環境會比臨時拼接多台本機或不受控的雲端主機更容易集中管理；但長期固定重負載、必須直接接觸實體周邊，仍應優先評估自購設備。

在切換環境前，建議先用非生產 Agent 完成「全候選超預算、首選故障、憑據失效、Token 限額」四類模擬，再決定是否把規則交付給團隊。若測試結果穩定，再進一步規劃持續在線閘道與雲端 Mac 工作環境，會比直接把未驗收的 cheapest 回退策略推入生產更安全。

• 多模型 API 價格與呼叫成本比較
• 程式碼代理串接模型的設定教學
• 程式碼代理訂閱方案、價格與功能分析