1.3 Agent 通信的“普通话”：MCP 协议深度解析与实战> 导语：如果说 Function Calling 是让

导语：如果说 Function Calling 是让单个 Agent 拥有“双手”的技术，那么多 Agent 系统又该如何沟通协作？当成百上千、由不同模型、不同框架构建的 Agent 需要协同工作时，我们是否需要一种通用的“语言”来避免混乱？这就是 MCP（Model-Controller-Plugin）协议诞生的意义。本文将带你深度解析这个旨在成为 Agent 通信“普通话”的协议，并通过实战教你如何构建和接入标准化的 MCP 服务，为你的多智能体系统打下坚实的基础。

告别混乱：为什么我们需要 Agent 通信协议？
- 多智能体协作的“巴别塔”困境
- API 直连的脆弱性与定制化开发的陷阱
- MCP 协议的核心使命：定义一套 Agent 间的标准化交互契约
MCP 协议深度解析：核心概念与数据结构
- 三大角色：模型（Model）、控制器（Controller）、插件（Plugin）
- 核心路由：从 mcp:// URI 看懂 MCP 的寻址方式
- 数据结构：McpRequest 和 McpResponse 的标准字段
- Mermaid 图解：一次完整的 MCP 请求-响应流程
FastMCP 实战：从零构建一个标准化的天气查询插件
- 环境准备：安装 fastmcp 和 uvicorn
- 插件（Plugin）开发：定义工具函数并用 @plugin.tool() 装饰
- 控制器（Controller）启动：一行代码运行你的 MCP 服务
- 使用 curl 或 requests 进行标准化的 API 测试
MCP 客户端开发：让你的 Agent “说普通话”
- 客户端的职责：发现服务、构造请求、解析响应
- 使用 requests 库手写一个简单的 MCP 客户端
- 实战：将上一章的文件搜索 Agent 接入 MCP 客户端
集成 LangChain 与 DeepSeek：构建跨框架的 Agent 系统
- 将 FastMCP 插件封装成 LangChain Tool
- 使用 DeepSeek 模型作为 Agent 大脑，通过 MCP 调用外部工具
- 代码实战：构建一个使用 DeepSeek 模型、通过 MCP 协议查询天气的 LangChain Agent
MCP 的设计哲学与未来展望
- 简单性 vs. 完备性：MCP 的设计取舍
- 服务发现与注册中心：MCP 生态的未来演进
- 安全性考量：认证、授权与数据加密
- MCP 与 Function Calling 的关系：互补而非替代
总结：构建可扩展、可维护的多智能体系统的第一步

1. 告别混乱：为什么我们需要 Agent 通信协议？

随着 Agentic AI 的发展，我们很快就会发现，单个 Agent 的能力是有限的。就像人类社会一样，真正的力量来自于协作。构建能够协同工作的多智能体系统（Multi-Agent System），是解决更复杂、更庞大任务的必由之路。

想象一个复杂的电商运营场景，我们可能需要：

一个数据分析 Agent，负责监控销售数据、分析用户行为。
一个营销文案 Agent，负责根据最新的潮流和产品信息，自动生成社交媒体内容。
一个库存管理 Agent，负责监控商品库存，并在库存不足时自动向供应商下订单。
一个客户服务 Agent，负责解答用户的售前售后问题。

这些 Agent 如何有效地沟通和协作？

多智能体协作的“巴别塔”困境

如果没有一个统一的标准，每个 Agent 的开发者都可能定义自己独特的 API 接口。

数据分析 Agent 的 API 可能是 /api/v1/get_sales_report，接受 POST 请求和 JSON body。
库存管理 Agent 的 API 可能是 /inventory/check?item_id=123，接受 GET 请求和 URL 参数。
营销文案 Agent 可能使用的是 GraphQL 接口。

当一个新的 Agent，比如“竞争对手分析 Agent”，想要接入这个系统时，它需要为每一个它想交互的 Agent 单独编写适配代码。这就像一个国际会议上，每个人都只说自己的方言，导致沟通效率极其低下，系统维护成本高昂。这就是多智能体协作中的“巴别塔”困境。

API 直连的脆弱性与定制化开发的陷阱

直接通过 API 进行点对点连接，看似简单，但随着系统规模的扩大，会暴露出其固有的脆弱性：

紧耦合：任何一个 Agent 的 API 发生微小变化（比如修改了 URL、改变了参数名），都可能导致所有依赖它的 Agent 失效。
重复开发：每个 Agent 都需要重复实现服务发现、请求构造、错误处理等逻辑，浪费开发资源。
难以扩展：每增加一个新 Agent，都可能需要修改多个现有 Agent 的代码来与之适配，系统扩展性极差。

