適合代理程式（Agents）的高性價比 LLM API 概覽

此精選清單根據模型適用的工作類型進行分組。這是一份基於公開功能與定價的編輯精選，而非私下的效能對比排名。

費率檢查或確認日期為 2026 年 10 月 8 日。以上為 GPT Proto 費率，非供應商直接提供的促銷價格。Haiku 5.5 在提示詞超過 100K tokens 時，每百萬 token 的輸入成本為 $0.45，輸出成本為 $2.25。在編列預算前，請務必於各模型頁面確認適用的上下文層級、快取費用、服務層級及即時費率。

決策前請先比較： 瀏覽 GPT Proto 可用的 AI 模型，並將入選的模型 ID 保留在設定中，以便您無需重建整個代理程式即可進行切換。

我們如何為代理 AI 評選這些高性價比 LLM

Simon Willison 提供了一個實用的定義：LLM 代理程式會在迴圈中執行工具以達成目標。該迴圈改變了衡量性價比的方式。一般的聊天機器人比較可能只關注單次回應的成本；但代理程式的比較必須同時計算工具呼叫、工具結果、重試次數、推理 token 以及失敗的執行次數。

我們採用了以下評估順序。

1. 模型必須通過代理能力門檻

模型不會僅因為 token 價格低廉就被納入。每個入選選項都必須具備明確的函式呼叫或工具使用路徑，以及能夠回傳結構化資料或延續多輪工作流程的可行方案。

2. 公開代理程式（Agent）的實證比通用知識評分更重要

「Berkeley Function Calling Leaderboard」對於理解工具使用評估應檢查的項目特別有幫助：正確的函式選擇、有效的參數、多輪對話行為，以及模型應避免呼叫工具的情況。然而，其公開排行榜最後更新於 2026 年 4 月 12 日，早於本文中的大多數模型。因此，我們採用其評估方法，而非將其舊分數套用於較新的版本。

我們也參考了 Artificial Analysis。其 Intelligence Index 包含了代理程式知識工作、現實世界工作、SaaS 自動化、終端使用以及長文本評估。這仍然是一個混合指標（而非純粹的函式呼叫評分），應將其視為篩選依據，而非特定代理程式的效能保證。

3. 每次成功任務的成本比單一 Token 的價格更重要

實用的生產指標為：

每次成功任務的成本 = 所有嘗試與重試的總 API 成本 / 已完成的任務數量

此計算應包含未快取的輸入、已快取的輸入、輸出、適用時的隱藏或計費推理 Token、失敗的嘗試以及恢復呼叫。如果一個模型完成了 100 個任務中的 90 個，而另一個完成了 60 個，僅比較它們的標價 Token 費率會掩蓋修復其餘 40 個任務的成本。

4. 速度、冗長度與整合摩擦會影響成本

每秒輸出 Token 數僅衡量生成階段。它們無法捕捉首個答案的反應時間、內部推理、工具執行、速率限制延遲或重複呼叫。冗長模型也可能將低輸出價格轉化為更高的最終帳單。

最後，類似的 API 仍有各自的模型特定規則。推理欄位、不支援的採樣參數、函式回應 ID 以及模型名稱的大小寫，都可能破壞原本可移植的工作流程。這就是為什麼每個條目都包含了精確的 GPT Proto 模型字串。

1. GPT-6 Luna — 最適合輕量級、高頻率的 Agent 步驟

GPT-6 Luna 是我們針對頻繁且範圍明確的請求所推薦的首選：例如分類工單、提取產品屬性、選擇工作流程或總結工具執行結果。GPT Proto 將其定價列為 每百萬輸入 Token 0.08 美元，每百萬輸出 Token 0.40 美元，這是此清單中最低的輸入與輸出費率。

該模型支援文字與圖像輸入、結構化輸出，並提供 105 萬 Token 的上下文視窗。可調整的推理能力讓開發者能測試任務所需的運算量。簡單的路由決策通常不需要與模糊的程式編寫問題相同的配置。

