过去一年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浏览器吗关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