MCP 协议的核心使命：定义一套 Agent 间的标准化交互契约

为了解决上述问题，社区提出了 MCP（Model-Controller-Plugin）协议。

MCP 并非一个具体的框架或软件，而是一套设计规范和通信契约。它的核心使命非常明确：在不同的 Agent（或 Agent 的组件）之间，建立一套统一的、标准化的交互语言。

通过遵循 MCP 协议，无论一个工具（插件）是用 Python、Go 还是 Node.js 编写的，也无论驱动 Agent 的大脑是 OpenAI 的 GPT-4、DeepSeek 还是本地的 Llama 模型，它们之间都能通过一套共同的语言进行无缝沟通。

MCP 就像是 Agent 世界的“普通话”和“HTTP 协议”，它将底层的实现细节抽象掉，让开发者可以专注于业务逻辑本身，而不是花费大量时间在“翻译”和“适配”工作上。

2. MCP 协议深度解析：核心概念与数据结构

要理解 MCP，我们首先要弄懂它的三大核心角色和基本交互流程。

三大角色：模型（Model）、控制器（Controller）、插件（Plugin）

MCP 的命名本身就揭示了它的三个核心组成部分：

插件（Plugin）：这是提供具体能力的单元，也就是我们常说的工具（Tool）。一个插件可以包含一个或多个工具函数。例如，一个“天气插件”可以包含 get_current_weather 和 get_weather_forecast 两个工具。插件是能力的提供方。
控制器（Controller）：这是整个系统的入口和协调者。它负责接收外部请求，解析请求的意图，然后将请求路由到正确的插件和工具上。控制器本身不实现具体能力，它像一个聪明的“交通警察”，指挥着数据的流向。
模型（Model）：这是 Agent 的大脑，通常是一个大型语言模型。模型是能力的使用方。它通过客户端向控制器发起请求，以调用插件提供的能力。需要注意的是，在 MCP 的语境下，任何调用方都可以被看作是“模型”或客户端。

这三者之间的关系是：模型（客户端） 向 控制器 发出标准化的请求，控制器 将请求路由给相应的插件，插件执行任务后将结果返回给控制器，控制器再将结果返回给模型。

核心路由：从 mcp:// URI 看懂 MCP 的寻址方式

MCP 的一个核心设计是它的路由机制。一个 MCP 请求的目标是通过一个类似 URL 的 URI 来指定的，其格式为：

mcp://<plugin_name>/<tool_name>

mcp://: 固定的协议头。
<plugin_name>: 插件的名称，用于让控制器知道该去哪个插件里寻找工具。
<tool_name>: 工具的名称，即插件中具体要调用的函数名。

例如，一个调用 weather 插件中的 get_current_weather 工具的请求，其目标地址就是 mcp://weather/get_current_weather。

这种设计非常优雅，它将“调用哪个工具”这个问题，从一个复杂的、需要特殊解析的字段，变成了一个标准的、可路由的地址。

数据结构：McpRequest 和 McpResponse 的标准字段

MCP 协议规定了 HTTP 请求和响应的 Body 必须遵循特定的 JSON 结构。

一个标准的 McpRequest（通常以 HTTP POST 请求发送）大致如下：

{
  "mcp_version": "0.1.0",
  "tool_uri": "mcp://weather/get_current_weather",
  "tool_args": [],
  "tool_kwargs": {
    "location": "Boston",
    "unit": "fahrenheit"
  },
  "request_context": {}
}

mcp_version: 协议版本号。
tool_uri: 核心的路由地址。
tool_args: 以数组形式提供的工具位置参数（较少使用）。
tool_kwargs: 以对象形式提供的工具关键字参数，这是最常用的传参方式。
request_context: 一个用于传递额外上下文（如用户认证信息、会话 ID 等）的保留字段。

一个标准的 McpResponse 如下：

{
  "mcp_version": "0.1.0",
  "status_code": 0,
  "error_message": "",
  "tool_response": {
    "location": "Boston",
    "temperature": "68",
    "unit": "fahrenheit"
  },
  "response_context": {}
}

status_code: 状态码，0 代表成功，非 0 代表失败。
error_message: 如果失败，这里会提供错误信息。
tool_response: 工具函数执行成功后的返回值。协议建议返回 JSON 对象。
response_context: 保留字段。

