这次不聊本地部署也不聊开源模型来聊一个最近被频繁讨论的产品形态ChatGPT Work。从公开报道看ChatGPT Work 是 OpenAI 面向重度工作场景推出的订阅方案核心看点不是“多给几次对话额度”而是把浏览器智能体、编码智能体、项目空间这些能力打包成一个完整的工作台。其中最抓眼球的功能是让 AI 代登录网站、填表单、办杂务并且不泄露密码。这篇文章围绕三个问题展开ChatGPT Work 到底是什么、它代登录网站的流程怎么跑、密码不泄露的机制靠什么实现。同时会补上 Codex 组合玩法、边界风险和常见问题排查。如果你在做 Agent 调研或者属于每天跟表单、邮件、报销、订票打交道的重用户这篇可以直接收藏。1. 核心能力速览能力项说明产品类型OpenAI 面向工作场景的订阅方案整合 Agent 工作台能力主要能力浏览器智能体代登录/办杂务、Codex 编码智能体、项目工作区安全模型云端沙箱浏览器 任务会话隔离 敏感输入手动接管密码保护方式密码不进入模型上下文由用户在关键环节手动输入或由密码管理器自动填充使用入口Web 端与桌面端具体以官方开放情况为准部署方式云端服务不涉及本地部署批量任务支持多步骤任务连续执行符合账号限额即可适合人群重办公用户、Agent 技术调研者、开发者不适合场景银行转账、无授权账号操作、违反平台条款的自动化、高度敏感业务费用高价位订阅档正式定价以 OpenAI 官方页面为准注意不同报道对具体权益的描述不完全一致本文只写能力方向不写死模型版本、对话额度和开放地区。实际以官方产品页为准。2. ChatGPT Work 是什么不是加额度是换工作方式从公开信息看ChatGPT Work 是 OpenAI 在常规 Plus/Pro 订阅之外面向“天天用 ChatGPT 干活”的重度用户推出的一档方案。它和普通订阅最大的区别不是模型更强或额度更多而是把 Agent 能力真正产品化了。具体来说它的能力大致分三层。第一层是浏览器智能体。用户可以给一个自然语言任务比如“帮我查某电商平台某个商品的历史最低价”“把这份表格信息填到报名系统里”它会在云端打开浏览器访问网站按步骤执行操作最后返回结果或截图。第二层是编码智能体 Codex。它可以读取代码仓库、写代码、改 bug、跑测试、提交改动。Codex 本身不是新项目但把它放进 Work 订阅里意味着用户可以把“网页杂务”和“编码任务”放在同一个工作流里完成不再需要切到另一个工具。第三层是项目工作区。对话、文件、Agent 任务、代码任务可以在同一个空间里组织适合一个需求对应一个项目的使用习惯。所以更准确地说ChatGPT Work 不是“ChatGPT 的升级版”而是“Agent 工作台”。普通 ChatGPT 像一个智能问答终端问一句答一句ChatGPT Work 更像一个能自己动手干活的数字助理你交代它办一件事它从头到尾把事办完。对技术读者来说真正值得关注的不是订阅价格而是这套产品定义释放的信号AI 产品的评价标准正在从“回答质量”转向“任务完成率”。表单填了没有、订单下了没有、代码测试过了没有这些指标比生成速度更能衡量 Agent 好坏。3. 开通与首次使用需要准备什么ChatGPT Work 是云端服务不涉及环境装包、CUDA 配置、本地模型下载。但首次使用之前有几项准备工作值得提前做。3.1 账号与开通需要一个 OpenAI 账号并且所在地区在服务开放范围内。确认当前账号能升级到 Work 档订阅入口以官方页面为准。支付方式要提前准备好这类工作档订阅通常需要国际信用卡或对应支付渠道。3.2 使用入口推荐先用 Web 端跑通核心功能再考虑桌面端。首次进入后先找 Agent 功能入口常见入口是新建任务时选择代理模式或浏览器模式不同版本入口名称可能有差异。如果同一账号在多个设备登录注意会话状态是否互斥。3.3 安全准备这是比开通更重要的一步。在使用代登录能力之前先把下面几件事确认清楚准备把哪些账号交给 Agent 操作这些账号的权限边界是什么。确认目标网站本身是正规站点避免把账号交给钓鱼站。第一轮测试不要用核心账号用一个低频、可注销的测试账号跑通流程。提前关闭目标账号的多因素验证或用“应用专用密码”替代主密码减少敏感信息暴露面。阅读官方关于敏感信息和隐私的说明明确哪些操作会被记录。3.4 明确任务边界首次使用不建议直接下“帮我订酒店”这种大而全的指令。更稳妥的做法是拆成“先查三家中等价位酒店列出价格和地址不要下单”这种带明确边界的任务等流程跑通了再逐步放开权限。4. “代登录网站办杂务”的执行流程拆解这一节拆一下 Agent 执行杂务的完整链路。理解这个链路后面排查问题会容易很多。以“帮我查某平台下周三从北京到上海的航班筛选上午出发、价格最低的前三个整理成表格”为例整个流程大致如下步骤Agent 行为需要用户做什么1. 接收任务解析自然语言拆成子步骤提供清晰的 URL 或站点名称2. 规划路径决定先打开哪个页面、按什么顺序筛选无3. 打开云端浏览器创建独立会话进入目标站点无4. 登录检查判断页面是否要求登录如果遇到登录可能需要手动接管5. 执行操作搜索、筛选、记录结果无6. 汇总输出把结果整理成表格或文本无7. 确认结束汇报结果关闭任务核对结果是否准确这里最值得关注的节点是第 4 步登录检查。如果目标站点要求登录Agent 会停下来询问而不是自己尝试猜测密码。这时候用户有两个选择一是手动接管浏览器完成登录再交还给 Agent二是让密码管理器自动填充Agent 全程不接触明文字符串。整个执行过程中用户在界面上通常可以看到云端浏览器的实时画面或操作日志相当于“看着一个远程员工干活”。这个设计对信任建立很重要Agent 不是黑箱它每一步做了什么用户都能回看。5. 密码不泄露的底层机制标题说“可代登录网站办杂务且不泄露密码”这是很多人最关心的点。下面按公开资料和这类浏览器 Agent 产品通用的安全架构拆一下机制。5.1 云端沙箱浏览器Agent 运行在一个独立的云端浏览器环境里而不是调用用户本地的 Chrome、Edge 或 Safari。这样做有几个直接好处本地浏览器的 Cookie、历史记录、插件状态不会同步到云端。用户本机不需要安装任何来自该服务的浏览器插件或驱动。任务结束后云端浏览器会话可以被销毁减少残留。换一个角度理解Agent 的浏览器和你的日常浏览器是两台互不相干的“机器”。它只是借你的账号在云端执行任务并不是接管你的整个本地浏览器。5.2 敏感输入不进入模型上下文“不泄露密码”最关键的一点在于密码这种敏感信息不应该被转换成模型可读的文本送进提示词上下文。实际操作中常见的实现方式是当页面出现密码输入框时Agent 能识别“这里需要验证”但是真正填入密码的动作由用户手动完成或者由浏览器密码管理器自动填充。模型看到的只是密码框状态从“空”变成“已填写”看不到明文字符串。这个设计思路可以类比为员工知道“需要刷卡进门”但门禁卡在用户手里员工只是等待用户刷卡之后继续走流程。5.3 手动接管机制这也是浏览器 Agent 类产品最常见的交互设计任务进行到密码、验证码、支付确认这类关键步骤时界面会提示用户“接管控制”。用户点一下就像操作远程桌面一样自己完成敏感输入再交还给 Agent 继续执行。手动接管的意义在于Agent 不需要知道密码也能完成“需要密码才能做的事”。密码只存在于用户和云端浏览器之间不经过模型推理链路。5.4 会话隔离与清理任务会话之间相互隔离。一次任务里登录了账号 A不代表下一次任务继承了同样的登录态。更稳妥的实现会在任务结束后清理会话下次需要时重新登录验证。这有两个好处一是任务之间的数据不会互相污染上一个任务的页面状态不会带进下一个任务二是即使云端环境被攻破单次会话的账号凭据也不会形成长期持久化风险。5.5 这套机制的边界需要说清楚这套机制能防什么、不能防什么。能防的防模型把明文密码记录在对话历史里防浏览器插件随意读取本地数据防任务完成后登录态长期残留。不能防的如果你在任务指令里直接输入了明文密码密码就进入了上下文和“代登录方案”的设计前提无关。如果目标网站本身就是钓鱼站Agent 登录进去反而会把账号数据暴露给不可信站点。如果账号开启了短信二次验证验证码必须由你提供那么验证码仍然要经过人工环节。所以“不泄露密码”应该理解为“系统设计上尽可能让密码不经过模型”而不是“这个服务认为你的密码绝对安全”。使用前仍然要评估目标网站的合法性、账号的权限边界、任务操作的可逆性。6. 与 Codex 的组合从办杂务到写代码最近的热词里“chatgpt work 和 codex”经常一起出现。原因不难理解ChatGPT Work 的价值不只是办杂务而是把“浏览器操作”和“代码开发”两条能力线接到同一个工作区里。Codex 是 OpenAI 的编码智能体可以在云端沙箱环境里读写代码、执行命令、运行测试。把它和浏览器智能体放在一起能组合出实际工作流。例如浏览器智能体负责查文档打开 API 官网、读取接口说明、抓取示例代码。Codex 负责写代码把查到的接口说明转成集成代码。Codex 再负责跑测试没有测试环境的先在本地沙箱里起一个 mock 服务验证。浏览器智能体负责提交结果登录代码托管平台创建 PR把改动推上去。整体链路已经接近一个“开发助理”的雏形。用户给方向Agent 查资料、写代码、自测、提交中间几个环节都可以用浏览器智能体补位。不过要提醒两点第一编码任务最好在测试仓库里先跑避免直接改动生产分支第二涉及第三方服务的账号、密钥、访问令牌不要写进对话或代码里应通过环境变量或密钥管理工具注入。7. 功能测试用三个小任务验证效果第一次拿到这类 Agent 能力建议按下面的测试顺序验证不要一上来就安排真实业务。7.1 任务一账号登录 信息查询测试目的验证代登录流程和会话是否正常。输入示例“打开 https://example.com登录账号 test001查看我的订单列表把最近一笔订单的状态告诉我。”操作步骤新建任务输入指令观察云端浏览器画面。预期结果Agent 能正常打开页面触发登录动作登录成功后正确读取订单状态。判断成功的标准返回的订单信息和你本机浏览器查到的结果一致。常见失败原因账号密码错误、验证码拦截、目标站点禁止自动化访问。7.2 任务二多步骤表单任务测试目的验证填表、提交、结果回传的完整链路。输入示例“在测试报名系统里帮我填写报名表姓名张三邮箱 testexample.com项目方向选后端提交后把报名成功的页面截图给我。”操作步骤确认目标是一个可逆的测试站点再下达指令。预期结果Agent 逐项填写提交后能返回截图或确认信息。判断成功的标准目标站点后台能看到这条新记录字段内容无误。常见失败原因页面结构复杂、下拉框操作失败、二次确认弹窗漏点。7.3 任务三Codex 编程任务测试目的验证编码智能体能闭环完成代码任务。输入示例“读取仓库根目录的 README把其中的 API 调用示例改写成 Python requests 版本运行单测确认通过。”操作步骤在测试仓库中运行仓库包含最小单测。预期结果Codex 生成代码运行测试结果通过。判断成功的标准测试通过改动内容符合需求。常见失败原因仓库权限不足、依赖安装失败、环境变量缺失。三个任务跑下来重点观察三个指标任务完成率、是否频繁需要人工接管、单次任务的配额消耗。如果一个小任务都频繁卡住说明当前站点兼容性或账号配置还需要调整不要直接上真实高频任务。8. 稳定性观察与常见问题排查Agent 任务和普通对话的最大区别是持续时间长、环节多任何一个环节出问题都可能让整个任务卡住。下面按问题现象给出排查建议。问题现象可能原因排查方式解决建议代理无法登录某网站网站有验证码、二次验证或风控观察云端浏览器实时画面手动接管完成登录再交还给 Agent任务执行到一半卡住页面弹窗、页面结构变化、登录过期查看任务日志和浏览器画面补充指令、重新登录、重新发起任务密码不自动填充密码管理器未保存该站点或站点表单结构特殊检查密码管理器记录手动输入后选择记住本次会话自动下单/支付失败平台风控、短信验证、支付方式受限检查支付环节支付与验证步骤改为手动接管额度消耗过快单任务步骤多、上下文长查看用量页面拆分任务减少单次任务复杂度代理访问的页面与预期不符地区跳转、账号权限不同、Cookie 状态差异对比本机访问结果明确给出完整 URL避免模糊指令任务超时中断长任务超过系统限制检查日志中的超时节点把任务拆成多个子任务分步执行输出内容不准确Agent 误读了页面信息回看操作日志用结构化指令重新描述需求一个更稳妥的操作习惯是重要任务先走一遍“小成本验证”。先让 Agent 只做查询和展示不做任何不可逆操作。跑通之后再放开修改、下单、提交这类高权限动作。稳定性这个东西跑一次和跑十次结论完全不同不要用单次成功评估整体可靠性。9. 使用边界、风险与合规提醒Agent 能代办杂务不代表所有杂务都适合交给 Agent。以下几点边界需要提前想清楚。9.1 账号授权边界只能让 Agent 操作自己拥有或获得明确授权的账号。未经授权登录他人账号、绕过付费墙、批量抓取受限数据都属于越界行为不在正常使用范围内。9.2 平台条款兼容性不少网站的服务条款明确禁止自动化访问和脚本操作。Agent 代登录本身可能触发平台风控轻则验证码弹窗重则账号被限制。使用前先看目标平台的条款不要拿核心账号测试。9.3 支付与不可逆操作自动下单、支付、修改配置、删除数据这类操作影响面大且难以撤回。第一原则是“关键步骤人工接管”。让 Agent 把流程推进到支付页面然后用户自己完成付款这是相对安全的使用方式。9.4 隐私与数据合规任务指令、网页内容、操作日志都可能包含个人信息。如果处理的是客户数据、企业内部数据或受监管数据需要确认服务商的隐私政策、数据留存机制和所在地区的合规要求。涉及人脸、声音、个人身份信息等敏感数据时更要严格限制处理范围。9.5 输出复核Agent 会把页面内容总结给你但总结可能出错。价格、日期、数量这类关键信息必须回到原文核对。可以要求 Agent 提供截图或原始数据作为佐证降低误导风险。10. 最佳实践与总结10.1 实践建议任务描述多用结构化指令。写清楚网址、账号、期望结果、禁止操作比写“帮我处理一下航班的事情”可靠得多。一个推荐模板是目标网址 任务目标 成功标准 禁区。先跑通最小任务再逐步放权。第一次用时任务越小越好比如只查不订、只读不改。等 Agent 在小任务上表现稳定了再尝试完整链路。敏感操作一律人工接管。密码、验证码、支付确认、删除确认这四个环节尽量自己操作不要图省事全交给 Agent。保留任务日志。Agent 执行完任务后导出操作记录或保留页面截图特别是有外部对接或审计需求的场景。控制任务频率。高频自动化容易被目标站点风控标记合理做法是降低频次避免同一时间大量并发任务。10.2 总结回到开头的问题ChatGPT Work 值不值得关注答案是值得。它不是“又一个订阅档”而是把 AI 从“回答者”变成“执行者”的一次产品化尝试。代登录网站办杂务、密码不泄露的安全设计、Codex 组合成开发工作流这三个点都值得实际体验后再下判断。最先应该验证的是第 7 节的三个小任务特别是登录和信息查询任务。如果小任务都跑不通说明 Agent 的站点兼容性没有达到你的预期如果跑通了再逐步扩大到真实业务场景。最容易踩的坑有两个一是把密码直接写进任务指令等于绕过了整套安全设计二是对不可逆操作完全放手自动下单、自动删除这类动作要设置人工确认。下一步可以继续观察的方向是Codex 与浏览器智能体的联动深度、任务完成率在真实业务中的表现、以及 Agent 生态在订阅方案里的进化速度。新产品刚出现时差距最大也最值得追。