隨著代理系統變得越來越復雜，企業能力在這些系統中作為工具出現，建立明確且一致的規則對于自主工作流程的成功至關重要。

模型上下文協議 (MCP) 為代理、LLM 和企業系統提供通用語言。將 MCP 納入 AI 數據戰略的企業將能夠構建新功能，確保信任和可審計性，并適應快速發展的創新。競爭優勢將源于周到的設計、強大的可操作性和學習意愿。

這篇文章介紹了 MCP 作為 AI 原生集成標準的工作原理、其主要特性、與 API 的關系、相對于 RAG 系統的優勢、實施策略以及組織的運營考慮因素。

什么是 MCP？它為何重要？

MCP 于 2024 年底推出，是一種開放的 AI 原生協議，用于描述外部工具、函數、API 和數據集，使 LLM 能夠自行決定如何以及何時使用它們。它基于數十年 API、SOAP、REST 和 OpenAPI/Swagger 的經驗教訓——但至關重要的是，它是為機器而非人類的消費和推理而設計的。

MCP 支持功能發現，代理或 LLM 可以確定哪些操作是可行的，以及成功執行這些操作所需的上下文。它通過詳細的描述提供豐富的語義，幫助 LLM 理解如何使用、何時以及為何使用一項功能。MCP 通過一致的接口公開各種資源（API、數據庫和內部工具），從而提供一致性。它還通過提供一個抽象層來支持可組合性，該抽象層用于在復雜的代理工作流中連接、組合和編排服務和數據源。

示例：Excel 即服務

假設一位業務用戶想要通過 AI 助手操作 Excel 電子表格中的數據。傳統方法需要專門構建的 API 連接器或自定義提示“配方”，用于執行每個操作，例如添加行、重新計算列或設置格式。這種集成非常繁瑣。

借助 MCP，Excel 服務可以通過 MCP 公開其功能（包括其存儲的數據類型和提供的功能）。代理可以讀取這些信息，推斷可用的操作，并執行諸如“添加季度增長率列”之類的任務，而無需進行自定義集成工作。

MCP 與 API 的關系和區別

MCP 可以被視為一次進化的飛躍。傳統的 API 充當系統交互的“名詞和動詞”，而 MCP 不僅闡明了存在哪些操作，還闡明了如何以豐富、靈活的方式（適合 AI 代理）使用它們。

API 和 MCP 都提供了定義客戶端可以對系統執行哪些操作的契約。它們都可以組合起來，以編排更復雜的工作流程。兩者都依賴于良好的設計，因為設計不良的 API 或描述不良的 MCP 端點會導致混亂、功能無法使用或下游問題。

然而，它們之間存在著關鍵的區別。API 是為人類開發人員設計的，而 MCP 是為能夠讀取并“推理”詳細描述和上下文的 AI 模型設計的。API 通常需要手動編寫，而 MCP 則明確面向能夠實時決定使用哪些工具以及如何使用的代理推理系統。MCP 可以輕松地以自由形式的敘述（而不僅僅是形式參數）來描述語義關系和上下文——這有助于 LLM 驅動的決策。

假設用例：ERP 集成

一家零售商的 ERP 系統包含數十個 API（庫存、定價、訂單）。以前，開發人員必須學習每個 API，閱讀文檔，編寫代碼，并處理各種邊緣情況。

通過 MCP，一個描述良好的界面即可展現業務優先的功能：“檢索當前庫存水平”、“檢查缺貨訂單”、“將價格上調 5%”。負責“準備低庫存警報報告”的 LLM 代理可以使用語義描述來發現、組合和排序這些功能，即使這些功能是跨 API、數據庫或遺留系統實現的。

超越檢索增強生成：人工智能應用集成的下一步

檢索增強生成 (RAG)幫助模型在推理時檢索外部信息，并通過最新或特定于企業的上下文來增強其響應能力。然而，RAG 主要關注的是數據檢索，而非操作。

MCP 更進一步，提供了工具契約，使 LLM 不僅能夠查找信息，還能調用操作。它通過描述提供語義指導，闡明工具的功能、使用時機、副作用以及預期的輸入/輸出類型。MCP 支持統一的編排，使 LLM 能夠以單一、一致的方式理解后端并與之交互，無論后端是 REST API、直接 SQL 接口還是其他接口。

示例：自動化支出管理

想要實現月度費用審批自動化的企業可以使用 LLM 代理，該代理會檢查已提交的請求（使用 RAG），然后使用 MCP 公開的 SQL 數據庫工具來審計預算消耗，在發現異常時調用 MCP 的“通知管理器”功能，并在 MCP 公開的 ERP 系統中記錄記錄。該代理無需使用脆弱的腳本或點對點集成，而是在豐富的 MCP 描述指導下動態導航功能。

