MCP 迎来重大升级！PHP 构建 MCP Server 更简单了

Tinywan

发布于 2026-09-15 14:27:49

880

MCP 协议变成请求/响应模型，PHP 构建 MCP Server 更容易了

2026 年 7 月 28 日，MCP 正式发布 2026-07-28 版规范。最核心的变化，是将协议核心从“依赖长连接和会话的双向有状态模式”，调整为“每次请求都可独立处理的无状态请求/响应模式”。这让 MCP 更接近 PHP 开发者熟悉的 Web 请求生命周期，也让使用 PHP 构建、部署和扩展 MCP Server 变得更加自然。

最近，Laravel MCP 核心维护者 Marcel Pociot 分享了一条颇有意思的观点：

MCP 协议变成了请求/响应模型，这会让使用 PHP，尤其是 Laravel，构建 MCP Server 变得更容易。

这句话点出了新版 MCP 与 PHP 的天然契合点。

无论是经典的 PHP-FPM，还是 Laravel、Symfony，以及常驻内存的 Webman、Workerman、Swoole、OpenSwoole 和 RoadRunner，PHP 生态都已经具备成熟的 HTTP 请求处理能力。

乍看之下，这似乎只是一次通信方式调整。但对真正部署过远程 MCP Server 的 PHP 开发者来说，它解决的是协议适配、扩容、负载均衡、容错和 Serverless 部署中的一系列实际问题。

按照 MCP 官方的说法，这是该协议自发布以来规模最大的一次修订。

旧版 MCP 为什么让远程部署变得复杂？

在此前的 Streamable HTTP 模式中，客户端不能直接调用工具，而是要先完成初始化握手：

客户端
  │
  ├─ initialize
  │
  ├─ notifications/initialized
  │
  └─ tools/call（携带 Mcp-Session-Id）

服务器在初始化后返回 Mcp-Session-Id，客户端后续请求必须继续携带这个会话标识。

这意味着服务端需要知道：

当前客户端完成了什么版本协商；
客户端声明了哪些能力；
这个会话由哪一个服务实例创建；
后续请求应如何恢复此前的协议上下文。

单机运行时，这些问题并不明显。一旦进入生产环境，情况就复杂了：

负载均衡器可能需要配置粘性会话；
多个实例之间可能需要共享 Session 状态；
实例重启或自动缩容可能导致会话丢失；
边缘函数和 Serverless 平台不适合维护长期状态；
网关很难只看普通 HTTP 元数据完成精确路由与授权。

换句话说，旧版 MCP 的能力很强，但协议层对“连接”和“会话”的依赖，让远程 MCP Server 不太像一个普通 Web 服务。

新版 MCP：每个请求都能独立完成

在 2026-07-28 规范中，MCP 正式将协议核心改为无状态模型：

客户端
  │
  └─ tools/call（请求中包含版本、能力及客户端信息）
        │
        ├─ 实例 A 可以处理
        ├─ 实例 B 可以处理
        └─ 实例 C 也可以处理

每次请求都带有处理它所需要的协议上下文，服务端不能依赖此前请求中隐含的协议状态。于是，任意一个兼容的 MCP Server 实例都可以接管当前请求。

官方示例中的一次工具调用大致变成这样：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "q": "PHP MCP Server"
    },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-app",
        "version": "1.0"
      }
    }
  }
}

请注意，MCP 仍然使用 JSON-RPC 2.0，并没有退化成随意设计的普通 REST API。变化发生在协议的状态管理和传输方式上。

这次到底移除了什么？

新版规范主要移除了三项协议级机制：

1. 移除初始化握手

旧版的 initialize 和 notifications/initialized 流程被取消。

协议版本、客户端能力和客户端信息改为随请求传递。客户端如果希望在正式调用前了解服务器支持的版本和能力，可以调用新的 server/discover 方法。

2. 移除协议级 Session

Streamable HTTP 不再使用 Mcp-Session-Id。服务器也不应通过连接或此前的调用推断当前请求的处理上下文。

这让请求可以被普通的轮询负载均衡器分发到任意实例，不再天然依赖粘性会话或共享 Session 存储。

3. 移除常驻的双向通信前提

过去，一些“服务端反过来向客户端提问”的能力依赖持续打开的双向通道。新版通过 Multi Round-Trip Requests，也就是 MRTR，重新组织这类交互。

例如，一个工具执行到一半需要用户补充参数时，可以返回 InputRequiredResult；客户端收集答案后，再携带补充信息重新发起请求。整个过程不再要求一直占用一条长连接。

无状态不等于业务不能保存状态

这是本次升级最容易被误解的地方。

MCP 无状态，指的是“协议层无状态”，不是要求应用本身不能有状态。

购物车、审批流程、AI 任务、文件处理进度以及多步骤业务流程，仍然可以保存到：

MySQL；
Redis；
缓存或对象存储；
队列与任务系统；
Laravel Queue、Symfony Messenger 或其他持久化工作流系统。

