从 FastAPI 到 FastMCP：Python API 与 MCP 框架的发展

前言

Python Web 开发曾经关注的是“怎样更快地写一个 HTTP 接口”，进入大模型与 Agent 时代以后，问题又变成了“怎样把现有系统的能力安全、清晰地交给 AI 使用”。FastAPI 和 FastMCP 分别出现在这两个阶段，却又在类型提示、自动生成接口和开发体验等方面产生了自然的联系。

FastAPI 面向浏览器、移动应用和后端服务，用路径、请求与响应描述 Web API；MCP（Model Context Protocol，模型上下文协议）面向 AI 应用，用工具、资源和提示词描述模型可以发现与调用的能力；FastMCP 则用更符合 Python 开发习惯的方式降低了构建 MCP 客户端和服务器的门槛。

本文沿着 FastAPI → MCP Python SDK → FastMCP 的发展顺序，梳理三者的由来、架构与关系，并说明现有 FastAPI 项目如何接入 MCP。文章基于 2026 年 7 月 29 日可以查到的官方资料，具体版本仍会继续变化。

FastAPI 出现之前：Python API 开发的问题

Python 很早就拥有 Django、Flask、Tornado 等成熟 Web 框架。Django 功能完整，适合构建包含数据库、模板和后台管理的 Web 应用；Flask 简洁灵活，开发者可以自由选择扩展。但是当 API 越来越强调类型、数据校验、接口文档和前后端协作时，传统方式容易产生几份相互重复的信息：

• 函数参数中写一遍字段。
• 校验逻辑中再写一遍类型和约束。
• 序列化代码中描述一遍输出结构。
• OpenAPI 文档里继续维护一遍接口定义。
• 编辑器仍不一定知道运行时数据究竟是什么类型。

同一份信息散落在多个地方，修改字段时就可能漏改文档或校验规则。FastAPI 的重要价值并不是让 Python 首次拥有 API 框架，而是把标准 Python 类型提示变成接口设计的中心。

FastAPI 的诞生与设计思路

FastAPI 的首个 PyPI 版本 0.1.0 发布于 2018 年 12 月。根据其官方历史说明，作者在实现框架之前研究了 OpenAPI、JSON Schema、OAuth2 等已有标准，并分析了不同 Python 框架的优缺点。最终方案没有重新发明底层 Web 服务器，而是建立在两个项目之上：

• Starlette 负责 ASGI、路由、中间件、WebSocket 等 Web 能力。
• Pydantic 读取类型提示，完成数据解析、验证与 Schema 生成。

一个最小的 FastAPI 应用可以非常短：

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title="Book API")


class Book(BaseModel):
    title: str
    price: float


@app.post("/books")
async def create_book(book: Book) -> Book:
    return book

这里的 Book 不只是编辑器里的类型声明。FastAPI 会用它校验请求数据、生成 JSON Schema、描述响应，并据此生成 OpenAPI 文档。运行应用后，开发者通常可以直接访问 Swagger UI 或 ReDoc 查看和调试接口。

这种设计带来了几个持续影响 Python API 开发的特点：

1. 类型提示成为单一事实来源。 类型、校验、文档和编辑器补全由同一份声明派生。
2. 异步能力自然融入框架。 普通函数和 async def 都可以使用，适合 I/O 密集型服务。
3. 默认遵循开放标准。 OpenAPI 与 JSON Schema 让接口能够被前端工具、代码生成器和其他平台识别。
4. 开发体验成为框架目标。 自动补全、错误定位和少量重复代码并非附加功能，而是核心取舍。

FastAPI 后来被广泛用于微服务、机器学习推理接口和 AI 应用后端。不过它解决的仍主要是 HTTP API 问题：客户端必须知道有哪些路径、如何认证以及怎样组织请求。

从新框架到 Python API 基础设施

