【沒有統一標準的時代】
諾基亞 → 圓口充電器
三星   → 扁口充電器  
蘋果   → Lightning
華為   → Micro USB
出門帶 4 根線，煩死了！

【有了 Type-C 標準後】
所有手機 → Type-C
一根線走天下！

【沒有 MCP 的 AI 世界】
高德地圖 API   → REST + 自定義認證
天氣查詢 API   → GraphQL + API Key
數據庫查詢     → SQL + 專用驅動
發送郵件       → SMTP + OAuth
每個工具都要單獨對接，累死了！

【有了 MCP 標準後】
所有工具 → 統一的 MCP 協議
一套規範接所有！

MCP ≠ 新的 AI 技術
MCP = 工具調用的標準化協議
底層還是 Function Call，只是把接口規範統一了

需求：做一個能回答"我的訂單什麼時候到？"的 AI 客服
需要對接：
├── 內部訂單系統 (REST API)
├── 順豐物流 (SOAP XML)
├── 京東物流 (gRPC)
└── 企業微信 (自定義協議)

你的需求是什麼？
    ├─→ 操作本地文件/數據庫？ ──→ 用 STDIO
    │     └─ 例：文件搜索、SQLite 查詢
    └─→ 調用遠程服務/API？ ──→ 用 SSE
          └─ 例：高德地圖、天氣 API、團隊共享工具

如果你的項目：
- 工具就幾個，都是自己的 API
- 一個人開發，不需要團隊協作
- 對工具調用有深度定製需求

→ 直接用 Function Call 更合適

如果需要快速接入：
- 高德地圖、天氣這類現成服務
- 開源社區的 MCP Server

→ MCP 能省不少事

┌──────────────────────────────────────────────┐
│              智能客服系統                     │
├──────────────────────────────────────────────┤
│  核心業務（自己實現 Function Call）           │
│  ├── 查訂單狀態 ← 自己的數據庫                │
│  ├── 查庫存信息 ← 自己的庫存系統              │
│  └── 處理退款 ← 核心業務邏輯                  │
├──────────────────────────────────────────────┤
│  通用能力（用 MCP 快速接入）                  │
│  ├── 地圖導航 ← 高德 MCP                      │
│  ├── 天氣查詢 ← 天氣 MCP                      │
│  └── 發郵件/短信 ← 通知 MCP                   │
└──────────────────────────────────────────────┘

┌─────────────────────────────────┐
│            MCP 協議             │  ← 標準化的接口規範
│  ┌─────────────────────────┐   │
│  │     Function Call       │   │  ← 底層核心能力
│  │   (AI 的工具調用能力)     │   │
│  └─────────────────────────┘   │
└─────────────────────────────────┘

// 1. 自己定義工具格式
const tools = [{
  name: "get_weather",
  description: "查詢天氣",
  parameters: {
    type: "object",
    properties: {
      city: { type: "string", description: "城市名" }
    }
  }
}]

// 2. 調用 AI，讓它決定是否用工具
const response = await openai.chat.completions.create({
  model: "gpt-4",
  messages: [{ role: "user", content: "北京天氣怎麼樣" }],
  tools: tools
})

// 3. 自己解析 AI 返回的工具調用
if (response.tool_calls) {
  const args = JSON.parse(response.tool_calls[0].function.arguments)
  // 4. 自己調用真實的天氣 API
  const weather = await fetch(`https://api.weather.com?city=${args.city}`)
  // 5. 把結果返回給 AI 生成最終回覆
}

// 只需配置一個 MCP Server
{
  "mcpServers": {
    "weather": {
      "url": "https://mcp.weather.com/sse"
    }
  }
}

【Function Call 流程】（自己實現）
用户 → AI → 你的代碼解析 → 你調用 API → 你返回結果 → AI 生成回覆
         ↑                                             ↑
         └──────── 全都要自己寫 ─────────────────────────┘

【MCP 流程】（標準化）
用户 → AI → MCP Client → MCP Server → 真實 API
         ↑       ↑            ↑
         │       │            └── 按協議暴露工具（別人寫好的）
         │       └── 按協議調用（框架處理）
         └── 還是 Function Call（只是被封裝了）

選擇 Function Call（自己實現）：
├── 工具數量少（1-3個）
├── 需要深度定製邏輯
├── 對調用過程要完全掌控
└── 不需要和別人共享

