工具太多,agent 反而變笨

先講這個反直覺的事實。大部分人的直覺是:給 agent 越多工具,它能做的事越多、應該越強。但現實剛好相反 —— 工具一多,它反而越常挑錯工具、越容易卡住。這不是感覺,是有研究實際量過的。接下來我給你看數字。

這張圖把兩條路擺在一起。右邊這條:把全部工具,一次全塞給 agent。工具一多,說明塞爆 context、它挑花眼,選對工具的準確度,有研究實測到低到只剩一成多。左邊這條:中間放一個發現層,先幫它挑出跟這個問題相關的少數幾個工具,再給它。同一批工具,準確度直接翻好幾倍。差別不在工具本身,在你「一次給它多少」。

給你幾個實測數字,心裡有個底。把全部工具塞進去,選對工具的準確度,有研究量到低至一成多;只給相關的,能翻好幾倍。實務上,agent 接到兩三個工具很多的 server,準確度就開始明顯下滑。還有,光是那些工具的說明文字,就可能吃掉你一大半的 context 視窗 —— agent 還沒開始做事,腦袋就先被塞滿了。要提醒的是,這些數字多來自單一研究的壓力測試,別當成鐵板一塊,但方向很清楚:工具越多越糟。

為什麼會這樣?原因其實很好懂。你開的每一個工具,它的名字、用途、參數說明,通通要塞進 agent 的 context 裡。工具一多,context 先被這些說明吃光,能拿來想事情的空間就變少;而且選項太多,它也會挑花眼,像人走進一家菜單有兩百道的餐廳,反而點不出來。你給它五十個工具,它每次回答前,都要先在這五十個裡面猜「這題該用哪個」,猜錯的機會自然變高。所以問題不是某個工具爛,是「一次給太多」這件事本身。

第一個解法,最便宜也最有效:少開工具。能只開一個,就別開兩個。還記得我們的 RAG 服務嗎?對外就只露一個 rag_search,不多開。這不是潔癖,是直接避開剛剛那個「挑花眼」的問題。在你想加第二個、第三個工具之前,先問一句:這個真的非開不可嗎?

第二個解法:如果你的工具真的很多,躲不掉,那就別一次全給。在 agent 跟工具中間,加一層「發現層」 ——它先看這個問題,挑出跟它相關的少數幾個工具,只把這幾個的說明給 agent。這樣 context 省一半、agent 也不挑花眼,準確度就回來了。這就是剛剛圖上左邊那條路,業界叫它動態發現。有趣的是,這個發現層的做法,跟我們整個系列在講的 RAG 幾乎一模一樣 ——把每個工具的說明也算成向量存起來,問題進來時,用同一招語意檢索,挑出最相關的幾個工具。等於是「對工具做一次 RAG」。你會發現,同一個概念,在不同層一直重複出現。

第三個解法,是治理層面的:閘道。當你內部有很多個 MCP server,就在它們前面放一個閘道,集中管理 ——統一認證、決定誰能用哪些工具、留稽核紀錄。工具的安全也是真問題,業界已經有專門的清單在盯這件事,別讓來路不明的工具隨便接進來。但閘道有代價:多一層就多延遲、還可能變成單點故障。所以小團隊、工具不多的,先別急著上閘道 —— 那是規模大了才划算。

最後給你一個很多人還沒意識到的方向:不是每件事都該做成一個工具。官方的定位是這樣分的:需要連外部、查資料、要認證的,用 MCP 工具;而「怎麼做一件事」這種流程知識,可以做成「技能」 ——它平常不佔 context,agent 要用到的時候才載進來。兩者是互補的,不是誰取代誰。把流程知識從工具裡搬出來,你的工具清單就會瘦一大圈,agent 也就不那麼容易被塞爆。

這集帶走一句話:工具不是越多越好,太多反而讓 agent 變笨,這有實測。所以優先「少開工具」;真的躲不掉,再加動態發現,只給它相關的;server 一多,才上閘道集中治理。還有,把「怎麼做」的流程知識做成技能,別全塞成工具。少,幾乎永遠是對的方向 —— 這也是整個系列一直在講的:先簡單,別過度。