Model Context Protocol (MCP) 取消了会话状态（session state），转而采用收据式请求（receipt-style requests）和全新的 server/discover 命令。开发者现在可以在 AWS Lambda 等无服务器（serverless）平台上运行 MCP，从而避免长期损害可靠性的“单一服务员”（single waiter）瓶颈。
为什么旧模型很重要
MCP 最初需要与特定服务器保持持久连接。服务器持有用户的“桌号”——一个存储上下文、规则和待处理操作的隐藏会话。当该服务器崩溃时，会话就会消失，客户端必须重新开始。
更新带来的变化
- 无会话 – 每个请求都携带服务器所需的一切信息，就像任何收银员都能读懂的餐厅收据一样。“initialize”握手环节也随之消失。
- 收据模型 – 每个请求开头的微型元数据块（meta block）包含了版本信息和所需参数。服务器独立处理请求，然后返回包含
resultType、ttlMs（以毫秒为单位的生存时间）和cacheScope的结果。这些字段允许客户端安全地缓存答案并获知其过期时间。 - Server/discover – 一个新命令允许客户端查询服务器当前的各项能力。响应是即时的，且不依赖于之前的交互。
- Subscriptions/listen – 类似于取餐器：客户端订阅更新，仅在发生变化时才收到通知，从而减少了轮询流量。
- Input_required 流程 – 如果服务器需要更多信息，它会返回
input_required响应，而不是反向联系客户端。随后，客户端会在后续请求中提供缺失的数据。
由于服务器不再持有状态，任何无状态计算环境都可以托管 MCP 端点。按需启动、暂停或跨区域迁移的函数可以处理流量，而不会中断对话。
谁是赢家，谁会担忧
构建 AI 前端的开发者 – 获得了更简单、更可靠的后端。
基础设施团队 – 可以在廉价、自动扩缩容的服务上部署 MCP。
MCP 服务器维护者 – 必须重写处理器以输出 ttlMs、cacheScope 并遵守 server/discover 协议。依赖持久会话的代码将需要进行重构。
有严格合规要求的企业 – 受益于更清晰的数据生命周期控制。
隐藏的细节：版本协商
每张“收据”都包含一个微型元数据块，用于声明客户端预期的协议版本。
尚不确定的因素
下一步值得关注的内容
总结
通过剥离会话状态并将每次交互转变为自包含的收据，MCP 现在能够自然地融入无服务器生态系统。这一转变使 MCP 更加稳定且具备可扩展性，让服务器可以在任何地方运行，并像任何普通的 Web 服务一样进行扩缩容。