早在 2024 年 11 月,Anthropic 的 Model Context Protocol (MCP)發佈,通過這個協議,大模型就能比較容易地呼叫工具。OpenAI 在 2025 年 3 月曾公開表示要在自家產品裡支援 MCP。當時,業內都認為工具呼叫這個難題很快就會藉著MCP得到解決,通向Agent元年之路暢通無阻。因此 2025 年的夏天,MCP 生態確實爆發了。GitHub 上湧現了數以萬計的 MCP Servers,從操作 Kubernetes 叢集到訂購披薩,似乎一切皆可 Agent 化。然而一年多時間過去了,想像中Agent爆發的場景並沒有發生,它們迷路了。當企業試圖將成百上千個內部工具掛載到自家Agent模型上時,它們開始變得遲鈍、健忘,無法完成任務。全自動執行工具呼叫,很多時候變成了一場昂貴的報錯循環。在2025年的4月,我在和Konjie老師溝通的過程中,形成了一個共識,即MCP確實是一個殘缺的協議,因為它沒有規定大語言模型和MCP的互動模式。也就是說,MCP只承諾提供統一的工具介面,但並沒有規定大模型應該如何發現、選擇、組合這些工具。當時,kongjie老師認為,這個工作應該是Agent整合商或者Agent平台的活兒。但在這之後,除了LangChain一直在最佳化之外,大家的進步都很慢。直到 2025 年 12 月,隨著 Anthropic 低調但極其重要地發佈了 高級工具呼叫(Advanced Tool Use)套件。終於自己動手補齊了這個「殘缺」的協議。這也許會帶來Agent開發的新一輪重要變化。01只有介面,沒有規則要理解為什麼 Agent 會迷路,我們必須重新審視Agent和工具間到底有什麼互動模式。在 MCP 協議下,當一個 Agent 試圖解決問題時,它必須經歷四個連續的互動步驟:感知、決策、組裝、執行。在2025年的工程實踐中,這四個步驟每一步都佈滿了地雷。步驟一:感知階段在這個階段中,Agent 做的是打開工具箱,查看自己有那些能力可用。在舊的MCP模式中,這是一個靜態全量的過程。為了讓 Agent 隨時可用,開發者被迫把成百上千個工具的完整定義(Schema),包括名稱、描述、參數結構一股腦塞進 System Prompt。這導致了上下文的公地悲劇。大量的工具說明書擠佔了模型的上下文。根據Anthropic的計算,大概50 個工具的定義就會吃掉約 20,000 Tokens。結果Agent 的注意力全放在記住工具名上了,其他的執行、推理嚴重受損。這一切,都是因為缺乏按需發現機制。模型只能遍歷所有工具進行搜尋。步驟二:決策階段在這個階段,Agent 根據使用者指令,在工具列表中挑選最合適的那一個。而此時,當工具從 10 個增加到 1000 個時,列表裡必然充滿了功能高度相似的選項。MCP 並沒有提供區分這些細微差別的機制,模型只能依靠工具定義中微弱的語義差異去猜測。這導致了決策癱瘓。面對海量選項,模型的注意力機制被稀釋,而且很容易選錯。選錯工具是連鎖反應的開始。一旦第一步選錯,後面的參陣列裝和執行全是無用功。造成這一問題的原因,也是缺乏動態收縮機制。步驟三:組裝階段這一步,當Agent 選中了工具後,會開始根據 Schema 填寫入參(Arguments)。這是被大多數人忽視,但報錯率最高的一步。MCP 的工具定義中,Schema 往往只定義了顯性語法(例如:參數 date 是字串),但沒有傳遞隱性規則(例如:這個日期必須是 YYYY-MM-DD 格式,且不能早於 2020 年)。 更沒有教你具體這個工具怎麼用。這導致了就算工具選對了,也得猜謎式試錯。Agent 只能靠直覺填參。然後經歷報錯 → 換個格式重試 → 再報錯的地獄循環,在這一過程中,大量的 Token 被浪費在其中,而不是推進任務。這一切都是因為MCP缺乏最佳實踐的顯式指引。模型不僅需要知道參數是什麼類型,還需要知道參數長什麼樣,怎麼用。步驟四:執行階段在這一階段中,Agent 發起呼叫,等待結果,讀取結果,決定下一步。在傳統的 MCP 模式中,這是一個線性阻塞(Linear Blocking)的過程。 如果任務需要“翻閱 100 頁日誌找到報錯行”,Agent 就必須進行 100 次“呼叫-等待-讀取-思考”的循環。這導致了推理瓶頸與資訊污染。首先它巨慢,每一次微小的操作都要經過一次完整的 LLM 推理和網路往返,耗時極長。而且它還會很髒,工具返回的中間結果(例如 100 頁的原始日誌)會被全量塞回上下文。這些垃圾資料不僅浪費 Token,還會干擾模型對最終結論的判斷。這就是MCP缺乏邏輯編排與資料清洗的能力。這導致它工具就算用上了,效率也很低,還會進一步增加天量的上下文。這四個步驟的崩壞,構成了一個完美的失敗閉環。而 Anthropic 的新工具,就是針對這四個步驟的精準爆破。02Anthropic 用三板斧,重建工具呼叫的秩序Anthropic最新發佈的這套被統稱為 Advanced Tool Use 的功能,精確地對應了上述四個痛點,在混亂的 MCP 荒原上重建秩序。下面我們就來看看,他們是怎麼一一鬆動這些“屎山問題”的。1. 修復感知與決策:Tool Search Tool針對「感知階段的上下文超載」和「決策階段的癱瘓」,Anthropic 給出的解法是 Tool Search(工具搜尋),它可以幫助MCP,不要把所有工具定義一股腦塞進上下文;而是先搜尋,再只載入少量候選工具的定義。這把缺失的「工具發現與按需載入」做成了平台級能力。Tool Search 的工作流程可以分為七步。那它和過去有什麼不同呢?Tool Search就這三招:先收縮工具空間,再做精確選擇,同時隱藏工具描述。不過,這個工具依然有Anthropic只做系統層的限制,它「只負責找工具,不負責保證一定找對」。它的每次搜尋只返回 3–5 個最相關工具。如果工具描述寫得差、關鍵詞不匹配、同義詞覆蓋不足,就可能搜不到你期待的工具。所以文件還給出了工具庫最佳化的建議。比如工具名/描述要清晰、描述裡放使用者會用的關鍵詞、系統提示裡提示工具類別等。但只要定義精準,使用者靠它一下就可以省下上萬的token,進而把上下文空間還給計畫、狀態和約束,而不是被工具說明書吃掉。2. 修復組裝:Tool Use Examples解決了找不到合適工具的問題,緊接就要解決怎麼用工具的問題。針對模型不知道怎麼填參的痛點,Anthropic 引入了 Tool Use Examples(工具使用示例) 標準。通過增加幾個範例,模型可以更好的呼叫其 Few-Shot Learner(少樣本學習者)的能力,更好的學會如何使用這些工具參數。舉個例子,比如我要連結個出票工具。Anthropic 的內部資料顯示,僅僅是加上這些示例,模型在處理複雜參陣列裝時的精準率就從 72% 飆升到了 90%。更重要的是,它終結了那個報錯-道歉-重試死循環,讓組裝這個工具使用步驟更精準。3. 修復執行:Programmatic Tool Calling (PTC)最後 Anthropic 通過加入 PTC (Programmatic Tool Calling)解決「執行階段慢與髒」的問題。回顧第一章,傳統的 Agent 調一次工具,就需要看一眼返回結果,再調一次工具。這不僅慢,而且把中間看到的幾千行垃圾日誌全塞進了上下文,導致後續推理難以為繼。PTC 則允許模型編寫程式碼來重新編排執行流程。 模型自己不再去翻頁、過濾、尋找,而是寫一段指令碼交給 Python 直譯器去循環、過濾、聚合、平行。而模型只在關鍵時刻(比如換工具時)介入,它只接受結構化的指令碼輸出作為上下文,而不是把全部中間資料灌給模型。這一改變讓過去幾十次網路往返被壓縮成了一次秒級的程式碼執行。而且中間過程產生的數以萬計的垃圾上下文在程式碼層就被消化了,永遠不會污染模型的推理上下文。Anthropic 的這套組合拳,本質上是在原本殘缺的 MCP 介面層之上,強行建構了一個「互動層」。Tool Search 確保了模型能看見(Perception)正確的東西;Examples 確保了模型能組裝(Formulation)正確的指令;PTC 確保了模型能執行(Execution)高效的操作。至此,讓 Agent 迷路的四個路口,都被立上了紅綠燈。03這股浪潮,不只是Anthropic 參與在 Anthropic 發佈這套方案的同時,行業內的其他玩家也開始在MCP發佈一年後,發現了「工具呼叫缺乏互動規則」是阻礙 Agent 規模化的最大絆腳石。於是在2025 年末這個節點上,我們可以看到各家給出了一些殊途同歸的解法。GitHub Copilot:用“虛擬聚類”對抗數量級GitHub Copilot 面臨的是最複雜的 IDE 場景,擁有成百上千個開發工具。 在 12 月的更新中,他們提出了「Smarter with Fewer Tools」策略。他們沒有像 Anthropic 那樣完全依賴搜尋,而是設計了一套「虛擬工具集(Virtual Tool Clusters)」。這套工具集將默認上下文中的工具壓縮到僅 13 個核心工具,而將其餘數百個工具被折疊進「虛擬類別」(如 Edit, Terminal, Git)。這樣,模型不再直接選工具,而是先選工作目的,比如修改程式碼,系統就會展開 Edit 類目下的具體工具。這種分層決策的機制,本質上也是一種對工具空間的動態收縮。Spring AI:中介軟體層的“介面卡模式”就在 GitHub 更新的同一周,2025 年 12 月 11 日,Java 生態的領軍者 Spring AI 發佈了 Christian Tzolov 撰寫的重磅更新。與 Anthropic 和 GitHub 不同,Spring AI 沒有自己的大模型。如果模型(比如 Llama 3 或舊版 GPT-5)本身不支援原生的 tool_search,該怎麼辦?那就不要等待模型進化,在框架層解決它。Spring AI 推出了 Advisors API,這實際上是一種中介軟體層的「介面卡模式」。它允許開發者在應用層外掛一個向量資料庫(Vector Store)。當使用者提問時,Spring 框架會先攔截請求,在向量庫裡進行 RAG 檢索,找到最相關的幾個工具,然後再動態地將這些工具的定義“掛載”到 Prompt 裡,最後才發給 OpenAI 或 Llama。這一舉措意義重大。它意味著按需載入的能力被解耦了。即使是那些智商較低或架構較老的模型,也能通過 Spring 框架這個外骨骼,獲得處理海量工具的能力。Warp:用“子智能體”分而治之終端工具 Warp 則更加激進,同樣在2025年11月,他們推出了 MCP Search Subagent。他們認為主模型(如 Claude 3.5 Sonnet)太貴了,不應該用來幹翻說明書這種雜活。於是他們設計了一個專門的輕量級 Subagent,專門負責去 MCP 伺服器裡海選工具,選好了再喂給主模型。這種主從架構不僅解決了上下文問題,還進一步降低了 Agent 的運行成本。04這是比Skills,對Agent影響更大的事進入 2026 年初,Skills無疑成了 AI 圈最喧囂的詞彙。大家喜歡它,因為把一堆脆弱的工具鏈打包成穩定的能力塊,像人一樣積累、復用、升級。你甚至可以想像一個 Skill Store,在那裡能力被商品化,Agent 被規模化。一個新的,屬於Agent的App Store。但 Skills 其實是「上層建築」。它的前提,是下面那套基礎設施得先成立:工具多了不崩、流程長了不漂、結果大了不炸。而 Anthropic 這次做的,恰好是那個「更底層、也更隱藏」的轉向點。它一起回答了 MCP 最初留下的空白:MCP 負責統一介面,而現在平台開始規定「怎麼互動」,工具市場才可能真的進入可治理、可營運、可擴張的階段。所以這是 Agent 圈水底的大事兒。如果說 MCP 1.0 是打通了 AI 與世界的物理連接,那麼加上這套互動標準後的 MCP 2.0,確立了 AI 與世界的溝通語法。 (騰訊科技)