当 MCP 走向无状态：一场关于可扩展性与安全性的艰难权衡

2026 年 7 月 28 日，Anthropic 发布了 MCP（Model Context Protocol）的第五版规范。官方将其定性为“该协议问世以来规模最大、最系统性的一次颠覆式修订”。核心变化只有一句话：MCP 从一个双向有状态协议，彻底转向无状态请求/响应模型。

但“无状态”三个字远不足以概括这次转向的全部含义。它是一连串工程权衡的起点——可扩展性上去了，上下文连续性下来了；部署门槛降低了，协议层的安全责任被重新分配了；工具生态爆发了，攻击面也跟着膨胀了。本文试图沿着这条线索，拆解 MCP 在 2026 年的技术现实：它解决了什么，又制造了什么，以及它还在等待什么。

无状态转向：不是升级，是重写

理解这次转向的动机，需要先回到旧规范的结构性瓶颈。

在 2025-11-25 及更早版本中，MCP 是一个有状态协议：客户端与服务器建立连接时必须先完成 initialize / initialized 握手，之后通过 Mcp-Session-Id 请求头绑定会话，服务器必须在内存或 Redis 中维护该会话的状态。这套设计在本地工具场景下运转良好，但一旦进入生产级部署，它就变成了一堵墙：请求必须路由到同一台服务器实例，即所谓“粘性会话”（Sticky Sessions），水平扩展只能靠加机器和会话亲和性来维持。

2026-07-28 规范的做法是拆掉这堵墙。initialize 握手被彻底移除，会话 ID 被取消，每个请求变为完全自包含——协议版本、能力声明、所需上下文全部随请求携带。服务器可以部署在 AWS Lambda 或 Cloudflare Workers 这类无服务器架构上，请求可以经过任意网关或负载均衡器，不再依赖会话亲和性。Google Cloud 的文档对此的表述很直白：每个 MCP 请求都是自描述的，可以通过 HTTP 头进行路由。

代价同样明确。有状态协议天然支持服务器到客户端的异步通知和双向流式通信，无状态化之后，这些能力被压缩或重新设计。资源更新通知现在需要通过显式的 subscriptions/listen 流来订阅，而不是依赖长连接的持续存在。换句话说，无状态换来了弹性伸缩，但“连接活着”这件事本身不再是一种可依赖的假设。

性能数据侧面印证了这一取舍的收益与边界。MCP-Nest 的基准测试显示，无状态工具调用的吞吐约为 2,800 req/s，在 1→100 并发连接范围内基本持平，内存占用稳定在约 420 MB。这组数字在无状态架构下并不惊人——它真正说明的是，吞吐不再随并发连接数剧烈波动，这正是无服务器部署所需要的可预测性。

分层架构：谁在控制什么

无状态化改变的是连接模型，但 MCP 的核心分层设计在 2026 规范中得以保留并进一步清晰化。理解 MCP 的关键，不在于记住 JSON-RPC 的方法名，而在于看清控制权在 Host、Client、Server 和模型之间的分配方式。

MCP 采用 client–host–server 架构：一个 Host 可以运行多个 Client 实例，每个 Client 与恰好一个 Server 保持 1:1 关系；Host 负责编排、权限和安全策略，Server 暴露能力和上下文，但不应该“看到”完整对话，也不应该“看进”其他 Server。这组约束不是实现细节，而是协议的信任边界声明。

传输层上，JSON-RPC 2.0 始终是线格式，stdio 和 Streamable HTTP 是两种内置传输。stdio 适合本地子进程，延迟极低；Streamable HTTP 面向远程部署，在无状态规范下成为一等公民。数据层则围绕原语展开，其中三大服务器原语构成了工具生态的语义基础：

这组划分的精妙之处在于控制权的有意错位：模型控制 Tools（它决定调什么工具），但应用控制 Resources（它决定模型能看到什么上下文），用户控制 Prompts（人决定何时触发预设流程）。这种设计把“模型自主性”限制在一个可审计的边界内——模型可以“动手”，但不能自行“决定看什么”或“决定何时行动”。

2026 规范还引入了版本化扩展框架，将 MCP Apps 和 Tasks 从核心协议中剥离出来。MCP Apps 允许 Server 在对话中内嵌交互式 UI（图表、表单、播放器），Tasks 则提供长时间运行操作的异步执行、轮询和持久句柄。扩展化的意义不在于功能本身，而在于它阻止了核心协议的无序膨胀：新能力以“版本化扩展”的方式加入，核心保持最小，向后兼容得以维持。

一个被反复误读的问题：MCP 不替代 Function Calling

围绕 MCP 最普遍的误解，是把它和 Function Calling 放在同一个替代关系里理解。二者作用在完全不同的链路环节上。

Function Calling 是大模型 API 的一种决策能力：模型根据工具描述和用户请求，输出“要调用哪个函数、传什么参数”的结构化意图，但它不执行函数——执行发生在应用代码里。用一句话概括：Function Calling 解决“模型怎么表达它想调用某个工具”。

MCP 解决的是另一个问题：工具从哪来、怎么被发现、怎么跨应用复用、怎么以统一方式被调用。它作用在应用后端与工具之间，而不是模型 API 与应用之间。一个 MCP Server 把工具暴露出来，客户端把这些工具翻译成各家模型能理解的 Function Calling 格式送进模型；模型决策之后，执行请求再经由 MCP 落到具体的工具上。

