AI 為什麼選擇這個工具？從資訊檢索理解 TSO

一、當 AI 開始替你訂餐廳、買機票，誰決定哪個 App 被打開？

試想一個每個人都熟悉的場景：這週五晚上你想和三位朋友在台北聚餐，於是對手機裡的 AI 助理說：「幫我找大安區這週五晚上七點、四個人、預算一人一千五以內的義式餐廳，確認有空位就直接訂位，訂好後把時間加進我的行事曆，再傳訊息通知朋友。」

過去完成這件事，你得親自打開 Google 地圖看評論、切到訂位網站確認空檔、打開行事曆輸入行程，最後再打開通訊軟體傳連結。對具備工具呼叫能力的 AI 代理人（AI Agent）而言，這是一段連續的自動化工作流：系統先解析你的意圖，接著尋找能查詢餐廳與空位的工具，完成預訂後，再依序呼叫行事曆與通訊軟體。問題在於，大型語言模型（LLM）本身只是一顆擅長理解語言與推理的大腦。它無法單憑模型參數得知哪家餐廳今晚還有空桌，也不能直接替你寫入行事曆或刷卡付訂金。這些與現實世界互動的動作，全部仰賴外部工具（External Tools）。

近年備受矚目的 Model Context Protocol（MCP）、OpenAI 的 Function Calling，以及各類外掛與 API 整合，本質上都是替這顆大腦接上感官與四肢。這裡先釐清三個常被混為一談的概念：Function Calling 是模型與應用程式交換工具呼叫指令的機制；MCP 是讓外部工具與資料來源以標準化格式接入 AI 的開放協定；Agent 則是能依使用者目標拆解任務、呼叫工具，並根據結果決定下一步的完整系統。

基礎建設成熟後，新的問題隨之浮現。假設你的 AI 助理同時連接了五種餐廳訂位服務、八種機票比價工具，以及十幾個旅遊行程平台；放眼整個市場，更有數百個功能高度相似的 API 支援 MCP 接入。當你說「幫我訂餐廳」或「買下週去東京的機票」，AI 究竟依什麼邏輯把哪個服務放進候選名單，並替你按下預訂鍵？

過去二十年，軟體產品競爭的核心是人類的注意力。從搜尋引擎排名（SEO）、App Store 排行榜到介面轉換率設計，企業想盡辦法說服人類點擊自己的產品。當使用者逐漸習慣只講結果、不問過程，把執行權交給 AI 代理人，軟體服務的第一線選擇者就從人類變成了模型及其背後的檢索系統。未來的競爭除了發生在人類看得見的搜尋結果頁，也會發生在 AI 內部的「工具候選清單」裡。要看懂這場新賽局，得先理解 AI 是怎麼學會挑選工具的。

二、從 5 個工具到 16,000 個 API：AI 如何透過「兩階段漏斗」找到工具？

語言模型並非天生就會使用外部工具。2023 年，Meta AI 團隊在 NeurIPS 發表《Toolformer》，首次系統性地探討這個問題。研究者觀察到，語言模型很會寫文章，卻常在簡單的四則運算或即時資訊查詢上出錯，好比一位博學的文科教授心算不準大數乘法。團隊於是利用自監督學習，訓練 GPT-J 6.7B 模型操作計算機、搜尋引擎、翻譯、問答系統與行事曆五種工具，證明模型能自主判斷「何時需要工具」、「該用哪個工具」以及「該傳入什麼參數」。

真實世界的軟體生態遠比五個工具複雜。2024 年清華大學等團隊在 ICLR 發表《ToolLLM》，從 RapidAPI Hub 收集了 16,464 個真實的 RESTful API，涵蓋美食、旅遊、金融、影音等 49 個類別。工具規模從個位數暴增到上萬個時，系統立刻撞上一道牆：上下文視窗（Context Window）限制與注意力稀釋。如果使用者只想訂個披薩，系統卻要把一萬六千個工具的名稱、說明與參數格式全部塞進提示詞讓模型挑選，每次對話都會消耗大量 Token，模型也更容易因資訊過載而選錯。

