Nanobrowser 入门：免费替代 OpenAI Operator 的多智能体网页自动化

引言：AI 浏览器代理的两条路

2024 年底以来，AI 浏览器代理（AI Browser Agent）迅速成为自动化领域最热门的方向。OpenAI 推出的 Operator 展示了「用自然语言控制浏览器」的能力，但每月 200 美元的订阅价让很多个人开发者和中小企业望而却步。

另一个方向藏在细节里：当你把浏览器的控制权交给 AI 时，你的 Cookie、浏览历史、登录状态如何处理？发送给云端服务的 DOM 数据会不会泄露敏感信息？

Nanobrowser 在这两个问题上给出了清晰的回答——完全开源、本地优先、零订阅费，同时用多智能体架构（Multi-Agent System）实现了媲美商业产品的自动化能力。

本文从工程实现角度深度剖析 Nanobrowser 的架构设计，并附带完整的安装、配置和实战示例。

架构深度解析：Planner → Navigator → Validator

Nanobrowser 的核心架构由三种专业化智能体角色组成，它们协作完成从自然语言指令到浏览器操作的完整链路。

Planner（规划者）

Planner 是系统的大脑。接收用户的高级指令后，将其分解为有序的子任务序列。

用户输入 → Planner → [子任务 1, 子任务 2, 子任务 3, ...]

示例：当用户说「在 example.16yun.cn 上找一款防水蓝牙音箱，价格 50 美元以下」，Planner 会生成：

打开 example.16yun.cn
在搜索框输入 "waterproof bluetooth speaker"
筛选价格低于 $50
逐个查看搜索结果，提取续航信息
返回符合条件的商品列表

Planner 承担了核心的推理任务，因此通常需要使用较强的模型。

Navigator（导航者）

Navigator 是执行引擎。它将 Planner 分解好的子任务逐一转化为具体的 DOM 交互操作——点击按钮、填写表单、滚动页面、读取文本。

Navigator 不负责高层规划，只负责「怎么执行」。这种职责分离使系统能更精确地控制每次模型调用的上下文窗口使用量。

Validator（验证器 / 自我纠错）

这是 Nanobrowser 最具工程价值的机制。当 Navigator 执行某个操作后，Validator 会检查预期状态是否到达。如果页面弹出意外的模态框、元素被隐藏、或操作未产生预期结果，验证器会触发 Planner 重新评估当前状态并调整策略。

Navigator 操作 → Validator 验证 ✓ → 继续下一步
Navigator 操作 → Validator 验证 ✗ → Planner 重新规划 → Navigator 调整执行

这种闭环反馈机制显著提高了任务完成的成功率，尤其是在面对动态页面、A/B 测试或意外弹窗时。

通信流程

用户指令
    │
    ▼
┌─────────────┐
│   Planner    │  ← 读取 DOM + 当前状态
│  (规划者)    │    输出：子任务列表
└──────┬──────┘
       │
       ▼
┌─────────────┐
│  Navigator  │  ← 执行具体交互
│  (导航者)    │    输出：操作结果
└──────┬──────┘
       │
       ▼
┌─────────────┐
│  Validator  │  ← 验证结果
│  (验证器)    │    输出：成功 / 失败
└──────┬──────┘
       │
   失败/阻塞
       │
       └──────→ Planner 重新规划

安装与配置

安装扩展

Nanobrowser 是一个标准 Chrome 扩展，在 Chrome Web Store 免费上架。

方式一：Chrome Web Store 安装（稳定版）

访问 Chrome Web Store，搜索 "Nanobrowser" 即可找到。但 Web Store 审核流程可能导致版本落后。

方式二：手动安装最新版（推荐）

# 1. 从项目 GitHub Releases 页面下载最新版 nanobrowser.zip
 
# 2. 解压
unzip nanobrowser.zip
 
# 3. 在 Chrome 中加载
# 打开 chrome://extensions/
# 开启「开发者模式」
# 点击「加载已解压的扩展程序」
# 选择解压后的文件夹

方式三：从源码构建

git clone <nanobrowser-repository-url>
cd nanobrowser
pnpm install
pnpm build
# 构建产物在 dist/ 目录
# 在 chrome://extensions/ 中加载 dist 文件夹

配置 LLM 模型

安装完成后，点击工具栏的 Nanobrowser 图标打开侧边栏，点击右上角的设置图标，添加你的 API Key。

Nanobrowser 允许为不同智能体角色配置不同的模型：

角色	推荐模型	原因
Planner	Claude Sonnet 4 / GPT-4o	需要强推理能力拆解任务
Navigator	Claude Haiku 3.5 / Gemini 2.5 Flash	执行任务，速度优先
Validator	同 Navigator 模型	验证逻辑较简单，同模型即可

支持的提供商包括：OpenAI、Anthropic、Gemini、Groq、Cerebras、Ollama（本地模型）以及任何兼容 OpenAI 接口的自定义提供商。

模型搭配指南

合理选择模型组合可以平衡成本和性能。

高性能配置

角色	模型	单次调用估算成本	适用场景
Planner	Claude Sonnet 4	中等	复杂多步骤任务
Navigator	Claude Haiku 3.5	低	快速执行
Validator	Claude Haiku 3.5	低	验证检查

这种配置适合银行开户、电商比价、数据分析等对准确性要求高的任务。

性价比配置

角色	模型	单次调用估算成本	适用场景
Planner	GPT-4o / Gemini 2.5 Pro	中低	日常自动化
Navigator	Gemini 2.5 Flash	极低	简单交互
Validator	Gemini 2.5 Flash	极低	基本验证

适合日常表单填充、信息采集等中等复杂度任务。

