「用 GPT-4o 還是 Claude？」是 AI Agent 開發者最常問的問題之一。但這個問題本身就有問題：它假設有一個「最好的 LLM」，而實際上，最好的 LLM 取決於你的 Agent 在做什麼、資金量多少、需要多快的響應速度、以及你願意接受多高的推理成本。
選 LLM 不是在選「最強的」，而是在為你的具體任務找到「成本 × 速度 × 品質」三角最佳平衡點。這篇文章提供一個可操作的框架，讓你在選型時有具體標準，而不是靠感覺猜或跟風用。
評估任何 LLM 是否適合你的 Agent，需要在四個維度上同時評分：
維度一：推理能力（Reasoning Quality）。Agent 的任務複雜嗎？需要多步驟的計劃、條件判斷、或者在模糊信息下做決策嗎？這類任務需要高推理能力的 LLM（Claude Opus、GPT-4o、Gemini 1.5 Pro）。如果你的 Agent 只是做「分類外部數據然後觸發固定動作」，低推理能力的小模型（GPT-4o mini、Claude Haiku）已經夠用，且成本低 10-20 倍。
維度二：Context Window 大小。Agent 每個推理循環需要裝多少信息進 Context？一個 DeFi 監控 Agent 可能需要同時裝下 20 個協議的當前狀態、過去 24 小時的 PnL 歷史、和完整的策略說明；這輕鬆超過 100K Token。如果 Context 不夠，你需要在每個推理周期截斷信息，可能導致 Agent 基於不完整信息做決策。目前 Context Window 最大的主流模型：Gemini 1.5 Pro（100 萬 Token）、GPT-4o（128K Token）、Claude Opus（200K Token）。
維度三：響應速度（Latency）。你的 Agent 是在時間敏感的場景裡運作嗎？一個套利 Agent 可能需要在 100 毫秒內完成推理並觸發交易；一個每天執行一次的利率優化 Agent 可以等待 30 秒的推理時間。更快的響應通常意味著較小的模型或較短的 Context。大型前沿模型（Claude Opus、GPT-4o）的推理延遲通常在 10-30 秒；小型模型（Haiku、GPT-4o mini）可以在 1-3 秒完成。
維度四：工具調用可靠性（Function Calling Reliability）。Agent 依賴 LLM 正確格式化工具調用的能力。一個 LLM 可能推理能力很強，但工具調用格式不穩定——頻繁輸出格式錯誤、忘記必填參數、或者在不應該調用工具時調用。這個維度需要在你的具體工具集和任務類型上實際測試，不能只看 Benchmark。建議：在部署 Agent 前，用你的實際工具集跑 50-100 次推理循環，統計工具調用格式錯誤率（理想目標：< 2%）。
Context Window 大小和每次推理的成本直接相關，這是 Agent 選型裡最容易被低估的成本因素。
假設你的 Agent 每次推理需要一個 50K Token 的 Context，每天執行 48 次推理循環（每 30 分鐘一次）：
用 Claude Opus 4（輸入 $15/百萬 Token）：50,000 × $15/1,000,000 × 48 = $36/天 = $1,080/月。
用 Claude Haiku（輸入 $0.25/百萬 Token）：50,000 × $0.25/1,000,000 × 48 = $0.60/天 = $18/月。
如果你的任務 Haiku 可以完成，每月節省 $1,062。但如果 Haiku 的推理品質不夠，導致每週執行錯誤操作一次，損失遠超這個成本差。
這個計算說明了一個反直覺的原則：為不需要高推理能力的任務用貴模型，是雙重浪費——你不只多付了 API 費用，還讓系統的響應速度變慢（大模型延遲更高）。正確做法：把 Agent 的不同子任務按推理複雜度分層，高複雜度任務（策略決策）用前沿模型，低複雜度任務（數據格式化、分類、摘要）用小模型。
一個實際的混合架構：Orchestrator 層用 Claude Opus 做策略推理，Data Collection Sub-agent 用 Claude Haiku 做數據整理和格式化。這讓整個系統的平均 Token 成本下降 60-80%，同時保留關鍵決策的推理品質。
在 LLM 選型裡，速度、品質、成本三者幾乎不可能同時最優。你需要明確哪個是你的 Agent 的「不可妥協」維度：
如果不可妥協是速度（毫秒級響應的套利 Agent、實時決策系統）：選最小的模型，接受推理品質的損失。優化方向：縮短 Context（只保留當前任務最必要的信息）、把複雜推理在 Agent 啟動時預計算並緩存結果、使用流式輸出（Streaming）讓 Agent 不需要等整個響應完成才執行。
如果不可妥協是品質（高資金量的投資決策 Agent、需要複雜條件判斷的治理 Agent）：選前沿模型，接受較高成本和較慢速度。優化方向：用 CoT（Chain of Thought）讓模型在給出行動建議前先列出推理步驟、讓模型在高不確定性場景下主動請求人工確認（而不是強行做決策）、保留完整 Context（不截斷歷史）。
如果不可妥協是成本（低收益、高頻執行的監控 Agent）：選小模型，把複雜推理任務分解成多個簡單的子任務分別處理。優化方向：用 Prompt 工程讓小模型的輸出格式更可預測（減少解析錯誤重試的成本）、用緩存減少重複的 LLM 調用（Semantic Cache）、限制每日最大推理次數（熔斷）。
大多數 Agent 的現實情況是：沒有任何一個維度是「無限預算」的，真正的選型是在三個維度上找到「對你的業務可接受的下限」，然後在這個下限之上選成本最低的模型。
按 Agent 的核心任務類型，給出具體的 LLM 選配建議：
DeFi 利率優化 Agent（每日一次，利率比較 + 移倉）：Orchestrator 用 Claude Sonnet 或 GPT-4o mini，Sub-agent 用 Claude Haiku。推理複雜度：中等（比較利率差、計算 Gas 成本回收期）。Context 需求：20-50K Token。建議不要用前沿模型——任務邏輯清晰，小模型可以可靠完成，沒必要為簡單的數值比較支付前沿模型費用。
鏈上治理提案分析 Agent（每週幾次，理解複雜提案並生成摘要和建議）：需要前沿模型（Claude Opus 或 GPT-4o）。理由：治理提案通常包含複雜的法律/技術語言，需要高推理能力才能正確理解隱含含義和風險。Context 需求可能高達 100K+ Token（完整的提案文本 + 歷史）。
套利執行 Agent（毫秒級響應，價格差出現即觸發）：LLM 不應該在執行路徑上。套利執行通常是純代碼邏輯，不需要 LLM 推理——只需要固定的規則引擎判斷「當前利差 > 閾值且 Gas 費 < 預算則執行」。如果你在套利執行路徑上放 LLM，延遲就已經讓套利機會消失了。LLM 在套利 Agent 裡適合的位置：離線的策略優化（每天分析昨日數據，更新套利策略參數），不是在線的執行決策。
社交監控 + 鏈上響應 Agent（監控 Twitter/Discord 情緒，在情緒轉變時調整倉位）：這是混合任務——情緒分析可以用小模型（GPT-4o mini），但倉位調整的決策應該用中型模型（Claude Sonnet）+人工確認門。把情緒分析和倉位決策分成兩個不同的推理步驟，使用不同的模型。
LLM 選型的錯誤是一種很隱性的成本——它不像 Bug 一樣立刻崩潰，而是讓你每個月多付了幾百美元的不必要 API 費用，或者讓你的 Agent 在本可以用小模型解決的任務上，因為沒有對比測試就默認用了前沿模型。
一個可操作的選型流程：第一，列出你的 Agent 的所有推理步驟，對每個步驟的複雜度評分（1-5 分）。第二，對複雜度 3 分以上的步驟，測試前沿模型；對 1-2 分的步驟，先測試小模型能不能完成，能完成就用小模型。第三，測試時不只看輸出品質，還看工具調用格式錯誤率——格式錯誤率高的模型即使推理準確也要付重試成本。第四，部署後監控每月的 LLM API 費用趨勢，如果費用增長快於業務增長，考慮把增量的推理任務切換到小模型。
最終，LLM 不是你 Agent 的靈魂，而是它的引擎。你需要的引擎取決於你的車要開多快、載多重、跑多遠——不是越貴越好，而是最合適的。