
Codex 从 0 到 1000 万:ChatGPT Work 如何把 coding agent 带进知识工作
Akshay Nathan 解释 Codex 如何借助共享 harness、异步执行和长期上下文,从开发者工具扩展成面向知识工作的 agent。
单集信息
- 播客:Latent Space: The AI Engineer Podcast
- 主持人:Swyx、Vibhu
- 嘉宾:Akshay Nathan,OpenAI core product engineering lead
- 集标题:Codex from 0 to 10M Users: Building ChatGPT Work
- 发布日期:2026 年 7 月 28 日
- 原集链接:1
这集真正值得关注的,不是「Codex 又有了什么新按钮」,而是面向程序员的 agent harness 如何扩成知识工作入口。Nathan 的叙述里,从 0 到 1000 万用户的关键,是 Codex 接入了 ChatGPT 的分发、上下文和用户习惯。
先发生的是非开发者采用
Nathan 说,Codex 发布后,OpenAI 内部出现了一个让团队意外的采用拐点:战略财务、市场等非开发岗位的人也开始使用 Codex。更有意思的是,他们不只是把它当成一个方便工具,而是带着一种「我本来不应该会这个,但我现在会了」的自豪感,觉得自己获得了某种 superpower。
这改变了产品问题的定义。假设只有开发者会使用 agent,界面可以围绕仓库、终端、diff 和代码审查设计;但如果财务、营销、研究和运营也要使用,同一个执行能力就必须能处理 spreadsheet、网页、文件、数据源和长时间任务。于是,ChatGPT Work 的方向不是再造一个独立 IDE,而是把 Codex 的能力带到 ChatGPT 已经积累的数亿用户面前。1
同一个 harness,两种工作表面
访谈中一个很容易被忽略的技术结论是:Codex 和 ChatGPT Work 底层使用同一个 harness。OpenAI 针对 knowledge work 做了改进,涉及 plugins、computer use 和 artifacts 等能力;差别主要出现在用户体验、sandbox 以及结果如何呈现,而不是重新发明一套完全不同的 agent 内核。
这带来一个具体的产品取舍。让 agent 创建一个 retirement calculator spreadsheet,在两种模式下都可以调用相近的能力;进入 Codex 模式,用户更可能看到 repo、文件编辑和 diff,能检查它具体改了什么;在 Work 的表面,重点则是直接得到可用的 spreadsheet 或其它 artifact。能力共享,监督方式不同。
这也解释了为什么「把 coding agent 带给所有人」不是改一个入口名称。程序员习惯看中间产物,非开发者更在乎结果能否继续使用。
从写代码到交付 artifact
Nathan 反复强调,agent 的价值不应停留在告诉用户一个答案。它更像一个会执行任务的同事:连接合适的数据和工具,花时间完成一项工作,然后交回文件、网页、分析结果或下一步可操作的材料。
Sites 和 artifacts 体现了这个转变:网页、交互式计算器或研究页面是可以打开、修改和继续使用的结果。对用户来说,agent 不再只是在「说它做了什么」,而是在「展示它做出了什么」。
但这里有一个边界:知识工作并不总是即时问答。访谈后段谈到,很多 Work 场景不要求 agent 立刻返回结果,更像是把任务交给它去执行。即时回答要访问多个外部来源,延迟和可靠性都会变难;可等待的任务则能让 agent 花更长时间检索、整理和复核。1
这意味着 agent 产品需要同时处理即时协作和异步委托。
连接不是全部,长期上下文也不是魔法
当讨论转向个人生产力时,主持人提到 OpenClaw 这类 personal OS 想象:把健康、财务、文件和日常信息集中到一个 agent 可以使用的空间。Nathan 对这个方向并不否定,但指出,仅靠 MCP、CLI 或 API 在需要时临时拉数据,未必足够。
如果用户要即时答案,系统必须反复访问多个来源;但很多任务可以延后完成,重点就变成怎样积累可复用的上下文。Nathan 提到自己有 data engineering 背景,数据仓库、缓存或 semantic layer 仍有价值。换句话说,agent 能连接多少工具,不等于它就拥有了一个可靠的长期工作记忆。
访谈还谈到 Chronicle,一种实验性的记忆输入。它不可能捕捉用户的每个意图,但可能在合适时机找回被忽略的相关信息。价值不是替用户记住一切,而是把过去行为转成当前任务可调用的线索。
生产力不是 agent 调用次数
在结尾,Nathan 给了这集最值得带走的一句判断:
「Motion is much easier now than ever before because of the tooling that we have. But progress requires you to be very prescriptive and deliberate about what you're actually trying to achieve.」
工具让行动变得容易,但行动次数不等于进展。OpenAI 自己也在面对一个难题:用户的工作类型差异太大,很难用一个统一指标测量 ChatGPT Work 到底提升了多少生产力。对团队负责人来说,真正可执行的建议不是追踪 agent 运行次数,而是先明确什么叫「完成得更好」:周期缩短了多少,错误少了多少,还是原来无法完成的工作现在可以交付。
这也让 Codex 的 1000 万用户不只是一个增长数字。它证明的是,一套 agent 执行系统可以跨出开发者边界;但它没有证明所有人都因此获得了同样的生产力。下一阶段的难题,是把共享 harness、长期上下文和可验证 artifact 变成不同岗位都能理解、监督和复用的工作流程。
这集值得谁听
- 做 AI 产品、agent UX 或 developer tools 的人值得完整听:重点是同一个 harness 如何通过不同工作表面服务开发者与非开发者。
- 做企业自动化和知识工作系统的人值得听:异步任务、外部连接、缓存层与长期记忆之间的关系,比工具数量更值得研究。
- 关注个人 agent 的人应听 Memory 和 Chronicle 部分:它既展示主动发现上下文的潜力,也保留了对遗漏、数据边界和信任成本的疑问。
- 只想看 Codex benchmark 的人可以跳过:这集几乎不做性能排名,核心增量在产品分发、执行层复用和生产力定义。
References
Related content
- Sign in to comment.
More from this channel›
- AI 先接管暖气维修的调度层:Netic 为什么不急着造机器人
- 从 ExploitGym 到 Hugging Face:Practical AI 复盘一次 AI agent 入侵链
- 安全评估不是一道总分题:Luminos 为什么要拆成 sub-risk
- Transformer 之后,下一步是让模型在部署中继续学习
- Poolside 的 model factory:模型公司如何把训练变成生产系统
- 企业 AI 为什么还慢:真正卡住的是数据、权限和 agent identity
- 读模型的「思维」:mechanistic interpretability 为什么有用又不完整
- Self-accelerating AI 的具体版本:让系统参与 AI 研发本身