在將其用作工具呼叫控制器之前，有一個相容性細節需要確認。OpenAI 透過 Responses 記錄了啟用推理功能的函式呼叫；Chat Completions 僅在 reasoning_effort: "none" 時支援函式呼叫。請使用 GPT Proto 模型頁面上的 試用此模型 快速入門來驗證路由與支援的欄位。

Luna 的角色是作為低成本的第一層處理。它可以處理常規步驟，而當出現明確的失敗或複雜性訊號時，再由能力更強的模型接手。低 Token 費率只有在這些初步步驟保持準確時才有幫助。若要進一步了解此權衡，請比較 GPT-6 Luna 與 GPT-6 Sol 在程式編寫與 Agent 工作負載上的表現。

選擇 GPT-6 Luna 的時機：

• 工作流程包含大量的分類、提取或總結任務；

• 每個步驟都有明確的架構，且結果可供您的應用程式進行檢查；

• 您希望為現有的 OpenAI 相容應用程式建立一個低成本的基準；

• 困難的案例可以被升級處理，而非無限期重試。

注意事項： 端點特定的工具支援以及重複的驗證失敗。請將 Luna 用於範圍明確的工作；針對複雜的規劃與恢復任務，請評估更強大的模型。

2. Claude Haiku 5.5 — 低成本支援與 Claude Agent 步驟的最佳選擇

Claude Haiku 5.5 是處理重複性支援工作、對話摘要、分類及小型程式編寫任務的強大替代方案。它於 2026 年 10 月 7 日發布，為 Haiku 層級帶來了可調整的運算強度，並可在同時使用較大型 Claude 模型的流程中，作為成本較低的執行者。

GPT Proto 提供的 Haiku 5.5 價格比 官方費率低 10%。對於輸入 Token 數不超過 100K 的請求，這意味著 每百萬輸入 Token 為 0.09 美元，每百萬輸出 Token 為 0.45 美元。當輸入 Token 超過 100K 時，相應費率為 輸入 0.45 美元，輸出 2.25 美元.

該門檻比最大上下文視窗更為重要。Haiku 支援 1M 上下文，但不斷增長的對話在達到該容量之前，很可能就會跨入較高的價格區間。此門檻適用於每個請求的輸入，包括保留的對話內容和工具執行結果。

自適應思考（Adaptive thinking）預設為啟用，透過「運算強度」（effort）來控制模型在任務上投入的資源。建議從精簡的請求開始，在增加強度之前先比較完成品質、延遲和計費 Token 數量。

選擇 Claude Haiku 5.5 的時機：

• 代理程式需要處理重複性的支援問題或工單分類；

• 摘要與壓縮對話狀態是工作流程中的常見步驟；

• 基於 Claude 的程式編寫工作流程需要針對特定子任務的協助；

• 大多數請求都保持在較低的提示長度價格區間內。

注意事項： 請求若超過 100K 輸入 Token。請保持可重複使用的狀態簡潔，並檢查完整請求的成本，特別是在長對話中。

3. GLM-5.3 Flash — 低成本視覺與工具驅動型代理程式的最佳選擇

GLM-5.3 Flash 仍然是結合視覺證據與外部工具的工作流程中最實用的候選模型之一。其公開的 GPT Proto 費率為 每百萬輸入 Token 0.15 美元，每百萬輸出 Token 0.50 美元.

Z.ai 記錄了其對文字、圖像、影片和檔案的原生輸入支援，並具備 1M Token 的上下文視窗。函數呼叫、結構化 JSON、快取、串流傳輸以及串流工具參數，使其非常適合需要檢查文件或介面並執行後續步驟的代理程式。