為了解決這個問題，ToolLLM 引入「神經網路 API 檢索器（Neural API Retriever）」，把 AI 使用工具的過程拆成「先檢索（Retrieval）、後決策（Selection）」的兩階段漏斗。這個架構與搜尋引擎的資訊檢索（Information Retrieval, IR）邏輯高度相通，只是比對對象從長篇網頁換成了工具的名稱、功能描述與參數定義。

如圖解一所示，第一階段會透過三種機制把上萬個工具濃縮成極少數的候選名單。最基礎的是以 BM25 為代表的關鍵字檢索（Sparse Retrieval），直接計算指令與工具說明之間的詞彙重疊度。所以工具命名與描述不能只寫抽象的品牌口號。使用者想「訂機票」時，一個描述寫著「提供卓越的全球智慧移動解決方案」的航空工具，在關鍵字檢索階段就會因為沒有字面交集而出局。

人類說話很口語，不會照著工程師寫的規格書下指令。你對 AI 說「幫我找週末跟朋友聚餐不限時的店」，某個訂位工具的說明寫的是「依用餐時間限制與人數篩選合作餐飲店家」，兩者用詞不同，意思卻高度一致。這時就輪到語義向量檢索（Dense Retrieval）：系統透過 Embedding 模型把口語需求和工具描述都轉成高維向量，以餘弦相似度（Cosine Similarity）找出語義相近的工具。

然而，語義相近不等於工具適用。假設你急著請 AI「幫我買今晚八點台北回左營的高鐵票」，在向量空間裡，「查詢高鐵歷史誤點率統計」、「搜尋高鐵旅遊美食部落格文章」與「高鐵即時餘票查詢與訂票」三個工具的向量可能非常接近，因為它們都圍繞著「高鐵」與「班次」。只靠第一輪向量相似度，AI 可能拿一個只能看歷史數據或食記的工具去執行買票任務。因此，大型檢索系統通常會在召回前幾十個候選後，再加一層重排序模型（Reranker），確認工具是否真的具備即時交易與訂位能力，把真正能辦事的選項推到前面，最後才交給語言模型做第二階段的決策。

三、工具越多反而越難選？從 ToolScope 與 Anthropic 實證看檢索瓶頸

理解兩階段漏斗後，就能明白一件事：你的工具沒被 AI 使用，往往不是模型覺得產品不好，而是在第一階段就已落選，模型從頭到尾都沒看見它。

隨著接入生態的工具數量膨脹，工具之間的「撞名」與「描述重疊」也越來越嚴重。Oracle AI 研究團隊在 ACL 2026 發表的《ToolScope》點出大型工具庫的兩個瓶頸：大量工具的功能描述高度雷同，讓檢索器與模型無法分辨差異；有限的上下文空間又容納不了龐大的工具定義。

想像你的手機 AI 同時裝了三個美食工具：第一個自稱「全方位智慧餐飲助手」，第二個寫著「熱門餐廳探索與美食指南」，第三個標榜「一站式餐飲生活服務」。從文字看幾乎一模一樣，實際上第一個是外送平台、第二個是食記評論網，第三個才是內用訂位系統。當工具提供者都用模糊、包山包海的詞彙包裝自己，檢索系統就會陷入混亂。ToolScope 團隊為此設計了自動化的工具合併（Tool Merging）與校正機制：先以向量相似度抓出高度重疊的工具，再交由模型釐清能力邊界，並搭配重排序模組。在 UltraTool 資料集上以 GPT-4o 測試的結果如下：

這組數據說明兩件事。第一，從關鍵字檢索升級到語義向量檢索，正確選中率（CSR）提升超過 30 個百分點。第二，論文的消融實驗顯示，合併功能重疊的工具、減少語義重疊帶來的提升最大，重排序只在大型、雜訊多的工具庫有小幅幫助。換句話說，把工具的能力邊界寫清楚，本身就是有效的檢索優化。

