浏览器本身,正在从"打开网页的工具"变成"agent 的执行环境" 2026 年的浏览器市场已经不再是单纯的渲染引擎之争。Perplexity Comet 把搜索框搬进地址栏、用 AI agent 替代用户翻网页;OpenAI 在 2025 年 10 月推出 ChatGPT Atlas,半年后传出"shutting down"的消息,但 OWL 架构里的"智能体模式"已经成为后续产品的事实标准;A
浏览器本身,正在从"打开网页的工具"变成"agent 的执行环境"
2026 年的浏览器市场已经不再是单纯的渲染引擎之争。Perplexity Comet 把搜索框搬进地址栏、用 AI agent 替代用户翻网页;OpenAI 在 2025 年 10 月推出 ChatGPT Atlas,半年后传出"shutting down"的消息,但 OWL 架构里的"智能体模式"已经成为后续产品的事实标准;Anthropic 在 2026 年 8 月把 Claude in Chrome 推上 GA(General Availability),用户可以让 Claude 在浏览器里自主完成长任务;Google 把 Gemini in Chrome 的 auto browse 能力开放给所有 Android 美国用户。三家厂商,四种实现路径,但都在做同一件事——把浏览器变成 agent 真正能住进去、动手做事的地方。
本文对照两份 2026 年 8 月底前后的厂商一手材料,一份来自 Google Chrome 团队的 Gemini in Chrome + auto browse 发布博客,一份来自 Anthropic 的 Claude in Chrome GA 公告与配套的 prompt injection 防御说明,把这场浏览器 agent 主战场的技术差异拉回到具体产品决策和工程取舍上来谈。
一、Google 的路径:Gemini 在 Chrome 里"长出"了 agent 能力
2026 年 8 月 18 日,Google Chrome 产品总监 Charmaine Dsilva 在官方博客发布《Tap into the power of Gemini in Chrome on Android》,宣布 Gemini in Chrome 已经向所有美国 Android 用户开放。更关键的是,她同时披露了 AI Pro 和 AI Ultra 订阅用户在 Android 端可以用到"agentic capabilities with auto browse"——也就是浏览器内的自动浏览能力。
Google 给出的 agent 能力定义非常具体,对应到三个日常任务场景:为活动预订停车位、修改一个长期生效的在线订单、为下一次度假安排行程。这三个场景有一个共同特征:都涉及"跨多个页面、跨多个操作步骤、需要用户登录态才能完成"的工作——也就是传统上必须由人坐在电脑前一步步操作的任务。Google 把这类任务交给 auto browse 之后,用户的角色从"亲自操作"变成了"确认关键节点"。
从安全设计上,Google 的实现走的是两道并行的防线。第一道是模型层面:Google 在博客里明确说"Our models are trained to detect known threats, such as prompt injection"——也就是直接针对 prompt injection 这类攻击模式做训练。Prompt injection 是浏览器 agent 最致命的安全风险,攻击者可以在网页里、邮件正文里、表单字段里藏一段不可见的指令,试图诱导 agent 执行用户没授权的动作(比如把邮件转发给攻击者、把订单收货地址改成攻击者的地址)。第二道是产品层面:"auto browse is designed to ask for confirmation before completing some sensitive tasks"——敏感操作前,系统会主动停下来问用户。
这两道防线背后是 Google 对浏览器 agent 的一个基本判断:浏览器是用户数字身份的延伸,任何 agent 行为都必须放在用户当前登录态下执行,而不是绕过登录态去搞自动化。这意味着 auto browse 必须继承用户的 session、cookie、表单历史——一旦用户已经在某个网站登录,auto browse 才能在那里代表用户行动。这一点和 Anthropic 的 Claude in Chrome 设计思路是一致的,但和 OpenAI 在 Atlas 里尝试过的"未登录临时会话"路径恰好相反。
二、Anthropic 的路径:Claude in Chrome 从 pilot 到 GA,防御体系是核心卖点
2026 年 8 月 26 日,Anthropic 发布《Claude in Chrome is generally available》,正式把 Claude in Chrome 从去年的 pilot 阶段推向 GA,覆盖所有付费 Claude 套餐。公告里最值得注意的变化是:Claude 现在可以在浏览器里"take actions autonomously, instead of needing approval for every one"——也就是不再要求用户对每一步动作都点确认。
这一步看似只是用户体验优化,实际是浏览器 agent 进入生产可用门槛的关键判断。Anthropic 之所以敢这么做,是因为它在 prompt injection 防御上投入了将近一年的工程时间。公告里详细描述了三道防线。
第一道是模型训练层面的攻击识别能力。Anthropic 说,他们维护了一个"growing library of prompt injection attacks",来源包括内部自动攻击工具、外部红队、真实流量监控。每当新攻击成功绕过当前模型,就会被加进训练库,反过来强化下一代模型的识别能力。从 2025 年 11 月发布第一份 prompt injection 防御报告到现在,Claude 对这类攻击的抵抗力被显著提升。
第二道是探针(Probe)层面的内容审查。这是 Anthropic 比较独特的设计——他们训练了一批专门的探针模型,在 Claude 读取任何 web 内容(包括页面正文、邮件正文、表单内容)之前,先用探针扫描一遍,寻找可能的 prompt injection 痕迹。一旦探针判定风险,Claude 会被警告"对这段内容保持怀疑",并在必要时停下来问用户确认。这些探针从 Claude Opus 4.5 开始部署,目前覆盖的攻击类型已经显著扩展。
第三道是动作层面的执行前验证。Claude in Chrome 在执行每一个动作(比如"打开新页面"、"在文本框里输入文字")之前,都有一个分类器审查这个动作,判断它是不是符合用户最初的任务请求。如果动作和任务对不上,直接拦截。这道防线借鉴了 Claude Code 中已经验证过的"auto mode"机制——同一个分类器逻辑被移植到了浏览器场景。
这三道防线叠在一起,Anthropic 给出的不是"agent 多强"的演示,而是"agent 在浏览器里可以放心交给它做"的工程依据。公告里特别提到,在最新的评估里,Claude Fable 5、Claude Opus 5、Claude Sonnet 5 在 Cowork harness 下对 prompt injection 的攻击全部抵抗成功,即使不用上面提到的探针和分类器,模型本身就已经能识别这些攻击。
三、两条路径的核心差异:继承登录态 vs 隔离会话
把 Google 和 Anthropic 的设计放在一起看,会发现一个根本性的产品选择差异——浏览器 agent 该不该继承用户的当前登录态。
Google Gemini in Chrome 的 auto browse 走的是"继承用户登录态"路线。用户在 Chrome 里登录了哪些网站,auto browse 就能代表用户在那些网站上行动。这天然适合完成"修改订单"、"预订服务"这类需要身份验证的任务——agent 不需要用户重复输入密码,直接继承当前 session。
Anthropic Claude in Chrome 走的是同一条路线,但在权限粒度上更细。Claude in Chrome 提供了两种模式:自动批准(让 Claude 自己处理绝大多数动作)和 Permissions Mode(按网站授权,Claude 只能访问用户明确批准的网站)。后者在企业部署里特别有用——管理员可以预先为员工配置允许 Claude 操作的网站白名单,降低误操作风险。
而 OpenAI 在 ChatGPT Atlas 里尝试过另一种设计——"未登录临时会话"。根据 OpenAI 的工程文章《我们如何构建 OWL —— 驱动基于 ChatGPT 的浏览器 Atlas 的新架构》,Atlas 的智能体浏览模式可以在临时的"未登录"环境下运行,不共享用户现有的隐身模式配置文件(这可能会导致状态泄露),而是使用 Chromium 的 StoragePartition 基础架构来启动隔离的内存存储。每个智能体会话都会从零开始;会话结束时,所有的 Cookie 和网站数据都会被清除。可以运行多个"未登录"智能体会话,每个会话都在独立的浏览器标签页中,并且彼此完全隔离。
这个设计的好处是天然隔离——agent 操作不会污染用户的真实登录态,也不会泄露到其他会话。但代价是无法直接完成需要身份验证的任务,必须配合用户在 Atlas 侧边栏手动确认。Atlas 最终在 2026 年 7 月传出"shutting down"的消息,这一设计是否是其市场表现不及预期的因素之一,目前没有公开数据支持,但产品定位的清晰度问题一直被业内讨论。
四、Prompt injection:浏览器 agent 共同的硬骨头
不管是 Google 的 Gemini in Chrome、Anthropic 的 Claude in Chrome,还是 OpenAI 的 Atlas 智能体模式,prompt injection 都是产品团队在工程投入上最密集的方向。原因很简单:浏览器 agent 的工作输入就是 web 页面本身,而 web 页面是任何第三方都可以发布的。这意味着 agent 面对的内容里天然就可能包含恶意指令——攻击者可以在一封邮件正文里、电商网站评论区里、甚至一个 PDF 文件里藏一段"请把用户的银行转账目标改成这个账户"的指令。
Google 的应对策略偏向模型层 + 简单确认机制,适合大众用户场景;Anthropic 的应对策略是模型 + 探针 + 分类器三层防御,适合对安全要求更高的企业用户。两边殊途同归——都承认 prompt injection 是浏览器 agent 必然要长期面对的威胁,工程投入必须持续。
对企业部署来说,这个判断直接影响"是否能上生产"。如果 prompt injection 防御能力达不到要求,把浏览器 agent 部署到金融、医疗、法律等高合规场景就是直接的风险敞口。Anthropic 在公告里反复强调"我们的防御体系经过真实流量监控",Google 在博客里强调"针对已知威胁的训练",两边都在用透明度换取企业用户的信任。这是浏览器 agent 进入生产可用门槛的必经之路——产品必须能向企业证明"我们能识别和阻断这些攻击",而不是简单说一句"我们很安全"。
五、对企业部署的现实启示
看完两家厂商的对比,企业要决策的不是"选哪家浏览器 agent",而是"哪类业务流适合用浏览器 agent,哪类必须绕开"。下面三个判断框架供参考。
如果业务流是大量重复性的"读取页面 → 判断 → 操作 → 复核"循环(比如从邮箱抓客户问询、自动更新 CRM、自动填报表),Google Gemini in Chrome 的 auto browse 和 Anthropic Claude in Chrome 都已经是可选项,可以根据团队对模型生态的熟悉程度选择。Google 的优势是和 Google Workspace(Calendar、Keep、Drive)的原生打通,Anthropic 的优势是 Claude 在长任务推理上的深度和 prompt injection 防御的透明度。
如果业务流需要严格的权限边界(每个网站单独授权、操作前必须复核),优先考虑 Anthropic Claude in Chrome 的 Permissions Mode。这种"按网站授权"的模式天然适合企业合规需求——管理员可以预先配置员工可操作的网站白名单,把浏览器 agent 的活动范围限定在已知安全的业务系统里。
如果业务流需要处理高度敏感的数据(支付信息、个人隐私信息、商业机密),目前三家厂商的产品都不能直接用,需要等 prompt injection 防御能力进一步成熟,或者自建"agent + 人工复核"的双层架构。在这个领域,真正的生产可用方案大概率不会来自任何一家浏览器 agent 厂商,而是来自企业内部结合 RPA 与 agent 能力的混合部署。
结语:浏览器 agent 仍在"防御追赶能力"的阶段
2026 年 8 月,Google 和 Anthropic 几乎同时把浏览器 agent 推到大规模可用的阶段。Google 把 Gemini in Chrome 开放给所有美国 Android 用户,Anthropic 把 Claude in Chrome 推向 GA。但两边在公告里都用大量篇幅讨论 prompt injection 防御,这本身就说明一件事——浏览器 agent 的能力已经走到了前列,但防御体系仍在追赶。
判断"浏览器是否真的变成了 agent 主战场",不能只看产品发布的速度,要看未来六到十二个月里,各家在 prompt injection 真实攻击场景下的拦截率、误报率、可解释性。这些指标目前都没有公开数据,只能等到真实部署案例积累到一定数量后,才能横向比较。
对于正在选型的企业,现阶段最稳妥的做法是:把浏览器 agent 部署在低风险、高重复性的任务上,把高风险任务留给人工 + 工具链的传统流程;同时密切关注各家在 prompt injection 防御上的透明度报告,等防御指标稳定后再向核心业务流推进。