Ian Chou's Blog

AI 真的知道它在呼叫哪個 Server 嗎？ (Tool Call ID 機制)

AI 真的知道它在呼叫哪個 Server 嗎？ (Tool Call ID 機制)

這是一個非常關鍵的誤解，釐清這點你就打通任督二脈了！

直接回答：AI（LLM 模型本身）完全不知道、也不需要知道「專屬秘書」或「管線」的名字。

AI 看到的只是一份 「對話劇本 (Context/Chat History)」。

真正的 「路由器」是 Cursor (Host App)，它是夾在中間的 「全能管家」。AI 只是發出命令，Cursor 負責跑腿並把結果貼回劇本裡。

我們用一個 「餐廳點餐」 的流程來演示，你會發現 AI 有多「懶」：

角色分配

  1. AI (LLM)：坐在包廂裡的 大老闆（只會動嘴，不知道廚房在哪）。
  2. Cursor (Host App)：全能管家（知道哪個廚師負責做什麼菜，手裡握有通往各個廚房的對講機/繩子）。
  3. MCP Servers：躲在不同地下室的 專屬廚師（只負責接單做菜）。

實際流程（這裡展示 AI 到底看到了什麼）

第一步：大老闆 (AI) 下單

使用者說：「幫我算 100 + 200，順便查一下台北天氣。」

AI 思考後，它 不會 說：「請呼叫 PID 5678 的 Math Server...」。
它只會在其回應中產生一個 「工具呼叫標籤 (Tool Call ID)」，像這樣：

AI 的心聲 (Output)：
"我要使用工具 add，參數是 {a: 100, b: 200}。這張單號叫做 call_AbCd123。"
"我要使用工具 get_weather，參數是 Taipei。這張單號叫做 call_XyZ987。"

(注意：AI 根本不知道是誰要去執行，它只發出需求和單號。)

第二步：管家 (Cursor) 忙碌跑腿

這時候，Cursor (程式邏輯) 接手了。AI 暫停運作。

  1. Cursor 看到 add：

    • 查表：喔！add 是 Math Server 提供的。
    • 動作：拉動 Math Server 的繩子（stdin），把資料送過去。

  2. Cursor 看到 get_weather：

    • 查表：喔！get_weather 是 Weather Server 提供的。
    • 動作：拉動 Weather Server 的繩子（stdin），把資料送過去。

(這一步完全是 Cursor 在後台跑，AI 正在發呆等待。)

第三步：廚師 (Server) 出菜

第四步：管家 (Cursor) 回報（關鍵！）

Cursor 把拿到的結果，整理成 AI 看得懂的格式，貼回到「對話劇本」裡。

Cursor 會對 AI 說：

「嘿，老闆！
針對單號 call_AbCd123 (加法)，結果是 300。
針對單號 call_XyZ987 (天氣)，結果是 Rainy。」

第五步：大老闆 (AI) 做總結

AI 被叫醒，它重新閱讀了整份劇本（包含剛剛貼上去的結果）。

AI 看到：

於是 AI 回答使用者：

「計算結果是 300，台北現在下雨。」

結論：祕密在於 ID 配對

所以，區分「誰是誰」的機制分為兩層：

  1. 傳輸層 (Transport Layer) - Cursor 負責：

    • 靠的是 Process Object / Pipe。
    • Cursor 知道 add 必須往 Math Pipe 送。
    • AI 完全不知情。

  2. 邏輯層 (Application Layer) - AI 負責：

    • 靠的是 Tool Call ID (例如 call_AbCd123)。
    • 這是為了讓 AI 知道「這個結果 300」是回應「那一次加法請求」的，而不是回應天氣請求的。
    • AI 依賴這個 ID 來把答案填回去。

簡單說：Cursor 負責「找對人做通訊」，AI 負責「認對單號做邏輯」。