一個實際的例子是視覺 QA 工作流程：檢查螢幕截圖、識別佈局問題、提出程式碼變更，並透過應用程式的工具審查渲染結果。模型提供決策與參數；周邊的代理程式則提供瀏覽器、程式碼執行與驗證功能。

主要的權衡在於其「持續推理」特性。這有助於處理模糊的決策，但對於基礎的標記或提取任務會產生額外開銷。GPT-6 Luna 和 Haiku 5.5 在此清單中對於短請求的 Token 費率較低。

選擇 GLM-5.3 Flash 的時機：

• 螢幕截圖、圖表、文件或影片證據會影響下一個動作；

• 工作流程需要工具呼叫與結構化結果；

• 視覺化程式編寫或迭代介面檢查是任務的一部分；

• 開放權重（Open weights）與託管 API 存取同樣重要。

注意事項： 推理與輸出量。請設定生成 Token 與工作流程步驟的限制；「Flash」名稱並不代表端到端的延遲表現。

4. DeepSeek Flash — 最適合快取、輸入量大的開源權重代理

DeepSeek Flash 是 DeepSeek V4.1 Flash 的路由名稱。請在請求中使用 deepseek-flash，而不是將版本名稱視為獨立的 API 層級。GPT Proto 顯示的輸入/輸出費率為 每百萬 token $0.30 / $1.20.

該模型結合了文字與圖像輸入、高達 1M token 的上下文視窗、工具呼叫、JSON 輸出、串流傳輸，以及思考或非思考模式運作。這種組合非常適合那些在生成相對較小的結果之前，需要反覆讀取儲存庫檔案、指令、文件或工具歷史記錄的代理。

快取是將其納入輸入量大之候選名單的原因。穩定的指令和工具定義可以在多次呼叫中重複使用，但節省的費用取決於實際的快取命中率。對於每次輪次都會大幅變動的長提示詞，應進行不同的預算規劃。

狀態處理也需要注意。在原生思考模式的工具工作流程中，推理狀態可能需要在呼叫之間保留。在遷移多輪迴圈之前，請先驗證所選的 GPT Proto 端點如何呈現該狀態。第一次回應有效並不代表整個對話都能保持相容。

選擇 DeepSeek Flash 的時機：

• 重複的指令或參考資料使快取變得實用；

• 儲存庫檢查或文件分析佔據了大部分輸入量；

• 工作流程受益於在思考與非思考模式之間切換；

• 同一任務中需要圖像證據搭配文字。

注意事項： 快取未命中、冗長的輸出以及遺失工具呼叫狀態。請衡量完整的迴圈，而不是僅根據快取率來估算節省的費用。

5. MiniMax M3 — 最適合長文件與研究型 Agent

MiniMax M3 當 Agent 需要處理大量文件或長期的工作紀錄時，非常值得考慮。在 GPT Proto 上，模型字串為 MiniMax-M3，顯示費率為 每百萬輸入 Token 0.48 美元，每百萬輸出 Token 0.96 美元。

該模型支援工具使用、長上下文編碼及 Agent 工作流程，上下文視窗約為 100 萬個 Token。它在此處的角色是處理文件密集型工作：比較政策、審閱支援歷史、追蹤參考檔案間的關聯，或保留中間研究結果。

價格上的權衡需要明確說明。MiniMax 目前針對 512K 輸入 Token 以內的提示詞，直接費率為每百萬 Token 輸入 0.30 美元、輸出 1.20 美元。在這些費率下，GPT Proto 的輸出價格較低，而直接管道的輸入價格較低。這兩個標價都無法決定哪種工作負載的帳單更便宜。

大型上下文視窗並不能取代檢索或驗證。將整個存檔餵給 Agent 可能會增加費用，卻無法幫助它找到正確的證據。

選擇 MiniMax M3 的時機：

• 任務依賴於多份文件或長期的工作紀錄；

• Agent 需要在多個步驟中保留中間發現的結果；

• 生成的報告或解釋使得輸出成本變得重要；