Mermaid 图解：一次完整的 MCP 请求-响应流程

让我们用 Mermaid 图来串起整个流程。

graph TD
    subgraph Client/Model [客户端/模型]
        A[Agent 大脑 (LLM)] --> B{构造 McpRequest};
    end

    subgraph Controller [控制器 (FastMCP 服务)]
        C[HTTP 入口] --> D{解析 tool_uri};
        D --> E{路由到指定插件};
    end

    subgraph Plugins [插件]
        F[Weather Plugin] --> G[get_current_weather(...)]
        H[Other Plugin] --> I[...]
    end
    
    B -- "POST /invoke" --> C;
    E -- "调用 weather/get_current_weather" --> F;
    G -- "执行并返回结果" --> E;
    E -- "构造 McpResponse" --> C;
    C -- "HTTP 200 OK" --> B;
    B -- "解析 Response, 提交给 LLM" --> A;

这张图清晰地展示了：

客户端（如一个 LangChain Agent）的 LLM 大脑决定调用工具。
客户端代码将这个意图构造成一个标准的 McpRequest JSON 对象，并通过 HTTP POST 请求发送到控制器的 /invoke 端点。
控制器接收到请求，解析 tool_uri (mcp://weather/get_current_weather)。
控制器根据 weather 这个插件名，将请求分发给已经注册的 Weather Plugin。
Weather Plugin 根据 get_current_weather 这个工具名，调用相应的函数，并传入 tool_kwargs。
函数执行完毕，返回结果。
控制器将函数结果包装成一个标准的 McpResponse JSON 对象，作为 HTTP 响应返回给客户端。
客户端解析 McpResponse，提取出 tool_response，并将其喂给 LLM 以生成下一步的思考或最终回复。

3. FastMCP 实战：从零构建一个标准化的天气查询插件

理论讲完了，让我们动手实践。fastmcp 是一个基于 FastAPI 的 MCP 协议实现，可以让我们非常快速地构建一个标准的 MCP 服务。

环境准备：安装 fastmcp 和 uvicorn

pip install fastmcp uvicorn

fastmcp: MCP 协议的核心实现库。
uvicorn: 一个高性能的 ASGI 服务器，用于运行我们的 FastAPI/FastMCP 应用。

插件（Plugin）开发：定义工具函数并用 @plugin.tool() 装饰

创建一个名为 weather_plugin.py 的文件。

# weather_plugin.py

import json
from fastmcp import Plugin

# 1. 创建一个插件实例
plugin = Plugin(
    name="weather",
    description="A plugin to get weather information."
)

# 2. 编写你的工具函数
def get_weather(location: str, unit: str = "celsius") -> dict:
    """
    Get the current weather for a specific location.
    
    :param location: The city name, e.g., "San Francisco".
    :param unit: The temperature unit, either "celsius" or "fahrenheit".
    """
    print(f"Getting weather for {location} in {unit}...")
    
    # 模拟真实 API 调用
    if "tokyo" in location.lower():
        return {"location": "Tokyo", "temperature": 10, "unit": "celsius"}
    elif "san francisco" in location.lower():
        return {"location": "San Francisco", "temperature": 72, "unit": "fahrenheit"}
    elif "paris" in location.lower():
        return {"location": "Paris", "temperature": 22, "unit": "celsius"}
    else:
        # 即使找不到，也返回一个结构化的响应
        return {"location": location, "temperature": "unknown"}

# 3. 使用 @plugin.tool() 装饰器将函数注册为工具
#    MCP 会自动将函数的参数、类型提示、文档字符串转换为工具的元数据
plugin.tool(name="get_current_weather")(get_weather)

# 你也可以直接传递函数
# plugin.tool(get_weather, name="get_current_weather")

这段代码做了三件事：

创建了一个名为 weather 的 Plugin 实例。这个名字将用于 MCP 路由。
定义了一个普通的 Python 函数 get_weather，它有类型提示和标准的函数文档。
使用 @plugin.tool() 装饰器将 get_weather 函数注册到插件实例中，并为其指定了在 MCP 协议中暴露的工具名称 get_current_weather。

fastmcp 会智能地解析 get_weather 函数的签名和文档字符串，自动生成符合 OpenAI Function Calling/Tools 规范的工具描述。

控制器（Controller）启动：一行代码运行你的 MCP 服务

现在，创建另一个文件 main.py 来启动我们的控制器服务。

# main.py

from fastmcp import Controller
from weather_plugin import plugin as weather_plugin

# 1. 创建一个控制器实例
controller = Controller()

# 2. 将我们的插件注册到控制器
controller.register(weather_plugin)

# 3. 让 FastMCP 创建一个 FastAPI 应用实例
#    你可以传递 title, description 等 FastAPI 支持的参数
app = controller.build_app(
    title="My First MCP Agent Service",
    description="This service provides weather and other tools via MCP."
)

# 如果你需要直接访问 app (FastAPI 实例) 来添加自定义路由等，可以这样做：
# @app.get("/my-custom-route")
# def custom_route():
#     return {"message": "Hello World"}

现在，在终端中运行 uvicorn 来启动服务：

uvicorn main:app --host 0.0.0.0 --port 8000 --reload

main:app: 指的是 main.py 文件中的 app 对象。
--reload: 热重载模式，当你修改代码时服务会自动重启。

服务启动后，你可以访问 http://localhost:8000/docs，你会看到一个由 FastAPI 自动生成的、非常漂亮的 API 文档页面。

在这个文档页面里，你会看到几个由 fastmcp 自动生成的标准端点：

/mcp/v1/invoke: 执行工具调用的核心端点。
/mcp/v1/tools: 获取所有已注册工具的详细描述（遵循 OpenAI JSON Schema 格式）。
/mcp/v1/plugins: 列出所有已注册的插件。

使用 curl 或 requests 进行标准化的 API 测试

现在，我们的 MCP 服务已经运行起来了。我们可以像调用任何普通 REST API 一样，使用 curl 来测试它。

curl -X 'POST' \
  'http://localhost:8000/mcp/v1/invoke' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "mcp_version": "0.1.0",
  "tool_uri": "mcp://weather/get_current_weather",
  "tool_kwargs": {
    "location": "San Francisco",
    "unit": "fahrenheit"
  }
}'

