背景

每天，我们都会在浏览器上工作，搜索信息、浏览网页内容、下订单、整理表格、填写表单、等等。

一方面，我们会打开几十个上百个浏览器标签，而切换和管理标签页已经是一件不可能的事情，很多时候需要推倒重来，只关注眼前的标签页。

另一方面，很多任务是重复性的，需要我们一遍又一遍地执行，比如填写表单、整理表格、填写验证码、等等。这个过程是伴随着无趣和低效的。

那么, 如果AI来做会怎么样呢? 我之前有做一款整理标签页的插件，智能整理庞杂的标签页为他们分组。 随着Tool Call和MCP的发展，意识到AI Agent可以做越来越多事情，很快这个插件成了现在的浏览器插件AIPex。 AIPex支持使用自然语言来控制浏览器，并且在优化了上下文工程之后，可以做到快速和精准的完成任务。

通过这篇文章，我希望能解答这些问题：

1. 为什么AI浏览器是未来的趋势？
2. AI浏览器的实现路径有哪些？各自的优劣势是什么？
3. 为什么我们有自信说AIPex是AI浏览器自动化的游戏改变者？

AI浏览器革命正在到来

从ChatGPT问世之后，就有过很多团队做了AI浏览器的尝试，最早就看到了ChatGPT for Google， 能够在谷歌搜索结果旁展示AI的回答，这瞬间吸引了几百万的用户注册。而后随着Sider和Monica的发布，不仅能够增强谷歌的搜索结果， 也能在页面随时唤起AI助手，并且针对视频网站、chat pdf、图片网站做了专门的优化，AI能随时加入到内容的生成、修订和分析中，大大地加强了用户体验， 至今我也是此类插件的忠实用户。以Sider来说，光chrome就有600w的用户，可以说是AI浏览器插件第一名了吧。

之后，随着Tool Use和MCP的出现和广泛使用，AI浏览器不仅是能够查询、在对话框内生成文字和图像，也能通过工具调用浏览器的能力，完成更复杂的任务。 从去年Browser Use提出这个概念，到今年Claude for Chrome、Comet、ChatGPT Atlas的出现，各家都发布了Agentic Browser，最大的特点就是能够自动地帮你完成任务。 从Query到Action，用户操作能被动浏览转向主动自动化。

1. 传统浏览器的根本瓶颈：它只“展示”，不“完成”

传统浏览器的角色是：打开网页、展示信息、等人点击、复制、判断、跳转。但真正的目标从来不是“看网页”，而是：找到合适的产品 、完成报税 / 订票 / 填表、对比方案并做出决策、把信息转化为结果

人在浏览器里做的，其实是流程执行者，而不是“阅读者”。AI 浏览器的核心升级是：

2. 现代网络的内容爆炸

现实问题是：页面越来越复杂（多步骤、弹窗、验证码、选项）、信息密度越来越高（比价、条款、评论、政策）、任务越来越流程化（申请、注册、比对、提交）。 而人类：点击慢、记忆有限、易出错、不擅长重复流程。

自主执行任务的 AI 浏览器，本质是：不疲劳、不遗漏步骤、能并行执行、能持续优化路径。

3. 信息时代的关键瓶颈已从“获取信息”转向“执行决策”

过去的问题是：

• 信息太少 → 我们需要搜索引擎

现在的问题是：

• 信息太多 → 决策和执行成本过高

举例：

• 选一个最划算的航班 + 行李规则 + 改签条款

• 给 20 家供应商发定制邮件并跟进

• 按公司政策完成一次报销 / 采购流程

这些都不是“搜一下就行”，而主要是理解目标、权衡约束、执行步骤。

传统模式是

人 → 指挥 → 软件 → 等反馈 → 人再操作

AI 浏览器模式：

人 → 设定目标与边界
AI → 自主规划 + 执行 + 汇报结果

4. 为什么是浏览器?

电脑是作为人与信息的媒介而诞生， 而浏览器基本覆盖90%的工作和生活系统，能够连接到SaaS、政务、金融、内容平台， 不用等待各家提供接口，而是可以直接在“人类界面”层完成任务，这是目前我认为 目前最现实、阻力最小、扩展性最大的 AI 自动化落地路径。

