所以我看到 Hacker News 上 The Prompt API 这条讨论冲到两百多分时，第一反应不是“浏览器终于也有 AI 了”，而是：这东西如果真能稳定落地，会改变一类低风险 AI 功能的默认架构。

Chrome 的官方文档把 Prompt API 描述得很直接：网页或 Chrome Extension 可以把自然语言请求发给浏览器内置的 Gemini Nano。换成人话说，就是以前你在前端调用 fetch('/api/ask')，后端再转发给 OpenAI、Gemini 或自建 vLLM；现在有些场景可以直接在浏览器里问本地模型。

这听起来很香，但我不建议现在就把它当成“云端 LLM 替代品”。它更像一块新的系统拼图：适合放在用户设备边缘，处理轻量、局部、对隐私敏感、失败代价不高的任务。

它真正解决的不是“更聪明”，而是“更靠近数据”

Prompt API 背后的标准化工作在 Web Machine Learning Community Group 的 prompt-api 仓库 里。这个 Explainer 说得很清楚：今天 Web 开发者要用语言模型，通常只有两条路：调用云端 API，或者自己把模型用 WASM/WebGPU 之类的方式塞进浏览器。前者简单但有隐私和成本问题，后者灵活但工程负担很重。

浏览器内置模型想走第三条路：模型由浏览器或操作系统提供，Web 应用只拿到一个标准 API。

说白了就是：模型不属于你，运行环境也不完全属于你，但调用入口变简单了。

这件事的工程价值不在于 Gemini Nano 一定比你后端的大模型强。恰恰相反，它大概率不会更强。它的价值在于位置：模型离用户输入、页面 DOM、临时草稿、聊天记录更近。很多数据本来就停留在浏览器里，如果只是做摘要、标签、轻量问答、辅助改写，非要绕一圈云端并不总是合理。

Chrome 的 built-in AI 入门文档 也强调了这个方向：内置 AI 让 Web 应用在不部署、不管理自有模型的情况下完成 AI 任务。这个表述很克制，它没有承诺“最强模型”，而是在强调部署和管理成本。

我觉得这才是正确打开方式。

但生产环境最先撞上的，是可用性而不是 API 语法

Prompt API 的代码示例并不复杂。Chrome 文档里建议先用 LanguageModel.availability() 判断模型是否可用，再调用 LanguageModel.create() 创建 session；如果模型需要下载，还要监听下载进度并明确告知用户。

技术上这是一个异步初始化问题。

人话翻译：你不能假设用户打开网页时模型已经躺在那里等你。它可能不可用，可能正在下载，可能因为硬件不满足条件而永远不可用。

这和我们熟悉的云端 LLM 调用完全不同。云端 API 的主要失败模式是网络、限流、账单、服务端报错；浏览器本地模型的失败模式多了一层“用户设备差异”。Chrome 的 Get started with built-in AI 写得很具体：使用 Gemini Nano 相关 API 需要桌面 Chrome，移动端暂不支持；设备还要满足存储、GPU/CPU、VRAM 或内存等条件。文档提到模型所在 Chrome profile 卷需要至少 22GB 可用空间，GPU 路线需要超过 4GB VRAM，CPU 路线需要 16GB RAM 和至少 4 个 CPU 核心。

这组门槛对开发机不算高，对真实用户群就很现实了。

所以如果你的产品经理问“能不能直接用 Prompt API 做全站 AI 总结功能”，我的回答会比较保守：可以做渐进增强，不能做唯一依赖。你要准备三层降级：

1. 浏览器本地模型可用：直接本地处理；
2. 本地不可用但用户允许云端处理：走后端 LLM；
3. 两者都不可用：展示普通搜索、规则摘要或关闭功能入口。

没有这层降级，Prompt API 带来的不是成本优化，而是一堆看起来随机的用户投诉。

隐私优势是真的，但别把它神化

本地 LLM 最容易被宣传成“隐私安全”。这个说法有一半对。

对的是：敏感文本不必离开用户设备。比如用户正在编辑一封邮件、整理客服聊天记录、给内部文档做摘要，如果任务可以在浏览器内完成，后端就不需要接触原文。对企业合规来说，这一点很有吸引力。

但另一半问题也不能忽略：Prompt API 仍然是一个网页可调用的能力。只要网页能拿到用户输入，它就可能构造提示词、读取模型输出、把结果再发回服务器。也就是说，本地执行降低的是“模型服务商和中间链路”风险，不会自动消灭“应用本身滥用数据”的风险。

这和我之前写 Agent Armor 安全框架 时的判断很像：AI 能力越靠近用户工作流，越不能只看模型能力，还要看权限边界、审计、用户确认和降级策略。浏览器内置 AI 也是一样。它不是隐私银弹，只是把一部分风险从云端调用迁移到了前端权限治理。

如果你要在生产里使用，我建议至少做三件事：

• 明确告诉用户哪些内容会被本地模型处理，哪些内容可能上传云端；
• 对所有云端降级路径做单独授权，而不是静默 fallback；
• 不要把本地模型输出直接写入高风险状态，比如自动提交表单、自动修改数据库、自动发送消息。

