作为 AI 应用开发者，你一定被这样的场景折磨过：为客服、财务、人事开发智能助手，每个助手要调用查订单、算工资、查年假等工具，结果 ——
- OpenAI、Claude、Gemini 各有一套工具调用格式，N 个模型 ×M 个工具，要做 N×M 次适配；
- 工具逻辑写死在 Agent 代码里，换个项目要复制粘贴，改一处要改多处；
- 多轮对话记不住上下文，用户问 “明天呢”，Agent 一脸懵；
- 新增 / 下线工具要重新部署整个 Agent，业务部门提需求，开发疲于奔命。
直到 MCP（Model Context Protocol）出现，彻底解决了 AI 工具调用的 “碎片化” 问题 —— 它就像 AI 世界的 USB-C 接口，统一了所有模型和工具的通信标准，让工具即插即用、动态组合，让 AI 工作流从 “手工作坊式开发” 走向 “工业化标准化生产”。
这篇文章，不堆砌概念、不绕弯子，用 “道法术器” 四层逻辑，从 “为什么需要 MCP” 到 “怎么接入工作流”，把 MCP 彻底讲透。全程附带实战代码和配置示例，新手能快速上手，老手能查漏补缺，建议立刻收藏，开发、面试、复盘都能直接用。
第一步：问题的原点 —— 为什么需要 MCP？（先搞懂痛点，再学用法）
在 MCP 出现之前，AI 工具调用的核心问题是 “碎片化”，我们一步步还原当时的开发困境：
痛点 1：N×M 的适配灾难，重复劳动到崩溃
每个大模型都有自己的工具调用格式：
- OpenAI 用 Function Calling 格式；
- Claude 用 Tool Use 格式；
- Gemini 又有一套自定义格式。
开发一个 “查天气” 工具，要为每个模型单独适配参数格式、返回格式，N 个模型 ×M 个工具，就是 N×M 次重复工作，效率低到离谱。
痛点 2：工具与代码深度耦合，复用性为 0
工具逻辑和 Agent 代码绑死，比如：
python
运行
# 传统方式：工具逻辑写在Agent代码里
def get_weather(city):
return weather_api.call(city)
# 换项目要复制粘贴，改一处要改所有引用的地方
工具改一行代码，所有用到这个工具的 Agent 都要重新部署，维护成本极高。
痛点 3：上下文丢失，多轮对话像 “失忆”
用户第一轮问 “北京天气”，Agent 调用工具查到结果；第二轮问 “明天呢”，Agent 记不住上一轮查的是北京，得让用户重新说一遍，体验极差。
痛点 4：工具动态管理难，响应需求慢
业务部门今天要加 “查快递” 工具，明天要加 “算积分” 工具，每次都要修改 Agent 代码、重新部署，开发团队被频繁的需求打断，疲于奔命。
痛点 5：工作流僵化，无法动态组合工具
传统工作流是写死的 A→B→C，比如用户问 “订去北京的高铁票并确认差旅标准”，需要同时调用财务、差旅、人事三个工具，固定流程根本无法适配这种灵活需求。
核心结论
MCP 存在的唯一理由：解决 AI 工具调用 “碎片化、耦合高、无状态、不灵活” 的痛点 —— 通过标准化协议，统一工具调用接口，实现工具与 Agent 解耦、动态发现、上下文持久化，让 AI 工作流能灵活组合工具，适配多变的业务需求。
第二步：道的层面 ——MCP 的根本思想（懂道，才懂它的设计精髓）
“道” 是 MCP 的灵魂，回答 “为什么这么设计”，搞懂这 4 个核心思想，就抓住了 MCP 的本质，面试被问也能对答如流。
道 1：标准化接口 ——AI 的 USB-C 口（核心中的核心）
MCP 最核心的设计思想是：为大模型定义一个标准的 “插座”，让所有工具都能即插即用。
正如官方定义：“MCP is an open protocol that standardizes how applications provide context to large language models. Think of MCP like a USB-C port for AI applications.”
✅ 核心价值：
- 以前：每个模型（手机）有自己的插头，每个工具（充电器）有自己的插座，根本插不上；
- 现在：所有模型统一装 USB-C 口，所有工具统一配 USB-C 插头，随便插都能用。
道 2：关注点分离 ——Agent 只思考，不执行
MCP 的第二个核心理念是 “分离思考与执行”，彻底解耦 Agent 和工具：
plaintext
传统方式：Agent（思考+执行）→ 调用工具（写在代码里）
MCP方式：Agent（只思考）→ MCP Client → MCP Server（执行工具）
✅ 核心价值：
- Agent 轻量化：只做任务规划、工具选择，不用关心工具怎么实现；
- 工具独立化：工具可以单独部署、升级、维护，不影响 Agent；
- 复用性提升：一个 MCP Server 可以服务多个 Agent，不用重复开发工具。
道 3：动态发现 —— 工具即插即拔
MCP 的第三个理念是 “工具动态发现”，而非硬编码：
✅ 核心流程：
- Agent 启动时，主动询问 MCP Server：“你有什么工具？怎么用？”；
- Server 返回工具清单（名称、描述、参数格式）；
- Agent 根据清单动态决定调用哪个工具。
✅ 核心价值：新增 / 下线工具，只需更新 MCP Server，不用重新部署 Agent，响应业务需求的速度提升 10 倍。
道 4：上下文传递 —— 让对话有记忆
MCP 的第四个理念是 “上下文是一等公民”，解决多轮对话 “失忆” 问题：
✅ 核心流程：
- 每次工具调用请求，都携带完整上下文（用户 ID、会话 ID、历史记录）；
- MCP Server 执行完工具后，更新上下文（比如记录 “上次查询的城市是北京”）；
- 下一次调用时，Agent 带着更新后的上下文，能理解用户的模糊指令。
✅ 核心价值：多轮对话保持状态连续，用户体验大幅提升。
第三步：法的层面 ——MCP 的核心方法论（懂法，才会用对 MCP）
“法” 是实现 “道” 的路径和方法论，回答 “怎么做”，这 5 个方法论，是 MCP 简化 AI 工具调用的核心，也是面试高频考点。
法 1：Client-Server 架构（MCP 的基础骨架）
MCP 采用标准的客户端 - 服务器架构，分工明确、通信清晰：
plaintext
┌─────────────────────────────────────────────────┐
│ MCP Client │
│ （AI Agent、IDE、聊天客户端等） │
│ - 发起请求 │
│ - 接收响应 │
│ - 管理会话 │
└─────────────────────┬───────────────────────────────┘
│ MCP协议
▼
┌─────────────────────────────────────────────────┐
│ MCP Server │
│ （工具提供方） │
│ - 注册工具 │
│ - 执行工具 │
│ - 管理上下文 │
└─────────────────────────────────────────────────┘
核心角色说明：
- Client（客户端） ：内置大模型的调用方（Claude Desktop、Cursor、VS Code、自研 Agent），是 “思考者”；
- Server（服务端） ：提供工具的服务方（开发者主要开发这部分），是 “执行者”。
法 2：三大核心能力 ——Tools、Resources、Prompts
MCP Server 对外暴露三种核心能力，覆盖 AI 工具调用的全场景：
表格
| 能力 | 核心作用 | 通俗类比 |
|---|---|---|
| Tools（工具） | 可执行的动作（查天气、查股价、算工资） | 给 Agent 的 “手”，能做事 |
| Resources（资源） | 可读取的结构化数据（可选项列表、预加载数据） | 给 Agent 的 “眼睛”，能看东西 |
| Prompts（提示词） | 可复用的指令（指导 LLM 推理、解释结果） | 给 Agent 的 “脑子”，知道怎么想 |
✅ 核心重点：Tools 是核心，每个 Tool 有唯一名称、描述、输入 / 输出参数格式，是 Agent 完成具体任务的核心载体。
法 3：两种传输模式 —— 本地与远程
MCP 支持两种通信方式，适配不同开发 / 部署场景：
表格
| 传输模式 | 通信方式 | 适用场景 | 优势 |
|---|---|---|---|
| STDIO（本地） | 标准输入输出 | 本地开发、个人使用 | 安全、高效、无需网络 |
| Streamable HTTP（远程） | 基于 HTTP 的流式传输 | 云端部署、多用户访问 | 跨网络、支持服务端主动推送 |
注意：早期 MCP 支持 SSE（服务器发送事件），现已废弃，统一改用 Streamable HTTP。
法 4：工具动态发现机制（MCP 的 “即插即用” 核心）
Client 启动时，通过/registry接口拉取 Server 的工具清单，示例如下：
json
// Client请求：GET /registry
// Server响应：
{
"tools": [
{
"name": "get_weather",
"description": "查询城市天气",
"parameters": {
"city": {"type": "string", "required": true},
"unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
}
}
]
}
✅ 核心价值：Agent 无需硬编码工具信息，新增工具后，Client 重启就能识别，无需改代码。
法 5：上下文传递协议（MCP 区别于普通 RPC 的关键）
MCP 的请求 / 响应格式，核心是携带上下文，示例如下：
json
// 请求格式（Client → Server）
{
"context": {
"user_id": "u123",
"session_id": "s456",
"history": ["用户：查北京天气", "Agent：调用get_weather工具"]
},
"tool_name": "get_weather",
"parameters": {"city": "北京"}
}
// 响应格式（Server → Client）
{
"result": {"temp": 25, "condition": "sunny"},
"updated_context": {"last_city": "北京", "last_query_time": "2026-03-14 10:00"}
}
✅ 核心价值：上下文在 Client 和 Server 之间闭环传递，多轮对话不再 “失忆”。
第四步：术的层面 —— 工作流接入 MCP 的具体技术（懂术，能解决实际问题）
“术” 是具体的技术技巧，回答 “用什么工具实现”，掌握这些，你能快速开发 MCP Server、接入工作流，解决实际开发中的问题。
术 1：工作流接入 MCP 的三种典型模式
根据业务场景不同，工作流接入 MCP 有三种核心模式，覆盖 90% 的开发需求：
模式一：Agent 调用 MCP Tool（最常用）
plaintext
用户问题 → Agent规划 → 调用MCP Client → MCP Server执行 → 返回结果
↓
工具1、工具2...
✅ 示例：股票分析助手
- Agent 收到 “分析招商银行股票”；
- 调用 “股价分析” MCP Tool，获取股价数据；
- 调用 “新闻分析” MCP Tool，获取相关新闻；
- 调用 “报告生成” MCP Tool，汇总结果生成投资建议。
模式二：工作流节点调用 MCP
plaintext
工作流节点1 → 调用MCP Server A
工作流节点2 → 调用MCP Server B
工作流节点3 → 聚合结果
✅ 示例：MaxKB 集成 MCP
- 将 MaxKB 知识库封装成 MCP Tool；
- 在可视化工作流中配置 MCP 调用节点；
- 大模型根据用户问题，动态调用对应的知识库工具。
模式三：MCP Server 嵌套调用
plaintext
MCP Server A → 调用 MCP Server B
→ 调用 MCP Server C
✅ 核心价值：实现工具链组合，比如 “查快递” 工具可以嵌套调用 “查物流轨迹” 和 “查快递公司联系方式” 两个子工具。
术 2：快速开发 MCP Server（FastMCP 框架实战）
FastMCP 是 Python 生态中最易用的 MCP 开发框架，用装饰器就能快速开发 MCP Server，示例如下：
python
运行
# 安装依赖
# pip install fast-mcp
from mcp.server.fastmcp import FastMCP
# 1. 创建MCP服务器实例
mcp = FastMCP("Weather Tools Server")
# 2. 注册工具（装饰器自动生成工具描述）
@mcp.tool()
def get_weather(city: str, unit: str = "celsius") -> str:
"""
获取指定城市的天气信息
参数：
- city: 城市名称（必填）
- unit: 温度单位，可选值：celsius（摄氏度）、fahrenheit（华氏度），默认celsius
返回：
格式化的天气信息字符串
"""
# 实际开发中替换为真实天气API调用
temp = 25 if unit == "celsius" else 77
return f"Weather in {city}: {temp}°{unit[:1].upper()}, sunny"
# 3. 运行服务器（默认监听stdio，也可指定HTTP端口）
if __name__ == "__main__":
mcp.run() # 本地模式：stdio通信
# mcp.run(host="0.0.0.0", port=8080) # 远程模式：HTTP通信
✅ FastMCP 自动处理：
- 初始化 Server；
- 生成工具发现接口（/registry）；
- 处理请求路由；
- JSON-RPC 序列化 / 反序列化。
术 3：MCP Server 的配置与连接
不同客户端接入 MCP Server 的配置方式不同，这里以 VS Code/Cursor 为例，展示核心配置：
json
// settings.json 配置示例
{
"mcpServers": {
// 本地MCP Server（stdio模式）
"weather-server": {
"command": "python",
"args": ["/path/to/weather_server.py"]
},
// 远程MCP Server（HTTP模式）
"jina-server": {
"url": "https://mcp.jina.ai/sse",
"headers": {
"Authorization": "Bearer ${JINA_API_KEY}"
}
}
}
}
✅ 环境变量管理（生产环境必备）：
python
运行
from dotenv import load_dotenv
import os
# 加载.env文件中的环境变量（API密钥、数据库地址等）
load_dotenv()
JINA_API_KEY = os.environ.get("JINA_API_KEY")
WEATHER_API_KEY = os.environ.get("WEATHER_API_KEY")
术 4：工作流编排中的 MCP 调用（实战伪代码）
以股票分析工作流为例，展示如何在代码中调用多个 MCP Server：
python
运行
# 安装MCP Client依赖：pip install mcp-client
from mcp.client import MCPClient
class StockAnalysisWorkflow:
def __init__(self):
# 初始化多个MCP客户端，连接不同的MCP Server
self.price_client = MCPClient("http://localhost:8081") # 股价MCP Server
self.news_client = MCPClient("http://localhost:8082") # 新闻MCP Server
self.report_client = MCPClient("http://localhost:8083") # 报告MCP Server
# 初始化会话上下文
self.context = {
"user_id": "user_001",
"session_id": "session_123",
"history": []
}
def analyze_stock(self, stock_code: str) -> str:
"""分析指定股票，返回分析报告"""
# 1. 调用股价MCP Tool
price_result = self.price_client.call_tool(
tool_name="get_stock_price",
parameters={"code": stock_code, "level": "detail"},
context=self.context
)
# 更新上下文
self.context["last_stock_code"] = stock_code
self.context["history"].append(f"查询股价：{price_result}")
# 2. 调用新闻MCP Tool
news_result = self.news_client.call_tool(
tool_name="get_stock_news",
parameters={"code": stock_code, "days": 7},
context=self.context
)
self.context["history"].append(f"查询新闻：{news_result}")
# 3. 调用报告生成MCP Tool
report = self.report_client.call_tool(
tool_name="generate_stock_report",
parameters={"price_data": price_result, "news_data": news_result},
context=self.context
)
return report
# 调用示例
if __name__ == "__main__":
workflow = StockAnalysisWorkflow()
report = workflow.analyze_stock("600036") # 招商银行股票代码
print(report)
术 5：MCP Server 的日志与调试（生产环境必备）
完善的日志是排查问题的关键，以下是 MCP Server 的日志配置示例：
python
运行
import logging
import sys
from mcp.server.fastmcp import FastMCP
# 配置日志
logger = logging.getLogger("mcp-weather-server")
logger.setLevel(logging.INFO)
# 日志格式
formatter = logging.Formatter(
"%(asctime)s - %(name)s - %(levelname)s - %(message)s",
datefmt="%Y-%m-%d %H:%M:%S"
)
# 1. 文件日志（持久化存储）
file_handler = logging.FileHandler("mcp_server.log", encoding="utf-8")
file_handler.setFormatter(formatter)
logger.addHandler(file_handler)
# 2. 控制台日志（实时调试）
console_handler = logging.StreamHandler(sys.stdout)
console_handler.setFormatter(formatter)
logger.addHandler(console_handler)
# 禁用日志向上传播（避免重复输出）
logger.propagate = False
# 创建MCP Server
mcp = FastMCP("Weather Tools Server")
@mcp.tool()
def get_weather(city: str, unit: str = "celsius") -> str:
logger.info(f"开始查询城市[{city}]的天气，单位[{unit}]")
try:
temp = 25 if unit == "celsius" else 77
result = f"Weather in {city}: {temp}°{unit[:1].upper()}, sunny"
logger.info(f"查询完成，结果：{result}")
return result
except Exception as e:
logger.error(f"查询天气失败：{str(e)}", exc_info=True)
return f"查询失败：{str(e)}"
if __name__ == "__main__":
logger.info("MCP Weather Server 启动成功")
mcp.run()
术 6：MCP 与 Function Calling 的协同（核心认知）
很多开发者会问：MCP 和 Function Calling 有什么关系？
结论：MCP 不是取代 Function Calling，而是为它提供标准化的基础设施。
表格
| 层次 | 技术 | 核心职责 |
|---|---|---|
| 协议层 | MCP | 标准化工具描述、调用格式、上下文传递 |
| 调用层 | Function Calling | 在具体对话中选择、编排工具，与大模型交互 |
✅ 一句话总结：MCP 让能力变成标准化、可插拔的 “基础设施”，Function Calling 让这些能力在具体对话中被智能地选择与编排。
第五步：器的层面 ——MCP 生态的工具箱（懂器，能高效开发）
“器” 是 MCP 的具体工具和组件，回答 “有哪些东西可以用”，这些工具覆盖开发、部署、调试全流程，开箱即用，大幅提升效率。
器 1：MCP SDK 与开发框架（开发必备）
表格
| 框架 / SDK | 语言 | 核心特点 | 适用场景 |
|---|---|---|---|
| FastMCP | Python | 装饰器风格、快速开发、自动生成工具描述 | 快速原型、小型项目 |
| MCP Python SDK | Python | 官方 SDK、功能完整、支持自定义扩展 | 生产环境、复杂项目 |
| MCP Node.js SDK | JS/TS | 官方支持、适配 Node.js 生态 | 前端 / 全栈项目 |
| MCP CLI 工具 | 跨平台 | 调试、测试 MCP Server、模拟请求 | 开发调试 |
器 2：MCP Server 实现示例（开箱即用）
示例 1：天气 MCP Server（最小示例）
python
运行
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Weather")
@mcp.tool()
def get_weather(city: str) -> str:
"""获取城市天气"""
return f"{city}: 22度，晴"
mcp.run()
示例 2：股票 MCP Server（对接真实数据）
python
运行
import akshare as ak # A股数据库
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Stock Tools")
@mcp.tool()
def get_stock_price(code: str, level: str = "brief") -> dict:
"""
获取A股实时行情
参数：
- code: 股票代码（如600036）
- level: 返回级别，brief（简要）/detail（详细）
返回：
股价数据字典
"""
stock_zh_a_spot_df = ak.stock_zh_a_spot()
stock_data = stock_zh_a_spot_df[stock_zh_a_spot_df["代码"] == code].iloc[0].to_dict()
if level == "brief":
return {
"code": code,
"name": stock_data["名称"],
"price": stock_data["最新价"],
"change": stock_data["涨跌幅"]
}
return stock_data
mcp.run(host="0.0.0.0", port=8081)
器 3：MCP 客户端 / 宿主（调用方）
表格
| 客户端 | 类型 | 核心特点 | 适用场景 |
|---|---|---|---|
| Claude Desktop | 桌面应用 | 原生支持 MCP、体验好 | 个人开发、本地测试 |
| Cursor | IDE | 内置 MCP、AI 编程专用 | 代码开发、工具调用 |
| VS Code + Copilot | IDE | 可配置 MCP、生态丰富 | 企业级开发、团队协作 |
| OpenCode | IDE | 国产 IDE、深度适配 MCP | 国内开发者、本地化部署 |
| Dify | 工作流平台 | 可视化编排、支持 MCP 调用 | 低代码开发、业务流程搭建 |
| MaxKB | 知识库系统 | 可发布为 MCP、知识库调用 | 企业知识库、问答系统 |
器 4：MCP 公共服务广场（现成工具）
不用重复造轮子，直接调用公共 MCP 服务：
腾讯 MCP 广场
- AI Word 文档助手：文档解析、编辑、生成；
- 微信读书：书籍内容检索、摘要；
- MySQL 数据库：数据库查询、操作；
- 腾讯云代码分析：代码质量检测、漏洞扫描。
Jina AI MCP Server
search_web：联网搜索；read_url：网页内容转 Markdown；search_arxiv：学术论文检索；sort_by_relevance：结果重排序；deduplicate_strings：文本去重。
器 5：MCP 相关生态项目（进阶工具）
MCO Protocol（编排层）
在 MCP 之上解决 Agent 执行不可靠的问题，核心能力：
- 渐进式揭示：分步骤给 Agent 注入能力，避免信息过载；
- SNLP：结构化自然语言编程，规范 Agent 执行逻辑；
- 持久记忆：跨步骤保持上下文，支持长流程执行。
✅ 核心定位：
plaintext
MCP → 数据接入（有什么工具）
A2P → Agent通信（怎么协作）
MCO → 可靠执行（怎么真正做完）
第六步：用比喻理解工作流接入 MCP（道法术器全打通）
很多人觉得 MCP 复杂，其实用 “智能工厂” 的比喻，就能轻松理解四层逻辑：
道的层面：工厂的经营理念（为什么这么做）
- 标准化接口（USB-C）：所有机器（模型）统一装 USB-C 口，所有工具（设备）统一配 USB-C 插头，随便插都能用；
- 关注点分离：厂长（Agent）只下指令，车间工人（MCP Server）只干活，各司其职；
- 动态发现：车间新增设备（工具），实时上报给厂长，厂长不用重新培训；
- 上下文传递：厂长说 “查北京天气”，工人做完记下来，下次说 “明天呢”，工人知道指北京。
法的层面：工厂的运营流程（怎么做）
- Client-Server 架构：厂长办公室（Client）和车间（Server）分开，用标准文件（协议）沟通；
- 三大能力：车间有机器臂（Tools）、显示屏（Resources）、操作手册（Prompts）；
- 两种通信：本地车间用对讲机（STDIO），远程车间用电话（HTTP）；
- 动态发现：每天开工前，厂长问车间 “有哪些设备能用”，车间给清单；
- 上下文传递：每次指令附 “工作日志”，工人做完更新日志还给厂长。
术的层面：工厂的操作技巧（具体怎么实现）
- FastMCP 框架：车间设备的标准化说明书模板，填表就能用；
- MCP 配置：厂长办公室的通讯录，记下班车间地址和对接方式；
- 工作流编排：厂长安排 “查股价→查新闻→写报告” 的流水线；
- 日志调试：车间配记录员，记下每一步操作，出问题好排查。
器的层面：工厂的工具套件（用什么做）
- 开发工具：车间建设工具箱（FastMCP、SDK）；
- 客户端：各种厂长办公室（Claude Desktop、Cursor）；
- 公共服务：共享车间集群（腾讯 MCP 广场、Jina AI）；
- 编排工具：车间调度系统（MCO Protocol）。
第七步：MCP 接入工作流的本质是什么？（第一性原理总结）
用第一性原理来看，工作流接入 MCP 的本质是：通过标准化的协议层，将工作流中的 “任务规划” 与 “工具执行” 解耦，实现工具的动态发现、即插即用和跨模型共享，让 AI 应用开发从 “手工作坊” 走向 “工业化生产”。
它的核心价值可以概括为：
表格
| 价值维度 | 解决的问题 | MCP 的实现 |
|---|---|---|
| 标准化 | N×M 适配灾难 | 统一协议，一套工具适配所有模型 |
| 解耦 | 工具与代码深度耦合 | Client-Server 分离，工具独立部署 |
| 动态性 | 工具管理困难 | 动态发现机制，新增工具无需改代码 |
| 状态化 | 上下文丢失 | 上下文传递协议，多轮调用保持状态 |
| 灵活性 | 工作流僵化 | 动态组合工具，适应多变需求 |
从道法术器四个层次，总结 MCP 的核心：
表格
| 层次 | 核心内容 | 一句话总结 |
|---|---|---|
| 道 | 标准化接口、关注点分离、动态发现、上下文传递 | AI 的 USB-C 口，即插即用 |
| 法 | Client-Server 架构、三大能力、两种传输、动态发现机制 | 标准化的通信和协作方式 |
| 术 | FastMCP 开发、工作流编排、日志调试、配置管理 | 具体的技术实现技巧 |
| 器 | SDK、客户端、公共服务、编排工具 | 开箱即用的工具套件 |
✅ 关键提醒：MCP 不是要取代 Function Calling，而是为它提供标准化的基础设施 —— 正如 USB-C 没有取代充电技术，而是让充电变得更简单。当工作流接入 MCP，你不再需要为每个模型适配工具，不再需要把工具逻辑写死在 Agent 里，只需开发一次 MCP Server，就能在任何支持 MCP 的客户端中即插即用。
总结：MCP 道法术器速查表（收藏备用）
表格
| 层次 | 核心内容 | 核心价值 |
|---|---|---|
| 道 | 标准化接口、关注点分离、动态发现、上下文传递 | 理解设计理念，知道 “为什么这么做” |
| 法 | Client-Server 架构、三大能力、两种传输、动态发现机制 | 掌握核心方法，知道 “怎么做” |
| 术 | FastMCP 开发、工作流编排、日志调试、配置管理 | 解决实际问题，掌握 “具体实现” |
| 器 | SDK、客户端、公共服务、编排工具 | 用好生态工具，提升开发效率 |
🔥 互动话题
开发 AI 应用时，你最头疼的工具调用问题是什么？
- 不同模型的工具格式适配，重复劳动多
- 多轮对话上下文丢失，用户体验差
- 新增工具要重新部署 Agent，响应需求慢
- 工作流编排复杂，难以动态组合工具
- 面试被问 MCP 原理，答不上来
评论区留下你的痛点，我会挑高频问题，下期专门出《MCP 实战避坑指南》，手把手教你解决，还会附赠 MCP 面试高频题合集，帮你轻松应对面试！
