【Nanobrowser源码分析2】架构篇：探究 Nanobrowser 的核心组件与通信模型-洪萨配资

欢迎来到《Nanobrowser 源码分析》系列的第二篇文章。在上一篇中，我们对 Nanobrowser 的基本功能和安装进行了快速上手。今天，我们将深入底层，剖析其多智能体（Multi-Agent）架构与通信模型。

作为一款开源的 AI 浏览器自动化工具，Nanobrowser 的精妙之处在于它并非简单的“提示词转发器”，而是一个运行在浏览器侧边栏中的微型操作系统。

Nanobrowser 采用了典型的Chrome Extension V3架构，并在此基础上构建了一套复杂的智能体协作逻辑。其核心设计哲学是Local-first（本地优先）：所有的逻辑调度、状态管理和 DOM 操作都在用户的本地浏览器中完成。

从逻辑上看，Nanobrowser 可以分为以下三层：

Nanobrowser 的核心竞争力在于其Planner-Navigator-Validator（规划者-执行者-验证者）模型。这种分工避免了单个 LLM 调用在处理复杂长链路任务时的“幻觉”和失控。

职责：任务分解。
逻辑：当用户输入“在京东搜索并购买最便宜的机械键盘”时，Planner 会将其拆解为：1. 导航至京东；2. 搜索关键词；3. 筛选并排序；4. 识别目标商品并点击。

职责：环境感知与动作执行。
逻辑：它是唯一直接与网页结构打交道的智能体。它会获取当前页面的Accessibility Tree (无障碍树)简化信息，决定点击哪个选择器（Selector）。

职责：质量控制。
逻辑：在每个关键动作结束后，Validator 会检查当前页面状态是否符合预期（例如：登录是否成功？搜索结果是否加载？）。如果失败，它会触发重试或反馈给 Planner 调整策略。

由于 Chrome 扩展的沙箱机制，Sidebar（侧边栏）、Background Service Worker（后台脚本）和 Content Script（页面脚本）运行在不同的环境中。Nanobrowser 构建了一套高效的通信链路。

Nanobrowser 使用chrome.runtimeAPI 进行跨环境协作：

LLM API：Nanobrowser 支持 OpenAI、Claude、Gemini 以及通过 Ollama 运行的本地模型。它通过标准的 HTTPS 请求与这些 API 通信，关键的System Prompt会在 Background 阶段完成组装。
MCP (Model Context Protocol)：Nanobrowser 正在引入 MCP 支持，这允许 Agent 调用外部工具（如本地文件读写、数据库查询），将浏览器自动化的边界扩展到操作系统层面。

一个典型的自动化循环如下：

感知 (Observe)：Content Script 提取当前页面的 DOM/无障碍树，并进行“瘦身”处理（减少 Token 消耗）。
决策 (Think)：调度层将页面信息 + 用户目标发送给 Navigator。
行动 (Act)：Navigator 生成特定指令（如click("#buy-btn")），通过消息总线发送至 Content Script 执行。
校验 (Validate)：Validator 观察行动后的页面变化，决定进入下一步还是重试。