本地模型配置

如果对数据隐私有严格需求，可以使用 Ollama 运行本地模型：

# 启动 Ollama
ollama pull qwen3-30b-a3b-instruct
ollama serve
 
# 在 Nanobrowser 设置中添加自定义 OpenAI 兼容提供商
# API URL: http://localhost:11434/v1

本地模型成本为零，但推理速度较慢。适合不要求实时响应的批量任务。

实战示例：跨站数据采集

以下是一个典型的多步骤数据采集任务，展示 Nanobrowser 如何协作完成。

任务：搜索商品并对比价格

在 Nanobrowser 侧边栏输入以下指令：

在 example.16yun.cn 搜索 "portable bluetooth speaker waterproof"，
列出前 5 个结果的产品名称、价格和评分。

执行过程如下：

[Planner] 分析指令，生成子任务序列：
  1. 打开 example.16yun.cn
  2. 在搜索框输入关键词
  3. 等待搜索结果加载
  4. 提取前 5 条结果的信息
  5. 整理为结构化列表
 
[Navigator] 执行步骤 1：
  → 导航到 https://www.example.16yun.cn
  → 等待页面加载
 
[Navigator] 执行步骤 2：
  → 定位搜索框
  → 输入 "portable bluetooth speaker waterproof"
  → 按 Enter
 
[Navigator] 执行步骤 3：
  → 等待搜索结果渲染
 
[Validator] 验证：
  → 检查搜索结果是否存在
  → 确认页面已加载完成
 
[Navigator] 执行步骤 4：
  → 提取前 5 个结果卡片
  → 从每个卡片提取名称、价格、评分
 
[Planner] 汇总输出：
  → 格式化为结构化列表返回给用户

任务：多步骤表单提交

帮我完成以下操作：
1. 打开 example.16yun.cn/register
2. 填写注册表单
3. 提交

Nanobrowser 会识别表单字段（邮箱、密码、确认密码等），依次填写并提交。如果表单有错误提示（如密码格式不符），Validator 会发现状态异常，Planner 会自动调整策略——例如滚动页面查看错误提示文本，然后重新填表。

安全与隐私设计

Nanobrowser 在隐私保护上的设计值得关注：

数据本地化：所有 DOM 数据和用户指令直接发送到你配置的 LLM API，不经过 Nanobrowser 的中间服务器
无订阅追踪：扩展本身不收集遥测数据
自选模型：你可以选择 Anthropic、OpenAI 或本地运行 Ollama，数据流向完全由你控制
防护机制：内置守卫（Guardrails）过滤敏感操作，防止提示注入攻击

这与 Operator 将 DOM 发送到 OpenAI 云服务处理的模式有本质区别。

使用代理

Nanobrowser 是浏览器扩展，运行在用户的真实浏览器环境中。如果需要在采集场景中切换出口 IP，可以通过 Chrome 本身的代理设置或系统环境变量实现。

方式一：Chrome 启动参数指定代理

google-chrome --proxy-server=http://user:pass@proxy.16yun.cn:8888

方式二：使用代理扩展配合

对于需要频繁切换代理的场景，可以在 Chrome 中安装代理管理扩展（如 SwitchyOmega），配置 16YUN 爬虫代理（隧道代理）的规则。Nanobrowser 作为扩展运行在同一浏览器环境中，自动继承代理配置。

方式三：系统级代理

# macOS/Linux
export HTTP_PROXY=http://user:pass@proxy.16yun.cn:8888
export HTTPS_PROXY=http://user:pass@proxy.16yun.cn:8888
google-chrome

场景	推荐方案	说明
临时切换出口	Chrome 启动参数	适合一次性采集任务
多站点轮换	代理管理扩展 + 爬虫代理	自动切换，兼容 Nanobrowser
固定出口长期任务	独享代理	稳定身份，适合登录态任务

局限性分析与选型建议

Nanobrowser 并非万能工具，在以下场景存在明显限制：

限制维度	说明	替代方案
运行环境	必须运行在图形化桌面浏览器中	无头场景选 Steel / agent-browser
并发能力	单浏览器实例，不支持大规模并发	高并发选 Steel / Camoufox 集群
浏览器支持	仅 Chrome 和 Edge，不支持 Firefox/Safari	跨浏览器选 Playwright 直接调用
模型依赖	需要用户自备 API Key	不想管理 Key 选 Browy（Copilot 订阅）
执行速度	每个步骤需 LLM 推理，比脚本慢	确定性任务用 Puppeteer 更合适

选型建议：

个人日常自动化（填表、比价、信息提取）→ Nanobrowser
需要大规模并发数据采集 → Steel / 爬虫代理
需要绕过高级反爬检测 → Camoufox
零额外成本方案 → Browy（利用现有 Copilot 订阅）
企业级生产部署 → agent-browser + 16YUN 代理

总结

Nanobrowser 代表了一类新兴工具的方向：将 AI 智能体直接嵌入用户已有的浏览器环境，利用多智能体协作完成复杂的网页交互任务。它的核心优势——零订阅费、数据本地化、灵活的模型配置——使其成为 OpenAI Operator 的有力平替。

但更重要的是，Nanobrowser 的架构设计展示了 AI 浏览器代理的工程范式：不再依赖脆弱的 CSS 选择器和 DOM 路径，而是通过 Planner 的推理能力、Navigator 的执行能力和 Validator 的纠错能力，构建了一个对环境变化有弹性的自动化系统。

下一篇文章将介绍 Browy——另一款 Chrome 扩展，但它通过 GitHub Copilot 订阅实现了零边际推理成本这一独特的模式创新。