OpenAI栽了：128個工具是它邁不過的坎

給大模型塞150個工具，它會變成瑞士軍刀還是選擇困難癥？

這個假設每個做AI Agent的人都想過，但很少有人真的測過。直覺告訴我們：工具越多，模型越懵。GitHub、Kubernetes、Slack、Jira全塞進上下文窗口，模型得讀完所有定義、理解差異、再選對工具——信號噪音比直線下降。

但直覺不是數據。Boundary團隊做了件狠事：開源了一套測試框架，把150個真實工具定義砸向六個主流模型，看它們什么時候崩潰。

測試設計：150個工具，五檔壓力測試

工具庫來自16個真實服務：GitHub、GitLab、Jira、Confluence、Kubernetes、AWS、Datadog、Slack、PagerDuty、Okta、Snyk、Grafana、Terraform Cloud、Docker、Linear、Notion。全是生產環境MCP（模型上下文協議）的真實Schema，只是做了無操作處理方便跑分。

六個模型分屬三家：OpenAI的GPT-4o和GPT-5.4 Mini、Anthropic的Claude Sonnet 4.6和Claude Haiku 4.0、xAI的Grok 4和Grok 4.1 Fast Reasoning。

每輪測試給模型60個提示，分兩種風格：直接提示點名服務（如"列出所有Terraform Cloud工作區"），模糊提示不點名（如"給跟蹤工單加個'已解決'評論"）。工具集規模從25個逐級加碼到50、75、100、150個，每次隨機抽取但確保正確答案一定在池子里。

核心問題只有一個：模型能不能選對工具？

GPT-5.4 Mini：優等生的128工具懸崖

測試結果里最反直覺的是GPT-5.4 Mini。25到50工具區間，準確率85%；模糊提示下92%的命中率，響應不到1秒，單次調用成本0.002美元。這組數據讓它成為中小工具集場景的最佳性價比選擇。

然后它撞墻了。

和GPT-4o一樣，GPT-5.4 Mini在128個工具處直接失效。不是逐漸變差，是徹底停擺。OpenAI API對這個參數有硬限制：超過128個工具的請求直接拒收。如果你的Agent接了足夠多的MCP服務器，工具總數突破128，整個OpenAI模型家族集體出局。

這不是性能曲線，這是產品邊界。做企業級Agent的工程師得算清楚：GitHub工具20個、Jira工具15個、Kubernetes工具30個、再加上Slack和PagerDuty——很容易過線。

Grok 4.1：唯一跑完150工具全程的模型

xAI的Grok 4.1 Fast Reasoning是測試里唯一完成全部五檔規模的模型。25工具時準確率86.7%，150工具時降到76.7%，但全程沒有斷裂。這條下滑曲線反而成了最穩定的輸出。

Grok 4（非Fast Reasoning版本）表現稍遜，同樣完成了150工具測試，但交叉服務錯誤從25工具階段就開始出現。所謂交叉服務錯誤，是指模型從完全錯誤的服務里挑工具——比如該找GitHub卻去了GitLab。

這種錯誤比"選錯工具"更危險。后者可能是參數填錯，前者是方向性迷失。想象一下：用戶讓Agent"關閉那個告警"，模型從Slack里找了個發消息的工具，而不是去PagerDuty真正處理告警。

Claude家族：貴的不一定好

Anthropic的測試結果堪稱尷尬。Claude Sonnet 4.6是六款模型里最貴的，單次調用0.028美元，卻在25工具階段就墊底，且全程沒有翻身。Claude Haiku 4.0價格只有它的三分之一，卻在每個規模檔位都擊敗自家大哥。

Haiku的交叉服務錯誤控制一度是全場最佳：75工具之前零失誤。但150工具階段突然惡化到4次錯誤，成為該規模下最差表現。

這個跳躍式惡化暗示了某種閾值效應——工具描述的信息密度超過某個臨界點，輕量級模型的過濾機制會突然失效。

模糊提示：GPT-5.4 Mini的隱藏強項

測試里有個細分數據值得玩味。在模糊提示場景下，GPT-5.4 Mini直到100工具規模仍保持92%準確率。這意味著當用戶不說人話、不指名服務時，這個"小"模型的語義推斷能力反而壓過一眾大模型。

產品經理視角看，這觸及Agent設計的核心矛盾：用戶自然語言越模糊，系統需要承擔的推理負擔越重。但大多數場景下，用戶確實不會精確描述"去GitHub的Issues里找標簽為P0的Bug"——他們說"看看有什么急事要處理"。

GPT-5.4 Mini在這個維度的優勢，解釋了為什么它在中小規模工具集里被稱為"最佳整體表現"。直到128工具墻把它攔在外面。

生產環境的真實困境

測試用的工具定義是合成數據，但Schema完全鏡像生產環境。這意味著現實中的Agent開發者面臨的困境只多不少：真實工具的參數更復雜、描述更長、版本迭代更頻繁。

一個典型企業的MCP配置可能包括：GitHub（20+工具）、Jira（15+工具）、Kubernetes（30+工具）、Datadog（10+工具）、Slack（10+工具）、PagerDuty（10+工具）。還沒算AWS和Terraform，已經逼近或超過128工具線。

OpenAI用戶現在的選擇很擰巴：要么精簡工具集，要么拆分Agent，要么換供應商。后兩種方案都意味著架構復雜度陡增。

Boundary團隊開源這個框架的意圖很明顯：工具膨脹是Agent的慢性病，需要持續監測而非一次性調優。他們建議把工具選擇準確率作為核心指標納入CI/CD流程，就像監控API延遲一樣。

測試數據還暴露了一個未被充分討論的問題：模型廠商的API限制正在成為架構天花板。OpenAI的128工具限制是硬性產品決策，不是技術必然。Grok證明150工具可以跑通，雖然準確率下滑，但系統不崩。

這種差異會重塑企業的模型選型邏輯。以前比的是推理質量、價格、延遲；現在得加一項：工具容量上限。

當你的Agent連接第129個工具時，你會選擇拆分架構，還是換一家API？