on-device-browser-agent · 智能体框架与编排

浏览器里的 AI 代理：让网页自动化在本地跑起来

一个真实的场景

深夜，你正在整理一份市场调研报告，需要从亚马逊上收集十几款同类产品的价格和评分。手动一个个打开页面、复制粘贴——这是标准操作，但重复 15 次之后，手指已经开始抗议了。如果有一个 AI 能帮你做这件事，而且全程不需要你的 API Key、不需要把任何数据发送到云端、所有推理都在你自己的电脑上完成——听起来像科幻？但这已经是现实了。

Local Browser（RunanywhereAI/on-device-browser-agent）就是这样一个工具：它是一个 Chrome 浏览器扩展，通过 WebLLM 在本地运行大语言模型，结合多 Agent 协作架构，让 AI 直接"驾驶"你的浏览器完成网页任务。数据永远留在本地，隐私零风险。

RunanywhereAI 组织头像 图1：RunanywhereAI 官方头像

项目背景与起源

RunanywhereAI 是一个专注于端侧 AI 工具开发的团队，旗下的 on-device-browser-agent 项目诞生于 2026 年 1 月，定位为浏览器内 AI 自动化 Chrome 扩展。项目的核心理念非常明确：打破"AI 必须上云"的思维定式，利用 WebGPU 加速的 WebLLM 技术，在浏览器沙箱内完成完整的 LLM 推理链路。

这个方向并非凭空出现。项目在 README 中明确致敬了两个前辈：

Nanobrowser：多 Agent 网页自动化框架，提供了 Planner + Navigator 双 Agent 协作的执行范式
WebLLM（MLC-AI）：在浏览器内运行 LLM 的基础设施，支持 WebGPU 硬件加速

Local Browser 将两者结合：以 Nanobrowser 的 Agent 架构为骨架，以 WebLLM 为推理引擎，打包成一个随手可装的 Chrome 扩展。截至 2026 年 6 月，项目已获得约 300 颗 GitHub Stars，属于早期但活跃的概念验证项目。

核心功能：本地 AI 驾驶浏览器

双 Agent 执行引擎

项目采用Planner-Navigator 双 Agent 架构，这是整套系统的"大脑"：

Planner Agent：接收用户的高级任务描述（如"在亚马逊上找一款评分最高的纸巾并加入购物车"），将其拆解为 3-6 步的中级行动计划，同时维护执行上下文中的记忆（memory），确保长流程不偏离目标。
Navigator Agent：负责战术级决策。它接收当前页面的 DOM 状态（序列化后的交互元素和页面文本），判断应该执行哪种具体操作——是点击按钮、输入文字、滚动页面，还是宣布任务完成。Navigator 的特别之处在于：它先用规则引擎做兜底（处理亚马逊、YouTube、Twitter 等主流站点的常见交互模式），LLM 仅在规则无法覆盖时介入。这种"小模型+规则"的混合策略让 Navigator 在资源受限的端侧环境中依然可靠。

Agent 的输出是结构化 JSON，定义了 action_type（navigate/click/type/press_enter/extract/scroll/wait/done/fail）和对应的参数，由 Executor 统一调度执行。

WebLLM 推理引擎

项目支持多种本地 LLM 模型，默认使用 Qwen2.5-3B-Instruct-q4f16_1-MLC（量化版本，约 2GB），在 Q4 量化精度下平衡了模型质量与推理速度。用户也可以切换到更轻量的 Qwen2.5-1.5B（约 1GB）或 Llama-3.2-1B（约 0.6GB），或者更重但推理能力更强的 Phi-3.5-mini（约 2.2GB）。

WebLLM 模型首次运行时从 HuggingFace 下载（需要访问 huggingface.co 和 cdn-lfs.huggingface.co），之后缓存在本地，下次启动无需重新下载。

视觉模式（Vision Mode）

项目已实现实验性视觉模式，支持 SmolVLM 系列模型（256M/500M/2B），让 AI 能"看"页面截图而非仅解析文本 DOM。这大大增强了 AI 对复杂页面的理解能力——弹窗、验证码、动态加载的内容，不再只能靠猜测。

内容脚本与 DOM 序列化

Content Script 负责两件事：一是通过 DOM Observer 将当前页面状态序列化为 Navigator 可消费的 JSON 结构（提取交互元素、页面文本、URL）；二是通过 Action Executor 执行 Navigator 输出的具体操作（点击、输入、滚动等）。项目还内置了 Cookie 弹窗和模态框的自动关闭逻辑，减少 AI 执行的阻断。

亚马逊专项优化

项目代码中包含大量亚马逊站点的专项适配：识别登录状态、购物车计数、商品页和搜索结果页的差异、CAPTCHA 检测等。这说明开发者对主流电商场景有深度思考，而非泛泛的"通用浏览器自动化"。

部署体验：需要一点耐心

