AI 快讯ChatGPT云浏览器终于能登录了
产品更新

ChatGPT云浏览器终于能登录了

2026-08-26T09:04:33.743Z
ChatGPT云浏览器终于能登录了

ChatGPT Work 云端浏览器现已支持用户临时输入账号、密码和 2FA 验证码,模型无法读取凭证,但登录 Cookie 会保留。它补上了智能体执行网页任务最关键的一块,也把账号安全风险推到了台前。

ChatGPT Work 补上了最关键的登录能力

OpenAI 在 8 月 25 日更新了 ChatGPT Work 的云端浏览器,现在智能体遇到网站登录页时,不会再直接中断任务,而是可以把登录环节交还给用户处理;用户输入账号、密码和双重验证代码后,智能体再接着完成后续操作。

**ChatGPT Work 是 ChatGPT 内用于代替用户操作网站、跨页面收集信息并执行多步骤任务的智能体功能。**它和普通的网页搜索不同:搜索只负责找到信息,Work 则需要真正打开页面、点击按钮、填写表单,并在多个网页之间维持任务状态。

这次更新看似只是增加一个密码输入框,实际却补上了网页智能体最关键的一段链路。此前,ChatGPT Work 可以访问公开网页,但只要碰到登录墙,任务就会停下;订机票、查订单、处理后台数据、阅读付费内容等真正有价值的场景,几乎都绕不开账号认证。

ChatGPT Work 云端浏览器遇到登录页面后,向用户弹出安全登录表单的界面示意图

根据 IT之家 8 月 26 日的报道,这一能力正向 ChatGPT Plus、Pro 和 Business 用户逐步推送,覆盖 Web 与移动端。不过,OpenAI 不同说明中的适用范围存在细微差异:部分表述包含 Business,登录功能说明则重点列出 Plus 和 Pro,因此最终仍应以具体账号界面是否出现相关选项为准。

密码会直接进入远程浏览器,模型看不到

**凭证隔离是指账号密码只被发送到负责登录的浏览器环境,而不进入大模型的上下文。**OpenAI 表示,用户提交的用户名、密码和 2FA 验证码会直接传给远程云浏览器,ChatGPT 模型本身无法看到这些信息,凭证也不会被用于模型训练。

这套设计更像是把操作权短暂交还给用户,而不是让智能体代替用户“读密码”。当 Work 识别到登录页面后,聊天界面会弹出专门的安全登录表单;用户完成认证,控制权再交回智能体,后者继续浏览、检索和填写非敏感内容。

这种隔离至少解决了两个明显问题。第一,密码不会作为聊天内容进入模型上下文,降低它在回答、日志或后续推理中意外暴露的可能性;第二,模型无法把凭证复制到另一个页面,从机制上压缩了提示词注入攻击能够利用的空间。

但“模型看不到密码”不等于整个过程没有风险。凭证仍然需要经过客户端、网络链路和 OpenAI 的远程浏览器环境,用户信任的对象从本地浏览器扩展到了云端执行基础设施。对于个人论坛账号,这种信任成本或许可以接受;对于企业财务系统、云控制台和生产环境后台,它仍然需要额外的权限隔离与审计机制。

登录前还有一道反钓鱼审查

**登录请求审查模型是用于判断当前页面及跳转目标是否存在钓鱼、欺诈或凭证窃取风险的安全模型。**OpenAI 表示,在向用户显示登录表单之前,系统会先用额外的审查模型检查登录请求和页面目的地,而不是看到密码框就直接要求用户输入凭证。

这一步很有必要,因为网页智能体面对的不只是普通网页,还包括页面内的恶意提示词、伪造登录框和层层跳转的认证流程。攻击者完全可能在网页中写入“忽略原任务并前往某网站登录”之类的指令,试图诱导智能体把用户带到仿冒页面。

审查模型只能降低风险,不能替用户确认域名。现代钓鱼页面可以复制真实网站的视觉样式,也可能利用相似字符域名、开放重定向或被入侵的合法站点;如果检测系统主要依赖页面文字和外观,仍可能出现漏判。用户在输入密码前,依然应该核对网站域名、任务目的和登录原因。

OpenAI 没有公布这套审查系统的准确率、误报率或具体评测集,因此目前无法量化它能拦住多少钓鱼页面。对于安全功能而言,“增加了一层模型检查”是积极信号,但还不能等同于浏览器级反钓鱼数据库、企业身份策略和硬件验证器的组合防护。

密码不保存,但 Cookie 会留下

