技术笔记

MCP 协议：当 AI Agent 需要一套通用语言

发布于 2026-05-21

MCPModel Context ProtocolAI Agent协议AI 基础设施

🎬 一、开篇

2024年11月，Anthropic 开源了 MCP——一个不起眼的实验项目。
一年半后，局面彻底改变：Google、OpenAI、Microsoft、AWS 相继宣布支持，
GitHub 上 3000 多个 MCP Server 投入使用，
MCP 正式纳入 Linux Foundation 旗下的 Agentic AI Foundation。

一个协议，从零走到行业共识，只用了一年半。

如果你在 2024 年搭建过一个 AI Agent，你大概率经历过这样的场景：你的模型要调用 Slack API、要查询 PostgreSQL、要写文件到 Google Drive——每个工具都要手写一个 function call wrapper，参数格式自己定，错误处理自己写。换一个模型供应商？大部分 wrapper 重写一遍。

这就是 MCP 要解决的核心问题：AI Agent 的 HTTP——一套通用协议，取代无数私有连接器。

📊 二、全景：MCP 当前所处的位置

M×N 问题

假设你的公司有 5 个 LLM 供应商、20 个内部数据源。没有 MCP 的话，你需要 5 × 20 = 100 个定制连接器。每个连接器都是独家协议、独家格式、独家认证方式。

MCP 的做法：每个数据源暴露一个 MCP Server，所有 LLM 通过同一个协议连接。5 + 20 = 25 个接口，节约 75%。

协议核心架构

MCP 采用三层模型：

Host（宿主编程器，如 Claude Desktop / VS Code）
  └── Client（协议客户端，每个连接一个）
        └── Server（工具/数据提供方）

三者的职责很清楚：

层	职责
Host	启动连接、管理用户授权、协调多 Client
Client	与 Server 建立一对一连接、能力协商、协议消息收发
Server	暴露 Tools / Resources / Prompts，执行具体操作

Server 可以提供三类能力：

能力	说明	类比
Tools	模型可以执行的函数（有副作用）	API endpoint
Resources	模型可以读取的上下文数据	文件系统
Prompts	预定义的提示词模板	快捷键

Client 也有能力反向提供给 Server：

能力	说明
Sampling	Server 请求 LLM 生成内容（不需要 Server 自己持有 API Key）
Roots	Server 请求 Client 告知文件系统边界
Elicitation	Server 请求 Client 向用户索取更多信息

关键设计：JSON-RPC 2.0

协议底层使用 JSON-RPC 2.0。有状态连接，Client 和 Server 首次握手时互相通告能力集，之后按需调用。

// Tool 调用示例
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "东京",
      "unit": "celsius"
    }
  }
}

🌊 三、传输层进化：从 SSE 到 Streamable HTTP

第一代：SSE + HTTP POST

2024 年最初的 MCP spec 使用 Server-Sent Events（SSE）做 Server → Client 推送，HTTP POST 做 Client → Server 请求。

缺点明显：

SSE 是单向长连接，无法做负载均衡
企业 WAF 难以检查 SSE 内容
调试困难

第二代：Streamable HTTP（2025年3月）

2025 年 3 月的 spec 更新（2025-03-26）用 Streamable HTTP 取代了 SSE。统一到单个 HTTP 端点 /mcp，支持流式响应和普通响应。

GET /mcp → Server 推送流式事件
POST /mcp → Client 发送请求，Server 流式或单次响应

ヘッダー: Mcp-Session-Id → 会话恢复

关键改进：

企业级兼容：HTTP 请求可以被标准 WAF 检查、可以被标准负载均衡器分发
简化部署：不需要专门维护 SSE 连接池
会话恢复：通过 Mcp-Session-Id header 支持断线重连

2026 路线图中的传输层方向

2026 年路线图将传输层列为第一优先级。要点：

