两年前,我们推出了 Python Workers,让开发者能在 Cloudflare Workers 运行时中运行 Python 应用,目标是让用 Python 编写 Workers 像用 TypeScript 一样简单,并让 Python 包和框架生态开箱即用。今天,Python Workers 正式可用(GA)。GA 意味着 Python 成为 Cloudflare 开发者平台上的一等公民、受完整支持的语言。你可以把已有的 Python 代码、库和设计模式接入 Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflows 以及 Cloudflare 平台的其他服务,也能在 Python Workers 中运行 FastAPI、Django、Flask 等流行框架,甚至用 Dynamic Workers 在一个 Worker 里创建 Python Worker。
正文
Python Workers 两年前推出,让 Python 应用能在 Cloudflare Workers runtime 中运行。目标是让用 Python 写 Workers 像 TypeScript 一样简单,并让 Python 包和框架生态“直接可用”。现在 Python Workers 正式 GA。
GA 意味着 Python 成为 Cloudflare 开发者平台上的一等、完全支持的语言。已有的 Python 代码、库和设计模式可以无缝连接 Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflows 以及平台其余部分,也能在 Python Workers 中运行 FastAPI、Django、Flask 等流行框架。甚至可以用 Dynamic Workers 在另一个 Worker 里创建 Python Worker。第一个示例展示了一个 FastAPI 应用:它从 request.scope 取 env,调用 env.AI.run("@cf/openai/gpt-oss-120b", ...),再通过 asgi.entrypoint 暴露为 Worker 入口。
Python Workers 背后的历程
把 Python 带到 Cloudflare Workers 是自然选择。Workers 从 2018 年起支持 WebAssembly,为运行 Wasm 编译的 Python 解释器提供了环境。借助 Pyodide,可以快速在 Workers 中支持大量 Python 应用。目标是打造首个可无限扩展的 Python 应用平台,同时让开发体验和性能不逊于在其他地方开发 Python。今天强调的功能来自多年努力;许多开发者已在 Python Workers 上构建应用,现在这些能力面向所有人生产可用。
Python 成为 Cloudflare Workers runtime 的一等语言
Python Workers 现在原生支持 Cloudflare 开发者平台绑定。以前,在 Python Workers 中使用这些绑定,需要在 RPC 边界显式把 Python 对象转换为 TypeScript 对象。比如向 Queue 发送 Python 字典,需要引入 pyodide.ffi.to_js 和 js 模块做胶水转换。这要求 Python 开发者写代码时还得想着 JavaScript 环境,也是人类和 AI agent 常见的错误来源。现在类型转换过程封装在 Workers runtime 和 Python SDK 中,所有 Cloudflare 绑定都能用 Pythonic 方式使用,无需写一行 JavaScript。直接 self.env.QUEUE.send({"key": "value"}) 即可工作。
Web 框架:FastAPI、Django 和 Flask
现在可以用 FastAPI、Django、Flask 等框架在 Python Workers 中构建 API 服务器。内置连接器可把 Web 应用接到 Python Workers。一个简单 FastAPI 应用在原生环境通常用 uvicorn 运行;在 Python Workers 中,使用 workers.asgi 包,添加 asgi.entrypoint(app) 就能运行。同步 Web 应用如 Django 可以用 workers.wsgi 包,通过 wsgi.entrypoint(app) 运行。
底层发生了什么?
Python 有标准契约规定 Web 应用如何与 Web 服务器通信:WSGI 及其现代异步版本 ASGI。这个标准让应用与服务器无关。传统部署中,Uvicorn、Gunicorn 等 Web 服务器负责并发连接和线程以扩展流量,FastAPI 等框架只关注应用逻辑。在 Cloudflare Workers 中,Workers 平台本身就是 Web 服务器。全球网络已经处理负载均衡和无限扩展,不需要在 Python Workers 里再跑一个服务器。workers.asgi 和 workers.wsgi 连接器是轻量、优化的桥:把传入的原生 JavaScript 请求翻译成 Python 应用期望的标准 WSGI/ASGI 结构,再以极低开销把响应传回去。这样开发者可以用喜欢的框架写和组织代码,同时让平台在全球即时扩展 API,无需配置服务器。这些连接器适用于任何使用 WSGI 或 ASGI 接口的 Python Web 框架,不只是 FastAPI、Django、Flask。文档中有各框架的更多信息。
使用 PostgreSQL 和 MySQL 与 Hyperdrive
如果用 PostgreSQL、MySQL 等关系数据库构建 Python 应用,现在可以把 Hyperdrive 集成进 Python Workers。以前 Python Workers 不支持 TCP socket,数据库驱动无法使用。原因在于 WebAssembly 的运行方式:aiomysql、asyncpg 等驱动依赖标准库 socket 模块建立连接,标准环境中它做 POSIX 系统调用,而在 Wasm 沙箱中这些网络系统调用通常是总是失败的桩。Cloudflare 使用 Workers 的 connect API 实现了 socket 系统调用。驱动尝试打开 TCP 连接时,会经过自定义 socket 系统调用实现,把打开连接、读取字节等 Python socket 操作翻译成 Workers runtime 使用的 JavaScript 调用。翻译发生在系统调用层,驱动不需要知道底层实现。正是这个 socket 桥让 Hyperdrive 集成成为可能。使用 Hyperdrive 时,先在 Wrangler 配置中设置绑定,比如 HYPERDRIVE_MYSQL,然后用熟悉的驱动连接,例如 aiomysql 连接后执行 SELECT username FROM user。支持的包见 Hyperdrive Python Workers 文档。
扩展 WebAssembly 包生态
Python Workers 运行在 WebAssembly 沙箱中,带原生 C/C++/Rust 扩展的包必须交叉编译到 WebAssembly。以前没有标准方式把任意 Python 包交叉编译到 WebAssembly,团队只能手动编译和托管自定义 Wasm 包,极大限制了可用包数量。希望用户能用更多包,但不想只构建仅 Python Workers 可用的包,那样对社区无益。Python Workers 基于 Pyodide,所以希望生态朝有利于 Pyodide 和整个 Python-on-WebAssembly 社区的方向发展。因此提出了 PEP 783,标准化一个在浏览器运行时中运行 Python 的平台,称为 PyEmscripten。经过一年多的讨论和完善,提案被接受,包维护者可以为 PyEmscripten 平台构建和发布包,并在所有实现该平台的环境中可用。还稳定了现有 Pyodide 构建工具链,使其对所有包维护者可用,并为 cibuildwheel 添加 PyEmscripten 平台支持,方便他人采用。生态仍在采用这个标准,希望未来每个 Python 包都有能在 WebAssembly 中工作的 wheel。正在与主要包维护者合作加入 PyEmscripten 构建。遇到不支持的包,可在 Discord 或 GitHub 反馈,团队会推动构建。EuroPython 2026 演讲“Python Everywhere: The State of Python on WebAssembly”有更多内容。
用 Python 构建 AI agent 和 pipeline
数据科学和机器学习包生态让 Python 成为构建智能 agent 和 AI pipeline 的自然选择。但把这些带到 Python Workers 过去有挑战:openai、langchain 等库依赖 requests 或 httpx 这样的 HTTP 客户端与外部 API 通信,而 Python Workers 缺少底层 socket 操作支持,这些 HTTP 客户端无法正常工作。Cloudflare 向上游贡献,让这些 HTTP 客户端在 WebAssembly 环境中直接通过 JavaScript fetch API 路由请求。结合新的底层 socket 支持,整个网络栈在 Python Workers 中无缝工作。现在可以原生运行 openai、langchain、mcp 等 AI 库,也可以结合 Workers AI 在 Cloudflare 网络的 GPU 上做无服务器推理,或通过 Cloudflare AI Gateway 代理请求。示例使用 langchain-cloudflare 包在 langchain 中运行 Workers AI 模型:ChatCloudflareWorkersAI 指定 @cf/meta/llama-3.3-70b-instruct-fp8-fast,绑定 env.AI,用 PromptTemplate 和 StrOutputParser 组成链并异步调用。
今天可以构建什么
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 连接保持存活。

