随着大语言模型在消费设备上的普及，浏览器正在从单纯的页面渲染引擎向智能交互平台转型。Chrome Prompt API 作为这一转型的核心接口，自提出以来便引发了激烈的技术争议。本文从技术设计细节出发，结合 Mozilla 的公开反对意见，剖析该 API 对 Web 安全生态的深层影响。
技术架构：浏览器内置大模型的能力边界
Chrome Prompt API 的定位是为 Web 开发者提供一个统一的 JavaScript 接口，以访问浏览器或操作系统提供的大语言模型。根据 Web Machine Learning 社区组的官方解释文档，该 API 的核心目标是让网站能够直接调用设备端的本地模型，从而实现敏感数据的本地处理、降低服务器交互延迟、支持离线使用场景，以及为开发者降低 AI 功能的接入门槛。
从技术实现角度看，Chrome 的内置 AI 采用分层架构设计。Prompt API 作为面向开发者的应用层接口，位于架构顶端；其底层则依赖 WebGPU 作为计算基座。WebGPU 是 W3C 标准化的低层 GPU 计算接口，Chrome 通过 Chromium 的 Dawn 栈将 API 调用从渲染进程路由至 GPU 进程，并处理着色器编译与命令序列化。这种设计使得浏览器能够在本地高效运行模型推理，而无需依赖云端 API。
值得注意的是，Prompt API 的设计明确了一个关键原则：API 本身不强制要求所有浏览器都必须携带或暴露大模型。文档中指出，设备存储或算力不足的情况下，实现者完全可以始终返回 “模型不可用” 的状态。这意味着该 API 更像是为具备本地 AI 能力的设备提供标准化访问层，而非强制性的浏览器功能。
在功能层面，Prompt API 提供了丰富的交互模式。开发者可以通过 LanguageModel.create() 创建会话，使用 session.prompt() 或 session.promptStreaming() 进行同步或流式推理。API 支持系统提示词、多轮对话上下文管理、工具调用（Tool Use）能力，以及图像和音频等多模态输入。值得注意的是，系统提示词在上下文窗口溢出时会被保留，这一点对构建长对话应用至关重要。
Mozilla 的核心反对理由：隐私与竞争的双重担忧
Mozilla 对 Chrome Prompt API 的反对立场，并非简单的功能争议，而是基于对 Web 生态长远发展的深刻担忧。在 2025 年中旬的公开表态中，Mozilla 明确指出了三个层面的风险。
首先是隐私层面的隐忧。当 Chrome 将基于 Gemini 的 AI 能力深度整合到浏览器中时，用户和开发者的交互数据将不可避免地与特定浏览器实现产生绑定关系。尽管 Prompt API 承诺本地处理敏感数据，但 Mozilla 担心的是：一旦 Web 开发者习惯于调用 Chrome 内置模型，他们可能会不自觉地依赖 Google 的模型行为特征，从而削弱用户在浏览器选择上的实质自由。更关键的是，如果 Google 通过浏览器层面收集模型使用数据，这将形成新的隐私边界模糊地带。
其次是竞争层面的威胁。Mozilla 认为，将大模型能力直接嵌入浏览器，会显著扩大 Google 在 Web 行为层面的控制范围。由于不同浏览器可能使用不同的大模型实现，开发者将面临浏览器行为差异加剧的困境。Chrome 可能凭借其内置模型的先发优势，形成事实上的标准压力，迫使整个行业向 Google 的实现方案靠拢。这种 “平台锁定” 效应在移动操作系统领域已有前车之鉴，Mozilla 不希望在 AI 时代重蹈覆辙。
第三是标准中立的潜在丧失。Mozilla 在反馈意见中强调，Web 标准的价值在于其跨浏览器兼容性。当浏览器开始提供差异化的 AI 能力时，Web 开发者可能被迫在 “功能完整性与跨浏览器一致性” 之间做出取舍。如果 Chrome 的 Prompt API 成为事实标准，而其他浏览器因算力或商业原因无法提供对等实现，整个 Web 生态的开放性将受到侵蚀。
对 Web 安全生态的工程影响
从工程实践角度看，Chrome Prompt API 的普及将带来一系列需要重新审视的安全考量。
在数据安全维度，Prompt API 提供了本地处理敏感数据的能力，理论上可以避免将用户输入发送至第三方服务器。然而，这层 “本地处理” 的安全边界需要严格界定。当开发者调用 session.prompt() 时，输入内容是否会被 Google 后端用于模型改进？API 的隐私政策并未明确排除这种可能性，而 Mozilla 的担忧恰恰源于此。
在权限模型维度，Prompt API 通过 Permissions Policy 进行访问控制。默认情况下，只有顶层窗口及其同源 iframe 可以访问该 API。跨域 iframe 需要显式声明 allow="language-model" 属性。这一设计符合 Web 平台的安全基本原则，但问题在于：当 AI 能力成为浏览器原生功能后，恶意网站通过诱导用户授权来调用本地模型进行数据提取的威胁模型将更加复杂。
在供应链安全维度，Prompt API 的工具调用（Tool Use）机制允许语言模型触发外部 JavaScript 函数执行。这一能力如果被滥用，可能成为新型攻击向量。攻击者可能通过精心构造的提示词，诱导模型调用开发者定义的 execute 函数，从而实现对 Web 应用内部逻辑的间接操纵。虽然 API 设计中要求开发者显式定义工具和执行函数，但这种 “模型驱动的代码执行” 范式本身就带来了新的攻击面。
工程实践建议
面对上述风险，从事 Web 开发的团队在接入 Prompt API 时应建立系统性的安全评估流程。首先，应在产品层面明确标注 AI 功能的可用状态，并通过 LanguageModel.availability() 方法在调用前检查设备能力，避免在不支持该 API 的环境中出现功能降级。其次，对于涉及敏感数据的场景，应在服务端实现补充的安全验证机制，不能仅依赖本地模型的 “隐私承诺”。第三，工具调用功能应遵循最小权限原则，仅暴露必要的函数，并对模型返回的参数进行严格的输入校验。
资料来源
本文技术细节主要参考 Web Machine Learning 社区组的官方解释文档，该文档详细描述了 Prompt API 的设计目标、非目标及实现细节。Mozilla 的反对意见来源于其公开的 standards-positions 反馈及 2025 年中旬的媒体声明。
延伸阅读：Chrome Platform Status 上有该特性的最新实现状态更新，WebGPU 技术报告则详细解释了底层计算架构的设计考量。