区别在于，状态必须显式存在于应用数据模型中。例如服务器可以返回一个 task_id、workflow_id 或状态句柄，客户端后续再将它作为普通工具参数传回来。

这种设计实际上更加清晰：

协议状态：由 MCP 请求本身完整携带
业务状态：由应用通过明确的 ID 持久化

它避免了把重要业务流程偷偷绑定在某个连接、某台服务器或某段易丢失的内存 Session 上。

为什么 PHP 会成为直接受益者？

PHP 最经典、最成熟的运行模型，就是一次请求对应一次完整的应用生命周期：

HTTP 请求进入
    ↓
Nginx / Apache / 网关
    ↓
PHP-FPM 或 PHP 应用服务器
    ↓
路由、中间件、认证与授权
    ↓
调用 MCP Tool / Resource / Prompt
    ↓
返回 MCP 响应

处理结束后，请求级变量自然释放；需要长期保存的数据则显式写入 MySQL、Redis、文件、队列或其他持久化设施。

而新版 MCP 的设计恰好遵循同一种思路：每次请求带齐协议版本、客户端能力和调用参数，任意兼容的服务实例都可以独立完成处理。

过去为了实现 MCP Server，PHP 开发者往往要额外处理初始化握手、协议 Session、长连接以及跨请求上下文。这些机制并非 PHP 不能实现，但会迫使传统 PHP 项目偏离已经非常成熟的请求/响应模型。

协议核心无状态化之后，PHP 不再需要为了适配 MCP 而刻意变成一个长期维护连接状态的服务。它可以继续发挥自己最擅长的部分：接收请求、执行业务、访问数据库，然后返回结果。

传统 PHP-FPM 也能更自然地承载 MCP

PHP-FPM 的 Worker 可以独立处理请求，应用无需在进程内保存 MCP 会话。一个请求落到哪个 Worker，原则上不再影响协议正确性。

这对已有 PHP 项目尤其重要：开发者可以把 MCP Server 看作现有业务系统新增的一组 AI 能力入口，而不是重新维护一套独立的常驻连接服务。

例如，一个电商系统可以直接把已有能力包装为 MCP Tools：

查询商品与库存；
创建或取消订单；
查询物流进度；
生成经营数据报表；
调用已有审批和售后流程。

底层仍然复用原有 Service、Repository、ORM、权限控制和审计日志。

Laravel、Symfony 等框架可以直接复用 Web 能力

以 Laravel MCP 为例，一个远程 MCP Server 可以继续按照熟悉的路由方式注册：

use App\Mcp\Servers\OrderServer;
use Laravel\Mcp\Facades\Mcp;

Mcp::web('/mcp/orders', OrderServer::class)
    ->middleware(['auth', 'throttle:mcp']);

Laravel 的路由、中间件、认证、授权、限流、验证、日志、缓存、队列和异常处理，都可以参与 MCP 请求生命周期。

Symfony、Slim、Hyperf 等框架也可以采用类似思路：协议适配层负责解析和输出 MCP 消息，业务逻辑继续由框架已有的 Controller、Service、事件和消息系统承载。

Webman、Workerman、Swoole 仍然有自己的优势

无状态 MCP 并不意味着常驻内存 PHP 框架失去价值。

Webman、Workerman、Swoole、OpenSwoole、RoadRunner 等运行模式仍然适合：

降低框架重复启动的开销；
复用数据库、Redis 和 HTTP 连接池；
处理大量并发 MCP 调用；
返回流式进度消息；
运行高吞吐量工具服务；
承载需要事件循环的异步 I/O。

变化在于，开发者不再被迫把“协议会话状态”绑定到某个 Worker。即使采用常驻内存架构，也应尽量让请求能够被任意 Worker 独立处理；真正需要跨调用的数据，则通过显式 ID 和持久化存储传递。

更容易水平扩容

同一个 PHP MCP Server 可以部署多个实例，通过普通轮询策略分发请求。理论上不再需要因为 MCP 协议 Session 而将某个客户端固定到同一台服务器或同一个 Worker。

更适合容器、弹性扩缩容和 Serverless

无状态请求适合短生命周期计算环境。PHP 实例启动、回收、重启或迁移，不再直接破坏某个隐式协议会话。

这让 PHP MCP Server 更容易部署到：

Docker 与 Kubernetes；
Laravel Cloud 等应用平台；
支持 PHP 的 Serverless 或边缘运行环境；
普通的 Nginx + PHP-FPM 集群。

可以复用成熟的网关能力

Mcp-Method 与 Mcp-Name HTTP Header 让 API Gateway 或反向代理可以在不解析 JSON 请求体的情况下，根据 MCP 方法名和工具名执行：

路由分发；
访问控制；
限流；
审计；
指标统计。

例如，可以对查询类工具和写入类工具应用不同的权限与限流策略。

更容易观察和排查问题

每次请求都携带足够的协议上下文，日志与 Trace 不再必须拼接一整段连接历史，才能解释一次工具调用。

对 PHP 开发者而言，这正是熟悉的“一次请求对应一条完整处理链路”。

