OpenAI 的 Codex 研究:Agent 改变的不是聊天,而是派活
1/7/2026 · 15:00

OpenAI 的 Codex 研究:Agent 改变的不是聊天,而是派活

OpenAI 用 Codex 使用数据展示了 AI Agent 从代码工具扩散到组织工作的路径:用户开始交派长任务、并行运行多个 Agent,并把流程沉淀为可复用的技能。本文拆解关键数据、方法边界,以及这对企业采用 Agent 的启发。

如果还把 Agent 当成「更会聊天的模型」,OpenAI 这篇 Codex 研究最有价值的部分就会被漏掉。它讨论的不是聊天框回答得更好,而是知识工作的基本单位变了:从一次问答,变成一段可以被交派、等待、验收、再分派的工作。OpenAI 在官网文章中把这种变化概括为:Agent 可以独立运行数分钟到数小时,调用工具、接触环境,并反复迭代出结果。1

这篇研究到底测了什么

配套论文 The Shift to Agentic AI: Evidence from Codex 分析的是 Codex 使用数据,覆盖三类人群:个人账户用户、企业 / 组织账户用户,以及 OpenAI 内部员工。研究团队用自动化、隐私保护的数据管线做聚合分析,并说明研究者不会直接阅读底层消息内容。2
Codex 最初是面向软件开发的工具,论文也承认软件仍是它最主要的使用场景。但 OpenAI 想证明的不是「AI 会写更多代码」,而是 Agent 工具正在把使用方式从咨询推向执行:调试、重构、验证改动、配置应用、分析数据、生成文档,都更接近「做事」而不是「给建议」。2

先看几个关键数字

观察点OpenAI 给出的数据该怎么理解
内部替代速度截至 2026 年 6 月 11 日,Codex 占 OpenAI 员工在 Codex 与 ChatGPT 合计输出 token 的 99.8%;组织账户为 63.3%,个人账户为 16.5%。2在高熟练、高授权的环境里,Agent 可能很快成为主要工作界面;普通个人用户还远没有到这个阶段。
组织账户渗透最近 28 天内,17.3% 的组织账户用户至少用过一次 Codex;个人活跃用户中这一比例低于 1%。2是否能接触文件、代码库、内部流程,会直接影响 Agent 是否真的可用。
长任务增长到 2026 年 5 月,70.2% 的抽样个人 Codex 用户至少提交过一个估计需要人类 1 小时以上完成的请求;25.6% 至少提交过一个 8 小时以上任务。2用户开始敢把更完整的工作包交出去,而不是只问一个短问题。
并行工作在 2026 年 6 月 11 日前一周,28.6% 的 OpenAI Codex 用户曾同时管理 5 个或更多 Agent;组织和个人用户多数还没有并行使用。2高强度用户的工作更像「调度一组 Agent」,而不是坐等一个助手回答。
可复用流程活跃 Codex 用户调用技能的比例从 2026 年 3 月 1 日的 5.4% 升至 6 月 11 日的 26.6%;OpenAI 内部活跃用户中,这一比例为 96.2%。2Agent 的价值不只来自模型能力,也来自把反复出现的流程、偏好和工具接入固定下来。
这组数字里最有意思的不是 99.8%。OpenAI 内部员工没有用量限制、学习成本低、反馈渠道近,本来就是最容易「全员 Agent 化」的样本。更值得看的是组织账户和个人账户的差距:同样是 Codex,有没有上下文、权限、流程和验收机制,结果完全不同。

非开发者为什么增长快

OpenAI 官网文章强调,非开发者的增长速度尤其快:自 2025 年 8 月以来,个人用户中的非开发者增长 137 倍,组织用户中的非开发者增长 189 倍,OpenAI 内部非开发者增长 12 倍。1
这不等于法务、招聘、财务都在写生产代码。论文的说法更窄:非技术岗位开始把 Codex 用在自动化、数据转换、工具搭建、调试和结构化分析上。比如业务部门并不一定要成为工程师,但可以让 Agent 处理一部分过去需要排队等技术同事支持的临近任务。1
这里的变化有点反直觉。很多人以为 Agent 会先替代执行者,论文看到的早期形态更像是扩大了个人能触碰的任务边界。会不会写代码仍然重要,但更稀缺的能力变成了:能不能把任务切清楚,能不能给足上下文,能不能判断结果是否可用。

Codex 为什么会从代码扩散到工作流

软件开发天然适合 Agent:材料是数字化的,任务可以拆成模块,输出能被测试、编译或人工审查。论文也把软件视为这轮变化的前沿场景。Codex 的使用并不只落在「实现新代码」,还包括理解既有系统、验证代码改动、管理仓库、配置环境和生成文档。2
一旦这些动作跑通,外溢就很自然了。许多知识工作也有类似结构:输入散落在文件、表格、邮件和内部系统里;输出是报告、清单、分析、脚本或流程改动;中间需要反复检查。Agent 比聊天机器人多出来的部分,正是「进入工作环境并修改工件」。
这也是为什么论文反复提到并行、运行时长和技能。传统聊天指标看的是有多少人打开、发了多少消息;Agent 指标要看任务有多长、能不能复用、是否能并行、产出了多少可审查的工件。OpenAI 在结论中直接说,未来分析 AI 使用情况时,活跃用户数、聊天数和消息量可能会变得不够用。2

这篇论文的边界也要看清楚

第一,OpenAI 内部不是普通企业样本。论文自己写得很明白:OpenAI 员工熟悉前沿模型,边际使用成本低,组织支持强,内部还有大量关于能力和用法的知识分享。因此,OpenAI 内部数据更像「阻力很低时可能发生什么」,不能直接外推到所有公司。2
第二,「任务需要人类多少时间」是模型估计,不是实际工时记录。论文对个人账户任务复杂度的估计来自 0.1% 随机样本,而且只包含允许数据用于模型训练的用户;官网脚注也提醒,这些阈值应被视为方向性指标,不应当精确理解。2
第三,输出 token 不是生产率。一个部门输出 token 增长 50 倍,可能说明完成了更多工作,也可能说明 Agent 需要反复尝试、生成了更多中间物。论文谈的是使用模式和组织变化的早期证据,不是已经证明企业利润或人均产出同步增长。

对团队采用 Agent 的启发

如果只把 Codex 当成「更强的代码补全」,这篇研究的含义会被看窄。更务实的读法是:Agent 的采用不是开账号问题,而是工作分配问题。
团队可以先挑三类任务试:重复出现、上下文可整理、结果可验收。比如数据清洗脚本、内部报告初稿、代码库巡检、配置迁移、测试补齐、招聘材料结构化。不要一上来就把模糊战略问题交给 Agent;那类任务很难验收,失败时也很难复盘。
更关键的是验收角色。Agent 把执行成本降下来以后,人类工作不会自动变轻,可能会先变成更多审查、协调和集成。论文最后给出的判断很直接:高强度用户不是聊天更多,而是在交派任务、并行运行、复用流程,并把自己的精力转向监督和整合。2
所以,判断一个团队有没有真的用上 Agent,不该只看「有多少人每周打开」。更有用的问题是:有没有任务被完整交派出去?有没有可复用的流程说明?有没有人同时管理多个工作流?最后,谁负责验收?如果这些问题答不上来,Agent 还只是一个更贵、更忙的聊天框。

Más de este canal

Contenido relacionado

  • Inicia sesión para comentar.