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

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

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

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

一、如何理解 Function Calling ？

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

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

那么，該如何理解“函數(shù)調(diào)用（Function-Calling）”？

本質(zhì)上而言，無碼可以一句話概括：為特定任務(wù)提供結(jié)構(gòu)化輸出。

通常而言，函數(shù)調(diào)用是一種廣受歡迎的 LLM 集成方法，其核心在于通過定義明確的函數(shù)簽名，約束模型生成符合預(yù)設(shè)接口的結(jié)構(gòu)化響應(yīng)。通過這種方式，LLMs 的輸出可以被精確地引導(dǎo)，從而更輕松地融入現(xiàn)有的企業(yè)系統(tǒng)，滿足業(yè)務(wù)場景對一致性和規(guī)范化的要求。

作為一種更直接的機制，通常嵌入在大型語言模型（LLM）內(nèi)部，F(xiàn)unction Calling 用于在模型生成響應(yīng)時動態(tài)調(diào)用外部函數(shù)或 API。其主要涉及如下組件：

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

以下是一個 OpenAI 函數(shù)調(diào)用的 JSON 定義示例，用于獲取指定地點的當(dāng)前天氣信息，具體可參考如下：

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

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

因此，此種方法特別適合那些需要精確、結(jié)構(gòu)化數(shù)據(jù)的任務(wù)，例如數(shù)據(jù)提取、分類或外部 API 調(diào)用等相關(guān)場景。

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

盡管函數(shù)調(diào)用（Function-Calling）在處理結(jié)構(gòu)化任務(wù)時表現(xiàn)出色，但模型上下文協(xié)議（Model Context Protocol，簡稱 MCP）則采用了完全不同的設(shè)計思路。

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

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

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

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

from mcp import MCPServer, Tool, Parameter


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


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


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


# 啟動服務(wù)器
server.start()

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

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

三、MCP & Function Calling 設(shè)計理念差異性解析

1. MCP 設(shè)計理念：模塊化、分布式與可控的智能任務(wù)執(zhí)行框架

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

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

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

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

集成化與高效性：Function Calling 將函數(shù)調(diào)用邏輯直接嵌入 LLM 中，從而簡化了系統(tǒng)架構(gòu)并減少了中間層。這種設(shè)計有助于提高系統(tǒng)的響應(yīng)速度，并且適用于需要快速響應(yīng)和高效執(zhí)行的簡單任務(wù)。

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

輕量級架構(gòu)：由于去除了復(fù)雜的中間層，F(xiàn)unction Calling 顯得更加輕量，適合嵌入式系統(tǒng)或單體應(yīng)用，能夠減少系統(tǒng)復(fù)雜度并提高維護效率。

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

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

那么，在實際的業(yè)務(wù)場景中，如何決策呢？

以下是關(guān)于如何選擇 Function-Calling 或 MCP 的詳細(xì)建議，并探討如何結(jié)合兩者以實現(xiàn)更優(yōu)的解決方案。

1. 使用 Function-Calling 的場景

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

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

典型案例：

• 數(shù)據(jù)提取：從用戶提交的文本中提取關(guān)鍵信息，如提取訂單號或用戶信息。
• 工單分類：如前文所述，將客戶支持工單分類為“賬單問題”或“技術(shù)支持”。
• API 集成：通過調(diào)用天氣 API 獲取實時天氣數(shù)據(jù)，并以結(jié)構(gòu)化格式返回。

在上述這些場景中，F(xiàn)unction-Calling 能夠以較低的開發(fā)成本和較高的可控性，快速滿足業(yè)務(wù)需求。

2. 使用 MCP 的場景

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

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

典型案例：

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

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

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

例如，在一個客戶支持系統(tǒng)中，可以通過以下方式結(jié)合兩者：

Function-Calling 用于工單分類：利用 Function-Calling 的結(jié)構(gòu)化特點，快速將用戶提交的工單分類為“賬單問題”或“技術(shù)支持”，確保分類結(jié)果的準(zhǔn)確性和一致性。

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

這種混合方法能夠在不同階段發(fā)揮各自的優(yōu)勢：Function-Calling 確保了關(guān)鍵任務(wù)的效率和可控性，而 MCP 則增強了對話的靈活性和上下文連貫性。通過合理設(shè)計，開發(fā)者可以在系統(tǒng)架構(gòu)中無縫集成這兩種方法，例如在函數(shù)調(diào)用完成后將結(jié)果傳遞給 MCP 的上下文層，用于后續(xù)處理。

綜上所述，F(xiàn)unction-Calling 和 MCP 各有其擅長的領(lǐng)域，選擇哪種方法取決于具體的業(yè)務(wù)需求和技術(shù)目標(biāo)。

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