你会收到一个标准格式的 McpResponse：

{
  "mcp_version": "0.1.0",
  "status_code": 0,
  "error_message": "",
  "tool_response": {
    "location": "San Francisco",
    "temperature": 72,
    "unit": "fahrenheit"
  },
  "response_context": {}
}

这证明我们的 MCP 服务已经成功运行！我们已经将一个普通的 Python 函数，通过标准化的方式暴露成了一个网络服务。

4. MCP 客户端开发：让你的 Agent “说普通话”

服务已经有了，现在我们需要一个客户端来调用它。

客户端的职责：发现服务、构造请求、解析响应

一个 MCP 客户端的核心职责很简单：

知道 MCP Controller 的地址（例如 http://localhost:8000）。
能够根据要调用的工具名和参数，构造出标准的 McpRequest JSON。
通过 HTTP POST 请求将该 JSON 发送到 Controller 的 /invoke 端点。
接收并解析返回的 McpResponse JSON，提取出 tool_response 或错误信息。

使用 requests 库手写一个简单的 MCP 客户端

我们可以非常容易地用 requests 库实现这个逻辑。

# mcp_client.py
import requests
import json
from typing import Any, Dict

class McpHttpClient:
    def __init__(self, controller_url: str):
        if not controller_url.endswith("/"):
            controller_url += "/"
        self.invoke_url = f"{controller_url}mcp/v1/invoke"
        self.tools_url = f"{controller_url}mcp/v1/tools"

    def get_tools_spec(self) -> Dict[str, Any]:
        """获取控制器上所有工具的 OpenAI 格式描述"""
        try:
            response = requests.get(self.tools_url)
            response.raise_for_status()
            return response.json()
        except requests.RequestException as e:
            print(f"Error fetching tools spec: {e}")
            return {}

    def invoke(self, tool_uri: str, **kwargs) -> Any:
        """调用一个 MCP 工具"""
        request_body = {
            "mcp_version": "0.1.0",
            "tool_uri": tool_uri,
            "tool_kwargs": kwargs,
        }
        
        try:
            print(f"Invoking tool: {tool_uri} with args: {kwargs}")
            response = requests.post(self.invoke_url, json=request_body)
            response.raise_for_status()
            
            mcp_response = response.json()
            
            if mcp_response.get("status_code", -1) != 0:
                error_msg = mcp_response.get("error_message", "Unknown error")
                print(f"MCP tool invocation failed: {error_msg}")
                return {"error": error_msg}
                
            return mcp_response.get("tool_response")
            
        except requests.RequestException as e:
            print(f"HTTP error invoking tool: {e}")
            return {"error": str(e)}