请求/响应模型会让 MCP 能力缩水吗？

不会，但部分能力被重新安排了位置。

新版 MCP 并非只能进行“一问一答”：

与当前请求有关的进度和日志通知，仍可通过该请求的响应流返回；
工具、资源或 Prompt 列表变化，可通过 subscriptions/listen 订阅；
需要用户补充信息的多轮工具调用，可使用 MRTR；
长时间运行的操作，可使用 Tasks 扩展；
有状态业务，可通过显式状态句柄延续；
MCP Apps 继续用于在客户端中呈现交互式界面。

因此，更准确的描述不是“MCP 取消了双向能力”，而是：

MCP 不再把长期双向连接和隐式 Session 作为协议核心的默认前提，而是把多轮交互、订阅和长任务拆分成更明确的机制。

除了无状态，这个版本还有哪些重要变化？

2026-07-28 不只是传输层升级，还包括：

新增 server/discover，用于发现服务器版本、能力和身份；
工具、方法名称进入 Mcp-Method 和 Mcp-Name HTTP Header；
列表结果支持确定性排序和缓存提示；
MCP Apps、Tasks 等能力进入正式扩展体系；
授权机制进一步贴近 OAuth 与 OpenID Connect 的成熟实践；
工具 Schema 完整对齐 JSON Schema 2020-12；
建立正式弃用策略，承诺至少 12 个月的迁移窗口；
Roots、旧式 Sampling 和 Logging 等能力进入弃用流程。

由于此次升级包含破坏性变化，旧版客户端和服务端不能仅凭“都是 MCP”就假设可以直接互通。升级时需要同步检查 SDK 版本、协议版本、废弃能力以及客户端支持情况。

PHP 开发者现在应该怎么做？

如果你的 MCP Server 仍处于开发阶段，可以优先关注：

当前使用的 PHP MCP SDK 或框架组件是否已支持 2026-07-28；
使用的 Claude、ChatGPT、IDE 或其他 MCP Client 是否支持新规范；
代码是否依赖 initialize、Mcp-Session-Id 或连接级状态；
业务状态是否已经通过数据库、缓存或显式 ID 持久化；
旧式 Sampling、Roots、Logging 是否需要迁移；
是否需要使用 MRTR、Tasks 或订阅机制承接复杂交互。

如果项目使用 Laravel，还应检查 laravel/mcp 的版本与迁移说明；如果使用其他 PHP SDK，则需要确认其实现的是最终版 2026-07-28 规范，而不只是此前各家行为不一致的“stateless”配置。

生产项目不建议只修改协议版本字符串就直接上线。更稳妥的方式是先建立兼容性测试，分别验证：

工具发现与调用；
认证与授权；
多实例负载均衡；
长任务与用户补充输入；
超时、重试与幂等；
新旧客户端兼容策略。

写在最后

早期 MCP 更像一个强调“客户端与服务器持续连接”的智能体协议；而 2026-07-28 版本开始明显吸收成熟 Web 架构的经验：

请求自描述；
服务端可替换；
状态显式化；
结果可缓存；
网关可路由；
链路可追踪。

这次升级不会让 MCP 变成普通 REST API，但它确实让 MCP Server 更像一种能够运行在标准 HTTP 基础设施上的现代服务。

对 PHP 开发者来说，最大的意义也正在这里：未来构建 MCP Server，不必先围绕长连接和协议 Session 重新设计一套运行模型，而是可以更自然地复用 PHP 生态已经成熟的 HTTP 生命周期、框架路由、中间件、认证、数据库、缓存、队列和持久化能力。

PHP-FPM 可以继续发挥简单、稳定和易部署的优势；Webman、Workerman、Swoole、OpenSwoole 和 RoadRunner 则可以在无状态协议之上进一步提供常驻内存、连接复用、异步 I/O 与高并发能力。

MCP 正在从“能连接 AI 与工具”，进一步走向“能够可靠地承载生产级 AI 工具生态”。

参考资料

MCP 官方：The 2026-07-28 Specification[1]
MCP 2026-07-28 关键变更[2]
MCP 2026-07-28 正式规范[3]
Laravel MCP GitHub 仓库[4]
Laravel MCP 13.x 官方文档[5]
Marcel Pociot：MCP 请求/响应模型与 Laravel[6]

参考链接

MCP 官方：The 2026-07-28 Specification: https://blog.modelcontextprotocol.io/posts/2026-07-28/
MCP 2026-07-28 关键变更: https://modelcontextprotocol.io/specification/2026-07-28/changelog
MCP 2026-07-28 正式规范: https://modelcontextprotocol.io/specification/2026-07-28
Laravel MCP GitHub 仓库: https://github.com/laravel/mcp
Laravel MCP 13.x 官方文档: https://laravel.com/docs/13.x/mcp
Marcel Pociot：MCP 请求/响应模型与 Laravel: https://x.com/marcelpociot/status/2082182848799297692

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2026-07-29，如有侵权请联系 cloudcommunity@tencent.com 删除

server