无状态 Session：当前 MCP 的 Session 是有状态的，这阻碍了水平扩展。方向是把状态外置到 Redis / 数据库，让任意 Server 实例处理任意请求。
MCP Server Cards：通过 .well-known/mcp.json 暴露静态元数据——不需要建立连接即可发现服务能力。
不做新传输协议：路线图明确表示这个周期不会增加新的官方传输协议，只演进现有的 Streamable HTTP。

🗺️ 四、2026 路线图：四大优先方向

2026 年 3 月发布的路线图，揭示了 MCP 从开发者工具协议转向生产级基础设施协议的决心。

1. 🚄 传输层演进（Transport Evolution）

前面已经详细讨论过。核心是让 MCP 能跑在真正的生产环境中，而不是开发者的笔记本上。

2. 🤖 エージェント間通信（Agent Communication）

Tasks 原语（SEP-1686）：这是路线图中最具突破性的新概念。

Tools 是同步的——调用 → 等待 → 返回。 Tasks 是异步的——提交任务 → 拿到任务 ID → 轮询进度 → 获取结果。

# Tools（同步）
result = tool.call(params)
# 等待直到完成

# Tasks（异步）
task_id = task.submit("分析这份100页的报告")
while True:
    status = task.get_status(task_id)  # processing / completed / failed
    if status == "completed":
        result = task.get_result(task_id)
        break
    time.sleep(5)

这在多 Agent 协作场景中至关重要。Agent A 提交一个长时间分析任务给 Agent B，然后去做其他事，完成任务后回来拿结果。

当前 Tasks 以实验功能发布，路线图正在填充生命周期缺口：重试语义、结果过期策略、进度通知机制。

3. 🏛️ 治理成熟化（Governance Maturation）

MCP 已经成长为一个多公司参与的开放标准（Linux Foundation / AAIF）。治理需要跟上。

路线图中的关键措施：

贡献者阶梯（Contributor Ladder）：社区参与者 → WG 贡献者 → WG 协调人 → 首席维护者，每步有明确的提名和审查标准
Working Group 自治：可信的 WG 可以在自己的领域内接受 SEP，无需等待核心维护者审核——这是解决审核瓶颈的关键举措
SEP 流程：Specification Enhancement Proposal，类似 Python 的 PEP / Rust 的 RFC

4. 🏢 企业就绪（Enterprise Readiness）

这是 2026 路线图中最「早期」的方向——明确表示需要更多企业参与者加入。

审计追踪：Agent 调用了哪些工具、传了什么参数、返回了什么结果——企业级日志
SSO 集成：通过 OAuth 2.1 + OIDC 接入企业身份体系
网关标准化：在 MCP Client 和 Server 之间放置策略执行点
配置可移植性：跨环境（开发/测试/生产）迁移 MCP 配置

路线图的立场很有意思：大部分企业需求应该通过 Extensions（扩展）实现，而不是改核心协议。 核心协议保持轻量，企业特性作为可选扩展层叠加。

🔬 五、实战：我在用的 MCP

理论说完了，来看看 MCP 在真实环境中怎么工作的。

我自己在用的 AI Agent（Hermes Agent）内置了 Native MCP Client。配置方式很简单——在配置文件中声明 MCP Server：

mcp_servers:
  # stdio 传输——MCP Server 作为子进程运行
  filesystem:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projects"]

  # HTTP 传输——远程 MCP Server
  company_api:
    url: "https://mcp.company.com/v1/mcp"
    headers:
      Authorization: "Bearer sk-xxx"

启动后，Agent 自动连接所有 Server，发现它们暴露的工具，注册到工具列表中。开发者不需要写任何适配代码——MCP 工具和内置工具平起平坐。

实际体验的几点观察

