Hello folks，我是 Luga，今天我們來聊一下人工智能應用場景落地 - 如何為 LLM 集成選擇合適的策略？

眾所周知，大型語言模型（LLMs）已經徹底改變了企業自動化、客戶交互以及決策制定的方式，其強大的語言生成能力為各行業帶來了前所未有的機遇。然而，要充分發揮 LLMs 的潛力，僅僅部署一個預訓練模型是遠遠不夠的。企業需要在實際應用中將 LLMs 無縫集成到現有系統中，確保其在釋放創造力的同時，能夠保持輸出的可控性；在提供靈活性的同時，兼顧結構的嚴謹性；在推動創新的同時，確保系統的穩定性和可靠性。

然而，這種集成并非易事。LLMs 的輸出通常具有一定的隨機性和不可預測性，如何在滿足業務需求的同時對其進行有效控制和結構化，成為企業在實際部署中面臨的最大挑戰之一。

隨著技術的發展，兩種主流的解決方案逐漸浮現：函數調用（Function-Calling）和模型上下文協議（Model Context Protocol，簡稱 MCP）。這兩種方法雖然都旨在提升 LLMs 的可預測性和生產就緒狀態，但它們在設計理念、實現方式和適用場景上有著顯著差異。深入理解這些差異，不僅有助于企業在集成 LLM s時做出明智的技術選擇，還能為構建更高效、更可靠的智能系統奠定基礎。

一、如何理解 Function Calling ？

眾所周知，LLMs 本質上是一種生成式技術，其核心優勢在于能夠生成富有創意且高度契合上下文的輸出。這種特性使得 LLMs 在諸多任務中表現出色，例如，進行生成代碼片段，或是參與開放式的對話互動。無論是用于提升工作效率還是優化用戶體驗， LLMs 的創造力都展現了巨大的潛力。

然而，在企業環境中，這種生成能力卻往往是一把雙刃劍。企業通常需要的是可預測、結構化的輸出，以確保其與特定的業務流程、監管要求或品牌規范保持一致，而 LLMs 的自由生成特性可能難以完全滿足這些需求。

那么，該如何理解“函數調用（Function-Calling）”？

本質上而言，無碼可以一句話概括：為特定任務提供結構化輸出。

通常而言，函數調用是一種廣受歡迎的 LLM 集成方法，其核心在于通過定義明確的函數簽名，約束模型生成符合預設接口的結構化響應。通過這種方式，LLMs 的輸出可以被精確地引導，從而更輕松地融入現有的企業系統，滿足業務場景對一致性和規范化的要求。

作為一種更直接的機制，通常嵌入在大型語言模型（LLM）內部，Function Calling 用于在模型生成響應時動態調用外部函數或 API。其主要涉及如下組件：

• 用戶：發起查詢。
• 大型語言模型（LLM）：直接解析查詢，決定是否需要調用函數，并生成響應。
• 函數聲明：預定義的外部函數接口（如天氣API的調用方式）。
• 外部API：提供具體數據或服務。

以下是一個 OpenAI 函數調用的 JSON 定義示例，用于獲取指定地點的當前天氣信息，具體可參考如下：

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "獲取指定地點的當前天氣信息",
    "parameters": {
      "type": "object",
      "properties": {
        "location": {
          "type": "string",
          "description": "城市名稱，例如：香港、臺北"
        },
        "unit": {
          "type": "string",
          "enum": ["celsius", "fahrenheit"],
          "description": "溫度單位"
        }
      },
      "required": ["location"]
    }
  }
}

在實際的業務場景中，在函數調用的框架下，開發者首先需要創建一組具有明確輸入和輸出參數的函數。當用戶與 LLM 進行交互時，模型會根據用戶的輸入內容，智能地識別出需要調用的函數，并生成符合該函數預期格式的響應。例如，函數可能要求返回一個特定的數據類型（如字符串或 JSON 對象），而 LLM 則被限制在這一范圍內生成輸出。    

因此，此種方法特別適合那些需要精確、結構化數據的任務，例如數據提取、分類或外部 API 調用等相關場景。

二、如何理解 Model Context Protocol (MCP) ？

盡管函數調用（Function-Calling）在處理結構化任務時表現出色，但模型上下文協議（Model Context Protocol，簡稱 MCP）則采用了完全不同的設計思路。

作為一種分層式技術，通過系統性地組織上下文和提示，MCP 為大型語言模型（LLM）提供更加靈活且可控的交互方式。相較于函數調用的剛性約束，MCP 更擅長處理復雜、多步驟的對話場景，尤其是在需要維持上下文連貫性和動態適應用戶需求的場景中，其優勢尤為明顯。