商業平台也已經把這套做法變成基礎設施。2025 年的預印本《RAG-MCP》指出，先以語義檢索篩選 MCP 工具再交給模型，工具選擇準確率從 13.62% 提高到 43.13%。同年 11 月，Anthropic 在 Claude 開發者平台推出 Tool Search Tool：工具可標記為延後載入，模型以 BM25 或正規表示式搜尋後才載入需要的定義。Anthropic 公布的例子是，同時接入多個 MCP 伺服器時，傳統做法光是工具定義就約 72,000 個 Token（開始工作前總消耗約 77,000 個）；改用 Tool Search Tool 後總消耗降到約 8,700 個，Anthropic 稱工具相關的 Token 開銷約減少 85%。選對工具的準確率也同步上升：

資料來源：Anthropic〈Introducing advanced tool use on the Claude Developer Platform〉。這是廠商內部評測，測試集未公開，不宜與學術基準直接比較。

當 Anthropic 與各大代理人框架都開始採用「先搜尋、後載入」的動態工具檢索，一個工具能否在第一輪搜尋中出線，就成了決定它有沒有機會被使用的分水嶺。

四、拆解失敗黑盒子：為什麼 AI 找到了工具，任務還是失敗？

談優化之前，要先建立診斷框架：被檢索出來（Tool Retrieval）不等於被模型選中（Tool Selection），被選中也不等於成功執行（Tool Calling）。ACL 2025 Findings 的《Retrieval Models Aren't Tool-Savvy》以涵蓋約 43,000 個工具的 ToolRet 基準測試發現，擅長找網頁文章的檢索模型面對工具檢索時表現明顯下滑，進而拖累整個代理人的任務成功率。

在 LS-Labs 的 TSO 四段框架中，工具提供者完成第一段「工具接入」後，工具在實際任務裡會依序經過三個斷點，正好對應第二段「候選曝光」、第三段「模型選擇」與第四段「呼叫與執行」。假設你請 AI 助理「幫我訂這週六晚上七點、四個人的火鍋店」，AI 卻回報訂位失敗，可以用下面的診斷圖找出卡在哪裡：

這張圖說明了為什麼「只管曝光」的思維在代理人時代不夠用。斷點 1 落敗，是可發現性（Discoverability）不足；斷點 2 落敗，是能力邊界（Capability Boundary）模糊；斷點 3 落敗，則是參數規格（Schema Design）定義不良。三個環節都打通，工具才能真正完成使用者的託付。

五、TSO（工具選擇優化）是什麼？做好 TSO 的四項優勢

過去的學術研究大多站在模型開發者的角度，思考怎麼訓練更聰明的檢索器與模型。把視角翻過來，站在提供服務的企業、SaaS 產品與工具開發者的立場：兩家功能相同的訂房網站、支付工具或電商服務同時接入 AI 生態系時，誰能以更精確的工具定義被正確選用？

這就是 LS-Labs 提出 TSO（Tool Selection Optimization，工具選擇優化）的出發點。本文採用的定義是：從工具提供者視角出發，透過真實、結構化且邊界清晰的工具名稱、能力描述、適用情境與參數設計，讓工具在 AI 代理人的檢索、決策與呼叫流程中被精準發現、正確理解與可靠執行的系統化方法。TSO 是本站的操作框架，不是任何 AI 平台公布的排名因子；LS-Labs 目前也還沒有自己的實測結果，以下優勢依據的是既有論文與平台文件。

要直觀理解 TSO 在 MCP 工具定義或 OpenAI Function Calling 中的施力點，可以比較一份工具定義優化前後的差異：

{
  "name": "travel_helper_api",
  "description": "提供全方位的智慧旅遊體驗，協助使用者輕鬆搞定全球住宿與行程規劃。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "date": { "type": "string" },
      "num":  { "type": "integer" }
    }
  }
}

