https://yennj12.js.org/yennj12_blog_V4/tags/function-calling/Recent content in Function Calling on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 21 Jun 2026 21:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase13-part1-mcp-apis-zh/Sun, 21 Jun 2026 21:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase13-part1-mcp-apis-zh/大多數人把 LLM 接上 API，然後祈禱模型不要亂呼叫。 正確做法是：設計工具邊界，讓模型只能做它該做的事。 差別不在「能不能呼叫」，而在「呼叫錯了有沒有圍欄」。 工具整合的本質，是在 LLM 的智能與外部世界的副作用之間建立可審計的閘門。 面試情境：你正在設計一個 AI 客服代理，需要讀取訂單資料庫、發送退款請求、查詢物流狀態。系統每日處理 5 萬通查詢，P99 回應要在 3 秒內。你怎麼設計工具層的架構，同時確保安全性與可觀測性？ 一、核心問題：LLM 如何安全地操作外部世界 純語言模型是無狀態的文字轉換器，它不知道今天幾號，不知道訂單狀態，也無法真正寄出一封信。但產品需求要求 AI 能夠「做事」，不只是「說話」。 這個落差催生了工具使用（Tool Use）這個範式。但工具使用帶來的不只是能力擴展，更帶來三個深層工程挑戰： 挑戰一：副作用不可逆性 模型呼叫 send_email() 後，信就出去了。模型呼叫 delete_record() 後，資料就消失了。不像純 LLM 呼叫可以重試，帶有副作用的工具呼叫必須有 idempotency 保護和操作審計。 挑戰二：工具定義爆炸 一個企業 AI 代理可能需要整合 30+ 個內外部 API。每個工具的參數 Schema 、認證方式、錯誤處理各不相同。沒有標準化協議，工具層會變成難以維護的義大利麵程式碼。 挑戰三：提示注入攻擊 當工具的輸出結果（如網頁內容、資料庫紀錄）重新進入 LLM 上下文時，惡意內容可以偽裝成工具結果，誘導模型執行非預期的指令——這是 AI 系統特有的 injection 攻擊面。 MCP（Model Context Protocol）的出現，正是為了系統性地解決這三個問題。 二、三個演進階段 Phase 1：POC（< 5K 用戶，單一工具） ╔══════════════════════════════════════════╗ ║ Phase 1：直接呼叫 API（POC 階段） ║ ╚══════════════════════════════════════════╝ 用戶輸入 │ ▼ ┌────────────┐ Function ┌──────────────────┐ │ LLM API │─────Calling────▶│ 直接呼叫外部 API │ │ (GPT-4o) │◀────結果────────│ (requests 庫) │ └────────────┘ └──────────────────┘ │ ▼ 回應輸出 特徵： - 工具定義寫死在 system prompt - 無認證管理，API key 硬編碼 - 無錯誤重試，失敗直接拋例外 - 無日誌，難以除錯 適合場景：內部 Demo、單一 API 的 Chatbot