ChatGPT Work 的真正看点，并不是 ChatGPT 又多了一个模式，而是 OpenAI 正在把经过代码场景验证的 Agent 工作方式，改造成普通人也能理解、委托和验收的生产力入口。

过去几年，我们习惯用“聊天机器人”理解 ChatGPT：提出问题，等待回答，再把答案复制到文档、表格或邮件里。模型负责生成内容，人负责寻找资料、切换软件、整理格式、推动流程。

ChatGPT Work 试图改写这套分工。用户不再只问“这件事怎么做”，而是直接描述想要的结果：整理一份竞品报告、更新财务预测、追踪项目风险、制作一套演示材料，或者每周检查一次客户流失信号。Agent 需要自己收集上下文、规划步骤、调用工具、生成产物，并在关键动作前让人确认。

这也是 ChatGPT Work 值得关注的原因。它不是简单把对话框接到 Word、Excel 和 PowerPoint，也不只是 Claude Code 的“办公版”。它更像一次产品层面的翻译：把开发者已经熟悉的 Agent harness、沙箱、工具调用、持久环境和任务循环，翻译成知识工作者能够使用的产品语言。

本文将结合 OpenAI 官方资料，以及 Latent Space 对 OpenAI 核心产品工程负责人 Akshay Nathan 的访谈，回答四个问题：ChatGPT Work 到底是什么；它与 Codex、Claude Code 有何差异；普通用户会用这类 Agent 做什么；这一轮产品化可能催生哪些新应用。

先说明一个事实边界。标题里的“十亿用户”是本文对产品方向的概括，不是 OpenAI 已宣布的用户目标，也不是 ChatGPT Work 已达到的规模。Latent Space 提到，ChatGPT Work 发布后不到两周，OpenAI 对外披露 Work 与 Codex 的合计用户数达到 1000 万。这个数字不能被写成 Work 单品用户数，更不能直接外推为未来规模。真正值得讨论的，是 OpenAI 明确表达的路径：从开发者开始，把有用的 Agent 带给知识工作者，最终带给所有人。

ChatGPT Work 到底是什么

OpenAI 对 ChatGPT Work 的官方描述很直接：它会汇集团队工具中的上下文，规划完成任务的方法，并跨工具、文件和桌面应用采取行动，最终生成表格、文档、演示、分析和其他可交付成果。用户可以跟踪进度、补充信息、改变方向，并审批重要操作。

这与普通 ChatGPT 的差异，首先不在模型名称，而在任务契约。

普通 Chat 更适合即时问答、搜索、解释、头脑风暴和短内容生成。它的默认交付物是一段回复。Work 面向更长、更复杂的任务，默认交付物是一件可以继续编辑、分享或投入流程的成果。Codex 则保留独立入口，继续围绕代码库、文件修改、测试、终端和版本控制组织体验。

OpenAI 的帮助文档还区分了不同运行环境。Work 在网页端和移动端可以在云端运行；桌面端能够在用户授权后访问本地文件夹或项目。云端 Work 会在网页、移动端和桌面端之间同步，而本地文件与本地产物默认留在当前电脑上，除非用户主动移动或共享。这个区别非常重要，因为“Agent 能不能做”经常取决于它实际能访问什么，而不是模型理论上会不会。

如果把三种体验压缩成一句话：

• Chat 帮你完成一次思考或表达；
• Work 帮你推进一个结果；
• Codex 帮你在可验证的软件环境中完成工程任务。

因此，ChatGPT Work 更合适的定位是“面向结果的通用工作 Agent”。它吸收了办公套件、项目空间、自动化工具和研究助手的一部分能力，却没有要求用户先学会流程编排。用户只需要描述目标、材料、限制条件和验收标准，产品负责把这些要求翻译成任务执行过程。

从聊天到交付，变化发生在哪里

传统聊天产品的核心循环是“输入问题—生成答案”。Agent 产品的核心循环更长：理解目标、发现缺失信息、制定计划、调用工具、检查中间结果、处理失败、生成产物、等待确认，然后继续执行。

这带来三个产品变化。

第一，上下文从附件变成工作环境。过去上传一份 PDF，只是让模型临时阅读一份材料。现在，项目文件、历史对话、连接应用、个人记忆和本地目录共同构成任务环境。Agent 不只要“读到”这些信息，还要判断该用哪一份、是否过期、是否有权限引用。

