Gemini Nexus：把 Gemini 网页会话、官方 API 与第三方模型塞进一个 Chrome 侧边栏
Gemini Nexus 是一款面向浏览器场景的 AI 助手扩展，集成 Gemini Web、Gemini API 与 OpenAI 兼容接口，支持网页上下文、图像处理、工具调用和 MCP 浏览器控制。
秒懂
- 它是什么？
- 它用 MV3 扩展同时接入九类模型提供方，并靠逆向 RPC 让 Gemini 网页端免密钥可用。这份评测只依据仓库自述，重点看它的数据流、配置方式和几处明确的边界。
- 适合谁用？
- 适合已经在用 Chrome、希望把网页上下文、截图和多个模型提供方放进同一个侧边栏的开发者或个人用户，尤其是愿意自己填 Base URL 和 API Key、接受自担风险的人。不适合把合规放在第一位的团队，也不适合需要长期稳定、可审计接口的生产系统，因为 Gemini Web 通道依赖逆向内部 RPC，随时可能失效。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 9 天前。
- 用什么语言写的？
- 主要是 JavaScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是浏览器里没有原生 AI 层这件事
浏览器用户面对的实际问题是上下文割裂。你正在读的页面、刚截的图、想追问的上一轮回答，分散在标签页、截图工具和另一个聊天窗口之间。Gemini Nexus 的做法是把这些收进 Chrome 侧边栏，再加一个注入页面的浮动工具栏，让提问入口贴着内容本身。
目标用户不是后端工程师。README 把场景写得很直白：网页上下文、图像与截图输入、基于 Chrome DevTools Protocol 的浏览器控制工具，以及可选的 MCP 外部工具。这些能力都要求你人在浏览器里，而不是在终端里。项目用 JavaScript 写成，走 Manifest V3，主页一栏是空的，说明它目前主要靠 GitHub 仓库本身分发。
Gemini Web 通道：从页面 HTML 里抠 token
最需要看清楚的一条数据流是 Gemini Web provider。README 的披露段落写明，扩展通过逆向 gemini.google.com 的内部 RPC 端点，并从页面 HTML 中提取 atValue、blValue、f.sid 三个认证 token。这些 token 存在本地，用来模拟浏览器请求，从而在没有官方 API Key 的情况下访问 Gemini。
代价也写在同一段里：这种做法很可能违反 Google 的服务条款，并可能被认定为未授权访问。请求会带着你的会话凭据发往 gemini.google.com 和 push.clients6.google.com。换句话说，这条路不是灰色地带的模糊描述，而是项目自己承认的风险。它还提供 Gemini Web 临时会话开关，让走网页通道的请求不进入 Recent chats，这算是对隐私的一点补救。
另一个功能是水印移除。针对 Gemini 生成的图片，扩展会去掉嵌入的元数据标记以便直接下载。README 明确说这会剥离 AI 生成内容的署名，并提醒用户注意版权影响和 Google 对生成内容使用的政策。这两项功能合起来，决定了这个扩展的定位：研究或实验用途，风险由使用者承担。
九类 provider 与它们的接入差异
项目在 services/providers 目录下放了各个 provider 驱动，代码里动态适配行为。README 的对照表列出了九类入口，但它们并非平级。
web.js 是唯一不需要 API Key 的，前提是浏览器里保持 Google 账号登录。official.js 走 Google AI Studio 的 key，支持 Thinking 和 Google Search grounding，回答里能显示网页来源。openai_compatible.js 是一个被复用了五次以上的驱动，覆盖 OpenAI 兼容接口、OpenAI 官方、DeepSeek、OpenRouter、Qwen / DashScope 和智谱 GLM，差异靠默认值和参数拼装来体现：OpenRouter 会拉取 /models 并支持 provider routing JSON 与原生 reasoning 字段，DashScope 走兼容端点并带 enable_thinking 和 VL 图像输入，GLM 用原生 thinking 开关载荷。Anthropic 单独有 anthropic.js，实现 Messages API 适配器，支持图像输入和扩展思考的流式展示。
这种设计的实际含义是：切换 provider 时你改的是 Base URL、API Key 和 Model IDs 三项配置，而不是换一套交互。但每个 provider 的搜索能力并不一致。Gemini API 用 Google Search grounding，OpenAI 兼容路径则根据当前端点选择 Responses API 的 web_search 还是 Chat Completions 的 web_search_options。这两者行为不同，README 没有说明结果如何归一化。
上下文管理靠压缩和截断，而不是无限窗口
README 提到用摘要压缩和最近轮次裁剪来控制上下文，降低超限风险。这是长对话扩展的常规做法，也意味着历史信息会被有损处理。项目没有给出压缩触发阈值或保留轮数的具体数值。
另一处限制藏在功能描述里：历史用户消息的重新编辑与从该点继续，只对 API provider 启用。Gemini Web 通道不支持这个操作，原因不难推测，网页会话的状态不在扩展手里。如果你把重新编辑当作核心用法，选 provider 时就没有多少余地。
浏览器控制部分用 Chrome 原生标签组标记被控制的任务，并让 list_pages 和 select_page 聚焦在受控范围内。侧边栏还支持按标签页限制作用范围，减少在不需要助手的页面上被打扰。这些是权限收敛的设计，但它们约束的是扩展自己的行为，不是你授予它的权限。
怎么装起来：命令和配置项
README 没有给出完整的安装命令块，仓库布局显示使用 Vite 构建，因此标准路径是先克隆仓库、安装依赖、构建产物，再通过 Chrome 的扩展管理页加载未打包扩展。具体命令请以仓库内的 package.json 脚本为准，本文无法确认脚本名称。
加载之后，配置集中在扩展的选项界面。README 明确列出的配置键有三类：Base URL、API Key、Model IDs，按 provider 分别填写。API Key 存放在 Chrome 扩展存储中，项目声明不会发送给所选提供方之外的第三方。
其余开关按功能划分：Gemini Web 的临时会话开关；Gemini API 的 Google Search grounding；OpenAI 兼容路径的 web search；侧边栏的按标签页作用范围；以及 MCP 服务器的接入配置。MCP 工具在 README 里被描述为可选的外部工具，具体配置字段没有展开。
什么时候它不该出现在你的机器上
最明确的失败模式是 Gemini Web 通道失效。它依赖从页面 HTML 里提取的三个 token 和内部 RPC 端点，Google 改动页面结构或端点签名，这条路就会断，而扩展本身无法阻止这种改动。README 对此没有给出降级方案，只说明你可以改用 API provider。
合规场景是第二个排除项。如果所在组织对服务条款、未授权访问或生成内容署名有明确要求，那么逆向 RPC 和水印移除两项功能都不该启用，剩下的价值就只有 API provider 那部分，而那一部分完全可以由更轻量的客户端替代。
第三，README 未提及任何自动化测试、CI 状态或权限清单。扩展需要读取网页内容才能提供上下文，这意味着它申请了相应的 host 权限，但仓库材料里看不到具体权限范围。在无法确认权限边界的情况下把它装进处理敏感数据的浏览器配置，是不合适的。
和直接用官方客户端的区别在哪
一个自然的替代方案是直接用 Google AI Studio 或各家官方客户端。差别在上下文来源：官方客户端拿到的是你粘贴进去的内容，Gemini Nexus 拿到的是当前页面、截图和标签页范围。如果你需要的是让模型看着你正在读的页面回答问题，官方客户端做不到，这是它存在的理由。
另一个方向是通用浏览器自动化框架。那类工具的抽象层级更低，需要你自己写脚本描述点击和取值，换来的是对流程的完全控制；Gemini Nexus 把浏览器控制封装成模型可调用的工具，用 list_pages、select_page 这样的语义操作页面，代价是你能干预的空间被限制在扩展暴露的接口内。
还有一类是纯 API 客户端。它们不碰网页会话，合规上干净，但需要你自己准备 key 并承担费用，也不具备页面上下文能力。三条路的分界线很清楚：要页面上下文就接受扩展的权限与风险，要合规可控就放弃免密钥的网页通道。
维护成本与 MIT 许可的边界
从发布节奏看，v5.2.0 到 v5.2.4 相隔两天，v5.3.0 在两周后发布，最近一次推送与最新版本同月。这说明项目处于活跃迭代期，同时也意味着配置界面和 provider 行为可能在小版本之间变动。升级前值得看一眼 release notes，尤其是涉及 provider 默认值和水印处理的部分。
MIT 许可允许你修改和再分发代码，但它不解决两件事。第一，Google 的服务条款是独立于代码许可的约束，MIT 不会因为你拿到了源码就让你获得访问 Gemini Web 的授权。第二，水印移除涉及生成内容的署名与版权，README 把责任明确交给使用者。如果你的用途需要法务确认，这份材料里没有任何可以替代法律意见的内容。
编辑结论
适合已经在用 Chrome、希望把网页上下文、截图和多个模型提供方放进同一个侧边栏的开发者或个人用户，尤其是愿意自己填 Base URL 和 API Key、接受自担风险的人。不适合把合规放在第一位的团队，也不适合需要长期稳定、可审计接口的生产系统，因为 Gemini Web 通道依赖逆向内部 RPC，随时可能失效。上手前先确认三件事：README 里那句关于 Google 服务条款的自我声明你是否接受；你打算用哪个 provider，以及它是否需要额外开启 web search 或 thinking 参数；以及扩展申请了哪些 Chrome 权限。最后一点直接决定它能读到哪些页面内容。
社区笔记