微软发布了Type Server Protocol（TSP，类型服务器协议）的技术规范文档，该协议定位为语言服务器协议（LSP）的扩展，核心目标是将类型检查能力从语言服务器中剥离出来，交由独立的类型服务器进程承担。LSP由微软于2016年推出，目前已成为编辑器与语言工具间通信的事实标准，VS Code等主流编辑器均基于该协议构建语言支持。然而随着TypeScript、Pyright等类型检查器功能日益复杂，将类型检查与补全、跳转等能力捆绑在同一语言服务器进程中，逐渐暴露出资源占用高、难以跨工具复用等问题。TSP的思路是引入新的协议边界：编辑器可连接一个常驻的类型服务器，由其统一提供类型诊断、悬停类型信息、跳转定义等类型系统能力；语言服务器则专注其余语言特性，并按需向类型服务器请求类型数据。这种解耦设计使同一个类型服务器可同时服务多个编辑器实例，也允许多个语言服务器共享同一份类型分析结果，显著减少重复计算开销。该规范文档托管在微软Pylance项目仓库中，与微软的Python类型检查器Pyright关系密切，预计将率先在Python生态中落地验证，为编辑器与类型工具的协作提供标准化基础设施。
事件分析
TSP延续了微软通过协议定义行业标准的一贯路径——LSP的成功已证明协议层解耦的价值，TSP则进一步把类型系统这一计算密集环节独立出来，技术上借鉴了tsserver常驻进程的思路。产业层面，该协议与Pyright、Pylance生态深度绑定，短期内主要影响Python开发工具链；若被TypeScript等其他语言采纳，可能重塑IDE插件的架构分层。值得对照的是，MCP协议正在标准化AI模型与工具的连接方式，TSP则试图标准化类型能力与语言工具的连接，开发工具栈的整体协议化趋势正在加速。协议能否成为标准，关键在于微软能否吸引VS Code之外的编辑器与开源社区接入，以及是否存在足够多的类型检查器实现来支撑生态。
核心观点：协议即权力：微软用TSP延续LSP的统治策略，把类型检查能力变成编辑器生态的公共地基。
原文链接：Hacker News