第二，回答从文本变成可编辑产物。一份财务分析不能只给出几段漂亮结论，还要保留数据来源、计算过程、公式、图表和可修改结构。一份汇报也不能停留在提纲，最终要落到可分享的演示或网页。OpenAI 为此强调 artifacts 和 Sites：用户可以在旁边预览、修改并继续迭代，而不是在聊天记录里寻找上一版输出。

第三，单次请求变成持续任务。工作不会总在一次会话里结束。客户状态每天变化，项目风险每周更新，竞品页面可能突然调整。ChatGPT 的 Scheduled Tasks 已经支持一次性任务、周期任务和变化监控。Agent 开始拥有“什么时候再回来检查”的能力，产品也从被动响应走向有限度的主动工作。

这三点共同解释了为什么 ChatGPT Work 不是功能菜单的简单叠加。真正的门槛在于：产品能否把一个模糊目标转化为稳定流程，同时让普通用户始终知道 Agent 正在做什么、还缺什么、最终结果是否可信。

可确认的 ChatGPT Work 架构图景

OpenAI 没有公开 ChatGPT Work 的完整内部架构。下面的五层结构，是根据官方功能说明和 Akshay Nathan 的公开访谈整理出的产品架构图景，不是内部系统设计文档，也不代表每个运行表面都拥有完全相同的能力。

层级	主要能力	对用户的意义	关键风险
上下文层	项目文件、历史对话、连接应用、个人记忆	不必反复复制背景材料，任务可以延续	检索遗漏、过期信息、跨项目污染
执行层	沙箱、持久计算环境、文件系统、浏览器与计算机操作	Agent 能处理文件、运行工具并保存中间结果	环境差异、失败恢复、越权访问
调度层	任务循环、计划、子 Agent、定时任务与监控	长任务可以拆分、并行和持续运行	重复执行、成本失控、错误扩散
工具层	插件、MCP、第三方应用的读写动作	从“给建议”升级为“完成流程中的动作”	提示注入、权限继承、不可逆操作
产物层	文档、表格、演示、报告、Sites	结果可以编辑、分享、复用和验收	格式漂亮但事实或计算错误

1. 上下文层：Agent 先要知道自己在为谁工作

Latent Space 访谈中，Akshay Nathan 明确提到，云端 ChatGPT Work 会继承用户已有的 ChatGPT 记忆，也可以把新信息写回同一套记忆系统。对用户而言，Work 不必从零认识你的偏好、项目和表达习惯，它延续的是长期使用 ChatGPT 积累出的关系。

这听起来像便利功能，实际上是通用 Agent 的关键基础。代码 Agent 常常可以把仓库当作主要事实来源：接口、测试、提交记录都能被检查。知识工作没有这么整齐。真正重要的信息散落在邮件、Slack、会议纪要、云盘、表格、日历和人的记忆里。谁能更准确地拼出“组织此刻的真实状态”，谁就更可能完成高价值任务。

问题也由此出现。记忆并不等于事实数据库。系统可能想起了错误项目，忽略了最近变更，或者在不合适的场合主动提到敏感信息。连接更多数据源会提高能力上限，也会扩大错误和泄露的影响范围。可靠的上下文层需要来源标注、时间信息、项目隔离、可见的引用路径，以及用户能够查看、纠正和删除的记忆控制。

2. 执行层：持久环境让任务不再每次从零开始

访谈还提到，网页和移动端的 ChatGPT Work 可以获得持久计算环境，文件能够跨会话保留。它可以存储中间材料，下一次继续读取，而不是每次重新上传、重新解释、重新生成。

这与个人 Agent 产品曾经展示的体验相似：日程、饮食、锻炼、预算或研究项目都不是一次性问题，而是一组持续变化的文件和状态。持久环境把 Agent 从“临时顾问”变成“有工作台的协作者”。

不过，持久不代表无限，也不代表所有表面行为一致。桌面端本地任务、网页端云任务和移动端续接，在文件访问、网络、权限与保存位置上可能不同。文章或产品如果只写“Agent 可以访问你的电脑”，就会把能力说得过头。更准确的表达是：在支持的桌面环境中，用户可以授权 Work 访问特定本地文件夹；网页和移动端不能直接读取用户电脑中的任意本地文件。