{
  "name": "search_and_book_hotel_rooms",
  "description": "查詢指定城市與日期的飯店空房價格，並可直接建立住宿預訂。回傳房型、含稅總價與取消政策。使用限制：僅限住宿訂房，不支援機票查詢、餐廳訂位或景點門票。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "check_in_date": {
        "type": "string",
        "description": "入住日期，格式 YYYY-MM-DD，例如 2026-11-07"
      },
      "guests_count": {
        "type": "integer",
        "description": "入住成人總數，不含嬰幼兒"
      }
    },
    "required": ["check_in_date", "guests_count"]
  }
}

綜合 NAACL 2025 的《EASYTOOL》、ICLR 2026 的《Tools are under-documented（Tool-REX）》與 EMNLP 2024 Findings 的《Re-Invoke》等研究，工具文件完成上述重構後，可以預期在四個層面取得優勢：

1. 突破上下文限制，取得首輪候選池的入場券（Top-K Recall）。在 Tool Search 與 RAG-MCP 這類架構下，AI 每次只把最相關的少數工具載入上下文。描述涵蓋明確的動詞、目標受詞與使用者常說的任務情境，無論使用者說「找旅館」、「訂民宿」還是「查週末住宿空房」，工具都比較有機會在 BM25 與向量檢索階段進入 Top-K，不至於還沒比較就出局。Tool-REX 與 Re-Invoke 的結果都顯示，補足工具文件或改寫查詢能提高工具檢索的召回。
2. 消除語義碰撞，在同類工具中提高正確獲選率（CSR）。ToolScope 的實驗顯示，市場上十幾個旅遊或餐飲工具都寫「智慧生活助手」，只會讓向量空間嚴重重疊。明確交代輸入條件、回傳資料與負向邊界（Negative Constraints），能讓重排序模型與 LLM 更快判斷哪個工具最契合當前子任務。
3. 降低參數幻覺與 API 報錯，減少重試成本。OpenAI 在官方文件中提出「實習生測試」：一位剛報到的實習生只看你給模型的參數說明，能不能一次填對所有欄位？inputSchema 寫清楚，模型就比較可能一次傳出正確的日期格式與參數，避免呼叫失敗後重試，或轉而改用其他工具。至於平台是否會把任務完成率納入工具排序，目前沒有平台公開這類機制。
4. 在零介面（Zero-UI）情境中，成為代理人直接呼叫的服務。傳統 SEO 爭取的是讓人類看見網頁連結，GEO 爭取的是讓 AI 在回答裡提到品牌；TSO 關心的是代理人執行任務時有沒有呼叫你的服務。當消費者只對手機說「幫我叫車去機場」或「幫我買划算的旅遊保險」，中間可能已經沒有網頁瀏覽與比價畫面。這也是 B2A（Business-to-Agent）討論的核心場景。

TSO 與現有優化概念的分工，可以用下表對照：

六、如何驗證 TSO 成效？兼論 ToolTweak 揭露的操縱風險

TSO 如果只停在「把文案寫清楚」，很容易淪為玄學。驗證成效要遵循控制變數與分層觀測：固定模型版本、工具池規模與權限，再用三層指標做 A/B 測試。

為什麼這麼強調「正確地不被選中」與誠實描述能力邊界？因為工具描述一旦能左右 AI 的決策，惡意操縱也會跟著出現。

2025 年 10 月的預印本《ToolTweak: An Attack on Tool Selection in LLM-based Agents》揭露了這個風險。研究團隊發現，攻擊者只要以演算法反覆微調工具的名稱與描述，手法類似早期的關鍵字填充與提示注入，就能系統性地拉偏代理人的選擇。在實驗環境中，目標工具的選中率從約 20% 的基準被拉高到最高約 81%，而且效果能跨越開源與閉源模型。

試想一個危險的情境：市面上出現一個來路不明的第三方換匯或購票工具，在 MCP 描述中塞滿「官方授權、零手續費、全網最安全即時出票首選」等誘導字眼，讓你的 AI 助理棄用銀行或航空公司的官方 API，轉而把信用卡資料傳給它。這正是工具選擇和網頁搜尋在風險上的根本差異：SEO 點錯連結，使用者頂多關掉網頁；TSO 選錯工具，AI 可能直接執行錯誤轉帳、刪除檔案或洩露個資。