新工具即插即用：加一行配置，重启动 Agent，新能力立刻可用
Transport 透明：stdio 还是 HTTP 对上层 Agent 没有区别
环境隔离：MCP Server 子进程继承经过过滤的环境变量（API Key 手动白名单），不会泄露宿主环境
工具数量超过一定规模后，工具的 Schema 描述会大量消耗 Token——目前有 Lazy Loading 方案（按需加载工具描述），但还在演进中
Server 端错误处理参差不齐：有些 Server 返回规范错误，有些返回原始异常
子进程生命周期管理：Server 崩溃后自动重连机制依赖各 SDK 实现质量

Sampling 能力的实际意义

MCP 的 Sampling 可能是被低估的特性。它允许 MCP Server 反向请求 LLM 生成内容，而不需要 Server 自己持有 API Key。

举个例子：一个数据分析 MCP Server 在处理请求时，可以请求 Host 通过 LLM 生成一段解释性文本。Server 不需要 API Key，不需要管用的是 Claude 还是 GPT——由 Host 决定模型。

这在企业环境中非常重要：工具提供方不需要持有模型密钥，模型提供方不需要暴露工具端点。 安全边界清晰。

⚔️ 六、竞争格局

MCP vs A2A（Agent-to-Agent）

Google 在 2025 年 4 月发布了 A2A（Agent-to-Agent）协议。常被拿来和 MCP 比较，但实际上两者解决的是不同层级的问题：

维度	MCP	A2A
层级	Tool 层（模型 ↔ 工具）	Agent 协作层（Agent ↔ Agent）
核心问题	如何标准化工具调用	如何标准化 Agent 间协作
消息格式	JSON-RPC 2.0	JSON-RPC + Task 描述
状态模型	有状态连接	无状态 + 任务清单
适用场景	数据库查询、API 调用、文件操作	多 Agent 编排、跨组织协作

两者不是替代关系，而是互补关系。理想情况下：Agent 内部用 MCP 调用工具，Agent 之间用 A2A 协调任务。

各厂商的落地

Anthropic：MCP 的发起者，Claude Desktop / Claude Code 全面内置
OpenAI：2025 年 3 月宣布支持 MCP，Agents SDK v0.12 加入 MCP 重试和错误规范化
Google：支持 MCP 的同时推出 ADK v2.0 的 Task API（A2A 的 Python 实现）
Microsoft：推出 Agent Governance Toolkit（AGT）——在 MCP Client 和 Server 之间插入策略执行层，扫描工具定义、检查输入输出、记录审计日志
Vercel：@ai-sdk/mcp v2 作为独立包发布，支持 OAuth2.0、Structured Output、Resources

微软的 Agent Governance Toolkit

特别值得关注的是微软的 AGT。它反映了企业客户对 MCP 的根本担忧：工具调用越方便，安全风险越大。

AGT 的功能：

工具定义扫描：在 Agent 看到工具描述之前，检查是否有隐藏指令、伪装攻击、对抗性模式
逐调用策略执行：用声明式规则（YAML / OPA / Cedar）在每次工具调用前做策略检查，开销 <1ms
响应检查：工具返回的内容在传给 Agent 之前过内容策略
身份与信任：每个 Agent 获得加密身份（Ed25519 + 量子安全 ML-DSA-65），信任分 0-1000
只读不可篡改的审计日志：哈希链形式记录每次工具调用

AGT 映射到 OWASP MCP Top 10 覆盖 7/10，其余 3 项在路线图中。

🔮 七、展望

上下文窗口危机

MCP 越流行，一个问题越突出：工具 Schema 会吃掉上下文窗口。

早期测试中，一个连接了 20 个 MCP Server 的 Agent，光 Tool Definitions 就能吃掉 70000+ Token。如果每个工具的 Schema 描述都在，留给真正对话的 Token 空间所剩无几。

解决方案方向：

Tool Search：Agent 先加载一个「搜索工具」的工具，用它来发现其他工具——而不是一次性加载全部
Lazy Loading：设置 defer_loading = true，只在实际需要时才加载具体工具的 Schema
工具分组与命名空间：按域（数据库 / 协同 / 文件）组织，Agent 只加载当前域

