2026 年 10 月 27 日，微软正式推出 Type Server Protocol（简称 TSP）。在此次架构更新中，维护了十年的 Pyright 从 Pylance 内部抽离为可替换组件。Meta 的开源类型检查器 Pyrefly 则作为首个外部后端完整接入。
这项改动让 Language Server Protocol（LSP）之上多了一层专门处理类型语义的协议通道。在补全、跳转与内联提示退为下游消费者后，这套协议将类型系统转变为独立的语义查询服务。它的核心受众延伸至自动化分析工具与代码 Agent。
微软解耦十年核心：Pylance 不再绑定 Pyright
在以往的架构设计中，Pylance 与 Pyright 深度绑定。Pyright 负责遍历语法树并构建类型推导，Pylance 则负责外部封装，承载 VS Code 里的补全、跳转与环境管理。这种紧耦合保证了开箱即用的稳定性，却锁死了底层的类型分析实现。
TSP 打破了这种单体架构。Pylance 继续保留 Python 智能层与 Copilot 集成，但诊断与类型计算被抽象为独立服务。Pyright 退回为默认检查器选项，其他引擎只要符合 TSP 规范即可接入。
这种解耦让开发者不必为了更换检查器而放弃成熟的工作区生态。如果直接使用独立运行的第三方插件，用户将失去与环境管理及 Copilot 的深度联动。通过 Pylance 桥接 TSP，编辑器得以在维持既有体验的同时吞吐新的计算引擎。
Meta 带来每秒 180 万行吞吐：Pyrefly 填补超大规模工程短板
Meta 成为 TSP 的首个重量级外部盟友，带来了全面遵循 TSP 规范的 Pyrefly。Pyrefly 在基准测试中展现出每秒 180 万行的类型检查吞吐能力。面对数百万行代码的单体仓库，类型分析从分钟级压缩到秒级响应，消除了全量检查造成的卡顿。
这种性能表现源自 Meta 长期维护 Instagram 等超大 Python 系统的工程积累。自 2017 年起，Meta 持续探索大规模动态语言的静态类型化方案。Pyrefly 并非概念验证产物，它在落地前已经经受了严苛的生产环境验证。
为了让类型系统在真实场景可用，Meta 针对科学计算核心库进行了深度标注。数据显示，NumPy 的类型完整度已接近 90%，pandas 的公共 API 也完成了全面类型覆盖。动态第三方库获得了高精度的静态推导依据。在缺乏显式类型标注的代码段中，检查后端依然能推导出明确类型。
拆出快照与多通道：TSP 协议为自动化工具铺路
从规范定义看，TSP 建立在 LSP 之上。二者采用相同的 JSON-RPC 通信机制。类型服务器在后台维护工作区状态，集中处理版本协商、搜索路径与模块导入解析。规范与 TypeScript 接口定义均已开源托管在 microsoft/pylance-release 仓库的 docs/tsp 路径下。
0.4.1 版本规范引入了两项关键设计：快照绑定的类型结果，以及多连接只读通道。编辑器排版只需单向诊断，自动化分析却需要并发读取代码状态。多通道机制允许外部进程并发读取类型数据，且不会阻塞主界面编辑。
协议对外提供三类核心查询：推导类型（computed）、声明类型（declared）与期望类型（expected）。这三类接口把抽象语法树拍平成结构化数据。外部工具调用简单 RPC 即可获知变量约束。这种细分结构把代码上下文拆解为确定性字段，自动化代理无需自行解析 AST 即可直接获取类型约束。
零成本平滑切换：在 VS Code 中接入 Pyrefly
对于终端用户，体验新后端的过程被设计得足够轻量。运行环境需要安装 2026.4.1 或更新版本的 Pylance 扩展，Pyrefly 版本需达到 0.60.0 以上。这两个版本基准确立了协议握手边界。只读多通道机制得以在双端稳定运行。
当工作区或虚拟环境中安装了 Pyrefly，或者配置文件包含 [tool.pyrefly] 时，VS Code 会自动识别并弹出确认提示。点击确认后，编辑器即可平滑启用 Pyrefly 作为底层诊断来源。
图：第一步，工作区环境中安装 Pyrefly 后，VS Code 弹出提示询问是否将其作为类型诊断来源。来源：devblogs.microsoft.com
开发者也可以在设置面板中手动干预。在设置项 Python › Analysis: Diagnostics Source 中，系统提供了三个选项：Pylance、Pylance + Pyright 以及 Pylance + Pyrefly。这种设计保留了随时回退到默认引擎的自由度。
图：第二步，在 Python 扩展设置中配置 Diagnostics Source，允许在 Pylance 内选择不同检查器。来源：devblogs.microsoft.com
完成切换后，VS Code 底部状态栏会实时显示当前的诊断来源。状态栏文案为 Diagnostics Source: Pylance + Pyrefly。此时类型检查工作已由 Pyrefly 接管。顶层的交互逻辑与快捷操作依然由 Pylance 原生驱动。
图：第三步，编辑器底部状态栏显示生效的诊断后端，确认 Pylance 与 Pyrefly 正常协同。来源：devblogs.microsoft.com
重构底层生态位：类型服务变成 AI 基础设施
如果只为了在编辑器里标记语法错误，微软无需拆解打磨十年的 Pyright。这一转变的核心驱动力，来自大模型编程时代对代码上下文的需求。Copilot 补全、代码对话以及 MCP 工具，都需要高度精确且稳定的类型语义支撑。
大模型单凭文本匹配难以理清复杂工程中的动态分发。类型服务器将工程的符号依赖预先计算成图谱，并通过快照接口暴露。代码 Agent 发起结构化查询即可获知参数类型与约束，降低了生成代码的错误率。
微软用开放协议换取了生态位优势。确立了类型查询标准，便定义了智能工具与代码库交互的语义接口。类型分析走向服务化，直接重塑了智能化开发工具链的底层基础设施。
参考链接：
- 微软 Python 官方博客发布公告
- Pyrefly 官方技术文档与基准测试