FastAPI 在 2018 年发布后并没有改变“类型提示 + OpenAPI”的核心方向，而是持续补齐依赖注入、安全认证、后台任务、WebSocket、生命周期管理和部署文档，并跟随 Starlette、Pydantic 及 Python 类型系统演进。截至本文写作时，PyPI 上的最新版本为 0.140.13。

版本号仍处于 0.x 并不意味着它只是实验项目。FastAPI 已经形成稳定、庞大的用户与工具生态，许多库能够直接读取它生成的 OpenAPI 文档。另一方面，Pydantic 等核心依赖发生大版本变化时，应用仍应认真阅读迁移指南、锁定版本并运行测试。FastAPI 的发展说明：框架真正产生长期影响的部分，不只是性能，而是让标准类型信息在编辑器、运行时校验、文档和生态工具之间流动。

大模型时代为什么还需要 MCP

大模型应用最初连接外部能力时，每个平台都有自己的函数调用格式、插件协议和工具定义。开发者如果希望同一个数据库、文件系统或业务服务同时供多个 AI 客户端使用，往往需要重复适配。

Anthropic 在 2024 年 11 月 25 日开源并发布 MCP，希望用一套开放协议标准化 AI 应用与外部数据、工具之间的连接。初始发布包括协议规范、SDK、Claude Desktop 支持和示例服务器。此后 MCP 逐渐被更多客户端、Agent 框架和编程工具采用。

MCP 通常包含两端：

• MCP 客户端位于 AI 应用一侧，负责连接服务器、发现能力和发起调用。
• MCP 服务器封装文件、数据库、搜索、业务 API 等外部能力，并按照协议暴露给客户端。

服务器提供的核心组件不只有“执行函数”：

MCP 组件	用途	例子
Tools（工具）	由模型决定是否调用，执行操作或计算	查询订单、创建工单、运行安全扫描
Resources（资源）	向客户端提供可读取的上下文数据	配置文件、知识库文档、数据库记录
Prompts（提示词）	提供可复用的交互模板	代码审查模板、故障分析流程

MCP 并没有取代 HTTP、数据库协议或操作系统接口。它更像 AI 应用面前的一层统一插座：服务器内部仍可以调用 REST API、读取文件或连接数据库，外部则以模型能够发现和理解的方式描述这些能力。

MCP Python SDK：协议的官方实现

MCP Python SDK 是 MCP 的官方 Python 实现，其 PyPI 包名为 mcp。它提供客户端、服务器、传输层、会话管理和协议类型等基础能力，让 Python 程序不必手工处理所有 JSON-RPC 消息。

这里有一个容易混淆的历史细节：FastMCP 1.0 在发布后很快被贡献给官方 Python SDK。因此，开发者会在官方包中看到下面的导入方式：

from mcp.server.fastmcp import FastMCP

它代表的是 进入官方 SDK 的 FastMCP 1.0 设计。而后来快速发展的 FastMCP 2.x、3.x 和 4.x 使用独立的 fastmcp 包：

from fastmcp import FastMCP

两个项目有直接的历史关系，但不能仅凭类名相同就把教程、依赖版本和导入路径混用。官方 SDK 更接近协议的基础实现；独立 FastMCP 则在 SDK 之上提供更高层的开发体验和框架能力。

FastMCP 1.0：让 MCP 服务器更像普通 Python

FastMCP 由 Prefect 创始人 Jeremiah Lowin 创建，1.0 于 2024 年 12 月 1 日发布。它的出发点很直接：早期 MCP 服务器需要编写不少协议相关代码，而 Python 开发者真正关心的是“把哪个函数交给 AI，以及函数需要什么参数”。

FastMCP 使用装饰器读取函数名称、类型提示和文档字符串，再生成 MCP 工具定义。这与 FastAPI 从类型提示生成 API Schema 的思路相似。一个基础服务器可以写成：

from fastmcp import FastMCP

mcp = FastMCP("Calculator")


@mcp.tool
def add(a: int, b: int) -> int:
    """计算两个整数之和。"""
    return a + b


if __name__ == "__main__":
    mcp.run()

