> ## Documentation Index
> Fetch the complete documentation index at: https://data-machi.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Day 12｜什麼是工具使用（Tool Use）？讓 AI 從「回答」開始學會「使用工具」
> 理解工具使用（Tool Use）如何讓模型連接外部系統，以及 LangChain 如何整合模型、提示詞、工具呼叫與訊息格式。框架負責技術整合，但業務邏輯、資料品質與安全邊界仍需由系統設計者負責。
檢索增強生成（RAG）讓 AI 可以查文件，但如果我們希望它取得即時數字、查詢專案狀態，甚至執行一個動作，就需要把外部能力包裝成工具（Tool）。對模型來說，工具可以理解成一組「我可以使用的方法」，每個方法都有清楚的名稱、用途與輸入參數。
例如 `query_google_sheets` 可以接受日期、地區或分類條件，回傳精確計算結果；`search_document_base` 負責從 PDF 找相關內容；`get_trello_cards` 則可以查詢任務狀態。模型不需要知道底層 API 怎麼寫，只需要知道什麼情況應該使用哪個工具，以及要傳入什麼資料。
## 函式呼叫（Function Calling）到底做了什麼？
當模型支援函式呼叫時，我們可以把工具規格提供給它。模型收到問題後，不一定直接生成答案，而是先輸出「我要使用哪個工具，以及需要哪些參數」。程式收到這個決定後，真的去執行函式，再把結果送回模型整理。
這裡有一個非常重要的分工：**模型負責理解意圖，程式負責執行事實。** 例如使用者問平均訂單金額，模型可以判斷需要查 Google Sheets，但最後的加總與除法最好由 Pandas、SQL 或程式完成，而不是讓大型語言模型（LLM）自己算。
## 那 LangChain 又是什麼？
LangChain 可以幫助我們把模型、提示詞（Prompt）、訊息格式、工具與輸出串在一起。它提供很多現成抽象層，讓開發者不需要每次都自己處理函式規格（Function Schema）、工具綁定（Tool Binding）與訊息交換。
但 LangChain 並不是「裝上去就會自動變成代理（Agent）」。資料應該去哪裡查、欄位怎麼定義、什麼情況需要重新查詢，以及哪些動作需要人工確認，這些仍然是產品與工程設計問題。
## 不要把框架當成業務邏輯
框架最有價值的地方，是幫你少寫重複整合程式；最危險的地方，是讓人誤以為只要使用某個代理類別，系統就會自然懂公司的流程。
在 Data Machi 裡，我們會使用框架降低工具整合成本，但關鍵規則仍然會清楚留在程式與工作流程（Workflow）裡。這樣未來就算替換模型或框架，商業邏輯也不會一起消失。
## 進階理解｜一個好工具，至少要說清楚四件事
對非工程背景的讀者，不需要先記 JSON 結構規格（JSON Schema）。只要把工具想成「交給 AI 使用的一項公司能力」，它至少要說清楚：**叫什麼、什麼時候用、需要哪些輸入、會回傳什麼。** 例如 `get_project_status` 如果只描述成「查資料」，協調者（Coordinator）很容易和其他工具混淆；如果明確寫成「當使用者詢問專案目前狀態、負責人與截止日時使用」，分流就會穩定很多。
| 工具要回答的問題 | 例子 |
| ----------------------- | -------------------- |
| 名稱（Name）｜它叫什麼？ | `get_project_status` |
| 用途說明（Description）｜何時使用？ | 查詢專案目前進度與負責人 |
| 參數（Parameters）｜需要什麼？ | 專案名稱或 ID |
| 回傳結果（Return）｜會得到什麼？ | 狀態、負責人、截止日、來源 |
LangChain 的價值主要是幫忙統一模型、訊息與工具的接法，降低不同 API 之間的整合成本。它不會替你決定公司的正確流程、資料定義與安全邊界。可以把它想成「轉接層」：讓不同零件比較容易接起來，但產品要解決什麼問題、哪些步驟不能出錯，仍然需要另外設計。
今天先記住一件事：工具使用（Tool Use）的核心是讓模型「選擇能力」，但真正的資料查詢、計算與操作仍由程式執行；LangChain 是整合工具箱，不是業務流程本身。
下一篇，我們會實際加入第一個結構化資料工具，讓 Data Machi 可以查 Google Sheets，而且所有數字都由程式精確計算。