简介页面辅助工具Page Assist是一款面向Chrome与Firefox浏览器的本地AI模型Web UI插件通过集成Deepseek模型让用户无需联网即可在侧边栏与网页中直接调用AI能力适合注重隐私或需要离线使用大模型的开发者与爱好者。压缩包共131个文件约11.97MB包含45个js逻辑脚本、14个json配置、多个字体与样式文件以及sidepanel.html、options.html等界面入口目录结构清晰便于二次配置。其中Chrome版本已实测通过Deepseek R1验证Firefox插件尚未测试但功能模块基本对应。资源附带内容脚本、后台逻辑及本地化资源可帮助理解浏览器扩展与本地AI的集成方式已有9764人学习下载适合作为本地AI应用开发与插件定制的参考。1. Page Assist 是什么一个长在浏览器里的本地 DeepSeek 界面第一次用 Page Assist 跑 deepseek 的时候我的第一反应是这不就是个侧边栏聊天框嘛。直到我在不打开任何 Docker 容器的情况下用浏览器扩展直接连上本地 Ollama 里的 DeepSeek 模型才反应过来它真正解决的问题是——本地 AI 模型的 Web UI 太重了。只要电脑能跑 LLM推理浏览器就是现成的壳子不用再维护一个 Web 服务端。这篇文章就是讲清楚 Page Assist 到底是什么、怎么把它接到 DeepSeek 模型上、以及它和 Open WebUI 这类工具的根本差异适合那些已经在用 Ollama 跑模型但嫌官方界面太朴素、或者不想为聊天界面再开一个 Python 服务的开发者。2. 为什么选 Page Assist它和 Open WebUI、Chatbox 不是一类东西2.1 架构先想明白这个 UI 根本没有服务端很多人第一次看到 Page Assist会下意识把它当成又一个聊天网页打开一个 URL输入 prompt拿到回答。这是 Open WebUI 的做法——它要给本地推理后端套一层 HTTP API宿主在一个 Python 服务里有独立的端口和会话管理。而 Page Assist 把整条链路搬进了浏览器扩展扩展页面本身是 UI浏览器负责发请求、管理会话历史、处理上下文注入后端可以是本机的 Ollama、LM Studio也可以干脆用浏览器内置的 WebLLM 在本地跑小模型。这个区别直接决定了你会不会选它。Open WebUI 是一个带完整生态的应用你需要安装 Python、装依赖、配置环境变量、管理容器生命周期如果用 Docker启动之后才轮到模型干活。Page Assist 的设计逻辑就是用最小代价换来一个够用的 Web 界面它不启动任何系统服务不占端口不用配反向代理关掉浏览器就等于整个 AI 服务从内存里消失。对于我在笔记本上跑着一个小蒸馏模型、就想要个顺手的聊天窗口这个场景它的开销趋近于零。选型时可以按这个表对号入座维度Page AssistOpen WebUIChatbox 桌面版形态浏览器扩展Docker/Python 应用独立桌面客户端安装成本低点一下装扩展高需要容器环境中下安装包启动开销几乎为零常驻服务常驻进程网页上下文原生支持读取当前标签页依赖浏览器插件或手动粘贴不支持适用场景本机 Ollama 轻度日常使用多用户 / 团队共享跨设备重度聊天我这里说的是常见方案里的对比不是劝你放弃 Open WebUI。如果你要跑一个 32B 以上的量化模型、要管多用户、要审计日志那 Web UI 后端反而是更稳的选择。但如果你只是一个人、一台机器、一个页面Page Assist 的零服务端模型确实值得先试一下——它能帮你省掉一大半建环境的血泪经验里最常见的那一步环境坏了重装。2.2 安装和入口它到底装在哪里、读写什么Page Assist 的安装方式按浏览器的扩展分发渠道来常见有两种一是从 Chrome 网上应用店或 Edge 加载项商店直接安装二是如果企业环境封闭可以下载扩展包crx 解压后的文件夹再用开发者模式加载已解压的扩展。第二种方式本质上和装一个普通扩展没有区别只是多一步选择文件夹的操作。装完以后浏览器工具栏会出现它的图标点开会有一个可拖动的侧边栏也支持抽成一个独立窗口来用。这里有一个大多数用户没注意到的权限点Page Assist 会申请读取网页内容的权限。它需要这个权限才能实现网页上下文功能——也就是你在任何一个页面上选中几段文字点一下按钮就能把它喂给本地模型做翻译、总结、改写。这意味着它在运行时能看到你在当前网页里选中的内容虽然只对当前激活标签页生效不会后台收集所有页面内容但如果你对隐私敏感可以把这个权限在扩展详情页里关掉代价就是只能手动粘贴文本进聊天框。装好后最值得做的第一件事不是急着聊天而是打开扩展的设置/模型管理页面把 Provider 看懂。页面里会有类似 Ollama、WebLLM、OpenAI 兼容接口 这样的选项这就是接下来要接 DeepSeek 模型的入口。很多人在这一步卡住不是因为界面复杂而是不知道 Ollama 和浏览器之间还隔着一道跨域的坎——这就是下一节要解决的问题。3. 用 Ollama 接 DeepSeek从装扩展到跑通聊天的完整链路3.1 为什么默认连不上扩展页面到 127.0.0.1 其实跨域了把 Page Assist 的 Provider 切到 Ollama地址填http://127.0.0.1:11434然后点连通性测试最常见的结果是失败。用 curl 直接打同一个地址明明一切正常。这个玄学背后是一个确定的技术原因浏览器扩展页面和内容脚本发起请求时请求的 Origin 是chrome-extension://扩展ID这个专属源源即 scheme host port。而 Ollama 服务默认只接受来自本机 localhost 的源对其他 Origin 一律返回 403。这不是 Page Assist 的问题而是 Ollama 出于安全考虑在较新版本里加上的跨源限制白名单由环境变量OLLAMA_ORIGINS控制。原因是任何网页都能向你的本地端口发请求如果把本地模型接口完全暴露给所有网页等于任何带毒网页都能偷偷调你的显卡算力、消耗你的内存。所以 Ollama 默认允许的来源非常收敛。这里绕不开的解决办法就是把chrome-extension://源加进白名单。3.2 最小可跑配置改一个环境变量解决 90% 的连接失败常见做法是设置两个环境变量OLLAMA_HOST控制监听地址OLLAMA_ORIGINS控制允许的跨域来源。对于本机单用户使用OLLAMA_HOST保持127.0.0.1:11434即可不需要改成0.0.0.0——那会把服务暴露给局域网得不偿失。真正要动的是OLLAMA_ORIGINS。Linux / macOS 下我用的是临时导出加写入配置文件的组合# 临时生效适合先验证链路 export OLLAMA_ORIGINSchrome-extension://* ollama serve # 持久化写入用户级 systemd 配置以 systemd 运行的常见方式 mkdir -p ~/.config/systemd/user cat ~/.config/systemd/user/ollama.service.d/override.conf EOF [Service] EnvironmentOLLAMA_ORIGINSchrome-extension://* EOF systemctl --user daemon-reload systemctl --user restart ollamaWindows 的情况稍有不同在环境变量面板里新建一个用户变量变量名OLLAMA_ORIGINS变量值chrome-extension://*然后重启 Ollama任务管理器结束 ollama.exe 再重新运行或在托盘区退出后重开。设置完后来验证一下链路curl http://127.0.0.1:11434/api/tags如果返回一段包含模型列表的 JSON说明 Ollama 本身没问题接下来才是被 Page Assist 调用。这里有一个容易忽略的点OLLAMA_ORIGINS的值为chrome-extension://*时*号匹配的是该 scheme 下的任意扩展 ID。为什么不用写死某一个 ID因为每次 Chrome 更新或你重新加载扩展扩展 ID 有可能变动写死白名单等于埋雷通配符在这里是省事且安全的做法——因为只有浏览器扩展这种进程才有chrome-extension://源普通网站伪造不了。参数说明OLLAMA_HOST不建议动保持127.0.0.1即可OLLAMA_ORIGINS可以写多个来源用逗号分隔比如你既要给 Page Assist 用又要给局域网内的某个开发机调试那就加上OLLAMA_ORIGINSchrome-extension://*,http://192.168.1.100:3000。每次改完环境变量都必须完全重启 Ollama 进程才生效很多改完还报错其实是因为旧进程还占着端口、新配置根本没加载。3.3 在 Page Assist 里配置 Provider地址、模型名和请求参数Ollama 服务正常后回到 Page Assist 的设置页。Provider 选 OllamaAPI 地址填http://127.0.0.1:11434。这里注意括号里的细节有些版本默认填的是http://localhost:11434而localhost在部分系统上会先解析成 IPv6 的::1如果 Ollama 只监听了 IPv4 就会连接失败。所以我建议一律写127.0.0.1少一个变量就少一次排查。模型列表会自动从 Ollama 拉取。DeepSeek 系列在 Ollama 上有多种命名量化程度和蒸馏参数不同常见的有deepseek-r1:7b、deepseek-r1:1.5b这类蒸馏量化命名以及针对代码场景的变体。选择时按硬件显存判断8GB 显存跑 7B 量化版还可以纯 CPU 就老实选 1.5B否则响应速度会让你怀疑服务是不是挂了。请求参数里最值得调的是num_ctx上下文长度。Ollama 默认的上下文长度有时候才 2048也就是说你喂给模型的对话历史超过这个 token 数之后模型会直接丢掉最早的部分造成聊着聊着它忘事儿了。Page Assist 有的版本会在请求里把参数传给 Ollama如果你没看到入口可以直接在 Ollama 的模型配置文件里改ollama create deepseek-r1:7b -f Modelfile # Modelfile 里写 # FROM deepseek-r1:7b # PARAMETER num_ctx 8192 # PARAMETER temperature 0.6这段命令的意思是基于现有模型创建一个继承其权重的自定义配置副本。num_ctx 8192相当于约 6000 个中文字符的上下文日常网页总结和长对话够用temperature 0.6是创造性开关代码生成和翻译建议设低一点0.3~0.5闲聊可以到 0.8。需要说明的是num_ctx改大直接增加 KV cache 的内存占用8GB 内存的机器不要无脑拉满 32768否则模型加载时内存直接爆掉。4. 避坑清单连不上 Ollama、模型列表空白和对话中途断掉4.1 坑一curl 能通扩展里却一直转圈现象在终端里用 curl 访问 Ollama 的/api/tags返回正常但 Page Assist 里测试连接时一直转圈或返回 403。原因没有设置OLLAMA_ORIGINS或者设置后 Ollama 进程没重启。浏览器发起的请求带了chrome-extension://源而 Ollama 默认拒绝。解决按 3.2 节设置OLLAMA_ORIGINSchrome-extension://*然后确认 Ollama 进程真的重启了。有个混淆点Windows 托盘区或者服务管理工具里看到的 Ollama 进程可能是开机自启的另一个实例你手动启动的这个只是一个前台进程。最稳妥的验证方式是杀掉所有 ollama 相关进程再重新启动然后在 Page Assist 里重新跑一次连通性测试。4.2 坑二模型列表是空的但 Ollama 里明明有模型现象在 Ollama 终端里ollama list能看到deepseek-r1:7bPage Assist 的模型下拉框却是空的。原因很多情况下是 API 地址填成了http://localhost:11434而 Page Assist 所在的运行环境解析 localhost 时走了 IPv6另一种情况是扩展从缓存里拿了启动时的空白列表没有重新拉取。解决把地址统一改成http://127.0.0.1:11434然后关掉扩展页面重新打开。如果还不行在浏览器开发者工具的网络面板里看/api/tags请求是否有报错看到 403 就回到坑一看到 200 但前端还是空的就重启浏览器。为什么缓存会过期因为 Ollama 的模型列表是动态的扩展只会拉一次并缓存不会实时探测。4.3 坑三对话中途突然断掉或超时现象聊得正投入模型回答到一半页面报错或者干脆空白。原因最常见的是num_ctx太小。长对话时 prompt 的 token 数超过了模型的上下文窗口Ollama 不会自动截断而是直接报错。另一个容易被忽略的原因是 CPU 推理太慢扩展默认的请求超时时间不够用尤其用 7B 模型在无 GPU 环境跑长文本生成的时候。解决按 3.3 节的方式加大num_ctx同时在 Page Assist 的请求参数里看有没有超时设置有就调到 120 秒以上。如果你用的是同一台机器的核显或集成 GPU注意观察显存占用是不是已经满了——显存溢出不报错而是表现为生成速度骤降这种翻车最隐蔽。可以先降到 1.5B 模型确认链路再换回 7B 排查性能瓶颈。4.4 坑四网页上下文功能选中总结没反应现象在一个网页里选中一段文字点 Page Assist 的总结/翻译按钮聊天框迟迟没有动静。原因权限问题或者页面限制。如果扩展没有读取网页内容权限它拿不到选中的文本如果在浏览器的内部页面如chrome://开头的页面或扩展商店页面任何扩展脚本都无法注入这是浏览器的安全机制。解决回到扩展详情页确认读取网站内容权限是开启的普通页面如果还不行刷新一次页面让 content script 重新注入。我一般会先在example.com这种普通网站上测试排除是内部页面的问题。这条经验提醒我网页上下文功能好用但它不是一个万能剪切板遇到无权限页面时该复制粘贴还是复制粘贴。4.5 坑五WebLLM 模式下模型下载到一半就失败现象不用 Ollama改用 Page Assist 内置的 WebLLM 跑模型下载进度条卡在 80% 或者中途失败重试又开始从头下。原因WebLLM 把模型文件缓存在浏览器存储里是一个黑盒。断点续传逻辑在处理分片文件时有时候不够可靠加上模型文件本身好几个 GB任何一次网络抖动都可能中断。解决除了找个稳定的网络重试之外更常用的做法是直接放弃 WebLLM回到 Ollama 方案——Ollama 的下拉中断后续传逻辑成熟得多而且不会把浏览器站点数据塞爆。这个坑给我的教训是浏览器内跑模型这个功能适合做演示或临时用真要长期用还是让专业后端干专业事。5. 进阶玩法用 WebGPU 在浏览器里直接跑 DeepSeek 蒸馏模型5.1 零后端原理WebLLM 把 GPU 计算搬到了浏览器的 WebGPU API 上Page Assist 的第二种模型来源是浏览器内模型WebLLM原理是把大模型推理所需的算子用 WASM 和 WebGPU 重写数据预处理、token 采样、KV cache 全部在浏览器进程内完成完全绕过 Ollama。模型权重以分片文件形式下载到浏览器的站点存储里然后按需加载到显存/内存。它没有独立的服务进程没有端口也没有 Python 环境依赖——两个浏览器标签页一个跑模型一个聊天。但要冷静看待这个模式的边界能塞进浏览器跑的 DeepSeek 模型通常只有蒸馏版的小参数模型1.5B / 7B 的 4-bit 量化。由于 WebGPU 的实现和驱动有关同样一个模型在同一台机器上换个浏览器版本速度可能差一倍以上。这个方案的定位是应急 极简——适合不方便安装 Ollama、或者临时在一台干净的机器上演示用。生产级体验还是 Ollama 更稳不要指望 7B 模型在浏览器里能追上原生推理后端的性能。用 WebGPU 跑模型首要前提是浏览器支持并启用了 WebGPU。Chrome 较新的正式版已经默认开启但如果你用的是旧版本或被组策略禁用的环境就需要手动检查。5.2 验证 WebGPU 是否可用一个 JS 命令搞定打开目标页面任意 https 网页或扩展页面按 F12 打开控制台输入// 检查当前浏览器是否暴露 WebGPU API if (navigator.gpu) { // 请求适配器打印 GPU 基本信息 const adapter await navigator.gpu.requestAdapter(); console.log(adapter ? WebGPU OK: ${adapter.info.vendor} : No adapter); } else { console.log(WebGPU not supported in this browser); }这段代码的思路分两层navigator.gpu存在只代表浏览器实现了 API真正能不能用还要看requestAdapter()能不能拿到一个适配器。如果适配器是null说明当前设备的显卡驱动或者浏览器黑名单机制把 WebGPU 禁用了。最常见的场景是 Windows 的远程桌面会话里很多虚拟显卡驱动不在 WebGPU 的支持列表内脚本会打印 No adapter。运行环境要求还有一个容易踩的点WebGPU 必须先过安全检查如果页面是在 HTTP非 localhost环境下打开requestAdapter()同样会拒绝返回适配器。而 Page Assist 的扩展页面天然是chrome-extension://安全源所以一般不会有这个问题但如果你把它的窗口抽出来放进普通标签页调试就要注意协议。参数说明这里我没有写死任何设备型号因为 WebGPU 的支持矩阵是驱动相关的黑匣子你的机器能不能用跑一下脚本比查文档快得多。5.3 切到浏览器内模型模型选择、缓存管理和期望值管理在 Page Assist 的设置里把 Provider 切到浏览器内模型 / WebLLM它会出现可用的模型列表。选择 DeepSeek 蒸馏版的时候注意看量化说明Q4 甚至 Q3 量化通常是为了适配 8GB 以下显存模型质量会有可见下降Q8 以上跟原始权重差距小但内存压力大。我一般按这个逻辑选日常聊天选 Q4代码或翻译类任务选 Q6/Q8 且保证显存足够。参数上值得调的有两个上下文长度和 temperature。WebLLM 的上下文长度会直接影响显存占用建议从 4096 起步跑长了再往上调。temperature 和 Ollama 里的含义一样但这个环境里我习惯设低一些因为浏览器内模型的采样稳定性本来就稍弱0.4 左右比较保险。模型文件下载到浏览器存储后占用体积相当可观多个 GB清理方式是删除扩展的站点数据在浏览器设置里清除该扩展的存储——相当于后悔药但吃完就得重新下载。缓存文件只能整体管理WebLLM 目前没有提供按模型单独删除的粒度。6. 最后一个习惯把选中文本一键喂给模型变成肌肉记忆真正提升 Page Assist 使用频率的是它那个网页上下文功能。用顺手的方案是配置三套固定提示词在设置里分别存好用时选中文本一键触发一套是把下面内容压缩成三条要点适合读技术文档一套是把下面内容翻译成中文术语保留英文并解释适合看英文 issue还有一套是指出下面这段代码里的问题并给修改建议适合逛代码片段。这三套模板能盖住日常 80% 的诉求省去了反复输入相同指令的麻烦。使用时选中文本、打开侧边栏点对应模板模型收到的是当前页面内容截取 你的指令。这里有一个安全习惯要养成不要选中登录后才能看到的隐私内容喂给模型尤其是本地模型虽然不联网但网页上下文本身可能会带上页面里其他不可见的文字比如未渲染的隐藏段落。有一次我给一个在线后台管理系统做页面文案总结选中一段可见内容模型却把隐藏在页面 JSON 里的另一段数据也一起处理了。从那以后凡是涉及敏感数据的页面我都关掉网页上下文权限手动把文本复制进聊天框——多花十秒少很多不必要的风险。这套工作流的最终形态是浏览器常年开着侧边栏随手呼出Ollama 在后台待命DeepSeek 蒸馏模型负责翻译、总结、写代码草稿。不再为一次临时总结打开各种云笔记或第三方 AI 网页。Page Assist 给我的最大价值不是又一个聊天框而是把本地模型变成浏览器的原生能力。希望帮到你。本文还有配套的精品资源点击获取