如果你是一个经常刷 AI 资讯的开发者最近应该看到过类似的消息OpenAI 又在浏览器方向搞动作然后又撤了。老实说AI 浏览器的赛道最近特别热闹但也很混乱。有人觉得把大模型塞进浏览器就是下一代入口有人觉得这不过是套了一层 AI 壳的 Chrome。我的判断是纯工具层面的 AI 浏览器基本没有活路。真正值得做的是往 Agent 入口和本地上下文管理方向走。这个判断不是我拍脑袋而是从 OpenAI 自身的动作变化里能看出来的。这篇文章不是给你盘点又出了哪个新浏览器而是想和你一起把 AI 浏览器这件事想透它卡在哪、为什么卡、还有哪条路能走。如果你是做 AI 应用、浏览器插件、Agent 工具链的开发者或者你只是想知道自己该不该上手研究 AI 浏览器这篇文章应该能帮你省下不少试错时间。1. 这篇文章真正要解决的问题先问一个实际问题你今天打开浏览器日常操作是什么大概率是登录网页、看文档、查资料、开多个标签页、复制粘贴、偶尔填个表单。这个过程很碎片也很“手工”。AI 浏览器想做的事就是把这套手工流程变成对话式操作你告诉它“帮我查一下最近三天 OpenAI 的新闻整理成要点”它自己打开网页、搜索、抓取、总结、给你一份结果。听起来很美好但问题来了这种能力到底是浏览器的核心功能还是只是一个插件如果 Chrome 和 Edge 都能通过插件实现那独立 AI 浏览器的护城河在哪如果 AI 调用 API 的成本由浏览器厂商承担那商业模式是什么如果用户输入的是敏感信息浏览器厂商怎么保证隐私和安全这四件事恰恰是 AI 浏览器从“演示很酷”到“产品可用”之间最大的坎。这篇文章会围绕“Agent 入口”和“本地上下文”这两个关键词展开给你一条可落地的分析和实践路径。如果你是开发者看完之后可以自己搭一个最小示例验证 AI 浏览器的核心流程。2. AI 浏览器的核心概念与三条技术路线在讨论 AI 浏览器之前得先分清三个容易混淆的概念。传统的“浏览器 AI 插件”浏览器还是那个浏览器AI 只是一个悬浮窗或者侧边栏。比如你选中一段文字插件帮你翻译、总结、解释。这种模式对浏览器内核没有任何改变体验是割裂的但胜在实现简单、成本低。原生 AI 浏览器浏览器从底层就集成了大模型能力。地址栏可以用自然语言输入页面内容可以实时被 AI 解析浏览器能理解上下文并辅助操作。代表性思路包括 Edge 的 Copilot、一些创业公司做的“AI-first 浏览器”。这种路线的核心优势是 AI 不再是附加功能而是浏览器的主交互方式。Agent 操作系统Agent OS这是更激进的一步。浏览器不再是“网页查看器”而是 Agent 的运行环境。AI 可以像人一样操作页面点击按钮、填写表单、读取数据、跨站点完成任务。这就是 OpenAI 之前探索的方向也是 Anthropic 的 Computer Use 尝试的方向。这三条路线的本质区别在于AI 是在帮你看还是在替你做事。帮你看信息入口层面的增强例如总结、翻译、推荐。替你做事行为执行层面的替代例如比价下单、订票、批量采集。前者是“信息差生意”后者是“任务代理生意”。信息差生意很难收费因为用户随时可以切回原生浏览器任务代理生意有真实价值但技术难度和安全责任成倍增加。我觉得单纯做“帮你看”的 AI 浏览器基本只剩一条窄路。你仔细想想如果 AI 只是把网页总结一下那么任何浏览器厂商在自家产品里加一个总结按钮就行不需要用户特意下载一个新浏览器。用户没有切换成本自然也没有忠诚度。真正能留住用户的是让 AI 浏览器成为一个可以持续积累用户上下文、记住偏好、代为执行任务的 Agent 入口。但这条路极难走OpenAI 的撤退恰恰证明了这一点。3. OpenAI 在浏览器方向的动作与战略收缩从公开信息看OpenAI 对浏览器生态一直很重视但动作非常谨慎。它没有像一些人预期的那样推出一款“ChatGPT 浏览器”而是更多地做了两件事一是推出 ChatGPT 浏览器插件在 Chrome、Edge 等主流浏览器中植入 AI 能力让用户不用离开当前页面就能调用模型。二是把重心转向 Codex 这类 Agent 工具链。Codex 可以在沙箱环境中执行代码、操作文件、调用命令行本质上是把 Agent 的执行环境从浏览器迁移到了云端开发环境。为什么说这是战略收缩因为做一款独立浏览器意味着要维护浏览器内核、处理网页兼容性、跟进无数 Web 标准这和大模型公司的核心能力并不匹配。OpenAI 真正的优势在模型层和 Agent 编排层而不是浏览器底层。与其从 Google 手里抢浏览器份额不如让 ChatGPT 插件出现在每一个浏览器里。这个选择给行业传递了一个很直接的信号大模型公司不想做浏览器它们想做的是浏览器里的“大脑”。谁来做“手脚”谁来提供“记忆”这是一个开放的位置。所以AI 浏览器创业者如果站在“和 Chrome 抢用户”的角度基本是在打一场没有胜算的仗。但如果站在“成为 AI Agent 的交互层”的角度可能还有机会。4. AI 浏览器的“窄路”到底在哪我们不妨把 AI 浏览器的价值拆成四个层面交互层、上下文层、执行层、生态层。4.1 交互层自然语言地址栏自然语言地址栏是目前最容易被感知的创新。用户不用记住网址直接输入“打开 B 站搜索 AI 编程教程”浏览器自动完成搜索。实现难度不高本质上用大模型解析意图再拼装搜索 URL。但它的价值有限因为搜索引擎本身就是最大的入口用户绕不开搜索页。可做的增强是地址栏不只是跳转而是能直接调起 Agent 任务。例如输入“把这篇文档翻译成英文并发给同事”浏览器调用翻译工具和邮件服务完成操作。这需要浏览器有 API 编排能力已经开始靠近 Agent 了。4.2 上下文层本地记忆与偏好管理这是我认为最核心、也是最被低估的一层。用户浏览网页时会产生大量上下文关注哪些技术方向、常看的文档站点、常用的表单信息、对某种内容风格的偏好。传统浏览器通过书签和历史记录管理这些信息但它们是静态的、结构化的AI 很难直接利用。AI 浏览器如果能把浏览历史、阅读内容、操作习惯转化为可检索的向量数据库让模型在生成回答时可以引用用户自己的“历史上下文”那这个浏览器就拥有了数据壁垒。用户用得越久AI 越懂他迁移成本就越高。这个方向对隐私要求极高。合理做法是所有上下文在本地处理和存储只有在用户明确授权时才上传到云端。这需要浏览器有很强的本地嵌入模型能力和加密存储方案而不是简单地“把数据发给大模型”。4.3 执行层Agent 安全操作网页让 AI 代替用户操作网页是技术门槛最高的一层。难点有三一是网页结构千变万化AI 需要从 DOM 中准确找到目标元素二是操作过程需要验证点错按钮的代价可能很大三是多步骤任务需要实时推理当前大模型的延迟和准确性还不能保证复杂任务的稳定完成。一个典型的折中方案是让 Agent 先生成操作计划然后分步执行每步都让用户确认。这种方式虽然牺牲了“全自动”的体验但能规避大部分误操作风险。我觉得现阶段“半自动 用户确认”是比“全自动无人值守”更现实的产品形态。4.4 生态层开放协议与插件体系AI 浏览器不能什么都自己做。它需要让第三方开发者贡献技能包Skill比如一个“查询航班”技能、一个“监控价格”技能。这类似于手机上的 App Store但技能包直接与浏览器内核交互权限模型更复杂。从生态角度看谁先定义了 Agent 技能的标准格式谁就可能成为平台。但当前的问题是OpenAI 在推自己的工具调用协议Anthropic 也在推自己的 API 风格各家的技能包不能互相通用开发者不知道该为哪个平台开发。5. 可落地的实验用 Playwright 加 OpenAI 兼容接口搭一个最小 AI 浏览器 Agent说了这么多接下来进入实操环节。我们用一个最小实验验证 AI 浏览器的核心链路接收自然语言指令、解析意图、调用浏览器自动化、总结结果。这个实验用 Python 编写核心组件是 Playwright 和 OpenAI 兼容 API。整体思路是先用模型解析用户指令生成目标 URL 和搜索词再用 Playwright 打开页面并抓取内容最后把内容交给模型总结。5.1 环境准备建议使用 Python 3.10 及以上版本安装以下依赖pip install playwright openai playwright install chromium如果你在服务器环境运行需要先安装 Playwright 的系统依赖playwright install-deps注意OpenAI 兼容接口可以填官方接口也可以填支持该协议的网关地址。为了避免把密钥硬编码到代码中建议通过环境变量传入。5.2 核心代码自然语言驱动浏览器下面是完整的示例代码。它只实现了一个很简单的流程用户输入“在必应搜索 xxx把第一条结果的标题和摘要告诉我”程序会调用大模型生成搜索 URL然后用 Playwright 打开页面并抽取内容。# 文件路径ai_browser_demo.py import os import json from openai import OpenAI from playwright.sync_api import sync_playwright client OpenAI( api_keyos.environ.get(LLM_API_KEY), base_urlos.environ.get(LLM_BASE_URL), ) def parse_command(command: str) - dict: 把自然语言指令解析为浏览器操作。 这里只做一个简化版本真实产品需要更强的 Agent 编排。 prompt f 你是一个浏览器操作助手。请把用户的指令解析成 JSON。 JSON 必须包含: - engine: 搜索引擎例如 bing - query: 搜索关键词 - action: 可选值 search / open 用户指令{command} 只输出 JSON不要输出额外文字。 response client.chat.completions.create( modelos.environ.get(LLM_MODEL, gpt-4o-mini), messages[{role: user, content: prompt}], temperature0, ) content response.choices[0].message.content.strip() # 清理可能的 json 标记 if content.startswith(): content content.strip() if content.startswith(json): content content[4:] return json.loads(content) def run_search(query: str): 使用 Playwright 打开必应搜索取第一条结果。 这里仅为演示生产环境应增加页面选择和结果抽取策略。 search_url fhttps://www.bing.com/search?q{query} with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(search_url, timeout30000) # 等待搜索结果出现 page.wait_for_selector(li.b_algo, timeout15000) # 取第一条结果 first_result page.locator(li.b_algo).first title first_result.locator(h2).inner_text() snippet first_result.locator(.b_caption p).inner_text() browser.close() return title, snippet def summarize(title: str, snippet: str) - str: 让模型对抓取内容做摘要模拟 AI 浏览器的结果输出。 prompt f请基于下面的搜索结果用 100 字以内给用户一个简洁回答。\n标题{title}\n摘要{snippet} response client.chat.completions.create( modelos.environ.get(LLM_MODEL, gpt-4o-mini), messages[{role: user, content: prompt}], temperature0.3, ) return response.choices[0].message.content.strip() if __name__ __main__: import sys cmd sys.argv[1] if len(sys.argv) 1 else 帮我搜索OpenAI 最新动态 parsed parse_command(cmd) print(解析结果, parsed) title, snippet run_search(parsed[query]) print(搜索结果标题, title) print(搜索结果摘要, snippet) print(AI 总结, summarize(title, snippet))这段代码的价值不在于它有多完善而在于它还原了 AI 浏览器的最小工作链路第一段解析指令说明 LLM 可以充当浏览器操作的“意图识别中枢”。第二段执行搜索说明浏览器自动化可以把模型输出变成真实网页操作。第三段生成总结说明抓取的内容还需要模型二次加工才能形成对用户有价值的信息。5.3 运行与验证设置好环境变量后运行示例export LLM_API_KEY你的密钥 export LLM_BASE_URLhttps://api.openai.com/v1 export LLM_MODELgpt-4o-mini python ai_browser_demo.py预期输出大致是解析结果 {engine: bing, query: OpenAI 最新动态, action: search} 搜索结果标题 OpenAI 最新动态 - 必应 搜索结果摘要 这里会显示必应第一条结果的摘要内容 AI 总结 根据最新搜索结果OpenAI 在模型和产品层面都有新动作……这段代码能不能直接上线不能。它只是验证“自然语言 - 浏览器操作 - 内容总结”这个闭环是否成立。真实的 AI 浏览器还需要考虑页面结构变化、验证码、登录态、反爬机制、异常恢复等一系列问题。5.4 进阶围绕浏览器 Agent 做操作确认如果你想让这个示例更接近真实产品可以加一个“操作确认”环节模型生成操作计划后不直接执行而是打印给用户确认。def plan_and_confirm(command: str) - bool: 模拟 Agent 操作前的用户确认环节。 真实产品中这里会展示操作计划、风险提示和目标说明。 parsed parse_command(command) print(即将执行以下操作) print(json.dumps(parsed, ensure_asciiFalse, indent2)) confirm input(是否继续(y/n): ) return confirm.lower() y这一步在工程上非常重要。AI 浏览器的自动化操作一旦越权轻则退回误操作重则泄露用户数据。加一个确认环节既能降低风险也能缓解用户对“AI 浏览器不信任”的问题。6. 如何判断一个 AI 浏览器值不值得用这里给技术选型者一套可以落地的评估指标不神话、不贬低只看结果。6.1 判定维度一上下文记忆能力传统浏览器只会记住你访问过的 URLAI 浏览器应该能够记住你反复关注的主题。你常驻的文档站点。你的信息筛选偏好。你已经处理过的任务状态。测试方法连续用同一浏览器完成三次同类任务比如三次查询 AI Agent 框架资料。如果第三次回答仍然像第一次那样“冷启动”说明它的记忆能力是假的只是简单拼接了历史记录。6.2 判定维度二任务闭环率给 AI 浏览器下达一个多步骤任务例如在 GitHub 上找到最近一周 star 增长最快的 AI Agent 项目然后打开它的 README总结安装方式。你要看它是否能完整走完这一系列步骤还是只跳到 GitHub 搜索页就停住。这个指标可以量化闭环率 成功完成全流程任务数 / 总测试任务数。6.3 判定维度三本地隐私边界检查它的设置页面看它是否提供以下能力本地向量索引开关。历史数据清理按钮。云端与本地处理的透明度说明。无痕模式下是否停止记录上下文。如果这些都没有那它只是把大模型插件重新包装了一遍。7. AI 浏览器开发中的常见问题与排查方法下面这些问题是做浏览器自动化 Agent 时最容易遇到的我给出一张排查表方便你对照处理。问题现象可能原因排查方式解决方案Playwright 启动浏览器失败缺少系统依赖库运行playwright install-deps查看缺什么安装对应系统依赖重新启动页面元素定位不到网站改版、动态渲染打开 DevTools 查看真实结构尝试wait_for_selector改用稳定的文本选择器或 XPath优先使用元素的 aria 标签大模型 API 返回超时网络波动或模型负载高打印请求耗时观察重试日志增加超时时间加入指数退避重试逻辑搜索结果被反爬拦截频繁请求触发风控查看页面返回状态码和页面标题降低请求频率使用合理的 User-Agent必要时候用官方搜索 API模型输出的 JSON 解析失败输出带 markdown 标记或多余文字打印原始返回内容在后处理中清理 json 标记或使用 JSON 模式多步骤任务中途断掉页面跳转后上下文丢失检查页面跳转后是否仍然持有原 Page 对象显式等待新页面加载重新定位元素上下文数据量太大本地向量库没有做切分检查索引文档大小按段落分块按域名或时间戳打标签控制单条索引长度这里特别提醒一点手动操作浏览器时不要对没有授权的站点做大规模自动化采集。自动化和合规之间的边界需要在项目启动前就明确下来。8. 从开发角度再看 AI 浏览器如果这个方向是有价值的那从开发角度来说我们到底应该怎么做与其纠结“做不做浏览器”不如想想怎么把现有浏览器变成 Agent 的交互层。8.1 把浏览器当作 Agent 的执行引擎对开发者来说浏览器本身就是一个天然的程序运行环境。你可以用扩展Extension的方式把 Agent 能力植入现有浏览器。Chrome Extension 支持从 background script 发起网络请求、读取页面 DOM、操作标签页这些足以支撑大部分 AI 浏览器的功能原型。扩展相比独立浏览器最大的好处是可以复用 Chrome 的用户基础和生态不用从零做内核。另一个好处是扩展可以体验现有的浏览器侧栏降低开发成本。8.2 用“侧边栏 本地服务”做记忆层AI 浏览器的记忆层可以做得轻量本地起一个 SQLite 或 LanceDB存储浏览历史的向量索引。Chrome 扩展通过 sidePanel API 展示 AI 对话界面后台在本地完成文本嵌入和相似度检索。这样既不需要自研浏览器也能实现“越用越懂你”的效果。这里有一个技术上的注意点浏览器扩展的 Service Worker 生命周期不可控不适合做长时任务。更稳妥的做法是在本地启动一个 Python/Node 服务通过 WebSocket 或 HTTP 与扩展通信。搜索、抓取、总结都交给本地服务扩展只负责渲染和交互。8.3 用 Agent 协议做任务编排如果你希望 AI 浏览器能执行多步骤任务需要一套任务编排机制。简单说就是“规划 - 执行 - 校验 - 修正”的循环。规划阶段由大模型生成操作序列执行阶段由 Playwright 或扩展 API 操作页面校验阶段要设定明确的成功条件如果校验失败就把错误信息反馈给模型让它生成新的方案。这就是 ReAct 模式在浏览器场景下的应用。你可以先用现成的 Agent 框架比如 LangChain、LlamaIndex跑通一个简单任务再逐步替换成自己的编排逻辑。关键是不要一上来就追求全自动先把单步操作做稳。9. 面向产品经理和企业决策者的建议如果你不是纯开发角色而是负责产品方向或技术选型我给三条建议。第一现在不要急着从“重新发明浏览器”切入。先观察 ChatGPT 插件、各类浏览器扩展的留存数据。如果用户装完插件后一周内就卸载说明“AI 总结网页”这个需求还没有强到让人改变习惯。第二AI 浏览器的价值在“任务时长”和“任务深度”而不仅是“打开次数”。如果用户一周只打开一次这个产品大概率做不起来如果用户每天通过它完成 3 个以上原本要切 5 个站点的任务这个产品就有机会。第三关注模型侧的变化。Anthropic 的 Computer Use、OpenAI 的 Agent API、各类本地小模型都在快速迭代。浏览器端的 Agent 能力会越来越标准化今天自研的东西明年可能变成某个开源库的一行配置。所以架构上尽量保持灵活把核心资产放在用户数据理解和任务流程设计上而不是底层浏览器自动化细节。10. 小结AI 浏览器能做但别再往“浏览器”上靠回到标题的问题OpenAI 都撤了AI 浏览器到底还剩什么在我看来纯做“给浏览器加 AI 功能”确实只剩窄路但把浏览器理解成“AI Agent 的交互与记忆层”空间仍然很大。区别只是你把自己定位成工具还是定位成入口。如果你定位成工具用户会拿你和其他 100 个类似扩展比最后比的是谁便宜、谁快。如果你定位成“记录用户上下文、代为执行任务”的 Agent 入口用户一旦形成依赖替代成本就会高很多。对开发者来说现在最值得做的不是造一个浏览器内核而是做一套“浏览器外挂”形态的 Agent 框架一边接入大模型做意图理解一边用 Playwright 做网页操作一边用本地向量库记录用户上下文。这套最小闭环并不难搭真正的壁垒在数据积累和任务流程设计上。下一篇文章我打算深入写一下“浏览器 Agent 的本地记忆层”怎么做包括向量索引选型、隐私边界设计和多标签页任务编排。如果你正在做相关方向可以先把这个最小示例跑通我们再往里加东西。收藏这篇文章等你开始动手做 Agent 浏览器实验时能省不少查资料的时间。 AI浏览器还能做吗？从Agent入口到本地上下文全解析
如果你是一个经常刷 AI 资讯的开发者最近应该看到过类似的消息OpenAI 又在浏览器方向搞动作然后又撤了。老实说AI 浏览器的赛道最近特别热闹但也很混乱。有人觉得把大模型塞进浏览器就是下一代入口有人觉得这不过是套了一层 AI 壳的 Chrome。我的判断是纯工具层面的 AI 浏览器基本没有活路。真正值得做的是往 Agent 入口和本地上下文管理方向走。这个判断不是我拍脑袋而是从 OpenAI 自身的动作变化里能看出来的。这篇文章不是给你盘点又出了哪个新浏览器而是想和你一起把 AI 浏览器这件事想透它卡在哪、为什么卡、还有哪条路能走。如果你是做 AI 应用、浏览器插件、Agent 工具链的开发者或者你只是想知道自己该不该上手研究 AI 浏览器这篇文章应该能帮你省下不少试错时间。1. 这篇文章真正要解决的问题先问一个实际问题你今天打开浏览器日常操作是什么大概率是登录网页、看文档、查资料、开多个标签页、复制粘贴、偶尔填个表单。这个过程很碎片也很“手工”。AI 浏览器想做的事就是把这套手工流程变成对话式操作你告诉它“帮我查一下最近三天 OpenAI 的新闻整理成要点”它自己打开网页、搜索、抓取、总结、给你一份结果。听起来很美好但问题来了这种能力到底是浏览器的核心功能还是只是一个插件如果 Chrome 和 Edge 都能通过插件实现那独立 AI 浏览器的护城河在哪如果 AI 调用 API 的成本由浏览器厂商承担那商业模式是什么如果用户输入的是敏感信息浏览器厂商怎么保证隐私和安全这四件事恰恰是 AI 浏览器从“演示很酷”到“产品可用”之间最大的坎。这篇文章会围绕“Agent 入口”和“本地上下文”这两个关键词展开给你一条可落地的分析和实践路径。如果你是开发者看完之后可以自己搭一个最小示例验证 AI 浏览器的核心流程。2. AI 浏览器的核心概念与三条技术路线在讨论 AI 浏览器之前得先分清三个容易混淆的概念。传统的“浏览器 AI 插件”浏览器还是那个浏览器AI 只是一个悬浮窗或者侧边栏。比如你选中一段文字插件帮你翻译、总结、解释。这种模式对浏览器内核没有任何改变体验是割裂的但胜在实现简单、成本低。原生 AI 浏览器浏览器从底层就集成了大模型能力。地址栏可以用自然语言输入页面内容可以实时被 AI 解析浏览器能理解上下文并辅助操作。代表性思路包括 Edge 的 Copilot、一些创业公司做的“AI-first 浏览器”。这种路线的核心优势是 AI 不再是附加功能而是浏览器的主交互方式。Agent 操作系统Agent OS这是更激进的一步。浏览器不再是“网页查看器”而是 Agent 的运行环境。AI 可以像人一样操作页面点击按钮、填写表单、读取数据、跨站点完成任务。这就是 OpenAI 之前探索的方向也是 Anthropic 的 Computer Use 尝试的方向。这三条路线的本质区别在于AI 是在帮你看还是在替你做事。帮你看信息入口层面的增强例如总结、翻译、推荐。替你做事行为执行层面的替代例如比价下单、订票、批量采集。前者是“信息差生意”后者是“任务代理生意”。信息差生意很难收费因为用户随时可以切回原生浏览器任务代理生意有真实价值但技术难度和安全责任成倍增加。我觉得单纯做“帮你看”的 AI 浏览器基本只剩一条窄路。你仔细想想如果 AI 只是把网页总结一下那么任何浏览器厂商在自家产品里加一个总结按钮就行不需要用户特意下载一个新浏览器。用户没有切换成本自然也没有忠诚度。真正能留住用户的是让 AI 浏览器成为一个可以持续积累用户上下文、记住偏好、代为执行任务的 Agent 入口。但这条路极难走OpenAI 的撤退恰恰证明了这一点。3. OpenAI 在浏览器方向的动作与战略收缩从公开信息看OpenAI 对浏览器生态一直很重视但动作非常谨慎。它没有像一些人预期的那样推出一款“ChatGPT 浏览器”而是更多地做了两件事一是推出 ChatGPT 浏览器插件在 Chrome、Edge 等主流浏览器中植入 AI 能力让用户不用离开当前页面就能调用模型。二是把重心转向 Codex 这类 Agent 工具链。Codex 可以在沙箱环境中执行代码、操作文件、调用命令行本质上是把 Agent 的执行环境从浏览器迁移到了云端开发环境。为什么说这是战略收缩因为做一款独立浏览器意味着要维护浏览器内核、处理网页兼容性、跟进无数 Web 标准这和大模型公司的核心能力并不匹配。OpenAI 真正的优势在模型层和 Agent 编排层而不是浏览器底层。与其从 Google 手里抢浏览器份额不如让 ChatGPT 插件出现在每一个浏览器里。这个选择给行业传递了一个很直接的信号大模型公司不想做浏览器它们想做的是浏览器里的“大脑”。谁来做“手脚”谁来提供“记忆”这是一个开放的位置。所以AI 浏览器创业者如果站在“和 Chrome 抢用户”的角度基本是在打一场没有胜算的仗。但如果站在“成为 AI Agent 的交互层”的角度可能还有机会。4. AI 浏览器的“窄路”到底在哪我们不妨把 AI 浏览器的价值拆成四个层面交互层、上下文层、执行层、生态层。4.1 交互层自然语言地址栏自然语言地址栏是目前最容易被感知的创新。用户不用记住网址直接输入“打开 B 站搜索 AI 编程教程”浏览器自动完成搜索。实现难度不高本质上用大模型解析意图再拼装搜索 URL。但它的价值有限因为搜索引擎本身就是最大的入口用户绕不开搜索页。可做的增强是地址栏不只是跳转而是能直接调起 Agent 任务。例如输入“把这篇文档翻译成英文并发给同事”浏览器调用翻译工具和邮件服务完成操作。这需要浏览器有 API 编排能力已经开始靠近 Agent 了。4.2 上下文层本地记忆与偏好管理这是我认为最核心、也是最被低估的一层。用户浏览网页时会产生大量上下文关注哪些技术方向、常看的文档站点、常用的表单信息、对某种内容风格的偏好。传统浏览器通过书签和历史记录管理这些信息但它们是静态的、结构化的AI 很难直接利用。AI 浏览器如果能把浏览历史、阅读内容、操作习惯转化为可检索的向量数据库让模型在生成回答时可以引用用户自己的“历史上下文”那这个浏览器就拥有了数据壁垒。用户用得越久AI 越懂他迁移成本就越高。这个方向对隐私要求极高。合理做法是所有上下文在本地处理和存储只有在用户明确授权时才上传到云端。这需要浏览器有很强的本地嵌入模型能力和加密存储方案而不是简单地“把数据发给大模型”。4.3 执行层Agent 安全操作网页让 AI 代替用户操作网页是技术门槛最高的一层。难点有三一是网页结构千变万化AI 需要从 DOM 中准确找到目标元素二是操作过程需要验证点错按钮的代价可能很大三是多步骤任务需要实时推理当前大模型的延迟和准确性还不能保证复杂任务的稳定完成。一个典型的折中方案是让 Agent 先生成操作计划然后分步执行每步都让用户确认。这种方式虽然牺牲了“全自动”的体验但能规避大部分误操作风险。我觉得现阶段“半自动 用户确认”是比“全自动无人值守”更现实的产品形态。4.4 生态层开放协议与插件体系AI 浏览器不能什么都自己做。它需要让第三方开发者贡献技能包Skill比如一个“查询航班”技能、一个“监控价格”技能。这类似于手机上的 App Store但技能包直接与浏览器内核交互权限模型更复杂。从生态角度看谁先定义了 Agent 技能的标准格式谁就可能成为平台。但当前的问题是OpenAI 在推自己的工具调用协议Anthropic 也在推自己的 API 风格各家的技能包不能互相通用开发者不知道该为哪个平台开发。5. 可落地的实验用 Playwright 加 OpenAI 兼容接口搭一个最小 AI 浏览器 Agent说了这么多接下来进入实操环节。我们用一个最小实验验证 AI 浏览器的核心链路接收自然语言指令、解析意图、调用浏览器自动化、总结结果。这个实验用 Python 编写核心组件是 Playwright 和 OpenAI 兼容 API。整体思路是先用模型解析用户指令生成目标 URL 和搜索词再用 Playwright 打开页面并抓取内容最后把内容交给模型总结。5.1 环境准备建议使用 Python 3.10 及以上版本安装以下依赖pip install playwright openai playwright install chromium如果你在服务器环境运行需要先安装 Playwright 的系统依赖playwright install-deps注意OpenAI 兼容接口可以填官方接口也可以填支持该协议的网关地址。为了避免把密钥硬编码到代码中建议通过环境变量传入。5.2 核心代码自然语言驱动浏览器下面是完整的示例代码。它只实现了一个很简单的流程用户输入“在必应搜索 xxx把第一条结果的标题和摘要告诉我”程序会调用大模型生成搜索 URL然后用 Playwright 打开页面并抽取内容。# 文件路径ai_browser_demo.py import os import json from openai import OpenAI from playwright.sync_api import sync_playwright client OpenAI( api_keyos.environ.get(LLM_API_KEY), base_urlos.environ.get(LLM_BASE_URL), ) def parse_command(command: str) - dict: 把自然语言指令解析为浏览器操作。 这里只做一个简化版本真实产品需要更强的 Agent 编排。 prompt f 你是一个浏览器操作助手。请把用户的指令解析成 JSON。 JSON 必须包含: - engine: 搜索引擎例如 bing - query: 搜索关键词 - action: 可选值 search / open 用户指令{command} 只输出 JSON不要输出额外文字。 response client.chat.completions.create( modelos.environ.get(LLM_MODEL, gpt-4o-mini), messages[{role: user, content: prompt}], temperature0, ) content response.choices[0].message.content.strip() # 清理可能的 json 标记 if content.startswith(): content content.strip() if content.startswith(json): content content[4:] return json.loads(content) def run_search(query: str): 使用 Playwright 打开必应搜索取第一条结果。 这里仅为演示生产环境应增加页面选择和结果抽取策略。 search_url fhttps://www.bing.com/search?q{query} with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(search_url, timeout30000) # 等待搜索结果出现 page.wait_for_selector(li.b_algo, timeout15000) # 取第一条结果 first_result page.locator(li.b_algo).first title first_result.locator(h2).inner_text() snippet first_result.locator(.b_caption p).inner_text() browser.close() return title, snippet def summarize(title: str, snippet: str) - str: 让模型对抓取内容做摘要模拟 AI 浏览器的结果输出。 prompt f请基于下面的搜索结果用 100 字以内给用户一个简洁回答。\n标题{title}\n摘要{snippet} response client.chat.completions.create( modelos.environ.get(LLM_MODEL, gpt-4o-mini), messages[{role: user, content: prompt}], temperature0.3, ) return response.choices[0].message.content.strip() if __name__ __main__: import sys cmd sys.argv[1] if len(sys.argv) 1 else 帮我搜索OpenAI 最新动态 parsed parse_command(cmd) print(解析结果, parsed) title, snippet run_search(parsed[query]) print(搜索结果标题, title) print(搜索结果摘要, snippet) print(AI 总结, summarize(title, snippet))这段代码的价值不在于它有多完善而在于它还原了 AI 浏览器的最小工作链路第一段解析指令说明 LLM 可以充当浏览器操作的“意图识别中枢”。第二段执行搜索说明浏览器自动化可以把模型输出变成真实网页操作。第三段生成总结说明抓取的内容还需要模型二次加工才能形成对用户有价值的信息。5.3 运行与验证设置好环境变量后运行示例export LLM_API_KEY你的密钥 export LLM_BASE_URLhttps://api.openai.com/v1 export LLM_MODELgpt-4o-mini python ai_browser_demo.py预期输出大致是解析结果 {engine: bing, query: OpenAI 最新动态, action: search} 搜索结果标题 OpenAI 最新动态 - 必应 搜索结果摘要 这里会显示必应第一条结果的摘要内容 AI 总结 根据最新搜索结果OpenAI 在模型和产品层面都有新动作……这段代码能不能直接上线不能。它只是验证“自然语言 - 浏览器操作 - 内容总结”这个闭环是否成立。真实的 AI 浏览器还需要考虑页面结构变化、验证码、登录态、反爬机制、异常恢复等一系列问题。5.4 进阶围绕浏览器 Agent 做操作确认如果你想让这个示例更接近真实产品可以加一个“操作确认”环节模型生成操作计划后不直接执行而是打印给用户确认。def plan_and_confirm(command: str) - bool: 模拟 Agent 操作前的用户确认环节。 真实产品中这里会展示操作计划、风险提示和目标说明。 parsed parse_command(command) print(即将执行以下操作) print(json.dumps(parsed, ensure_asciiFalse, indent2)) confirm input(是否继续(y/n): ) return confirm.lower() y这一步在工程上非常重要。AI 浏览器的自动化操作一旦越权轻则退回误操作重则泄露用户数据。加一个确认环节既能降低风险也能缓解用户对“AI 浏览器不信任”的问题。6. 如何判断一个 AI 浏览器值不值得用这里给技术选型者一套可以落地的评估指标不神话、不贬低只看结果。6.1 判定维度一上下文记忆能力传统浏览器只会记住你访问过的 URLAI 浏览器应该能够记住你反复关注的主题。你常驻的文档站点。你的信息筛选偏好。你已经处理过的任务状态。测试方法连续用同一浏览器完成三次同类任务比如三次查询 AI Agent 框架资料。如果第三次回答仍然像第一次那样“冷启动”说明它的记忆能力是假的只是简单拼接了历史记录。6.2 判定维度二任务闭环率给 AI 浏览器下达一个多步骤任务例如在 GitHub 上找到最近一周 star 增长最快的 AI Agent 项目然后打开它的 README总结安装方式。你要看它是否能完整走完这一系列步骤还是只跳到 GitHub 搜索页就停住。这个指标可以量化闭环率 成功完成全流程任务数 / 总测试任务数。6.3 判定维度三本地隐私边界检查它的设置页面看它是否提供以下能力本地向量索引开关。历史数据清理按钮。云端与本地处理的透明度说明。无痕模式下是否停止记录上下文。如果这些都没有那它只是把大模型插件重新包装了一遍。7. AI 浏览器开发中的常见问题与排查方法下面这些问题是做浏览器自动化 Agent 时最容易遇到的我给出一张排查表方便你对照处理。问题现象可能原因排查方式解决方案Playwright 启动浏览器失败缺少系统依赖库运行playwright install-deps查看缺什么安装对应系统依赖重新启动页面元素定位不到网站改版、动态渲染打开 DevTools 查看真实结构尝试wait_for_selector改用稳定的文本选择器或 XPath优先使用元素的 aria 标签大模型 API 返回超时网络波动或模型负载高打印请求耗时观察重试日志增加超时时间加入指数退避重试逻辑搜索结果被反爬拦截频繁请求触发风控查看页面返回状态码和页面标题降低请求频率使用合理的 User-Agent必要时候用官方搜索 API模型输出的 JSON 解析失败输出带 markdown 标记或多余文字打印原始返回内容在后处理中清理 json 标记或使用 JSON 模式多步骤任务中途断掉页面跳转后上下文丢失检查页面跳转后是否仍然持有原 Page 对象显式等待新页面加载重新定位元素上下文数据量太大本地向量库没有做切分检查索引文档大小按段落分块按域名或时间戳打标签控制单条索引长度这里特别提醒一点手动操作浏览器时不要对没有授权的站点做大规模自动化采集。自动化和合规之间的边界需要在项目启动前就明确下来。8. 从开发角度再看 AI 浏览器如果这个方向是有价值的那从开发角度来说我们到底应该怎么做与其纠结“做不做浏览器”不如想想怎么把现有浏览器变成 Agent 的交互层。8.1 把浏览器当作 Agent 的执行引擎对开发者来说浏览器本身就是一个天然的程序运行环境。你可以用扩展Extension的方式把 Agent 能力植入现有浏览器。Chrome Extension 支持从 background script 发起网络请求、读取页面 DOM、操作标签页这些足以支撑大部分 AI 浏览器的功能原型。扩展相比独立浏览器最大的好处是可以复用 Chrome 的用户基础和生态不用从零做内核。另一个好处是扩展可以体验现有的浏览器侧栏降低开发成本。8.2 用“侧边栏 本地服务”做记忆层AI 浏览器的记忆层可以做得轻量本地起一个 SQLite 或 LanceDB存储浏览历史的向量索引。Chrome 扩展通过 sidePanel API 展示 AI 对话界面后台在本地完成文本嵌入和相似度检索。这样既不需要自研浏览器也能实现“越用越懂你”的效果。这里有一个技术上的注意点浏览器扩展的 Service Worker 生命周期不可控不适合做长时任务。更稳妥的做法是在本地启动一个 Python/Node 服务通过 WebSocket 或 HTTP 与扩展通信。搜索、抓取、总结都交给本地服务扩展只负责渲染和交互。8.3 用 Agent 协议做任务编排如果你希望 AI 浏览器能执行多步骤任务需要一套任务编排机制。简单说就是“规划 - 执行 - 校验 - 修正”的循环。规划阶段由大模型生成操作序列执行阶段由 Playwright 或扩展 API 操作页面校验阶段要设定明确的成功条件如果校验失败就把错误信息反馈给模型让它生成新的方案。这就是 ReAct 模式在浏览器场景下的应用。你可以先用现成的 Agent 框架比如 LangChain、LlamaIndex跑通一个简单任务再逐步替换成自己的编排逻辑。关键是不要一上来就追求全自动先把单步操作做稳。9. 面向产品经理和企业决策者的建议如果你不是纯开发角色而是负责产品方向或技术选型我给三条建议。第一现在不要急着从“重新发明浏览器”切入。先观察 ChatGPT 插件、各类浏览器扩展的留存数据。如果用户装完插件后一周内就卸载说明“AI 总结网页”这个需求还没有强到让人改变习惯。第二AI 浏览器的价值在“任务时长”和“任务深度”而不仅是“打开次数”。如果用户一周只打开一次这个产品大概率做不起来如果用户每天通过它完成 3 个以上原本要切 5 个站点的任务这个产品就有机会。第三关注模型侧的变化。Anthropic 的 Computer Use、OpenAI 的 Agent API、各类本地小模型都在快速迭代。浏览器端的 Agent 能力会越来越标准化今天自研的东西明年可能变成某个开源库的一行配置。所以架构上尽量保持灵活把核心资产放在用户数据理解和任务流程设计上而不是底层浏览器自动化细节。10. 小结AI 浏览器能做但别再往“浏览器”上靠回到标题的问题OpenAI 都撤了AI 浏览器到底还剩什么在我看来纯做“给浏览器加 AI 功能”确实只剩窄路但把浏览器理解成“AI Agent 的交互与记忆层”空间仍然很大。区别只是你把自己定位成工具还是定位成入口。如果你定位成工具用户会拿你和其他 100 个类似扩展比最后比的是谁便宜、谁快。如果你定位成“记录用户上下文、代为执行任务”的 Agent 入口用户一旦形成依赖替代成本就会高很多。对开发者来说现在最值得做的不是造一个浏览器内核而是做一套“浏览器外挂”形态的 Agent 框架一边接入大模型做意图理解一边用 Playwright 做网页操作一边用本地向量库记录用户上下文。这套最小闭环并不难搭真正的壁垒在数据积累和任务流程设计上。下一篇文章我打算深入写一下“浏览器 Agent 的本地记忆层”怎么做包括向量索引选型、隐私边界设计和多标签页任务编排。如果你正在做相关方向可以先把这个最小示例跑通我们再往里加东西。收藏这篇文章等你开始动手做 Agent 浏览器实验时能省不少查资料的时间。