docs: update MCP transport from HTTP+SSE to Streamable HTTP

Author: Snailclimb

docs/ai/agent/mcp.md

@@ -20,7 +20,7 @@ head:
 3. MCP v1.0 的四大核心能力是什么？
 4. ⭐ MCP 的四层分层架构是如何运行的？
 5. 为什么 MCP 选择了 JSON-RPC 2.0 而非 RESTful？
-6. ⭐️ MCP 支持哪些传输方式？
+6. ⭐️ MCP 支持哪些传输方式？（stdio、Streamable HTTP）
 7. ⭐ 生产环境下开发 MCP Server 有哪些必知的最佳实践？
 
 ## MCP 基础概念
@@ -299,33 +299,55 @@ MCP 采用 **JSON-RPC 2.0** 作为应用层通信协议，原因如下：
 - **源码审计**：审阅社区 Server 的源代码，只使用可信来源的 Server；建议建立沙箱突破审计日志。
 - **网络限制**：沙箱内禁止出站网络连接，防范数据外泄。
 
-**HTTP/SSE 模式增强安全**：
+**Streamable HTTP 模式增强安全**：
 
-- **认证机制**：添加 OAuth 2.0 或 API Key 认证。
+- **认证机制**：每条请求携带标准 `Authorization` 头，支持 OAuth 2.0 或 API Key 认证（旧版 HTTP+SSE 只在建立 SSE 连接时校验一次，后续请求无法逐条鉴权）。
 - **传输加密**：强制 TLS 1.3，防止中间人攻击。
 - **访问控制**：基于 RBAC 限制 Resources 和 Tools 的访问权限。
 
-#### HTTP/SSE（Server-Sent Events）
+#### Streamable HTTP（推荐）
 
