Anthropic出手，補齊Agent短板｜Hao好聊論文

早在 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 的新工具，就是針對這四個步驟的精準爆破。

02

Anthropic 用三板斧，重建工具呼叫的秩序

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 與世界的溝通語法。 (騰訊科技)