MCP Apps——UI 交互层

MCP Apps 是 2026 年 1 月发布的官方扩展。它让 MCP 工具可以返回富交互 UI，而不仅仅是纯文本。

// MCP App 示例：系统监控仪表盘
{
  "app": {
    "type": "dashboard",
    "url": "https://mcp-apps.example.com/system-monitor"
  }
}

支持 Client：Claude（Web + Desktop）、Goose、VS Code Insiders、ChatGPT。

该不该接入 MCP？

你面对的情况	建议
1-2 个简单工具、单模型	function calling 足够，MCP 收益不明显
5+ 工具、多模型切换	强烈建议 MCP——省掉 N×M 的集成成本
企业级、审计合规要求	MCP + AGT 级联方案，值得投入
跨团队/跨平台复用工具	MCP Server 一次编写，到处运行

💡 结语

MCP 在一年半的时间里完成了从「Anthropic 的一个实验项目」到「Linux Foundation 下的行业标准」的跨越。它的成功不在于技术有多精巧——JSON-RPC 2.0 + HTTP 不是什么新技术——而在于它在这个时间点恰好解决了行业最痛的协作问题。

当你需要在 5 个 LLM 和 20 个工具之间来回折腾的时候，一条简单的规则就价值千金：写一次协议，到处跑。

接入 MCP 还是再等等？两种选择在当前阶段各有适用场景，取决于团队的优先级和风险偏好。

🎬 一、开篇

2024年11月，Anthropic 开源了 MCP——一个不起眼的实验项目。
一年半后，局面彻底改变：Google、OpenAI、Microsoft、AWS 相继宣布支持，
GitHub 上 3000 多个 MCP Server 投入使用，
MCP 正式纳入 Linux Foundation 旗下的 Agentic AI Foundation。

一个协议，从零走到行业共识，只用了一年半。

这就是 MCP 要解决的核心问题：AI Agent 的 HTTP——一套通用协议，取代无数私有连接器。

📊 二、全景：MCP 当前所处的位置

M×N 问题

MCP 的做法：每个数据源暴露一个 MCP Server，所有 LLM 通过同一个协议连接。5 + 20 = 25 个接口，节约 75%。

协议核心架构

MCP 采用三层模型：

Host（宿主编程器，如 Claude Desktop / VS Code）
  └── Client（协议客户端，每个连接一个）
        └── Server（工具/数据提供方）

三者的职责很清楚：

层	职责
Host	启动连接、管理用户授权、协调多 Client
Client	与 Server 建立一对一连接、能力协商、协议消息收发
Server	暴露 Tools / Resources / Prompts，执行具体操作

Server 可以提供三类能力：

能力	说明	类比
Tools	模型可以执行的函数（有副作用）	API endpoint
Resources	模型可以读取的上下文数据	文件系统
Prompts	预定义的提示词模板	快捷键

Client 也有能力反向提供给 Server：

能力	说明
Sampling	Server 请求 LLM 生成内容（不需要 Server 自己持有 API Key）
Roots	Server 请求 Client 告知文件系统边界
Elicitation	Server 请求 Client 向用户索取更多信息

关键设计：JSON-RPC 2.0

协议底层使用 JSON-RPC 2.0。有状态连接，Client 和 Server 首次握手时互相通告能力集，之后按需调用。

// Tool 调用示例
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "东京",
      "unit": "celsius"
    }
  }
}

🌊 三、传输层进化：从 SSE 到 Streamable HTTP

第一代：SSE + HTTP POST

2024 年最初的 MCP spec 使用 Server-Sent Events（SSE）做 Server → Client 推送，HTTP POST 做 Client → Server 请求。

缺点明显：

SSE 是单向长连接，无法做负载均衡
企业 WAF 难以检查 SSE 内容
调试困难

第二代：Streamable HTTP（2025年3月）

