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

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

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

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

一、如何理解 Function Calling ？

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

然而，在企業(yè)環(huán)境中，這種生成能力卻往往是一把雙刃劍。企業(yè)通常需要的是可預(yù)測(cè)、結(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ù)場(chǎng)景對(duì)一致性和規(guī)范化的要求。

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

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

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

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

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

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

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

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

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

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

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

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

from mcp import MCPServer, Tool, Parameter


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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 使用 Function-Calling 的場(chǎng)景

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

• 需要結(jié)構(gòu)化、可預(yù)測(cè)的輸出：當(dāng)任務(wù)對(duì)輸出的格式和內(nèi)容有嚴(yán)格要求時(shí)，函數(shù)調(diào)用能夠通過預(yù)定義的函數(shù)簽名，確保 LLM 生成的結(jié)果始終符合預(yù)期。例如，在需要返回固定格式的 JSON 數(shù)據(jù)時(shí)，函數(shù)調(diào)用可以有效約束模型行為。
• 任務(wù)邊界清晰且需要特定數(shù)據(jù)格式：對(duì)于那些目標(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)中。例如，在一個(gè)需要調(diào)用外部服務(wù)的場(chǎng)景中，函數(shù)調(diào)用可以直接映射到 API 請(qǐng)求。

典型案例：

• 數(shù)據(jù)提?。簭挠脩籼峤坏奈谋局刑崛￡P(guān)鍵信息，如提取訂單號(hào)或用戶信息。
• 工單分類：如前文所述，將客戶支持工單分類為“賬單問題”或“技術(shù)支持”。
• API 集成：通過調(diào)用天氣 API 獲取實(shí)時(shí)天氣數(shù)據(jù)，并以結(jié)構(gòu)化格式返回。

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

2. 使用 MCP 的場(chǎng)景

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

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

典型案例：

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

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

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

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

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

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

這種混合方法能夠在不同階段發(fā)揮各自的優(yōu)勢(shì)：Function-Calling 確保了關(guān)鍵任務(wù)的效率和可控性，而 MCP 則增強(qiáng)了對(duì)話的靈活性和上下文連貫性。通過合理設(shè)計(jì)，開發(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ù)雜交互、長時(shí)間上下文管理或需要在創(chuàng)造力與控制力之間取得平衡，MCP 則更具優(yōu)勢(shì)。而在一些綜合性場(chǎng)景中，結(jié)合兩者可以實(shí)現(xiàn)更高的效率和靈活性，為 LLM 的實(shí)際應(yīng)用提供更全面的解決方案。企業(yè)在選擇時(shí)，應(yīng)充分評(píng)估任務(wù)的復(fù)雜性、系統(tǒng)架構(gòu)的兼容性以及對(duì)可控性和創(chuàng)造力的需求，以確保最終方案能夠最大化地滿足業(yè)務(wù)目標(biāo)。