MCP設計和操作化的重要性

對于 API 而言，成功通常取決于清晰、以開發者為中心的設計。而使用 MCP，您編寫的模型會關注每一個字詞。LLM 能夠處理詳盡的文檔、示例和細微差別，因此，全面性和清晰度會帶來回報。

一個好的薪資 MCP 端點不僅僅是被描述為“update_salary”。其文檔解釋道：“使用此功能調整員工薪酬。典型場景：年度加薪、特別獎金。要求：employee_id、new_salary、reason。觸發通知給人力資源和財務部門。”

一個糟糕的例子是“可調用對象：update（eid，val）”，它沒有提供任何上下文，可能會被 LLM（或人類）誤用或忽略。

陷阱：糟糕的設計會延續下去

與 API 一樣，后端結構與業務流程之間缺乏一致性會導致混亂。將原始數據庫模式表達為 MCP 端點，或用技術術語公開每個方法，都違背了初衷。LLM 可以彌補一些歧義，但無法完全克服清晰度或業務上下文的缺失。

資源考慮

AI 操作并非免費：每個令牌和每次調用都需要計算資源，進而也需要資金。如果客服人員天真地重復或過度調用，后端可能會不堪重負，預算也可能超支。

緩解策略包括使用精確的、以任務為中心的 MCP 端點，在 MCP 描述中指示成本、副作用或推薦的使用模式，并根據需要實施緩存或限制，同時將這些限制告知代理。

新的測試、監控和管理模式

測試確定性 API 很簡單，但由 MCP 支持的代理 AI 引入了可變性：相同的請求可能會根據上下文、負載或細微的提示差異產生不同的工具鏈。

MCP 世界中的 QA 包括合成任務生成以創建代表性任務并自動化測試運行、邊緣案例分析以監控無效的工具選擇或資源問題，以及凍干模式以將可靠的工具鏈“凍結”為固定序列或新的 MCP 端點。

自動化的連續體：代理和程序

并非所有問題都需要自由形式的代理編排。許多企業工作流程一旦發現，最好進行硬編碼，以提高效率和可預測性。相同的 MCP 基礎架構可以同時支持這兩種方法，在需要的地方提供靈活性，在其他地方提供確定性。

企業戰略的最終考慮

MCP 屬于 AI 數據庫，因為它通過減少逐案定制集成的需要來加速集成，通過詳細描述的功能來提高透明度和信任度，通過防止“失控”的計算費用來降低成本，并通過帶來適應性來確保架構的未來性。

可行的步驟包括從小處著手，通過 MCP 公開關鍵 API 或工具，通過詳細說明功能使用的原因、時間和后果來進行清晰的設計，迭代和凍結成功的工作流程，規劃包括成本和資源監控在內的運營，并通過試點和分析進行邊做邊學。

常見問題

人工智能中的數據戰略是什么？

人工智能中的數據戰略是指組織如何收集、管理、存儲和使用數據來驅動人工智能系統的全面規劃。它涵蓋數據治理、質量控制、集成方法以及像 MCP 這樣的工具，使人工智能系統能夠有效地訪問和使用組織數據。良好的人工智能數據策略能夠確保人工智能代理能夠發現、理解并合理利用所有可用的數據資源和工具，從而實現業務價值。

什么是 AI-first 數據策略？

AI 優先的數據策略優先考慮專為 AI 消費而非人類消費而設計的數據系統。它致力于通過實施 MCP 等協議，使 AI 系統能夠理解上下文、發現功能并采取適當的行動，從而使數據具備 AI 就緒性。這種方法強調語義豐富性、跨不同數據源的一致性以及服務的可組合性，從而使 AI 代理能夠高效工作，而無需大量的人工干預或針對每個用例進行自定義集成。

數據策略的一個例子是什么？

數據策略的一個實際例子是企業實施 MCP 來統一對其各個系統的訪問。例如，零售商可能會制定一個全面的數據策略，該策略包括：

1. 通過 MCP 接口公開庫存、定價和訂單系統
2. 為每項功能創建清晰的語義描述
3. 對人工智能代理交互實施適當的測試和監控
4. 建立數據訪問和操作的治理協議
5. 開發成本控制機制以防止失控的計算費用
6. 創建一個流程來識別成功的 AI 工作流程，并對其進行“冷凍干燥”以提高效率
7. 構建具有一致元數據標準的集中式數據湖
8. 在信息進入人工智能系統之前建立數據質量控制流程

這種方法可以使企業逐步構建人工智能功能，同時保持對代理與關鍵業務系統交互方式的控制。