通常情況下，MCP 的設計更偏向于模塊化和分布式系統，強調清晰的流程控制和中間狀態管理。其主要涉及如下核心組件：

• 用戶：發起查詢（如“香港的天氣如何？”）。
• MCP Client：接收用戶查詢，協調工具選擇和任務分配。
• MCP Server：執行具體的工具調用（如調用天氣API）。
• LLM（大型語言模型）：處理自然語言，生成最終輸出。
• 工具（Tools）：外部 API 或其他功能模塊（如天氣API）。

以下是一個使用 MCP 框架實現的簡易服務器示例，用于獲取指定地點的天氣信息，具體代碼可參考如下：     

from mcp import MCPServer, Tool, Parameter


# 初始化MCP服務器
server = MCPServer()


@server.tool
class WeatherTool(Tool):
    """用于獲取指定地點天氣信息的工具"""


    @server.function
    def get_weather(self, location: Parameter(descriptinotallow="城市名稱"), 
                   unit: Parameter(descriptinotallow="溫度單位", default="celsius")):
        """獲取指定地點的當前天氣"""
        # 調用天氣API的實現（此處為模擬數據）
        return {"temperature": 22, "condition": "晴天", "humidity": 45}


# 啟動服務器
server.start()

在實際的場景中，MCP 的核心在于通過分層的方式分解和組織交互過程。每一層上下文都為 LLM 提供了特定的指令、約束條件或背景信息，從而在模型生成響應時，既能保持其創造性，又能確保輸出與業務目標高度契合。

具體來說，MCP 的每一層可能包含不同的信息模塊，例如任務目標、用戶背景、業務規則或歷史對話記錄。模型在生成響應時，會綜合考慮所有上下文層的信息，確保輸出的準確性和相關性。這種分層設計不僅為模型的行為提供了清晰的引導，還避免了過度限制其生成能力，使得 LLM 能夠在復雜場景中展現更高的靈活性和智能性。

三、MCP & Function Calling 設計理念差異性解析

1. MCP 設計理念：模塊化、分布式與可控的智能任務執行框架

模塊化與分布式架構：MCP 將任務劃分為多個獨立模塊（如 Client、Server、LLM、Tools ），每個模塊專注于特定功能。這種設計方式非常適合分布式系統，能夠支持多個組件的協同工作，確保任務的高效完成。

中間狀態管理：MCP 在每個處理步驟（例如工具選擇、API 調用、數據處理）中都實現了明確的狀態管理。這種管理方式有助于調試過程中的問題定位，并且能夠有效進行錯誤處理。

安全性與控制：MCP 引入了“ API 請求審批”等安全控制機制，以增強系統的安全性和可控性，從而使得 MCP 特別適用于需要嚴格權限管理和高安全要求的應用場景。

2. Function Calling 設計理念：集成化、模型驅動與輕量級的功能擴展方案

集成化與高效性：Function Calling 將函數調用邏輯直接嵌入 LLM 中，從而簡化了系統架構并減少了中間層。這種設計有助于提高系統的響應速度，并且適用于需要快速響應和高效執行的簡單任務。

模型驅動：在 Function Calling 中，LLM 扮演著核心角色，負責從解析用戶查詢到生成響應的整個過程。該設計依賴于大型語言模型的智能能力，能夠理解函數聲明并基于此提供精確的功能調用。

輕量級架構：由于去除了復雜的中間層，Function Calling 顯得更加輕量，適合嵌入式系統或單體應用，能夠減少系統復雜度并提高維護效率。

四、MCP vs Function Calling，該如何選 ？

函數調用（Function-Calling）和模型上下文協議（MCP）作為兩種主流的大型語言模型（LLM）集成方法，各有其獨特的應用場景和優勢。它們并非互相替代，而是互為補充，能夠在不同的業務需求和技術環境中發揮各自的價值。理解兩者的適用場景，不僅有助于企業在 LLM 集成時做出明智的選擇，還能為構建高效、可靠的智能系統提供清晰的指導方向。

那么，在實際的業務場景中，如何決策呢？

以下是關于如何選擇 Function-Calling 或 MCP 的詳細建議，并探討如何結合兩者以實現更優的解決方案。

1. 使用 Function-Calling 的場景

Function-Calling 以其結構化和高效的特點，成為許多特定任務的首選方法。以下是其適用的典型場景，具體可參考：

