在浏览器原生能力与人工智能深度融合的浪潮中，Chrome 正在重新定义扩展程序的开发范式。2025 年以来，Google 将 Gemini Nano 直接嵌入 Chrome 运行时，并通过 Prompt API 向第三方扩展开放了浏览器内置的小语言模型调用能力。这一机制使得开发者无需依赖外部 API 密钥，即可在用户的浏览器环境中完成自然语言理解、内容提取、结构化转换等任务。从工程视角看，这条从提示词到可安装扩展的管线涉及权限配置、Manifest V3 规范遵循、以及运行时模型调用的精妙设计，理解这些细节是构建下一代 AI 驱动扩展的前提。
Prompt API 的核心技术架构
Chrome 的 Prompt API 并不是一个全新的外部服务，而是一个将 Google 自研的 Gemini Nano 模型运行于浏览器进程内的接口层。该 API 通过 chrome.aiOriginTrial.languageModel 命名空间暴露给扩展开发者，这意味着只有在加入特定 origin trial 并获得有效 token 后，API 才会在用户的 Chrome 实例中激活。从架构位置来看，模型本身运行在 Chrome 的渲染进程中，借助 WebAssembly 加速推断，延迟可以控制在本地调用的毫秒级别，远低于依赖远程 API 的往返延迟。这种本地化部署策略不仅提升了响应速度，还显著降低了敏感数据离开用户设备的风险，对于需要处理页面内容的隐私敏感型应用尤为重要。
要使扩展能够调用 Prompt API，开发者必须在 manifest.json 中声明 aiLanguageModelOriginTrial 权限，同时在使用 API 前检查其可用性。由于该 API 仍处于实验阶段，Chrome 不会在所有安装版本中默认启用，开发者需要通过 origin trial 机制获取 token 并在服务器端正确配置响应头，才能够在受信任的范围内激活功能。这一设计虽然增加了入门门槛，但也确保了只有在明确授权的环境中才会运行大模型推理，符合 Chrome 一贯的安全优先原则。
从提示词到扩展的工程实现路径
将自然语言需求转化为可安装的扩展程序，核心在于遵循 Manifest V3 的权限最小化原则，同时正确配置 Prompt API 的调用上下文。一个典型的开发流程始于需求描述：开发者先以自然语言形式表述扩展的功能目标，例如 “提取当前页面中所有日期和邮箱地址并允许一键复制”。随后，这一描述被转化为针对 Gemini Nano 的结构化提示词，包含输入格式说明、期望输出格式、以及错误处理策略。Chrome 的 Prompt API 支持在提示词中嵌入上下文示例，这种 few-shot 能力使得模型能够准确理解特定领域的输出格式要求，减少后处理解析的复杂度。
在代码实现层面，扩展的 popup 或 background service worker 会调用 window.ai.languageModel.create() 创建一个模型会话实例，随后通过 session.prompt() 方法向模型发送包含任务指令和页面内容的组合提示。API 的返回结果为纯文本，开发者需要根据预设的解析规则将其转换为结构化数据，如 JSON 数组或 CSV 格式。值得注意的是，Prompt API 对单次提示的 token 数量有限制，超长页面内容需要先进行摘要或分块处理，这一约束直接影响扩展设计时的数据流规划。
权限配置是整个管线中的关键环节。根据 Chrome 的安全规范，扩展不应请求超过功能所需的最小权限集。对于使用 Prompt API 的扩展，通常只需要 activeTab 权限即可访问当前标签页的 DOM 内容，结合 scripting 权限执行内容脚本完成数据提取。这种权限组合既满足了功能需求，又避免了请求 host_permissions 带来的过度授权问题，有助于通过 Chrome Web Store 的审核流程。
实际应用场景与可落地的参数配置
基于 Prompt API 的扩展在内容处理类场景中具有显著优势。第一个典型场景是信息抽取：用户浏览一篇长文章或产品页面时，扩展可以调用模型从页面文本中提取关键实体，如事件时间、地点、人物关系，并将其格式化为结构化摘要。实现时，建议将页面文本的前 2000 个字符作为输入上下文，超出部分通过截断或摘要方式处理，以避免超过模型的上下文窗口限制。第二个场景是内容过滤与改写：扩展可以检测页面中的敏感词汇或不当表述，并基于提示词生成合规的替代表达，这种能力在企业内网的合规审查工具中具有实用价值。第三个场景是跨页面任务编排：结合 Chrome 的 side panel API，扩展可以在用户浏览多个页面时维护上下文记忆，逐步收集信息并生成聚合报告。
在实际部署时，以下参数配置值得开发者关注。首先是模型会话的创建选项：maxTokens 参数控制单次输出的最大 token 数，默认为 1024，对于简单的结构化提取任务可以适当降低以减少延迟；temperature 参数控制输出的随机性，取值范围为 0 到 1，建议在 0.3 到 0.5 之间以平衡准确性与多样性。其次是错误处理策略：由于模型运行在本地，失败场景包括模型未初始化、输入超长、以及设备资源不足，此时扩展应提供清晰的降级方案，如回退到正则表达式匹配或提示用户手动操作。最后是性能监控：通过 Chrome 的 chrome.metricsPrivate API 可以记录 API 调用的延迟分布和成功率，这两项指标对于评估扩展在真实用户环境中的表现至关重要。
与云端 AI 管道的对比与协同
理解 Chrome Prompt API 的定位，需要将其与 Vercel 推出的 open-agents 等云端 AI 管道进行对比。open-agents 展示了一条从自然语言描述到完整代码生成的端到端路径：用户在 Web 界面输入任务描述，agent 在云端的沙箱环境中执行文件编辑、代码搜索、仓库操作，最终产出可部署的代码变更。这种模式的强项在于模型可以调用完整的开发工具链，包括编译器、测试框架和版本控制系统，适合复杂的软件工程任务。然而，代价是延迟较高且涉及代码离开本地环境的安全顾虑。
Chrome Prompt API 则走了一条相反的路径：模型运行在用户本地，不需要网络往返，天然支持离线场景和隐私敏感的数据处理。但其局限也很明显 ——Gemini Nano 作为轻量级模型，在复杂推理和多步骤任务规划上的能力弱于云端大模型。因此，一个合理的架构设计是将两者结合：在浏览器端使用 Prompt API 完成即时内容提取和轻量级转换，将需要深度推理的任务通过安全的 API 网关委托给云端 agent 处理。这种混合模式既能保证用户体验的流畅性，又能处理超出本地模型能力范围的复杂需求。
开发者入门的检查清单
对于希望快速上手 Prompt API 扩展开发的团队，以下检查清单可以显著降低前期探索成本。第一步是环境准备：确保安装了 Chrome 128 及以上版本，并前往 Chrome 开发者预览频道获取支持 Prompt API 的版本；同时需要在 Chrome Origin Trials 门户注册扩展的域名以获取 trial token。第二步是 Manifest 配置：在 manifest.json 的 permissions 数组中添加 aiLanguageModelOriginTrial，并在 minimum_chrome_version 中指定最低版本要求。第三步是可用性检测：在扩展代码中使用 if (window.ai && window.ai.languageModel) 进行能力检测，避免在不支持的环境中崩溃。第四步是功能验证：使用简单的提示词（如 “列出这段文本中的所有日期”）测试模型响应，确认输出格式符合预期后再扩展至复杂场景。
从更长远的视角看，Chrome Prompt API 代表了一种以浏览器为平台的边缘 AI 推理趋势。随着设备端芯片性能的持续提升和模型压缩技术的成熟，越来越多的 AI 能力将下沉到用户终端。掌握这一管线工程细节的开发者，将在下一代 Web 应用的构建中占据先机。
资料来源：Chrome 官方文档中关于 Prompt API 的技术说明，以及 Chromium 开源项目中 Prompt API for Extension 的实验文档。