博客2026 年 3 月该协议 SDK 月下载量 9700 万。但企业部署面临四个硬伤：可流式 HTTP 上下文管理、认证授权、服务发现、传输层选型。从架构决策出发，给 CTO 一套可落地的评估框架和 FastMCP 2.x 生产级代码。
2026 年 3 月，Anthropic 公布：Model Context Protocol 月 SDK 下载量 9700 万，公开可用的服务端突破 10,000 个¹。OpenAI、Google DeepMind、Microsoft、AWS 全在核心产品里内置支持。但 5 月发布的路线图²更像一份公开检讨——维护者把阻碍这套协议进入受监管企业的四个短板逐一列了出来。如果你还没搞清楚这套协议在 AI 工具调用生态里的位置，建议先看从 Function Calling 到 MCP 的架构演进。本文不谈"是什么"，直接讲你作为架构师在把这类服务塞进生产前必须做的四个决策。
该领域最主流的 Python 框架，GitHub 25,000+ stars³——用 type hints 和 docstring 自动推导 tool schema，省掉手写 JSON Schema。一行 @mcp.tool() 装饰器，LLM 就能发现并调用你的函数。
但企业级场景下，"能跑"和"能上生产"之间隔着一整套工程决策。正如我们在AI Agent 生产部署实战中踩过的坑——POC 到每天 10 万请求，每一层都翻倍。2025 年 3 月规范修订引入三个关键变更：可流式 HTTP 替代 SSE 作为推荐传输层、授权协议成为远程部署强制要求、服务端被重新归类为 Resource Server⁴。这些不是"可选增强"——面向多租户、负载均衡、合规审计场景，它们是硬性前提。
| 方式 | 适用 | 限制 | 建议 |
|---|---|---|---|
| stdio | 本地开发、桌面 IDE | 进程绑定，崩溃即丢状态 | 仅限本地 |
| SSE | 早期远程调用 | 单向推送，已标记为遗留 | 不再新项目使用 |
| 可流式 HTTP | 远程部署、多租户 | 无状态，需外部存储做上下文 | 当前生产首选 |
| WebSocket | 长连接双向推送 | 规范未稳定 | 观望 |
2025 年 3 月 26 日规范更新正式从 SSE 切换到新传输方案⁵。核心原因：SSE 单向推送，调用方需另开 POST 通道回传。在负载均衡器后面两个 TCP 连接可能落到不同实例，状态对不上。新方案用单一连接承载双向流，消除分裂。
但它依然是无状态模型——扩容到 3 实例后，同一来源的连续请求可能分发到不同 pod。这就是路线图里的「状态维持与负载均衡冲突」，协议层不帮你解决亲和性。
路线图列为企业部署第一大硬伤。
假设你的工具管理 CI/CD。用户说「部署 staging」，返回 deployment ID。接着说「回滚刚才那个」，工具端需要知道「刚才那个」是哪个。stdio 下 naturally works——状态在内存里。远程方案下两次请求零关联。
两条路线：
ip_hash 或 K8s affinity: ClientIP 固定 pod。简单，但 pod 重启丢上下文。ctx → state。pod 可随意扩缩，但引入 Redis 依赖。倾向方案二。2026 年 1 月 CA-MCP 论文（Context-Aware 扩展）⁶已验证共享上下文在多服务协作下能减少 LLM 调用次数。迟早要上，不如一开始外挂。核心模式：每个请求到达时从 Redis 按 ctx_id 拉取状态字典，处理完后写回，设置 TTL（建议 3600s）。生产环境补充过期清理、并发写入锁、上下文大小上限即可。
2025 年 6 月安全规范更新把远程服务端重新归类为 OAuth 2.1 Resource Server⁷。你的工具不再自己签发 token，改验证 Auth Server 签发的 access token。Resource Indicators（RFC 8707）强制——每个 token 绑定特定资源。
「搞个 API Key 不就完了」——内网、单团队、少量工具确实够用。但以下任一条件 API Key 立刻崩：
当前实践：工具前架 API Gateway（Kong / APISIX / Envoy），网关做 token 校验和权限路由：
AI Host ──① PKCE Flow──▶ Auth Server
◀──② JWT Token────
──③ Bearer Token──▶ Gateway ──④ introspection──▶
│
▼ ⑤ 注入 X-User-Id / X-Scopes
FastMCP 服务 ──⑥ 执行 tool──▶ ⑦ 返回
这层不在规范正文，但路线图明确「授权合规」是工作组推进方向。
路线图第二个硬伤：「注册表缺乏机器可读方式发现服务」。当前调用方要知道服务端存在，靠 mcpServers JSON 手动填，或 IDE 插件静态列表。企业内部每换一个 endpoint，全团队重配。
三条折中路线：
GET /servers 返回节点信息（endpoint、capabilities、health）{tool}.mcp.internal + SRV 记录，适合 10-20 个服务方案 2 今天就能落地。别等路线图承诺的注册表升级。如果你的团队正在评估是否外包这类基础设施搭建，可以参考AI Agent 开发外包的 7 个评估指标——服务发现和认证授权这两块，在交付质量上是最容易出问题的分水岭。
import time
from typing import Annotated
from mcp.server.fastmcp import FastMCP, Context
mcp = FastMCP(name="internal-cicd", version="2.1.0")
_rate: dict[str, list[float]] = {}
def _limit(caller: str, rpm: int = 30) -> bool:
now = time.monotonic()
w = [t for t in _rate.get(caller, []) if now - t < 60]
_rate[caller] = w
if len(w) >= rpm:
return False
w.append(now)
return True
@mcp.tool()
async def trigger_deploy(
svc: Annotated[str, "目标服务名"],
env: Annotated[str, "staging 或 production"],
ctx: Context
) -> str:
"""触发部署。生产环境需二次确认。"""
if env not in {"staging", "production"}:
return f"Error: 必须是 staging/production，收到 '{env}'"
caller = ctx.client_id or "unknown"
if not _limit(caller, rpm=10):
return "Error: 速率限制（10 req/min）"
if env == "production":
ctx.info("⚠️ 生产部署，请确认服务名。")
ctx.report_progress(0.5, "流水线触发中...")
return f"✅ {svc} → {env} 已触发"
if __name__ == "__main__":
mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)
值得注意的细节：
Context（该库 2.x 内置）提供 caller 标识、日志、进度通知——做审计比在返回值里拼字符串干净得多Annotated[str, "..."] 让参数描述自动成为 tool schema，LLM 能准确理解语义Q：这套协议和 REST API 的区别？为什么不用 FastAPI？
A：价值在协议层——标准化 tool discovery、参数描述和 LLM 调用约定。FastAPI 手写 JSON-RPC + Schema 可以，但每接入新 AI 宿主都要适配。这层标准让服务写一次，所有兼容宿主（Claude、Cursor、Copilot、自定义 Agent）都能发现调用。本质是"AI 世界的 USB-C"。
Q：远程部署的状态问题多严重？单实例不行？
A：单实例绕过意味着放弃高可用。5 人用的 Jira 查询工具单实例足够。承载部署、数据库操作、客户数据的企业级服务，单实例故障 = 全公司 AI 工具链不可用。先评估可用性要求再决定。
Q：LLM 会通过 Tool 执行危险操作吗？
A：协议只是通道。安全三层解决：(1) Tool 层输入校验和白名单；(2) 传输层授权认证 + TLS；(3) 模型层 human-in-the-loop。2025 年安全研究在早期实现发现 23 个关键漏洞⁸，核心结论：像对待公网 API 一样对待 LLM 输入——永远不信任。
Q：Go/TypeScript 团队用什么替代？
A：官方 SDK 覆盖 Python、TypeScript、Java、Kotlin、C#⁹。Go 社区 mark3labs/mcp-go（~3K stars）。优先团队主力语言对应的官方或头号社区 SDK。