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）很容易和其他工具混淆；如果明確寫成「當使用者詢問專案目前狀態、負責人與截止日時使用」，分流就會穩定很多。
延伸閱讀：LangChain 比較像轉接層（Middleware），不是 AI 大腦
延伸閱讀：LangChain 比較像轉接層（Middleware），不是 AI 大腦
LangChain 的價值主要是幫忙統一模型、訊息與工具的接法，降低不同 API 之間的整合成本。它不會替你決定公司的正確流程、資料定義與安全邊界。可以把它想成「轉接層」：讓不同零件比較容易接起來，但產品要解決什麼問題、哪些步驟不能出錯，仍然需要另外設計。
今天先記住一件事：工具使用（Tool Use）的核心是讓模型「選擇能力」，但真正的資料查詢、計算與操作仍由程式執行；LangChain 是整合工具箱，不是業務流程本身。