评测
MCP 2026-07-28 无状态架构：为什么 Agent Server 终于可以真正横向扩展？
MCP 正在经历自推出以来最重要的一次基础架构变化。2026-07-28 规范候选版本移除了传输层 Session：过去 HTTP MCP Server 需要 `initialize` 握手并返回 `Mcp-Session-Id`，后续请求必须保持会话状态，导致 Sticky Session、Redis Session Store、Pod 重启丢会话和 Serverless 难以落地。新规范把协议版本、Client Info 和 Capability 放进每个请求的 `_meta`，每次调用都成为自描述、相互独立的 HTTP 请求。Google 表示这一变化源于其在大规模云环境中部署 MCP 时遇到的实际瓶颈。本文重点分析无状态核心、HTTP Header 路由、缓存、Multi Round-Trip Request、Tasks 和安全机制对企业 Agent 平台意味着什么。
# MCP 2026-07-28 无状态架构：为什么 Agent Server 终于可以真正横向扩展？
## 文章摘要
MCP 正在经历自推出以来最重要的一次基础架构变化。2026-07-28 规范候选版本移除了传输层 Session：过去 HTTP MCP Server 需要 `initialize` 握手并返回 `Mcp-Session-Id`，后续请求必须保持会话状态，导致 Sticky Session、Redis Session Store、Pod 重启丢会话和 Serverless 难以落地。新规范把协议版本、Client Info 和 Capability 放进每个请求的 `_meta`，每次调用都成为自描述、相互独立的 HTTP 请求。Google 表示这一变化源于其在大规模云环境中部署 MCP 时遇到的实际瓶颈。本文重点分析无状态核心、HTTP Header 路由、缓存、Multi Round-Trip Request、Tasks 和安全机制对企业 Agent 平台意味着什么。
---
MCP 最早非常适合：
```text
一个 IDE
↓
一个本地 MCP Server
```
例如：
```text
Claude Code
↓
stdio
↓
Local Git MCP
```
这种场景根本不需要考虑 Kubernetes、Load Balancer、Auto Scaling、Serverless 或 Failover。
但企业 Agent 完全不同。
可能是：
```text
10,000 Users
↓
AI Gateway
↓
MCP Cluster
↓
100+ Tools
```
这时早期的 Session 设计就会变成基础设施瓶颈。
## 旧版 MCP 为什么难扩展？
旧的 HTTP 模式中：
```text
Client
↓
initialize
↓
Server
↓
Mcp-Session-Id
```
后续所有请求都要携带这个 Session ID。
假设 Kubernetes 有：
```text
Pod A
Pod B
Pod C
```
用户第一次请求打到 Pod A，Session 存在 Pod A 内存。
第二次请求经过普通 Round Robin 打到 Pod C。
Pod C 不认识这个 Session。
结果就是：
```text
400 Session Not Found
```
## 企业过去怎么解决？
### Sticky Session
Load Balancer 强制同一个 Session 始终打到同一个 Pod。
问题：
- 流量不均衡；
- Auto Scaling 效率差；
- Pod 故障时会话丢失。
### Redis Session
把状态放进 Redis。
每次工具调用都要读 Session、执行、写 Session。
问题：
- 多一次网络调用；
- 多一套高可用基础设施；
- 延迟增加；
- 运维复杂。
### Gateway Session Routing
由 Gateway 识别 Session 并定向路由。
问题是 Gateway 开始理解 MCP 内部状态，基础设施越来越重。
## 2026-07-28 做了什么？
最核心变化：
> **传输层彻底无状态。**
新的规范删除：
- `initialize / initialized` 握手；
- `Mcp-Session-Id`。
每个请求都带完整元信息。
例如：
```text
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
```
Body 内同时携带 `_meta`，描述协议版本、Client Capability 和 Client Info。
任意 Pod 都可以处理。
## 这意味着什么？
### 1. 普通 Round Robin 就够了
```text
Request 1 → Pod A
Request 2 → Pod C
Request 3 → Pod B
```
没有 Session Pinning。
### 2. Pod 重启不再破坏传输会话
如果 Pod A 挂掉，下一次请求直接去 Pod B。
Client 不需要知道。
### 3. Serverless MCP 终于自然
以前一个 MCP Session 可能需要保持连接。
现在请求完全独立。
因此 MCP Server 可以跑在 Cloud Run、Cloud Functions 或其他 Serverless 平台。
空闲时甚至可以 Scale to Zero。
### 4. 不再为了协议 Session 部署 Redis
Google 明确提到，GitHub MCP Server 已经使用新规范并移除了 Redis Session Storage。
需要注意：
> 业务状态仍然可能需要数据库。
删除的是 Transport Session，而不是所有应用状态。
## HTTP Header 变得非常重要
新规范将 Protocol Version、Method 和 Name 提升到 Header。
这让 Gateway 不用解析 JSON Body，就能做：
- Routing；
- Rate Limit；
- Audit；
- Metrics；
- Security Policy。
例如：
```text
Mcp-Name = delete_user
↓
Require Approval
Mcp-Name = search
↓
Allow
```
## Header 和 Body 不一致怎么办？
规范要求拒绝请求。
如果 Header 是：
```text
Mcp-Name: search
```
Body 却调用：
```text
delete_user
```
Server 应返回 Header Mismatch。
这可以避免 Gateway 看到的是安全工具，而 Body 实际执行另一个高风险工具。
## 缓存也终于变得标准化
新规范引入：
```text
ttlMs
cacheScope
```
Client 可以知道 Tool List 或 Resource Result 多久仍然有效。
大型 Agent 平台可以减少大量重复 `tools/list` 请求。
## 无状态以后，用户确认怎么办？
例如 Server 需要问：
> 你确认删除这三个文件吗？
过去可以保持连接等待。
新规范提供 Multi Round-Trip Requests。
Server 返回：
```text
InputRequiredResult
```
并携带：
```text
requestState
```
Client：
1. 向用户提问；
2. 得到 Yes / No；
3. 带回 `requestState`；
4. 重新发请求。
因为状态已经序列化，任意 Pod 都能继续。
## 长任务怎么办？
例如：
- 数据库备份；
- CRM Sync；
- 大文件分析；
- Refund；
- Build。
可能需要几十秒。
新规范强化 Tasks Extension。
调用后先返回：
```text
taskId
```
后台继续执行。
Client 可以通过任务接口查询进度和最终结果。
Agent 对话不需要一直挂着连接。
## 无状态不等于业务完全无状态
这是必须强调的。
如果工具本身是长任务，业务仍然需要保存：
```text
taskId
status
result
```
区别是：
> Redis 或数据库用于业务 Task State，而不是 MCP Transport Session。
这个分离非常关键。
## 安全变化同样值得关注
新规范加入更明确的 OAuth 安全机制。
### Issuer Verification
Client 验证 `iss`，减少授权响应被劫持风险。
### Resource Indicators
Token 明确指定目标 MCP Server，降低 confused deputy 风险。
### JSON Schema 2020-12
Tool Schema 支持：
- oneOf；
- anyOf；
- allOf；
- `$ref`。
参数验证能力更强。
## 正式 Deprecation 生命周期
新版本建立：
```text
Active
↓
Deprecated
↓
Removed
```
的正式生命周期，并提供迁移窗口。
Roots、Sampling、Logging 等旧机制开始进入废弃路线。
云环境中的结构化可观测性越来越倾向 OpenTelemetry。
这再次说明 MCP 正从本地开发协议转向企业基础设施协议。
## 企业 MCP 架构现在可以简化成什么样？
过去：
```text
Agent
↓
MCP Gateway
↓
Sticky Load Balancer
↓
MCP Pod
↓
Redis Session
```
现在：
```text
Agent
↓
API Gateway
↓
Round Robin Load Balancer
├── MCP Pod
├── MCP Pod
└── MCP Pod
```
业务长任务的 Task Store 独立存在。
这更符合云原生设计。
## Serverless 场景
例如企业有一个低频 `read-invoice` MCP Tool。
过去可能为了 Session 维持常驻服务。
现在可以：
```text
Request
↓
Cloud Run
↓
Scale from Zero
↓
Execute
↓
Return
↓
Scale Down
```
对大量长尾内部工具非常有价值。
## 怎么迁移？
Google 当前建议从 Staging 开始测试。
Python beta 示例：
```bash
pip install "mcp[cli]==2.0.0b1"
```
TypeScript v2 开始拆分 Server / Client Package，并提供 Codemod：
```bash
npx @modelcontextprotocol/codemod@beta v1-to-v2 .
```
生产环境不要一次性升级全部 MCP Server。
## 推荐迁移路线
### 第一步：盘点 Server
记录：
```text
protocol version
transport
session store
tools
auth
traffic
```
### 第二步：找到 Session 依赖
例如：
- In-memory Session；
- Redis；
- Sticky Route。
### 第三步：升级一个只读 Server
比如 `search_docs`。
### 第四步：放到普通 Load Balancer 后
关闭 Sticky Session。
### 第五步：压测
测试：
- Pod 重启；
- Auto Scale；
- Timeout；
- User Confirmation；
- Long Task。
### 第六步：再迁移写操作
重点检查：
- Idempotency；
- Approval；
- Task State。
## 企业现在最应该关注的三个指标
### Session Error Rate
新版本应该接近 0。
### Pod Failover Impact
Pod 重启不应该影响 Client。
### Infrastructure Cost
Redis Session 和常驻 Pod 减少后，成本是否实际下降？
## 最终判断
MCP 2026-07-28 的最大变化不是增加几个 Tool 字段。
而是：
> **MCP 开始真正按照云原生基础设施的方式设计。**
从有状态 Session Protocol 转向 Stateless HTTP Protocol，带来的结果包括：
- 普通 Round Robin；
- 无 Sticky Session；
- Serverless；
- Pod Failover；
- Header Routing；
- Gateway Rate Limit；
- Cache；
- Async Task；
- Multi Round-Trip；
- 更明确安全边界。
如果 MCP 只适合一个开发者电脑上的本地 Server，它永远只是一个很好用的开发工具协议。
而当它能够处理大规模、无状态、可治理、可横向扩展的远程 Server，它才真正开始具备成为企业 Agent 基础设施标准的条件。
想继续了解 MCP、Agent 架构、AI Gateway 和企业 AI 工程实践，可以访问 **智元选**：https://www.zyentorpicks.com/。我们会持续跟踪真正影响生产架构的协议变化。