最后一点尤其重要。浏览器 AI 很适合“建议”，不适合“无确认执行”。

它适合哪些场景？我会从低风险辅助功能开始

从 Chrome 的 Built-in AI APIs 页面看，Google 并不只推一个通用 Prompt API，还把 Summarizer、Writer、Rewriter、Translator、Language Detector、Proofreader 等能力拆成更窄的 API。这个方向我反而更认可。

通用 Prompt API 很灵活，但灵活意味着不可预测。窄 API 的好处是产品语义更明确，浏览器和规范制定者也更容易约束输入输出。

我会优先考虑这些场景：

• 页面内摘要：对长文、评论串、客服记录做“先看概要”；
• 本地分类和标签：给用户自己的笔记、收藏、邮件草稿打标签；
• 写作辅助：改写、润色、语气调整，但保留用户确认；
• 站内轻量问答：只基于当前页面或当前文档回答问题；
• 隐私敏感预处理：先在本地抽取结构化信息，再决定是否上传。

反过来，我不建议现在用它做这些事：

• 需要稳定推理能力的复杂 Agent；
• 需要严格一致输出格式的核心业务流程；
• 跨用户一致体验要求很高的 SaaS 核心功能；
• 需要引用最新知识或大量私有知识库的 RAG。

这里可以类比 RAG 里的重排问题。我在 RAG 系统中 Bi-Encoder 与 Cross-Encoder 的工程对决 里提过，工程系统经常不是选“最先进模型”，而是把不同模型放到合适的位置。Prompt API 也是这个逻辑：它适合做离用户最近的第一层智能，而不是替代整个后端 AI 架构。

标准化会比模型本身更关键

Prompt API 最值得关注的地方，其实不是 Chrome 现在接了 Gemini Nano，而是它出现在 W3C Web Machine Learning 社区的标准化讨论里。GitHub 仓库 README 明确提到，Chrome、Microsoft Edge 和 Web Machine Learning Community Group 都在探索让 Web 开发者直接 prompt 浏览器或操作系统提供的语言模型。

这句话的信息量很大。

如果最后只有 Chrome 支持，那它更像 Chrome 独占能力，适合 Extension 或实验性 Web 功能。如果 Edge、Safari、Firefox 或操作系统层 API 也逐步靠近同一抽象，那浏览器内置模型就可能变成新的 Web 平台能力。历史上很多能力都是这样来的：先是某个浏览器的实验 API，然后经过权限、兼容性和安全模型反复打磨，最后才进入开发者默认工具箱。

当然，这里仍然有几个硬问题没解决：

• 不同浏览器背后的模型能力差异怎么暴露？
• 开发者能不能知道上下文窗口、语言支持、模态支持？
• 本地模型更新后，线上功能行为变化如何回归测试？
• 企业管理员是否能禁用或管控这类 API？
• prompt 注入和页面内容污染如何防？

这些问题不解决，Prompt API 就很难承载高风险生产流程。

但这不妨碍它先从低风险场景切进去。Web 平台很多能力都是这样长大的。

我的结论：把它当“边缘 AI 层”，不要当“后端替代品”

如果只问“Chrome Prompt API 能不能用于生产环境”，我的答案是：可以用于生产环境里的渐进增强功能，但不适合作为核心 AI 后端的唯一依赖。

它最适合的位置，是浏览器侧的边缘 AI 层：

• 先做本地摘要、分类、改写、草稿辅助；
• 对隐私敏感内容尽量不上传；
• 对失败可接受的功能做体验增强；
• 对复杂推理、企业知识库、审计和一致性要求高的任务，仍然交给后端。

这不是一个“本地模型打败云端模型”的故事。更准确地说，是 Web AI 架构开始分层：浏览器负责近场、低延迟、隐私友好的轻任务；后端负责强模型、统一策略、知识库和审计。

我不确定 Prompt API 最终会以现在的形态稳定下来，尤其是浏览器兼容性和企业管控这两块还有很长的路。但它提出的问题已经很明确：不是所有 AI 请求都应该离开用户设备。

这句话，可能会成为未来几年 Web AI 架构设计里越来越重要的默认前提。

参考资料

• Hacker News: The Prompt API
• Chrome Developers: The Prompt API
• Chrome Developers: Get started with built-in AI
• Chrome Developers: Built-in AI APIs
• Web Machine Learning Community Group: prompt-api

2025 年底，某三甲医院的 AI 团队在内部文档分析场景中遇到了一个典型困境：医生需要向 AI 助手上传患者病历、检查报告进行语义检索，但医院 IT 合规政策明确禁止将患者数据上传至第三方云服务。

他们最初的方案是自建 GPT-4 API 代理——但每个月 API 费用数万元，且数据仍然要先出医院网络。后来他们接触到 GAIA 框架，在一台配备 AMD Ryzen AI 9 的工作站上跑起了完全本地化的 RAG 问答 Agent，所有病历数据从未离开医院内网。

「我们关掉了网络访问权限，Agent 依然能跑完整流程。HIPAA 合规审计直接通过。」——项目负责人后来在 AMD 社区分享道。