安装流程（不复杂，但有门槛）

项目不是"一键安装"的 Docker 容器，而是需要手动编译的 Chrome 扩展。标准流程：

git clone 克隆仓库
npm install 安装依赖（@huggingface/transformers、@mlc-ai/web-llm、React 等）
npm run build 构建扩展
打开 chrome://extensions，开启开发者模式，点击"加载已解压的扩展"，选择 dist 目录

整个过程在网络畅通的情况下约 10-15 分钟。最大的时间消耗是首次下载 LLM 模型（1-2GB）。

环境依赖

Chrome 124+：项目使用了 WebGPU 在 Service Worker 中的能力，这是 Chrome 124 才稳定支持的特性。旧版 Chrome 用户需要先升级。
WebGPU 支持：大多数现代显卡（Intel UHD 600+、AMD RX 400+、NVIDIA GTX 900+）的浏览器都支持 WebGPU，但某些 Linux 用户或 macOS 用户可能需要在 chrome://gpu 中检查状态。
Node.js 18+：标准前端开发工具链要求。

为什么不是"快速部署"？

Dockerfile？不存在的。docker-compose？也没有。这是一个纯前端 Chrome 扩展项目，不适合容器化部署。其价值在于"触手可及"——装好之后，在任何网页上都能调用 AI 自动化，这正是本地工具的优势：没有网络延迟、没有 API 限流、没有数据泄露风险。

技术架构：TypeScript + React + WebLLM

项目的技术选型非常务实：

TypeScript：全项目强类型，从 Agent 的输入输出 schema 到 Content Script 的 DOM 类型定义，类型覆盖完整。src/shared/types.ts 定义了所有核心类型。
React 18：Popup UI（用户输入任务、查看执行状态的界面）用 React 构建，与 Vite 生态完美契合。
Vite 5 + @crxjs/vite-plugin：专门为 Chrome 扩展设计的构建流水线，支持 HMR 开发模式。
@mlc-ai/web-llm：WebLLM 的官方 JS SDK，处理模型加载和推理。
@huggingface/transformers：备选推理引擎（Transformers.js），支持 LiquidAI LFM2.1 等 32K 上下文的模型。
Chrome Extension Manifest V3：采用最新的 Chrome 扩展架构，Service Worker 作为后台进程。

代码结构遵循清晰的模块化设计：background/ 处理 Service Worker 中的 LLM 推理和 Agent 协调，content/ 处理 DOM 观测和操作执行，popup/ 处理 UI 渲染，shared/ 集中管理类型和常量。这种分离让各模块职责明确，也便于后续扩展视觉模式等新功能。

当前局限：POC 的诚实告白

项目 README 用整整一节坦诚地列出了当前局限：

纯文本 DOM 分析：没有视觉理解能力（视觉模式是实验性的），AI 只能看到 DOM 树，无法"看到"页面的实际渲染效果
仅支持当前活动标签：不支持跨标签页协作
支持的浏览器操作有限：navigate、click、type、extract、scroll、wait
复杂任务可能失败：小模型在复杂推理场景下能力有限
某些页面无法注入：如 chrome:// 页面

这些限制反映了一个真实的 POC 状态：项目的核心价值——本地运行、隐私保护、端侧 LLM——已经实现得很好，但距离真正替代商业化的 AI 浏览器产品还有距离。

行业意义与未来展望

on-device-browser-agent 代表了一个重要趋势：AI 推理正在从云端向边缘下沉。WebLLM 证明了在消费级浏览器中运行 1-3B 量级的大模型是可行的；Local Browser 则进一步探索了"端侧 LLM + 浏览器自动化"的应用场景。

类似的探索在 2026 年已经形成一个小生态：Nanobrowser、BrowserGym、OpenAI 的 Browser Use 等项目都在从不同角度解决"让 AI 操作网页"的问题。Local Browser 的差异化在于隐私优先——所有数据不离开用户设备，这对于企业级数据安全场景和重视隐私的个人用户有独特吸引力。

随着 WebGPU 普及和端侧模型效率持续提升，这种"浏览器内 AI Agent"的形态可能会成为未来人机交互的一种重要范式。

快速上手

# 克隆仓库
git clone https://github.com/RunanywhereAI/on-device-browser-agent
cd on-device-browser-agent

# 安装依赖
npm install

# 构建扩展
npm run build

# 在 Chrome 中加载 dist 目录
# chrome://extensions → 开发者模式 → 加载已解压的扩展 → 选择 dist

首次使用：点击扩展图标 → 输入任务（如"在维基百科搜索 WebGPU 并提取第一段"）→ 观看 AI 分步执行。

浏览器里的 AI 代理：让网页自动化在本地跑起来

一个真实的场景

RunanywhereAI 组织头像 图1：RunanywhereAI 官方头像

项目背景与起源

这个方向并非凭空出现。项目在 README 中明确致敬了两个前辈：

