MCP 的 initialize 握手做什么？协议版本协商是怎么进行的？
initialize 是 Client 发给 Server 的第一个请求，一次交换三样东西：协议版本、双方能力（capabilities）、双方身份信息。版本协商规则是 Client 报出自己支持的 protocolVersion（协议版本按日期命名，如 2025-06-18），Server 回一个双方都兼容的版本；对不上时常见做法是 Server 回退到自己支持的版本，由 Client 检查回应版本后决定是否继续。
完整回答
握手在同一条响应里同时完成两件事：版本协商与 capability negotiation（能力协商，双方声明自己提供和接受的能力，此后只能用协商过的能力）。以本站 POST /api/mcp 的真实实现为例：Server 支持 2024-11-05、2025-03-26、2025-06-18 三个版本，Client 请求的版本在支持列表内就照用，不在就回退到服务端最新版 2025-06-18；同一条响应还返回 capabilities（如 tools.listChanged=false 表示工具列表变化时 Server 不主动推送）和 serverInfo。Client 确认后必须再发一条 notifications/initialized——通知是没有 id、不应答的消息，本站对通知一律回 202 空响应——会话才算就绪，之后才是 tools/list、tools/call 这类正常请求。等通知的响应是死等，跳过握手直接调用则属于协议违规。
加分信息
- 能区分一次握手里完成的两件事：协议版本协商与能力协商
- 知道通知不应答：initialized 发完不等响应，等了就卡住
常见问题
- 跳过 initialize 直接发 tools/call
- 以为版本对不上握手一定失败，其实规范允许 Server 回退版本、由 Client 决定是否继续
面试官可能追问
- Client 只支持 2024-11-05，Server 回应了 2025-06-18，Client 应该怎么决策？
- capabilities 里 listChanged=false 对 Client 后续行为有什么约束？
/labs/mcp-tools 的第一帧就是 initialize 的请求与响应原文，能直接看到 protocolVersion、capabilities 和 serverInfo 三个字段的真实取值；版本列表与回退逻辑即 lib/agent-runtime/mcp.ts 的实现。