ChatGPT Deep Research 进入 Work：研究与 Codex 共用额度

ChatGPT Deep Research 已于 2026 年 9 月 9 日进入 ChatGPT Work 和 Codex。真正值得关注的，并不是界面里又多了一个研究按钮，而是预算归属发生了变化：在 Work 中提交研究任务，现在会和团队用于构建、分析与交付的 agent 任务一起，消耗 Work/Codex 共用的使用额度或 credits。

一句话说清这次变化

如今，ChatGPT 里的 Deep Research 对应两套不同的计量方式。

在普通 Chat 中运行，它消耗 Chat 单独提供、且随套餐而变化的研究任务额度；在 Work 或 Codex 中运行，则消耗 Work 与 Codex 已经共用的额度或 credits。Work 中的研究任务不会占用 Chat 的研究额度，反过来也一样。

预算问题的关键就在这里：同一种研究能力，从不同入口启动，走的可能是不同的计量通道。

OpenAI 在 9 月 9 日的发布说明中写明，这项功能面向拥有 Work 访问权限的 Plus、Pro、Business、Enterprise 和 Edu 用户开放。具体能否使用仍取决于账号和工作区，目前覆盖网页版、桌面端、iOS 与 Android。

Work 里的 Deep Research 到底能做什么

Deep Research 适合处理需要查阅多个来源、进行对比并形成有据可查结论的问题。只要交代清楚目标、受众、限制条件、文件和允许使用的来源，它就能追问必要信息、收集证据，并输出带引用或来源链接的结构化结果。任务运行期间，也可以随时调整方向或中断。

Work 版本的价值，在于研究结果可以直接进入交付流程。如果现有工具支持，可以要求它生成可编辑的文档、演示文稿、电子表格或 Site。在 Codex 中，同一类研究还能和技术工作放在同一个上下文里，适合在改代码前准备迁移简报、依赖审查或实施决策材料。

如果还不熟悉 Work，可以先看这篇 ChatGPT Work 评测，了解 Chat、Work 与 Codex 的区别。简单来说：Chat 给出回答，Work 负责周期更长的交付物，Codex 则面向软件与技术系统开展工作。

不过，来源边界并不会因此消失。Deep Research 能使用公开网络、用户提供的文件、当前可访问的工作区文件、可用时的网页搜索，以及已为当前账号启用并授权的受支持 App。启动研究任务，不会自动获得其他文件夹、他人 Drive，或被工作区禁用 App 的访问权。

因此，连接了某个 App 并不等于它一定可用。并非所有 App 或插件都支持 Deep Research；即使支持，任务能读写什么，仍由服务商权限和工作区管控决定。Deep Research 指南对这些限制写得很明确。

ChatGPT Deep Research 为什么会占用共享预算

在 Work 和 Codex 中，研究与执行现在会争用同一份 agent 能力预算。

Plus 和 Pro 账号使用受支持的 agent 功能时，会先消耗套餐内含额度；账号支持购买 credits 时，再从已购 credits 中扣除。ChatGPT Business 标准席位同样先使用套餐内含额度，符合条件的任务之后可以继续消耗工作区购买的 credits。采用灵活定价的 Enterprise 和 Edu 工作区按 credits 扩展用量；未采用灵活定价的工作区仍受套餐限制。

因此，不存在一个适用于所有账号的“每月可运行多少次 Work 研究任务”数字。实际用量取决于模型、来源数量、缓存上下文、输出长度、推理过程、所用工具，以及同一资源池里正在运行的其他任务。只有账号自己的用量页面能给出准确答案。

当前面向 Business、Enterprise 和 Edu 的 ChatGPT 费率表里，有一个很容易被忽略的区别：对于适用 credits 计费的套餐，Chat 中每次 Deep Research 任务约为 50 credits。这个固定的 Chat 项目，并不是 Work 或 Codex 中 Deep Research 的价格；后两者按实际 token 用量计费。

以 GPT-5.6 Sol 为例，当前 Work 和 Codex 的费率是：每 1 million 输入 token 消耗 100 credits，每 1 million 缓存输入 token 消耗 10 credits，每 1 million 输出 token 消耗 500 credits。计算公式为：

消耗的 credits = 输入部分 + 缓存输入部分 + 输出部分。

来看一个明确属于假设的团队预算示例，前提是工作区采用上述费率表。团队为一个月预留 1,000 credits，并计划完成 20 份研究简报。假设每份简报在 GPT-5.6 Sol 上使用 100,000 个输入 token、200,000 个缓存输入 token，以及 20,000 个输出 token。

其中，输入消耗 10 credits，缓存输入消耗 2 credits，输出消耗 10 credits，合计每份简报 22 credits。20 份简报共消耗 440 credits，规划预留额中还剩 560 credits，供其他所有 Work 和 Codex 任务使用。

这些 token 数只是示例，不是预测。篇幅较短的研究备忘录可能用得更少；来源广泛、同时要求产出较长可编辑演示文稿的简报，也可能用得更多。更实用的做法，是把研究和后续执行放在一起编预算，再根据最初几次任务的真实用量替换假设数据。

购买的使用 credits 与 API credits 彼此独立。为 Work 或 Codex 购买更多 credits，不会给 API 项目充值；API 余额也不会扩大这个资源池。个人 credits 指南也明确指出，购买选项会因账号、地区和套餐而异。

哪些人明天就能用起来

小型代理公司的研究负责人

负责人可以让 Work 基于获准使用的研究网站、上传的访谈笔记和已连接的文档库，对客户所在赛道进行比较。最终交付的是一份带引用、可继续编辑的市场简报，而不是又一段聊天记录。

