背景

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

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

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

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

demo

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

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 ，用户操作能被动浏览转向主动自动化。

? 你说的趋势没错。 但我仍然不觉得 AI 浏览器是必然。

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

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

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

? 从「页面渲染工具」 → 「任务完成工具」

2 现代网络的内容爆炸

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

👉 不是人不聪明，而是人类不适合当“网页流程引擎”

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

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

过去的问题是：

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

现在的问题是：

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

举例：

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

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

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

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

传统模式是

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

AI 浏览器模式：

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

4 为什么是浏览器?

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

一句话总结为什么我们需要 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 爆炸

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

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

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

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

1. 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 联系到我们。