Vercel 正式支持 Python：从后端 API 到 AI Agent 的一等公民

Vercel 长期被视为前端和 JavaScript 生态的部署平台，但这个定位正在被改写。官方宣布 Python 正式成为 Vercel 的一等语言与运行时，开发者可以用 FastAPI、Flask 或 Django 构建 API、全栈应用乃至 AI Agent，并与 JavaScript 前端共享同一套开发和部署工作流。

框架与运行时：基础设施交给 Vercel

Vercel 这次没有走「插件式支持」的路线，而是把 Python 当作原生运行时来对待。FastAPI、Flask 和 Django 应用会被自动识别和配置，框架专属的静态资源服务也直接走 Vercel CDN，不需要额外写适配层。

运行时层面，Vercel 在 Linux 上跑 CPython，依赖管理支持 uv 和 pyproject.toml。对已经用 uv 管理项目的团队来说，迁移成本接近零；对习惯 requirements.txt 的团队，则需要做一次轻量调整。

计算形态分成两条线：请求驱动的应用通过 Fluid compute 弹性伸缩，长时间运行的拉取型负载则交给 Vercel Daemons。这个区分很关键——它意味着 Vercel 不再只服务「短请求」场景，后台 worker 类任务也有了对应用法。

Fluid compute 与拉取型负载的差异

Fluid compute 是 Vercel 对传统 Serverless 执行模型的改良：它允许实例在请求之间保持一定存活状态，从而降低冷启动频率，并能在流量高峰时按需弹性伸缩，但不保证实例长期驻留。与之相对的「拉取型负载」指需要持续运行、主动消费队列或轮询外部系统的进程，例如后台 Worker、定时任务或消息消费者。这类负载如果放在普通 Serverless 函数里，会因为执行时长上限和实例回收而中断，所以 Vercel 单独提供了 Vercel Daemons。理解这条分界线很重要：它决定了你该把代码放进请求驱动的函数，还是放进常驻进程，两者的伸缩策略、计费方式和失败恢复模型都不相同。

原生 Python SDK：Agent 与工作流的基础设施

这次发布里更值得关注的是原生 Python SDK 的组合能力。开发者可以在同一个 Python 应用里按需选用这些组件：

• Sandbox：按需为应用或 Agent 提供隔离的 Linux VM，适合执行不受信任的代码
• AI SDK for Python（Beta）：生成或流式输出模型响应、调用工具，通过 uv add ai 即可引入
• Workflow SDK for Python（Beta）：持久化执行状态，失败步骤可重试
• Queues（Beta）：面向后台工作的消息收发
• Connect：获取调用外部 API 所需的凭证
• Blob：对象存储中的文件上传与读取

这套 SDK 可以单独使用，也可以组合在同一个应用里。说个细节 Sandbox 和 AI SDK 的搭配——在隔离环境中运行模型生成的代码，是当下 Agent 产品绕不开的安全命题，Vercel 选择把它做成平台原语而不是让开发者自己拼装。

Sandbox 与「执行不受信任代码」

在 Agent 场景里，模型经常被要求生成并运行代码，比如数据分析脚本、网页抓取片段或工具调用逻辑。直接在主应用进程中执行这些代码风险极高：一段恶意或错误的代码可能读取环境变量、访问内网、写坏文件系统。Sandbox 提供的是按需创建、用完即弃的隔离 Linux VM，让这类代码在受限环境中运行，从而把爆炸半径限制在单个沙箱内。Vercel 把它做成平台原语，意味着开发者不必自己维护容器编排或安全边界，只需调用 SDK 就能把「模型生成代码—隔离执行—取回结果」串成一条链路，这对构建生产级 Agent 是基础性的能力。

前后端同项目：Services 与共享预览

对全栈应用，Vercel Services 允许前端和后端部署在同一个项目里，共享预览环境，部署和回滚保持原子性。项目内可以按 service 查看日志，后端之间通过 service bindings 私有连接。

配置方式是在仓库根目录放一个 vercel.toml。官方给的例子是前端放在 frontend/，FastAPI 的 app 定义在 backend/main.py：

[services.web]
root = "frontend/"

[services.api]
root = "backend/"
entrypoint = "main:app"

[[rewrites]]
source = "/(.*)"
destination = { service = "web" }

[[rewrites]]
source = "/api/(.*)"
destination = { service = "api" }

/api/ 下的请求以原路径抵达匹配的 FastAPI 路由，其余请求走前端。本地用 vercel dev 同时运行两个 service，再从同一个仓库一起部署。

vercel.toml 中的 services 与 rewrites

vercel.toml 是 Vercel 项目级的声明式配置文件，放在仓库根目录即可生效。[services.*] 段用来定义同一个项目里的多个子应用，每个 service 通过 root 指定代码目录，并通过 entrypoint 指定 Python 应用的入口（如 main:app 表示 main.py 中的 app 对象）。[[rewrites]] 段则是路由规则：source 匹配请求路径，destination 决定转发目标。示例中第一条规则把所有路径交给 web 服务，第二条把 /api/ 开头的路径交给 api 服务，且原路径被保留，因此 FastAPI 里定义的路由无需改动前缀。这种配置让前端和后端共用一份部署描述，预览环境、回滚和日志也随之一体化。

这意味着什么

Vercel 的 Python 支持不是简单的「也能跑 Python」，而是把 Python 放进了和 JavaScript 对等的位置：同一套预览、同一套原子部署、同一套日志体系。对已经在 Vercel 上跑 Next.js 的团队，后端不必再迁到别处；对以 Python 为主的团队，前端和 Agent 层可以收进同一个项目。

真正拉开差距的可能是 Agent 相关的 SDK 组合。Sandbox、Workflow、Queues、AI SDK 这几个原语覆盖了构建生产级 Agent 的主要难点，而它们现在都在 Python 里可用。

如果你正在评估后端托管方案，可以先用一个小型 FastAPI 服务验证 vercel.toml 和 Services 的工作方式，再决定是否把现有后端整体迁入。更完整的说明可以参考 Vercel 的 Python 官方文档。

为什么 uv 和 pyproject.toml 值得关注

uv 是近两年在 Python 社区快速普及的包管理与环境工具，主打极快的解析和安装速度，并用 pyproject.toml 作为统一的项目与依赖声明文件。它正在逐步替代 requirements.txt 加 virtualenv 的传统组合。Vercel 在运行时层面直接支持 uv 和 pyproject.toml，意味着已经采用现代 Python 工程实践的项目可以近乎零改动地迁移，不必为平台写额外的依赖描述或构建脚本。对仍在使用 requirements.txt 的团队，迁移成本也很低，但需要把依赖迁移到 pyproject.toml 的格式，这一步在本地开发与 CI 中同样有益，因为依赖锁定和版本解析会变得更可复现。