OpenAI Codex 软件工厂以智能体监督取代编程

OpenAI 在数月内将 Codex 从可选的编程助手，转变为几乎所有内部工作的底层运行层。如今，OpenAI Codex 软件工厂将智能体连接至代码、文档、通信系统、测试基础设施和生产遥测数据。

这一结论来自 Gergely Orosz；他曾访问 OpenAI 总部，并采访了七位工程师及工程领导者。他的内部报道描述了一个由智能体日益参与创建、检查、部署和监控软件的组织。

关键矛盾已不再是 Codex 与人类打字速度的较量，而是智能体吞吐量与人类注意力、审查系统以及组织控制机制之间的平衡——这些机制是信任其产出的必要条件。

OpenAI 的经验也代表了一个异常有利的案例。员工拥有广泛的模型访问权限、深度的内部集成，以及专门负责改进智能体运行框架的团队。大多数公司并不具备这些条件，因此其复制前述成果的确定性低于标题所暗示的程度。

OpenAI Codex 软件工厂成为默认工作流

最明显的变化是，Codex 已从辅助个别开发者，转向协调 OpenAI 范围内的工作。

Orosz 报道称，这一转变始于 2026 年 1 月左右。在四个月内，非工程部门对 Codex 的使用率据称从几乎为零上升至约 90%。

财务、招聘、法务、营销和研究部门的员工与工程师一道采用了该系统。据报道，几乎每位 OpenAI 员工如今都会在典型的一周内使用 Codex 或 ChatGPT Work。

OpenAI 自身的职场分析也支持这一报道的大方向。该公司表示，Codex 目前生成了普通员工平均产出 token 的 85% 以上。

根据 OpenAI 的说法，这一比例对于普通工程师达到 99%。在全公司范围内，Codex 据称占通过 OpenAI 工具生成的每周产出 token 的 99.8%。

这些数字衡量的是模型产出，而非已完成的业务价值。不过，它们仍表明，内部 AI 工作的交互界面已决定性地从对话转向委托执行。

聊天机器人通常会等待每一条新指令。智能体则接收一个目标、使用工具、检查结果，并在更长的一连串决策中持续工作。

这一差异解释了 Codex 为何扩展至软件开发之外。研究某个主题、制作演示文稿、处理电子表格和监控 Slack，都涉及智能体可通过软件操作的数字化资产。

OpenAI 于 2026 年 2 月发布了适用于 Mac 的 Codex 桌面应用，并于 3 月将可用范围扩展至 Windows。采用相同底层智能体运行框架的 ChatGPT Work 则在 7 月推出。

据报道，在界面对非工程人员变得友好之前，采用曲线便已开始。Orosz 表示，当产品仍显示代码并假设用户具备技术熟悉度时，这些员工的使用率已接近 40%。

这一模式挑战了关于职场 AI 采用的普遍看法。相比精致的界面，智能体完成一项实质性任务并返回可用成果的能力更为重要。

运行时间更长的工作似乎加速了这一转变。Orosz 报道称，随着基于目标的工作流得到改进，内部使用率在 4 月至 5 月间从约 60% 升至 90%。

员工可以指定一个结果，并让智能体跨越多个步骤继续执行。该系统还可以将子任务委派给额外的智能体，无需员工监督每一条工作线程。

OpenAI 描述了外部使用中的类似趋势。截至 5 月，70.2% 的抽样个人用户至少提出过一次请求，其代表的预计人工工作量超过一小时。

该公司称，25.6% 的用户曾请求预计超过八小时的工作。由于这些估算来自模型判断，OpenAI 建议将其视作趋势性指标，而非精确数值。

内部定制与更长的任务时长同样重要。各团队创建了特定岗位的技能与插件，为通用智能体提供可重复执行的流程、工具和领域背景。

这种组合帮助 Codex 成为基础设施，而非又一个应用程序。员工不再需要将每一个重复性工作流都转化为一次全新的对话。

依赖性随采用而来。Orosz 报道称，即使是轻微的故障，也可能在自动监控向负责团队发出警报之前引发内部投诉。

因此，OpenAI 同时打造了生产力引擎和共同的单点故障。越多工作流经同一智能体运行框架，该框架变慢或失效时的运营影响就越大。

