TSO 工具選擇優化：接入、檢索與選用｜LS-Labs（AI 搜尋與數位行銷實驗室）

01

TSO 閱讀指南

從工具選擇流程開始，延伸到接入協定、搜尋介面與應用案例。

延伸名詞：工具中繼資料、工具描述、候選召回、TCC。

延伸閱讀：用 TCC 檢查工具定義；AI 代理人的工具選擇機制。

02

TSO 的四個環節

TSO 把代理人選工具的過程拆成四段：工具接入、候選曝光、模型選擇、呼叫與執行。工具沒被用上時，可能根本沒進候選清單，也可能進了清單卻輸給別人；四段拆開，才分得清問題在曝光、選擇還是執行。

01
工具接入 Integration
它有沒有接進代理人能用的系統？
以 MCP 為例，工具定義包含名稱、描述與輸入參數。模型看的是這些中繼資料，不是你的程式寫得多好。
02
候選曝光 Exposure
它有沒有被載入，讓模型看到？
採用工具搜尋的系統，會先檢索候選，再載入部分工具定義。以 Anthropic 的工具搜尋為例，標記為延後載入的工具要等 Claude 搜尋到才會出現。沒被載入的工具，後面的選擇根本輪不到它。
03
模型選擇 Selection
候選工具裡，模型為什麼選它？
模型在已載入的工具中挑一個。使用者需求與工具描述的語意有多接近，會直接影響選擇。BiasBusters 研究就發現，小幅改動工具描述也可能明顯改變結果。
04
呼叫與執行 Execution
被選中之後，真的做完了嗎？
模型決定工具與參數後，由用戶端以 MCP 的 tools/call 等方式送出呼叫。接著要檢查參數、回傳結果與執行錯誤，不能把「有呼叫」當成「已完成」。

套回訂位的例子

假設餐廳的訂位 API 已接進某個代理人，使用者說要訂位，它卻沒被呼叫。若它不在搜尋回傳的候選工具裡，問題出在候選曝光；若在清單上卻輸給另一個訂位工具，要看模型選擇；若被選中但日期參數填錯，就是呼叫與執行出了狀況。

「被找到」和「被選中」要分開處理。Microsoft Foundry 可以替每個工具設定只給搜尋用的文字；這段文字會被索引，模型讀不到。模型挑工具時看的，仍是名稱、描述與參數。

03

訂位需求下的三種工具狀態

同一個訂位需求下，訂位工具可能沒被載入、能力與任務對不上，也可能符合任務。切換下面三個狀態，看每個狀態該怎麼檢查。

使用者問「今晚 19:00，幫兩位找一家餐廳並訂位。」

選一個狀態沒進候選能力不符符合任務

已接入的訂位工具沒有進入候選清單

本次載入餐廳搜尋可見

本次載入地圖查詢可見

已接入但未載入訂位工具缺席

怎麼檢查先看這次載入了哪些工具。訂位工具沒進候選，後面的選擇與呼叫都不用談。

下一步：能力不符 →

搜尋餐廳的工具沒有訂位能力

任務需要查空位，並建立訂位

工具能做搜尋名稱、地址與介紹

能力缺口：查空位、建立訂位

怎麼檢查訂位要查空位、建立紀錄。工具描述只寫搜尋名稱與地址，模型就不知道它能訂位。

下一步：符合任務 →

工具能力與訂位參數相符

候選能力查詢空位、建立訂位

日期今晚
時間 19:00
人數兩位

怎麼檢查查空位、建立訂位，加上日期、時間與人數，模型才能把使用者需求轉成一次工具呼叫。

工具定義該怎麼寫？看三張圖 ↓

04

代理人怎麼篩選工具

採用工具搜尋的系統，會先檢索候選工具，再交給模型選擇與呼叫。下圖用 12 → 3 → 1 的教學設定說明篩選過程；實際候選數與流程依系統而異。

選一張圖解兩階段檢索三個失敗斷點工具定義對照

已接入的工具只有一部分進入模型視野

「幫我訂週六晚上七點，四個人的內用座位。」

12個工具已接入的工具庫

餐廳搜尋
地圖
評論
查詢空位
支付
建立訂位
行事曆
天氣
查詢訂位狀態
外送
郵件
翻譯

01候選檢索比對名稱、描述與能力

3個進入模型視野載入工具定義

查詢空位
建立訂位
查詢訂位狀態

02模型決策依任務挑工具

1個被選中送出工具呼叫

查詢空位

週六・19:00・4 人

第一道門

檢索出哪些候選工具

工具名稱、描述與參數資訊，讓檢索器找到與需求相關的候選。

第二道門

挑出能完成任務的工具

模型讀取候選的完整定義，比較查空位、建立訂位與必要參數。

延伸：Anthropic 的工具搜尋流程、ToolLLM 的 API 檢索器。

