当大多数端侧 AI 方案聚焦于移动端原生应用或桌面客户端时，一个名为 Gemma Gem 的开源项目将战场拉向了浏览器本身。该项目由开发者 Yaniv Kessler 创建，是一个运行在 Chrome 扩展中的纯本地 AI 助手，能够在不依赖任何云端 API 的前提下，利用 WebGPU 在用户设备上直接运行 Google 的 Gemma 4 模型。这意味着用户的对话数据、页面内容乃至操作行为都不会离开本地浏览器，为隐私敏感场景提供了一种全新的技术路径。
核心架构：三层通信模型
Gemma Gem 的技术架构采用了经典的三层分离设计，分别承载模型推理、消息路由和用户交互三大职责。理解这一架构是掌握整个系统工作原理的关键。
Offscreen Document（离屏文档） 是整个系统的推理核心。Gemma 4 模型通过 @huggingface/transformers 库加载到 WebGPU 上下文中执行推理。离屏文档是一种特殊的 Chrome 扩展页面，它在后台运行而不显示在用户界面中，天然适合承载长时间运行的模型推理任务。该文档内部实现了完整的 Agent 循环，负责接收用户请求、构造提示词、执行模型推理、解析工具调用并返回结果。由于模型完全运行在 WebGPU 上，推理过程的计算密集型操作被有效转移到 GPU 加速，这与传统的 WebAssembly 方案形成了技术路线的差异化 ——WebGPU 提供了更直接的 GPU 访问能力，在支持该特性的现代浏览器中能够实现更高的推理吞吐量。
Service Worker（服务工作者） 充当整个系统的消息路由器。它不仅负责在内容脚本和离屏文档之间传递请求与响应，还承载了两项关键的系统能力：截图捕获（take_screenshot）和 JavaScript 执行（run_javascript）。前者将当前页面渲染为 PNG 图像供模型 “视觉理解” 页面内容，后者则在页面上下文中执行任意 JavaScript 代码，提供完全的 DOM 访问能力。这种设计将需要高权限的操作集中到 Service Worker 中统一管理，而将轻量级的 DOM 工具下放到内容脚本执行，形成了合理的安全边界。
Content Script（内容脚本） 负责向用户呈现聊天界面并执行页面内的 DOM 操作。聊天界面以 Shadow DOM 的形式注入到当前页面中，通过底部右侧的宝石图标触发。内容脚本还实现了 read_page_content、click_element、type_text、scroll_page 等一系列 DOM 工具，这些工具直接运行在页面上下文中，能够精准地读取元素内容、模拟用户点击和输入、控制页面滚动。
推理引擎：模型选择与量化策略
在浏览器环境中运行大语言模型，模型的选择和优化是决定体验成败的核心因素。Gemma Gem 采用了 onnx-community/gemma-4-E2B-it-ONNX 这一 ONNX 格式的 Gemma 4 变体，其参数配置体现了工程上的深思熟虑。
模型采用 Q4F16 量化（4 位量化，FP16 推理），将原始数十亿参数的模型压缩到约 500MB 的体积，首次加载后会被浏览器缓存到磁盘，后续使用无需重新下载。这一体积对于现代浏览器扩展而言是可控的，但对于低配设备仍可能造成加载延迟。Gemma Gem 通过在图标和聊天窗口中显示加载进度来缓解用户的等待焦虑。
128K 上下文长度 是该模型的另一项关键能力。超长上下文使得模型能够在单次推理中 “记住” 整篇页面的内容、完整的对话历史乃至多轮工具调用的结果，为复杂的页面分析和多步骤任务执行提供了基础。然而，超长上下文也意味着更大的显存和内存消耗，在 WebGPU 显存受限的浏览器环境中，这可能成为性能瓶颈。
工具系统：六大能力构建浏览器智能体
Gemma Gem 的工具系统是实现 “浏览器内 AI 助手” 愿景的最后一环。通过将模型的语言理解能力与浏览器的操作能力相结合，用户可以用自然语言指挥 AI 完成多样化的页面任务。
| 工具名称 | 功能描述 | 执行环境 |
|---|---|---|
read_page_content |
读取页面文本内容或指定 CSS 选择器对应的元素 | 内容脚本 |
take_screenshot |
捕获当前可见页面为 PNG 图像 | Service Worker |
click_element |
点击指定 CSS 选择器对应的元素 | 内容脚本 |
type_text |
向指定 CSS 选择器的输入框中输入文本 | 内容脚本 |
scroll_page |
按指定像素量向上或向下滚动页面 | 内容脚本 |
run_javascript |
在页面上下文中执行任意 JavaScript 代码 | Service Worker |
这套工具组合覆盖了浏览器自动化的大部分基础场景。值得注意的是，模型并非直接操作 DOM，而是通过工具调用抽象层来执行操作 —— 这种设计使得 Agent 逻辑与具体的浏览器实现解耦，理论上可以适配不同的浏览器扩展框架。Gemma Gem 的 agent/ 目录采用了零依赖设计，只定义了 ModelBackend 和 ToolExecutor 两个核心接口，具备独立提取为通用库的潜力。
工程实践：开发与调试要点
对于希望复用这一技术方案或参与贡献的开发者而言，了解其工程化细节至关重要。
构建系统基于 WXT，这是一个基于 Vite 构建的 Chrome 扩展框架，提供了开箱即用的热重载、类型支持和构建优化。开发时使用 pnpm build 生成带有完整日志和源码映射的开发构建，通过 chrome://extensions 的开发者模式加载 .output/chrome-mv3-dev/ 目录即可测试。生产构建使用 pnpm build:prod，会移除日志并启用代码压缩。
调试入口根据问题域的不同而有所区别：Service Worker 日志在扩展管理页面的 “检查视图：service worker” 中查看；离屏文档日志在 “检查视图：offscreen.html” 中查看；内容脚本日志则在页面本身的 DevTools 控制台中输出。其中离屏文档日志最为关键，包含了模型加载进度、提示词构造、令牌计数、原始模型输出和工具执行等核心信息，是排查推理异常的主要依据。
配置参数通过聊天界面的设置面板暴露，主要包括三项：思考模式开关（启用 Gemma 4 原生的思维链推理能力）、最大迭代次数限制（控制单次请求的工具调用循环上限）、上下文清除（重置当前页面的对话历史）。此外还支持按域名禁用扩展的粒度控制，隐私敏感场景下可关闭特定站点的 AI 能力。
差异化价值与局限性
与 Google AI Edge Gallery 等面向移动端的端侧 AI 方案相比，Gemma Gem 的核心差异化在于完全基于浏览器环境，无需安装独立应用，不依赖特定操作系统，也不产生任何数据外流。其技术选型 ——WebGPU 加持的 ONNX 推理 —— 在兼容性上仍受限于支持 WebGPU 的 Chromium 系浏览器，但已覆盖了主流的 Chrome、Edge 和 Opera 用户群体。
在性能层面，浏览器环境的显存限制意味着无法运行超大规模模型，Gemma 4 E2B 在能力上与云端版本存在差距。推理速度也高度依赖于用户设备的 GPU 性能，在集成显卡或低端设备上可能出现明显的延迟。这些都是计划采用类似方案时需要评估的现实约束。
资料来源：Gemma Gem 项目仓库（https://github.com/kessler/gemma-gem）