每天，我们都会在浏览器上工作，搜索信息、浏览网页内容、下订单、整理表格、填写表单、等等。
一方面，我们会打开几十个上百个浏览器标签，而切换和管理标签页已经是一件不可能的事情，很多时候需要推倒重来，只关注眼前的标签页。
另一方面，很多任务是重复性的，需要我们一遍又一遍地执行，比如填写表单、整理表格、填写验证码、等等。这个过程是伴随着无趣和低效的。
那么, 如果 AI 来做会怎么样呢? 我之前有做一款整理标签页的插件，智能整理庞杂的标签页为他们分组。 随着 Tool Call 和 MCP 的发展，意识到 AI Agent 可以做越来越多事情，很快这个插件成了现在的浏览器插件 AIPex 。 AIPex 支持使用自然语言来控制浏览器，并且在优化了上下文工程之后，可以做到快速和精准的完成任务。
通过这篇文章，我希望能解答这些问题：
从 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 浏览器实现的关键在于如何高效地理解页面，这里有如下路径
直接读取 document / HTML
把 DOM 节点序列化成文本
交给 LLM 理解 + 生成操作
HTML / DOM → serialize → LLM → action
Playwright / Puppeteer 也是 DOM 的思路，他们在处理 DOM 上做了很多脏活累活，能够拿到一个比较干净的 DOM 树表示。 但这个方案有以下问题
❌ DOM ≠ 用户看到的界面
❌ div 套 div ，DOM 不是语义表达会导致语义缺失
❌ LLM token 爆炸
把网页当成“截图”，用 OCR + Vision Model 识别：按钮、文本、输入框，再让 AI 通过坐标点击
Screenshot → Vision Model → UI elements → click(x,y)
目前来说 OpenAI 也有个 computer-use-agent(cua)模型，能够根据截图和任务生成动作。 优点在于这种方式比较通用，不依赖于浏览器对于网页的表达，可以推广到任何浏览器、任何操作系统的自动化。 这个方案虽然通用，但是成本和延迟高，目前即使是 ChatGPT Atlas 也不会使用 cua 去做自动化。
原理（重点）
浏览器内部其实已经有一棵 “给读屏软件用的语义树”：
role：button / textbox / link
name：人类可读名称
state：disabled / checked / expanded
hierarchy：真实 UI 结构
DOM → Accessibility Tree → Semantic UI Graph → LLM
为什么它非常适合 AI ？
| 维度 | DOM | Accessibility Tree |
|---|---|---|
| 是否语义化 | ❌ | ✅ |
| 是否贴近用户感知 | ❌ | ✅ |
| 是否稳定 | ❌ | ✅ |
| token 密度 | 高 | 低 |
| 可操作性 | 间接 | 直接 |
目前来说，有以下实现浏览器自动化的的产品形态，我们逐一分析：
Agent 浏览器是指独立的 AI 浏览器应用，如Comet、ChatGPT Atlas等。这些产品重新构建了浏览器，将 AI 能力深度集成到浏览器内核中。
优势：
劣势：
典型代表： Comet、ChatGPT Atlas、Dia
插件/扩展式是指基于现有浏览器（ Chrome 、Edge 等）开发的扩展程序，如 AIPex 。这种方式在现有浏览器基础上添加 AI 自动化能力。
优势：
劣势：
典型代表： AIPex、Claude for Chrome
| 特性 | Agent 浏览器 | 插件/扩展式 |
|---|---|---|
| 迁移成本 | 高（需迁移数据） | 零（保留所有数据） |
| 开发成本 | 极高（需构建浏览器） | 中（基于现有 API ） |
| 用户体验 | 需适应新界面 | 无需改变习惯 |
| 生态兼容 | 无法使用现有扩展 | 完全兼容 |
| 深度集成 | 高 | 中 |
| 市场接受度 | 低（需改变习惯） | 高（即插即用） |
从实际落地角度来看，插件/扩展式是目前最现实、阻力最小、用户接受度最高的路径。用户不需要放弃已经建立的工作流和习惯，就能获得 AI 自动化能力。这也是 AIPex 选择扩展式路径的核心原因。
与Comet、ChatGPT Atlas等需要安装全新浏览器的方案不同，AIPex 是 Chrome/Edge 扩展，
"Your browser already works!" —— 你的浏览器已经很好用了，我们只是让它更智能。
对于一个能够阅读、执行任务的 AI Agent 来说，隐私和安全是至关重要的。 AIPex 采用MIT 开源协议，完全透明、可审计、可扩展：
与ChatGPT Atlas、Dia等需要付费订阅且数据需要上传到服务器的方案相比，AIPex 在隐私和安全方面都有明显优势。
AIPex 在上下文工程方面做了大量优化，这是其能够高效、准确完成任务的核心技术优势：
无障碍树 + 搜索召回机制：
智能快照去重：
Search-based Element Retrieval：
在处理网页内容时，AIPex 并没有使用基于 embedding 的 RAG 技术，相比于代码，网页是随时变化的，静态的 embedding 很难适应分析网页这个场景。 与 Claude Code 以及 Cline 的方案一致，AIPex 并不会去 embedding 存储你的网页，而是使用了优化后的 search ，让大模型去判断需要哪些元素， 既不是把全部页面内容给大模型，也不是基于 embedding 的 RAG 技术。
这些技术创新使得 AIPex 能够在保持高准确性的同时，大幅降低计算成本和响应时间。
AIPex 与**Claude Agent Skills**无缝集成，为浏览器自动化开辟了无限可能：
这意味着你不仅可以使用 AIPex ，还可以利用整个 Claude Agent Skills 生态系统，这使得你的任务可复用、可分享、并且更加快捷高效。
AIPex 会在任务需要确认时，智能地提示用户进行确认，这保证了如支付、确认提交等关键和敏感操作的安全性。
AIPex 能够理解网页和用户动作，所以对一些细化场景做了针对性的优化，比如撰写用户指引文档(《如何在 vercel 上创建域名？》)。
以前，如果你想要为自己的系统撰写用户文档，你需要
回到用户视角，保证文档不出现技术术语
手动录制每一步，并为每一步撰写描述文档
手动截屏每一步，并打上关键标注
将每一步的文档进行整理和排版，并最终形成文档
但是现在，你只需要打开 AIPex 用户指引功能，然后录制你的操作，AIPex 就会自动为你生成用户指引文档。
这个效率提升是革命性的，作为人你不需要再关注排版、用户视角、技术术语，这些 AIPex 都为你准备好了， 而你只需要关心最终的产物，并且可以随时更新。 还有很多类似于"撰写用户指引"这种细分场景，比如端到端测试、录制产品 demo ，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 联系到我们。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。