Cost per task：使用低成本分類器路由至 Gemini 模型與思考層級

代理程式成本結構的轉變

Google Cloud AI 技術解決方案的 Sergio Villani 指出，雖然每百萬 token 的 API 價格持續下降，自主編碼代理程式的工程費用卻一路攀升。生產環境中，真正主導經濟面的指標已從單價轉向「每項任務成本」，也就是總支出除以通過驗證的任務數量。代理程式對每個微決策都調用高思考層級的推理配置時，等於為輕量級配置就能準確回答的問題，付了深度推理的價格。要避免這種不必要的開銷，建議在請求送到昂貴模型之前，先加一層輕量級路由，攔下常規決策。

分類器路由與規則路由的效能對比

文章以 TypeSafe 的 Jev 分類器為例，說明如何透過結構化輸出分類來評估任務。Jev 專為高吞吐量決策管道設計，能在單一前向傳遞中評估 Choice、Score 或 Noul 等結構化分類原語。測試中，以 50 個自動評分的編碼代理程式基準測試，對 Gemini 與 Jev 的線上 API 進行評估，檢驗這個近乎免費的分類器能否把每項任務路由到仍能答對的最便宜模型。

初期測試中，若用寬泛的 Choice 問題把任務分成簡單或複雜，Jev 會把多數任務送上簡單路徑，連需要追蹤 LRU 快取的任務也不例外。改成原子化的 Noul 問題後，系統就能精確判斷任務是否需要多步序列計算、模擬步驟或邏輯推導。在 16 個開發問題中，Jev 首次運行與手動標註的難度一致率為 13 比 16，第二次運行達 14 比 16。

相較之下，以正規表達式和 token 長度為基礎的本地啟發式規則，在 16 個開發問題中表現很好，準確率達 93.8%（15 比 16）。但這套規則未經修改、直接套用到 34 個未見任務時，準確率驟降 23.2 個百分點，只剩 70.6%。實際場景中，提取 Kubernetes YAML 端口這類簡單任務，因字數超過 35 字而被錯誤升級；反過來，簡潔的多步程式碼追蹤因缺少特定關鍵字，被錯誤送上簡單路徑。Jev 在全部 34 個未見任務上一致率達 100%，50 個任務合計準確率為 96.0%。

輸出限制並非思考預算的閥門

常見的誤解是，把 maxOutputTokens 上限設低就能降低簡單任務的成本。測試數據顯示，將 gemini-3.8-flash 的 maxOutputTokens 分別設為 300 與 4096，在 Jev 標記為 SIMPLE 的 27 個任務上，兩者的思考 token 消耗幾乎相同。上限只是天花板，簡單任務的答案從未接近這個限制。實際上，設限的版本在簡單任務上成本還略高，並導致 7 個困難任務失敗：其中 6 個因推理空間不足而沒有結果，第 7 個則因推理被壓縮而給出錯誤答案。

如果路由把簡單任務送到設限的模型，困難任務送到正常的 Flash，雖然 50 題全部答對，但總成本略高於全程使用正常 Flash，速度也更慢。這說明，如果低成本選項無法減少模型在簡單任務上的思考量，任何路由都省不了成本。

基準測試與最佳實踐建議

第二輪測試加入 Flash-Lite（預設不思考）與 Gemini 3.8 Flash（思考層級設為低）作為輕量選項。結果顯示，不做路由時，表現最強的配置是低思考層級的 Gemini 3.8 Flash，成功解決全部 50 個任務。Jev 路由配置同樣解決全部 50 個任務，做法是所有任務先送到 Flash-Lite，只把 Jev 標記為複雜的任務升級。這個配置在成本與回應時間上都優於全程使用低思考層級，對互動式代理程式來說，等待時間較短是主要優勢。

Flash-Lite 單獨運作時，半秒內就答完所有簡單任務，但漏掉 6 個困難任務。Jev 以高信心把這 6 個任務標為複雜並升級，讓成本接近完美路由器的水準。關鍵字啟發式規則雖然較便宜，卻錯把 5 個困難任務送到 Flash-Lite，其中 2 個失敗，總計只有 48 比 50。把困難任務升級到預設思考層級的 Flash，在這個情境下成本高於全程使用低思考層級；只有在低設定開始失敗時，升級到更重的設定才有意義。

快取機制與模型選擇的實務考量

路由與快取互相衝突。測試提示是短小、獨立的任務，Jev 路由有助於降低成本與延遲。但真實的編碼代理程式常在每一輪都送出相同的大塊上下文（如儲存庫地圖與工具定義）。Agent Platform Context Caching 可將重新發送的成本降低 75% 至 90%，但快取只屬於單一模型。如果代理程式在 Flash-Lite 與 Flash 之間切換，就得維持兩份快取，或放棄折扣。實務建議是：路由短小、自包含的任務（如日誌解析或結構驗證），長篇、上下文密集的回合則留在單一模型上。

Gemini 3.1 Pro 專為深度多步推理設計，對所有請求都提供這種深度。對於以快速檢查與提取為主的工作負載，Flash 配置更合適，Pro 則留給真正需要其推理深度的任務。此外，不同的模型配置可能套用不同的安全設定。測試中，Pro 配置拒絕了兩個短程式碼安全審查提示，Flash 則有回答。如果代理程式要執行安全審查，需要先測試打算使用的配置。

結論與實施步驟

文章提出三項實用規則。第一，建立路由之前，先使用低思考層級的 Flash。這個配置解決全部 50 個任務，成本也明顯低於預設設定。降低輸出 token 限制不能替代這個做法，應直接把 thinkingLevel 設為 "LOW"。

第二，用 Jev 路由短小、獨立的任務。簡單任務送到 Flash-Lite，困難任務送到低思考層級的 Flash。針對每個因素提出簡單的 yes-or-no 問題。這個配置在成本與回應時間上優於全程使用低思考層級，表現也接近完美路由器。長篇上下文的回合應留在單一模型上，以保住快取的效益。

最後，要測量代理程式的實際支出。把代理程式的追蹤記錄與思考 token 計數送到 Cloud Logging 與 BigQuery，找出推高支出的任務，並抓出造成成本膨脹的截斷或重試行為。最終目標是以「每項正確完成任務的成本」而非每 token 價格來評估各種選項，讓任務對應到最合適的模型。