# 使用 Nanobrowser Chrome 扩展构建多代理浏览器自动化 > 基于开源 Nanobrowser，探讨 Chrome 扩展中多代理任务编排、DOM 交互与容错导航的工程实践，提供可落地参数与监控要点。 ## 元数据 - 路径: /posts/2025/09/17/building-multi-agent-browser-automation-chrome-extension-nanobrowser/ - 发布时间: 2025-09-17T20:46:50+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 站点: https://blog.hotdry.top ## 正文 在 AI 驱动的网页自动化领域，浏览器扩展已成为一种高效、隐私友好的实现方式。不同于云端代理工具，本地运行的 Chrome 扩展可以直接访问 DOM 结构，利用本地 LLM API 实现多代理协作，避免数据外泄风险。开源项目 Nanobrowser 正是此类工具的典范，它通过 Planner 和 Navigator 等代理，处理复杂任务如新闻汇总、GitHub 研究或电商搜索。本文聚焦于构建类似扩展的核心技术点：任务编排、DOM 交互机制及容错导航策略，提供工程化参数和落地清单，帮助开发者快速上手。 ### 多代理任务编排：从指令到执行流程 多代理系统的核心在于任务分解与协作。Nanobrowser 采用 Planner 代理负责高层规划，Navigator 代理执行具体操作。这种分工类似于 LangChain 中的工具链，但嵌入浏览器环境，更注重实时反馈。 任务编排的起点是用户输入的自然语言指令，例如“访问 TechCrunch，提取过去 24 小时的 Top 10 头条”。Planner 使用 LLM（如 Claude Sonnet）分析指令，生成结构化计划：步骤包括 URL 导航、元素定位、数据提取。计划以 JSON 格式输出，包含动作序列，如 { "action": "navigate", "url": "https://techcrunch.com", "params": { "wait": 2000 } }。 在扩展实现中，Service Worker 充当中央调度器。使用 chrome.runtime API 监听消息，Planner 的输出通过 content script 传递给 Navigator。编排参数建议： - **最大迭代次数**：5–10 次，避免无限循环。超过阈值时，回滚到用户确认。 - **代理模型分配**：Planner 用高推理模型（如 GPT-4o），Navigator 用轻量模型（如 GPT-4o-mini），平衡成本与速度。本地 Ollama 时，优先 Qwen2.5-14B 以支持长上下文。 - **上下文窗口**：限制在 8K–16K tokens，包含页面快照和历史步骤，防止幻觉。 落地清单： 1. 在 manifest.json 中声明 "background": { "service_worker": "background.js" } 和 permissions: ["activeTab", "storage"]。 2. 实现 Planner 函数：prompt = "分解任务为原子步骤，确保每个步骤可观测。" 使用 fetch 调用 LLM API。 3. 存储计划在 chrome.storage.local，键为 taskId，支持断点续传。 这种编排确保了任务的模块化，便于调试复杂流程如多页爬取。 ### DOM 交互：精确定位与操作 浏览器自动化离不开 DOM 操作。Nanobrowser 的 Navigator 代理通过 content script 注入 JavaScript，直接操纵页面元素，实现点击、输入、滚动等动作。相较 Puppeteer 的 headless 模式，扩展方式更贴近真实用户行为，绕过部分反爬机制。 核心交互使用 chrome.scripting API（Manifest V3）。例如，定位头条元素：querySelectorAll('article h2')，提取 textContent。Navigator 的 prompt 强调语义描述：“找到水抵抗蓝牙音箱，价格低于 50 美元，电池续航 10 小时以上。” LLM 生成 CSS 选择器或 XPath，如 'div.product-card:has(span.price:under($50))'。 工程参数： - **等待策略**：动态等待，使用 MutationObserver 监听 DOM 变化，默认超时 5–10 秒。针对异步加载，设置 retry_interval: 500ms，max_retries: 3。 - **元素交互阈值**：点击前验证元素可见性（getBoundingClientRect().height > 0），输入时模拟 keydown 事件以防表单验证。 - **数据提取格式**：统一为 Markdown 或 JSON，包含元数据如 timestamp、url。限制提取量 < 10KB，避免性能瓶颈。 在 Amazon 搜索示例中，Navigator 先导航到搜索页，注入 script 执行 document.querySelectorAll('.s-result-item')，过滤条件后汇总结果。监控点：使用 chrome.devtools.network 记录 API 调用，检测异常如 403 错误。 落地清单： 1. Content script: "matches": [""]，注入 navigator.js。 2. 定义交互工具集：click(selector), type(selector, text), scrollTo(element), extractData(selector, format)。 3. 处理跨域：通过 postMessage 与 background 通信，代理 fetch 请求。 此机制使自动化更鲁棒，适用于动态 SPA 应用。 ### 容错导航：自愈与回滚设计 网页环境的不可预测性要求强容错。Nanobrowser 的亮点在于 Planner 的自纠错：当 Navigator 报告失败（如元素未找到），Planner 重新规划路径，例如切换到备用选择器或调整等待时间。 导航流程从 chrome.tabs.create 开始，监控 tab.id。故障类型包括网络超时、页面重定向、反爬封禁。容错策略： - **重试机制**：指数退避，初始 delay 1s，上限 30s。失败率 > 20% 时，切换模型或提示。 - **状态机管理**：定义状态如 IDLE, NAVIGATING, EXTRACTING, ERROR。使用 chrome.storage.sync 持久化，支持侧边栏实时显示。 - **回滚参数**：保留 3–5 个历史快照（innerHTML 截取），失败时恢复最近成功状态。针对隐私，加密存储 API 密钥。 示例：GitHub 趋势仓库搜索，若 stars 排序失败，Planner 指令“滚动到底部，点击 Sort by stars”。监控阈值：任务时长 > 2min 触发警报，日志记录到 chrome.storage。 本地 LLM 集成增强容错：使用 Ollama 时，设置 temperature: 0.3 降低变异，top_p: 0.9 确保一致性。风险：模型延迟 > 5s 时，fallback 到云 API。 落地清单： 1. 在 background.js 实现 errorHandler：catch 异常，发送 { type: "error", details: err.message } 到 Planner。 2. 自愈 prompt："基于错误 {error}，生成替代计划。优先简单动作。" 3. 测试套件：模拟故障如网络断开，使用 chrome.debugger API 注入错误。 ### 工程化监控与优化 构建扩展时，性能监控不可或缺。Nanobrowser 的侧边面板使用 React 渲染实时日志，支持历史对话。建议集成 chrome://tracing 追踪 LLM 调用耗时。 优化点： - **资源限制**：Service Worker 内存 < 100MB，content script 避免无限循环。 - **安全考虑**：验证所有输入，防止 XSS；API 密钥仅本地存储，不上传。 - **扩展性**：支持插件化代理，未来添加视觉代理如截图分析。 实际部署：从 Chrome Web Store 发布，监控用户反馈。Nanobrowser 的开源性质允许 fork 定制，社区 Discord 分享提示库。 通过这些实践，开发者可构建高效的 AI 网页自动化扩展。Nanobrowser 证明了本地多代理的潜力，未来结合 WebGPU 可进一步加速本地推理。立即试用，探索无限可能。 （字数：1028） ## 同分类近期文章 ### [NVIDIA PersonaPlex 双重条件提示工程与全双工架构解析](/posts/2026/04/09/nvidia-personaplex-dual-conditioning-architecture/) - 日期: 2026-04-09T03:04:25+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 NVIDIA PersonaPlex 的双流架构设计、文本提示与语音提示的双重条件机制，以及如何在单模型中实现实时全双工对话与角色切换。 ### [ai-hedge-fund：多代理AI对冲基金的架构设计与信号聚合机制](/posts/2026/04/09/multi-agent-ai-hedge-fund-architecture/) - 日期: 2026-04-09T01:49:57+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析GitHub Trending项目ai-hedge-fund的多代理架构，探讨19个专业角色分工、信号生成管线与风控自动化的工程实现。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation-framework/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [LiteRT-LM C++ 推理运行时：边缘设备的量化、算子融合与内存管理实践](/posts/2026/04/08/litert-lm-cpp-inference-runtime-quantization-fusion-memory/) - 日期: 2026-04-08T21:52:31+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 LiteRT-LM 在边缘设备上的 C++ 推理运行时，聚焦量化策略配置、算子融合模式与内存管理的工程化实践参数。