AI 摘要： 本文由 Chrome 团队成员撰写，详细阐述了新一代内置 AI Web APIs（如 Prompt API、Summarizer、Translator 等）的设计思路与挑战。文章探讨了如何在快速演进的 AI 技术环境中，平衡 API 一致性（interoperability） 与 未来兼容性（futureproofing） 的需求，并分析了客户端优先的设计与传统 HTTP API 的差异，最终提出了一种具备状态管理、可扩展性和跨浏览器统一性的架构思路。

1. API 设计背景与挑战
• Chrome 推出一系列内置 AI APIs，目标是成为 Web 平台的标准库，被各大浏览器采纳。
• 与传统 Web API（如 USB、Payment、Codecs）不同，AI APIs 缺乏长期先例，且领域演进极快。
• 特别关注 Prompt API 的复杂性与标准化问题。

2. Prompt API 的设计核心
• 借鉴已有生态，采用对话消息数组模型（user、assistant、system 三种角色）。
• 主要挑战包括：
• 多模态输入输出（text、image、audio 等）。
• 约束条件（是否允许多条 system 消息、重复 assistant 消息等）。
• 语义一致性（拼接消息 vs 多条分离消息）。
• 简写形式（role 省略、直接输入字符串等）。
• Chrome 方案：统一为 {role, content: Array<{type, value}>, prefix?} 的标准格式，并增加约束规范。

3. 客户端优先 vs 服务端 API
• 传统 HTTP API 往往 stateless，依赖 JSON 与 HTTP 调用；而 Web API 则以 JavaScript 调用、支持 on-device 模型为核心。
• 优势：
• 使用原生对象类型（如 ImageBitmap、AudioBuffer），规避 base64 冗余。
• 工具调用通过 async Promise 方式隐藏复杂度。
• 设计为 有状态 API：
• LanguageModelSession 管理会话，支持 append()、clone()、destroy() 和 AbortSignal。
• 改善资源管理与性能，但需处理 context window 溢出机制。

4. 互操作性 (Interoperability) 与未来兼容性 (Futureproofing)
• 挑战：不同浏览器可能使用不同模型，API 需保证代码不因模型差异而崩溃。
• 解决策略：
• 引导开发者使用 结构化输出（JSON Schema、RegExp 约束）。
• 每个任务型 API 设计独立入口，允许底层模型自由组合（如 LoRA 扩展、语言包下载）。
• API availability() 与 create() 方法帮助开发者预判功能是否可用，降低模型差异带来的不确定性。
• Translator API 示例：对开发者暴露 {sourceLanguage, targetLanguage}，内部可实现 pivot language 策略（实际通过英文中转），保证未来兼容。

5. 仍在探索的前沿问题
• Sampling 参数扩展：Top-K、temperature、Top-P、repetition penalty 的标准化。
• 设备约束：隐私/性能可能要求 on-device 模型或 GPU 模型，如何给予开发者适度控制。
• Prompt injection 安全性：如避免任务 API 被恶意文本指令干扰。

6. 总结与展望
• 内置 AI APIs 是 Web 平台延续生态开放战略的一环，类似暴露硬件/系统能力。
• AI 发展过快，Web 可能被迫扮演“慢速跟随者”，标准化存在滞后。
• 核心疑问：Web 能否跟上前沿 AI 的实时交互与推理进展，还是只能在多年后提供简化、抽象的最低共同标准？