2025 年 3 月的 spec 更新（2025-03-26）用 Streamable HTTP 取代了 SSE。统一到单个 HTTP 端点 /mcp，支持流式响应和普通响应。

GET /mcp → Server 推送流式事件
POST /mcp → Client 发送请求，Server 流式或单次响应

ヘッダー: Mcp-Session-Id → 会话恢复

关键改进：

企业级兼容：HTTP 请求可以被标准 WAF 检查、可以被标准负载均衡器分发
简化部署：不需要专门维护 SSE 连接池
会话恢复：通过 Mcp-Session-Id header 支持断线重连

2026 路线图中的传输层方向

2026 年路线图将传输层列为第一优先级。要点：

无状态 Session：当前 MCP 的 Session 是有状态的，这阻碍了水平扩展。方向是把状态外置到 Redis / 数据库，让任意 Server 实例处理任意请求。
MCP Server Cards：通过 .well-known/mcp.json 暴露静态元数据——不需要建立连接即可发现服务能力。
不做新传输协议：路线图明确表示这个周期不会增加新的官方传输协议，只演进现有的 Streamable HTTP。

🗺️ 四、2026 路线图：四大优先方向

2026 年 3 月发布的路线图，揭示了 MCP 从开发者工具协议转向生产级基础设施协议的决心。

1. 🚄 传输层演进（Transport Evolution）

前面已经详细讨论过。核心是让 MCP 能跑在真正的生产环境中，而不是开发者的笔记本上。

2. 🤖 エージェント間通信（Agent Communication）

Tasks 原语（SEP-1686）：这是路线图中最具突破性的新概念。

Tools 是同步的——调用 → 等待 → 返回。 Tasks 是异步的——提交任务 → 拿到任务 ID → 轮询进度 → 获取结果。

# Tools（同步）
result = tool.call(params)
# 等待直到完成

# Tasks（异步）
task_id = task.submit("分析这份100页的报告")
while True:
    status = task.get_status(task_id)  # processing / completed / failed
    if status == "completed":
        result = task.get_result(task_id)
        break
    time.sleep(5)

这在多 Agent 协作场景中至关重要。Agent A 提交一个长时间分析任务给 Agent B，然后去做其他事，完成任务后回来拿结果。

当前 Tasks 以实验功能发布，路线图正在填充生命周期缺口：重试语义、结果过期策略、进度通知机制。

3. 🏛️ 治理成熟化（Governance Maturation）

MCP 已经成长为一个多公司参与的开放标准（Linux Foundation / AAIF）。治理需要跟上。

路线图中的关键措施：

贡献者阶梯（Contributor Ladder）：社区参与者 → WG 贡献者 → WG 协调人 → 首席维护者，每步有明确的提名和审查标准
Working Group 自治：可信的 WG 可以在自己的领域内接受 SEP，无需等待核心维护者审核——这是解决审核瓶颈的关键举措
SEP 流程：Specification Enhancement Proposal，类似 Python 的 PEP / Rust 的 RFC

4. 🏢 企业就绪（Enterprise Readiness）

这是 2026 路线图中最「早期」的方向——明确表示需要更多企业参与者加入。

审计追踪：Agent 调用了哪些工具、传了什么参数、返回了什么结果——企业级日志
SSO 集成：通过 OAuth 2.1 + OIDC 接入企业身份体系
网关标准化：在 MCP Client 和 Server 之间放置策略执行点
配置可移植性：跨环境（开发/测试/生产）迁移 MCP 配置

路线图的立场很有意思：大部分企业需求应该通过 Extensions（扩展）实现，而不是改核心协议。 核心协议保持轻量，企业特性作为可选扩展层叠加。

🔬 五、实战：我在用的 MCP

理论说完了，来看看 MCP 在真实环境中怎么工作的。

我自己在用的 AI Agent（Hermes Agent）内置了 Native MCP Client。配置方式很简单——在配置文件中声明 MCP Server：