工具的参数、返回值和说明都靠普通 Python 信息表达。2024 年 12 月 3 日，项目宣布 FastMCP 1.0 将加入官方 MCP Python SDK。FastMCP 因此既成为 SDK 的一部分，也验证了“高级 Pythonic API”对 MCP 开发生态的重要性。

FastMCP 2.x：从服务器封装发展成完整框架

独立 FastMCP 项目没有停在 1.0。2025 年 4 月 16 日发布的 FastMCP 2.0 扩大了框架边界：它不再只是创建服务器的装饰器工具，还加入客户端、服务器组合、代理、传输转换，以及从 OpenAPI/FastAPI 生成 MCP 服务器的能力。

2.x 的演进可以概括为几个阶段：

• 2.0：客户端与组合能力。 服务器可以组合本地或远程 MCP 服务，也可以代理其他服务器，把不同传输方式连接起来。
• 2.3：Streamable HTTP。 跟进 MCP 新的 HTTP 传输方式，改善远程部署体验。
• 2.6：一等认证能力。 框架开始系统处理远程服务中的身份认证问题。
• 2.9：MCP 原生中间件。 日志、错误处理、限流等横切逻辑可以进入统一处理链。
• 2.10：跟进 2025-06-18 协议。 支持结构化输出、elicitation 等协议能力。
• 2.13：状态、缓存与 OAuth 成熟。 面向长期运行和生产部署继续完善。
• 2.14：后台任务。 以任务形式运行耗时操作，并跟踪进度和结果。

这一阶段的核心变化是：FastMCP 开始处理真实系统中的连接、认证、组合和运维问题。它从“快速写一个工具”逐渐变成能够组织多个 MCP 服务的应用框架。

FastMCP 3.x：Provider 与 Transform 架构

FastMCP 3.0 稳定版于 2026 年 2 月 18 日发布。对普通使用者来说，熟悉的 @mcp.tool 装饰器仍然存在；对框架内部而言，组件来源和组件处理方式则被重新抽象为 Provider（提供者） 与 Transform（转换器）。

Provider 回答“工具、资源和提示词从哪里来”。它们既可以来自代码装饰器，也可以来自文件系统、OpenAPI 文档或被代理的远程服务器。Transform 回答“这些组件在交给客户端之前怎样变化”，可以进行重命名、添加命名空间、过滤、版本控制或可见性管理。

装饰器 / 文件系统 / OpenAPI / 远程 MCP
                    │
                 Provider
                    │
       rename / namespace / filter / auth
                    │
                 Transform
                    │
             MCP 客户端与 Agent

这套架构解决了大型 MCP 服务中的几个问题：

1. 能力不必全部硬编码在同一个服务器文件中。
2. 多个来源可以通过统一方式组合。
3. 同一组工具可以按环境、版本或用户权限改变名称和可见范围。
4. 框架扩展不再依赖不断增加特殊参数，而是通过提供者和转换器组合。

3.x 随后的版本继续扩展这条路线：3.2.0 引入 FastMCPApp 和交互式 UI 工具；3.3.0 推出 fastmcp-slim，让只需要客户端和传输层的项目不必安装完整的 Starlette、Uvicorn 等服务端依赖；3.4.0 又加入 fastmcp-remote，用于把远程 HTTP MCP 服务桥接到只支持 stdio 的宿主。截至本文写作时，3.4.5 是稳定维护版本。

FastMCP 4.0 Beta：与 MCP Python SDK 2.0 重新对齐

2026 年 7 月 28 日，FastMCP 发布了 4.0.0b1。它建立在稳定的 MCP Python SDK 2.0 之上，并跟进新的 sessionless 协议，同时保留对旧会话握手方式的兼容。会话状态被整理为 UserSession 与 SessionId，后台任务拆分至 fastmcp-tasks，扩展则可以通过 add_extension() 接入。

这说明 FastMCP 与官方 SDK 的关系正在进入新阶段：1.0 的高级 API 曾进入官方 SDK，后续独立项目扩展出更完整的框架，而 4.0 又重新建立在 SDK 2.0 稳定基础之上。