更快的代码让审查与交付承压

Codex 降低了生产代码的成本，但并未消除验证和交付代码的成本。

Orosz 报道称，自 1 月以来，OpenAI 对集成开发环境的使用正在下降。IDE 在一个开发者界面中整合了代码编辑、导航、测试和调试功能。

工程师正日益通过 Codex 委托实施工作。他们的工作重心转向定义结果、提供上下文、判断结果，以及决定哪些变更值得部署。

这改变了稀缺资源。当一名工程师开会时，智能体可以生成多个实现方案，人类打字时间便不再限制产出。

注意力成为瓶颈。工程师仍须识别有价值的问题、辨别薄弱的解决方案、消除歧义，并为生产环境结果承担责任。

传统拉取请求围绕人类编写变更的较慢流速而设计。它们为同行提供了一组有边界的代码包，以便在合并至共享代码库前进行检查。

当每位工程师都能启动许多智能体时，这种模式便会承受压力。OpenAI 应用基础设施工程副总裁 Venkat Venkataramani 表示，拉取请求量正以加速的速度增长。

新增产出并不只影响代码审查。每项变更都会消耗构建能力、测试执行、部署基础设施、存储、可观测性以及审查者的注意力。

OpenAI 的团队正围绕这一更高的工作量重新考虑持续集成与持续部署。这些系统会在开发者提交变更后自动构建、测试并发布。

旧有流程假定代码创建相对昂贵。智能体开发颠倒了这种关系，因为提出另一项变更变得廉价，而证明其安全性仍然代价高昂。

OpenAI 正以专门的审查智能体应对这一问题。工作流不再要求一个通用模型检查变更，而是可分别分配安全、基础设施、性能或合规视角。

每个审查者都会获得相关代码库知识和组织规则。高风险变更可触发更广泛的智能体审查以及强制性人工批准。

低风险领域可以采用更轻量的控制措施。一些代码库可允许智能体批准经过严格分类的变更，无需等待人工处理。

这意味着从普遍适用的审查步骤转向基于风险的路由。它同样依赖准确分类、及时更新的文档和可靠的访问控制。

这一做法给仍通过已接受的建议数量或开发者调查来衡量 AI 采用情况的组织带来压力。这些指标忽略了新增代码和更快实验所造成的下游成本。

团队可以合并更多拉取请求，却未改善客户结果。它也可能产生更多维护义务、运营噪声和架构不一致。

原生移动端交付清楚地暴露了这一差距。OpenAI 可以快速生成应用变更，但有意义的 iOS 和 Android 更新仍须经过外部审核流程。

应用商店审批可能耗时数小时或数天。因此，更多由智能体生成的变更会积压在智能体无法控制的分发系统之后。

同样的不匹配也存在于企业内部。安全评估、变更管理委员会、合规审查和客户验证，并不会仅仅因为实施速度更快而加速。

竞争对手面临相同的结构性压力。Anthropic 对约 40 万个 Claude Code 会话的研究发现，人类仍作出大部分规划决策，而智能体则处理更多执行层面的选择。

其使用研究还发现，领域专业知识仍与更高的成功率相关。编程智能体改变了工作分配，但并未让判断变得无关紧要。

因此，新出现的竞争并非 OpenAI Codex 与 Claude Code 在孤立编程基准上的较量，而是哪个组织能够围绕充足的机器执行能力重新设计其完整交付系统。

OpenAI 当前拥有重大优势，因为它同时构建模型、产品和内部环境。当自身工作流暴露弱点时，它可以调整智能体。

企业买家必须将智能体整合至既有代码库、控制措施和审批链中。他们的限制因素往往将是组织准备程度，而非模型访问权限。

工厂通过上下文与反馈循环运作

OpenAI 的模式之所以类似工厂，是因为智能体参与了整个生产周期，而不是因为代码生成已完全自主化。

流程始于人类定义期望结果。该人员决定哪些问题重要、适用哪些约束，以及可接受的结果应实现什么。

随后，Codex 会从代码库、文档、Slack、Notion、日志、监控系统和内部数据源中收集上下文。这一检索阶段决定了智能体在做出任何改动前能够理解什么。