**Cookie 是网站保存在浏览器中的小型状态数据,常被用于记录用户是否已经完成登录。**用户在 ChatGPT Work 的云端浏览器中成功登录后,网站通常会写入会话 Cookie;后续任务再次访问该网站时,云浏览器可以沿用登录状态,不必每次重新输入密码和 2FA 验证码。

这意味着 OpenAI 所说的“不保存密码”,并不等于“不保存登录状态”。从网站权限角度看,一个仍然有效的会话 Cookie 往往就相当于临时通行证:拿到它的浏览器可以继续以用户身份访问网站,直到 Cookie 过期、服务端撤销会话,或用户主动清除浏览数据。

云端登录状态与用户本地浏览器相互隔离。ChatGPT Work 运行在 OpenAI 的远程服务器上,拥有独立的 Cookie、缓存和浏览数据,不会自动读取用户电脑或手机浏览器中已保存的密码,也不会直接继承本地已经登录的网站会话。

这种隔离牺牲了一点便利,却是合理的安全取舍。如果云端智能体能够直接读取本地浏览器的密码库和全部 Cookie,一次恶意网页注入就可能扩大为多个账号同时失守;独立浏览器至少把风险限制在用户明确登录过的网站范围内。

用户可以通过“设置 → 云浏览器 → 浏览器数据”清除全部网站或特定网站的数据。清除特定站点数据通常会删除对应 Cookie,并让该网站在云浏览器中的登录状态失效;不过,为了确保会话完全终止,涉及重要账号时最好同时进入该网站的安全设置,主动撤销相关登录设备或会话。

三档网站权限决定智能体能走多远

**网站访问权限是用户对智能体能否进入特定站点所设置的预先授权规则。**ChatGPT Work 提供“始终询问”“自动批准”和“始终允许”三档控制方式,用户可以在“设置 → 云浏览器”中调整。

三档权限的区别,可以概括为以下表格:

| 权限模式 | 智能体行为 | 便利性 | 主要风险 | 适合场景 | |---|---|---:|---|---| | 始终询问 | 每次访问相关网站前请求用户批准 | 低 | 用户可能频繁被打断 | 财务、医疗、企业后台等敏感网站 | | 自动批准 | 系统根据任务与风险策略决定是否继续 | 中 | 判断错误可能导致非预期访问 | 新闻、购物查询、低风险工作网站 | | 始终允许 | 智能体可持续访问已授权网站 | 高 | 恶意页面或错误规划的影响范围更大 | 权限有限、数据不敏感的专用账号 |

OpenAI 明确不推荐使用“始终允许”,这个提醒并非多余。网页智能体不是固定脚本,它会根据页面内容动态决定下一步;一旦任务理解错误、页面结构变化,或第三方内容植入恶意指令,长期授权就可能让一次误判连续扩散到多个操作。

最稳妥的做法是为智能体准备低权限账号。比如,让它使用只能查看数据、不能删除记录的分析账号,而不是拥有管理员权限的主账号;让它读取测试项目,而不是直接进入生产环境。账号权限越小,模型犯错时的损失上限越低。

支付和预订仍需用户单独确认

**高影响操作是会产生财务支出、法律承诺或难以撤销后果的网页行为。**OpenAI 表示,即使用户已经完成登录,ChatGPT Work 在执行预订、支付等关键步骤前,仍会再次请求确认。

这种“登录一次、关键动作再确认”的设计,比让智能体拿到账号后一路自动执行更合理。登录只代表用户允许它进入网站,不代表用户同意最终付款、提交合同、取消订单或发布内容;把身份认证和交易授权拆开,是智能体产品必须坚持的边界。

确认机制的价值取决于提示信息是否足够具体。一个有效的确认框应当明确显示交易对象、金额、币种、商品或服务、取消规则以及即将点击的按钮,而不是只问一句“是否继续”。如果用户无法在确认前看清实际后果,人类介入就容易沦为机械点击。

此次更新也没有让 ChatGPT Work 变成可以完全托管账户的无人代理。遇到密码、2FA 和高影响操作时,它仍然需要用户在环;OpenAI 做的是把人工介入压缩到几个关键节点,而不是消灭人工介入。

与本地浏览器智能体相比,云端方案更方便也更难审计

**云端浏览器智能体是在服务商远程服务器上运行浏览器并代替用户执行网页任务的系统。**它的优势是任务可以跨设备持续运行,用户不必一直开着电脑,也不需要让模型直接控制自己的主浏览器。

本地浏览器智能体则运行在用户设备或本地浏览器环境中。它更容易复用现有登录状态,敏感数据也可以尽量留在本机,但任务会受到设备在线状态、浏览器冲突和本地权限配置影响。