这个分层关系可以用“聚合支付”来类比：Function Calling 是用户说“我要用这张卡付这笔钱”的意图表达，MCP 是让不同银行、不同支付渠道用同一套二维码完成结算的协议层。没有 MCP，N 个 Agent 框架对接 M 个工具需要 N×M 套适配器；有了 MCP，框架各对接 MCP 一次、工具各暴露一次，复杂度降为 N+M。Function Calling 优化“脑”，MCP 优化“连接”，二者不是替代，是上下游。

安全：无状态并没有消解的结构性缺陷

如果只看规范演进，MCP 正在变得越来越“工程友好”。但如果把视线转向安全研究，画面会复杂得多。

2026 年 IEEE 的一篇大规模分析对 MCP 生态做了一次“普查”：覆盖 1,360 个 Server、12,230 个工具，结论是生态中“充斥着真实可被利用的 gadget 和多样的攻击方法”。另一篇论文揭示了一种名为 Parasitic Toolchain Attacks（MCP-UPD）的攻击模式：攻击者不需要与受害者直接交互，而是把恶意指令嵌入 LLM 在合法任务中访问的外部数据源，将多个合法工具组装成一个协调工作流，使组合行为在整体上完成数据窃取。其根因分析直指 MCP 的两个结构性缺失：缺乏上下文-工具隔离，以及缺乏最小权限强制。

无状态化与这些安全问题之间的关系，需要精确表述。无状态规范确实消除了会话状态管理带来的一部分攻击面——没有会话 ID 可被劫持，没有跨请求的状态残留可以被利用。但它没有触及工具链层面的隔离和权限问题。一个 Server 仍然可以声明它不需要的宽泛工具集，一个工具的输出仍然可以不被区分地流入下一个工具的输入，模型仍然无法可靠地区分“工具返回的数据”和“工具返回的指令”。联邦 MCP 网关的研究进一步显示，即使传输认证和租户隔离被正确执行，语义层面的攻击和工具输出介导的攻击仍然频繁绕过轻量级的模式匹配检查。

这意味着，无状态化提升的是可扩展性和部署弹性，而不是安全基线。协议层把安全责任更多地推向了实现层和运维层：网关、最小权限策略、工具输出的类型化隔离、对工具描述的完整性校验，这些必须在 MCP 之外被建立。Agentic Firewall、MCP-Secure 等运行时访问控制层开始出现，试图在不修改 Agent 和 Server 的前提下，通过拦截代理实施最小权限和审批门控。但这些是补救措施，不是协议内建的保证。

生态：事实标准之后的问题

MCP 的采纳速度在协议史上并不常见。SDK 月下载量突破 4 亿次，一年内增长 4 倍；公开活跃 MCP Server 超过 10,000 个；ChatGPT、Cursor、Gemini、Microsoft Copilot、VS Code 均已采纳。2026 年 8 月，Anthropic 将 MCP 捐赠给 Linux 基金会旗下的 Agentic AI Foundation（AAIF），与 Block 的 goose、OpenAI 的 AGENTS.md 并列成为创始项目，治理模型承诺保持社区驱动和厂商中立。

但生态数据的另一面同样值得注意。一项对 802 篇 MCP 相关论文和 33,319 个 GitHub 仓库的双维度研究显示，57.8% 的论文和 93.7% 的仓库将 MCP 作为“使能技术”使用，而非直接分析、评估、扩展或保护协议本身。换句话说，生态在快速扩张应用层，但对协议本身的系统性审视严重不足。在安全研究已经明确指出结构性缺陷的情况下，这种失衡本身就是一个风险信号。

另一个尚未闭合的议题是扩展层的成熟度。Tasks 扩展虽然被正式纳入版本化框架，但其重试行为、结果过期、长期状态管理等问题在 2026 路线图中仍被标记为未解决。MCP Apps 的 ui:// 资源通过沙箱 iframe 渲染，引入了新的内容安全和交互信任问题。扩展化是正确的架构方向，但它把“协议复杂度”转化为了“扩展治理复杂度”，后者并不自动更简单。

结语

MCP 在 2026 年完成了一次从“能用”到“可规模化部署”的关键转身。无状态核心让它真正成为云原生工作负载，分层原语让工具生态有了可复用的语义基础，扩展框架为协议的未来演进留出了制度空间。这些都是扎实的工程进步。

但这次转向也清晰地划出了协议能力的边界：MCP 标准化的是连接，不是信任；是发现和调用的接口，不是隔离和权限的保证。 工具链攻击、最小权限缺失、上下文与指令的不可区分性，这些问题不会因为会话 ID 的消失而消失。它们需要网关层的强制、运行时的策略执行、以及工具输出在类型和语义层面的更严格分离。

一个协议走向成熟的标志，不是它声称自己能解决所有问题，而是它让“哪些问题应该在哪里解决”变得清晰。从这个标准看，MCP 2026 规范做对了一件重要的事：它把连接层做薄、做快了，然后把安全的重担诚实地留在了它本该在的地方——实现者和运维者的手里。