• 您希望透過託管存取來評估開放權重模型。

注意： 昂貴的累積輸入成本以及在長文件中遺漏證據的可能性。請測試跨文件推理並確認所選管道的輸入能力。

6. Gemini 3.8 Flash — 最適合音訊、視訊與混合媒體 Agent

Gemini 3.8 Flash 當任務包含音訊、視訊、圖像或 PDF 以及文字時，它便能發揮價值。GPT Proto 針對 gemini-3.8-flash 管道顯示的費率為 每百萬輸入 Token 0.90 美元，每百萬輸出 Token 4.50 美元。

該模型擁有約 100 萬個 Token 的輸入視窗、可調整的思考能力、函式呼叫及結構化輸出。對於需要審閱客戶影片、閱讀支援文件並準備後續應用操作的工作流程來說，它是個實用的選擇。

它的價值來自於這些輸入所能取代的工作。一個能理解多種媒體類型的 Agent 可能減少對獨立預處理階段的需求。在假設上游模型的完整工具生態系統可用之前，請先驗證 GPT Proto 管道上支援的檔案格式與請求對應。

這並非此處 Token 價格最低的選項。Google 在 2026 年 12 月 31 日前的直接介紹費率為每百萬 Token 輸入 0.75 美元、輸出 3.75 美元，低於 GPT Proto 目前顯示的費率。使用此管道的原因是能夠透過單一帳戶與餘額同時存取其他模型。

選擇 Gemini 3.8 Flash 的時機：

• 音訊或視訊是任務的核心；

• 同一個工作流程必須檢查多種媒體類型；

• 多模態模型可以簡化獨立的預處理階段；

• 可調整的推理能力在常規與困難請求中都很有用。

注意： 輸出成本與供應商特定的工具支援。請對完成的工作流程進行基準測試，而不是僅依賴生成速度數據。

7. Grok 4.7 — 最適合處理困難編碼與多步驟升級任務

Grok 4.7 是此精選清單中的升級首選。它已在 GPT Proto 上架，價格為 每百萬輸入 token 1.20 美元，每百萬輸出 token 3.60 美元，與 Grok 4.6 的顯示費率一致。

該模型支援文字與圖像輸入、函數呼叫與結構化輸出，並提供 500K token 的上下文視窗。其四種推理等級（低、中、高與極高）讓開發者能測試困難任務所需的運算強度。

當代理程式必須診斷失敗的程式碼變更、協調多個相依工具的結果，或在驗證失敗後重新規劃時，此模型便顯得至關重要。低成本模型可處理常規準備工作，而由 Grok 處理困難步驟。

其限制更多是經濟層面而非技術層面。將每次提取或路由請求發送至升級模型，會在真正需要其強大推理能力之前就增加成本。即便新版本採用相同 token 費率，也不代表最終任務帳單會更低；若現有應用程式已依賴 Grok 4.6，請務必比較兩個版本。

選擇 Grok 4.7 的時機：

• 編碼或研究任務需要多個相依決策時；

• 低成本路徑反覆無法通過定義的驗收檢查時；

• 需要同時考量圖像證據與推理時；

• 成功復原的價值高於額外的模型費用時。

注意事項： 留意昂貴的重試與過度的推理消耗。請將其保持在定義好的升級路徑上，並在任務需要其他模型無法提供的權限或缺失輸入時停止。

為何低廉的 Token 價格仍可能導致昂貴的代理程式任務

低 token 費率有助於重複性的分類或重寫任務，但對於需要選擇工具、解釋結果並從錯誤中復原的代理程式而言，其參考價值較低。

模型可能會產生廉價的回應，卻反覆選擇錯誤的函數或遺漏必要的參數。每次修復都會增加額外的模型呼叫、更長的對話歷史，以及潛在的額外工具操作。在代理程式產出可接受的結果之前，任務成本可能已變得相當昂貴。

