Agent 继续执行
await client.continue_task({
"task_id": "task-uuid-123",
"resume_from": "stage-2"
})
这个机制让 AI Agent 可以像人类一样"边做边问"，而不需要在上一步就把所有信息都问清楚。
---
## 五、证据链与可追溯：从"说了什么"到"依据能否还原"
### 5.1 企业场景的证据需求
在企业级 AI 应用中，AI 给出的结论往往需要被审计和追溯。考虑以下场景：
**场景：银行信贷审批**
信审员使用 AI Agent 辅助审查一家供应商的资质。AI 给出了"该供应商存在重大法律风险，建议拒绝"的结论。
三个月后，供应商投诉："凭什么拒绝我们？" 信审员需要回答：
- AI 的结论基于哪些数据？
- 数据的时间点是什么？
- 有没有可能数据已经过期？
**旧版 MCP 的问题**：工具调用结果只返回自然语言数据，没有任何元信息可以追溯。
**新版 MCP 的改进**：每个工具调用结果都携带结构化的证据元信息。
```json
// v0.28+ 工具调用结果（带证据元信息）
{
"result": {
"data": {
"company_name": "企查查科技股份有限公司",
"credit_code": "91110108MA01XXXXX",
"risk_level": "high",
"litigation_count": 23,
"penalty_count": 5
},
"_meta": {
"evidence_id": "evidence-uuid-789",
"data_source": "qcc_mcp_business_data",
"query_timestamp": "2026-07-26T07:00:00+08:00",
"data_timepoint": "current",
"confidence": 0.95,
"fields_used": ["litigation_count", "penalty_count", "risk_level"],
"raw_response_hash": "sha256:abc123...",
"limitations": [
"仅覆盖中国大陆司法数据",
"行政处罚数据可能存在 7 天更新延迟"
]
}
}
}
5.2 完整 JSON Schema 的生产价值
2026-07-28 规范将工具的输出 Schema 升级到完整的 JSON Schema 2020-12，这不只是格式升级，而是让结构化交付成为可能。
旧版 Schema（简化）：
{
"type": "object",
"properties": {
"company_name": {"type": "string"},
"risk_level": {"type": "string"}
}
}
新版 Schema（完整）：
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"company_name": {
"type": "string",
"description": "企业名称"
},
"risk_level": {
"type": "string",
"enum": ["low", "medium", "high", "critical"],
"description": "综合风险等级"
},
"litigation_count": {
"type": "integer",
"minimum": 0,
"description": "当前有效诉讼数量"
},
"last_updated": {
"type": "string",
"format": "date-time",
"description": "数据更新时间"
}
},
"required": ["company_name", "risk_level", "last_updated"],
"additionalProperties": false
}
完整 Schema 的价值在于：
- 客户端可以自动验证返回数据的完整性
- AI Agent 可以知道哪些字段是必填的、哪些是可选的
- 可以自动生成类型安全的客户端代码
- 数据质量可以被系统化地监控
5.3 链路追踪：W3C Trace Context 集成
新版 MCP 引入了 W3C Trace Context 标准，让每次工具调用都可以被纳入分布式追踪体系：
# 工具调用时注入链路追踪上下文
result = await client.call_tool(
"risk_scan",
{"company_id": "qcc-123"},
trace_context={
"traceparent": "00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01",
"tracestate": "congo=t61rcWkgMzE"
}
)
# 链路追踪结构
trace = {
"trace_id": "0af7651916cd43dd8448eb211c80319c",
"span_id": "b7ad6b7169203331",
"parent_span_id": "a1b2c3d4e5f6", # 调用方 span
"duration_ms": 234,
"tools_in_chain": [
"company_anchor",
"risk_scan",
"litigation_query",
"penalty_query"
],
"tokens_used": 18432,
"errors": []
}
对于企业级部署，这意味着：
- 可以精确分析每次 AI 推理的耗时分布（哪个工具最慢？）
- 可以发现工具调用链中的错误和异常
- 可以审计每次 AI 决策背后的完整数据路径
- 可以对比不同 AI 模型在同一任务上的表现差异
六、企业级 MCP 架构：实战设计模式
6.1 一个完整的企业 MCP 部署架构
基于 2026-07-28 规范，一个生产级的 MCP 部署架构大概是这样的：
┌──────────────────────────────────────────────────────────────────────┐
│ 客户端层 │
│ Claude Desktop | Cursor | 自定义 Agent | 第三方平台 │
└──────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ MCP Gateway（Envoy/Kong） │
│ • JWT 鉴权 & 租户隔离 │
│ • 限流（per-tenant, per-tool） │
│ • 链路追踪（OpenTelemetry） │
│ • 请求路由（根据 tool/server 分发） │
│ • 响应缓存（基于 cacheTtlMs） │
│ • 成本计量（per-tool-cost tracking） │
└──────────────────────────────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ Business MCP │ │ Legal MCP │ │ DocParse MCP │
│ Server │ │ Server │ │ Server │
│ ───────────── │ │ ───────────── │ │ ───────────── │
│ 185 tools │ │ 10 tools │ │ 2 tools │
│ (company/risk/ │ │ (laws/cases/ │ │ (PDF→struct/ │
│ ip/opera...) │ │ citations) │ │ doc→struct) │
└───────────────────┘ └───────────────────┘ └───────────────────┘
│ │ │
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ 企业数据源 │ │ 法律数据库 │ │ 文档存储 │
│ (工商/司法/ │ │ (裁判文书/ │ │ (PDF/Word/ │
│ 知识产权/...) │ │ 法规/...) │ │ Excel) │
└───────────────────┘ └───────────────────┘ └───────────────────┘
6.2 无状态 Server 的实现模式
在 2026-07-28 规范下，MCP Server 应该是完全无状态的。这意味着：
# 错误示范：Server 中存储会话状态
class MCPStatefulServer:
def __init__(self):
self.sessions = {} # ❌ 不应该在 Server 中维护会话状态
self.cache = {} # ❌ 不推荐：限制水平扩容
async def handle_request(self, request):
session_id = request.headers.get("Mcp-Session-Id") # ❌ v0.28 已移除
if session_id in self.sessions:
return self.sessions[session_id]
# 正确示范：无状态 Server
class MCPStatelessServer:
def __init__(self, redis_url: str, upstream_db: str):
self.redis = aioredis.from_url(redis_url) # ✅ 状态外置到 Redis
self.db = create_db_pool(upstream_db)
# ✅ 无本地状态，可水平扩展
async def handle_request(self, request: MCPRequest) -> MCPResponse:
# 每个请求自包含所有必要信息
trace_id = request.meta.trace_id # 从请求中获取链路 ID
tenant_id = request.meta.tenant_id # 从请求中获取租户 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），迁移主要是协议层面的：
# 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",