選擇 MCP：
├── 需要快速接入多個第三方服務
├── 團隊協作，需要統一規範
├── 想複用社區已有的 MCP Server
└── 項目規模大，工具多

Function Call = 自己組裝電腦
  - 完全掌控每個零件
  - 但每台都要從頭組裝

MCP = 買品牌整機 + 標準配件
  - 插上就能用
  - 但底層還是那些零件

你：北京現在幾度？
AI：抱歉，我無法獲取實時天氣信息，建議你查詢天氣網站...

你：北京現在幾度？
AI：（內心活動：這個問題需要查天氣，我調用一下天氣工具）
    → 調用 get_weather(city="北京")
    → 獲得結果：15°C，晴
AI：北京現在 15°C，天氣晴朗。

第 1 步：用户提問       
用户："北京今天天氣怎麼樣？"       
        ↓
第 2 步：AI 分析 + 決策      
AI 收到問題，同時看到可用工具列表：      
　　可用工具：    
　　├── get_weather(city) - 查詢天氣                
　　├── send_email(to, content) - 發郵件            
　　└── search_web(keyword) - 搜索網頁            
AI 判斷：這是天氣問題 → 應該用 get_weather        
AI 輸出：調用 get_weather，參數 city="北京"    
        ↓
第 3 步：執行函數              
你的代碼接收到 AI 的"指令"：       
 {                                                          
　　 "function": "get_weather",                              
　　 "arguments": { "city": "北京" }                       
 }          
然後調用真實的天氣 API，獲得結果：{ "temp": "15°C", "weather": "晴", "wind": "北風3級" }   
        ↓
第 4 步：結果返回給 AI          
把天氣數據塞回對話："工具執行結果：北京，15°C，晴，北風3級"  
        ↓
第 5 步：AI 生成最終回覆
AI 根據工具返回的數據，組織自然語言回覆："北京今天天氣晴朗，氣温 15°C，有北風 3 級，適合户外活動，記得帶件薄外套哦~"

// 1️⃣ 定義工具（告訴 AI 有什麼能力可用）
const tools = [{
  type: "function",
  function: {
    name: "get_weather",
    description: "查詢指定城市的實時天氣",
    parameters: {
      type: "object",
      properties: {
        city: { 
          type: "string", 
          description: "城市名稱，如：北京、上海" 
        }
      },
      required: ["city"]
    }
  }
}]

// 2️⃣ 調用 AI（帶上工具列表）
const response = await openai.chat.completions.create({
  model: "gpt-4",
  messages: [{ role: "user", content: "北京天氣怎麼樣" }],
  tools: tools  // ← 告訴 AI 可以用這些工具
})

// 3️⃣ AI 返回的不是文字，而是"調用指令"
// response.choices[0].message.tool_calls = [{
//   function: {
//     name: "get_weather",
//     arguments: '{"city": "北京"}'
//   }
// }]

// 4️⃣ 你來執行真實調用
const args = JSON.parse(response.choices[0].message.tool_calls[0].function.arguments)
const weatherData = await 調用真實天氣API(args.city)

// 5️⃣ 把結果喂回 AI，讓它生成最終回覆
const finalResponse = await openai.chat.completions.create({
  model: "gpt-4",
  messages: [
    { role: "user", content: "北京天氣怎麼樣" },
    { role: "assistant", tool_calls: [...] },
    { role: "tool", content: JSON.stringify(weatherData) }  // ← 工具結果
  ]
})

// 最終得到自然語言回覆
console.log(finalResponse.choices[0].message.content)
// → "北京今天 15°C，天氣晴朗，適合出行~"

顧客（用户）    ："我要一份宮保雞丁"
服務員（AI）   ：理解需求，寫菜單
              → 下單：宮保雞丁 × 1
廚房（你的代碼）：收到訂單，真正去做菜
              → 返回：一盤宮保雞丁
服務員（AI）   ：把菜端給顧客，説"您的菜好了"

// 好的描述
description: "查詢指定城市的實時天氣，返回温度、天氣狀況、風力等"

// 差的描述
description: "天氣"  // AI 可能搞不清什麼時候該用

┌─────────────┐          ┌─────────────┐
│    大腦      │  ──────► │    手腳     │
│    (AI)     │    指令   │  (你的代碼)  │
└─────────────┘          └─────────────┘
     │                         │
     │ 理解 + 決策              │ 執行 + 返回
     ↓                         ↓
  "要查天氣"               真的去查天氣
= 讓 AI 從"只會説"升級到"能指揮幹活"