Python Workers 正式可用
两年前，我们推出了 Python Workers，让开发者可以在 Cloudflare Workers 运行时里运行 Python 应用。目标很简单：用 Python 写 Worker，体验要和 TypeScript 一样顺畅，同时让 Python 的包和框架生态“开箱即用”。今天，Python Workers 正式可用（GA）。GA 意味着什么？意味着 Python 在 Cloudflare 开发者平台上成为一等公民，获得完整支持。你可以直接拿来自己熟悉的 Python 代码、库和设计模式，无缝对接 Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflows 以及 Cloudflare 平台的其他服务。你也可以在 Python Workers 里运行 FastAPI、Django、Flask 这些主流 Python 框架。甚至可以用 Dynamic Workers 在一个 Worker 里创建另一个 Python Worker。
Python Workers 的发展历程
把 Python 引入 Cloudflare Workers 是顺理成章的选择。Workers 从 2018 年就支持 WebAssembly，这为我们提供了理想的环境来运行编译成 Wasm 的 Python 解释器。借助 Pyodide，我们很快就让 Cloudflare Workers 支持了大量 Python 应用。我们的目标是打造第一个可无限扩展的 Python 应用平台，同时让开发体验和性能与在其他地方写 Python 应用一样好。今天重点介绍的功能，是多年投入的结果。很多开发者已经在 Python Workers 上构建应用；现在，我们把这些能力做成生产可用，开放给所有人。
Python 成为 Cloudflare Workers 运行时的一等语言
Python Workers 现在原生支持 Cloudflare 开发者平台的绑定（bindings）。以前，在 Python Workers 里使用这些 Cloudflare 绑定，需要在 RPC 边界上把 Python 对象显式转换成 TypeScript 对象。举例来说，把一个 Python 字典发送到 Cloudflare Queue，需要下面这段胶水代码才能工作：
过去，Python 开发者在编写 Python Workers 时，必须时刻惦记着 JavaScript 环境和代码，人和 AI 智能体都经常在这里出错。为此，我们把整套类型转换过程封装进了 Workers 运行时和 Python SDK。现在，你可以用符合 Python 习惯的方式使用所有 Cloudflare 绑定（binding），不用写一行 JavaScript 代码，下面这些用法都能直接跑通。
Web 框架：FastAPI、Django 和 Flask
现在，你可以在 Python Workers 里运行自己熟悉的 Python 框架，比如 FastAPI、Django、Flask，用它们搭建 API 服务器。我们内置了一个连接器，可以轻松把 Web 应用接入 Python Workers。假设你有一个简单的 FastAPI 应用：
在原生环境里，通常要用 uvicorn 这类 Web 服务器来运行这个应用。到了 Python Workers 里，用我们提供的 workers.asgi 包就能运行同一个应用，只需在代码里加上这一小段：
同样，你也可以用 workers.wsgi 包运行 Django 这类同步 Web 应用。
那么，底层到底发生了什么？Python 有一套标准约定，规定了 Web 应用应该如何与 Web 服务器通信，这就是 Web 服务器网关接口（WSGI），以及它对应的现代异步版本 ASGI。有了这套标准，开发者写出来的应用就能完全不依赖具体的服务器。在传统部署方式里，像 Uvicorn、Gunicorn 这样的 Web 服务器负责处理大量并发的客户端连接和线程，以此应对流量增长；而 FastAPI 这类 Web 框架则可以专注于应用逻辑本身。在 Cloudflare Workers 里，Workers 平台本身就是那台 Web 服务器。我们的全球网络已经能够自动完成负载均衡和无限扩容，所以没必要在 Python Workers 内部再跑一个服务器，重复造轮子。取而代之的是，我们的 workers.asgi 和 workers.wsgi 连接器充当一座轻量、经过优化的桥梁。它们把进来的原生 JavaScript 请求转换成 Python 应用所期望的标准 WSGI/ASGI 结构，再把响应顺畅地送出去，额外开销极小。
这样一来，Python 开发者两头的好处都能拿到：你可以用自己喜欢的 Web 框架来写代码、组织项目，同时让 Cloudflare Workers 平台把你的 API 瞬间扩展到全球，全程不用配置任何服务器。这些连接器不仅能配 FastAPI、Django 或 Flask 使用，任何基于 WSGI 或 ASGI 接口的 Python Web 框架都可以。关于各个 Web 框架的具体用法，可以查阅 Python Workers 文档。
在 Python Workers 中使用 PostgreSQL 和 MySQL 与 Hyperdrive 集成
如果你正在用 PostgreSQL 或 MySQL 这类关系型数据库构建 Python 应用，现在可以把 Hyperdrive 集成到 Python Workers 里了。以前 Python Workers 不支持 TCP socket，所以数据库驱动根本没法用。要理解这个限制从何而来，得先看看 WebAssembly 是怎么运作的。
像 aiomysql 或 asyncpg 这样的 Python 数据库驱动，依赖标准库里的 socket 模块来建立连接。在普通环境中，这个模块会向底层操作系统发起 POSIX 系统调用。但在 WebAssembly 沙箱里，这些 POSIX 网络系统调用通常只是占位实现，一调用就失败。任何尝试打开标准 socket 的操作都会立刻报错。
为了解决这个问题，我们借助 Workers 的 connect API 实现了 socket 系统调用。当数据库驱动尝试建立 TCP 连接时，请求会走我们自定义的 socket 系统调用实现。它把 Python 中打开连接、读取字节这类标准 socket 操作，翻译成 Workers 运行时对应的 JavaScript 调用。因为这种转换发生在系统调用层面，数据库驱动完全不需要知道底层是怎么实现的。正是这座 socket 桥梁，让 Hyperdrive 集成成为可能。
要在 Python Workers 中使用 Hyperdrive，首先把数据库接入 Hyperdrive，并在 Wrangler 配置里设置好绑定：
然后，用你熟悉的数据库驱动连接 Hyperdrive：
想了解在 Python Workers 中具体怎么用 Hyperdrive、目前支持哪些包，可以参考 Hyperdrive Python Workers 的文档。
扩展 WebAssembly 包生态
Python Workers 运行在 WebAssembly 沙箱里，所以凡是带原生 C/C++/Rust 扩展的包，都必须先交叉编译成 WebAssembly 才能在 Python Workers 里使用。但此前一直没有一套标准做法，能把任意 Python 包交叉编译到 WebAssembly。这意味着我们团队只能手动编译、自己托管一些定制好的 WebAssembly 包，可用包的数量因此受到很大限制。我们想改变这一点，让用户可以选用更丰富的包。
不过，我们并不想只做一批“仅限 Python Workers 使用”的包——那样对社区没有好处。Python Workers 构建在 Pyodide 之上，所以我们希望生态的演进能同时惠及 Pyodide 和整个 Python-on-WebAssembly 社区。为此，我们提出了 PEP 783，为在浏览器运行时中运行 Python 定义了一个标准化平台，命名为 PyEmscripten。经过一年多的讨论和打磨，这个提案已被接受。包维护者现在可以针对 PyEmscripten 平台构建并发布包，并在所有实现了 PyEmscripten 的环境中通用。
我们还稳定了现有的 Pyodide 构建工具链，并把它改造成所有包维护者都能上手的形式，让开发者可以轻松为 PyEmscripten 平台构建包。此外，我们在 cibuildwheel 中增加了对 PyEmscripten 平台的支持，方便其他人跟进适配。虽然生态仍在逐步采纳这一标准，但我们希望未来每个 Python 包都能有可在 WebAssembly 下使用的 wheel。我们也在积极与主要包的维护者合作，推动他们提供 PyEmscripten 构建版本。如果你遇到还不支持的包，可以在 Discord 或 GitHub 上告诉我们，我们团队会着手把它构建出来。你也可以看看我们在 EuroPython 2026 的演讲《Python Everywhere: The State of Python on WebAssembly》，了解我们是如何做到的。
用 Python 构建 AI 智能体和流水线
庞大的数据科学和机器学习包生态，让 Python 成为构建智能体和 AI 流水线的天然选择。但要把这些搬到 Python Workers 上，过去一直有个难题：openai 和 langchain 这类库依赖 requests 或 httpx 这样的 HTTP 客户端来跟外部 API 通信。而 Python Workers 缺少对底层 socket 操作的支持，这些 HTTP 客户端就没法正常工作。
为了解决这个问题，我们向上游贡献了代码，让这些 HTTP 客户端在 WebAssembly 环境里可以把请求直接走 JavaScript 的 fetch API。再加上上一节介绍的对底层 socket 操作的新支持，整个网络栈就能在 Python Workers 里无缝运行了。
因此，你现在可以在 Python Workers 里原生运行 openai、langchain、mcp 等 AI 库。也可以把它们和 Workers AI 结合，在 Cloudflare 网络中的 GPU 上做无服务器推理，或者通过 Cloudflare AI Gateway 代理请求。下面的例子展示了如何用 langchain-cloudflare 包，在 langchain 里运行 Workers AI 模型：
现在就能构建什么
我们在 python-workers-examples 仓库里整理了一批可直接用于生产的模式。下面是一些把 Python Workers 与 Cloudflare 生态结合起来的用法。
异步 AI 编排
构建一个全栈 AI 应用，往往要连接存储、队列、推理等多个服务。这个例子展示了如何完全用 Python Workers 构建一个 AI 驱动的图生图生成器。它接收用户请求，放进 Cloudflare Queue，再用 Workflows 通过 Workers AI 编排图像生成步骤，最后把图片存进 R2 存储桶。
用 Bluesky Jetstream 做实时流处理
要消费海量的实时事件流，通常得专门配一台服务器来维持连接。在这个例子里，我们用 Python Worker 连接 ATProto/Bluesky Jetstream 的 WebSocket。再借助 Durable Object 为这条连接提供后端支撑，Python Worker 就能保存长生命周期的状态，让 WebSocket 连接始终保持在线。
更多示例
模型上下文协议（MCP）服务器
用官方 Python MCP 包构建并部署一个 MCP 服务器，让你的 AI 助手能够访问边缘数据。
基于 Vectorize 的检索增强生成（RAG）系统
用 Workers AI 和 Cloudflare 的向量数据库 Vectorize 搭建一套 RAG 系统。
Cloudflare 开发者文档中的 Python 代码示例
我们更新了 Cloudflare 各产品的文档，加入了 Python 示例代码。几乎每一处用 TypeScript 演示如何操作的代码示例旁边，现在都有对应的 Python 版本。我们会继续为所有产品补充 Python 示例。在开发者文档里，你可以随时在 JavaScript、TypeScript 和 Python 之间切换代码片段。
下一步
正式可用（GA）只是一个开始。我们有很多计划要让 Python Workers 变得更好，包括提升性能和内存效率，以及支持更多包。继续告诉我们你想用 Python Workers 构建什么，我们会不断拓展它能做到的事。
查看 Python Workers 文档，动手构建你的第一个 Python Worker吧！