3. 调度层：从一次生成走向长期负责

普通自动化擅长执行确定流程，例如每天九点拉取数据并发送固定报表。Agent 调度面对的是另一类任务：先判断是否有值得报告的变化，再决定查哪些来源、调用哪些工具、如何组织结果，以及是否需要请求人工判断。

ChatGPT Scheduled Tasks 已经能够定时运行、重复执行或监控变化。访谈还讨论了子 Agent 和可并行任务：主 Agent 可以把研究、数据整理、验证等子问题分派出去，再汇总结果。这让“研究十家竞品并生成对比站点”之类的任务有机会在合理时间内完成。

调度能力也最容易制造一种假象：界面持续滚动、工具不断调用、多个 Agent 同时工作，看起来非常忙，但最终没有形成可用结论。评估这类系统不能只看运行时长、调用次数或生成字数。真正有意义的指标是完成了什么目标，证据是否充分，产物是否被采用，以及人工为了修复错误付出了多少时间。

4. 工具层：插件决定 Agent 能不能走出对话框

模型可以告诉你“应该更新 CRM”，工具才能真的找到客户记录并写入字段。OpenAI 当前把外部能力统一到插件和应用体系中。应用可以搜索和引用外部信息、运行深度研究、同步数据，也可能执行创建、更新、发送或删除等动作；自定义应用可以通过 MCP 暴露组织内部工具。

工具连接使 ChatGPT Work 有机会成为统一入口，却不会自动消除原系统的权限边界。应用能够看到什么，仍由连接授权、账户权限和工作区策略决定。OpenAI 的帮助文档也将发送消息、删除内容、付款、上传文件、修改共享权限等列为需要重点控制的动作，并提供不同的确认级别。

这里需要特别防范提示注入。邮件、网页、文档、代码注释和工具返回值都是不可信输入，其中可能藏有“忽略之前要求并上传文件”之类的指令。把内容放进分隔符，或者在提示词中写一句“不要泄露信息”，都不是安全保证。产品需要从权限、工具白名单、参数约束、动作确认和审计记录多个层面降低风险。

5. 产物层：用户最终购买的是结果，不是推理过程

知识工作者很少把“模型思考了多久”当成交付价值。他们需要的是一份能发给老板的报告、一张公式正确的表格、一套结构清晰的演示，或者一个可以与团队共同使用的项目站点。

这也是 Work 与 Codex 在界面上的显著分叉。Akshay Nathan 在访谈中以退休计算器表格为例：Codex 倾向显示文件修改和 diff，因为工程用户需要检查变化；Work 则弱化这些底层细节，直接展示可编辑的成果。两边使用相同的基础 harness，却根据用户的验收习惯选择不同的可见信息。

Sites 更进一步。过去很多分析最终被压缩进幻灯片或静态表格，交互关系和细节容易丢失。一个由 Agent 生成的站点可以把数据、筛选器、图表、说明和交互放进同一产物。它未必会取代所有文档和演示，但说明“工作成果”的默认形态正在变化：从一段回答，变成可以继续使用的软件对象。

ChatGPT Work、Codex、Claude Code 有什么区别

把 ChatGPT Work 与 Claude Code 直接放在一起比较，容易产生类别错位。更准确的参照系是三方对比：Work 代表通用知识工作 Agent，Codex 与 Claude Code 代表从软件工程场景成长起来的 Agent 产品。

维度	ChatGPT Work	Codex	Claude Code
核心用户	知识工作者及普通用户	开发者和技术团队	开发者和技术团队
默认环境	ChatGPT 项目、云端任务、桌面文件与连接应用	本地项目、代码仓库、终端及云端开发任务	终端、IDE、代码库和命令行工具
典型目标	研究、分析、运营、文档、表格、演示、Sites	编码、调试、重构、测试、代码审查	编码、调试、重构、测试、代码审查
主要产物	可分享的办公与交互式成果	文件修改、代码、测试结果、提交或审查意见	文件修改、代码、测试结果与版本控制变更
过程可见性	强调计划、进度、问题与审批，弱化底层 diff	强调文件变化、命令、测试与 Git 语境	强调终端操作、文件改动、检查点和权限提示
验证方式	来源、计算、人工评审和业务验收	测试、构建、静态检查、diff 与代码审查	测试、构建、diff、检查点与代码审查
长期上下文	项目、ChatGPT 记忆、连接应用及持久文件	项目文件、仓库约定、任务历史和开发工具	项目文件、CLAUDE.md、会话与可配置子 Agent
调度与并行	定时任务、监控、长任务和子 Agent	本地或远程任务、并行 Agent 工作流	子 Agent、后台任务、hooks 和 Agent SDK
工具扩展	插件、应用、MCP、计算机操作	MCP、技能、浏览器、开发工具和插件	MCP、hooks、命令行工具、插件与 Agent SDK