在將工作流程控制權交給模型之前，請檢查它是否能：

• 區分相似的工具；

• 產生同時滿足架構與業務規則的參數；

• 在工具結果或可復原錯誤後繼續執行；

• 識別出沒有合適工具可用的情況。

請從您的驗收門檻開始，然後比較所有合格模型的總成本。單純的提取步驟與多工具控制器並不需要使用同一個模型。

實用的低成本模型路由策略

您可以在同一個代理（Agent）內為不同的步驟分配不同的模型。常規準備工作使用低成本路徑；困難的推理任務則使用升級路徑。應用程式會根據任務類型、驗證結果和支出限額來做出選擇。

以上僅為評估的起點。驗證失敗可能源於提示詞（Prompt）、工具定義、應用程式或模型本身；在支付更高昂的路徑費用前，請先檢查失敗原因。

透過以下五項規則控制代理的成本：

1. 僅在通過任務驗收檢查後，才使用低成本模型。

2. 在執行前驗證工具參數。

3. 限制每次執行的模型呼叫次數、輸出 Token 數量、經過時間與支出。

4. 定義恢復或升級規則，而非無限期地重試相同請求。

5. 當操作超出代理權限時，暫停並請求批准。

GPT Proto 提供單一 API 金鑰與共享餘額，讓您存取支援的模型。應用程式或框架仍需負責管理路由、狀態、工具執行與停止條件。請參閱 AI 代理的 LLM API 頁面，以比較模型存取權限並估算現有工作流程的成本。對於有邊界的路由與分類步驟，請在將決策指派給更昂貴的代理模型前，先比較 Jev 與通用 LLM。

使用 GPT Proto 進行最小化工具呼叫請求

此範例使用 glm-5.3-flash 並定義 get_order_status 作為應用程式可執行的工具。模型回應可能會請求該函式；請求本身並不會讓模型存取您的訂單系統。

開啟 GLM-5.3 Flash 模型頁面 並選擇 試用此模型 進行當前的快速入門，然後將您的伺服器端 API 金鑰提供給該範例。

curl https://gptproto.com/v1/chat/completions \
  -H "Authorization: Bearer $GPTPROTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3-flash",
    "messages": [
      {
        "role": "user",
        "content": "Where is order A-1042?"
      }
    ],
    "tools": [
      {
        "type": "function",
        "function": {
          "name": "get_order_status",
          "description": "Return the current status of one order.",
          "parameters": {
            "type": "object",
            "properties": {
              "order_id": {
                "type": "string",
                "description": "The order identifier."
              }
            },
            "required": ["order_id"],
            "additionalProperties": false
          }
        }
      }
    ],
    "tool_choice": "auto"
  }'

若要取得與 OpenAI 相容的聊天完成回應，請檢查 choices[0].message.tool_calls。對於每個回傳的呼叫：

1. 檢查該函式對於此使用者和任務是否被允許；

2. 解析並驗證參數；

3. 在您的應用程式中執行該函式；

4. 在工具訊息中回傳其結果，並附上對應的 tool_call_id；

5. 請求下一個模型回應，並保留任何必要的推理狀態。

切換模型需要進行相容性檢查。GPT-6 Luna 的上游聊天完成工具呼叫需要 reasoning_effort: "none"；啟用推理的函式呼叫會使用回應。其他路徑可能具有不同的狀態或參數要求。請檢查每個模型的快速入門，不要假設相同的負載在任何地方都適用。

這是工具迴圈中的第一個請求。您的應用程式必須提供工具執行結果及後續訊息。

如何為您的 Agent 測試經濟實惠的 LLM API

請使用您應用程式中的代表性任務。通用基準測試有助於建立初步名單，但模型還必須能與您的工具名稱、資料及驗收規則相容。

請從以下四個類別開始：

1. 工具選擇： 提供類似的功能，並檢查模型是否選擇了正確的工具。