Nanobrowser：多 Agent 网页自动化框架，提供了 Planner + Navigator 双 Agent 协作的执行范式
WebLLM（MLC-AI）：在浏览器内运行 LLM 的基础设施，支持 WebGPU 硬件加速

核心功能：本地 AI 驾驶浏览器

双 Agent 执行引擎

项目采用Planner-Navigator 双 Agent 架构，这是整套系统的"大脑"：

Planner Agent：接收用户的高级任务描述（如"在亚马逊上找一款评分最高的纸巾并加入购物车"），将其拆解为 3-6 步的中级行动计划，同时维护执行上下文中的记忆（memory），确保长流程不偏离目标。
Navigator Agent：负责战术级决策。它接收当前页面的 DOM 状态（序列化后的交互元素和页面文本），判断应该执行哪种具体操作——是点击按钮、输入文字、滚动页面，还是宣布任务完成。Navigator 的特别之处在于：它先用规则引擎做兜底（处理亚马逊、YouTube、Twitter 等主流站点的常见交互模式），LLM 仅在规则无法覆盖时介入。这种"小模型+规则"的混合策略让 Navigator 在资源受限的端侧环境中依然可靠。

Agent 的输出是结构化 JSON，定义了 action_type（navigate/click/type/press_enter/extract/scroll/wait/done/fail）和对应的参数，由 Executor 统一调度执行。

WebLLM 推理引擎

WebLLM 模型首次运行时从 HuggingFace 下载（需要访问 huggingface.co 和 cdn-lfs.huggingface.co），之后缓存在本地，下次启动无需重新下载。

视觉模式（Vision Mode）

内容脚本与 DOM 序列化

亚马逊专项优化

部署体验：需要一点耐心

安装流程（不复杂，但有门槛）

项目不是"一键安装"的 Docker 容器，而是需要手动编译的 Chrome 扩展。标准流程：

git clone 克隆仓库
npm install 安装依赖（@huggingface/transformers、@mlc-ai/web-llm、React 等）
npm run build 构建扩展
打开 chrome://extensions，开启开发者模式，点击"加载已解压的扩展"，选择 dist 目录

整个过程在网络畅通的情况下约 10-15 分钟。最大的时间消耗是首次下载 LLM 模型（1-2GB）。

环境依赖

Chrome 124+：项目使用了 WebGPU 在 Service Worker 中的能力，这是 Chrome 124 才稳定支持的特性。旧版 Chrome 用户需要先升级。
WebGPU 支持：大多数现代显卡（Intel UHD 600+、AMD RX 400+、NVIDIA GTX 900+）的浏览器都支持 WebGPU，但某些 Linux 用户或 macOS 用户可能需要在 chrome://gpu 中检查状态。
Node.js 18+：标准前端开发工具链要求。

为什么不是"快速部署"？

技术架构：TypeScript + React + WebLLM

项目的技术选型非常务实：

TypeScript：全项目强类型，从 Agent 的输入输出 schema 到 Content Script 的 DOM 类型定义，类型覆盖完整。src/shared/types.ts 定义了所有核心类型。
React 18：Popup UI（用户输入任务、查看执行状态的界面）用 React 构建，与 Vite 生态完美契合。
Vite 5 + @crxjs/vite-plugin：专门为 Chrome 扩展设计的构建流水线，支持 HMR 开发模式。
@mlc-ai/web-llm：WebLLM 的官方 JS SDK，处理模型加载和推理。
@huggingface/transformers：备选推理引擎（Transformers.js），支持 LiquidAI LFM2.1 等 32K 上下文的模型。
Chrome Extension Manifest V3：采用最新的 Chrome 扩展架构，Service Worker 作为后台进程。

当前局限：POC 的诚实告白

项目 README 用整整一节坦诚地列出了当前局限：

纯文本 DOM 分析：没有视觉理解能力（视觉模式是实验性的），AI 只能看到 DOM 树，无法"看到"页面的实际渲染效果
仅支持当前活动标签：不支持跨标签页协作
支持的浏览器操作有限：navigate、click、type、extract、scroll、wait
复杂任务可能失败：小模型在复杂推理场景下能力有限
某些页面无法注入：如 chrome:// 页面

行业意义与未来展望

随着 WebGPU 普及和端侧模型效率持续提升，这种"浏览器内 AI Agent"的形态可能会成为未来人机交互的一种重要范式。

快速上手

# 克隆仓库
git clone https://github.com/RunanywhereAI/on-device-browser-agent
cd on-device-browser-agent

# 安装依赖
npm install

# 构建扩展
npm run build

# 在 Chrome 中加载 dist 目录
# chrome://extensions → 开发者模式 → 加载已解压的扩展 → 选择 dist

首次使用：点击扩展图标 → 输入任务（如"在维基百科搜索 WebGPU 并提取第一段"）→ 观看 AI 分步执行。