据报道，OpenAI 已将文档移至更接近源代码的位置。这使得智能体和工程师都更容易在代码库内找到运营知识。

智能体实施变更、运行测试、修复失败项，并创建拉取请求。它可以持续监控该请求，并在自动检查发现问题时作出响应。

对性能敏感的变更可能进入额外评估。性能测试框架会让选定构建版本经历受控对比，以便在部署前发现性能回退。

多个审查智能体随后会通过不同的领域视角检查工作。它们的价值来自聚焦的指令以及对 OpenAI 特定知识的访问，而不只是采用专家标签。

工作流会按风险对变更分类。该分类决定变更是否需要更多智能体审查、人工决策，或采用更简单的审批路径。

在 Orosz 记录的流程中，人类仍会批准生产部署。获批后，另一名智能体会在发布过程中跟踪该变更，并观察其运营信号。

该部署智能体可以定位功能开关、理解变更内容、选择成功指标并创建监控仪表板。随后，它会观察发布过程，以寻找问题迹象。

生产行为会反馈至新的开发工作中。OpenAI 据报道的 Perf Factory 会对警报进行分组、识别延迟回退、调查可能原因，并提出修复建议。

另一个内部系统 Sevbot 会在服务事故期间提供协助。它收集上下文、提出缓解建议，并在响应频道内回答问题。

目前，Sevbot 不会自行执行其提出的缓解措施。工程师必须授权某项具体操作，从而在人为风险较高的边界保留人工决策。

这一完整闭环比任何一次单独的模型回答都更重要。智能体接收结构化上下文，通过受限工具开展操作，接受自动化测试，并将证据回传至后续阶段。

OpenAI 将这一外围系统称为 harness（支撑框架）。harness 将模型与工具、数据、权限、执行环境、记忆和反馈机制连接起来。

该公司早期的 harness experiment 说明了这类工程为何重要。一个团队表示，Codex 生成了某个内部产品的全部代码，该产品约含 100 万行代码。

OpenAI 估计，该项目耗时约为人工实施所需时间的十分之一。这仍是公司针对一个从零开始的内部项目作出的估计，而非独立的行业基准。

更具启发性的结论是，智能体需要一个清晰可理解的环境。代码库知识需要明确组织，测试需要提供有用反馈，架构约束则需要能够由机器验证和执行。

工程师还必须清除长期累积的无序状态。当代码库将过时模式呈现为有效示例时，智能体可能会迅速复制这些模式。

因此，高吞吐量反而提升了 OpenAI 所称“垃圾回收”的重要性。团队必须在过时文档、重复抽象、废弃代码和不一致惯例进一步累积之前将其清除。

OpenAI 随后开发了 Symphony，这是一项将编程智能体与问题追踪器连接起来的编排规范。每项符合条件的任务都可以拥有专属工作区，以及一个持续工作直至完成的智能体。

该公司称，其 Symphony workflow 在前三周内让部分团队已合并的拉取请求数量增长了 500%。

同样，拉取请求数量衡量的是产出，而非客户价值。不过，这项实验揭示了另一个重要瓶颈：人们难以同时监督大量交互式智能体会话。

OpenAI 表示，大多数工程师在频繁切换上下文变得痛苦之前，通常只能舒适地管理三到五个会话。Symphony 将监督重点从单个会话转移到任务状态和交付成果。

问题追踪器由此成为控制平面。智能体可以领取未受阻的工作、在失败后重新启动、创建后续任务，并在多个代码库之间维持执行。

人类检查计划、优先级和最终结果，而不是反复提示每一个会话。这种模式让工程师站在实施工作之上的一层。

这也改变了组织为智能体开发做好准备所需具备的条件。高质量工单、最新文档、可观测系统和确定性测试都会成为生产基础设施。

探索类似工作流的团队需要可靠的组织上下文来源。可搜索的 engineering knowledge base 可以提供帮助，尽管仅靠检索并不能建立可信赖的自动化。

因此，应谨慎使用“工厂”这一比喻。OpenAI 并未将人从软件开发中移除，其最敏感的决策仍保留人工控制。

它实现自动化的，是从意图到证据之间更长的一段路径。人类工作则转向设计这一路径、评估其产出并维护其约束。

生产力叙事仍存在验证缺口