2. 多重工具： 提供一個需要兩個獨立結果的請求。在路由支援的情況下測試平行呼叫，或透過連續的對話輪次完成兩者。

3. 無工具請求： 包含一些不應呼叫任何可用工具的問題。

4. 恢復能力： 回傳一個真實的工具錯誤，並檢查模型是否能在不陷入無限迴圈的情況下修正其下一步動作。

請保持指令、工具定義、輸入資料和驗收標準的一致性。為每個路由使用支援的設定，並記錄其端點和推理配置；相同的參數名稱在不同供應商之間並不總是通用的。

每個類別至少執行五次。若有七個模型、四個類別，且每個執行五次，初步比較將包含 140 次執行。這是一個試點評估設計，並非聲稱這些執行已經完成，也不代表五次重複就能建立生產環境的可靠性。

記錄：

• 已驗收的任務完成情況；

• 正確的工具選擇與有效的參數；

• 不必要的呼叫與恢復失敗；

• 模型輪次與總工作流程時間；

• 未快取的輸入、快取讀取或寫入，以及計費的輸出或推理 Token；

• 適用的提示詞長度層級與其他計費項目；

• 總 API 成本，包含重試與失敗的嘗試。

計算：

單次已驗收任務成本 = 評估期間的總 API 花費 / 已驗收的完成任務數量

請將失敗案例分開報告，特別是當模型無法完成任何任務時。僅在檢查過品質門檻後再比較成本；然後針對生產環境中重要的失敗案例擴大評估範圍。

Agent 建構者如何看待延遲

社群報告提供了定價頁面無法呈現的背景資訊。在一次 AI Agents 社群討論中，據報導一個簡單的檢索系統能在不到一秒內回答，而更具 Agent 特性的版本則需要近三秒。對於客戶支援而言，這種差異被描述為無法接受的致命傷。

其他參與者則不同意這種普遍的結論。他們指出，研究與內部分析的使用者可能願意接受更長的等待時間，前提是工具的使用能實質提升回答品質。重要的教訓並非「三秒總是太慢」，而是同一個模型對於某個 Agent 來說可能很划算，但對另一個 Agent 卻不適用，因為延遲、品質與失敗成本的價值各不相同。

請將社群評論視為經驗報告，而非基準測試結果。利用這些評論來識別您自身評估中的失敗案例。

對於您自己的 Agent，請測量「獲得第一個有用回答的時間」與「完成任務的時間」，並同時考量生成速度。模型可能啟動很快，但需要額外的幾個輪次才能完成任務。因此，互動式支援與背景研究可能需要不同的延遲目標，即使它們使用相同的 API 路由。

最終建議

對於頻繁且有邊界的步驟，請從 GPT-6 Luna 開始。它在此短名單中擁有最低的基礎輸入與輸出費率，且適合您的應用程式可驗證的請求。

選擇 Claude Haiku 5.5 進行重複性支援與 Claude 編碼子任務，同時留意 100K 輸入的定價門檻。當需要截圖、文件或其他視覺證據來引導下一個工具操作時，請使用 GLM-5.3 Flash。

評估 DeepSeek Flash 以處理重複且高快取需求的輸入，並選擇 MiniMax M3 處理長文件對話。當音訊或影片理解能減少獨立處理階段的數量時，請選擇 Gemini 3.8 Flash。將 Grok 4.7 保留給困難的編碼與多步驟恢復任務。

最終選擇應是能在最低測量工作流程成本下達到您驗收目標的模型。請使用 Token 費率來建立短名單，然後將失敗的執行、推理、工具使用與重試次數納入決策考量。

準備好連接您的短名單了嗎？探索 GPT Proto 的 AI 代理 LLM API，以獲取支援的模型、工作負載估算，並透過單一金鑰與共享餘額進行存取。使用各模型頁面上的 試用此模型 面板進行快速入門，並在擴展規模前查看 GPT Proto 定價。