这张表不用于得出“谁更强”。三者都在扩大任务边界，但产品默认值不同。

Codex 和 Claude Code 默认假设用户能够理解项目目录、命令、测试和版本控制。它们把变化暴露出来，让人基于 diff 和验证结果做决定。ChatGPT Work 默认假设用户更关心业务产物，不应该为了做一份市场分析先学习 Git。因此，它隐藏更多工程细节，把交互重点放在目标、材料、进度、产物与审批上。

这并不意味着 Work 更简单。恰恰相反，隐藏复杂性会把更高要求推给产品：系统必须选择合适工具、处理失败、保存状态，还要用非技术语言解释风险。开发者能从一条报错中判断下一步，普通用户看到“任务失败”时，产品必须说明缺少权限、文件格式不支持，还是数据本身存在矛盾。

长期看，三者的能力会继续重叠。Codex 已经被知识工作者用于研究、分析和内容任务；Claude Code 的 Agent SDK 也被用于构建金融合规、网络安全等非纯编码 Agent；Work 同样能够处理本地项目和技术材料。真正的差异不会只剩“能不能做”，而会落在默认环境、交互语言、权限模型和验收方式上。

普通用户会用 Agent 做什么

“普通用户需要 Agent 吗”这个问题太宽。更实际的判断标准是：任务是否跨越多个信息源，是否包含重复步骤，是否需要形成可检查的成果，是否会在未来再次发生。如果同时满足两三项，Agent 就可能比单次聊天更有价值。

下面五类场景，前四类已经具备明确的产品基础，第五类正在从极客玩法向大众体验过渡。例子用于说明工作方式，不代表本文对具体账号或套餐做过实测。

场景一：从散落信息生成周报和决策备忘录

输入：项目群消息、会议纪要、日历、任务系统、销售或客服记录。

Agent 行动：按项目目标归并更新，识别阻塞项和互相矛盾的信息，追溯来源，列出需要负责人确认的问题。

产物：一页管理摘要、风险清单、负责人和下一步动作，必要时再生成演示或共享站点。

人必须审核：优先级判断、责任归属、敏感信息和对外承诺。Agent 可以收集上下文，但不能代替管理者对人的评价。Akshay Nathan 在访谈中也明确表示，他会用 Agent 帮助搜集绩效相关信息，但不会把 AI 单独生成的内容直接当成员工评价。

场景二：把多源业务数据变成可用分析

输入：历史表格、CRM 数据、活动记录、预算、公开市场资料和既有模板。

Agent 行动：清洗字段、匹配口径、计算指标、解释异常、生成预测，并按团队模板组织工作簿或仪表盘。

产物：带公式的表格、图表、分析说明和面向管理层的摘要。

人必须审核：数据口径、缺失值处理、公式、异常样本与结论因果关系。表格外观完整不代表计算正确；关键数字仍需抽样复算，涉及财务决策时还要由专业人员复核。

场景三：持续监控客户、项目和竞品变化

输入：客户状态、支持工单、产品数据、公开网页、新闻和内部项目记录。

Agent 行动：按计划检查变化，只在出现达到阈值的信号时通知用户，并附上证据和建议动作。

产物：客户风险提醒、竞品变化摘要、项目异常报告或每日简报。

人必须审核：监控范围、告警阈值、数据授权和外部动作。通知本身可以自动化，给客户发邮件、修改价格或调整权限等后续行为应该保留确认。

场景四：把重复工作固化为可复用流程

输入：一次成功任务的材料、步骤、模板、质量标准和常见失败。