OpenAI 的内部证据令人瞩目，但尚不足以证明大多数公司能够安全地复现同样的收益。

OpenAI 拥有不同寻常的优势。其员工可以使用大量算力、宽泛的 token 预算、先进的内部模型，并能直接接触构建 Codex 的团队。

该内部系统还连接了公司代码库、通信工具、运营数据和文档。公开客户获得的则是一个边界更明确、组织专属集成更少的产品。

这一差距至关重要，因为智能体依赖上下文。接入不完整文档或碎片化权限的智能体，与深度嵌入模型实验室各处的智能体，产生的结果会截然不同。

OpenAI 的数据也侧重使用量和产出。token 占比、拉取请求数量和代码行数反映了活动程度，却并不直接衡量可靠性、客户满意度或总体维护成本。

即使是时间估算也需要谨慎看待。OpenAI 对长周期任务的说法，是通过模型估计等效人工投入，而非记录某个人完成同一任务所花的时间。

独立证据仍然喜忧参半。一项随机 METR 研究发现，经验丰富的开源开发者在熟悉的代码库中使用 2025 年初的 AI 工具时，完成任务反而多花了 19% 的时间。

这项 developer trial 包含 16 名开发者完成的 246 项任务。参与者平均已在各自代码库中工作约五年。

该实验考察的是较早期的工具，以及持续时间约为 20 分钟至四小时的任务。它并未测试 OpenAI 内部所描述的、运行时间更长的 2026 年工作流。

这种对比仍提供了有益警示。模型能力、任务形态、代码库设计、用户专业水平和验证成本，都可能逆转表面上的生产力结果。

OpenAI 的环境已经为智能体重新设计。许多公司起初会将智能体置于为人类优化的系统中，随后困惑于为何产出仍不可靠。

安全性带来了另一个难以复制的问题。一个有用的智能体需要访问源代码、凭据、通信系统、部署工具和生产信息。

每一项新增连接都会扩大错误或被操纵指令可能造成的影响。提示词注入能够把恶意指令隐藏在智能体读取的文档、网站、消息或工具输出中。

OpenAI 表示，它通过沙箱、受管网络策略、集中式认证、命令规则和详细遥测来限制这些风险。其 Codex safeguards 会阻止开放式网络访问，并要求对不熟悉的目标地址进行批准。

公司还会记录提示词、工具活动、批准记录和网络策略决策。安全团队可将这些记录与终端告警结合，以还原智能体为何执行了某项异常操作。

这些控制措施是产品的一部分，而非可有可无的行政装饰。一个权限广泛且速度很快的智能体，可能将一次小小的误解变成一连串迅速发生、影响重大的行动。

审查自动化本身也带来不确定性。专用智能体或许能发现忙碌的人类遗漏的缺陷，特别是在它能够一致地检查每一项变更时。

但使用相关模型的多个智能体可能共享相同盲点。自动化审查者之间的一致意见，并不能保证变更一定正确。

团队还面临自动化偏见的风险。由于流程看似全面，审查者可能会较少仔细检查经机器批准的变更。

这种“工厂”模式同样可能削弱共享理解。工程师历来通过实现功能、调试故障和审查同事的决策来学习系统。

当智能体承担更多此类工作时，组织需要找到另一种方式来保留架构知识。否则，人类可能仍保有批准权，却失去了行使这一权力所需的上下文。

OpenAI 给出的答案，是更加重视品味、判断力和能动性。这些品质有助于工程师明确更好的结果，并拒绝看似合理但并不理想的实现方案。

但它们很难评估和教授。初级工程师过去通常通过较小的实施任务培养判断力，而智能体正日益吸收这些任务。

因此，长期的人才配置影响仍未明朗。智能体工作流可以扩大一名资深工程师的产出范围，同时收窄进入这一职业的传统入口。

OpenAI 的案例也不应被简化为岗位替代。该文档化系统仍依赖人来进行优先级排序、提供领域专业知识、接受风险和承担事故处置权限。

眼前的变化更具体：组织能够生成提议工作的速度，已经快过其治理、基础设施和学习系统所能吸收的速度。

这使反馈循环的质量变得决定性。薄弱的测试和陈旧文档会让错误快速传播，而强有力的控制则能将失败尝试转化为有用信息。