不过 4.0.0b1 仍是 Beta，不应被写成当前生产环境的默认选择。新项目如果追求稳定，应优先参考 3.4.x 文档；只有准备验证新协议、扩展 API 或迁移兼容性的项目，才适合在隔离环境评估 4.0 Beta。

FastAPI 与 FastMCP 有什么区别

FastAPI 与 FastMCP 都会读取 Python 类型提示，也都能减少接口声明的重复代码，但它们服务的客户端和抽象层不同。

维度	FastAPI	FastMCP
主要使用者	浏览器、移动应用、前后端服务	AI 客户端、Agent、编程工具
核心抽象	路由、请求、响应、依赖	工具、资源、提示词、会话
常见协议	HTTP + OpenAPI	MCP over stdio / HTTP
调用方式	客户端通常明确请求某个 URL	模型可根据描述选择工具或读取资源
典型用途	REST API、微服务、业务后端	向 AI 暴露业务能力和上下文
是否互相替代	否	否

如果一个订单接口需要同时服务网站与 AI 助手，通常没有必要在 FastAPI 和 FastMCP 之间二选一。更合理的做法是把订单规则放在独立业务层，再分别提供 HTTP 与 MCP 入口。

网站 / 移动端 ──> FastAPI ──┐
                             ├──> 业务服务 ──> 数据库 / 第三方系统
AI 客户端 ─────> FastMCP ───┘

这样可以避免 MCP 工具通过本机 HTTP 反复调用自己的 FastAPI，也避免两套入口各自复制业务规则。认证、审计和输入约束则应针对 HTTP 用户与 AI Agent 的风险分别设计。

从现有 FastAPI 生成 FastMCP 服务

当项目已经拥有结构清晰的 FastAPI 路由时，FastMCP 可以读取应用生成的 OpenAPI 规范，并将路由转换成 MCP 组件。按照 FastMCP 的官方 FastAPI 集成文档，基础方式如下：

from fastapi import FastAPI
from fastmcp import FastMCP

app = FastAPI(title="E-commerce API")


@app.get("/products/{product_id}")
async def get_product(product_id: int):
    return {"id": product_id, "name": "Keyboard"}


mcp = FastMCP.from_fastapi(app=app, name="E-commerce MCP")
mcp_app = mcp.http_app(path="/mcp")

combined_app = FastAPI(
    title="E-commerce API with MCP",
    routes=[*mcp_app.routes, *app.routes],
    lifespan=mcp_app.lifespan,
)

默认情况下，OpenAPI 路由会映射为 MCP 工具。项目还可以使用 route maps，把匹配的 GET 路由转换为资源或资源模板，或者排除不应暴露给 AI 的内部路径。

自动转换很方便，但“能转换”不等于“应该全部暴露”。传统 REST API 常包含后台管理、批量删除、内部调试和字段过多的接口；它们的命名与描述也未必适合模型理解。生产环境至少需要检查：

• 工具名称和描述是否清楚，模型能否正确选择。
• 写操作是否需要用户确认、幂等键或更严格权限。
• 返回内容是否包含隐私数据、内部字段或过大的响应。
• OpenAPI 中的认证方式能否正确映射到 MCP 部署。
• 哪些路由应成为工具，哪些更适合资源，哪些必须排除。

另一个依赖细节是：FastAPI 并不是 FastMCP 的默认依赖。如果要使用这项集成，需要在项目中单独安装 FastAPI。

MCP 服务器的生产化问题

用装饰器写出第一个工具并不难，真正困难的是让它在生产环境中长期、可控地运行。随着 FastMCP 的发展，框架新增的认证、中间件、状态、任务和可观测性能力，本质上都在回答下面的问题。

权限不能只做到“连上就能用”

同一个 MCP 服务器可能同时包含查询和修改工具。系统需要判断当前用户是谁、能够访问哪些资源，以及某次写操作是否超出权限。工具列表本身也可能包含敏感业务信息，因此组件的发现与调用都要考虑授权。