所以方法論上要畫出紅線：TSO 的目標是讓真實能力與任務意圖正確匹配，不是用誇大的詞彙換取最高選中率。一個只能查詢歷史股價的工具，若為了流量把自己描述成能「提供最新股市報價」，只會讓代理人做出錯誤的交易決策，對代理人背後的使用者造成傷害，也讓工具本身失去信任。

LS-Labs 的研究進度本站正在設計把「候選曝光」與「模型選擇」分開觀察的受控實驗，尚未執行，因此本文不主張任何改寫能提高特定工具的被呼叫比例。實驗結果出來後會另文發布，包括沒有發現差異的結果。

七、結論：當 AI 成為軟體服務的代理操作者，產品需要新的「被理解方式」

從 2023 年 Toolformer 讓模型學會按計算機、2024 年 ToolLLM 處理上萬個 API 的檢索難題，到 2025 年 Anthropic 把工具搜尋做成平台功能，以及 2026 年 ToolScope 處理工具庫的語義重疊，軟體服務的入口正在移動。

過去，打造一款優秀的訂位系統、比價網站或理財工具，企業主要思考如何讓人類覺得介面好看、廣告吸引人。在代理人時代，產品多了一位只看結構化文件、又握有實際執行權的使用者：大型語言模型與它的檢索系統。人會被視覺設計與品牌口號打動；AI 代理人在意的是工具名稱是否明確、功能邊界是否清晰、參數格式是否沒有歧義。

對開發者與企業而言，過去藏在工程部門角落、只為方便串接而寫的 API 與 MCP 說明文件，如今走到了競爭前線，成為產品能否被 AI 發現、理解與選用的核心資產。未來的軟體市場，除了比誰在人類世界更有知名度，也會比當使用者說出需求的那一秒，哪個產品能讓 AI 確信：「這就是完成這項任務最可靠的工具。」

想先掌握 TSO 的定義與四段框架，可以從 TSO 主題頁開始；工具選用之後代理人能不能把事情辦完，則屬於 AX（代理人體驗）的範圍。

參考文獻

學術研究

• Schick, T., et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023. arXiv:2302.04761
• Qin, Y., et al. (2024). ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs. ICLR 2024. arXiv:2307.16789
• Shi, Z., et al. (2025). Retrieval Models Aren't Tool-Savvy: Benchmarking Tool Retrieval for Large Language Models. Findings of ACL 2025. arXiv:2503.01763
• Liu, M. M., et al. (2026). ToolScope: Enhancing LLM Agent Tool Use through Tool Merging and Context-Aware Filtering. ACL 2026, 34095–34119. arXiv:2510.20036
• Gan, T., & Sun, Q. (2025). RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. arXiv 預印本. arXiv:2505.03275
• Yuan, S., et al. (2025). EASYTOOL: Enhancing LLM-based Agents with Concise Tool Instruction. NAACL 2025. arXiv:2401.06201
• Lu, X., et al. (2026). Tools are under-documented: Simple Document Expansion Boosts Tool Retrieval. ICLR 2026. arXiv:2510.22670
• Chen, Y., et al. (2024). Re-Invoke: Tool Invocation Rewriting for Zero-Shot Tool Retrieval. Findings of EMNLP 2024. arXiv:2408.01875
• Sneh, J., et al. (2025). ToolTweak: An Attack on Tool Selection in LLM-based Agents. arXiv 預印本. arXiv:2510.02554

官方技術文件與產業資料

• Anthropic (2025). Introducing advanced tool use on the Claude Developer Platform. anthropic.com
• Anthropic. Tool search tool. platform.claude.com
• Model Context Protocol (2026). Specification: Server Tools (2026-07-28). modelcontextprotocol.io
• OpenAI. Function calling. platform.openai.com
• Biilmann, M. (2025). Introducing AX: Why Agent Experience Matters. biilmann.blog