Cloudflare让Python真正跑进边缘云：AI应用开发开始换一种方式

Python不再只是“能跑”，而是开始原生融入WorkersFastAPI、Django、Flask也能直接跑Python终于可以连接MySQL和PostgreSQL更大的变化，发生在AI应用上MCP、RAG，也开始成为Python Workers的标准玩法WebAssembly正在成为关键基础设施Cloudflare真正想做的，是“全球服务器”Python Workers只是开始

作者：牛云 「科技先生」旗下「云边网」

Python，正在真正进入边缘计算的主舞台。

9月21日，Cloudflare宣布，Python Workers正式结束测试阶段，进入正式可用（GA）阶段。

这意味着，Python不再只是Cloudflare Workers上的一个实验性运行环境，而是成为Cloudflare开发者平台的一等语言。开发者可以直接使用熟悉的Python代码、第三方库和开发框架，并将它们连接到Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflows等Cloudflare服务。

更重要的是，这套体系已经开始向AI应用开发延伸。

FastAPI、Django、Flask可以直接运行，OpenAI、LangChain、MCP等AI开发库也可以使用。对于开发者而言，这实际上意味着：过去需要服务器、数据库、消息队列和AI服务拼起来的一套Python应用，现在可以被压缩到Cloudflare的边缘云平台中。

Cloudflare两年前首次推出Python Workers。

当时的核心思路很简单：让Python应用能够运行在Workers这个基于隔离运行时的无服务器平台上。

但真正的问题并不是“Python能不能运行”，而是Python能不能像在传统服务器上一样工作

早期Python Workers依赖Pyodide，将Python解释器编译为WebAssembly后运行。由于WebAssembly运行环境与传统Linux服务器存在明显差异，Python开发者使用Cloudflare服务时，还需要在Python和JavaScript之间进行数据类型转换。

例如向Cloudflare Queue发送一个Python字典，就需要额外通过Pyodide完成Python对象到JavaScript对象的转换。

现在，这些底层细节被Cloudflare封装进运行时和Python SDK。

开发者可以直接使用Python方式调用Cloudflare的服务，不再需要自己写JavaScript“胶水代码”。

这看似只是开发体验上的变化，实际上意味着一个重要转折：

Cloudflare正在试图让Python成为Workers原生开发语言，而不是“JavaScript平台上额外支持的Python”。

另一个明显变化，是Python生态中最重要的Web框架开始进入Workers。

Cloudflare现在提供了针对WSGI和ASGI的连接器，因此FastAPI、Django、Flask以及其他兼容WSGI/ASGI标准的Python Web框架，都可以部署到Python Workers。

传统架构中，一套FastAPI应用通常需要配合Uvicorn、Gunicorn等Web服务器，再通过云服务器、容器或者Kubernetes完成部署和扩容。

到了Workers环境，开发者可以继续使用熟悉的FastAPI代码，而请求接入、负载均衡和扩容则交给Cloudflare的全球网络完成。

换句话说：

开发者负责写应用，Cloudflare负责“服务器”。

这也是Serverless架构发展到今天，一个越来越明显的趋势——开发者不再需要围绕服务器本身设计应用，而是围绕运行时和服务能力设计应用。

Cloudflare称，其Workers全球网络可以处理负载均衡和自动扩展，因此Python应用不需要自己维护传统意义上的Web服务器。

如果只是支持Web框架，还不足以改变Python开发者的使用方式。

真正关键的是数据库。

过去Python Workers面临的一个技术障碍，是WebAssembly环境缺少传统意义上的TCP Socket支持。

而大量Python数据库驱动，例如、，都依赖标准Socket机制。

aiomysql

asyncpg

Cloudflare这次解决了这一层问题。

通过Workers的连接能力，Cloudflare为Python Workers补上了底层Socket支持，并进一步打通Hyperdrive。

于是，开发者可以继续使用熟悉的Python数据库驱动，通过Hyperdrive连接MySQL和PostgreSQL等数据库。

这意味着一个完整的后端应用开始具备了基本条件：

Python + Web框架 + 数据库 + 全球部署。

而且开发者无需为了部署到边缘环境重新学习一套完全不同的开发模式。

如果说传统Web应用是Python Workers的基础，那么AI应用才是Cloudflare重点押注的方向。

Python本身就是AI开发生态最重要的语言之一。

OpenAI SDK、LangChain、MCP等工具链，大量AI Agent和RAG项目都建立在Python之上。

