昨天我們把 Agentic AI 想成一次大掃除，也替 Agent、Tool、MCP、RAG 與 Human-in-the-loop 找到各自的位置。
其中有一個名詞是：
Function Calling：領班填好工單，請真正會操作工具的人來處理。
今天就把這張工單攤開來看。不過先說結論：如果你只是在使用 ChatGPT、Claude 或 Gemini，通常不需要自己寫 Function，也不需要盯著 JSON 檢查每一格。一般人仍然是用自然語言工作，Function Calling 多半發生在產品背後。
那為什麼還要知道它？
因為當 AI 從「回答問題」變成「查資料、讀檔案、寄信或修改行事曆」，你需要知道它究竟做了什麼、你的指令能影響多少，以及什麼時候應該先踩煞車。
到目前為止，我們談的大語言模型，本質上仍然很會根據 Context 產生下一個 Token。如果你請它：
這些工作所需的內容已經在 Context 裡，模型通常可以直接回答。
但有些事情只靠生成文字做不到：
模型可以生成一句「信件已寄出」，但句子寫得再像物流通知，也不代表信真的離開寄件匣。當任務需要外部資料或要對外部世界採取行動時，背後就需要搜尋、API、資料庫或其他工具。
Function Calling 是模型與這些工具合作的方法之一。
多數時候，一般使用者看不到原始的函式名稱、JSON 參數與工具回傳值。那比較像廚房裡的工作單，不一定要貼到餐桌上。
使用者通常會從介面看到幾種線索：
介面顯示多少細節，由產品設計決定。有些產品會清楚列出正在使用的工具，有些只顯示簡短狀態，也有些把整個流程藏在回答背後。因此，「畫面沒有 JSON」不代表沒有工具；反過來，模型說「我已經處理好了」也不能單獨證明工具真的執行成功。
對一般使用者來說，重要的不是背下 function 名稱，而是看見來源、權限、確認與結果。
會，但不是你說了就算。
可以把工具選擇想成三層：
如果產品沒有連接天氣、Email 或行事曆工具，你再怎麼說「請務必呼叫行事曆 Function」，模型也不會憑空長出一個 Google Calendar 帳號。
平台或開發者會先決定：
這是使用者指令不能跨越的硬邊界。
開發者可以讓模型自行判斷是否使用工具，也可以要求這一輪一定要用、禁止使用，或只能使用某個指定工具。不同平台的設定名稱不完全相同，但核心都是限制模型的選擇範圍。
在可用工具與權限範圍內，你的指令會影響模型是否使用工具。例如：
這些句子不是在寫 Function，而是在告訴 AI：資料要從哪裡來、可以做到哪一步、哪裡要停下來等人類決定。
因此，使用者指令會影響工具使用，但工具是否存在、是否允許執行，以及產品是否接受這項指令，仍由系統設計與權限決定。自然語言是方向盤，不是萬能通行證。
這取決於你使用的是現成產品，還是自己開發的應用。
| 情境 | 使用者要做什麼 | 背後由誰處理工具 |
|---|---|---|
| 使用 ChatGPT 等現成產品 | 用自然語言提出需求，必要時授權或確認 | 產品已整合的工具與平台流程 |
| 使用公司內部 AI 系統 | 提出需求並遵守公司權限與確認流程 | 公司開發者預先接好的工具 |
| 自己開發 AI 應用 | 定義工具、權限、執行方式與錯誤處理 | 自己的程式與外部服務 |
以網頁搜尋為例，現成 AI 產品可能已經把「決定搜尋、送出查詢、取得結果、整理來源」包在產品裡。使用者只看到搜尋狀態和最後的引用，不需要自己寫搜尋 Function。
但如果你要讓 AI 查詢實驗室內部資料、控制自己設計的設備，或操作公司特有的工作流程，現成產品不會知道該怎麼做。這時才輪到開發者自己定義工具。
比較精確的流程是：
模型根據使用者要求與可用工具，提出工具名稱和參數；真正執行操作的，通常是外部應用程式。
假設系統提供一個天氣工具：
get_weather(location)
使用者問：
今天台北適合帶傘嗎？
模型可能產生一張概念化的工單：
{
"name": "get_weather",
"arguments": {
"location": "Taipei"
}
}
接著由應用程式呼叫天氣服務，把結果交回模型。模型最後才整理成：
台北今天降雨機率約 80%，建議帶傘。除非你剛好想測試新買的狗鐵絲(GORE-TEX)外套。
完整流程是：
使用者提出需求 → 模型選擇工具與參數 → 應用程式執行 → 工具回傳結果 → 模型整理回答
少了「應用程式執行」，Function Calling 只是一張字跡工整、但始終沒有人處理的工單。OpenAI 的官方文件也把 Tool Calling 描述為模型與應用程式之間的多步驟往返，而不是模型單方面完成所有操作。
圖片來源：Google AI for Developers：使用 Gemini API 呼叫函式
不同平台使用的名稱略有差異：OpenAI 常稱 Function Calling 或 Tool Calling，Anthropic 常稱 Tool Use。訊息格式不完全相同，但核心概念接近：
先讓模型知道有哪些工具，再由模型提出工具請求，外部系統執行後把結果交回模型。
如果只是使用現成 AI 產品，可以先停在這裡。後面的內容不是每個人都會碰到，而是給想把 AI 接到自己系統的人一張簡圖。
你通常會在以下情況自己寫 Function Calling：
開發者首先要提供工具說明，通常包括名稱、用途、參數與必填欄位。以下是概念化簡寫；不同 API 的完整外層格式會不同：
{
"name": "create_calendar_event",
"description": "在使用者的行事曆中建立活動",
"parameters": {
"type": "object",
"properties": {
"title": { "type": "string" },
"start_time": { "type": "string" },
"duration_minutes": { "type": "integer" }
},
"required": ["title", "start_time", "duration_minutes"]
}
}
工具說明要讓模型知道「什麼時候用」與「參數代表什麼」。如果只把工具命名為 do_it，說明寫成「做事情」，模型不知道你是要它排會議、查天氣還是發射火箭，不能完全怪它沒有讀懂空氣。
接下來的最小流程是：
1. 開發者把可用工具與使用者要求交給模型
2. 模型回傳工具名稱與參數
3. 應用程式驗證權限與參數
4. 應用程式執行工具
5. 應用程式把結果交回模型
6. 模型產生最後回答，或提出下一個工具請求
AI 可以協助你產生 schema、串接 API 與撰寫程式碼，但有人仍要決定權限、驗證條件、錯誤處理與高風險操作的確認方式。叫 AI 幫忙蓋橋沒有問題，只是橋蓋完還是要驗收，不能因為程式碼縮排很整齊就直接剪綵通車。
如果模型只是把天氣講錯，我們可能白帶一把傘；但如果它能寄信、付款、刪除檔案或修改資料庫，錯誤參數就不只是小尷尬。
可靠的系統還需要：
例如使用者說：
幫我刪掉昨天建立的測試檔案。
系統應該先列出符合條件的檔案並要求確認，而不是看到「刪掉」兩個字，就立刻展現超乎預期的工作熱情：
你確定是這 347 個檔案嗎？
一般使用者不需要閱讀每一筆 Function Call，但需要知道如何判斷 AI 是否真的完成工作：
進階的測試可以到day06_practice.ipynb
而對開發者來說，Function Calling 真正改變的也不是讓模型突然變成萬能，而是替自然語言與外部系統之間建立一套合作方式。
所以，AI 從「會說」走向「會做」時，使用者不必跟著進廚房看每張工單，但至少要知道：端上桌的菜究竟真的煮過，還是模型只寫了一份讀起來很香的菜單。
明天，我們就來看看這些工具工單為什麼經常長得像 JSON，以及 Markdown、JSON、YAML 與 HTML 分別在 AI 工作流程中扮演什麼角色。
參考資料
iThome鐵人賽
看影片追技術