ChatGPT Work现在能登录网站了一个浏览器搞定一切

ChatGPT Work云浏览器登录界面

过去一年，AI助手的执行能力在快速扩展。从最初的文本对话，到能读取网页，再到调用工具和API，每一步都在拓宽"AI能替人做什么"这个问题的边界。

但有一个场景一直没解决好——需要登录的网站。

你的项目管理后台、企业邮箱、网盘、甚至是配置了OAuth的SaaS服务，AI助手基本只能干瞪眼。返回给你的答案永远是"我需要你手动登录"。然后你切过去输密码、验证码、等跳转，再把结果粘贴回来。

说实话这个流程比自己做还麻烦。

7月24日OpenAI开发者团队放出了一个更新——ChatGPT Work现在能操作需要登录的网站了。原理不复杂：云端浏览器里，你登录一次，AI就能在登录状态下替你继续执行任务。而且登录状态跨会话保持，今天登录明天还能用。

关键变化不在技术，在产品逻辑

从实现层面看，云端浏览器 + 会话持久化不是什么新技术。Selenium、Puppeteer、Playwright做了多少年了，每个做自动化测试的人都用过。

但产品化之后，逻辑完全变了。

之前开发者要用AI操作网页，需要自己搭环境、写prompt、处理cookies和session。企业搞一套"AI浏览器自动化"方案，光调试session过期问题就能折腾一周。

翻了一下原文，OpenAI的做法是让用户在云端浏览器里手动完成登录——输账号、收验证码、处理两步验证——然后把控制权交给AI。登录状态写入持久化存储，下次调用时恢复。

一个值得关注的细节是：登录状态跨会话保持。这意味着什么？你可以让AI每天早上帮你下载当天的业务报表，发到群里；或者定期检查某个后台的新订单，汇总给团队。

那问题来了——安全边界怎么处理？

登录状态持久化概念示意图

从实际使用来看，ChatGPT Work采用的是"用户登录后接管"的模式，而不是"AI代登录"。这是关键区别。AI代登录意味着要储存你的密码、处理各种验证码和2FA，安全风险太高。

而现在是——你先登录进去，然后告诉AI"帮我做这个"。登录凭证不会直接暴露给AI，它只是在授权会话里执行操作。

这里容易被忽略的是，OpenAI做这个功能不是为了让AI帮你刷网页。从产品定位看，ChatGPT Work更像是企业场景下的助手工具。想一想每天有多少重复操作是在浏览器里完成的：刷新后台 → 检查状态 → 下载文件 → 发消息。这类场景就是ChatGPT Work的目标。

Greg Brockman在推文下的具体描述也印证了这一点："Take over the cloud browser to log in, then let your agent continue the task."

这个"take over"和"continue"的组合很有意思。你先用，AI接着干。不是AI替你干一切，而是AI做你剩下的部分。

说实话这个更新对个人开发者可能影响不大——很多人都习惯了自己搭自动化脚本。但对企业团队来说，变化是明显的。

以前要自动化一个需要登录的业务流程，流程大致是：搭浏览器环境 → 处理session → 写异常处理 → 处理验证码 → 调试。每一环都是工程投入。

现在变成了：让用户登录一次，然后把任务交给AI描述。投入从工程时间变成了描述时间。

当然，代价是——你依赖于ChatGPT Work这个产品，你的任务逻辑跑在OpenAI的云端浏览器上。对于注重数据安全的团队来说，这不是一个容易做的选择。

不过换个角度看，如果只是处理公开报表或非敏感数据的周期性任务，这个功能的效率提升是明显的。

盯着那个对比图看了好一会——"只需登录一次，之后全自动"看起来简单，背后是会话持久化、浏览器沙箱、安全隔离等一堆工程问题。OpenAI选择了一种务实的方式：让用户自己完成最难的部分（登录验证），AI做剩下的。

问题是：企业真的愿意把后台操作交给一个云端AI浏览器吗？

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。