Gemini Spark 将智能体式网页浏览带入 Chrome,引发安全权衡
Google 已让 Gemini Spark 直接访问 Chrome,使其智能体不再局限于远程浏览器,尽管这意味着更高的安全风险。对关注 Engadget Google 报道的读者而言,关键变化并非 Gemini 又新增了一项聊天功能,而是 Spark 现在可以在包含已登录账户、保存偏好和个人数据的浏览器会话中工作。
这项访问能力让 Spark 能够处理多步骤事务,包括旅行研究、比价购物、预约安排和表单填写。Google 表示,涉及敏感操作时,控制权仍会交还给用户。但同样的设计,也让这款实验性 AI 智能体在个人数字生活中获得了更具实用价值的位置。
由此形成了能力与暴露风险之间的直接权衡。远程浏览器能隔离智能体,却缺少用户既有的大量上下文。本地 Chrome 则提供了这些上下文,同时也扩大了错误、恶意网页或权限机制理解不足所带来的后果。
Engadget Google 报道标志着从聊天到行动的转变
Gemini Spark 的 Chrome 集成,使这款助手从提供操作指引的工具,变成能够访问活跃浏览器会话的执行者。
Google 于 2026 年 7 月 30 日宣布了这项集成。其 Chrome integration 允许 Spark 在用户授权后连接桌面浏览器。
该功能名为 Chrome auto browse。它让 AI 智能体能够浏览网站、输入信息、比较选项,并跨多个页面推进一项任务。用户可以观看其操作、随时停止,或在必要时接管控制权。
这一差异至关重要。标准聊天机器人可以推荐航班、解释预订政策,或准备购物清单。Spark 则可以访问相关网站、使用现有账户、评估选项,并开始进行交易。
Google 以找房为例。Spark 可以查看用户此前保存的房源、比较可用时间并预约看房。它还可以研究航班,并根据用户明确表达的偏好启动预订流程。
这比在网页旁放置一个聊天面板更有用。Spark 能够跨多个网站操作,并持续推进用户请求的结果。它是在工作流程中行动,而不是对流程发表评论。
这一连接也弥合了 Spark 的远程工具与用户日常工作网站之间的差距。Spark 此前可以访问独立的远程浏览器。该浏览器无需依赖用户电脑即可持续运行,但经过身份验证的步骤往往仍需人工介入。
本地 Chrome 让 Spark 可以访问用户可用的同一批网站,其中包括浏览器已持有活跃会话的服务。获得许可后,Spark 还可以使用储存在 Google Password Manager 中的登录信息。
活跃的浏览器会话不只是便捷的快捷方式。它代表着用户与银行、零售商、旅行服务、工作场所、医疗门户和通信平台之间的关系。每个会话都携带着远程、未登录浏览器所不具备的权限。
Engadget 的报道将这一功能描述为处理繁琐网页事务的一种方式。这个说法没有错,却低估了产品转型的意义。繁琐事务往往恰恰涉及最敏感的身份、账户和支付信息。
Google 并未取消远程浏览器。其 Spark documentation 表示,智能体可以在本地与远程浏览路径之间进行选择。本地浏览要求电脑和 Chrome 持续可用。
如果本地设备不可用,Spark 可能会通过远程浏览器继续执行。不过,当网站要求身份验证或用户输入时,智能体可能会暂停。这种混合设计优先保障任务完成,同时为部分受保护步骤保留检查点。
因此,该产品拥有两种运行环境。一种提供更强的连续性与隔离性,另一种则通过用户现有浏览器提供更丰富的上下文和访问能力。
这一架构构成了本文的核心张力。Chrome 之所以让 Spark 更有能力,是因为它承载着用户的数字权限。而同样的权限,也让故障的后果更加严重。
Chrome 为 Spark 提供了其他智能体所需的上下文
Google 的优势不只是更好的模型,还在于它掌控着模型周围的浏览器、账户、服务和已保存的上下文。
AI 助手在任务跨越多个边界时往往表现不佳。寻找一家餐厅,可能需要 Maps、评价、预订服务、电子邮件确认和日历条目。每一次切换都可能中断工作流程。
Google 已经运营着其中许多服务界面。Spark 可以与 Gmail、Calendar、Drive、Maps、Flights、Hotels、Search 和 YouTube 等服务协同工作。它还支持部分第三方应用和自定义连接。
Chrome 将这一覆盖范围扩展到专为 Gemini 构建的集成之外。浏览器智能体可以通过传统网站的可视界面与之交互。它不需要每家商户、诊所或本地服务商都建立专用的 Gemini 连接。
这种方式给依赖远程浏览器或有限应用接口的独立 AI 智能体带来压力。这些智能体可以浏览公开网页,但身份验证和个人上下文仍然很难处理。Google 的起点则是一个许多用户早已登录的浏览器。
Chrome 还提供了连续性。Cookie、账户会话、保存的地址和浏览历史可帮助网站记住用户。Spark 可以利用这一环境中的部分信息,减少任务过程中重复设置的步骤。
在比价购物中,这种优势尤其明显。通用助手可以列出产品并总结评价。本地浏览器智能体则可以查询会员专属库存、应用已保存的账户信息,并在多家零售商之间准备购物车。
一位 TechRadar 评测者以电视搜索测试了这一场景。根据该评测者的 Spark test,该智能体比较了多家商店、核查折扣、将选定产品加入购物车,并在付款前停止。
同一位评测者还让 Spark 规划一次家庭出游。这项任务需要处理营业时间、出行时长、餐厅可订情况和门票准备。Spark 将这些步骤整合为一个序列,并在完成受保护预订前暂停。
这些案例仍只是个别测试,不能证明其在整个网络上的可靠性。但它们确实说明了本地上下文为何重要。智能体可以在研究和执行之间切换,无需让用户重新搭建每一步。
Google 将 Spark 推出为一款面向长时运行任务的智能体。此前的更新已赋予它桌面文件访问、已连接应用、日程安排和实时监控能力。Chrome 如今将这些能力带到了开放网络。
这一演进揭示了 Google 的战略。Spark 正在成为跨设备、文件、网站和 Google 服务的编排层。聊天界面只是用户定义所需结果的地方。
这一定位使 Chrome 具有战略重要性。浏览器见证了意图转化为行动的时刻:搜索在其中变成购买,文档在其中变成提交,推荐在浏览器标签页中变成预订。
Google 可以将这些行动与 Workspace 和 Personal Intelligence 中的信息连接起来。Personal Intelligence 包括记忆的偏好、此前的 Gemini 对话和用户提供的指令。Spark 可以在选择或完成网页任务时应用这些上下文。
用户可能会要求 Spark 为一次经常进行的家庭旅行寻找合适酒店。该智能体可以考虑日期、目的地偏好、过往指令和可用网站,随后准备预订,无需用户再次重复每项偏好。
对于知识工作者而言,同一模式可以支持重复性的行政工作。智能体可能收集收据、将信息填入表单、整理日历或查找支持文件。当智能体可以对收集到的信息采取行动时,结构化的 AI workflow 会更有价值。
局限在于,上下文与权限会一同传递。向 Spark 提供更多信息能改善个性化体验,给予它更多会话访问权限则能提升执行能力。两者结合,会扩大一次错误决策可能造成的损害。
这正是这则 engadget google 新闻的意义超越一次功能发布之处。Google 展示了浏览器所有权如何成为智能体 AI 的优势,同时也承担起管理隔离式助手通常可以避免的风险的责任。
真正的较量是能力与浏览器风险之间的平衡
Chrome 访问通过将 Spark 置于安全故障最可能造成严重影响的环境中,解决了智能体的上下文问题。
主要风险来自提示注入。提示注入是指旨在将 AI 系统从用户原本指令中引开的恶意内容。它可以出现在网页、文档、电子邮件、图像或智能体读取的其他材料中。
普通访问者或许永远不会注意到隐藏指令。AI 智能体却可能将其理解为与任务相关的输入。如果智能体无法区分用户指令权限与不可信网页内容,页面就可能试图操纵其行为。
Google 表示,Spark 包含针对提示注入的防护措施。该公司还要求浏览器的 Safe Browsing 保护保持启用状态。这些控制措施可以降低风险,但 Google 并未声称每一次攻击都能被拦截。
其自身支持材料将 Spark 描述为实验性产品,并警告该智能体可能会犯错。Google 建议用户不要直接在 Spark 任务对话中输入密码、支付详情或其他敏感信息。
这一警告很重要,因为 Chrome 访问为敏感数据创造了多条可能路径。Spark 可以读取任务指令、查询已连接服务、打开已认证网站,并与第三方共享必要信息。
Google 表示,共享的信息可能包括姓名、联系方式、文件、偏好和敏感材料。具体数据取决于任务以及 Spark 选择访问的网站。
恶意页面可能试图说服智能体泄露其他来源的信息。它可能请求电子邮件、文档或已连接应用中的内容,也可能试图将智能体引向不需要的操作。
威胁并不需要 Spark 直接泄露密码。活跃会话通常让用户无需再次输入凭证即可执行重要操作。通过这些会话运行的智能体,也可能继承实质性的权限。
Google 的企业文档对这一担忧表达得格外直接。其 Spark policy 警告管理员注意凭证风险、本地网络访问,以及上下文感知安全信号可能丢失的问题。
本地网络问题值得关注。浏览器有时可以访问不向公共互联网开放的内部仪表板、路由器、开发服务或公司工具。连接到该浏览器的智能体,便可能拥有通往这些资源的潜在路径。
企业控制功能可禁用 Spark 的自动浏览连接。管理员还可以定义允许或禁止访问的网页目的地。这些设置承认,面向消费者的便利性并不会自动转化为可接受的工作场所风险。
核心问题不在于 Google 是否增加了安全措施。它确实增加了。问题在于,这些措施能否在网络上数量庞大的界面、欺骗性内容和不断变化的攻击技术面前持续保持可靠。
网站是为人类设计的,而非为自主代理设计。同意对话框、广告、隐藏元素、重定向以及嵌入式第三方组件,都可能使解读变得复杂。即使是无害的页面,也可能产生意料之外的行为。
用户监督有所帮助,但无法解决所有问题。人们将繁琐事务交给代理,正是因为他们不想监控每一次点击。若一种安全模式要求持续关注,就会削弱该功能最主要的价值。
相反的做法同样行不通。让 Spark 在没有实质性检查点的情况下继续执行,会让系统更具自主性,却也会使用户面临意外提交或信息披露的风险。设计必须决定,哪些情况下的中断值得付出这类摩擦成本。
Google 目前会针对敏感操作使用确认和交接机制。Spark 会在执行浏览任务前请求浏览器权限。用户可以停止任务、接管控制权,或在完成受保护步骤后交还控制权。
这些边界很重要,但“敏感”的定义可能并不容易。完成付款显然属于敏感操作。发送消息、更改预约、提交表单或泄露家庭住址,也可能带来严重后果。
不同用户会为同一操作赋予不同的风险等级。对一个人而言,餐厅预订微不足道;对另一个人而言,它可能暴露位置、日程、饮食信息或私人关系。
这种不确定性使能力与风险之间的冲突,比简单的产品比较更为重要。Google 不只是在与另一款助手竞争,它还在测试用户愿意向任何 AI 代理授予多少浏览器权限。
已保存密码让便利性更难与信任区分开来
Password Manager 支持消除了自动化的一大障碍,同时也让权限设计成为核心安全控制措施。
Google 表示,在获得用户许可后,Spark 可以使用已保存的登录信息。这并不意味着代理一定会以可读文本形式显示或接收密码,而是指浏览器可以协助完成获批任务的身份验证。
这一差异在技术层面很重要,但从用户角度看其意义有限。一旦身份验证成功,代理便可能获得账户的功能和信息访问权限。会话本身比密码更重要。
以忠诚度账户为例。Spark 可能登录账户、查找积分、比较出行选项并准备预订。这个流程很方便,因为用户无需查找凭据,也不必在多个账户页面间导航。
但同一账户可能暴露地址、出行记录、会员号码或已保存的付款方式。Spark 必须使用足够的信息来完成任务,同时避免向其他网站分享不必要的细节。
Google 将第一道同意边界设在浏览器连接处。随后,当 Spark 开始浏览任务时,它会请求确认。付款或其他敏感操作周围还会出现额外的交接环节。
这种分层模式优于一项涵盖未来所有任务的宽泛权限。不过,重复出现的批准对话框可能变得司空见惯。当同一请求频繁出现时,用户往往不再仔细评估提示内容。
权限疲劳带来了实际的安全问题。一个界面可以在技术上取得同意,却未能促成充分知情的关注。因此,对预期访问的网站、数据和操作做出清晰说明将至关重要。
用户还需要了解 Spark 是在本地运行还是远程运行。本地浏览器使用用户电脑上的会话和环境。远程浏览器则存储独立的浏览数据,并且可在本地设备不可用时继续运行。
这两种模式有不同含义。本地访问可以触及已登录的服务,以及潜在的内部资源。远程访问隔离了环境,但 Google 表示,远程会话中的身份验证数据可能会被保留,以便未来使用时更方便。
Spark 设置允许用户删除远程浏览器数据和远程代码执行数据。Google 表示,关闭 Spark 会删除这些远程存储内容,但不会清除用户现有的 Chrome 浏览数据。
这一设计需要精确的沟通。停止单个任务的用户,并不一定删除了保留的远程数据。禁用本地自动浏览的用户,也不一定移除了账户历史记录或其他 Gemini 活动。
Google 的自动浏览指南还说明,本地任务要求 Chrome 保持运行,设备也必须保持唤醒。如果设备关闭,Spark 在可能的情况下会转移到远程浏览器。
环境之间的交接应当保留任务,同时不能模糊安全边界。用户需要看到明确指示,了解代理在哪里运行,以及哪些凭据仍可使用。
当前的资格规则提供了另一层边界。Chrome 自动浏览初期要求用户为成年人、使用个人 Google Account、拥有受支持的订阅、使用已更新的桌面浏览器,并位于符合资格的地区。
工作和学校账户面临额外限制或管理员控制。该功能无法在 Incognito 模式下运行。这些限制在 Google 收集运行与安全数据期间降低了早期暴露风险。
但它们也限制了此次推广能够证明什么。早期采用者通常更愿意接受实验性行为,并花更多时间理解设置。他们的体验并不能保证更广泛的受众会以同等谨慎程度管理权限。
因此,已保存密码功能既不能自动被视为鲁莽,也不仅仅是方便。它的安全性取决于身份验证边界、操作级同意、网站选择、监控,以及代理抵御操纵的能力。
对于评估该功能的 engadget Google 读者而言,正确的问题不是 Spark 是否“拥有”他们的密码。更好的问题是,Chrome 验证账户身份后,Spark 获得了何种权限。
这种权限应当是有限、可见、临时且可撤销的。Google 已经实现了这一模式的部分内容。实际使用将显示,这些控制措施能否在更长、更复杂的事务中始终保持易于理解。
Google 的浏览器优势给所有独立 AI 代理带来压力
竞争对手如今面临分发难题,因为 Google 可以将其代理置于浏览器内——经过身份验证的工作本就发生在那里。
浏览器代理并不新鲜。早期系统使用扩展程序、远程虚拟机或浏览器控制框架来点击访问网站。困难之处始终在于,如何让这些系统足够可靠和值得信赖,以便用于日常生活。
远程浏览器提供了更清晰的安全边界。它们可以将自动化与个人文件、内部网络以及用户的主浏览器配置文件隔离开来。但它们也迫使用户重复登录,或手动传递信息。
本地代理提供了更丰富的上下文,却也继承了更大的攻击面。它们可以使用活跃会话、打开的标签页、已保存数据,以及设备可访问的服务。这种访问能力使其更有用,也更难保护。
Google 可以在同一产品中支持两种方式。Spark 可以使用远程浏览器处理持续性工作,也可以使用本地 Chrome 执行需要身份验证的任务。这种灵活性提高了人们对每一款竞争性助手的期待。
独立代理如今需要的不只是胜任的推理能力。它还需要可靠的浏览器控制、权限系统、身份验证处理、账户集成,以及针对恶意网页内容的可信防御能力。
它还需要分发能力。说服用户安装扩展程序或配置独立浏览器会带来摩擦。Chrome 可以通过符合资格的用户已经拥有的浏览器界面来提供 Spark。
Google 还将 Spark 与其更广泛的服务组合相连接。Gmail 包含出行确认和收据;Calendar 包含可用时间;Maps 包含地点;Drive 包含文件,而 Search 和 Flights 则提供发现工具。
竞争对手可以通过接口和用户授权连接其中部分服务。但他们无法复制 Google 对整个技术栈的所有权。这是一种结构性优势,而不只是功能领先。
然而,所有权也带来义务。监管机构和企业买家可能会质疑,Google 是否利用对 Chrome 的控制来偏向 Gemini。安全团队则可能要求证据,证明现有浏览器政策在由代理控制的会话中依然有效。
Google 自己的企业警告指出,某些现有管理和安全控制措施可能不会得到遵守。这一说法将引起依赖浏览器上下文来执行访问决策的管理员关注。
一名员工的浏览会话可能包含设备信任、网络位置、身份和行为信号。AI 代理通过该会话行动,会改变这些信号的含义。网站可能看到的是获批用户,而实际操作者却是软件。
企业需要能够区分人工操作与代理操作。审计日志应记录 Spark 访问、输入、更改或提交了什么。管理员还需要专门适用于自动化会话的控制措施。
消费者用户则需要更简化版本的同类可见性。已完成的任务应显示访问过的网站、共享的信息、作出的选择,以及等待批准的操作。没有这些记录,用户就无法评估意外结果。
因此,竞争压力不止影响 AI 公司。网站运营者必须决定是否允许自动化代理。身份提供商必须调整身份验证方式。安全厂商必须检测针对代理而非人的操纵行为。
在线商家可能欢迎能够完成购买的代理。其他网站可能会抵制自动化流量、抓取行为或账户操作。Spark 将在整个网络中遇到不一致的政策和界面。
这种不一致会削弱可靠性。代理可能在大型旅行和零售网站上表现良好,却在本地服务或不常见的表单上失败。验证码、反机器人措施和不断变化的布局,可能中断原本直接明了的事务。
Engadget 的报道捕捉到了一个重要的产品里程碑。但更大的变化在于,Google 已将代理竞争带入浏览器会话本身。这个位置奖励集成能力,同时也放大了信任问题。
最终结果不会只取决于基准测试表现。用户会评判 Spark 是否准确完成工作、是否会在合理时刻请求帮助,以及是否留下清晰记录。企业则会评判其行为能否得到治理。
Google 为自己设定了很高的标准。Chrome 为 Spark 提供了许多竞争对手想要的访问能力。当代理误解页面或跨越预期边界时,这也让 Google 更少有借口可言。
Gemini Spark 扩展时值得关注的事项
三个信号将表明 Chrome 自动浏览会成为可靠的基础设施,还是仍只是一项信任有限的令人印象深刻的实验。
第一个信号是关于任务完成率和错误率的独立证据。产品演示展示的是预期行为,但无法衡量其在不同账户、网站和边缘案例中的表现。
评测者应测试涉及多个网站和不断变化条件的更长工作流程。有价值的评估应记录人工干预、错误选择、放弃的任务,以及到达确认边界的操作。
成功不应只意味着抵达最后一个网页。Spark 必须遵守用户约束,区分建议与决策,并避免暴露无关信息。当网站发生变化时,它还应能够清晰地恢复工作。
Google 尚未公布 Chrome 自动浏览功能的整体可靠性指标。在早期推广阶段,这一缺失可以理解;但随着更多用户将重要任务交由其处理,这项指标将变得关键。
第二个信号是 Google 的安全记录和披露流程。研究人员将测试其对提示注入的防御能力、跨站数据处理、本地网络访问以及权限边界。
可信的回应不能只是悄然修补个别漏洞。Google 应说明哪些安全假设失效、哪些信息被暴露,以及受影响的控制机制发生了怎样的调整。
该公司已经承认了这一基础威胁。其帮助文档列举了恶意指令试图从电子邮件或已连接应用中提取信息的示例。这种透明度提供了一个有益的起点。
研究人员将测试:在用户分配了无关任务后,隐藏的网页内容是否能够影响 Spark。他们还将考察确认提示是否准确描述了攻击者试图触发的操作。
一次重大漏洞利用并不能证明浏览器代理无法得到妥善保护。它会揭示哪些边界需要加固。而在同一边界上反复出现的失败,将削弱 Google 的安全论证。
第三个信号是企业采用情况和政策成熟度。Google 提供了用于禁用该功能的管理控制,但大型组织需要更细致的治理能力。
应关注细粒度的网站规则、代理专属审计事件、数据共享日志,以及与安全监控系统的集成。这些控制措施将表明 Google 预计 Spark 会处理真实的工作场景任务。
简单的开关设置意味着该功能仍主要面向消费者。细致的治理能力则表明,Google 相信由代理控制的浏览可以与受监管数据及企业访问系统共存。
区域扩张也是这一信号的一部分。Google 最初在美国推出了本地 Chrome 功能,同时将 Spark 的可用范围扩大到更多国家和地区。
不同的隐私规则和消费者保护制度将检验 Google 对同意、数据保留和自动化操作的解释。若扩张过程中没有出现重大限制,将增强人们对其运营模式的信心。
竞争对手的反应同样值得关注,但相较这三个信号仍属次要。其他公司会增加浏览器功能。更重要的问题是,是否有人能让已认证的自动化足够可预测,从而适用于日常授权委托。
目前来看,Spark 展示了一个可信的使用场景。它能够减少处理日常事务时涉及的标签页切换、重复输入和账户导航。独立测试已在购物、日程安排和表单填写方面显示出有用的结果。
它也说明了,为何从安全角度看,这些事务并不简单。每一项都将个人信息与外部服务连接起来。一个节省时间的代理,也在决定哪些数据会流向何处。
因此,engadget google headline 应被理解为责任的转移。Google 正请求用户信任 Gemini 所拥有的浏览器权限,而不只是其生成的答案。
在启用这项权限前,请检查资格要求和权限提示。先从不涉及敏感记录、且可逆的任务开始。审阅 Spark 的计划,监控它选择的网站,并保留对最终提交操作的控制权。
随后,确认完成后的记录是否符合你的指令。Spark 是否访问了合适的服务、仅分享了必要信息,并在产生重要后果的操作前停止?这些结果比一场精致的演示更重要。
当用户能够委托任务而无需盯着每一次点击时,Chrome 自动浏览才具有意义。只有当用户能够理解、限制并撤销代理所做的操作时,它才值得信赖。未来几个月应会揭示 Google 能否同时实现这两个目标。