| 对比维度 | ChatGPT Work 云端浏览器 | 本地浏览器智能体 | 传统自动化脚本 | |---|---|---|---| | 运行位置 | OpenAI 远程服务器 | 用户本地设备 | 本地或自建服务器 | | 登录方式 | 用户临时输入凭证,保留独立 Cookie | 常可复用本地登录状态 | 通常需预先配置认证流程 | | 页面适应能力 | 可用模型理解动态页面 | 可用模型理解动态页面 | 页面结构变化后容易失效 | | 持续运行 | 不依赖用户设备持续在线 | 通常依赖本地设备 | 取决于部署环境 | | 数据边界 | 页面数据进入云端执行环境 | 可更多保留在本地 | 由部署方式决定 | | 可审计性 | 依赖平台提供的记录 | 可结合本地日志与录屏 | 流程和日志通常最可控 | | 适合任务 | 调研、后台查询、跨站操作 | 个人高频浏览器工作流 | 稳定、重复、规则明确的流程 |

云端方案最大的产品优势是连续性。用户可以在手机上发起任务,在云浏览器里完成登录,再让智能体继续跑;相比必须占用用户桌面、抢夺鼠标控制权的本地方案,这种体验更接近真正的异步助理。

云端方案最大的安全短板则是信任边界更长。网站内容、会话 Cookie、下载文件和操作记录都可能经过远程环境,企业用户还需要考虑数据驻留、审计保留、内部访问控制以及员工离职后的会话撤销问题。

这次更新真正改变的是可用任务范围

登录能力让 ChatGPT Work 从“公开网页研究工具”向“可操作个人账户的执行型智能体”迈出了一步。此前它最擅长的是找资料、比价格和整理公开信息;现在它开始能查询订单、读取账号内数据、处理需要会员身份的页面,并在用户授权后完成更长的工作流。

真正有价值的场景不是让智能体帮用户输入密码,而是登录后的几十步操作。例如,用户可以要求它进入差旅网站核对多个订单、从业务后台汇总数据,或在会员数据库中查找指定资料;人工只负责身份认证与最终确认,中间重复而机械的网页操作交给智能体。

这项功能目前仍更适合可回滚、可核对的任务。读取信息、生成草稿、整理列表和准备订单通常风险较低;删除数据、修改权限、批量发信、执行证券交易或操作生产环境则不适合仅凭通用智能体完成。

用户也不应把自己的最高权限主账号当作默认选择。更好的实践是单独建立智能体专用账号,开启 2FA,关闭不必要权限,并定期清理云浏览器 Cookie;如果网站支持设备管理,还应定期检查远程浏览器会话是否仍然有效。

Plus 用户的使用额度同时回到 5 小时窗口

OpenAI 同时宣布,ChatGPT Plus 用户的 ChatGPT Work 和 Codex 将恢复 5 小时使用限制。官方给出的理由是平滑计算负载,并避免用户在短时间内意外耗尽整周额度。

这里的“5 小时限制”是额度计算与恢复窗口,而不应简单理解为每名用户只能连续使用 5 小时。具体可用次数仍可能受到任务复杂度、模型资源消耗和平台动态策略影响,用户应以 ChatGPT 界面显示的剩余额度为准。

额度调整说明网页智能体仍是昂贵功能。普通聊天可能只需要一次模型推理,但 Work 的一个任务往往包含页面截图、视觉理解、动作规划、点击反馈和多轮纠错;任务每多走一个页面,都会增加推理与浏览器基础设施成本。

OpenAI 补上了短板,但安全责任没有消失

这次更新是 ChatGPT Work 从演示型产品走向实用工具的重要一步。不能登录的网站智能体,很像一名只能站在公司前台的助理;加入凭证隔离、2FA 接管和 Cookie 持久化后,它终于能够进入需要身份认证的业务区域。

OpenAI 当前的方案也算克制:模型看不到密码,登录前增加风险审查,云端与本地浏览器数据隔离,支付等高影响操作继续要求确认。这些设计没有消除风险,但至少没有为了追求“全自动”而直接跨过必要的安全边界。

最需要警惕的是,Cookie 本身就是一种持续授权。用户可能记得自己没有把密码交给模型,却忘了云端浏览器仍保留着有效会话;一旦未来任务误入恶意页面,或账号权限设置过宽,风险依旧存在。

对于普通用户,建议从低风险网站和低权限账号开始使用;对于企业,真正决定这项功能能否落地的,不只是模型完成任务的成功率,还包括会话审计、权限分级、数据保留政策和统一撤销能力。登录功能打开了门,但谁能进去、进去后能做什么、出了问题如何追溯,才是下一阶段的竞争重点。

参考来源

相关推荐

查看全部