# --- 使用客户端 ---
if __name__ == "__main__":
    # 假设我们的 MCP 服务运行在 localhost:8000
    client = McpHttpClient("http://localhost:8000")

    # 1. 获取工具列表（可选，但对于 Agent 很有用）
    tools_spec = client.get_tools_spec()
    print("--- Available Tools Spec ---")
    print(json.dumps(tools_spec, indent=2))

    # 2. 调用天气工具
    print("\n--- Invoking Weather Tool ---")
    weather_result = client.invoke("mcp://weather/get_current_weather", location="Tokyo")
    print("Result:", weather_result)

这个 McpHttpClient 封装了所有与 MCP 服务交互的细节，向调用者提供了两个简单的方法：

get_tools_spec(): 用于获取所有可用工具的 OpenAI 格式描述，这对于初始化 Agent 至关重要。
invoke(): 用于实际执行工具调用。

5. 集成 LangChain 与 DeepSeek：构建跨框架的 Agent 系统

现在，最激动人心的部分来了。我们将把所有东西串联起来：使用一个强大的开源模型（DeepSeek）作为大脑，使用 LangChain 作为 Agent 开发框架，并通过我们刚刚构建的 MCP 客户端来调用标准化的外部工具。

将 FastMCP 插件封装成 LangChain Tool

LangChain 的 Tool 对象是一个非常灵活的抽象。我们可以自定义一个 Tool，让它的 _run 方法调用我们的 McpHttpClient。

环境准备

pip install langchain langchain_openai

注：langchain_openai 用于和 DeepSeek 等兼容 OpenAI API 的模型交互。

# langchain_mcp_integration.py

from langchain.agents import Tool
from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_openai_tools_agent
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
from mcp_client import McpHttpClient # 从我们之前的文件导入客户端
import os
import json

# --- 1. 创建 MCP 客户端实例 ---
mcp_client = McpHttpClient("http://localhost:8000")

# --- 2. 从 MCP 服务动态创建 LangChain Tools ---
# 这是一个非常强大的模式：Agent 启动时自动从 MCP 服务发现可用工具
tools_spec_from_mcp = mcp_client.get_tools_spec().get("tools", [])
langchain_tools = []

for tool_spec in tools_spec_from_mcp:
    func_name = tool_spec["function"]["name"]
    # LangChain 的 Tool name 不能包含 "mcp://" 或 "/"
    # 我们用 "." 来代替 "/"
    tool_name = func_name.replace("mcp://", "").replace("/", ".")
    
    # 获取函数描述
    tool_description = tool_spec["function"]["description"]
    
    # 动态创建一个函数，该函数调用我们的 MCP 客户端
    def create_mcp_tool_func(uri):
        def _mcp_tool_wrapper(**kwargs):
            return mcp_client.invoke(uri, **kwargs)
        return _mcp_tool_wrapper

    # 创建 LangChain Tool
    new_tool = Tool(
        name=tool_name,
        description=tool_description,
        func=create_mcp_tool_func(func_name),
    )
    langchain_tools.append(new_tool)

print("--- Dynamically Created LangChain Tools ---")
print(langchain_tools)

# --- 3. 初始化 LLM (以 DeepSeek 为例) ---
# 需要设置 DeepSeek 的 API Key 和 Base URL
# export OPENAI_API_KEY="YOUR_DEEPSEEK_API_KEY"
# export OPENAI_API_BASE="https://api.deepseek.com/v1"
llm = ChatOpenAI(model="deepseek-chat")

# --- 4. 创建 LangChain Agent ---
prompt = ChatPromptTemplate.from_messages(
    [
        ("system", "You are a helpful assistant."),
        ("user", "{input}"),
        MessagesPlaceholder(variable_name="agent_scratchpad"),
    ]
)

# 使用 LangChain 的标准方法创建 Agent
# 注意：这里我们并没有直接把 MCP 的 JSON Schema 给 Agent
# LangChain 会在内部从 Tool 对象重新构造
agent = create_openai_tools_agent(llm, langchain_tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=langchain_tools, verbose=True)


# --- 5. 运行 Agent ---
if __name__ == "__main__":
    result = agent_executor.invoke({"input": "What's the weather like in Paris?"})
    print("\n--- Final Answer ---")
    print(result["output"])

在运行这段代码之前，请确保：

你的 FastMCP 服务（uvicorn main:app）正在运行。
你已经在环境变量中设置了 DeepSeek 的 API Key 和 Base URL。

当你运行 langchain_mcp_integration.py 时，你会看到 verbose=True 打印出的 Agent 的思考过程：

