Vercel Python 正式 GA：CPython 原生支持与开发全流程解析

Python 开发者长期以来在部署全栈应用时面临一个割裂的现实：后端用 Python 写业务逻辑，前端却往往需要另一套 JavaScript 工具链，本地开发、预览部署、回滚发布各走各的流程。Vercel 在十个月前启动的 Python 支持项目，目前已经正式进入 GA 阶段。

这次发布的核心思路是让 Python 在 Vercel 上"不像客人，而像原生居民"。从运行时选择到 SDK 设计，再到前后端工作流的统一，Vercel 试图回答一个具体问题：当 Python 开发者把现有项目搬上来时，框架、依赖和项目结构本身能否决定构建和运行方式，而不是被迫改造成平台期望的样子。

三条设计主线：从"能跑"到"像 Python 开发者写的那样跑"

Vercel 为这次 GA 设定了三个目标，它们贯穿了后续几乎所有技术决策。

第一，SDK 要符合 Python 习惯。 这意味着使用类型注解、async/await 以及上下文管理器，而不是把其他语言风格的 API 硬套到 Python 上。

第二，前后端共享同一套工作流。 Python 应用经常搭配 JavaScript 前端，开发者需要能在本地同时运行两者，在同一个预览部署中审查，并一起发布或回滚。

第三，兼容 Python 生态。 运行时使用 Linux 上的 CPython 标准解释器，以保持对现有包和工具的兼容性。

据 Vercel 官方博客介绍，这三条目标决定了从框架检测到 SDK 设计的全部路径。

CPython 是 Python 语言的官方参考实现，用 C 语言编写，绝大多数 Python 包（包括带 C 扩展的 NumPy、Pydantic 等）都以它为目标编译和测试。许多平台为了追求冷启动速度或隔离性，会改用 PyPy、GraalPy 等替代实现，或在容器中裁剪标准库，这往往导致某些依赖无法安装或行为出现偏差。Vercel 明确选择在 Linux 上运行标准 CPython 解释器，实质上是在"启动速度"和"生态兼容性"之间押注后者：开发者不必再为平台适配而替换依赖版本或改写代码，pip/uv 能装的包理论上都能直接运行。

uv 是由 Astral 团队（Ruff 的作者）开发的 Python 包与项目管理工具，用 Rust 编写，兼容 pyproject.toml 标准并可作为 pip、pip-tools、virtualenv 的高速替代。它通过全局缓存和并行解析大幅缩短依赖解析与安装时间，近年被大量新项目采用。Vercel 在部署时读取 uv 管理的依赖文件，意味着使用现代项目管理方式的团队无需额外提供 requirements.txt，锁文件即可决定构建内容。

部署机制：框架检测、Services 与 Daemons

在部署层面，Vercel 会读取项目的依赖文件，包括由 uv 管理的依赖，并自动检测 FastAPI、Flask、Django、FastHTML 等框架。框架定义的"基础设施"负责配置构建和请求路由，静态资源则通过 CDN 提供服务。

对于带有前端的项目，Vercel Services 把前后端合入同一个项目。运行 vercel dev 可以同时启动两者，共享预览则让后端变更能直接在前端环境中测试。

针对从队列或数据库拉取任务的长时间运行 worker，Vercel Daemons 让容器保持运行，同时携带 Python 代码及其包和系统依赖。

这三个机制的组合意味着：Python 后端不再需要为了适配平台而重构项目结构，框架本身就成为部署配置的来源。

Vercel Daemons 针对的是一类传统上与 Serverless 模型相冲突的工作负载：常驻进程。Serverless 函数按请求唤醒、空闲即回收，天然不适合从队列或数据库持续拉取任务的 worker。Daemon 则让容器长时间保持运行，并把 Python 代码连同其依赖的第三方包和系统级库一起打包进去，相当于为后台任务保留了类似传统常驻服务的语义，但仍由同一套部署管线管理。

Vercel Services 可以理解为项目层面的组合抽象：它允许多个服务（如前端静态站与 FastAPI 后端）共存于同一个 Vercel 项目，并共享预览链接、环境变量和发布/回滚生命周期。这一设计直接回应了前后端分属不同仓库或不同平台时常见的"预览环境对不齐"问题。

六个 Python SDK：让基础设施调用符合语言习惯

Vercel 为常见后端需求构建了六个 Python SDK，API 设计遵循 Python 语言惯例：

SDK	用途
AI SDK for Python	生成和流式传输模型响应、调用工具、构建 agent
Sandbox SDK	创建和控制隔离环境以运行代码
Workflow SDK	定义带重试和保存执行状态的持久工作流
Queues SDK	发送和接收消息，用于后台任务和通知
Blob SDK	在对象存储中上传和检索文件
Connect SDK	获取调用外部 API 的凭证