沒訂到位的三個可能斷點

「幫四個人訂週六晚上七點的內用座位。」

01
檢索斷點
工具有進入候選嗎？

service_v2「提供餐飲數位轉型服務」

只看這段名稱與描述，找不到「餐廳內用訂位」的具體能力。

檢查工具索引補上餐廳、空位與建立訂位等任務用語。
02
選擇斷點
候選之間分得清楚嗎？

外送點餐／內用訂位

兩個工具都寫「火鍋預訂」，使用方式卻完全不同。

檢查能力描述寫明現場座位、外送或自取，讓選擇有依據。
03
呼叫斷點
參數符合工具要求嗎？

"晚上七點"→"19:00"

工具選對了，時間欄位仍需要符合伺服器接受的格式。

檢查參數與回傳標明時間格式、必填欄位，並核對呼叫結果。

對照 MCP 的工具定義、呼叫與回傳結構，逐段找到失敗的位置。

工具名稱、描述與參數的寫法對照

名稱說動作，描述說能力，參數說格式。

資訊太模糊

name: restaurant_helper_api
description: 全方位餐飲體驗，輕鬆搞定用餐大小事。
參數: date、num

日期是哪一天？人數包含誰？會查空位，還是會直接建立訂位？

動作與輸入都明確

name: search_restaurant_tables
description: 查詢指定日期、時段與人數的空位，回傳可訂時段、座位區與訂位條件。建立訂位使用 create_table_reservation。
參數: restaurant、date、time、party_size、area

查空位與建立訂位各有明確入口，模型可以按任務選擇。

展開完整的輸入參數結構

{
  "type": "object",
  "properties": {
    "restaurant": { "type": "string", "description": "餐廳名稱或分店" },
    "date": {
      "type": "string", "format": "date",
      "description": "用餐日期，YYYY-MM-DD"
    },
    "time": {
      "type": "string",
      "description": "用餐時段，24 小時制 HH:MM"
    },
    "party_size": {
      "type": "integer", "minimum": 1,
      "description": "用餐人數，含兒童"
    },
    "area": {
      "type": "string",
      "description": "偏好座位區，例如內用或戶外"
    }
  },
  "required": ["restaurant", "date", "time", "party_size"],
  "additionalProperties": false
}

參考：MCP Tools 規格。

05

常見問題

TSO 是誰提出的？

TSO 是 LS-Labs 提出的操作框架，用來拆解 AI 代理人為什麼選用或沒選用某個工具。它把問題分成四段，避免把所有失敗都歸因給模型。

TSO 和 GEO 差在哪？

GEO 看 AI 回答裡提到誰、引用誰；TSO 看代理人動手執行任務時，呼叫了誰的工具、API 或 MCP 伺服器。

產品還沒有 API 或 MCP 伺服器，需要關心 TSO 嗎？

要。還沒有 API 時，第一段「工具接入」就是起點。網站本身能不能讓代理人讀懂、操作，則屬於 AX 的範圍。先從一個最常發生的任務開始，不必一次把整套系統做完。

做了 MCP 伺服器，代理人就會用我的工具嗎？

不一定。接上 MCP 只完成第一段「工具接入」；工具還要被載入候選清單，模型看得到它，並覺得它適合眼前的任務，才會選用。以 Anthropic 的工具搜尋為例，標記為延後載入的工具要等 Claude 搜尋到才會出現。

工具的名稱、描述與參數該怎麼寫？

名稱說動作，描述說能力，參數說格式。例如把「查空位」與「建立訂位」拆成兩個工具，各自寫清楚能做什麼，並標明時間格式與必填欄位。可對照 MCP 的 Tools 規格。

候選曝光是什麼？

在採用工具搜尋的系統裡，工具被檢索並載入模型視野的過程，就是候選曝光。沒被載入的工具，後面的選擇輪不到它。

工具被選中了，就代表任務完成了嗎？

不是。被選中之後，還要檢查呼叫的參數、回傳結果與執行錯誤，不能把「有呼叫」當成「已完成」。

品牌常出現在 AI 回答裡，代理人就會選用它的工具嗎？

代理人還會依任務挑選當下可用的工具。GEO 看 AI 回答中的提及與引用，TSO 接著看工具是否被載入、是否適合任務，以及模型最後選了誰。

06

四個研究主題的關係

GEO 看自然回答裡的提及與引用，TSO 看代理人選用哪個工具，AX 看任務能不能完成，AI 廣告看回答下方的付費版位怎麼配對與轉換。四者處理相鄰的問題，可依內容交叉閱讀。

TSO 工具選擇優化工具準備好了，
AI 為何沒選你？

TSO 閱讀指南

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

MCP 是什麼？

搜尋 API 是什麼？

Exa 3.0 搶攻 AI 代理人的搜尋需求