Agent 看到用户问题 "What's the weather like in Paris?"。
它查看可用的工具，发现一个名为 weather.get_current_weather 的工具，其描述是 "A plugin to get weather information."，非常匹配。
它决定调用这个工具，并从问题中提取出参数 location="Paris"。
LangChain 的 Agent Executor 调用我们自定义的 Tool 的 func，也就是 _mcp_tool_wrapper。
_mcp_tool_wrapper 调用 mcp_client.invoke("mcp://weather/get_current_weather", location="Paris")。
请求被发送到我们的 FastMCP 服务，天气插件被执行，结果被返回。
Agent 得到工具的返回结果 {'location': 'Paris', 'temperature': 22, 'unit': 'celsius'}。
最后，Agent 基于这个结果，生成最终的自然语言回答：“The weather in Paris is 22°C.”

我们成功了！我们构建了一个 Agent 系统，其中：

大脑（DeepSeek LLM）和身体（天气查询插件）是完全解耦的。
它们通过一个标准化的协议（MCP） 进行通信。
我们可以轻易地替换大脑（比如换成 GPT-4）或增加新的身体（比如注册一个新的“计算器插件”），而无需修改任何一方的内部代码。

6. MCP 的设计哲学与未来展望

简单性 vs. 完备性：MCP 的设计取舍

MCP 的设计体现了强烈的 Unix 哲学：“做一件事，并把它做好”。它没有尝试去解决所有问题，比如服务发现、负载均衡、认证授权等，而是专注于定义 Agent 间交互的核心数据契约。

这种“小而美”的设计使得 MCP 非常容易理解和实现，但也意味着在生产环境中使用时，需要与其他工具（如 Nginx, Consul, API Gateway）结合，来构建一个完整的、鲁棒的系统。

服务发现与注册中心：MCP 生态的未来演进

在我们的例子中，MCP 客户端是硬编码了 Controller 的地址。在更复杂的系统中，我们需要一个服务注册与发现机制。

注册：每个 MCP Controller 启动时，可以向一个中央“注册中心”（如 Consul 或 Etcd）注册自己的地址和其提供的插件列表。
发现：客户端不再直连 Controller，而是先向注册中心查询：“谁能提供 mcp://weather/get_current_weather 这个工具？” 注册中心返回一个可用的 Controller 地址列表，客户端再进行连接。

这将使 MCP 生态系统变得更具弹性和可扩展性。

安全性考量：认证、授权与数据加密

FastMCP 基于 FastAPI，因此可以无缝利用 FastAPI 生态中的各种安全工具。你可以在 Controller 层面轻松地加入：

认证：使用 fastapi.Depends 和 OAuth2PasswordBearer 来确保只有合法的客户端才能调用工具。
授权：在 McpRequest 的 request_context 中传递用户信息，插件在执行敏感操作前进行权限检查。
数据加密：部署在标准的 HTTPS (TLS) 环境下，确保通信链路的加密。

MCP 与 Function Calling 的关系：互补而非替代

初学者可能会混淆 MCP 和 Function Calling。它们处于不同的抽象层次：

Function Calling：是 LLM 的一项原生能力。它定义了 LLM 如何表达“调用一个函数”的意图，并以特定格式（JSON Schema）描述函数。
MCP：是一个应用层的通信协议。它利用了 Function Calling 的思想，但将其规范化为一套基于 HTTP 的、跨语言、跨框架的 Agent 间交互标准。

你可以认为，MCP 是 Function Calling 思想在分布式、多智能体系统场景下的一个标准化、工程化的实现方案。它们是互补的，而非相互替代的关系。

7. 总结：构建可扩展、可维护的多智能体系统的第一步

通过本文的学习，我们不仅理解了 MCP 协议是什么，为什么需要它，更重要的是，我们亲手构建了一个完整的、遵循 MCP 规范的 Agent 应用。

掌握 MCP，意味着你开始用“架构师”的思维来审视 Agent 开发。你不再只是满足于让一个 Agent 跑起来，而是开始思考：

如何让我的系统解耦，降低维护成本？
如何让我的系统标准化，便于团队协作和能力复用？
如何让我的系统可扩展，能够平滑地接入未来成千上万的 Agent？

这正是从中级“AI 应用开发者”向高级“多智能体系统架构师”迈进的关键一步。在未来的 Agentic AI 世界里，懂得如何构建大规模、可协作的 Agent 系统的人，将拥有最核心的竞争力。

1.3 Agent 通信的“普通话”：MCP 协议深度解析与实战

目录