Fan：开源浏览器Agent，让AI自动操作网页执行任务

一款能自主操作浏览器的AI Agent

当大模型逐渐从「聊天工具」进化为「行动工具」时，浏览器自动化正在成为AI Agent最具想象空间的落地场景之一。近日，一位B站UP主开源了名为 Fan（FanAgent） 的浏览器Agent产品，并录制了完整的下载与使用教程。这款工具的核心定位很明确：一款直接与浏览器交互、具备自动化能力的AI Agent。

简单来说，它能像人一样操作网页——理解页面内容、点击元素、填写表单，并根据你设定的目标自主执行一系列任务。这不是简单的脚本录制回放，而是让AI真正「看懂」网页并做出决策。

浏览器Agent是AI Agent领域中一个快速发展的分支，其核心思路是让大语言模型（LLM）直接与浏览器交互，完成传统上需要人类手动操作的网页任务。与传统的RPA（机器人流程自动化）或Selenium等自动化测试框架不同，浏览器Agent具备语义理解能力，能够根据自然语言指令理解用户意图，并动态规划操作路径。代表性项目包括OpenAI投资的Operator、微软的UFO、以及开源社区广受关注的Browser-Use和WebVoyager等。这些项目的共同特点是将网页的DOM结构或截图转化为LLM可理解的上下文，再由模型输出具体的操作指令（如点击、输入、滚动等），形成"感知-决策-执行"的闭环。值得注意的是，这一领域在2024年经历了爆发式增长，从学术界的WebArena基准测试到商业化产品的密集发布，浏览器Agent正在从实验室走向生产环境。推动这一趋势的关键因素包括：多模态模型能力的提升使视觉理解成为可能、上下文窗口的扩大使Agent能处理更复杂的页面信息、以及Function Calling等结构化输出能力的成熟使模型能精确输出可执行的操作指令。

从演示可以看出，Fan打开百度后能够高亮出页面上所有可点击的元素，这一步是浏览器Agent的关键能力证明——它需要先建立对网页结构的理解，才能进行后续的自动化操作。

这种高亮可点击元素的能力，涉及浏览器Agent领域的一个核心技术环节——页面状态表征（Page State Representation）。目前业界主要有两种实现路径：一是基于DOM解析的方式，通过遍历网页的HTML结构树，识别出所有可交互的DOM节点（如<a>、<button>、<input>等标签），并为每个元素分配唯一标识符；二是基于视觉的方式，通过截图配合多模态模型来识别可操作区域。DOM解析的优势在于精确度高、token消耗少，但对复杂的动态渲染页面（如大量使用Shadow DOM或Canvas的页面）适应性较弱；视觉方式更接近人类操作习惯，但计算成本更高。目前最前沿的方案往往采用混合策略——先用DOM解析获取结构化信息，再辅以视觉截图帮助模型理解空间布局和视觉上下文。例如，Browser-Use项目会将DOM树进行精简压缩后与页面截图同时提供给模型，让模型既能获取精确的元素属性信息，又能理解页面的整体视觉布局。Fan采用的高亮标注方式，可以直观地向用户展示Agent对页面的理解程度，同时也为后续的操作指令提供了明确的目标锚点。

Fan的三大核心能力

根据作者介绍，Fan的能力可以归纳为三个层面。

网页理解能力

Fan能够解析网页结构，识别出页面中的可交互元素（如按钮、链接、输入框）。这是所有自动化操作的前提。相比传统的基于固定选择器的爬虫或RPA工具，具备语义理解能力的Agent对页面改版的适应性更强。

