AI 智能體現在能做的事情真的很厲害,可以思考、規劃,還能執行各種復雜任務,而且代碼量并不大。這讓開發者看到了一個機會:把那些龐大復雜的代碼庫和 API 拆解成更實用的模塊。
不過要讓這些智能變成現實世界里真正能用的東西,還需要模塊化、標準化和強大的接口支持。模型上下文協議(Model Context Protocol,簡稱 MCP) 就是為了解決這個問題而出現的。
什么樣的智能體才算是好智能體?
一開始構建智能體挺簡單的:給大型語言模型寫一些專門的指令來執行任務,再可選地提供一些函數工具,讓它能調用外部 API。
但真正優秀的智能體應該具備這些特點:
- 模塊化:每個任務都是獨立定義且可重用的
- 可組合:智能體可以智能地委派任務或協同工作
- 接地:通過工具與現實世界數據交互
- 可編排:行動序列可根據輸入和上下文進行路由
- 可維護:邏輯和工具可以獨立演進
比如說,有人之前構建了一個處理文檔的應用,這個多智能體流水線可以:
- 讀取文檔(PDF/圖片)
- 提取原始文本
- 對內容進行摘要
- 提取元數據
- 存儲數據
- 回答用戶關于存儲數據的問題
聽起來很不錯,但最初的設計方式其實有不少限制。
MCP 的客戶端-宿主-服務器架構是怎么工作的
MCP 的核心遵循客戶端-宿主-服務器模型,既抽象了工具的集成方式,又保留了靈活性和控制力。
-
宿主(Host) 是整個操作的大腦,通常是像 Claude、ChatGPT 這樣的 AI 接口,或者自己的編排器應用。它負責啟動 MCP 客戶端、執行安全和權限策略,并決定何時調用外部工具。
-
客戶端(Client) 充當宿主和單個服務器之間的橋梁。一旦啟動,它會處理所有通信,格式化結構化請求,將其傳遞給相應的服務器,并將結果返回給宿主。這里不需要寫很多定制代碼,因為客戶端 SDK 處理了大部分復雜性。
-
服務器(Server) 是真正實現功能的地方,也是開發者需要構建的部分。比如 OCR 微服務,它公開了特定的能力。OCR 服務器可能提供一個名為
extract_text
的工具,檢索服務器則可以提供query_documents
或semantic_lookup
等工具。
服務器可以公開三種能力:
- Prompts(提示詞):預定義的模板或指令,用于指導模型
- Resources(資源):結構化的上下文數據,如 PDF 文檔、數據庫記錄或向量嵌入
- Tools(工具):可調用的函數,讓模型能夠采取行動
可以把 MCP 看作連接智能體與外部能力的結締組織,它通過標準化、可內省和可互操作的接口實現連接。
乍一看,它可能跟傳統 API 差不多,但有個關鍵區別:API 是直接暴露功能供使用,而 MCP 允許智能體通過 JSON Schema 動態地發現、描述和調用工具。
比如說,Firestore 服務器可以輕松替換為 MongoDB 版本,而無需更改編排器代碼。或者可以將 OCR 服務器接入到另一個項目中,只要它符合 MCP 清單的要求,就能正常運行。
用 OpenAI Agents 和函數工具構建的傳統方式
使用像 OpenAI 的 Agents SDK 或 LangChain 這樣的框架時,可以將工具定義為 Python 函數,然后將它們傳遞給智能體。
這是一個用于 OCR 的工具示例:
@tool
def extract_text(file_bytes: bytes) -> str:image = vision.Image(content=file_bytes)response = client.document_text_detection(image=image)return response.full_text_annotation.text
然后將它包裝成一個智能體:
extract_text_agent = Agent(instructions="Extract text using OCR.",tools=[extract_text],model="gpt-4o-mini"
)
用編排器將這些智能體鏈式連接起來:
orchestrator = Agent(instructions="""1. Use the OCR tool to extract text2. Summarize the text3. Extract metadata4. Store everything""",tools=[extract_text_agent.as_tool("ocr"),summarizer_agent.as_tool("summarize"),metadata_agent.as_tool("extract_metadata"),firestore_agent.as_tool("store")])
這種做法是可行的,但它緊密耦合了代碼、智能體和服務。如果想要:
- 將 OCR 服務從 GCP 換到 Azure
- 從 Firestore 遷移到 PostgreSQL
- 添加緩存層
這都意味著需要修改核心的智能體邏輯和編排器指令,增加了額外的工作量,并限制了系統的擴展能力。
MCP 登場:解決模塊化問題
模型上下文協議(MCP) 是 Anthropic 提出的一項標準,用于通過結構化的 JSON 接口向 LLM 公開工具。它實現了:
- 可發現性:模型通過清單內省工具能力
- 解耦:工具是服務器,而不是內聯函數
- 標準化:輸入和輸出使用類型化 Schema
- 可替換性:通過指向新的清單來替換工具
- 兼容性:與 GPT、Claude、LLaMA 及其他 LLM 宿主兼容
把 MCP 想象成工具與 AI 運行時之間的契約。現在構建的是帶有清單的 REST 服務器,而不是函數工具。
AI 智能體能發揮多大作用,很大程度上取決于它們能訪問的數據。如果沒有能夠連接到互聯網或數據庫的函數工具,那么能力會受到嚴重限制。MCP 為 AI 工具提供了一種標準化的方法來發現其他 API 和工具,讓 AI 工具能找到新的信息源并執行動作,而不僅僅是提供洞察。
以往,這意味著需要創建自定義集成才能讓 AI 應用連接外部工具。MCP 使開發者能夠更容易、更快速地構建工具集成,同時也方便在不同的工具之間切換,從而實現模塊化和可擴展性。
構建 MCP 兼容工具服務器
讓我們演示如何構建一個遵循 MCP 標準的 OCR 工具。
第 1 步:將 OCR 工具構建為服務器
# ocr_mcp_server.pyfrom typing import Any
from mcp.server.fastmcp import FastMCP
from google.cloud import vision
import base64
import asyncio# Initialize MCP server
mcp = FastMCP("ocr")# OCR Tool
@mcp.tool()
async def extract_text(file_content: str) -> str:"""Extract text from a base64-encoded PDF or image content."""client = vision.ImageAnnotatorClient()# Decode the base64 content back to bytesimage_bytes = base64.b64decode(file_content.encode("utf-8"))image = vision.Image(content=image_bytes)response = await asyncio.to_thread(client.document_text_detection, image=image)if not response.full_text_annotation or not response.full_text_annotation.text:return "No text found in document."return response.full_text_annotation.text# Run the server
if __name__ == "__main__":print("MCP Server starting in stdio mode...")mcp.run(transport="stdio")
第 2 步:定義 MCP 清單
{"name": "OCR MCP Server","description": "使用 Google Cloud Vision API 從 Base64 編碼的 PDF 或圖像文件中提取原始文本。","tools": [{"name": "extract_text","description": "從 Base64 編碼的文件內容字符串中提取完整的文檔文本。","input_schema": {"type": "object","properties": {"file_content": {"type": "string","description": "PDF 或圖像的 Base64 編碼二進制內容"}},"required": ["file_content"]},"output_schema": {"type": "string","description": "文檔中經 OCR 識別的完整文本內容"}}]
}
這份清單使得任何模型編排器都能理解:
- 此工具的功能是什么
- 期望的輸入/輸出格式是怎樣的
- 請求應該發送到何處
MCP 客戶端:將工具調用為動作
現在,編排器不再需要與具體的工具實現方式綁定,而是通過 MCP 客戶端調用抽象的動作。
import base64
from mcp.client import MCPClient
import asyncio
import osasync def main():file_path = "sample.pdf"# Step 1: Read and encode filetry:with open(file_path, "rb") as f:file_bytes = f.read()file_content = base64.b64encode(file_bytes).decode("utf-8")except FileNotFoundError:print(f"Error: File not found at {file_path}")returnexcept Exception as e:print(f"Error reading file: {e}")return# Step 2: Initialize clientserver_url = "http://localhost:8001"print(f"Attempting to connect to MCP server at {server_url}...")try:client = MCPClient(server_url)# Step 3: Call the OCR toolprint("Calling 'extract_text' tool...")params = {"file_content": file_content}result = await client.call_tool("extract_text", params)# Step 4: Output extracted textprint("\nExtracted Document Text:\n")print(result)except Exception as e:print(f"An error occurred during MCP client call: {e}")print("Please ensure the MCP server is running and accessible at the specified URL.")if __name__ == "__main__":asyncio.run(main())
任何智能體或工具都無需了解其他部分的具體實現方式。這正是 MCP 的強大之處。
MCP 架構的優勢
- 模塊化:每個工具都是獨立的、可版本化和可測試的
- 可組合性:智能體可以通過清單混合搭配工具
- 可維護性:工具 Schema 的變化不會破壞編排邏輯
- 可擴展性:添加新服務無需更新智能體
- 跨模型兼容:適用于 GPT、Claude、LLaMA 等多種模型
MCP 與傳統智能體 API 的對比
AI 智能體是智能系統,旨在無需指定每個步驟就能采取行動。比如在文檔助手中,一旦上傳了文件,無需手動調用 OCR、摘要或元數據提取。編排器智能體根據設定的指令自主處理這一切。
MCP 通過為智能體提供訪問外部服務的標準化途徑,提升了這種自主性。無需將函數調用硬編碼到編排器中,而是可以將 OCR 或 Firestore 存儲等能力作為獨立的 MCP 服務器公開。智能體無需知道具體實現——它只需調用一個像 extract_text
這樣的動作,底層服務器會處理其余部分。
這使得接入新工具或切換提供商變得更加容易,比如從 Google Vision 切換到 Azure OCR,而無需重寫智能體邏輯。
總結
MCP 是一個注重開發者體驗的框架,專為希望精確控制智能體如何與工具和數據交互的工程師而設計。它通過允許 AI 連接外部工具,來賦予 AI 具身智能的能力。
MCP 和傳統智能體 API 為不同人群解決了不同問題,并且都在不斷發展的 AI 生態系統中扮演著各自的角色。構建一個完全自動化系統最重要的考量應該是模塊化、可擴展性和可靠性。如何實現這一步取決于個人偏好以及可用的工具。