Lumos

想象一下：你正在阅读一篇几千行的 GitHub Issue 讨论帖，传统方式需要一页页滚动、反复跳转。而现在，只需打开 Lumos，向 AI 提一个问题——「这个讨论的核心争议是什么？」——AI 就会结合当前页面的内容给出精准答案。这不是科幻，而是 Lumos 正在做的事。

项目背景：隐私优先时代的浏览器 AI 助手

Lumos 是一个基于 Chrome 浏览器的 RAG（检索增强生成）AI 助手，由独立开发者 andrewnguonly 创建于 2023 年 11 月。它的核心理念与众不同：你的数据永远留在本地，不会经过任何远程服务器。

这一设计源于 Chrome 扩展平台的安全限制——扩展无法直接调用 Ollama 的 API，因此项目采用了一个巧妙的架构：在用户本地同时运行 Ollama 服务器（负责 Embedding 索引和 LLM 推理），Chrome 扩展通过 localhost:11434 与之通信。这样既绕过了安全限制，又实现了真正的隐私保护。

图 1：Lumos 扩展运行界面。用户在浏览网页时可随时唤出侧边栏，向 AI 询问当前页面内容。

核心功能：从「网页大海捞针」到「一键精准问答」

Lumos 的使用场景非常具体：当你面对大量非结构化网页内容时，它能让你像拥有一个贴身研究助手一样，快速提取关键信息。

典型使用场景包括：

• 论坛/Issue 讨论摘要：GitHub Issues、论坛帖子、社交媒体长帖，可以一键生成摘要，节省数小时阅读时间
• 新闻文章摘要：快速了解长篇新闻的核心要点
• 产品评论分析：提取电商页面中用户评论的关键信息和情感倾向
• 技术文档问答：对 OpenAPI 文档、API Reference 等长文档直接提问
• 本地文档解析：支持上传 PDF、CSV、JSON 文件作为上下文

多模态支持是 Lumos 的一大亮点。通过 llava、bakllava、moondream 等视觉模型，用户可以直接向 AI 展示截图并提问，例如「这个错误信息是什么意思？」或「这张架构图描述的是哪个组件？」。

技术架构：LangChain.js 驱动的 RAG Pipeline

Lumos 的技术栈选择非常务实，核心依赖包括：

| 技术 | 用途 | 版本 |

|------|------|------|

| TypeScript + React 18 | Chrome 扩展前端界面 | 4.9.5 / 18.2.0 |

| LangChain.js (0.1.21) | RAG Pipeline 编排 | 核心框架 |

| @xenova/transformers | 浏览器端 Transformer 模型 | 2.8.0 |

| Ollama (本地) | LLM 推理 + Embedding | — |

| Webpack 5 | 打包工具 | 5.89.0 |

| ChatScope UI Kit | 聊天界面组件 | 1.10.1 |

| MUI (Material UI) | UI 组件库 | 5.15.11 |

RAG 工作流程分为以下几个阶段：

1. 内容抓取：content.ts 脚本在当前页面执行，通过 fetch() API 获取 DOM 中的文本内容，注入到后台脚本
2. 文档分块：使用 RecursiveCharacterTextSplitter 按字符数分块（默认 1000 字符），保证语义完整性
3. 向量索引：使用 Ollama Embedding 模型（如 nomic-embed-text）生成向量，存入增强版 MemoryVectorStore
4. 混合检索：EnhancedMemoryRetriever 支持三种检索模式——相似度检索（similarity）、关键词检索（keyword，基于 Fuse.js）、混合检索（hybrid），还支持 MMR（最大边际相关）策略
5. LLM 生成：将检索到的上下文片段注入 System Prompt，调用 Ollama LLM（如 llama2）流式返回结果

自定义工具系统值得单独一提。tools/calculator.ts 实现了一个纯 JavaScript 的算术表达式计算器工具，通过 LangChain 的 Tool 接口注册。当用户输入包含数字运算时（如「2025 年比 2024 年增长了多少？」），系统会先调用计算器处理数值，再将结果注入 LLM 上下文——这避免了 LLM 直接做数学运算的错误率问题。