更多示例
Model Context Protocol (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 性能更好、内存更高效,并支持更多包。继续告诉 Cloudflare 你想用 Python Workers 构建什么,团队会继续突破可能边界。查看 Python Workers 文档,开始构建第一个 Python Worker。
评论
社区对 Cloudflare 正式支持 Python Workers 整体正面,但技术讨论聚焦于冷启动架构隐患与上游库维护责任错配,同时不少人畅想更多语言支持。
质疑冷启动性能与架构绑定
- 有人提问 WebAssembly 冷启动慢的固有劣势是否解决,另有竞品开发者基于此前基准测试指出,当前架构绑定 JS/V8 导致冷启动难低于 100 毫秒,此前测得约 600 毫秒,而本次发布未公布更新指标,呼吁公开(较多人)。 > 架构上绑定 JS/V8 世界,要想把冷启动压到 100 毫秒以内相当困难,且此次发布未包含更新的冷启动数据(@syrusakbary)
指出上游库维护成本与资金支持错配
- urllib3 维护者说明,外部贡献者受资助实现了 Pyodide 支持并合入上游,但维护实验性后端的重任落在维护者身上,且浏览器 fetch 语义差异带来安全隐患,资助代码贡献不等于资助后续维护(高赞)。 > 资助给上游项目的代码贡献和资助之后不得不支持它的上游维护者,是两码事(@illia-v)
期待扩展语言支持与回馈开源
- 多名用户希望未来能同样简便地支持 Go、Mojo 甚至 Elixir 等语言,也有人称 Pyodide 是 Python 生态瑰宝,呼吁 Cloudflare 对上游开源项目提供资金赞助(较多人)。 > Pyodide 是 Python 生态里很酷的组件,希望 Cloudflare 能考虑捐些钱(@simonw)
有价值的补充
- urllib3 的 Emscripten 后端目前仍标记为实验性且明确不在安全策略范围内,曾因请求经 fetch 路由导致重定向控制行为不符预期而爆出漏洞。
- 此前公开基准测试中,最小 Python 应用在 Wasmer Edge 冷启动约 60 毫秒,而在 Cloudflare Workers 上约 600 毫秒,差距显著。
- 有用户将新闻标题误解为“用 AI 替换了 Python 程序员并让他们自由可用”,折射出社区对 AI 替代开发者的调侃情绪。