这一核心主张在方向上可信，但在适用范围上仍不完整。OpenAI 展示了智能体能够如何深刻重塑一家为其提供支持而设计的公司。

但它尚未证明，同一套架构在系统碎片化、AI 专业能力有限的普通企业中，仍然具备经济性、安全性和可维护性。

三项信号将表明这一模式能否推广

下一项考验是，OpenAI 能否在不转移不可接受风险的前提下，将其内部运营模式转变为客户可重复采用的系统。

第一项信号是关于结果的更广泛证据。买方应关注周期时间、事故数量、回滚率、客户影响和维护投入方面经过测量的变化。

仅有更多代码并不够。只有独立团队在不增加缺陷或运营负担的情况下改善交付，OpenAI Codex 软件工厂才能在总部之外真正具备说服力。

最有力的证据将比较相似团队采用前后的表现。其中应包括审查、修正和维护由智能体生成的变更所花费的时间。

第二项信号是审查和部署控制如何演进。OpenAI 当前的架构仍在人为选定的生产和事故响应边界设置人工参与。

未来版本将揭示哪些决策会变为自主执行，哪些会被刻意保留给人类。这些边界的设定将定义该系统在实践中的风险模型。

关注智能体生成的仪表盘、专门审查和风险分类，是否能捕捉到既有控制遗漏的故障。同时也要关注常见模型盲点是否会导致关联性的审查失败。

第三项信号是 Anthropic、Google、Microsoft 和企业软件供应商的竞争回应。它们都希望掌控人们委派工作的接口，因此都有这样做的动力。

Anthropic 已经将长时间运行的 Claude 智能体连接至开发环境和企业工作流。Google 和 Microsoft 则可以将智能体与大型生产力套件、云平台和身份系统相结合。

战略奖赏不止于代码生成。获胜的系统能够成为控制层，读取组织上下文、调度任务，并返回已完成的产物。

这一位置会形成可观的转换成本。技能、权限、审查政策、机构知识和工作流历史，都会围绕所选择的 harness 不断累积。

它同样会集中运营依赖。一旦发生模型退化、服务中断、安全缺陷或政策变化，多个部门的工作都可能同时被打断。

因此，企业采用将与原始能力一样依赖可移植性和可审计性。买方需要了解智能体访问了什么、做出了什么决策、变更了什么，以及将什么交给了另一个智能体。

面向技能、工具连接、追踪记录和评估的开放标准，将降低对单一供应商的依赖。封闭的内部集成或许能带来更快进展，但会使迁移更加困难。

工程师的角色仍将是隐藏在这三项信号背后的第四个、更长期的问题。OpenAI 的员工正减少直接编写代码的时间，转而更多地指挥系统。

这并不意味着工程能力不再重要。它改变的是专业能力介入流程的位置，使其更偏向于规格定义、架构、评估、安全和运营判断。

最有能力的组织不会只是把一个 agent 加入旧有工作流。它们会决定哪些知识必须变得可供机器读取，以及哪些决策必须由人承担责任。

它们还会衡量被放弃的实验、审查成本和故障恢复成本。当一次廉价的实现会在下游制造高昂的不确定性时，它就并不便宜。

Orosz 的到访记录了一个仍在形成中的重要转变。OpenAI 不再仅仅使用 Codex 来帮助工程师更快地编写软件。

它正在围绕 agents 重组软件生产流程：这些 agents 负责收集上下文、执行工作、审查变更、监控部署，并从生产信号中学习。

结果是一座 agentic 软件工厂，但并非没有人类参与的黑灯工厂。人们仍然选择目标、定义约束、接受风险，并在系统行为出乎意料时进行干预。

对读者而言，实际的问题不是是否应立即复制 OpenAI 的工作流，而是当实现成本大幅下降时，交付系统中的哪一环会成为瓶颈。

先找出一个范围明确的工作流：它应具备可衡量的结果、可靠的测试、最新的上下文和可逆的操作。然后衡量完整的审查与维护负担，而不只是 agent 可见的速度。

如果这项实验成功，应先扩展反馈系统，再扩展自主性。OpenAI Codex 软件工厂表明，agents 通过更好的环境实现规模化，而人类判断决定它们的产出是否值得发布。