多模态图像处理：当检测到用户上传图片时（支持 jpeg/jpg/png），CodeBlock 组件将图片转为 Base64，注入 ChatBar.tsx 的 Attachment 对象，最终作为多模态消息内容传给 Ollama 的 /api/chat 端点。

部署体验：零服务器依赖，但有前置门槛

Lumos 的部署难度中等偏低，但存在一个前置条件：用户必须自行安装和配置 Ollama。

部署步骤（5–10 分钟）：

1. 安装 Ollama：访问 ollama.ai 下载安装包
2. 拉取模型：ollama pull llama2（或 ollama pull nomic-embed-text 用于 Embedding）
3. 以特殊参数启动 Ollama：OLLAMA_ORIGINS=chrome-extension://* ollama serve
4. 加载 Chrome 扩展：打开 chrome://extensions，开启开发者模式，加载 dist 或源码目录
5. 配置扩展：在扩展设置页面填入 Ollama 地址和模型名称，验证连接

需要注意的坑：Chrome 扩展的平台安全策略限制了扩展直接与 localhost 通信的能力（Manifest V3 限制了 xmlHttpRequest），所以 Ollama 服务必须配置 OLLAMA_ORIGINS=chrome-extension://* 才能被扩展正常访问。此外，默认端口是 11434，如果本机端口被占用需要手动修改。

硬件需求：由于 Ollama 在本地运行推理，CPU 推理可以工作，但速度较慢；推荐使用有 GPU（至少 4GB 显存）的机器。扩展本身的内存占用极小（< 50MB）。

代码质量评估

从源码来看，Lumos 的代码质量相当不错：

• TypeScript 严格模式：启用 strict: true，所有函数都有完整类型注解，LumosOptions 等核心接口定义清晰
• 模块化设计：各功能模块职责分明——vectorstores/ 处理检索逻辑、tools/ 处理工具扩展、document_loaders/ 处理文件解析
• 测试覆盖：配置了 Jest 测试框架（jest.config.js），有 __tests__/ 目录
• ESLint + Prettier：完整的代码规范配置，lint 脚本在 CI 中自动运行
• 文档完整：README 详细覆盖了安装步骤、Ollama 配置、多模态模型使用说明

不过也有一些值得注意的地方：background.ts 中直接使用全局变量（context、attachments、completion、controller）管理状态，在高并发场景下可能存在状态污染风险；options.tsx 的 UI 组件嵌套较深，部分代码行数偏长（超过 300 行），后期维护时建议做组件拆分。

局限与争议

Lumos 并非完美，以下几个问题值得关注：

• Ollama 版本依赖：项目依赖特定版本的 Ollama API，新版本 Ollama 的接口变动可能导致功能失效
• 内存型向量存储瓶颈：EnhancedMemoryVectorStore 基于 MemoryVectorStore，所有向量存储在内存中，每次扩展重启后索引丢失。对于频繁使用的用户，这意味着每次都要重新 Embedding 整个页面
• 非开发者不友好：纯 CLI + Chrome 扩展的组合，对非技术用户有较高门槛。没有 Web UI 版本，无法在服务器上部署供团队共享使用
• 检索精度依赖 Embedding 模型：nomic-embed-text 在中文场景下的表现一般，中文网页的问答效果可能不如英文

行业意义：让本地 AI 真正「看见」你的工作

Lumos 出现在 2023 年底，正值 Web LLM 和本地推理技术快速成熟的时间节点。它的最大贡献不在于技术突破，而在于思路创新——将 RAG 的应用场景从服务器端扩展到了浏览器端，让 AI 真正「活」在用户的工作流里。

随着 Ollama 生态的壮大和 Chrome 扩展Manifest V3 的逐步稳定，这类本地 AI 浏览器助手的使用体验正在持续改善。Lumos 的作者也在持续维护（最新版本 1.0.17），如果你关心隐私、喜欢折腾、或者对 LangChain.js 的实际应用感兴趣，Lumos 是一个值得深入研究的优质开源项目。