一句话总结为什么我们需要AI浏览器

AI浏览器的实现原理

AI浏览器实现的关键在于如何高效地理解页面，这里有如下路径

1. DOM Tree（DOM 树）——最直观、也是最脆弱的方式

• 直接读取 document / HTML

• 把 DOM 节点序列化成文本

• 交给 LLM 理解 + 生成操作

HTML / DOM → serialize → LLM → action

Playwright / Puppeteer 也是 DOM 的思路，他们在处理DOM上做了很多脏活累活，能够拿到一个比较干净的DOM树表示。 但这个方案有以下问题

❌ DOM ≠ 用户看到的界面

❌ div 套 div，DOM不是语义表达会导致语义缺失

❌ LLM token 爆炸

2. Visual Tree / OCR（视觉理解派）

把网页当成“截图”，用 OCR + Vision Model 识别：按钮、文本、输入框，再让 AI 通过坐标点击

Screenshot → Vision Model → UI elements → click(x,y)

目前来说OpenAI也有个computer-use-agent(cua)模型，能够根据截图和任务生成动作。 优点在于这种方式比较通用，不依赖于浏览器对于网页的表达，可以推广到任何浏览器、任何操作系统的自动化。 这个方案虽然通用，但是成本和延迟高，目前即使是ChatGPT Atlas也不会使用cua去做自动化。

3. Accessibility Tree（无障碍树）——AIpex 的路线

原理（重点）

浏览器内部其实已经有一棵 “给读屏软件用的语义树”：

• role：button / textbox / link

• name：人类可读名称

• state：disabled / checked / expanded

• hierarchy：真实 UI 结构

DOM → Accessibility Tree → Semantic UI Graph → LLM

为什么它非常适合 AI？

AI浏览器的产品形态

目前来说，有以下实现浏览器自动化的的产品形态，我们逐一分析：

1. Agent浏览器

Agent浏览器是指独立的AI浏览器应用，如Comet、ChatGPT Atlas等。这些产品重新构建了浏览器，将AI能力深度集成到浏览器内核中。

优势：

• 深度集成：AI能力与浏览器内核深度融合，可以更底层地控制浏览器行为
• 统一体验：所有功能都在一个应用中，体验更统一
• 性能优化：可以针对AI场景做专门的性能优化

劣势：

• 迁移成本高：用户需要放弃现有浏览器，迁移书签、扩展、密码等数据
• 生态割裂：无法使用Chrome/Edge的丰富扩展生态
• 学习成本：用户需要适应新的浏览器界面和操作习惯
• 开发成本：需要从零构建浏览器，开发成本极高

典型代表： Comet、ChatGPT Atlas、Dia

2. 插件 / 扩展式

插件/扩展式是指基于现有浏览器（Chrome、Edge等）开发的扩展程序，如AIPex。这种方式在现有浏览器基础上添加AI自动化能力。

优势：

• 零迁移成本：保留所有书签、扩展、密码、历史记录
• 即插即用：安装后立即可用，无需改变使用习惯
• 生态兼容：可以继续使用Chrome/Edge的丰富扩展生态
• 开发效率高：基于成熟的浏览器API，开发成本相对较低
• 用户接受度高：用户无需改变浏览器使用习惯

劣势：

• API限制：受限于浏览器扩展API的能力边界
• 性能约束：需要与浏览器其他扩展和功能协调，可能受性能影响

典型代表： AIPex、Claude for Chrome

路径对比

从实际落地角度来看，插件/扩展式是目前最现实、阻力最小、用户接受度最高的路径。用户不需要放弃已经建立的工作流和习惯，就能获得AI自动化能力。这也是AIPex选择扩展式路径的核心原因。

AIPex的优势

产品优势

1. 无需迁移

与Comet、ChatGPT Atlas等需要安装全新浏览器的方案不同，AIPex是Chrome/Edge扩展，

