AI評估平臺Braintrust近期發佈了一項大規模實證研究，從Hugging Face抓取了1781條智能體在生產環境中的完整運行軌跡，覆蓋六款主流模型在六大類任務中的表現，並使用GPT-4o進行逐條評分。研究結果挑戰了當前業界對模型能力的過度聚焦，揭示出智能體框架（harness）才是決定任務成功率的關鍵變量。

數據顯示，在保持底層模型不變的情況下，僅更換包裹模型的智能體框架，成功率可以從12%直接躍升至92%，波動幅度超過80個百分點。迴歸分析進一步量化了這一影響：在控制基準測試和模型變量後，智能體框架能解釋約5.3%的成功率差異，而模型僅能解釋0.7%。這意味著，切換智能體框架對成功率的影響力是更換模型的7倍以上。更值得關注的是，框架切換幾乎不帶來額外成本——同一任務中不同框架的Token消耗基本相當。

研究測試了五種架構迥異的智能體框架。claude_code是Anthropic的原生Agent循環，允許模型以類XML格式自主管理工具調用和上下文。smolagents_code則讓模型通過編寫Python代碼來串聯操作。tool_calling採用標準的結構化JSON函數調用，一次執行一個工具。tool_calling_with_shortlisting在前者基礎上每輪預篩選可用工具。openai_solo則是最薄的OpenAI封裝。同模型、同任務下的對比結果令人震驚。在SWE-bench編程任務中，Claude配合claude_code成功率達到100%，換成tool_calling後驟降至14%。在AppWorld多應用編排任務中，Kimi配合smolagents_code達到92%，tool_calling下僅12%。GPT-4.1在電信客服任務中，smolagents_code下為51%，claude_code下僅剩18%。這些斷崖式的成功率差異，均源於框架設計中看似微小的決策——是讓模型自主管理上下文，還是用固定模板約束每一步；是允許模型寫代碼串聯工具調用，還是隻能逐次調用。

值得注意的是，tool_calling_with_shortlisting試圖通過每輪縮小可用工具列表來提高效率，但數據表明這一設計反而拖累了表現。縮小選項可能切掉了有用工具，也可能引入了路由錯誤，說明“更精密的控制”並不自動等同於“更好的結果”。

在成本端，開源模型展現出顯著優勢。在SWE-bench編程基準上，開源模型與頂尖閉源模型處於同一成功率檔位：DeepSeek V3.2達到96%，Kimi K2.5達到94%，Claude Opus 4.5為100%，GPT-5.2為93%，Gemini 3 Pro為87%。但真正的分水嶺在於每次成功任務的成本。Braintrust按LiteLLM的實際Token費率定價，並用成功率折算每次成功成本。claude_code配合Kimi K2.5每次成功僅花費0.73美元，配合DeepSeek V3.2為1.27美元。閉源的Claude Opus需4.28美元，Gemini 3 Pro需4.97美元。在AppWorld任務上，差距進一步拉大：Kimi配合smolagents_code每次成功僅0.40美元，Claude配合claude_code高達84.33美元，相差超過200倍。開源模型還具備自託管優勢，無需每次調用付費，也免受API漲價風險，為大規模部署提供了結構性的成本護城河。

研究還揭示了一個關鍵誤區：Token單價最低不等於效率最高。GPT-4.1的Token賬單在紙面上比其他模型便宜10到100倍，但其在SWE-bench和AppWorld等硬核任務上的失敗率高達53%至90%。它之所以“便宜”，是因為“更快地失敗了”。衡量效率的正確維度是每次成功成本，即單次任務成本除以成功率。這一指標完全重塑了配置排名。在編程類任務上，開源模型走到了成本效率的最前沿；在對話客服類任務上，GPT-4.1以每次成功0.02至0.03美元的成本大幅領先Claude的1.95美元。這意味著不存在一個通吃的“最便宜模型”，不同任務家族對應完全不同的成本最優解。

六個基準測試產生了四個不同的冠軍。Claude贏下SWE-bench、BrowseComp+和TAU2零售/電信客服。Gemini在TAU2航空客服上以100%成功率奪冠。DeepSeek和Kimi在AppWorld多應用編排任務上大幅領先。甚至在同一智能體框架內，不同模型的表現也差距懸殊。AppWorld任務中，Claude在自家原生的claude_code下僅有26%成功率，遠低於同框架下DeepSeek的80%和Kimi的78%。模型與任務的匹配度、以及與框架之間的協同效應，遠比模型參數的絕對規模更能預測最終表現。此外，高平均成功率可能掩蓋局部塌方，某些配置總體得分不錯，但在特定任務類型上完全崩盤。

Braintrust還發現，Agent失敗時的行為在編碼任務和對話任務上方向完全相反。在SWE-bench和AppWorld等硬核編程任務中，失敗伴隨著“顛簸”——Agent比成功的同行發出更多LLM調用、消耗更多Token、運行更長時間，BrowseComp+的失敗運行消耗Token是成功運行的2.3倍。而在TAU2客服對話類任務中，失敗的Agent調用更少、Token更少、結束更快，直接自信地給出錯誤答案後收工。這兩種截然相反的失敗模式要求生產環境的監控策略必須差異化：編碼任務需要Token用量的上限告警以止損，對話任務則需要下限告警以捕捉“流暢的錯誤交付”。

這組數據改寫了AI創業公司的競爭規則。六個主流模型在編程任務上的成功率差距已收窄至個位數百分點，模型層商品化速度超出預期。繼續圍繞“接入哪個最新模型”構築商業故事，護城河正在快速蒸發。真正拉開差距的，是為每類任務匹配最優智能體框架、按每次成功成本衡量效率、以及建立差異化的失敗監控體系。這三項能力的核心指向同一組關鍵詞：推理成本的精細管理和部署效率的系統優化。對於ToB的AI創業公司，產品定義的重心需要從“我們接入了哪個模型”轉向“我們在什麼任務場景、用什麼成本結構、以什麼成功率交付”。敘事不再是比模型，而是比成本、比效率、比工程。