d # 从请求中获取租户 ID
# 状态从外部存储读取（Redis/DB）
context = await self.redis.get(f"context:{trace_id}")
# 执行工具逻辑
result = await self.execute_tool(request.params)
# 证据元信息
result._meta = EvidenceMeta(
trace_id=trace_id,
timestamp=datetime.now().isoformat(),
server_instance=self.instance_id # 用于追踪哪台服务器处理的
)
return result
### 6.3 能力治理的实施清单
将能力治理落地到生产环境，建议按以下顺序推进：
**Phase 1：工具分类（Week 1-2）**
- 盘点所有现有工具，按"数据域"分类
- 标记每个工具的 `dataScope`（当前/历史）
- 标记每个工具的 `capabilityType`（查询/扫描/分析）
- 识别工具间的互斥关系
**Phase 2：描述增强（Week 3-4）**
- 为每个工具补充完整的 `description`
- 添加 `prerequisites` 声明
- 添加 `cacheTtlMs` 建议
- 完善 `inputSchema` 和 `outputSchema`
**Phase 3：治理配置（Week 5-6）**
- 配置限流规则（per-tool, per-tenant）
- 配置成本计量
- 启用审计日志
- 配置缓存策略
**Phase 4：监控体系（Week 7-8）**
- 接入 OpenTelemetry 链路追踪
- 设置工具调用成功率告警
- 设置响应时间 P99 告警
- 构建成本仪表盘
---
## 七、性能对比：v1.x vs v0.28
我们来做一个量化的对比分析：
| 维度 | MCP v1.x（会话模式） | MCP v0.28（无状态） | 提升 |
|------|----------------------|---------------------|------|
| 水平扩容 | 需要黏性会话负载均衡器 | 任意 HTTP 网关即可 | 架构复杂度大幅降低 |
| 故障恢复 | Session 中断需重建 | 任意实例可接管 | RTO ≈ 0 |
| 滚动发布 | 需要优雅停机等待会话迁移 | 任意时刻可切换实例 | 发布窗口扩大 |
| 协议握手 | 2-RTT（initialize + initialized） | 0-RTT（直接调用） | 延迟降低 |
| 网关兼容性 | 仅支持 SSE 感知网关 | 任何 HTTP 网关 | 生态丰富 |
| 工具治理 | 无 | 限流/缓存/审计/计费 | 企业可用 |
| 任务持久化 | 无 | Tasks + MCP Apps | 复杂场景支持 |
| 证据追溯 | 无 | 完整元信息 + Trace Context | 合规保障 |
---
## 八、迁移路径：从 v1.x 到 v0.28
### 8.1 客户端迁移
对于 MCP 客户端（如 Claude Desktop、Cursor、自定义 Agent），迁移主要是协议层面的：
```python
# v1.x 客户端
class MCPv1Client:
async def connect(self, url: str):
self.session = await create_session(url)
await self.session.initialize() # v1.x 需要握手
self.session_id = self.session.id
async def call_tool(self, name: str, args: dict):
return await self.session.call(
"tools/call",
{"name": name, "arguments": args},
headers={"Mcp-Session-Id": self.session_id}
)
# v0.28 客户端
class MCPv28Client:
async def connect(self, url: str):
# v0.28 不需要握手，直接可用
self.base_url = url
async def call_tool(self, name: str, args: dict):
return await self.http.post(
f"{self.base_url}/tools/call",
{
"jsonrpc": "2.0",
"id": self._next_id(),
"method": "tools/call",
"params": {
"name": name,
"arguments": args,
"meta": {
"trace_id": uuid.uuid4().hex,
"tenant_id": self.tenant_id
}
}
}
)
8.2 服务端迁移
对于 MCP Server，迁移需要注意兼容性问题：
class MCPv28CompatibleServer:
async def handle_request(self, request: Request) -> Response:
# 检测客户端协议版本
client_version = request.headers.get("MCP-Version", "1.x")
if client_version.startswith("1."):
# 兼容 v1.x 客户端：维护 Session
return await self._handle_v1(request)
else:
# v0.28+ 客户端：无状态处理
return await self._handle_v28(request)
async def _handle_v28(self, request: Request) -> Response:
# 无状态处理：所有上下文从请求中获取
result = await self._execute_tool(request.json)
# 添加 v0.28 特有的元信息
result["_meta"] = {
"server_version": "0.28.0",
"trace_id": request.params.meta.trace_id,
"capabilities_discovered": True
}
return result
8.3 迁移检查清单
- 确认所有 MCP 客户端升级到支持 v0.28 的版本
- 服务端移除
Mcp-Session-Id依赖 - 将会话级状态外置到 Redis/数据库
- 为每个工具补充
annotations元信息 - 配置限流和审计规则
- 更新文档（工具描述、使用示例）
- 测试故障恢复场景
- 验证水平扩容能力
九、未来展望：MCP 的演进方向
9.1 协议成熟度的判断标准
2026-07-28 规范的发布，标志着 MCP 进入"生产成熟期"。判断一个协议是否达到生产成熟，有几个关键信号：
信号一：规范稳定 —— 协议的基本结构不再频繁变更，企业可以基于稳定规范做长期投入
信号二：治理能力完备 —— 不仅仅是"能用"，还要"管得住"。限流、审计、缓存、追踪等治理能力是生产部署的基础
信号三：生态丰富 —— 有足够多的客户端、Server、网关、中间件选择，企业不会被单一实现绑定
信号四：向后兼容 —— 新版本需要照顾存量部署，不能因为升级而破坏现有系统
从这几个标准看，MCP v0.28 是一个重要的里程碑，但生态的完全成熟还需要时间。
9.2 接下来值得关注的方向
方向一：MCP Apps 生态
随着 MCP Apps 的成熟，可能会出现"企业级 MCP App Store"——企业可以购买、组合标准化的 MCP Apps 来快速构建 Agent 能力。比如"反洗钱 KYC App"、"供应商评估 App"、"竞品分析 App"。
方向二：MCP 安全标准
企查查在实践中已经遇到了 MCP 安全的问题："大模型可能被恶意构造的工具描述或提示词操纵，执行超出预期的操作"。协议层面需要有更严格的能力边界描述和执行机制。
方向三：多模态 MCP
当前 MCP 主要处理文本工具调用。随着 AI Agent 能力的扩展，图像生成、视频处理、代码执行等能力的 MCP 标准化调用也是值得期待的方向。
结语
MCP 2026-07-28 规范的核心，不是增加了几种调用方式，而是推动了 MCP 从"工具连接协议"走向"生产级 Agent 基础设施"。无状态核心让远程 MCP 部署不再需要特殊的会话管理；能力发现机制让大规模工具集可以被系统化理解；任务协作和证据链让 AI Agent 能够完成复杂的企业级任务。
对于正在构建 AI Agent 系统的开发者，这次升级意味着：
- 如果你正在考虑将 MCP 引入生产环境，现在是好时机——协议已经准备好
- 如果你已经部署了 MCP v1.x，升级到 v0.28 可以获得显著的架构简化
- 如果你还在观望，2026-07-28 是一个值得关注的里程碑节点
唯一不变的是变化本身。MCP 的演进还在继续，但方向已经清晰：让 AI Agent 不仅能调用工具，而且能可靠地、可治理地、可持续地调用工具。
选题来源：MCP 2026-07-28 规范候选版技术解读
标签：MCP|AI Agent|协议标准化|生产级 AI|工具调用|无状态架构
关键字：MCP|Model Context Protocol|AI Agent|无状态核心|能力发现|工具治理|企业 AI|协议规范
附：MCP Server 实战开发——从零构建企业级 MCP Server
A.1 项目结构与依赖
让我们通过一个完整示例来展示如何构建一个符合 v0.28 规范的生产级 MCP Server。
# 项目结构
mcp-enterprise-server/
├── src/
│ ├── __init__.py
│ ├── server.py # 主服务器入口
│ ├── tools/ # 工具实现
│ │ ├── __init__.py
│ │ ├── business.py # 企业数据工具
│ │ ├── risk.py # 风险查询工具
│ │ └── legal.py # 法律数据工具
│ ├── governance/ # 治理层
│ │ ├── __init__.py
│ │ ├── rate_limiter.py # 限流器
│ │ ├── cost_tracker.py # 成本计量
│ │ └── audit_logger.py # 审计日志
│ ├── schemas/ # Schema 定义
│ │ ├── business.py
│ │ └── risk.py
│ └── utils/
│ ├── evidence.py # 证据元信息生成
│ └── trace.py # 链路追踪
├── pyproject.toml
├── Dockerfile
└── docker-compose.yaml
# pyproject.toml
[project]
name = "mcp-enterprise-server"
version = "0.28.0"
requires-python = ">=3.11"
dependencies = [
"mcp>=1.0.0",
"fastapi>=0.110.0",