LLM 工具調用的真相：模型從來沒有「執行」任何東西
你有沒有問過 AI「幫我查一下今天台北的天氣」，然後它真的回答你了？
看起來它「上網查了」。但事實上，它沒有。
AI 其實只是在「畫設計圖」
想像一位建築師坐在辦公室，畫好一份施工圖，交給工頭：「這面牆要打掉，這裡重新走管線。」
建築師從頭到尾沒碰過一塊磚。真正動手的是工班。完成後，工頭跑回來回報：「牆打掉了，但發現裡面有一條舊管線沒在圖上。」建築師看了，才決定下一步怎麼改。
AI 工具調用的機制幾乎一模一樣。
當你叫 AI「搜尋最新消息」，它不是自己去打開瀏覽器、輸入關鍵字。它做的事情是：畫一張格式化的施工圖，告訴外部系統「我需要這個搜尋結果」。真正去搜尋的，是外部的程式。結果回來後，再交回給 AI，它才能繼續回答你。
用技術的話說，那張「施工圖」長這樣：
{
"type": "tool_use",
"name": "web_search",
"input": { "query": "台北天氣" }
}
AI 輸出這段文字之後，它的工作就暫停了。它既不知道搜尋有沒有成功，也不知道結果是什麼——直到工頭把答案送回來。
AI 從來不是在「使用工具」，而是在「請別人幫它用工具」。
幕後其實有三個角色
理解 AI 工具調用，可以把整個系統想成一個工程團隊：
| 角色 | 在 AI 系統裡是誰 | 負責什麼 |
|---|---|---|
| 建築師 | Model Weights（模型本體） | 幾百億個數字構成的設計知識，本身不動手 |
| 工頭 | Orchestration Layer（協調層） | 接收設計圖、指揮工班執行、把結果回報給建築師——真正的執行者 |
| 工班 | Inference Engine + 各種工具 | 實際跑搜尋、執行指令、讀取檔案 |
所謂「AI 模型」，本質上就是那位建築師——滿腦子設計知識，但從不親自砌磚。
你用不同的 AI 工具，背後的「工頭」也不一樣：
- Claude.ai 網頁版：Anthropic 自己的後台系統
- Claude Code（程式開發工具）：你電腦裡的一個程式
- ChatGPT Plugins：OpenAI 的後台（2023 年 6 月率先普及「function calling」這套機制）
- 你自己串 API：你寫的程式
Anthropic 的 tool use API 於 2024 年 5 月 30 日正式 GA，同年 11 月再開源 MCP（Model Context Protocol），讓任何工具都能標準化地接進 AI 系統。
換句話說，同一個 AI 模型，接上不同的「工頭」，能做的事就完全不一樣。
一個任務是怎麼完成的
以「幫我比較這兩份文件有哪裡不同」為例，完整走一遍：
第一步：你提問，系統把問題打包送給 AI 包含「你有哪些工具可以用」的說明，以及你的請求。
第二步：AI 輸出它的「點單」
我需要比較工具來讀取這兩份文件
第三步：協調層真正去執行 它呼叫比較工具，讀取檔案，取得差異結果。AI 沒有參與這一步。
第四步：結果送回給 AI AI 現在才看到比較結果，才能告訴你「第三段有一處不同：原文是 A，新版改成了 B」。
整個過程，AI 從來沒有碰過任何檔案。它看到的只有文字——你的問題，以及工具回傳的結果。
用圖來看，整個流程是這樣：
sequenceDiagram
participant 你
participant 工頭 as 工頭（協調層）
participant 建築師 as 建築師（AI）
participant 工具
你->>工頭: 提出任務
工頭->>建築師: 打包問題＋工具清單
建築師->>工頭: 輸出施工圖（JSON）
工頭->>工具: 實際執行
工具->>工頭: 回傳結果
工頭->>建築師: 結果注回，繼續下一步
建築師->>工頭: 下一步施工圖
工頭->>工具: 再次執行
工具->>工頭: 再次回傳
工頭->>建築師: 任務完成，收工
建築師->>工頭: 最終回答
工頭->>你: 交付結果
AI 怎麼處理多個步驟——甚至自己組合工具
有時候現場根本沒有你要的工具。
就像工頭回報「工地沒有吊車」，建築師不是放棄，而是說：「那用滑輪加人力，分兩段吊上去。」這正是 AI agent 最有價值的能力之一——手邊沒有完整工具，自己組合現有的湊出來。
工地有時候會遇到這種狀況：大型升降機故障了，但有一批建材得在今天搬上五樓。
工頭沒有呆站在那裡。他安排兩組人：一組負責把建材用手推車推到樓梯口打包好，一組在五樓架滑索等著。第一組推完一批，回報「樓梯口備好了，八箱」，工頭才叫五樓開始往上吊。吊完回報「收到，全數到位」，才繼續下一批。
沒有升降機，照樣完工。兩個普通動作，組合出同樣的結果。
這正是 AI agent 碰到工具缺口時的做法。Git Bash 環境裡沒有 rsync，AI 不會跟你說做不到——它自己拆成兩步：先用 tar 把檔案打包，再用 scp 傳過去，遠端收到再解開。每一步等回報，確認沒問題才繼續。
關鍵是：這個組合不是事先設計好的，是 AI 看到現場狀況臨時決定的。
整個過程，建築師（AI）和工頭（系統）的對話大概是這樣：
建築師：先把資料打包壓縮
工頭回報：打包完成，512MB
建築師：用 scp 傳到遠端伺服器
工頭回報：傳輸完成
建築師：在遠端把壓縮包解開
工頭回報：解壓完成，資料就位
AI 每次只提出一個動作，等工頭回來說結果，再決定下一步。它不是一開始就把三條指令全部列出來——而是走一步、看一步。
出錯的時候更能看出這個設計的彈性：
工頭回報：scp 傳輸失敗，連線逾時
建築師：先去確認遠端那邊狀況再說
（工頭去查，回報遠端磁碟空間不足）
建築師：清掉舊檔再重傳
這個「遇到問題換策略」的能力，不是工程師寫死的 if/else 邏輯。它是 AI 從海量的人類問答記錄裡訓練出來的直覺——某種意義上，是整個開發者社群的集體經驗被壓縮進了模型裡。
這套「看結果、決定下一步」的循環，有個正式名稱叫 ReAct（Reasoning + Acting），由 Princeton 和 Google Brain 的研究團隊在 2022 年提出，2023 年發表於 ICLR。現在幾乎所有主流 AI agent 框架都以這個架構為基礎。
AI 這套「換策略」的能力從哪裡學來的
簡單說，有三個來源：
少量的人工示範：訓練時，人類示範「遇到這種錯誤要這樣處理」。奠定基本模式，但數量有限。
大量的合成練習：自動產生各種出錯情境，讓 AI 練習回應，再篩選好的答案進訓練資料。這是主要來源。
網路上吸收的集體智慧：GitHub、Stack Overflow、技術論壇上幾十億筆「遇到問題→找到解法」的記錄，全都進了模型的訓練資料。你問 AI 怎麼解決某個問題，它給出的直覺，很可能來自某個十年前在論壇發文的工程師。
這也是為什麼，AI 在常見問題上表現很好，但碰到冷門或從未有人討論過的狀況，就容易出錯——它的知識底子，是人類留下的紀錄。
為什麼要這樣設計
你可能會問：為什麼不讓 AI 直接自己執行，而要這麼繞一圈？
這個「繞一圈」的設計，其實帶來三個很重要的好處：
- 安全性：工頭可以攔截每一個動作、加上確認步驟、限制 AI 能做什麼。Claude Code 每次執行指令前問你「要不要允許」，就是這個機制。
- 靈活性：同一個 AI 模型可以接上不同的工具組合，換工具不需要重新訓練模型。
- 可追蹤性：每一次工具調用都可以記錄下來，方便排查問題。
分離，帶來了控制。
下次看到 AI「做了什麼」，你知道真相了
AI 「查了資料」、「執行了指令」、「讀了你的檔案」——這些描述都沒錯，但背後真正發生的事，是 AI 提出了請求，有個你看不見的系統代為執行，再把結果交回給它。
AI 是那個說「我需要這個」的人，不是那個真正動手的人。
理解了這一點，下次你看到 AI 工具的確認提示、或是某個 AI 功能說「需要連接外部服務」，你就知道那意味著什麼了——那是幕後的「工頭」正在出動。
延伸閱讀
- ReAct 論文：ReAct: Synergizing Reasoning and Acting in Language Models（Yao et al., 2022）
- Anthropic tool use GA 公告：Claude can now use tools（2024 年 5 月 30 日）
- MCP 開源公告：Introducing the Model Context Protocol（2024 年 11 月）
想看更多作品、服務與主站整理，請前往 stanwu.org。