Cloudflare过去的一个问题在于，部分Python网络库依赖传统Socket，而Workers的WebAssembly运行环境并不完全兼容这些机制。

Cloudflare此次针对HTTP客户端和底层网络能力进行了适配，使、、等库可以直接在Python Workers中运行。

openai

langchain

mcp

于是，一条新的组合开始出现：

Python + LangChain + MCP + Workers AI + R2/D1/Queues/Workflows。

这已经不是简单的“把Python部署到云上”。

它更接近一个面向AI Agent的完整运行环境。

例如，开发者可以让Python Worker接收用户请求，再调用LangChain组织Agent流程，通过Workers AI执行模型推理，把任务放入Queue，通过Workflows进行多步骤编排，最后将生成的内容存储到R2。

整个过程可以在Cloudflare的平台体系内完成。

Cloudflare此次还特别展示了几个应用场景。

其中包括基于Python构建MCP Server，让AI助手能够访问边缘侧的数据；使用Workers AI和Vectorize搭建RAG系统；以及利用Queue、Workflows和R2搭建AI图像生成流程。

这背后其实对应了AI应用正在发生的一次架构变化。

早期AI应用更多是：

前端 → 后端 → 大模型API。

而现在越来越多的应用变成：

用户 → Agent → MCP → 工具 → 数据库 → 工作流 → 模型 → 存储。

系统开始变得高度分布式。

这也是Cloudflare这类边缘云平台真正的机会所在。

它不只是提供CDN或者传统云服务器，而是在试图把计算、存储、数据库、AI推理、消息队列、工作流和Agent运行环境全部放进同一个开发平台。

Python Workers背后的另一个值得关注的变化，是WebAssembly。

Cloudflare最初能够把Python带到Workers，很大程度上得益于Workers对WebAssembly的支持。

但Python生态存在一个现实问题：

很多Python库并不是纯Python实现，而是依赖C、C++或者Rust扩展。

这些组件无法简单地直接放进WebAssembly环境。

因此，Cloudflare正在推动Pyodide以及更广泛的Python-on-WebAssembly生态发展。

Cloudflare参与推动的PEP 783，提出了PyEmscripten平台标准，为Python软件包在浏览器和其他WebAssembly环境中的构建提供更加统一的方式。

同时，Cloudflare还在推动PyEmscripten支持进入cibuildwheel等Python生态工具。

这件事情的意义可能比Python Workers本身更大。

因为如果越来越多Python软件包能够直接获得WebAssembly版本，那么未来Python就不只是“运行在服务器上的语言”，而可能真正成为一种跨服务器、浏览器、边缘节点和AI运行环境的通用开发语言

Cloudflare这次发布的重点表面上是Python，背后实际上是Cloudflare Workers战略的进一步延伸。

此前Cloudflare已经在Workers上不断增加数据库、对象存储、AI、工作流、队列等能力。

2025年，Cloudflare曾进一步完善Python Workers的包支持、冷启动和工作流；如今Python Workers正式进入GA，则意味着这条技术路线开始走向生产环境。

uv

这套模式与传统云计算存在明显区别。

传统云平台通常是：

租服务器 → 部署应用 → 配置网络 → 扩容 → 管理数据库。

Cloudflare希望提供的则是：

写代码 → 部署 → 全球运行。

服务器本身被进一步隐藏。

而AI时代恰恰放大了这种需求。

一个AI Agent可能需要模型调用、数据库查询、向量搜索、文件存储、异步任务、工作流和外部API。如果开发者每增加一种能力，就需要再购买一个服务、配置一台服务器，那么整个系统很快会变得复杂。

因此，Cloudflare正在做的事情可以理解为：

把越来越多的AI应用基础设施塞进Workers。

Cloudflare自己也明确表示，Python Workers进入GA并不是终点。

下一阶段，公司还计划继续提升Python Workers的性能和内存效率，同时扩大可用Python软件包范围。

这也意味着，Python Workers目前依然不是传统Python服务器的简单替代品。

尤其是那些高度依赖本地系统能力、原生扩展或者特殊运行环境的Python应用，仍然需要考虑WebAssembly兼容性。

但对于API服务、AI Agent、MCP Server、RAG、数据处理以及事件驱动型应用而言，边缘云正在提供一种越来越成熟的选择。

从这个角度看，Cloudflare这次的真正新闻并不是“Python终于可以跑在Cloudflare上”。

而是：

Python正在从传统服务器时代，进入一个由WebAssembly、Serverless和AI共同定义的新运行环境。

而Cloudflare显然希望成为这个新环境的重要基础设施提供者。