最近有个说法在圈子里传得很快OpenAI 都撤了AI 浏览器是不是凉了把时间线拉出来看更准确的表述是——OpenAI 从来没有正式发布过一个独立浏览器产品也没有官宣关闭某个浏览器项目。它做过的事情是传出过要做浏览器的风声挖过浏览器团队的人也上线过浏览器扩展但产品主线始终压在 ChatGPT 桌面端、ChatGPT Search 和 Operator 这类 Agent 工具上。换句话说OpenAI 不是“撤退”而是从一开始就没打算在浏览器这个形态上正面开战。这件事对行业的影响却是真实的。很多创业团队此前把“AI 浏览器”当成一条可以复制的路径套一个 Chromium 内核加一个 AI 侧边栏再塞一个对话入口就声称自己做了下一代浏览器。OpenAI 用产品轨迹给这条路打了一个问号——如果连最不缺模型能力、最不缺流量入口的公司都不愿意正面做浏览器那独立 AI 浏览器到底还有没有机会这篇文章不打算预测股价也不做概念科普。我们从产品、技术、商业模式三个角度拆一遍AI 浏览器到底难在哪为什么说它只剩一条窄路以及这条路具体长什么样、适合谁走。1. 先说清楚OpenAI 到底撤了什么先看时间线。根据公开报道OpenAI 在 2024 年下半年传出过做浏览器的计划也曾招募过 Chrome 团队背景的工程师。这个阶段行业普遍认为 OpenAI 要做一个基于 Chromium 的浏览器和 Google 在入口层面正面竞争。到了 2025 年OpenAI 的实际动作变成了几件事把 ChatGPT 能力加强到桌面客户端推出 ChatGPT Search 并把它植入对话流程发布 Operator 这类可以操作网页的 Agent同时上线了 ChatGPT 浏览器扩展。从这些动作可以看出OpenAI 并没有把“独立浏览器”当作战略级产品。它更在意的是用户在浏览网页时能不能随时把 AI 叫出来能不能让 AI 代替用户完成网页操作。浏览器本身是谁家的、内核是什么OpenAI 并不在乎。它的策略是“寄生”在现有浏览器上而不是“替代”浏览器。再看最近两个信号就更清楚了。OpenAI 用比较短的时间推进自研芯片同时把 Codex Harness 等开发工具开源。芯片解决的是推理成本问题Codex 解决的是 Agent 工程化问题。这两件事都指向同一个方向把 AI 能力做成基础设施和服务让它在各种各样的界面里被调用。浏览器只是其中一个界面不是不可替代的入口。所以“OpenAI 撤了”这个表述需要修正为OpenAI 放弃的是传统形态的浏览器产品选择的是跨浏览器、跨终端的 AI 入口。这个判断对创业者很重要因为如果我们还在按“做一个浏览器”来理解 AI 浏览器就已经走错了方向。2. 为什么独立 AI 浏览器越来越难做如果把 AI 浏览器拆开看它需要的核心能力其实有两层第一层是浏览器本身的工程能力第二层是 AI 能力与浏览场景的融合能力。大部分新团队有能力做第二层但很难承担第一层。浏览器本身是一个重工程产品不是套一层壳就完事。市面上几乎所有的 AI 浏览器都是基于 Chromium 二次开发原因很简单自研内核需要处理 JavaScript 引擎、排版引擎、网络安全模型、GPU 合成、协议栈、无障碍支持等一系列底层问题这至少是几百人团队的长期投入。就算基于 Chromium也要持续跟进上游安全补丁和版本升级否则浏览器就成了一个巨大的安全漏洞入口。这还不是最难的。最难的是生态迁移成本。用户换浏览器的成本太高了收藏夹、密码、插件、历史记录、书签同步每个都是习惯。Chrome 的插件生态有几十万个扩展新浏览器即便兼容 Chrome 扩展也很难保证所有扩展都能正常运行。用户没有理由为了一个 AI 侧边栏放弃用了几年的浏览器。从商业模式看独立浏览器也缺少令人信服的变现路径。广告是传统浏览器的主要收入但 AI 浏览器如果靠广告变现就会和 AI 助手“帮你过滤信息”的定位冲突。订阅制可以收一部分钱但愿意为浏览器本身付费的用户规模很有限。数据服务是一条路但涉及隐私问题处理不好会变成品牌危机。我整理了一张表把传统浏览器、带 AI 功能的浏览器和 Agent 型浏览器的差异列一下方便直接对比对比维度传统浏览器带 AI 功能的浏览器Agent 型浏览器核心价值打开网页、管理书签、插件在浏览时提供 AI 辅助代替用户完成网页操作用户角色主动浏览主动浏览 被动提效下达目标Agent 执行入口形态独立应用独立应用 / 扩展扩展、桌面端、API技术难点内核、兼容性、性能上下文理解、UI 注入页面理解、操作执行、失败恢复商业逻辑广告、搜索导流订阅 调用量订阅 任务计费 To B典型风险生态固化用户无感留存低正确率不够安全责任大从这张表能看到独立 AI 浏览器处在中间位置既没有传统浏览器的生态壁垒也没有 Agent 型产品那么强的不可替代性。它很容易被浏览器巨头的内建 AI 功能覆盖掉。3. 现在还在牌桌上的玩家OpenAI 没有做独立浏览器不代表这个赛道没人做了。现在牌桌上的玩家大概分三类。第一类是传统浏览器巨头。Google 在 Chrome 里不断强化 Gemini 的集成能力Microsoft 把 Copilot 放进了 EdgeOpera 有内置的 Aria 助手DuckDuckGo 也做了 AI Chat 入口。这些玩家的思路是一致的不改变浏览器的基本形态把 AI 变成系统级能力。它们有现成的用户、现成的内核、现成的升级渠道AI 功能只是加分项。第二类是创业公司。方向主要集中在两个细分点一是 AI 搜索体验二是网页 Agent。AI 搜索方向的产品会把搜索结果重新组织成一句话答案或结构化摘要页面本身比传统搜索更轻。网页 Agent 方向的产品则倾向于把手伸进浏览器里操作网页比如自动填表、自动比价、自动订票。这类产品最大的价值是“省时间”最大的风险是操作正确率和安全边界。第三类是大模型厂商和云厂商。它们的逻辑不是做浏览器而是做浏览器里的 AI 底座提供模型接口、Agent 框架、浏览器操作工具链。OpenAI 有 Operator 和 ChatGPT 扩展Anthropic 推出过 Computer Use 能力国内几家大模型厂商也陆续开放了类似的工具调用能力。它们更愿意让浏览器变成调用 AI 的终端而不是自己做终端。从这三类玩家的动作能看出一个共同点没有人再把“做一个新浏览器”当成核心叙事大家都在做“浏览器里的 AI”。因此对独立创业团队来说能走的路已经不在“浏览器”这个维度上而在“AI 怎么真正改变浏览行为”这个维度上。4. 技术拆解一个 AI 浏览器的核心模块要真正理解这条窄路得先知道一个可用的 AI 浏览器或浏览器 Agent 在技术上由哪些模块构成。下面这套架构是行业内比较通用的一种描述方式不针对某个特定项目。一个典型的 AI 浏览器系统可以拆成五层内核层负责页面加载、渲染、网络请求、Cookie 管理。独立产品一般基于 Chromium嵌入模式则直接使用浏览器的现有能力。感知层负责理解当前页面。信息来源包括 DOM 树、页面截图、可访问性树Accessibility Tree、OCR 结果和用户操作事件。这一层决定 Agent 能不能“看懂”页面。规划层大模型负责把用户目标拆解成一系列操作步骤比如“先点这里再填表格最后提交”。规划层需要根据页面状态动态调整不能一次性生成全部步骤。执行层把规划好的步骤转换成真实的浏览器操作包括点击、输入、滚动、切换标签页、等待页面加载。执行层通常依赖 浏览器调试协议 或自动化测试框架。记忆层保存用户的偏好、历史操作、已经验证过的选择路径。这一层让 Agent 越来越懂某一个具体用户而不只是懂通用网页操作。下面用一个简化伪代码描述浏览器 Agent 的主循环这是很多实现的原型def run_agent(task: str, page: Page) - TaskResult: # 初始化目标与历史操作 goal task history [] max_steps 20 for step in range(max_steps): # 1. 感知获取当前页面状态 state extract_page_state(page) # DOM 摘要 坐标 可交互元素列表 # 2. 规划让模型决定下一步操作 action llm_plan(goalgoal, statestate, historyhistory) # 3. 执行把动作转成浏览器操作 success execute_action(page, action) # 4. 记录写入历史判断是否完成 history.append(action) if check_done(goal, state): return TaskResult(successTrue, stepshistory) if not success: # 失败恢复尝试另一种操作 action recover_action(state, action) execute_action(page, action) return TaskResult(successFalse, stepshistory)这个主循环看着简单真正落地时难点在extract_page_state和execute_action。网页结构是动态的同一个按钮在不同页面里可能是button、div或自定义组件元素坐标会随滚动变化。大量真实网页还有弹窗、懒加载、验证码、登录墙这些都会打断 Agent 的自动操作。另外一个关键点是“规划”和“执行”的误判概率。就算模型每一步的正确率是 90%十步任务全部正确的概率也只有 35% 左右。如果每一步正确率只有 85%十步任务全部正确的概率只剩约 20%。这就是为什么浏览器 Agent 离“稳定可用”还有一段距离。5. 从“浏览”到“执行”的硬门槛如果把 AI 浏览器分成两个阶段第一个阶段是“AI 帮你找信息”第二个阶段是“AI 帮你做事”。现在大家真正卡住的是第二个阶段。“找信息”阶段的实现相对成熟模型把搜索结果、网页正文、用户问题一起作为上下文生成摘要或答案。这个模式对页面的依赖很弱本质上是一个检索增强生成RAG流程。很多浏览器扩展做得还不错用户体感也明显。“帮你做事”阶段的复杂度完全不同。Agent 需要在陌生页面上定位元素、判断当前状态、处理连续操作中的异常。举几个实际场景用户让 AI “帮我填写这个表单并提交”Agent 要先判断哪些字段是必填项字段是文本框还是下拉框还是日期选择器提交后页面是否会跳转跳转后是不是成功页。任何一个环节判断错误任务都会失败。更麻烦的是网页风控。很多平台对自动化操作有识别机制高频点击、非人类操作特征、异常的行为轨迹都可能导致账号受限。合规的自动化 Agent 必须严格控制操作频率并在用户授权的前提下运行。这部分不仅是技术问题也是责任问题。如果 Agent 在用户不知情的情况下执行了错误操作比如提交了错误订单或发布了不合适的内容责任归属会非常敏感。安全边界是另一个硬门槛。浏览器 Agent 拥有操作网页的权限就等于拥有了用户在某平台的执行权限。Agent 必须在执行敏感动作前二次确认必须在沙箱环境里运行第三方脚本必须对页面注入操作做权限分级。把“能操作网页”这个能力滥用用户隐私和资金安全都会受到威胁。因此一个能走到用户面前的 AI 浏览器产品技术能力只占一半剩下的一半是权限设计、风控策略、失败回滚和合规审核。6. 开发者机会窄路上的三个方向既然独立浏览器难做那开发者和创业团队的机会在哪里从目前的产品演化趋势看有三个方向值得实际去做。6.1 方向一浏览器扩展形态的 AI 助手不做一个完整浏览器而是做一个高质量的 Chrome/Edge 扩展。扩展可以访问当前页面的上下文调用模型 API在侧边栏或悬浮窗里给用户生成摘要、翻译、文案改写、表单辅助。这种形态的用户获取成本低安装门槛低也比独立浏览器更容易触达用户。下面是一个最简扩展的清单示例Manifest V3 是目前 Chrome 扩展的主流规范实际字段需要按目标浏览器做调整{ manifest_version: 3, name: AI Page Assistant, version: 0.1.0, permissions: [activeTab, storage, scripting], host_permissions: [all_urls], action: { default_title: Open AI Assistant }, background: { service_worker: background.js }, content_scripts: [ { matches: [all_urls], js: [content.js] } ] }扩展逻辑的通用做法是content_script负责读取页面文本和用户选择内容background负责调用模型接口再把结果通过消息协议回传给前端 UI。这个方案不重构浏览器而是在现有浏览器里加一个 AI 操作层性价比远高于做独立浏览器。6.2 方向二MCP 与浏览器工具链MCPModel Context Protocol类协议正在成为 AI 工具连接外部能力的标准方式。浏览器端可以做成 MCP server对外暴露“搜索网页”“读取页面内容”“点击元素”“填写表单”等工具让任何具备 Agent 能力的模型都能调用。这类工具链的价值在于不绑定具体浏览器。开发者可以先做一个通用的浏览器操作服务再把它接到 ChatGPT、Claude、自家模型或开源 Agent 框架上。先做底座比先做界面更容易积累长期竞争力。下面是一个通用的 MCP 工具调用请求示例字段名是示意真实接口需要按照具体协议格式调整import requests mcp_server_url http://127.0.0.1:8080/mcp payload { jsonrpc: 2.0, id: 1, method: tools/call, params: { name: browser_click, arguments: { selector: #submit-btn, wait_after_ms: 1000 } } } response requests.post(mcp_server_url, jsonpayload, timeout30) print(response.json())这个方向更适合有工程能力的团队做的事情是让模型“长出手脚”而不是自己做产品界面。它的商业逻辑也更顺按调用量计费按任务结果计费或者直接卖自动化能力给 To B 客户。6.3 方向三垂直场景的浏览器 Agent通用浏览器 Agent 很难做垂直场景反而有机会。比如客服工作台自动填单、跨境购物比价、文献检索自动下载、政府表单批量填写这些场景页面结构固定、操作路径清晰、用户需求具体。Agent 只需要针对有限的站点做优化正确率和稳定性都能做到比较高。垂直场景 Agent 还有一个优势可以先人工编排流程再让模型在关键节点做决策而不是完全依赖模型自主规划。这种“人工编排 模型决策”的混合模式能显著降低错误率也是目前行业里更容易落地的产品方案。7. 性能与体验怎么判断一个 AI 浏览器好不好用讨论了一堆概念落到工程层面衡量 AI 浏览器或浏览器 Agent 的质量核心看几个指标。第一个是任务成功率。在测试集里给定 N 个任务Agent 完全成功完成的比例是多少。测试任务要从简单到复杂分层至少包括信息提取类、表单填写类、多页面跳转类、异常恢复类。没有测试集就谈性能基本是空谈。第二个是平均步数和耗时。同一个任务如果 Agent 需要 15 步而人工只需要 3 步即使成功了体验也很差。可以用“任务完成耗时”和“用户可接受的等待时间”做对比。实测时重点观察每个操作之间的等待时间很多失败其实是因为页面还没加载完成Agent 就开始下一步操作了。第三个是 Token 消耗和成本。页面状态要转换成自然语言摘要喂给模型长页面会产生大量 Token。同一个任务在不同产品里Token 消耗可能差 10 倍。批量处理场景必须关注这个指标否则会陷入“帮用户省了时间但成本高到无法商业化”的困境。第四个是安全违规率。统计 Agent 在执行过程中是否出现了越权操作、敏感信息泄漏或未授权提交等行为。这个指标在开发阶段容易被忽略到用户量上来之后会变成最重要的问题。性能观察建议用测试脚本自动化跑比如固定 50 个任务每小时跑一轮记录成功率、步骤数、耗时、Token 消耗。不要靠人工肉眼判断数据集中对比才有意义。资源占用方面浏览器 Agent 主要吃内存和 CPU如果本地跑模型还要看显存。但具体数值取决于内核版本、页面复杂度和模型路线必须按实际测试场景测量不能拍脑袋给结论。8. 现在入局最容易踩的坑做 AI 浏览器相关的产品有一个清单是避不开的。这里把常见问题整理成表格方便开发者和产品经理对照检查坑点现象原因建议过度依赖 Chromium开发速度很快但每个版本都要同步上游安全更新内核维护成本被低估明确是否长期维护内核或选择扩展形态规避用户留存低用户试用一次后不用了AI 功能没有形成高频使用习惯把 AI 能力埋进用户高频操作而不是放在独立入口任务正确率不稳定同样的任务有时候成功有时候失败页面结构动态变化模型规划不稳定建立回归测试集每次改版后全量跑一遍Token 消耗失控单次任务成本过高页面上下文没有做摘要裁剪限定页面输入长度优先使用结构化抽取安全权限过宽用户担心 Agent 乱操作权限设计没有分级敏感操作二次确认高风险操作默认禁止网页风控导致账号受限用户反馈平台账号异常自动化行为特征明显控制操作节奏延迟随机化只在授权场景执行技术栈绑定单一模型模型一更新产品行为就变没有抽象模型层用中间层统一模型接口可切换多模型以上问题里最容易低估的是“任务正确率不稳定”和“Token 消耗失控”。前者决定了产品能不能用后者决定了产品能不能活。建议在项目启动第一周就建立评测集和成本监控而不是等到上线后再补。9. 合规与安全边界AI 浏览器和浏览器 Agent 涉及的用户隐私和数据安全比普通应用更敏感。浏览器能读取用户浏览的几乎所有页面内容包括登录态、个人信息、支付信息等。产品设计必须遵守几个底线原则。第一数据最小化。只在任务需要时才读取页面内容不需要访问的域名和内容一律不采集。不要把整个页面源码传给模型优先做结构化抽取把必要字段传给模型。第二用户授权确认。涉及提交操作、支付操作、发布操作时必须让用户明确确认不能在后台静默执行。第三日志脱敏。任务日志里不能记录密码、Cookie、Token、完整表单内容需要保留的数据要做脱敏和加密处理。第四模型输出审查。Agent 生成的回复不能直接作为最终结果展示要做一轮内容校验防止出现错误信息、不当内容或伪造的引用来源。在版权方面浏览器对网页内容的抓取、存储、二次生成需要符合内容来源网站的授权要求。做批量采集时尤其要注意 robots 协议和使用条款不能把抓取结果直接用于商业用途。涉及用户个人数据的处理必须落实隐私政策、数据主体权利响应和最小授权要求。这些不是合规部门的额外负担而是 AI 浏览器类产品能否长期存在的底线。一旦在安全边界上出事失去的不只是用户信任还有整个行业的生存空间。10. 这条窄路具体怎么走回到开头的问题AI 浏览器只剩一条窄路这条路到底是什么从产品形态上看它不是再做一款独立浏览器而是把 AI 能力嵌入到用户已经有的浏览环境里。Chrome 扩展、Edge 侧边栏、桌面端 Agent这些都是可选的载体。从技术路径上看它不是重新发明内核而是围绕“感知 - 规划 - 执行 - 记忆”这套 Agent 能力做工程化。从商业路径上看它不是面向所有用户的通用入口而是聚焦高价值垂直场景按任务结果和效率提升收费。对开发者来说最值得先做的不是 App不是浏览器而是一个带有评测集的浏览器 Agent 原型。先收集一批真实任务跑出成功率和成本数据再决定适合走哪个方向。如果跑了一周连测试集里的 50 个任务都没有稳定完成那说明当前技术路线还需要优化如果稳定了再考虑扩展、MCP 还是垂直产品。对团队来说选择 AI 浏览器相关方向要有意识地避开通用浏览器战场。与其做一个“什么都能干但什么都不精”的浏览器不如做一个在特定工作流里替代人工操作的工具。窄意味着用户需求明确意味着可以做深意味着有付费意愿也意味着不容易被巨头的一键集成直接覆盖。AI 浏览器这个概念还会继续演化。只是它的终局形态大概率不是一个孤零零的浏览器图标而是散布在各类软件里的 Agent 能力。谁能把这些能力做得更稳、更省、更安全谁就在这条窄路上拿到了真正的通行证。