• 零迁移成本: 只需要安装插件就可以使用
• 保留所有数据：书签、扩展、密码、历史记录、Cookie全部保留
• 无需改变习惯：继续使用熟悉的浏览器界面和操作方式
• 即插即用：安装扩展后立即可用，无需学习新界面
• 生态兼容：可以继续使用Chrome/Edge的丰富扩展生态

"Your browser already works!" —— 你的浏览器已经很好用了，我们只是让它更智能。

2. 开源 & 隐私保护

AIPex GitHub仓库

对于一个能够阅读、执行任务的AI Agent来说，隐私和安全是至关重要的。 AIPex采用MIT开源协议，完全透明、可审计、可扩展：

• 完全开源：代码完全公开，任何人都可以审查、贡献、fork
• 隐私优先：你的数据永远不会离开你的机器，我们将数据完全保存在你的电脑内，不会上传到任何服务器
• BYOK（自带密钥）：使用你自己的API密钥，完全控制数据流向

与ChatGPT Atlas、Dia等需要付费订阅且数据需要上传到服务器的方案相比，AIPex在隐私和安全方面都有明显优势。

3. 优秀的上下文工程

AIPex在上下文工程方面做了大量优化，这是其能够高效、准确完成任务的核心技术优势：

无障碍树 + 搜索召回机制：

• 使用语义更丰富的无障碍树（Accessibility Tree）替代传统DOM
• 通过语义搜索按需召回相关元素，而非传递整个页面
• 大幅减少上下文长度，提高响应速度和准确性

智能快照去重：

• 同一标签页只保留最新一次的页面快照
• 将上下文复杂度从O(n²)降为O(n)
• 50次操作：从1,275个快照降至50个快照（节省96% token）

Search-based Element Retrieval：

在处理网页内容时，AIPex并没有使用基于embedding的RAG技术，相比于代码，网页是随时变化的，静态的embedding很难适应分析网页这个场景。 与Claude Code以及Cline的方案一致，AIPex并不会去embedding存储你的网页，而是使用了优化后的search，让大模型去判断需要哪些元素， 既不是把全部页面内容给大模型，也不是基于embedding的RAG技术。

这些技术创新使得AIPex能够在保持高准确性的同时，大幅降低计算成本和响应时间。

4. 支持Skills

AIPex与**Claude Agent Skills**无缝集成，为浏览器自动化开辟了无限可能：

• 导入技能：访问社区创建的数千个预构建技能，扩展自动化能力
• 导出技能：将成功的AIPex工作流程导出为可重用的技能
• 技能组合：混合和匹配多个技能，创建复杂的自动化工作流程
• 生态协作：从Claude生态系统的集体知识中受益

这意味着你不仅可以使用AIPex，还可以利用整个Claude Agent Skills生态系统，这使得你的任务可复用、可分享、并且更加快捷高效。

5. 智能介入

AIPex会在任务需要确认时，智能地提示用户进行确认，这保证了如支付、确认提交等关键和敏感操作的安全性。

6. 针对性的用户场景

AIPex能够理解网页和用户动作，所以对一些细化场景做了针对性的优化，比如撰写用户指引文档(《如何在vercel上创建域名？》)。

以前，如果你想要为自己的系统撰写用户文档，你需要

• 回到用户视角，保证文档不出现技术术语

• 手动录制每一步，并为每一步撰写描述文档

• 手动截屏每一步，并打上关键标注

• 将每一步的文档进行整理和排版，并最终形成文档

但是现在，你只需要打开AIPex用户指引功能，然后录制你的操作，AIPex就会自动为你生成用户指引文档。

这个效率提升是革命性的，作为人你不需要再关注排版、用户视角、技术术语，这些AIPex都为你准备好了， 而你只需要关心最终的产物，并且可以随时更新。 还有很多类似于"撰写用户指引"这种细分场景，比如端到端测试、录制产品demo，AIPex可以为这些细分场景提供更好的解决方案，敬请期待。

AIPex是如何诞生的