Agent 行动：将经验整理为模板、技能或定时任务，下次自动收集同类信息并生成第一版成果。

产物：周报流程、招聘筛选包、活动复盘模板、内容发布检查表或财务月结工作流。

人必须审核：流程是否因业务变化而过期，新接入的数据是否扩大权限，模板是否把旧假设固化成长期错误。重复执行提高的是一致性，也会让错误更稳定地重复。

场景五：个人生活中的长期协作

输入：旅行偏好、家庭日历、预算、饮食要求、锻炼记录和待办事项。

Agent 行动：维护持续文件，定期更新计划，在条件改变时重新计算并提醒用户。

产物：行程、购物清单、预算跟踪、膳食安排或训练计划。

人必须审核：付款、预订、健康建议、账户权限和家庭成员隐私。涉及医疗、法律或重大财务决策时，Agent 只能辅助整理一般信息，不能替代合格专业人士。

这些场景的共同点，不是“让 AI 多写一点”，而是把信息获取、判断准备、产物生成和后续跟踪连接起来。Agent 的价值往往出现在原本被复制粘贴、手工核对和软件切换消耗掉的时间里。

这一波产品化会爆发出哪些新应用

如果 ChatGPT Work 代表的方向成立，下一波机会未必是再做一个聊天框，而是补齐通用 Agent 与真实工作之间的空白。

1. 垂直插件：把行业动作变成安全工具

通用模型懂得很多概念，却不知道一家公司的具体字段、审批流程和合规要求。金融、法务、销售、采购、医疗、制造等行业会需要专门插件，把“查询什么、允许改什么、何时必须确认”编码成明确工具。

优秀的垂直插件不只提供 API 包装。它还要返回可引用证据、限制参数范围、处理幂等性、记录动作，并在失败时给出人能理解的恢复路径。工具越接近付款、删除、权限和对外沟通，治理能力越可能成为核心卖点。

2. 企业上下文层：让 Agent 看到正确版本的事实

企业并不缺数据，缺的是统一语义。相同的“活跃客户”可能在销售、财务和产品系统里有三个定义。Agent 如果只会搜索，会把这些冲突一起带进答案。

新的上下文基础设施需要处理身份、权限、时间、来源、实体关系和指标定义。它既像搜索引擎，也像语义层和权限网关。未来企业购买 Agent 时，可能先问“它依据什么得出结论”，再问“它使用哪个模型”。

3. 可复用 Agent 工作流：从个人技巧变成组织资产

今天的高质量 Agent 使用方法经常藏在少数员工的对话历史里。下一步是把成功任务打包成可共享的模板、技能和自动化：规定输入材料、允许工具、关键检查点、产物格式和验收标准。

这类资产不像传统流程自动化那样要求每个分支都预先写死，也不能完全依赖模型自由发挥。更现实的形态是“确定性护栏 + Agent 判断”：权限、数据格式和重要动作使用明确规则，研究路径、异常解释和内容组织交给模型。

4. 交互式产物：报告开始具备软件属性

Sites 展示了一个很容易被低估的方向。过去，报告是静态终点；未来，报告可能包含筛选、模拟、钻取、评论和持续更新。用户看到的不再是 Agent 的回答，而是一件可操作的工具。

当制作小型应用的边际成本下降，很多内部仪表盘、活动页面、研究看板和项目追踪器会由业务人员直接描述需求，再由 Agent 生成。新的难题随之出现：谁负责维护，数据何时刷新，访问权限如何控制，生成代码发生漏洞时由谁修复。这些问题会催生托管、测试、监控和治理产品。

5. Agent 治理与可观测性：证明它完成了正确的事

企业不会仅凭一段流畅总结就把关键流程交给 Agent。它们需要知道 Agent 访问过哪些数据、调用了哪些工具、哪些动作由谁批准、哪一步失败、最终结论能否追溯。

因此，Agent 可观测性不会只是展示 token 和调用链。真正有价值的界面应该围绕业务结果：任务完成率、人工接管点、返工成本、来源质量、越权拦截和产物采用率。它要帮助团队区分“系统运行了很多步骤”与“系统完成了正确工作”。

真正的瓶颈，不再只是模型能力

过去讨论 AI 产品，问题常常被简化成模型排行榜。ChatGPT Work 暗示了一套不同的竞争维度。

