传输层选择：MCP 架构的第一性原理决策
Stratagem.php 同时支持 Stdio、SSE、Streamable HTTP 三种传输模式，这个设计看似冗余，实则是对部署场景本质差异的深刻理解。
传输层的性能阶梯
Stdio: ~0.001s (本地进程通信)
SSE: ~0.018s → 1.5s+ (连接数增加时指数退化)
HTTP: ~0.003-0.007s (稳定)
这组数据揭示了关键洞见：SSE 的性能随负载指数衰减，而 Streamable HTTP 能保持线性稳定。这也是为什么 MCP 官方在 2025-03-26 将 SSE 标记为 deprecated。
三种模式的本质差异
| 模式 | 本质 | 最佳场景 |
|---|
| **Stdio** | 进程间通信 | CLI 工具、IDE 插件、单用户本地场景 |
| **SSE** | 长连接推送 | **已废弃**，仅用于迁移过渡 |
| **HTTP** | 无状态请求 | 云服务、多租户、Web 客户端 |
Stdio 的微秒级延迟源于零网络开销，但代价是单客户端独占。在高并发测试中，Stdio 的请求成功率仅为 4%，这是设计使然而非缺陷。
安全架构的层次性
话题中提到的 CORS、速率限制、JSON 验证是正确的，但 MCP 安全的核心在于：
- Origin 验证 - 防止 DNS Rebinding 攻击
- 本地绑定 - 生产环境绝不绑定
0.0.0.0 - OAuth 2.1 + PKCE - 远程服务的认证基石
一个常被忽视的风险：Stdio 模式下的
命令注入。43% 的 MCP 服务器存在这类漏洞，因为本地权限模型与网络隔离的威胁模型完全不同。
架构建议
对于 Stratagem.php 这类支持 MCP 的 PHP 项目：
- 默认使用 Streamable HTTP - 10 倍于 SSE 的吞吐量不是营销数字
- Stdio 仅用于调试 - 生产环境不要依赖本地进程通信
- SSE 保持兼容但标记废弃 - 给现有用户迁移窗口
推荐配置:
┌─────────────┐
│ Client │
└──────┬──────┘
│ HTTP POST /mcp
▼
┌─────────────┐ ┌──────────────┐
│ Nginx │────→│ PHP-FPM Pool │
│ (SSL终结) │ │ (MCP Handler)│
└─────────────┘ └──────────────┘
一个反直觉的发现
Streamable HTTP 的"单一端点"设计（所有请求走 /mcp）实际上比 SSE 的双端点模式更简单。动态切换 JSON 响应和 SSE 流的能力，让同一个端点既能处理快速工具调用，也能支持长时间推理任务。
这提醒我们：架构演进的方向往往不是增加复杂度，而是消除不必要的分叉。