mcp_servers:
  # stdio 传输——MCP Server 作为子进程运行
  filesystem:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projects"]

  # HTTP 传输——远程 MCP Server
  company_api:
    url: "https://mcp.company.com/v1/mcp"
    headers:
      Authorization: "Bearer sk-xxx"

启动后，Agent 自动连接所有 Server，发现它们暴露的工具，注册到工具列表中。开发者不需要写任何适配代码——MCP 工具和内置工具平起平坐。

实际体验的几点观察

新工具即插即用：加一行配置，重启动 Agent，新能力立刻可用
Transport 透明：stdio 还是 HTTP 对上层 Agent 没有区别
环境隔离：MCP Server 子进程继承经过过滤的环境变量（API Key 手动白名单），不会泄露宿主环境
工具数量超过一定规模后，工具的 Schema 描述会大量消耗 Token——目前有 Lazy Loading 方案（按需加载工具描述），但还在演进中
Server 端错误处理参差不齐：有些 Server 返回规范错误，有些返回原始异常
子进程生命周期管理：Server 崩溃后自动重连机制依赖各 SDK 实现质量

Sampling 能力的实际意义

MCP 的 Sampling 可能是被低估的特性。它允许 MCP Server 反向请求 LLM 生成内容，而不需要 Server 自己持有 API Key。

这在企业环境中非常重要：工具提供方不需要持有模型密钥，模型提供方不需要暴露工具端点。 安全边界清晰。

⚔️ 六、竞争格局

MCP vs A2A（Agent-to-Agent）

Google 在 2025 年 4 月发布了 A2A（Agent-to-Agent）协议。常被拿来和 MCP 比较，但实际上两者解决的是不同层级的问题：

维度	MCP	A2A
层级	Tool 层（模型 ↔ 工具）	Agent 协作层（Agent ↔ Agent）
核心问题	如何标准化工具调用	如何标准化 Agent 间协作
消息格式	JSON-RPC 2.0	JSON-RPC + Task 描述
状态模型	有状态连接	无状态 + 任务清单
适用场景	数据库查询、API 调用、文件操作	多 Agent 编排、跨组织协作

两者不是替代关系，而是互补关系。理想情况下：Agent 内部用 MCP 调用工具，Agent 之间用 A2A 协调任务。

各厂商的落地

Anthropic：MCP 的发起者，Claude Desktop / Claude Code 全面内置
OpenAI：2025 年 3 月宣布支持 MCP，Agents SDK v0.12 加入 MCP 重试和错误规范化
Google：支持 MCP 的同时推出 ADK v2.0 的 Task API（A2A 的 Python 实现）
Microsoft：推出 Agent Governance Toolkit（AGT）——在 MCP Client 和 Server 之间插入策略执行层，扫描工具定义、检查输入输出、记录审计日志
Vercel：@ai-sdk/mcp v2 作为独立包发布，支持 OAuth2.0、Structured Output、Resources

微软的 Agent Governance Toolkit

特别值得关注的是微软的 AGT。它反映了企业客户对 MCP 的根本担忧：工具调用越方便，安全风险越大。

AGT 的功能：

工具定义扫描：在 Agent 看到工具描述之前，检查是否有隐藏指令、伪装攻击、对抗性模式
逐调用策略执行：用声明式规则（YAML / OPA / Cedar）在每次工具调用前做策略检查，开销 <1ms
响应检查：工具返回的内容在传给 Agent 之前过内容策略
身份与信任：每个 Agent 获得加密身份（Ed25519 + 量子安全 ML-DSA-65），信任分 0-1000
只读不可篡改的审计日志：哈希链形式记录每次工具调用

AGT 映射到 OWASP MCP Top 10 覆盖 7/10，其余 3 项在路线图中。

🔮 七、展望

上下文窗口危机

MCP 越流行，一个问题越突出：工具 Schema 会吃掉上下文窗口。