传统的网页爬虫和RPA工具依赖CSS选择器、XPath等固定路径来定位页面元素。这种方式虽然执行效率高，但极其脆弱——一旦目标网站进行前端重构或改版，选择器路径发生变化，整个自动化脚本就会失效，需要人工重新维护。据行业统计，大型企业维护RPA流程的成本中，有30%-50%花费在因网页改版导致的脚本修复上。而基于大语言模型的语义理解方式则完全不同：Agent通过理解元素的语义含义（比如"搜索按钮"、"提交表单"）来定位目标，而非依赖特定的HTML属性或DOM路径。这意味着即使页面的HTML结构发生变化，只要功能语义不变，Agent仍然能够正确识别和操作目标元素，大幅降低了自动化流程的维护成本。这种能力本质上来源于LLM在大规模网页数据上的预训练——模型见过数十亿网页的结构模式，因此能够泛化地理解"一个带有放大镜图标的输入框旁边的按钮通常是搜索按钮"这类隐含知识。

自动化执行能力

Fan可以打开或关闭页面、填写自动化表单，并根据用户设定的目标去执行任务。这意味着用户只需描述「要做什么」，而不必手把手告诉它「每一步怎么做」，由Agent自行规划路径。

这背后依赖的是LLM的推理与规划能力。在技术实现上，这通常采用ReAct（Reasoning + Acting）框架或类似的思维链（Chain of Thought）机制：Agent先观察当前页面状态，然后进行推理判断下一步应该执行什么操作，执行后再观察新的页面状态，如此循环直到任务完成。ReAct框架由Google Research在2022年提出，其核心创新在于将"推理"和"行动"交织进行，而非先完成所有推理再统一执行。具体到浏览器Agent场景，一次典型的ReAct循环可能是：观察（"当前页面显示百度首页，搜索框为空"）→ 思考（"用户要搜索天气，我需要先在搜索框中输入关键词"）→ 行动（"在id为kw的输入框中输入'北京天气'"）→ 观察（"输入成功，搜索框现在显示'北京天气'"）→ 思考（"接下来需要点击搜索按钮"）→ 行动（"点击'百度一下'按钮"）。这种"观察-思考-行动"的循环模式使Agent能够处理多步骤的复杂任务，并在遇到意外情况（如弹窗、验证码、页面加载失败）时做出适应性调整。相比预定义的线性脚本，这种方式具有更强的鲁棒性和灵活性。此外，一些更先进的实现还引入了记忆机制和错误恢复策略——当某一步操作失败时，Agent能够回溯到之前的状态并尝试替代方案。

多任务并行能力

这是Fan比较有特色的一点——它支持开启多个 Space，实现多任务的同时执行。对于需要批量处理网页操作的场景（比如同时追踪多个报告、批量提取评论），这种并行能力能显著提升效率。

从技术角度来看，实现多任务并行通常需要解决几个核心问题：首先是浏览器实例的隔离管理，每个Space可能对应一个独立的浏览器上下文（Browser Context）或独立的浏览器进程，以确保不同任务之间的Cookie、Session等状态互不干扰；其次是LLM调用的并发管理，多个任务同时运行意味着需要并行发送多个API请求，这对token消耗和API速率限制提出了更高要求；最后是任务状态的统一调度，需要一个中央调度器来监控各个Space的执行进度和异常状态。在底层实现上，现代浏览器自动化库（如Playwright和Puppeteer）已经原生支持Browser Context的概念——每个Context相当于一个独立的浏览器会话，拥有独立的Cookie存储、LocalStorage和缓存，但共享同一个浏览器进程，这比启动多个完整浏览器实例更加节省系统资源。这种并行架构特别适合需要同时处理多个独立网页任务的场景，如批量数据采集、多平台价格监控、同时管理多个社交媒体账号等。

适用场景：从签证申请到旅行订票

作者在项目官网上列举了一系列典型使用场景，覆盖面相当广：

• 签证申请：自动填写繁琐的申请表单
• 文献检索：在学术平台批量搜索资料
• 报告追踪：定期监控特定网页的更新
• 评论提取：从电商或社交平台抓取评论
• 旅行订票：自动比价、预订
• 信息对比：跨页面收集并形成对比

