MCP 2026-07：从会话制到无状态协议架构

MCP 2026-07-28 现已成为稳定的 Model Context Protocol 版本。其最大的架构变化是设计了一个无状态、无会话的核心，能够更自然地运行在普通的 HTTP 基础设施之上。

这对协议实现者来说是一项重大改进。但这并不使通过 MCP 执行的工作变成无状态的。

披露：AI 工具协助编辑了本文。Manor AI 团队在发布前根据稳定的 MCP 规范、变更日志和引用的 SEP 验证了技术声明。

MCP 解决的问题

在 MCP 出现之前，每个 AI 主机都倾向于为文件、数据库、开发工具和商业系统发明自己的适配器。每个连接都带来一个新的 schema、发现模型、认证流、错误模型和生命周期。

MCP 为主机和服务器提供了一种通用方式来暴露：

• 模型可以调用的 Tool；
• 提供数据和上下文的 Resource；
• 打包可复用交互模式的 Prompt。

该协议规范化了能力的描述和调用方式。但它不决定为什么应该使用某个能力、谁应该批准它，或结果明天应该存放在哪里。

MCP 2026-07-28 中的变化

1. 核心协议是无状态的

之前的 Streamable HTTP 部署可以建立一个会话，并在请求间携带 Mcp-Session-Id。水平扩展的服务器则需要会话亲和性或共享的会话基础设施。

新版本移除了初始化握手和协议级会话。每个请求都携带理解它所需的信息，而 server/discover 让客户端检查服务器的能力。

现在任何健康的服务器实例都可以处理请求。这非常适合普通的负载均衡器、网关、缓存和追踪系统。

当工作流需要跨调用的状态时，服务器可以返回一个显式的句柄，并在之后将该句柄作为普通参数接受。一个 basket_id、browser_id 或 job_id 变成应用数据，而不是隐形的传输状态。

2. 服务器到客户端的交互变成显式的往返

服务器在处理请求时可能仍需要更多信息。Multi Round-Trip Requests 模式使这项需求显式化。

与依赖开放的双向会话不同，一个操作可以返回 input_required。客户端收集请求的输入，并用 inputResponses 重试该操作。

相关状态是可见的、可路由的，而不是隐藏在连接内部。

3. 扩展可在核心外独立演进

MCP 现在拥有一流的扩展模型。可选能力被显式地广告，可以在不强迫每个实现同时采纳的情况下独立演进。

两个扩展特别与 agent 应用相关：

MCP Apps 可以在对话内渲染交互式界面，如表单和图表。

MCP Tasks 添加了异步操作，支持持久句柄、轮询和中途输入。

这些扩展使 MCP 超越了短型同步工具调用的应用范围。但它们仍不能取代围绕团队的产品级运营模型。

4. 授权改进，但主机策略仍然必要

该版本加强了授权，并使其更紧密地对齐 OAuth 和 OpenID Connect 部署。

认证可以确定客户端是否可以连接到服务器。但它无法完全回答这个特定 agent 是否应该在当前情况下发送邮件、发布帖子、修改记录或删除文件。

规范保持这个边界明确：主机应用仍需要同意界面、访问控制和安全执行行为。

无状态协议并不意味着无状态的工作

一个工具调用可以是自成一体的，而围绕它的工作仍然需要持久化。

考虑一个客户入驻工作流。它可能包括研究、文档生成、CRM 更新、邮件草稿、批准和最终交付。多个 MCP 调用可能参与其中，但团队仍需要知道：

• 目标和当前状态；
• 使用了哪些文档和指导；
• 哪些工具可用；
• 什么完成了，什么失败了；
• 在哪里需要人工输入；
• 哪些证据支持了结果。

这些都不属于传输会话。它们属于主机应用的数据模型。

Prompt 不是持久任务

Chat 对于表达意图很有用。但它是运营状态的一个糟糕数据库。

一个真正的任务需要所有者、优先级、验收标准、计划、状态、证据、评论和可验证的结果。如果执行在中途停止，另一个人应该能够看到发生了什么并继续工作。

对话可以启动任务。但任务应该成为工作的记录。

这也解释了为什么 MCP Task 和产品级任务是不同的概念。MCP 扩展代表协议操作的生命周期。主机应用决定该操作如何关联到业务目标、所有者、策略、审查，以及之后仍然有用的结果。

Context 需要一个运营边界

让每个 agent 访问每个文档和每个工具在演示中很方便，在生产中很危险。

Context 应该属于一个边界，比如项目、workspace、客户账户、团队或环境。该边界将属于同一工作的人员、agent、知识、工具、集成和规则分组。

它回答两个基本问题：

• 这个 agent 可以使用什么信息？
• 这个 agent 在这里可以执行什么操作？

没有边界，检索和工具调用就变成了全局能力，所有权不明确。

人工批准应该在执行内部

批准不应该是在自动化设计后添加的弹窗。

一个任务应该能够暂停、显示建议的操作和支持证据、记录决定，并从相同状态继续。这创造了一个有用的责任分工：

• agent 准备并解释操作；
• 运行时执行检查点；
• 一个人做出决定；
• 任务记录发生了什么。

这对客户沟通、发布、权限更改、支付和破坏性操作最为重要。

证据使 agent 工作可调试

当自动化产生不良结果时，第一个问题通常是：为什么？

答案不应该需要重建整个 chat 记录。生产主机应该保留与工作相关的计划、步骤、工具结果、artifacts、批准、错误和最终状态。

证据帮助运营者审查建议的操作，开发者调试失败的运行，以及团队在重复使用后改进工作流。

生产主机仍需提供什么

协议有意不是一个业务流程引擎。生产主机仍需要提供：

• 用于人员、agent、知识和规则的运营边界；
• 超越单次对话的持久上下文；
• 具有所有权、状态、验收标准和结果的工作对象；
• 范围狭窄的工具和凭证；
• 用于重要操作的批准检查点；
• 使执行可审查的证据；
• 可以重复和改进的工作流。

这不是 MCP 的弱点。这是正确的关注点分离。

MCP 规范化了集成表面。主机仍然负责将工具调用转变为团队可以运营的工作。

给 agent 一个小任务，带有可验证的结果。让它使用一个文档和一个范围受限的工具。触发一个应该需要批准的操作。

然后验证系统：

• 在重要操作前暂停；
• 显示有用的证据；
• 记录决定；
• 从相同状态恢复；
• 留下另一个人可以检查的结果。

该路径揭示了系统是仅仅一个 agent 演示，还是团队可以运营的东西。

MCP 2026-07-28 规范

自 2025-11-25 以来的关键变化

SEP-2567: 通过显式状态句柄的无会话 MCP

最初由 Manor AI 团队在 Medium 上发布。此 DEV 版本是一个技术交叉发布，原始 URL 设为规范源。