Opera推出WebAI:浏览器本地AI开放给网站调用

Opera推出WebAI,把本地AI模型作为浏览器原生接口开放给网站直接调用。
Opera在Product Hunt发布WebAI,核心是把运行在用户设备上的本地AI模型开放给网页调用,取代过去依赖第三方扩展或云端API的做法。文章分析了这一方向的三重价值:数据不出设备带来的隐私优势、算力成本从网站转移到终端、以及开发者可绕过扩展层直接构建浏览器能力。同时也指出其局限:模型规模受用户硬件制约,产品仍处早期,接口稳定性、权限授权机制与跨浏览器兼容性均未验证。放在更大背景下,这反映浏览器厂商正争夺AI入口,分歧在于走自带助手路线还是把AI作为平台接口开放给网页。
Opera推出WebAI:浏览器本地AI开放给网站调用
在Product Hunt上,Opera发布了一款名为WebAI的浏览器能力,核心思路是把运行在用户电脑上的本地AI模型开放给网页调用。官方在Product Hunt的标语写得很直接:"Let websites use AI running on your computer"——让网站使用跑在你电脑上的AI。
这个产品目前在Product Hunt获得71个投票、2条评论,排名第18,归类在API、隐私、人工智能三个分类下。从这些数字看,它还不是现象级爆款,但它指向的方向值得关注:浏览器正在从"渲染网页的工具"变成"向网页提供算力的平台"。
产品定位:把本地AI做成浏览器原生能力
WebAI的官方描述是,你现在可以访问内置于浏览器的本地AI,用它来构建自己的浏览器能力,而不用依赖别人的扩展。这句话里有几个关键点。
第一,AI是"内置于浏览器"的,不是挂在云端的API。第二,它的使用对象是"网站"和"开发者",用于构建浏览器能力,而不是让用户去装一个第三方插件。第三,它明确把"依赖他人扩展"当作要替代的现状。
换句话说,Opera想做的不是再发一个AI助手,而是把AI变成浏览器的一个底层接口,让网页开发者可以像调用摄像头、麦克风、通知那样,调用本地模型。这更接近平台化的思路。
**浏览器原生能力(Web Platform API)**指的是浏览器直接提供给网页 JavaScript 调用的标准化接口,例如 getUserMedia 调用摄像头、Notification 发通知、Geolocation 读定位。这类接口的共同特征是:由浏览器内核实现,网页无需安装插件即可使用,并受统一的权限提示机制约束。把本地 AI 纳入这一体系,意味着模型推理不再是网页外挂的脚本或扩展,而是像摄像头一样成为浏览器暴露给网页的标准能力。这对生态的意义在于可发现性和一致性——开发者面对的是文档化的 API,而不是各浏览器私有的实验特性;对用户的意义则在于权限模型可以复用浏览器已有的授权弹窗与站点设置。
为什么本地化调用值得关注
把AI放在本地运行,最直接的好处是数据不离开设备。网页调用模型时,输入内容不需要上传到远端服务器推理,这对隐私敏感场景有实际意义。Opera在分类里也把Privacy和Artificial Intelligence并列,说明隐私是它想强调的卖点之一。
另一层价值是成本和可用性。推理跑在用户设备上,网站方不必为每次调用支付云端推理费用,也不会受制于第三方API的配额和限流。对开发者来说,这意味着一种新的成本结构:把算力负担转移给终端,换取更低的边际成本。
当然,本地推理的代价也很明确——模型规模受限于用户硬件,性能表现取决于设备。素材里没有披露WebAI具体调用的是哪个模型、能力边界如何,这部分信息还需要观望。
**端侧推理(On-device Inference)**与云端推理的核心差异在于计算发生的位置。云端推理把输入发送到服务器,由数据中心的大模型完成计算后返回结果,优点是模型可以很大、设备无要求,缺点是存在网络延迟、数据出设备、按调用量计费。端侧推理则把模型权重下载或内置到本地,利用用户设备的 CPU/GPU/NPU 计算。受限于消费级硬件的显存与算力,端侧通常只能跑参数量较小的模型(数亿到数十亿参数级别),并且首 token 延迟、吞吐量都与设备强相关。业界的常见做法是用量化压缩模型体积,并借助 WebGPU 等浏览器图形接口加速矩阵运算,这也是当前浏览器内运行本地模型的主要技术路径。
对开发者意味着什么
从"用别人的扩展"到"自己构建浏览器能力",这个转变降低了中间层依赖。过去想给网页加AI功能,常见做法是接入云端API,或者依赖浏览器扩展注入脚本。前者把数据送出设备,后者受扩展商店审核和权限模型约束。
如果浏览器原生提供AI调用入口,网页本身就能完成推理,扩展这一层可以被绕过。对独立开发者和小团队来说,这可能是一个门槛更低的实验路径。
需要注意的是,WebAI目前仍处在早期阶段。Product Hunt页面上的投票和评论数都不多,说明它尚未经过大规模开发者检验。接口稳定性、跨浏览器兼容性、以及网站调用本地模型时的权限与用户授权机制,都是落地过程中绕不开的问题。
浏览器扩展的权限模型是理解这一转变的关键背景。扩展通常需要向扩展商店提交审核,并在安装时申请主机权限(host permissions)与 API 权限,其脚本可以跨站点注入,因此权限范围较宽、审核周期较长。相比之下,网页原生调用 AI 接口时,能力边界由浏览器内核与站点权限共同界定,网页只能在其自身源(origin)内运行,天然受同源策略约束。这意味着原生接口在权限粒度上更细,但也要求浏览器设计出清晰的授权流程,让用户知道某个站点正在占用本地算力。跨浏览器兼容性同样是现实障碍:如果该能力没有进入 W3C 或 WHATWG 等标准组织的讨论,就可能只是 Opera 一家的私有实现,开发者接入时需评估迁移成本。
浏览器成为AI入口的竞争
Opera推出WebAI,放在更大的背景下看,是浏览器厂商争夺AI入口的一部分。浏览器掌握着用户上网的第一触点,谁能把AI能力嵌进这一层,谁就有机会定义网页与模型交互的方式。
这个方向上的分歧在于开放程度。一种路线是浏览器自带AI助手,用户直接使用;另一种是像WebAI这样,把AI能力作为接口开放给网页。后者更接近平台思维,但也带来新的治理问题:网站能调用多少本地算力、用户如何知情和授权、恶意页面能否滥用本地模型,这些都需要产品层面的答案。
Opera在描述中提到"start creating your own browser capabilities",用词是"开始",暗示这还是一个起点。对这个方向感兴趣的开发者,可以关注其后续的接口文档和权限模型设计——那才是决定它能否被真正用起来的关键。
总结
WebAI by Opera的价值不在于它现在有多少投票,而在于它提出了一个具体的问题:当浏览器自带本地AI,网页是否应该直接调用?它的答案是肯定的,并且把隐私和摆脱扩展依赖作为理由。这个方向是否成立,取决于后续开发者生态和权限设计,但浏览器作为AI分发入口的趋势,已经越来越清晰。
相关推荐

Cognition SWE-2 实战:一个提示词搞定产品发布全流程
解析 YouTube 创作者用 Cognition SWE-2 发布产品的完整提示词:落地页、七封邮件序列与未购买用户跟进工具三段式结构,以及"测试并汇报"这一约束如何改变 AI 的交付质量。
AWS AgentCore Gateway:用MCP打通AI Agent与企…
AWS AgentCore Gateway:用MCP打通AI Agent与企业后端
AWS AgentCore Gateway如何作为主MCP服务器聚合REST API、Lambda与已有MCP服务?解析其AST实时映射、零冷启动、语义搜索治工具过载、会话隔离与密钥注入安全设计,以及企业AI Agent解耦后端的架构思路。

一个链接给Figma AI装上新技能:MCP连接器实战
通过粘贴一个MCP服务器链接,Figma中的AI Agent就能获得新工具能力。本文拆解配置流程、超过20个一键接入应用、读写权限与执行策略设置,以及公开HTTPS链接这一关键限制。