这些场景有一个共同点——都是重复性高、流程相对固定但又需要一定判断力的网页操作。这正是浏览器Agent最能发挥价值的地方。传统的自动化工具（如Selenium脚本或按键精灵）虽然也能完成这些任务，但它们要求用户精确定义每一步操作，一旦网页布局发生变化就需要重新编写脚本。而AI Agent的优势在于它具备对页面内容的语义理解和动态决策能力——比如在旅行订票场景中，Agent不仅能自动填写出发地和目的地，还能理解"选择最便宜的直飞航班"这样的模糊指令，并在多个搜索结果中做出判断。

值得注意的是，这些场景的复杂度和风险等级各不相同。文献检索和评论提取属于低风险的信息获取类任务，即使Agent犯错也不会造成实际损失；而签证申请和旅行订票则涉及真实的表单提交和支付操作，容错空间极小。在实际部署时，高风险场景通常需要引入"人机协同"机制——Agent自主完成大部分操作，但在关键决策节点（如确认支付、提交申请）暂停并等待用户确认。这种分级策略既保留了自动化带来的效率提升，又避免了全自动模式下可能出现的不可逆错误。

开源设计思路：作为「浏览器运行时」

作者特别强调了选择开源的原因，这也是Fan最值得关注的设计思路。

他将Fan定位为一个 「浏览器运行时」（browser runtime），而非一个封闭的成品应用。这意味着开发者可以 Fork 或 Clone 项目，在此基础上打造面向自己行业的细分领域助手。

这种设计哲学在开源生态中有着深厚的传承。类比来看，Node.js是JavaScript的服务端运行时，Docker是容器化应用的运行时——它们都不直接解决具体的业务问题，而是提供一个底层执行环境，让开发者在此之上构建各种应用。Fan的思路类似：它抽象出浏览器自动化所需的核心能力（页面感知、元素交互、任务调度等），作为基础设施层提供给开发者。这种分层架构的好处是显而易见的——底层能力由社区共同维护和优化，而上层的行业应用则由各垂直领域的开发者根据自身需求定制，实现了关注点分离。从软件工程的角度看，这也符合"做好一件事"的Unix哲学——Fan专注于提供可靠的浏览器操控能力，而将业务逻辑的决策权交给下游开发者。这种模式如果运作良好，有可能形成类似Hugging Face之于NLP模型、LangChain之于LLM应用的生态位——成为浏览器Agent领域的事实标准底层框架。

作者举了两个B端场景的例子：

假如你是B端的签证申请商家，可以基于Fan做一个签证申请AI助手；如果你做其他B端业务，同样可以定制专属的行业Agent。

这种「运行时 + 二次开发」的模式，本质上是把浏览器自动化的底层能力抽象出来，让下游开发者聚焦于业务逻辑，而不必重复造轮子。对于希望在垂直领域构建AI应用的团队来说，这是一个有吸引力的起点。

两类人群的安装指南

Fan为不同背景的用户提供了两条路径。

面向开发者：GitHub源码启动

有编程经验的开发者可以在 GitHub 搜索 FanAgent 找到项目。README 提供了中文和英文两个版本的详细说明，包含产品介绍和启动方式。

源码启动的方式非常简洁，只需一条命令：

npm run

执行启动脚本后，系统会自动下载后端 Agent 以及前端 Electron 的相关依赖，完成环境搭建。Fan的前端采用了Electron框架，这是一个基于Chromium和Node.js的跨平台桌面应用开发框架，被VS Code、Slack、Discord等知名应用广泛采用。Electron的核心原理是将一个完整的Chromium浏览器引擎和Node.js运行时打包到应用中，前端使用HTML/CSS/JavaScript进行UI开发，后端通过Node.js访问操作系统API。对于浏览器Agent产品而言，选择Electron有天然优势：它本身内置了完整的Chromium浏览器引擎，可以直接在应用内部控制浏览器行为，无需依赖用户系统上安装的浏览器，同时开发者可以通过Chromium DevTools Protocol（CDP）直接与内置浏览器进行底层通信，实现精细的页面控制。Node.js环境则提供了丰富的系统级API访问能力，方便与后端Agent服务进行通信。不过Electron也有其固有的缺点，如内存占用较高（每个Electron应用都会运行一个完整的Chromium实例，空载即占用约100-200MB内存），这在多Space并行场景下可能尤为明显。近年来也出现了Tauri等更轻量的替代方案，但在浏览器Agent这一特殊场景下，Electron内置Chromium的特性反而成为了独特优势。