• 需要結構化、可預測的輸出：當任務對輸出的格式和內容有嚴格要求時，函數調用能夠通過預定義的函數簽名，確保 LLM 生成的結果始終符合預期。例如，在需要返回固定格式的 JSON 數據時，函數調用可以有效約束模型行為。
• 任務邊界清晰且需要特定數據格式：對于那些目標明確、數據格式固定的任務，函數調用表現出色。例如，在數據提取任務中，模型可能需要從文本中提取日期、金額等信息，并以特定格式（如“YYYY-MM-DD”）返回。
• 目標是將 LLM 無縫集成到現有系統：函數調用天然契合傳統的軟件架構，能夠通過明確的接口（如 API ）將 LLM 嵌入到企業系統中。例如，在一個需要調用外部服務的場景中，函數調用可以直接映射到 API 請求。

典型案例：

• 數據提取：從用戶提交的文本中提取關鍵信息，如提取訂單號或用戶信息。
• 工單分類：如前文所述，將客戶支持工單分類為“賬單問題”或“技術支持”。
• API 集成：通過調用天氣 API 獲取實時天氣數據，并以結構化格式返回。

在上述這些場景中，Function-Calling 能夠以較低的開發成本和較高的可控性，快速滿足業務需求。

2. 使用 MCP 的場景

相比之下，MCP 以其靈活性和上下文管理能力，更適合復雜、多步驟的交互場景。以下是其適用的典型場景：

• 涉及復雜、多步驟的交互：當任務需要跨越多個步驟，且每個步驟可能依賴于前一步的結果時，MCP 的分層上下文管理能夠確保對話的連貫性和邏輯性。例如，一個智能助手可能需要先確認用戶需求，再調用相關服務，最后生成總結性建議。
• 需要長時間維持上下文：在長時間對話或多輪交互中，MCP 通過分層上下文管理，確保模型能夠記住歷史信息并生成上下文相關的響應。例如，在客戶支持場景中，MCP 可以幫助模型追蹤用戶之前的提問，避免重復或矛盾的回答。
• 任務需要在創造力與控制力之間取得平衡：MCP 允許模型在保持一定創造力的同時，受到上下文約束的引導，適合需要在開放性與規范性之間找到平衡的場景。例如，在品牌化的對話中，模型需要既展現自然語言的流暢性，又遵守品牌規范。

典型案例：

• 特定領域智能助手：如金融領域的合規性助手，需要在多輪對話中提供符合監管要求的建議。
• 監管合規工具：確保模型輸出符合行業法規，例如醫療領域的隱私保護要求。
• 品牌化聊天機器人：在保持品牌聲音一致性的同時，參與自然、開放式的對話。

在上述的這些類似場景中，MCP 的靈活性和上下文感知能力能夠顯著提升交互質量，滿足復雜業務需求。

然而，在實際的業務場景中，可能面臨某些復雜的應用，單獨使用 Function-Calling 或 MCP 可能無法完全滿足需求。此時，結合兩種方法可以充分發揮它們的優勢，同時彌補各自的局限性，形成更強大的混合解決方案。

例如，在一個客戶支持系統中，可以通過以下方式結合兩者：

Function-Calling 用于工單分類：利用 Function-Calling 的結構化特點，快速將用戶提交的工單分類為“賬單問題”或“技術支持”，確保分類結果的準確性和一致性。

而 MCP 用于后續問答和上下文管理：在工單分類后，用戶可能會提出進一步的問題（如“如何解決賬單問題？”）。此時，MCP 可以通過分層上下文管理，追蹤之前的對話內容，生成連貫且個性化的回答，同時確保響應符合品牌規范。

這種混合方法能夠在不同階段發揮各自的優勢：Function-Calling 確保了關鍵任務的效率和可控性，而 MCP 則增強了對話的靈活性和上下文連貫性。通過合理設計，開發者可以在系統架構中無縫集成這兩種方法，例如在函數調用完成后將結果傳遞給 MCP 的上下文層，用于后續處理。

綜上所述，Function-Calling 和 MCP 各有其擅長的領域，選擇哪種方法取決于具體的業務需求和技術目標。

如果任務需要高度結構化的輸出和快速集成，Function-Calling 是更優的選擇；如果任務涉及復雜交互、長時間上下文管理或需要在創造力與控制力之間取得平衡，MCP 則更具優勢。而在一些綜合性場景中，結合兩者可以實現更高的效率和靈活性，為 LLM 的實際應用提供更全面的解決方案。企業在選擇時，應充分評估任務的復雜性、系統架構的兼容性以及對可控性和創造力的需求，以確保最終方案能夠最大化地滿足業務目標。