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 的工具示例：
python
@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然后将它包装成一个智能体：
python
extract_text_agent = Agent(
instructions="Extract text using OCR.",
tools=[extract_text],
model="gpt-4o-mini"
)用编排器将这些智能体链式连接起来：
python
orchestrator = Agent(
instructions="""1. Use the OCR tool to extract text
2. Summarize the text
3. Extract metadata
4. 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 工具构建为服务器
python
# ocr_mcp_server.py
from 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 bytes
image_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 清单
json
{
"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 客户端调用抽象的动作。
python
import base64
from mcp.client import MCPClient
import asyncio
import os
async def main():
file_path = "sample.pdf"
# Step 1: Read and encode file
try:
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}")
return
except Exception as e:
print(f"Error reading file: {e}")
return
# Step 2: Initialize client
server_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 tool
print("Calling 'extract_text' tool...")
params = {"file_content": file_content}
result = await client.call_tool("extract_text", params)
# Step 4: Output extracted text
print("\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 生态系统中扮演着各自的角色。构建一个完全自动化系统最重要的考量应该是模块化、可扩展性和可靠性。如何实现这一步取决于个人偏好以及可用的工具。