省流：MCP出现的意义是什么？让 AI 智能体更模块化
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 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 工具构建为服务器
# 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()
asyncdef 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)
ifnot response.full\_text\_annotation ornot 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 os
asyncdef 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 生态系统中扮演着各自的角色。构建一个完全自动化系统最重要的考量应该是模块化、可扩展性和可靠性。如何实现这一步取决于个人偏好以及可用的工具。
添加微信，备注” LLM “进入大模型技术交流群
如果你觉得这篇文章对你有帮助，别忘了点个赞、送个喜欢
/ 作者：致Great
/ 作者：欢迎转载，标注来源即可