简介：Page Assist 是一款面向开发者的开源浏览器扩展，可在 Chrome 中直接调用本地 AI 模型，无需切换窗口即可完成模型交互与测试。整个压缩包仅 5.97MB，包含 94 个文件，以 JS 逻辑脚本、HTML 页面、JSON 配置和大量 ttf/woff/woff2 字体文件为主，另有 wasm、css、gz 等格式，分别承担扩展逻辑、界面样式、数学公式渲染与 OCR 识别等功能。提供 1.4.5 完整版扩展，解压后可直接加载使用；目录模块清晰，后台逻辑、内容脚本与选项页分工明确，对想学习浏览器扩展结构或定制本地 AI 工具的人很有帮助，其中还包含对接 Ollama 与 Hugging Face 的拉取脚本，便于理解本地模型接入方式。内置多语言 messages 文件和 Tesseract OCR 组件，既支持多语言界面，又能在浏览器中完成图片文字识别，进一步提升了插件的可用性与参考价值。已有 580 人浏览学习，适合开发者、AI 爱好者及扩展程序研究者作为入门或二次开发的基础包。
1. 谷歌浏览器 Page Assist 插件：它到底解决了什么问题
如果你已经在本机装好本地模型服务并拉下来几个模型，大概率也经历过这个场景：读技术文档时想立刻让 AI 解释某段逻辑，或把长文压缩成三句话，却不得不复制全文、切到另一个聊天页面再粘贴。Page Assist 是安装在 Chrome 等 Chromium 浏览器里的开源扩展，它把本地大模型的聊天入口直接放进浏览器侧边栏、浮层和右键菜单，让你不离开当前网页就能完成页面摘要、选中文本翻译、自定义提问，甚至基于整个页面内容做检索式问答。它的核心价值就一句：给浏览器装上本地 AI 的随叫随到入口，数据始终留在本机。全文会从原理讲到配置，再从页面 RAG 讲到常见坑，适合已经跑通本地模型、想把模型真正融进网页阅读流程的人。
2. 原理与选型：Page Assist 是怎么把本地模型“塞”进浏览器的
2.1 一条完整调用链：浏览器扩展、本地推理服务与模型的关系
Page Assist 本身不运行模型，也不包含推理引擎。它只是一个经过封装的前端客户端，负责三件事：渲染聊天界面、从当前页面收集文本、把文本和对话历史转换成对本地推理服务的 HTTP 请求。真正的推理过程发生在你本机的模型服务进程里，也就是通过 Ollama 这类工具拉起的常驻服务，它默认监听 11434 端口，处理完请求后把结果流式返回给扩展。
我用最直白的方式理解这条链路：浏览器扩展是“遥控器”，本地模型服务是“机顶盒”，模型是“频道”。你在浮层里输入一句话，扩展把它打包成 JSON 发给本机服务；服务把输入交给模型做推理，再把生成结果一段一段送回扩展的对话框。整个过程全部走localhost回环地址，不经过公网，这是它适合处理敏感内容的根本原因。
要验证这条链路是否通，最快的方式是直接在终端里请求本地服务的接口。下面这几个命令是配置 Page Assist 之前必做的检查：
# 1. 确认本地服务正在运行，并返回模型列表 curl -s http://localhost:11434/api/tags # 2. 拉取一个对话模型，用于摘要、翻译和普通问答 ollama pull qwen2.5:7b # 3. 拉取一个嵌入模型，页面上下文检索依赖它 ollama pull nomic-embed-text第一条命令返回的 JSON 里能看到模型列表，如果连接被拒绝，说明服务没启动或者监听地址不是 11434。第二条和第三条是准备环节：对话模型负责“思考和回答”，嵌入模型负责把网页文本变成向量，局部 RAG 的“检索”能力建立在向量之上。只拉对话模型不拉嵌入模型，页面问答功能会直接不可用，这是我见过最多的配置翻车点。
浏览器扩展与本地服务之间的调用也有安全限制：Chrome 的跨域策略通常不允许普通网页脚本随意访问localhost的其他端口，但扩展会预先声明本地服务访问权限，因此可以访问本机服务。正因为这种权限边界，Page Assist 必须以扩展形式存在，而不是做成一个普通网页。这也是它和“把模型网页版开在浏览器里”最本质的区别。
2.2 为什么选插件而不是纯 Web 界面：三个不可替代的场景
模型服务自带一个简单的 Web 聊天界面，你也可以用第三方桌面客户端。但如果你认真数一数日常阅读网页的动作，会发现它们大多发生在“当前页面”这个上下文里：看到一段配置想翻译，看到一段报错想解释，看完一整页想做个总结。每次切走标签页都意味着阅读中断，而浏览器插件能把 AI 入口放在手边。
第一个不可替代的场景是右键菜单。选中一段文字，点右键，直接把选中内容发给模型，浮层立即显示回答，不用复制、不用粘贴、不用再描述上下文。第二个场景是页面摘要。扩展可以直接抓取当前标签页的正文，你只要点一下“总结”就能拿到结果，这在读长文档时非常省事。第三个场景是页面实时问答：开启页面上下文后，扩展会先对当前页面内容做向量化索引，然后你问的任何问题都能在页面范围内检索答案，效果类似给网页加了一个私有的知识库。
这三个场景单独拿出来，理论上都能用“复制粘贴 + 网页版”实现，但操作成本完全不同。插件把上下文提取和答案生成做成了连续动作，使用者只需要保持阅读状态。对高频阅读者来说，有没有这一层交互差异，决定了本地模型最终是“偶尔打开的工具”还是“随手可用的助手”。
2.3 动手之前：环境准备与模型选型清单
在安装扩展之前，建议先花五分钟把“地基”打好。首先是确认系统内存和显卡显存。7B 级别模型量化后大约需要 4～6GB 内存，如果电脑总共只有 8GB 内存，建议先跑 3B 或更小模型；如果有独立显卡，尽量选择能完整放入显存的量化版本，推理速度会明显更快。
其次是模型选型。日常摘要、翻译和问答，我一般会选指令跟随能力强的中英文模型；如果主要处理英文技术文档，英文较强的模型表现会更稳定。嵌入模型方面，nomic-embed-text是入门百搭选择，中文场景也可以用，效率足够但效果一般；如果你有更好的中文嵌入模型，也可以替换，只要能在本地服务里跑起来就行。
最后是环境变量确认。默认情况下本地服务会监听127.0.0.1:11434，这也正是扩展默认配置能直接连通的原因。有些开发者习惯把监听地址改成局域网以便其他设备访问，改完记得填对地址。检查命令就是上一节的curl，看到模型列表再往下走，后续所有问题排查都建立在此之上。
3. 从安装到第一次对话：Page Assist 的最小可复现路径
3.1 扩展从哪里装：商店版与手动加载版怎么选
安装 Page Assist 有两条常见路径。第一条是去 Chrome 扩展商店搜索它的英文名，找到后直接“添加到 Chrome”，这是最省事的方式，自动完成更新，适合绝大多数用户。第二条是从开源发布页下载打包好的 zip 文件，在chrome://extensions页面打开“开发者模式”，选择“加载已解压的扩展程序”，路径指向解压目录。手动加载的优势是可以用最新构建版本，也可以先快速浏览代码确认没有隐私风险，但缺点是不会自动更新，每次升级都要手动重复一次。
给一张很直观的对比表，方便决定选哪条路：
| 安装方式 | 优点 | 缺点 | 适合人群 |
|---|---|---|---|
| 商店直接安装 | 自动更新、安装快 | 版本可能略旧 | 绝大多数普通用户 |
| 手动加载 zip | 版本最新、可先审代码 | 手动升级、略繁琐 | 开发者、喜欢尝鲜的用户 |
不管用哪种方式，装完之后建议把扩展图标固定到浏览器工具栏上。Page Assist 的使用频率非常高，每次从扩展菜单里翻会很别扭。固定方式是在工具栏的拼图图标里找到它，点击图钉固定到显眼位置。
3.2 三个必填配置项：服务地址、对话模型、嵌入模型
安装完成后，点击扩展图标会进入设置页面。这里最重要的就是三个配置：服务地址、对话模型、嵌入模型。服务地址默认是http://localhost:11434，一般不用改，除非你改了本地服务端口，或者想连接同一局域网里另一台机器上的模型服务，那就需要填对应的 IP 和端口。
对话模型是从服务端拉取的模型列表里选一个，入口通常是一个下拉框，里面显示的是你已经拉取的模型。如果你在列表里找不到想要的模型，先在终端执行ollama list确认模型名字，很多时候只是扩展读取的是精确名称，或者这个模型还没下载，先去拉取再回来看。嵌入模型同样在下拉框里选，建议选择nomic-embed-text这样的小型嵌入模型，索引网页时开销很低。
这里有一个很常见的坑需要提前说明：嵌入模型是使用页面归纳能力的前提，但它不在“对话模型”列表里，而在独立的嵌入模型配置里。如果只看对话模型列表，会以为嵌入模型没有配置选择，但页面问答功能仍然报“请配置嵌入模型”。配置好这三个参数之后，保存设置，再重新打开浮层，就能开始正常对话了。
3.3 跑通第一次真实调用：页面摘要与选中文本问答
配置完成后的第一件验证工作，我建议直接做一次页面摘要。打开你正在读的一篇技术文章，点击扩展图标打开浮层，在输入框里输入“总结这个页面的核心步骤”，或者选择预设的页面摘要命令。等待几秒后，扩展会先请求本地服务做文本嵌入，然后把结果和问题一起交给对话模型，最终生成摘要。
这里有个小技巧：摘要任务质量跟页面正文干净程度强相关。如果打开的是一篇包含大量导航、广告和评论区的文章，摘要可能被干扰点污染；大多数时候扩展能识别正文并提炼核心内容，但极端情况下摘要会变成“这个页面包含导航菜单和文章列表”。遇到这种情况，不要急着怀疑扩展，先用浏览器自带的“阅读模式”再试一次，通常能显著提升摘要质量。
验证完摘要后，再试第二个场景：在任意一页选中一段文字，点右键，选择 Page Assist 的翻译或解释命令。这个操作不需要预先设置任何额外参数，选中什么就发什么，浮层会立刻返回结果。这一步跑通，说明扩展与本地服务的“流式响应”链路完整，后面进阶使用页面上下文和自定义指令才有保障。
4. 让 Page Assist “读”网页：页面上下文与本地 RAG 实战
4.1 页面上下文是什么：抓取、分段、嵌入、检索四步走
Page Assist 最值得投入的部分，是它的页面上下文功能，本质是一个跑在浏览器里的轻量 RAG 系统。开启后，扩展会先抓取当前标签页的可见正文，把正文切分成若干小段，每段用嵌入模型计算出一个向量，保存到扩展的本地索引里；之后你用浮层提问时，扩展先计算你的问题和所有页面片段的相似度，把最相关的若干个片段挑出来，连同问题一起交给对话模型。
理解这一步非常重要：它没有把整个页面一股脑塞给模型，而是只把“与问题最相关的内容”塞进上下文。这就是它和直接复制粘贴全文的最大区别。二十页的长文档，可能只有三段内容跟你的问题有关，检索器把它们找出来，模型只需在这几段里找答案，准确率和速度都会更好。
这一步的工作流程，不依赖云端任何服务，所有的向量计算和存储都发生在本地。对于读文档、查 API、核对配置类任务，这套机制非常可靠。它不会把你整个文档库都做成全局知识库，它一次只关注当前打开的页面，这一点反而保留了轻量级临时知识库的灵活性，也让索引速度保持在秒级。
4.2 把页面问答跑通：操作路径与关键参数
实际操作时，先打开目标页面，点击扩展浮层，在设置或对应功能入口里开启页面上下文开关。第一次开启时需要几十秒甚至更久的索引时间，页面越长越久；索引完成后，浮层里直接输入问题即可。比如你正在读部署文档，可以问“这个页面的部署步骤里，第二步要求修改哪些配置项”，回答会只引用页面里存在的内容。
如果你安装的版本在设置里暴露了检索参数，有几个值值得认真调。分块大小建议控制在 800～1000 个字符，块太大容易把不相关的段落卷进去，块太小又容易把关键句子切断；重叠一般设 100 字符左右，避免切分时正好把一句完整配置切成两半；top-k 检索数量默认 3～5 就够，问题涉及多个分散主题时可以调到 8。这些参数本质上是检索精度和覆盖面的平衡，新手先用默认值跑通，再逐步调整。
需要说明的是，不同版本对这些参数的具体命名可能不一样，有的甚至不开放这些参数，固定使用内部默认值。没有参数入口也不影响使用，最多只是没法做细节优化。如果你对效果不满意，优先换更强的基础模型，比调参收益更明显。
4.3 本地 RAG 与云端知识库的边界：隐私、成本、效果
本地 RAG 和云端知识库在实际里各有舒适区，这里给一个明了的对比表：
| 对比维度 | Page Assist + 本地模型 | 云端 AI 内置知识库 |
|---|---|---|
| 隐私 | 页面内容不出本机 | 内容发送到服务商 |
| 成本 | 主要为硬件电费和内存开销 | 订阅或按调用量计费 |
| 延迟 | 取决于设备性能 | 受网络和服务排队影响 |
| 上下文上限 | 受本地模型窗口限制 | 通常更大更灵活 |
由此可以看清它的定位：本地最适合单页深度问答、需要保密的技术文档、没有网络的离线场景；云端适合需要超大上下文、全局知识检索或更高推理能力的复杂任务。对“今天读的这一篇文章”这种临时知识库，Page Assist 的体验是最顺畅的。
5. 避坑与排查：新手最容易翻车的 5 个场景
5.1 现象：连接被拒绝，明明本机服务已经启动
打开浮层，模型列表加载不出来，或者一提交问题就报“连接失败”。原因大概率出在地址配置和环境变量上。很多人在设置里把地址写成了https://前缀，或者填了奇怪的自定义端口，实际上本地服务的默认协议是http，端口是11434。解决很简单，先用curl http://localhost:11434/api/tags验证，如果终端正常而扩展失败，就去扩展设置里把地址改回http://localhost:11434；如果终端也不通，就说明本地服务没在监听，检查它的进程状态和环境变量OLLAMA_HOST是否被改过。
5.2 现象：模型下拉列表是空的，或调用时提示模型不存在
配置页里的模型列表空，或者手动输入模型名后报错。先不要怀疑扩展坏了，多半是本地服务没运行，或者模型根本没有拉取。在终端执行ollama list，能看到模型名，列表就以它为准；如果列表是空的，就回去重新拉模型。还有一个很典型的原因：模型名和标签不匹配。qwen2.5:7b和qwen2.5是两回事，手动输入时要带全版本标签，否则服务端返回模型不存在的错误。这属于版本号填错的后悔药问题，填完整名字就能避免。
5.3 现象：页面摘要丢关键信息，只回目录不抄细节
摘要输出框架完整但缺少技术细节，比如命令、端口、配置项全被丢掉。这种情况大多是模型上下文太小或页面太长，扩展对正文做了无声截断；模型拿到的不完整文本，自然总结不出细节。解决思路是换用上下文窗口更大的模型，或者在提问指令里明确要求“保留所有命令、端口、文件名”。如果还是不行，把一次总结拆成“按章节分别总结，再汇总”的两段式操作，效果会明显改善。
5.4 现象：页面问答答非所问，甚至引用不存在的段落
页面里有答案，但它答不出来，这种“检索黑匣子”现象通常有几种原因。第一是嵌入模型没配置，系统在找不到向量时退化成纯生成，模型就开始胡编。第二是分块设置太大，关键信息被淹没在无关内容里。第三是提问方式和检索范围不匹配，比如你问的是两个不同小节的内容，默认检索只选了最相关的 3 块，另一部分信息没被搜到。解决路径是：先确认嵌入模型已配置，然后把分块调小到 500 字左右，把 top-k 调大，再明确一点描述问题，让它能命中正确片段。
5.5 现象：浮层转圈、页面卡顿、风扇狂转
整个浏览器的 CPU 和内存占用飙升，打开浮层后明显卡顿，甚至整个浏览器变慢。这种资源问题常见于两种同时发生的情况：一是后台正对长页面做向量化索引，二是本地模型推理时把所有内存都吃光。解决方法是把页面上下文只在真正需要深度理解的文档页开启，普通网页阅读就关掉；模型选小一个级别；还可以在系统层面限制本地服务的并行输出数。一个直接的感受是：如果只是聊天，不开启页面上下文，资源占用立刻会降下来很大一截。
6. 进阶技巧：让 Page Assist 融入日常高频浏览
6.1 按任务切换模型，形成你的固定搭配
在设置里一次性配置好几个模型，然后根据任务切换。日常快速问答、翻译、看新闻摘要，用小模型足够；处理复杂技术文档、需要推代码逻辑时，再换更大参数的模型。我现在的固定搭配是：普通网页一律用小模型，长文档和代码排查换大模型，两者通过浮层上的模型切换入口来回切换，不用反复进设置。
6.2 自定义提示词：固定回答风格和输出结构
页面问答的输出质量，很大程度上取决于提示词设计。我通常会针对技术文档场景固定一个专用提示词，下面这个模板可以直接照搬：
你是一名有一线工程经验的技术从业者。请基于页面上下文回答用户问题。回答时先给结论，再给论据，最多列 5 条关键信息。优先引用原文中出现的命令、参数、文件名和配置项。如果页面上下文里找不到依据，直接说明“页面内容没有提供相关信息”，不要推测。把这段内容粘贴进扩展的自定义指令配置里，以后所有页面问答都会按这个格式输出。重点是它限定了“找不到就直说”这个边界，有效防止模型在检索不到时自己脑补答案。
6.3 一个具体的落地习惯：把敏感文档留在本机提问
我处理内部技术方案时，习惯把文档页面固定在一个浏览器标签页里，打开页面上下文，所有提问都基于页面本身内容，结果不出本机。即使文档里包含敏感配置和内部 IP，也不会经过任何外部服务。现在我的日常已经稳定成了这个模式：读长文、查接口文档、核对部署步骤，全部在侧边栏完成，遇到内容较长的文章，先分段做摘要，再针对重点小节开启页面问答，最后把碎片结论拼成完整理解。
最想提醒你的一条经验：真正折腾出效果的关键，不在扩展本身，而在于两个基础准备是不是到位——对话模型拉对了、嵌入模型拉了。这两个前提控制好，后面所有烦恼基本都少一大半。希望这篇从原理到排错的实战路线能帮到你，如果你也准备开始，建议今天就用一篇真实文档跑通摘要和页面问答，感受一下浏览器里头随时追问本地模型的流畅度。
本文还有配套的精品资源，点击获取
