在此之前，Trae连接MCP Server支持两种传输方式：
1、stdio传输，主要用于本地进程与AI模型的交互，它基于操作系统进程间通信的机制，主要应用于本地环境。
2、SSE传输，主要用于远程通信，它是一种基于HTTP的服务器推送技术，允许服务器通过长连接主动向客户端发送数据流。
本次更新新增了一种传输方式--Streamable HTTP 传输方式，那么Streamable HTTP 传输方式到底是什么呢，与之前有啥区别。
Streamable HTTP 的核心定义
Streamable HTTP 是 MCP 协议在 2025 年引入的新型传输机制，用于替代传统的 HTTP + SSE（Server-Sent Events）方案。
它通过统一端点和动态流式传输能力，解决长连接资源消耗、断线不可恢复等关键问题，同时保留实时数据推送的优势。
核心工作原理
1、统一通信端点：移除传统独立的 /sse 端点，所有请求和响应均通过单一端点（如 /message 或 /mcp）处理。 客户端通过 POST/GET 发送请求，服务器可动态选择返回 即时 HTTP 响应 或 升级为 SSE 流式传输。
2、动态传输模式切换：服务器根据任务需求灵活选择响应方式： 普通 HTTP 响应：适用于简单请求（如数学计算、文本处理），直接返回结果。 SSE 流式响应：适用于长时任务（如大文件处理、AI 生成），分批次推送进度或结果，完成后自动关闭连接
3、会话管理与断线恢复 会话标识（Mcp-Session-Id）：通过 HTTP Header 传递会话 ID，服务器可关联历史状态，支持多轮对话。 断线恢复：网络中断后，客户端凭会话 ID 重连，服务器恢复进度。
4、无状态服务器支持：无需维持长连接，适合 Serverless 架构。
与传统 HTTP + SSE 的关键对比
特性 | HTTP + SSE | Streamable HTTP |
|---|---|---|
连接管理 | 强制长连接，高并发资源压力大 按需建立连接 | 支持短响应/流式传输 |
断线恢复 | 中断后需重头开始 | 凭会话 ID 恢复进度 |
端点复杂度 | 需维护 /sse 和 /message 双端点 | 单一端点简化集成（如 /mcp） |
服务器状态 | 需保持长连接状态 | 支持无状态模式，释放资源 |
兼容性 | CDN/防火墙可能阻断长连接 | 纯 HTTP 协议，兼容现有基础设施 |
核心优势
1、灵活性：按需启用流式传输，避免不必要的长连接开销。
2、可靠性：会话恢复机制提升弱网环境下的用户体验（如移动端）。
3、资源效率：无状态设计降低 70% 服务器资源消耗，支持万级并发。
4、开发简化：客户端代码量减少 40%+，无需独立处理 SSE 通道。
从以上对比情况可以看出来，Streamable HTTP主要是为了节省资源和提升传输效率，那么在Trae支持该传输模式以后，有部分只支持Streamable HTTP传输方式的MCP就可以在Trae中使用啦。
好了，今天就说到这里了，如果对你有所启发，麻烦动动你宝贵的小手点个赞，谢谢！