面向非开发者：官网直接下载

没有编程经验的用户则可以直接前往产品官网 fandcode.com 下载安装包使用，无需配置任何开发环境。

关于API Key与版本规划

作者也坦诚地谈到了当前的一个限制：目前的API Key费用由作者个人承担。由于大模型API调用成本高昂，个人开发者难以长期负担。

大模型API的调用成本是当前所有AI应用面临的核心挑战之一。以OpenAI的GPT-4o为例，输入token价格为每百万token 2.5美元，输出token为每百万token 10美元；而Claude 3.5 Sonnet的价格为输入每百万token 3美元，输出每百万token 15美元。浏览器Agent的每一步操作都需要将页面状态（可能包含大量DOM信息）发送给模型进行推理，单次任务可能消耗数千到数万token。以一个典型的5步网页操作任务为例，如果每步需要发送约3000token的页面上下文并接收500token的操作指令，一次完整任务的成本约为0.05-0.1美元。这个数字看似不大，但如果一个开源项目由作者免费提供API Key供所有用户使用，随着用户量增长，每天数百次调用就可能产生数十美元的费用，成本将呈指数级上升。开源社区中已有多个项目（如GPT4Free等）因API成本失控而难以为继的先例。

因此在版本规划上，作者透露：

• 当前版本为 0.4.3
• 下一个版本 0.4.5 计划上线支持用户自行填写API Key的功能，同时更新一批新特性

这个调整对项目的可持续性很重要——让用户自带 Key（即BYOK，Bring Your Own Key模式）后，项目才能摆脱作者个人承担成本的压力，实现更健康的开源运营。BYOK模式已经成为开源AI项目最主流的可持续运营模式，包括Open WebUI、LobeChat、ChatBox等知名开源项目都采用了这一策略。其核心逻辑是：开源项目免费提供软件本身的代码和功能，而将推理成本合理地分摊给终端用户——用户自行注册大模型服务商的账号、获取API Key，并按实际使用量直接向服务商付费。这种模式既保持了开源的免费使用属性，又确保了项目不会因为成本问题而停止维护。对用户而言，BYOK还带来了一个额外好处：用户可以自由选择不同的模型供应商（如OpenAI、Anthropic、国内的智谱、月之暗面等），根据自己的需求在成本、性能和隐私之间做出权衡。

写在最后

从整体来看，Fan 代表了当下浏览器Agent的一个务实方向：不追求大而全，而是把底层的网页操作能力做扎实，并以「运行时」的形态开放出来，鼓励社区在垂直行业进行二次创作。

对于关注AI Agent落地的开发者而言，Fan 值得一试——无论是直接使用来解决日常的重复性网页任务，还是 Fork 下来打造行业专属助手。作者也在视频中呼吁大家为项目点 Star、Fork，参与到有意义的二次开发中来。随着 0.4.5 版本开放API Key，这款工具的可用性有望进一步提升。

从更宏观的视角看，浏览器Agent赛道正处于从"技术验证"向"产品化"过渡的关键阶段。2024-2025年间，我们看到了从学术demo到可用产品的快速迭代：模型能力的提升解决了"能不能做"的问题，而Fan这样的开源项目正在尝试回答"怎么做得好用"和"怎么持续运营"的问题。可以预见，随着模型推理成本的持续下降（过去一年GPT-4级别模型的单token价格已下降超过90%）和Agent框架的成熟，浏览器自动化将从开发者的极客玩具逐步走向普通用户的日常工具。