ChatGPT 终于能“自己上班”了：新邮件一来就醒，登录后继续干活

结论

ChatGPT 终于开始像一个会自己“上班”的助手了。

8 月 25 日，OpenAI 同时补上了 Work 的两个缺口：云浏览器遇到受支持网站的登录页时，可以让用户在安全表单中自己输入账号、密码和验证码，然后继续完成后面的流程；Scheduled Tasks 也不再只会按钟点醒来，而是能被 Gmail 新邮件、Slack 频道消息和 GitHub PR 变化直接触发。

再加上同日启动的 WebMCP Challenge，一条过去需要邮箱触发器、Zapier、RPA、浏览器自动化和大模型才能拼出来的链路，正被 OpenAI 往一个产品里收。

不过标题里的“自己上班”有边界：不是模型替你看密码，不是所有网站都能进，更不是付款、发消息之类的动作可以无人放行。

第一道门卡：遇到登录页不用直接下班了

以前的 Browser Agent 有一种很尴尬的聪明：会搜索、会点按钮、会填表，一看到“请登录”就把工作交回给你。偏偏 CRM、保险、物流、招聘和供应商后台这些真正有商业价值的地方，基本都在登录墙后面。

新流程里，ChatGPT Work 的云浏览器到达受支持的登录页后会暂停。用户在安全登录表单里完成账号、密码和双重验证，随后 Agent 恢复任务。OpenAI 说，凭证会直接进入远程浏览器，模型看不到用户名和密码，ChatGPT 也不保存这些登录凭证。

登录状态可以保留到过期为止，所以下次任务不一定还要从门口重来。官方给的场景已经从“帮我查个网页”走到查找 DMV 预约、登录公用事业账户比较套餐、核对发票并更新会计记录。

第二道门卡：Tasks 从“隔一会看一眼”变成事件触发

定时任务以前像闹钟。你可以让它每天查新闻，或者每小时看一次邮箱。问题是，客户 9:01 回了信，Agent 可能 10:00 才醒。真实工作更需要的是“事情发生就开工”。

新的事件触发任务使用 webhook。Gmail 可以在收到新邮件时触发，并按发件人或主题过滤；Slack 可以监听已加入 @ChatGPT 的频道；GitHub 可以对已授权仓库的 PR 活动做出反应。它们当前只对拥有 Work 的合格 Plus、Pro、Business、Enterprise、Edu 和部分 Healthcare 用户开放，Free、Go 与 FedRAMP 工作区不在范围内。

这比“更频繁地轮询”有用。客户邮件、客服频道或 PR 一有变化，ChatGPT 就可以先读、归纳、准备下一步，而不是等人记得打开聊天框。

两块拼起来，才有了“数字员工”的样子

想象一个外贸询盘。新邮件进入 Gmail，webhook 立即叫醒 Work；Agent 提取客户、国家、产品和数量；再打开保留了登录状态的 CRM，查历史报价；最后把回信草稿和交期建议送到你面前。

过去这条线往往要用 Gmail webhook、Zapier 或 Make、RPA、浏览器脚本和 LLM 拼装。现在 OpenAI 想在 Work 里同时拥有事件、理解、工具、浏览器和人工批准。

这也是原稿最有价值的判断：新闻不是多了两个开关，而是“事件发生 → 理解 → 进入系统 → 执行 → 高风险处批准”开始成为一条产品链。

WebMCP 补的是第三块：别再让 Agent 猜按钮

OpenAI 同日启动的 WebMCP Challenge 把另一个老问题摆上桌面：Browser Agent 如果只会看屏幕、猜哪个蓝色方块是提交按钮，页面一改就可能跑偏。

WebMCP 是一个实验性开放标准。网站可以直接暴露结构化工具，明确告诉 Agent 可以搜索、更新记录或修改购物车，不用先模拟鼠标和键盘。ChatGPT 桌面端的内置浏览器已能在账号和网页都支持时发现这些 Site tools，并使用当前页面的登录状态。

别把它和 Work 的云浏览器混成一个东西。前者当前是桌面端内置浏览器里的网站工具协作；后者是在远程电脑上继续运行的委托任务。它们还没有变成一个无缝、全网通用的自动化层。

先别给它发工牌：三个现实限制

第一，网站有最终决定权。官方只承诺受支持的公开与已登录网站；部分站点会用风控或反自动化手段拦截云浏览器。

第二，“能进后台”不等于“能随便改后台”。付款、确认预订、发消息或修改外部数据仍可能暂停，等人审核。

第三，权限越实用，错误的代价越大。OpenAI 的云浏览器文档明确提到了提示注入、钓鱼和非预期动作，也明说防护不能消除所有风险。一个拥有 CRM 和邮箱 session 的 Agent，应该像新员工一样先用最小权限，而不是先拿管理员账号试手。

谁现在值得试

最适合的第一批流程，有一个共同点：触发信号清楚，需要理解上下文，但最终动作可以让人审核。比如客户回信后归纳需求、Slack 出现投诉后准备处理草案、PR 更新后总结变更与风险。

不适合的，是一上来就让它自动付款、删数据、承诺价格或给全体客户群发。先从“读、分类、查询、起草”开始，把“发送、修改、购买、删除”留在批准点后面。

实用性还取决于账号和地区。云浏览器在受支持地区的付费计划中提供，不含 Free 和 Go；企业工作区的事件触发任务还受管理员权限和 App 开关影响。

我们的判断

这次更新比“ChatGPT 又多了一个功能”大，因为它没有继续追问 Agent 还差多少分智商，而是在补决定它能否真上工的无聊基础设施：事件、登录态、权限、执行环境和批准点。

它还没到“数字员工”的终点，却已经从聊天框走到一个 Agent Runtime 的雏形：任务可以等待、被触发、使用 App、打开云浏览器、借助已登录 session 继续，遇到高风险动作再回来找人。

对 Zapier、Make 和传统 RPA，这还不是死刑。确定性流程仍更可靠，Agent 则擅长读懂含混信息并准备选项。但 OpenAI 正在主动吃进更多自动化平台的价值链，这条线值得继续盯。

仍然要观察

第一批用户真正需要回答的，不是演示能不能跑，而是长时间运行会不会漏事件、重复执行或因登录失效无声暂停。实际上线后还要看运行上限、审批延迟、错误恢复和审计记录是否足够好。

WebMCP 另一头也有冷启动问题。只有网站愿意做 Site tools，并把授权、回滚和确认机制一起做好，结构化工具才会比点按钮真正可靠。

最后还要盯住一个用户最在意的结果：它会不会帮你少打开三个后台，而不是只多了一个需要照看的 Agent 后台。

来源与证据边界

• 一手更新记录：OpenAI 8 月 25 日 Release Notes 明确写入受支持网站登录与 Gmail、Slack、GitHub PR webhook 触发；
• 一手产品文档：云浏览器文档支持安全登录流程、session 保留、网站限制和高风险确认；
• 一手任务文档：Scheduled Tasks 文档支持资格、三类事件源、管理员开关和需要批准时的暂停行为；
• 一手标准与实现说明：WebMCP Challenge 和 Site tools 文档支持“网站暴露结构化工具”与桌面端内置浏览器当前边界。