前言

（首先，我要正式宣布：RAG 篇休刊，開新坑，MCP 篇開始）

過去在做 Function Calling 的時候，我一直在想：如果我要讓 Agent 查天氣，我要寫一段程式；如果我要讓她去讀 Google 日曆，我又得寫一段程式。

這就像是遊戲裡某個角色的獨門絕技，只有他能用，換成其他人（別的模型或別的專案）都用不了，完全是專屬硬編碼（Hard-coding）。

而 MCP (Model Context Protocol)，概念完全不一樣！它比較像是 遊戲主機的卡帶插槽。只要主機有這個卡帶槽（支援 MCP 協定），不管插進去的是哪一款遊戲，主機都能直接讀取來玩，不用為了每一款遊戲去重新改造主機板。

今天停下來把這兩者的本質釐清，才不會在後續開發「外掛手套」時走錯方向。

今天的輕量目標：

1. 理解 Function Calling（用「角色專屬技能」來比喻）
2. 搞懂 MCP (Model Context Protocol)（用「卡帶插槽」來比喻）
3. 規劃陪伴 Agent 的工具擴充策略（核心邏輯 vs. 外部外掛）

第一關：傳統 Function Calling：角色的「專屬綁定招式」

「Function Calling 是讓模型能以結構化方式請求外部函式／工具的一種能力。」

• 運作機制：我們在 Python 裡寫好一個 get_weather()，然後在給 Gemini 的 Prompt 裡寫清楚它的名字與參數格式。Gemini 看懂後，回傳一串 JSON 說：「請幫我執行 get_weather(location='Taipei')」。
• 遊戲比喻：角色專屬的綁定技能。
• 優點：非常直覺且輕量！要處理莉莉的好感度加減（FSM）、ChromaDB 記憶讀取這種專屬於我們專案的內部邏輯，用 Function Calling 速度最快。
• 致命缺點：這是點對點綁死的！如果哪天我們要把莉莉的底層模型從 Gemini 換成別家，或是想把這個氣象工具移植到另一個陪伴 Agent 專案，可能就要把這些工具代碼通通重新包裝一次。

第二關：MCP (Model Context Protocol)：萬能插拔的「通用裝備」

MCP 不是某個模型的專屬功能，而是一種跨系統的「通訊標準 (Protocol)」。

• 運作機制：社群或官方會把某些功能包裝成獨立運作的「MCP Server」（例如 GitHub MCP Server、Google Drive MCP Server）。而我們的莉莉 Agent 只需要擔任「MCP Client」，透過標準化的語言跟 Server 對話。
• 遊戲比喻：主機的卡帶插槽。只要介面符合，換上一個新工具（卡帶）就能立刻使用，完全不需要自己手寫 def get_weather()。
• 核心優勢：
  • 隨插即用（Plug and Play）：不需要為了新工具重新造輪子。
  • 生態系共用：不論是哪個編輯器、桌面 App 還是我們自己寫的莉莉 Agent，只要支援 MCP，大家就能共享同一套開源工具集！

第三關：兩者核心差異懶人包

• 本質層面：Function Calling 是模型與外部函式／工具之間的結構化呼叫機制；MCP 則是跨系統的標準通訊協定。
• 比喻說明：Function Calling 就像專屬的角色必殺技，換人就不能用；MCP 就像卡帶，任何一台主機插上去都能直接讀取。
• 維護成本：Function Calling 每個工具都要自己用 Python 包裝；如果已有合適的 MCP Server，可以直接重用既有工具整合，降低重複開發成本。
• 適合場景：涉及專案核心隱私與客製邏輯（如 FSM 好感度、個人記憶）用 Function Calling；需要連接龐大的外部服務（如 GitHub、Notion、Slack）選 MCP。