工具描述也是接口设计

普通 API 的调用者是程序员，MCP 工具的直接选择者可能是模型。模糊的名称、缺失的参数说明或一次承担过多职责的工具，都会增加误调用概率。一个好的 MCP 工具应当目标单一、输入明确、返回结构稳定，并准确描述副作用。

长任务需要进度、取消和恢复

代码扫描、数据分析和批量处理可能运行数分钟。让一次 HTTP 请求一直等待并不可靠，任务系统需要提供状态查询、取消、失败重试和结果存储。FastMCP 2.14 之后对后台任务的探索，正是框架从示例服务走向真实工作负载的表现。

Agent 的输入同样不可信

工具参数可能来自用户内容、网页或其他服务器返回值。服务端仍要校验路径、防止命令注入、限制网络目标并记录关键操作。MCP 统一了连接方式，但不会自动消除越权、提示词注入和供应链风险。

版本选择建议

截至 2026 年 7 月，Python 开发者可以按需求选择不同层级：

需求	建议
需要紧贴 MCP 协议、控制底层行为	使用官方 mcp Python SDK
想快速开发完整 MCP 客户端或服务器	使用独立 fastmcp 稳定版 3.4.x
已有 FastAPI/OpenAPI，希望增加 AI 入口	使用 FastMCP 的集成能力，并人工筛选路由
只需要轻量客户端或传输能力	评估 fastmcp-slim
宿主只支持 stdio，服务端位于远程 HTTP	评估 fastmcp-remote
想验证 SDK 2.0 和最新协议	在测试环境评估 FastMCP 4.0 Beta

无论选择哪条路线，都应锁定依赖版本，并根据对应大版本的官方文档开发。尤其要检查教程中的导入路径：mcp.server.fastmcp 与独立的 fastmcp 并不是可以随意互换的同一条版本线。

总结

FastAPI 证明了类型提示、开放标准和良好开发体验可以共同构成一个成功的 Python API 框架。MCP 则把接口问题带进 AI Agent 时代，尝试统一模型连接工具与上下文的方式。FastMCP 延续了类似的 Pythonic 思路，并从一个低样板代码的服务器工具，逐渐发展为包含客户端、代理、组合、认证、任务和可扩展架构的 MCP 框架。

三者之间不是简单的替代关系：

• FastAPI 继续负责稳定、通用的 Web API。
• MCP Python SDK 提供协议的官方 Python 基础实现。
• FastMCP 在 SDK 之上提升开发效率并处理更复杂的 MCP 应用场景。

对于已有 Python 后端，比较稳妥的路线不是为了 MCP 推翻现有系统，而是先整理业务层和 OpenAPI 描述，再选择少量安全、边界清楚的能力暴露给 Agent。随着 MCP 协议和 FastMCP 4.x 继续演进，这种“同一份业务能力，多种接口入口”的架构可能会越来越常见。

参考资料

• FastAPI：History, Design and Future
• FastAPI 官方文档
• Anthropic：Introducing the Model Context Protocol
• Model Context Protocol 官方网站
• MCP Python SDK
• FastMCP 官方文档
• FastMCP Updates：版本发展记录
• FastMCP：FastAPI Integration
• FastAPI on PyPI
• FastMCP on PyPI

版权声明

作者

Dawn

链接

https://blog.eastondawn.top/blog/ae966b1c.html

许可

本博客所有文章除特别声明外，均采用CC BY-NC-SA 4.0许可协议。转载请注明来源 Dawn's Blog！

相关文章

• Kali Linux 安装 uv 教程2026/06/07
• 从 AI IDE 到编程 Agent：六款主流 AI 编程工具简介2026/07/24
• Kimi K3 发布：2.8T 参数、1M 上下文与开放权重计划2026/07/18
• 主流大模型发布时间汇总表2026/05/24
• Windows系统重装的替代方法之一：新建账户迁移法2026/03/15