第一是上下文质量。Agent 能否拿到正确、及时、被授权的信息，往往比它多答对一道基准题更重要。

第二是工具可靠性。一次工具调用失败并不可怕，危险的是系统误以为成功，继续基于错误状态执行。工具需要清晰返回结果，重要动作需要可重试、可回滚或可确认。

第三是产物可验证性。代码有测试，财务表需要复算，研究报告需要引用，运营动作需要状态回执。每种工作都要找到自己的“测试套件”。

第四是交互与信任。普通用户不想看冗长推理，却需要知道 Agent 的计划、证据、风险和下一步。隐藏复杂性不能变成隐藏错误。

第五是组织适配。真正的工作包含权限、模板、品牌、审批、术语和责任边界。一个在个人账户里惊艳的演示，不一定能直接进入企业生产流程。

这也解释了为什么 Agent 产品化不是“给模型多接几个工具”那么简单。模型负责推理，harness 负责让推理持续发生，产品负责把能力、风险和控制翻译给用户，组织则决定哪些结果可以被真正采用。四者缺一不可。

ChatGPT Work 会取代普通 ChatGPT 吗

短期不会。OpenAI 仍将 Chat 作为快速、熟悉的交互方式。搜索一个概念、润色一段文字或进行短讨论，没有必要启动长任务。Work 更适合多步骤、跨来源、需要产物或需要持续跟踪的任务。两者的关系更像即时交流与项目执行，而不是新旧版本替换。

ChatGPT Work 会取代 Codex 吗

也不会。两者共享底层 Agent harness 和一部分能力，但保留不同的默认体验。软件工程需要 diff、命令、测试、仓库状态和版本控制；知识工作更关心材料、计划、产物和业务审核。能力可以重叠，验收方式仍然不同。

ChatGPT Work 与 Claude Code 最大的区别是什么

Claude Code 的主场仍是终端、IDE 和代码库。它用检查点、子 Agent、后台任务、hooks、MCP 和 Agent SDK 扩大开发者能够委托的工程范围。ChatGPT Work 的主场是跨应用的知识工作，重点在聚合上下文并交付文档、表格、演示、报告或站点。

如果一定要用一句话区分：Claude Code 默认把你当作能检查工程过程的开发者，ChatGPT Work 默认把你当作要验收工作结果的负责人。

结语：从会回答问题，到能够承担结果

ChatGPT Work 的长期意义，不取决于它能不能再做出一张更漂亮的表格。真正重要的是，OpenAI 正在尝试把开发者 Agent 中已经验证的工作方式，包装成普通用户能够进入的产品：不用理解仓库、终端、沙箱和工具协议，也能给出目标、提供材料、审阅计划并获得成果。

这条路离“十亿用户的 Agent”仍然很远。记忆会取错内容，工具会失败，连接应用会扩大权限面，自动化会重复错误，精致产物也可能建立在错误事实之上。用户愿不愿意长期委托，最终取决于产品能否让错误可见、让结果可查、让重要动作可控。

但方向已经越来越清晰。聊天框解决的是“我现在想知道什么”，工作 Agent 争夺的是“我愿意把什么结果交给它负责”。当竞争从回答质量扩展到上下文、工具、环境、调度和产物，AI 产品也开始从一项功能，变成新的工作入口。

而下一批真正有价值的应用，会出现在这个入口与现实世界之间：替 Agent 接上正确的数据，限制它能做的动作，把成功经验固化为流程，并为每一份结果建立可靠的验收方法。

参考资料

1. OpenAI：ChatGPT Work for every team
2. OpenAI Help Center：ChatGPT Work and Codex
3. OpenAI Help Center：Creating and editing documents, spreadsheets, and presentations with ChatGPT Work
4. OpenAI Help Center：Apps in ChatGPT
5. OpenAI Help Center：Scheduled Tasks in ChatGPT
6. Latent Space：Codex from 0 to 10M Users: Building ChatGPT Work — Akshay Nathan, OpenAI
7. Anthropic：Enabling Claude Code to work more autonomously
8. Anthropic：Claude Code overview

资料核验日期：2026 年 8 月 10 日。产品能力、套餐、界面和权限策略可能继续变化，实际使用时请以对应产品的最新官方文档和工作区设置为准。