解决方案方向：

Tool Search：Agent 先加载一个「搜索工具」的工具，用它来发现其他工具——而不是一次性加载全部
Lazy Loading：设置 defer_loading = true，只在实际需要时才加载具体工具的 Schema
工具分组与命名空间：按域（数据库 / 协同 / 文件）组织，Agent 只加载当前域

MCP Apps——UI 交互层

MCP Apps 是 2026 年 1 月发布的官方扩展。它让 MCP 工具可以返回富交互 UI，而不仅仅是纯文本。

// MCP App 示例：系统监控仪表盘
{
  "app": {
    "type": "dashboard",
    "url": "https://mcp-apps.example.com/system-monitor"
  }
}

支持 Client：Claude（Web + Desktop）、Goose、VS Code Insiders、ChatGPT。

该不该接入 MCP？

你面对的情况	建议
1-2 个简单工具、单模型	function calling 足够，MCP 收益不明显
5+ 工具、多模型切换	强烈建议 MCP——省掉 N×M 的集成成本
企业级、审计合规要求	MCP + AGT 级联方案，值得投入
跨团队/跨平台复用工具	MCP Server 一次编写，到处运行

💡 结语

当你需要在 5 个 LLM 和 20 个工具之间来回折腾的时候，一条简单的规则就价值千金：写一次协议，到处跑。

接入 MCP 还是再等等？两种选择在当前阶段各有适用场景，取决于团队的优先级和风险偏好。

当 AI Agent 敲不开门

AI Agent反爬数据生态平台垄断豆包手机

Token 经济学：当运营商开始卖算力

Token 经济学三大运营商算力经济AI 基础设施中国电信中国移动中国联通

MCP 协议：当 AI Agent 需要一套通用语言MCPプロトコル：AIエージェントに必要な共通言語

🎬 一、开篇

📊 二、全景：MCP 当前所处的位置

M×N 问题

协议核心架构

关键设计：JSON-RPC 2.0

🌊 三、传输层进化：从 SSE 到 Streamable HTTP

第一代：SSE + HTTP POST

第二代：Streamable HTTP（2025年3月）

2026 路线图中的传输层方向

🗺️ 四、2026 路线图：四大优先方向

1. 🚄 传输层演进（Transport Evolution）

2. 🤖 エージェント間通信（Agent Communication）

3. 🏛️ 治理成熟化（Governance Maturation）

4. 🏢 企业就绪（Enterprise Readiness）

🔬 五、实战：我在用的 MCP

实际体验的几点观察

Sampling 能力的实际意义

⚔️ 六、竞争格局

MCP vs A2A（Agent-to-Agent）

各厂商的落地

微软的 Agent Governance Toolkit

🔮 七、展望

上下文窗口危机

MCP Apps——UI 交互层

该不该接入 MCP？

💡 结语

🎬 一、开篇

📊 二、全景：MCP 当前所处的位置

M×N 问题

协议核心架构

关键设计：JSON-RPC 2.0

🌊 三、传输层进化：从 SSE 到 Streamable HTTP

第一代：SSE + HTTP POST

第二代：Streamable HTTP（2025年3月）

2026 路线图中的传输层方向

🗺️ 四、2026 路线图：四大优先方向

1. 🚄 传输层演进（Transport Evolution）

2. 🤖 エージェント間通信（Agent Communication）

3. 🏛️ 治理成熟化（Governance Maturation）

4. 🏢 企业就绪（Enterprise Readiness）

🔬 五、实战：我在用的 MCP

实际体验的几点观察

Sampling 能力的实际意义

⚔️ 六、竞争格局

MCP vs A2A（Agent-to-Agent）

各厂商的落地

微软的 Agent Governance Toolkit

🔮 七、展望

上下文窗口危机

MCP Apps——UI 交互层

该不该接入 MCP？

💡 结语

相关文章

MCP 协议：当 AI Agent 需要一套通用语言