这不是孤例。随着 ChatGPT API 成本上涨和企业数据外泄风险加剧，「纯本地 AI 推理」从概念验证进入了生产可用阶段。AMD GAIA 框架正是在这个节点上，将本地 Agent 开发从极客玩具变成了企业级选项。

GAIA 框架核心拆解

架构概览

GAIA 是 AMD 官方开源的 AI Agent 开发框架，GitHub 已有 1.1k Stars、77 Forks，最新版本 v0.17.2 于 2026 年 4 月 13 日发布，最近提交距今仅 6 小时。项目采用 Python + C++ 双引擎设计，核心定位是「让 AI Agent 跑在你的 PC 上，而不是别人的服务器上」。

┌──────────────────────────────────────────────┐
│                 GAIA Agent                    │
├──────────────────────────────────────────────┤
│  ┌─────────────┐  ┌──────────┐  ┌─────────┐  │
│  │  Tool       │  │  LLM     │  │ State   │  │
│  │  Registry   │  │  Client  │  │ Machine │  │
│  └─────────────┘  └──────────┘  └─────────┘  │
│  ┌────────────────────────────────────────┐   │
│  │       Agent Loop: think → tool → loop   │   │
│  └────────────────────────────────────────┘   │
├──────────────────────────────────────────────┤
│  ┌──────────┐ ┌──────────┐ ┌───────────────┐  │
│  │  RAG SDK │ │ Talk SDK │ │ MCP Client    │  │
│  └──────────┘ └──────────┘ └───────────────┘  │
├──────────────────────────────────────────────┤
│  Python Runtime (amd-gaia pip 包)            │
│  C++ Runtime (amd-gaia-cpp)                 │
│  AMD Ryzen AI NPU + iGPU 硬件加速           │
└──────────────────────────────────────────────┘

Agent 基类：Python 版最小代码

GAIA 的核心是 gaia.agents.base.agent.Agent 基类，所有自定义 Agent 都通过继承它并注册工具来实现：

from gaia.agents.base.agent import Agent
from gaia.agents.base.tools import tool

class MedicalRAGAgent(Agent):
    """医疗文档 RAG Agent"""

    def _get_system_prompt(self) -> str:
        return (
            "你是一个医疗文档助手。始终确认引用的文档来源。"
            "不要编造任何未在检索结果中出现的信息。"
        )

    def _register_tools(self):
        @tool
        def search_patients(query: str) -> dict:
            """语义搜索患者文档库"""
            return local_vector_db.similarity_search(query, top_k=5)

        @tool
        def get_lab_report(patient_id: str, report_id: str) -> dict:
            """获取指定患者的检验报告"""
            return db.get(patient_id, report_id)

关键设计点：工具用 @tool 装饰器注册，Agent Loop 内部自动完成 推理 → 选工具 → 调用 → 结果回填 → 继续推理 的循环，无需手动管理状态机。

C++ 引擎：无 Python 依赖的轻量选择

C++ 版本实现了与 Python 版完全一致的 Agent Loop、工具注册接口和 MCP 客户端协议，但零 Python 依赖，适合嵌入桌面应用或嵌入式设备：

#include <gaia/agent.h>

class MyAgent : public gaia::Agent {
protected:
    std::string getSystemPrompt() const override {
        return "You are a helpful assistant.";
    }
};

多 SDK 生态：从 RAG 到语音到 MCP

GAIA 不只是一个 Agent 框架，它自带一整套本地 AI 工具链：

关键工程洞察

1. NPU 加速才是本地 LLMs 的未来

AMD Ryzen AI PC 的核心优势在于 NPU（Neural Processing Unit）：一块独立神经网络处理器，额定算力最高 50 TOPS，功耗低于 10W。对比纯 GPU 推理，NPU 允许长时间低发热运行，适合桌面 Always-on Agent 场景。

GAIA v0.17.x 已经支持将推理任务卸载到 NPU，这意味着：

• CPU 保持空闲，LLM 推理不卡住主线程
• 笔记本电池续航不受影响
• 可以在 Air-gapped（物理隔离）环境中持续运行

2. 双引擎策略是务实的工程选择

Python 版本功能完整（所有 SDK），C++ 版本精简可用（Agent Loop + MCP）。这不是「二选一」，而是渐进式迁移路径：

• 阶段 1：Python 原型验证，功能完整
• 阶段 2：C++ 重写核心逻辑，嵌入 Electron UI
• 阶段 3：打包成跨平台桌面应用，用户无需知道 Agent 背后是什么语言

这对需要交付商业产品的团队尤为重要。

3. 隐私合规场景的真实取舍

本地 Agent 不是银弹。选型结论：

信源

• GAIA 官方文档（AMD）：https://amd-gaia.ai/docs
• GAIA GitHub 仓库：https://github.com/amd/gaia
• GAIA PyPI 包：https://pypi.org/project/amd-gaia/
• GAIA 最新 releases（含桌面安装包）：https://github.com/amd/gaia/releases
• GAIA v0.16.0 C++ Agent Framework 发布说明：https://github.com/amd/gaia/releases/tag/v0.16.0