好处是，策略与创意团队接手时信息更清楚；预算上的代价则是，每完成一份深度简报，团队用于 Work 中演示文稿、电子表格和制作任务的共享能力就会相应减少。

SaaS 公司的产品经理

产品经理可以把客户笔记、政策页面、竞品文档和内部需求文件整合成决策备忘录。如果任务过度依赖某一来源，可以在执行中及时纠偏；之后再要求生成一份供产品与法务团队共同编辑的文档。

这样做的价值，是留下了一条可检查的完整证据链。但决策责任仍在产品经理本人，任何会影响路线图或客户承诺的关键论断，在采用前都必须再次核查来源。

负责迁移计划的工程主管

工程主管可以先在 Codex 中启动 Deep Research，对比最新的供应商文档、兼容性说明和代码仓库限制，再让 Codex 修改代码。研究与实施因此能够留在同一个工作上下文中。

好处是减少上下文交接；成本影响也很直接：前期调查和后续实施消耗同一份 Work/Codex 预算。研究范围一旦膨胀，就可能挤占真正完成迁移所需的能力。

为团队制定规则的工作区管理员

管理员可以给成员一条清晰规则：如果交付结果只是一份研究型回答，而且适合使用 Chat 的独立任务额度，就选 Chat；如果结果需要成为可编辑的团队资产，或继续驱动执行，就选 Work 或 Codex。

这样一来，预算逻辑更容易向所有人解释。Enterprise 和 Edu 管理员还需要开启 Deep Research 权限与网页搜索；缺少这些设置时，即使成员本来符合使用条件，也可能根本看不到该功能。

一套更稳妥的操作流程

1. 1

   1. 主动选择计量通道

   需要研究型回答时从 Chat 开始；需要可编辑的业务交付物时从 Work 开始；研究必须与技术执行放在一起时，则从 Codex 开始。不要把这三个入口视为成本完全相同的选项。

2. 2

   2. 划清证据范围

   明确报告必须覆盖的网站、文件、日期范围、受众和要支持的决策，同时列出不得使用的来源。证据集越聚焦，越容易核验，通常也会占用更少上下文。

3. 3

   3. 说清交付格式

   只要求一种受支持的格式，并说明结果应该放在哪里。任务只有具备相应工具和权限时才能生成可编辑交付物，因此还应预先指定兜底方案，例如在对话中提供结构化报告。

4. 4

   4. 偏航前及时纠正

   关注任务进度。如果它开始追随薄弱来源或不断扩大问题范围，就立即中断并收窄目标。研究更多，并不天然等于研究更好。

5. 5

   5. 记录用量变化

   任务前后分别查看 Work/Codex 用量页面，记录模型、范围、输出类型、消耗的 credits 和审核时间。积累几份同类简报后，这些真实记录会比通用的任务估算更有价值。

6. 6

   6. 检查交付物

   打开交付的文件或链接，抽查支撑关键决策论断的引用，确认来源确实表达了报告声称的内容。如果证据缺失，或没有交付指定输出，就要求修订。

必须说清的限制

Work 中的 Deep Research 并不等于无限研究。它会消耗现有的 Work/Codex 额度或 credits，而功能是否可用，仍取决于账号、工作区和使用入口。如果一项研究挤占了后续实施所需的资源，它就不再是一笔划算的投入。

可编辑的输出，不代表经过验证的输出。文件结构可能很完整，却仍会引用质量不高的页面、漏掉相互矛盾的信息，或没有真正回答研究要求。OpenAI 要求用户检查引用是否确实支撑相关论断，并确认要求生成的文件或链接不仅已经创建，而且能够正常打开。

只在普通 Chat 中使用 Deep Research 的团队，不受这套新 Work/Codex 共享计量方式影响，其独立的 Chat 额度保持不变。没有 Work 访问权限的人，以及所在工作区已由管理员关闭 Deep Research 或网页搜索的成员，也无法从这次发布中获得新的工作流。

现在应该怎么做

如果团队已经在重复制作需要大量来源的交付物，并且能查看 Work/Codex 用量，就在本周行动：选定一个负责人、一种输出，以及一个审批关口。

如果无法检查来源、不清楚费用会由哪个账号或工作区承担，或者必须使用一个并不支持 Deep Research 的 App，那就先等一等。先把这些边界理顺，再创建周期性任务。

如果只需要一份研究型回答，无须把结果变成 Work 或 Codex 的交付物，那就继续使用 Chat。独立的 Chat 额度本来就是为这种模式准备的。

周一只做这一件事

拿一份团队原本就会制作的简报，先运行一次，不要立即设成定时任务。开始前记录 Work/Codex 用量，然后使用下面这份范围明确的请求：

@Deep Research。请为产品负责人准备一份可编辑的决策备忘录，判断是否续约 Vendor A。仅使用随附合同、最近 2 份季度复盘、Vendor A 当前的定价与安全页面，以及 3 个已点名的替代方案。请将已验证事实与分析分开，为每项价格及安全相关论断提供引用，列出尚未解决的信息缺口，并给出续约、重新谈判或替换的建议。不要联系任何供应商，也不要改动本报告以外的任何文件。

任务完成后，打开交付的备忘录，并逐一点击支撑最终建议的引用。确认来源确实支持对应语句，检查指定文件是否存在并能正常打开，再把用量变化和审核时间记在一起。如果引用或交付物未通过检查，任务就还没有完成。

如果想继续获得 AI 产品计费变化的易懂实操指南，可以订阅 newsletter。