起初我只是想做一个浏览器内的raycast，能够在任何位置唤起，帮助我 切换标签(类似Arc浏览器的Command + T快捷键, 选择标签切换)、整理标签页面(我经常需要处理40+个标签页，手动整理非常麻烦)、任何位置唤起AI助手(不管是发邮件、发推特，还是进行询问)，于是我开发了AIPex的第一个版本。 这个版本能优化我遇到的多标签的问题，可以在一些页面对AI提问，但我觉得还不够酷。

去年此时Anthropic提出了Computer Use Operator的概念， 紧接着Browser Use也出现了提出了AI浏览器自动化的概念。 随着技术发展，主要是tool use和mcp的发展，出现了一些chrome的mcp，比如说mcp-chrome、playwright-mcp、browserMCP以及devtools-mcp项目。 我在cursor里进行了尝试，最大的问题是他们都是用的无头浏览器，这样就无法复用用户的登录状态，甚至无法再无介入的情况下帮我发一篇小红书。 其实这种mcp client、servers分离也有上下文浪费的问题，cursor无法针对性的进行上下文优化。

所以我就想做一个chrome扩展，能够直接在浏览器中使用，并且能够复用用户的登录状态，自然语言控制浏览器行为，并且针对浏览器做针对性的上下文优化。 在这之前我其实还搞不懂什么是MCP，什么是tool use，什么是Agent Loop。在于cursor老师搏斗一周之后，有了AIPex的第一个版本，涵盖了80+个浏览器工具， 当时开源了AIpex代码并录制了第一个demo视频《帮我使用谷歌研究MCP》，AIPex会打开谷歌、填入MCP、点击查询、进一步点入子链接进行研究，并最终生成一篇关于MCP的报告。

我将这个demo分享给了我的领导、同事和朋友们，他们都非常感兴趣，想搞清楚这里面做了什么。一开始我只是以业余时间做的玩具对待AIPex，Glace是第一个进行贡献的朋友， 对于AIPex他有无限的热情和想法，他希望借助AIPex的能力解决工作中遇到的实际问题，比如撰写用户文档、界面端到端测试等等。 我会和他沟通产品形态和需求，相同的是我和他虽然都是typescript纯小白，但都无比相信cursor老师的代码水平。 Glace的高能量也进一步影响了我，让我知道AIPex是有趣的、有价值的，推动我去进而进一步优化AIPex。

随着越来越多同事和朋友了解到AIPex，也收到了更多的需求和修改建议，比较严重的是第一版本的UI是比较丑陋的，几乎是混用原生组件和第三方组件， 导致UI风格不好看、不统一，并且存在一些bug。Ken在国庆时完全用ai elements重构了AIPex的UI，这部分代码量更改已经占了当时的1/2， 最终效果非常惊艳才有了现在的AIPex UI。后来Claude Agent Skills一出现，Ken也在一周内的时间就1:1复刻了Skill并整合到AIPex中， Skill能够使用prompt + 脚本 记录本次成功的执行过程，下一次再使用时，AIPex就能根据Skill表现的更加一致、更加快速。

目前，k8s/golang/supabase/tidb contributor卡神也加入了我们，在研读了市面上如gemini-cli、openai-agents-sdk、spring-ai等主流AI Agent 实现方式后，对我们的开源仓库进行重构，AIPex的开源代码变得更加易懂、更加规范、更易于维护，卡神会继续协助我们做开源社区的运营。

我们依旧是一个4个人的小团队，我和Glace主要负责产品，Ken是资深前端，对于AIPex这种富前端模型的Agent是至关重要的。 卡神是资深的开源贡献者，对于我们项目的开源路线和社区运营是非常重要的。 目前我们都是在业余时间为AIPex添砖加瓦， 产品方面目标是继续开发更契合的垂直场景，比如说录制产品demo、端到端测试、UI比对等等，每一种垂直场景都是针对不同的人群解决问题。 营销方面我们没有太多的资金投入，我在尝试优化SEO， SEO我其实一年来一直在研究，有做过AI导航站有拿到过一定的成绩，但在AIPex上还没有太好的效果。 当前目标是能够拿到稳定可观的MRR，如果有合作意向，也可以在 https://www.claudechrome.com/zh/contact 联系到我们。