-| 特性         | 说明                             |
-| ------------ | -------------------------------- |
-| **适用场景** | 远程部署、独立服务               |
-| **实现方式** | HTTP POST 发送请求，SSE 推送响应 |
-| **优势**     | 易穿透防火墙，支持流式推送       |
-| **典型应用** | Web 应用、团队共享的 MCP 服务    |
+> MCP 协议版本 `2025-03-26` 正式引入 Streamable HTTP 传输方式，取代了旧版的 HTTP+SSE。旧版 HTTP+SSE 使用两个端点（`/sse` 持久连接 + `/sse/messages` 发送消息），已**标记为废弃**，不建议在新项目中使用。
+
+| 特性           | 说明                                                                                                      |
+| -------------- | --------------------------------------------------------------------------------------------------------- |
+| **适用场景**   | 远程部署、独立服务、生产环境                                                                              |
+| **实现方式**   | 单端点（如 `/mcp`），客户端 POST 发送 JSON-RPC 请求，服务端按需返回 JSON 响应或 SSE 流                    |
+| **优势**       | 标准兼容性好（负载均衡器、API 网关、CORS 中间件开箱即用），每条请求独立鉴权，无需维护长连接                |
+| **典型应用**   | Web 应用、团队共享的 MCP 服务、云端托管 MCP Server                                                        |
+
+**Streamable HTTP 核心机制**：
+
+| 能力             | 说明                                                                                                     |
+| ---------------- | -------------------------------------------------------------------------------------------------------- |
+| **单端点交互**   | 所有客户端→服务端消息通过 POST 发送到同一端点（如 `https://example.com/mcp`）                             |
+| **灵活响应**     | 服务端返回 `application/json`（简单请求-响应）或 `text/event-stream`（流式推送，如进度通知）              |
+| **会话管理**     | 通过 `Mcp-Session-Id` 响应头分配会话 ID，客户端在后续请求中携带                                           |
+| **可恢复性**     | 基于 SSE 事件 ID + `Last-Event-ID` 请求头实现断线重连后消息补发                                           |
+| **服务端推送**   | 客户端可通过 GET 请求打开独立 SSE 流，接收服务端主动推送的通知和请求（可选能力）                          |
+
+**Streamable HTTP vs 旧版 HTTP+SSE 对比**：
+
+| 对比维度     | 旧版 HTTP+SSE（已废弃）                       | Streamable HTTP（当前推荐）                       |
+| ------------ | ---------------------------------------------- | ------------------------------------------------- |
+| **端点数量** | 两个（`/sse` + `/sse/messages`）              | 一个（如 `/mcp`）                                 |
+| **连接模型** | 必须维护持久 SSE 连接                          | 标准 HTTP 请求-响应，SSE 可选                     |
+| **认证**     | 仅连接建立时校验，后续无法逐条鉴权             | 每条 POST 请求携带 `Authorization` 头，逐条鉴权   |
+| **基础设施** | 需要粘性会话，与负载均衡器/API 网关兼容性差    | 与标准 HTTP 基础设施天然兼容                      |
+| **会话管理** | 非正式化                                       | `Mcp-Session-Id` 头，生命周期明确                 |
 
 **选型决策**：
 
 ![MCP 传输方式选择](https://oss.javaguide.cn/github/javaguide/ai/skills/mcp-transport-decision.png)
 
 #### 传输层异常与背压分析（生产级考量）
 
-| 风险类型                 | stdio 模式                                                            | HTTP/SSE 模式            | 工程防御手段                                               |
-| ------------------------ | --------------------------------------------------------------------- | ------------------------ | ---------------------------------------------------------- |
-| **子进程僵死**           | 高：Server 异常退出时，Host 可能未正确回收子进程，产生 Zombie Process | 低：无子进程概念         | 配置 `SIGCHLD` 信号处理器 + `waitpid` 兜底回收             |
-| **文件描述符泄漏**       | 高：stdin/stdout 管道未关闭会导致 FD Leak，最终耗尽系统资源           | 中：长连接未及时释放     | 设置 FD 上限（`ulimit -n`），实现连接池健康检查            |
-| **长连接中断**           | 中：Server 崩溃导致管道断裂                                           | 高：网络抖动触发重连风暴 | 指数退避重试 + 熔断机制（Circuit Breaker）                 |
-| **背压（Backpressure）** | 缺失：stdio 无流量控制机制                                            | 部分：SSE 可控制推送速率 | 实现滑动窗口限流，超出缓冲区时返回 `429 Too Many Requests` |
+| 风险类型                 | stdio 模式                                                            | Streamable HTTP 模式              | 工程防御手段                                               |
+| ------------------------ | --------------------------------------------------------------------- | ---------------------------------- | ---------------------------------------------------------- |
+| **子进程僵死**           | 高：Server 异常退出时，Host 可能未正确回收子进程，产生 Zombie Process | 低：无子进程概念                   | 配置 `SIGCHLD` 信号处理器 + `waitpid` 兜底回收             |
+| **文件描述符泄漏**       | 高：stdin/stdout 管道未关闭会导致 FD Leak，最终耗尽系统资源           | 低：标准 HTTP 连接，框架自动管理   | 设置 FD 上限（`ulimit -n`），实现连接池健康检查            |
+| **连接中断**             | 中：Server 崩溃导致管道断裂                                           | 低：每次请求独立，天然容错         | 指数退避重试 + 熔断机制（Circuit Breaker）                 |
+| **背压（Backpressure）** | 缺失：stdio 无流量控制机制                                            | 原生支持：HTTP 状态码控制流量      | 实现滑动窗口限流，超出缓冲区时返回 `429 Too Many Requests` |
 
 ## 工程实践
 
@@ -498,7 +520,7 @@ MCP 协议的出现，标志着 AI 应用开发从"各自为战"走向"标准化
 1. **MCP 是什么**：AI 领域的"USB-C 接口"，通过 JSON-RPC 2.0 统一了 LLM 与外部工具的通信规范
 2. **四大核心能力**：Resources（只读数据）、Tools（可执行动作）、Prompts（预设指令）、Sampling（请求 LLM 推理）
 3. **四层架构**：Host → Client → Server → Data Source，一对多连接，模型无感知
-4. **传输方式**：stdio（本地）、HTTP/SSE（远程），各有适用场景
+4. **传输方式**：stdio（本地）、Streamable HTTP（远程），各有适用场景
 5. **生产级实践**：工具粒度设计、Context Window 管理、安全防护、失败路径处理
 
 **与其他概念的区别**：