这些 SDK 与开发者已有的框架和库协同工作，而不是替代它们。

持久工作流（Durable Workflow） 是近年兴起的一种执行模型，核心在于把工作流的每一步状态持久化到存储中，使流程在进程崩溃、超时或部署重启后能够从断点恢复，而不是从头重跑。这对调用大模型、执行多步工具链的 AI agent 尤其关键：一次 agent 运行可能涉及多次模型调用和代码执行，任何一步失败都代价高昂。Workflow SDK 提供的重试与状态保存正是围绕这一需求设计。

Sandbox（沙箱） 在这里指隔离的代码执行环境，通常基于容器或轻量虚拟机实现，用于运行不可信或可能出错的用户代码，防止其访问应用后端、数据库或宿主文件系统。SDK 化的 Sandbox 让 Python 后端可以用几行代码创建、挂载依赖并在其中执行代码，而无需自行搭建隔离基础设施。

实战案例：协作文档应用如何串联这些能力

为了展示各组件如何配合，Vercel 工程师构建了一个协作式 Web 应用，用于创建和浏览 Python notebook。用户可以在其中创建 notebook、发布供他人浏览或 fork，并使用 AI 助手编写和运行 Python 代码。

该应用采用 Vite 前端 + FastAPI 后端 + PostgreSQL 存储 notebook 源码和对话历史。Services 让前后端保持在同一部署中，前端通过 CDN 提供服务。

编辑与运行代码： 已登录用户在编辑器中打开 notebook 时，FastAPI 创建或复用运行 Jupyter 的 Vercel Sandbox，将用户代码与应用后端隔离。浏览器直接连接 Jupyter，挂载的 Drives 提供 Python 依赖和工作区文件。

保存与发布： 浏览器定期将当前 notebook 发送给 FastAPI。FastAPI 将源码保存到 PostgreSQL，将变更渲染为 HTML 并上传到 Blob，这样读者可以通过 CDN 阅读已发布的 notebook，而无需启动 Python kernel。

共享更新： 发布变更后，FastAPI 通过 Vercel Queues 发送消息。每个连接了浏览器的后端实例收到通知后，通过 WebSocket 推送更新后的 notebook 列表，用户无需刷新即可看到变更。

代码辅助： Agent 使用 AI SDK for Python，运行在 Vercel Workflows 中，保存执行状态并对失败步骤进行重试。对话历史保存在 PostgreSQL 中，notebook 编辑和执行工具通过已连接的浏览器工作，浏览器将结果发回 FastAPI 以恢复工作流。

这个案例的价值在于它展示了 Vercel 所主张的"原生感"究竟如何落地：Sandbox 负责隔离执行，Queues 处理实时通知，Blob 承担静态内容分发，Workflow 保障 AI agent 的可靠性。每个组件都解决一个具体问题，而不是为了堆砌功能。

社区投入与 PEP 827

Vercel 的 Python 团队来自 Gel Data 团队，由本文作者和 Elvis Pranskevichus 领导，于去年 12 月加入 Vercel。团队同时宣布赞助 Python Software Foundation，并承诺通过基金会资助 Serhiy Storchaka 一年的 CPython 维护工作。据博客披露，Serhiy 在 2026 年已向 CPython 主分支提交超过 600 个 commit。

团队还赞助了 PyCon US 和 EuroPython，并发布了 PEP 827。如果该提案被接受，将增加类型操作特性，帮助 FastAPI 等框架以更少样板代码提供更简洁的 API 和更精确的类型检查。

PEP（Python Enhancement Proposal，Python 增强提案） 是 Python 社区引入语言特性的标准流程，任何语法或类型系统层面的改动都需要经过提案、讨论和核心开发者裁决。PEP 827 由 Vercel 团队提出，聚焦"类型操作"（type operations）能力，目标是让框架作者能以更少的样板代码表达更精确的类型签名。影响的典型场景如 FastAPI 这类严重依赖类型注解做依赖注入和请求校验的框架：更强的类型操作意味着框架可以在不牺牲类型检查精度的前提下简化用户侧的声明式 API。提案能否被接受仍需社区审议，但它反映了平台厂商开始反哺语言底层生态。

展望

Vercel 表示将继续改进 Python SDK、运行时性能，以及面向人和编码 agent 的开发工作流。对于遇到部署问题或发现 SDK 缺失功能的开发者，官方建议在 Vercel Community 中反馈，以引导后续开发方向。

对于已经在使用 Python 构建全栈应用的团队来说，这次 GA 意味着一个值得评估的选项：如果项目恰好使用 FastAPI、Flask 或 Django，且前端是 JavaScript，那么 Vercel 的这套方案可能减少部署管线的维护成本。但真正的考验仍在于实际迁移时的兼容性细节，以及六个 SDK 在复杂场景下的稳定性。