外网爆料者 @elder_plinius 近期公开了一份据称属于 OpenAI 现役代码模型 GPT-6 Sol Codex 的系统提示词与工具定义，文件已在 GitHub 仓库 CL4R1T4S 的 OPENAI/Codex_Desktop 路径下放出。按爆料说法，文档约 29.4 万字符、共 1902 行，涵盖指令模板、临时指令文件与内部协作逻辑。需要说明的是，这份材料的真实性在开发者社区仍有争议，下文仅以「若内容属实」为前提，拆解其中反映出的提示词工程与智能体设计思路。

先给自己列了一份「废话黑名单」

文档中最直观的一点，是 OpenAI 在写作风格板块对模型做了严厉的反套路训练。指令点名要求避免使用一批「AI 废话词汇」，例如结论中不要写「底线是（Bottom Line）」「重要性（Significance）」「视角（Perspective）」，也不要用「深入（delve）」「培养（foster）」「利用（leverage）」「值得注意的是（it’s worth noting）」「重要的是（importantly）」这类套话。

更进一步的约束包括：不准强行热情——要求模型像「充满好奇心、思想严谨的协作者」，让个性自然流露，而非阿谀奉承；不准用废话凑字数，直接说明意图，不要列举「我不会做什么」「哪些保持不变」；讨论技术概念时像和同事对话，优先用熟悉词汇与具体描述，绝不假设用户能自行脑补缺失步骤。

对中文使用者而言，这相当于给所有提示词工程师上了一课：想要模型输出高质量内容，第一步往往是建立一份负面词汇黑名单，强制斩断套路化表达。

被赋予「别烦我，我在干活」的自主权

文档把 GPT-6 Sol Codex 塑造成一个拥有极高自主权的数字员工。在「自主与持久性」章节，指令明确要求：一旦会话中的证据支持下一步操作，模型就应继续工作，而不是停下来向用户确认；不要为了节省时间或令牌而满足于「勉强有用」的半成品。

落到具体行为：遇到缺陷自己修，可自主创建隔离工作区、解决 Git 合并冲突、创建草稿拉取请求（PR），除非操作具有破坏性或不可逆，否则不会中途询问「接下来怎么办」；只有在点击「部署」或「合并代码」这类最后一步时，才把结果交给用户签字。为防止后台干活时把用户晾在一边，指令还规定：只要请求需要调用工具，每 60 秒必须在评论频道给出一条简短状态更新。

工具链偏好与并行策略

作为代码智能体，文档暴露了它对工具链的硬编码偏好。搜索文本或文件时，指令要求优先使用 rg（ripgrep，极速搜索工具）或 rg –files，而非更慢的 grep；多个独立任务必须用 await Promise.allSettled([…]) 并行处理，压榨时间效率。

文档还定义了一套名为 SKILL.md 的机制：当用户要求做某件事时，模型可去指定目录读取技能说明，甚至通过短路径别名快速调用，相当于给模型外挂了一本可热更新的「技能书」。在浏览器与桌面操作模块，OpenAI 设置了多级确认模式，既允许模型自己打开网页、点击按钮、填写表单、截图，又用复杂确认逻辑防止其「闯祸」。

记忆压缩与「心跳唤醒」

面对庞大代码库，大模型最怕上下文超载。文档给出的解法是：当令牌（Token）预算即将耗尽时，系统不会直接崩溃，而是先用笔记工具保存一份简明的交接记录——包含目标、决策、进度、学习内容、下一步，以及相关窗口与项目编号，再开启全新上下文窗口，如同人类换班前写交接文档。

更值得关注的是常驻后台能力：文档要求模型主动跟踪任务，例如用户问某个评估（eval）跑得怎么样、而它还在运行时，先报告当前状态，再继续监控直到终止；系统还会定期向模型发送隐藏的 XML 标签将其「唤醒」，检查后台任务是否完成。若无事可做，模型必须选择不通知；若持续集成（CI/CD）跑崩，则立即弹窗通知用户。

一份能直接抄走的代码审查指南

对程序员来说，文档里最实用的或许是内置的代码审查规则：忽略无关紧要的代码风格，除非它影响可读性或违反既定标准；每一条建议都必须用一段话讲清「为什么这是个问题」；绝不提供超过 3 行的代码片段；若是具体替换建议，必须使用 Markdown 的 suggestion 块，并完美保留原有缩进；语气必须客观，禁止拍马屁，不许说「干得好」「谢谢你的提交」。这套逻辑稍加改造，就能接进公司内部的代码审查机器人。

社区怎么看

这份近 30 万字的泄露在外网开发者社区引发两极反应。有人被其系统工程密度震撼；也有人质疑意义——网友 vechen 指出，这「泄露」可能本就从本地文件直接取得，在 OpenAI 公开的 Codex 仓库里本就有影子；另有开发者嘲讽，称任何人跑一个 mitmproxy 都能从 OpenAI、Gemini 或 Claude 提取提示词，无需包装成「死海古卷」般的噱头。

无论真伪，这份文档折射出一个趋势：工业级人工智能应用靠的不是几句讨巧话术，而是严密的系统工程——模块化技能动态加载、记忆管理与压缩、并行执行与重试、以及挂载严格的安全协议。大模型正从一个聪明的对答机，逐步演进为具备接管权限的自主系统，而这类底层逻辑，正是通向该方向的一份说明书。

从聊天工具到工作伙伴

OpenAI 称，ChatGPT Work 和 Codex 用户的快速增长，反映出企业和开发者对文档处理、数据分析、软件开发及工作流程自动化等功能的需求不断上升。公司同时加大对企业级人工智能市场的布局，推出的”Dots”AI 智能体可以跨应用执行任务，并结合 Codex 和 ChatGPT Work 完成资料调研、数据分析、文档制作和软件开发等工作。OpenAI 表示，企业用户规模的扩大，将推动人工智能从”对话工具”转向”工作伙伴”。

行业背景

第三方媒体 The Decoder 报道称，OpenAI 年化收入正接近 700 亿美元，较第三季度初增长约 70%；在开发者日上，OpenAI 还面向重度用户推出每月 500 美元的 ChatGPT Pro 档位，并重新开放每月 200 美元档位。企业级销售与针对 Claude 及中国模型的激进定价，被视为用户规模持续增长的主要驱动力。

过去两年，甲骨文花费数十亿美元帮助其他企业运行 AI，但公司内部全面引入生成式 AI 的时间却晚得多。据《商业内幕》报道，甲骨文联合 CEO 克莱·马古尔克在内部员工大会上坦言，直到去年，公司还没有找到让生成式 AI 在整个员工队伍中真正发挥作用的方法。

这番”自曝家丑”式的表态，为大型企业如何真正用好 AI 提供了一份难得的真实样本。

三个月冲到 80% 采用率

甲骨文首席信息官杰伊·埃文斯向员工介绍，转折出现在今年 4 月和 5 月，公司开始部署 ChatGPT Enterprise 和 OpenAI 的代码工具 Codex。甲骨文没有简单地把工具开放给员工，而是同步制定公司标准、安全控制措施和内部政策，三个月内使用率便达到 80%，覆盖约 16 万名员工。

埃文斯说：”我们把这些工具做得太容易上手了，结果可能多少会被成本吓到。”甲骨文因此建立了内部监控机制，可以查看员工使用哪些模型，以及分别产生多少费用。

在模型选型上，成本差异显著。埃文斯指出，OpenAI 的 GPT-6 Astra 使用成本达到其他模型的 2.5 倍，而许多任务并不需要调用如此昂贵的模型，日常工作可以交给成本较低的 Terra 处理。类似地，摩根大通近期为员工使用 Anthropic 的 Claude 设定了每月 2000 美元的上限。

写代码快了，交付没快

两名高管称，AI 显著加快了软件开发，但也把工程流程的瓶颈推向其他环节。埃文斯表示，开发人员用这款工具大约一周就能生成过去一个开发团队通常要花两到三个季度才能完成的代码。

然而目前，开发速度的提升还没有转化为更快的产品交付。马古尔克解释称，公司仍在研究如何重新设计测试、验证、部署和发布管理流程，使其跟上代码生成速度。”写代码本身变快了，并不意味着所有事情突然都会快 1000 倍。”

甲骨文的经历暴露出企业大规模引入 AI 后的下一道难题：强大的模型能够大幅压缩单项任务所需时间，却可能同时带来高额账单，并把瓶颈转移到其他环节。

安全扫描的误报困局

甲骨文还获得提前使用 Anthropic 用于扫描代码安全漏洞的 Mythos Preview 模型。埃文斯称，这款模型投入使用后，短短两周发现的潜在问题就超过甲骨文此前一整年的发现数量。今年 4 月公布的 Anthropic Mythos 被认为是迄今最强的 AI 系统之一，多国政府和安全机构警告其能力超过其他模型，在网络安全领域尤为突出。

不过，如此强的扫描能力也带来了大量误报。埃文斯估计，Mythos 发现的问题中约 60% 至 70% 属于误报。甲骨文因此建立了新的核查流程，由工程师先确认漏洞是否真实存在，再着手修复。

换言之，AI 模型写代码的速度超过公司发布代码的速度，发现缺陷的速度也超过任何人核查的速度。瓶颈被转移，而非消失——这正是许多急于铺开 AI 的大型企业共同面临的现实。

（本文基于《商业内幕》及 IT之家报道，并参考多家媒体转述整理。）

微软于 9 月 17 日发布 Visual Studio Code 1.138 版本更新。本次更新的核心方向是强化人工智能智能体（Agent）在编辑器中的协作能力，包括支持在开发容器中运行智能体会话、扩展 Codex harness 运行环境，并预览一项会话清理功能。

智能体会话进驻开发容器

新版最值得关注的变化，是允许智能体在本地开发容器中运行。启用配置项 chat.agentHost.devContainer.enabled 之后，凡是带有受支持开发容器配置的本地文件夹，都会在文件夹菜单中出现“使用开发容器”选项。点击该选项，智能体会话便会在对应的容器中执行，不过使用该功能需要预先安装 Docker。

与以往智能体直接调用本机全部工具与依赖不同，容器内的智能体只能使用项目明确指定的工具和依赖项，并严格遵循项目配置的运行环境。这种设计让智能体的操作被限定在项目边界之内，减少了误触本机环境的隐患，也让“在同一套依赖下复现结果”变得更可靠。

Codex harness 打通 ChatGPT 与 VS Code

1.138 版本还扩展了 Codex harness 的支持范围，使同一段会话可以在 ChatGPT 应用与 VS Code 之间延续。用户既可以选择 GitHub Copilot 订阅，也可以选择 ChatGPT 订阅；若两类账户同时登录，还能在模型选择器中直接切换所使用的模型。

所谓 Codex harness，是指围绕 Codex 模型搭建的一整套运行环境与控制机制，负责把模型接入应用、工具与工作流。在 VS Code 中，Codex 能够调用编辑器的内置工具、扩展工具以及 MCP（模型上下文协议）工具。若使用的是基于 ChatGPT 的模型，Codex 还能在会话中直接调用图像生成工具。

会话清理功能进入预览

本次更新还以预览形态推出了会话清理功能。它能够让开发者对已经完成的工作做调整，同时把对话保留下来以备日后查阅。在合并了所有非活跃会话对应的拉取请求之后，智能体窗口会支持将相关会话标记为“已完成”。

整体来看，VS Code 1.138 把人工智能智能体从“对话窗”进一步推向“工程执行单元”：开发容器隔离、跨应用会话延续、可清理的会话管理，三者共同指向同一个目标——让智能体更可控、更可复现地参与到真实开发流程中。

三款工具的产品形态

三者在「长什么样、怎么用」上走了完全不同的路线：

– Cursor：构建在 VS Code 之上的 AI 原生代码编辑器，提供图形界面（GUI），支持多模型切换，上手门槛低，适合习惯在编辑器里写代码的开发者。 – Claude Code：Anthropic 推出的终端（命令行）编程智能体，强调代理式执行，能够自主读写文件、运行命令并迭代修复，适合复杂项目的重构与跨文件改造。 – Codex：OpenAI 的云端自主编程代理，任务在沙盒云端虚拟机中异步运行，适合把「让 AI 长时间自动干活」这类工作流交给它。

价格区间

三款工具的入门价格均在每月 20 美元左右：Cursor Pro 约 20 美元/月，Claude Code 走 Claude 订阅体系（Pro 约 20 美元/月），Codex 随 ChatGPT Plus（20 美元/月）可用或按 API 用量计费。对个人用户而言，起步成本接近，重度使用才需要升级更高档位。

怎么选：看场景而非看参数

– 日常写代码、改小需求：Cursor 最容易上手，补全与建议体验顺滑。 – 跨多文件的大改造、项目重构：Claude Code 的代理能力更强，但命令行操作对新手有门槛。 – 长时间自动化任务、脚本与流水线：Codex 适合让 AI 在云端异步跑完一整段工作。

三款工具并不冲突，不少开发者会两三个搭配使用。

中国开发者的可用路径

这三款国际工具均需要访问对应的海外服务。对于中国开发者，国内市场也有替代方案可选，例如字节跳动的 Trae、阿里的通义灵码等 AI 编程产品，在合规接入与本地化体验上更贴合国内环境。选择时可优先考虑团队实际的访问条件、数据安全要求与协作习惯。

小结

选 AI 编程工具，先想清楚自己「主要在什么界面、做什么类型的任务」。GUI 派选 Cursor，终端代理派选 Claude Code，云端异步派选 Codex；若更看重国内可用与合规，可把国产替代方案纳入首选清单。

它到底是什么

Agents API 通过 OpenAI 托管的接口，向应用提供 Codex 的 harness。在 OpenAI 自己的表述里，它负责管理工作会话、编排、上下文压缩与恢复，而应用只需提供工具，并选择智能体在哪里执行。文档定义了四个核心对象：

– agent（智能体）：打包模型、指令、工具与 MCP 服务器； – environment（环境）：可选沙箱，智能体在其中访问文件、加载技能、运行命令； – session（会话）：一个持久实例，跨任务持续工作并响应输入； – events / items（事件与条目）：发送的输入与产出的输出。

其中”持久（durable）”一词最关键：一个 session 被设计为可存活，OpenAI 称基础设施能让智能体可靠运行数天。

托管框架替你干的活

公开测试版中，有四个能力直接对应着各团队过去手工维护的代码：

– 上下文压缩（context compaction）：会话接近上下文上限时自动压缩早期内容，保留智能体继续所需的信息，工作流可跨多个上下文窗口运行，无需自建摘要逻辑。 – 工具搜索（tool search）：不再把每个工具定义都塞进提示词，而是按需加载相关定义，降低 Token 消耗、保护模型缓存。 – 程序化工具调用：智能体可并行运行调用、链式串联相关操作、在代码中过滤或合并结果。 – 子智能体（subagents）：以多智能体模式把任务拆成独立片段，并行委托给各自持有独立上下文的子智能体，由主智能体协调并合并结果。配置只需两行：

"agent": {
  "model": "gpt-6-astra",
  "multi_agent": { "enabled": true, "max_concurrent_subagents": 3 }
}

智能体跑在哪里

执行位置留给开发者选择，共有三种：OpenAI 托管的沙箱、自有基础设施、或合作方沙箱。OpenAI 公布了九家首发合作方：Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop 与 Vercel。托管沙箱运行在与 Codex、ChatGPT 相同的隔离架构之上，可配置文件、包、技能与插件；自有与合作伙伴路线则用于那些通常会劝退托管服务的场景——自有 VPC 内部署、特定密钥存储，或特定的 CPU、GPU、内存配置。

怎么收费

OpenAI 在公告中称使用 Agents API”没有额外费用”，严格意义上确实没有名为”Agents API”的账单条目。但文档更精确：模型用量按所选模型的 API 费率计费，OpenAI 工具按标准费率计费，OpenAI 托管的沙箱按标准容器费率计费。由于持久智能体是一个保持温热的容器，在围绕长寿命会话做架构设计前，值得先了解这些容器费率。

早期客户数据

OpenAI 公布了若干早期客户说法作为佐证，应作为方向性参考而非基准：

– Ciridae 的 CTO 称其评测分数从 0.71 升至 0.85，子智能体流程带来约 4 倍延迟下降； – SafetyKit 在将案例审查流程迁移后，单案例成本下降 60%； – Hypha 称把 harness 与沙箱分离后，失败的智能体响应减少 86%。

这些数字的形状，与并行委托本应对墙上时钟时间产生的作用一致。

值得注意的取舍

公开测试期内，数据处理仍留在美国境内，且即便在自托管沙箱上也不支持零数据保留。更重要的权衡是依赖关系：采用 Agents API，意味着把应用的编排层锁定在 OpenAI 的实现上，并随 OpenAI 的模型发布进行版本对齐，而不是独立拥有这一层。对于差异化在于工具、数据与工作流、而非智能体循环本身的团队，这笔交易相当直接；而旨在跨多家模型供应商工作的智能体平台，更可能把 GitHub 上开源的 Codex harness 而非这套托管 API，视为更相关的采纳对象。

结语

框架如 LangGraph、CrewAI 帮助开发者拼出智能体管线，但让长寿命智能体在生产中稳定存活的运维负担，过去一直由各个团队自行承担。Agents API 把这块负担收归托管，是”模型供给”向”智能体运行时”延伸的明确一步，也与 Anthropic、Google 的 agent 框架形成正面竞争。

OpenAI 于当地时间 9 月 10 日推出 Agents API 公测版，把原本只在自家产品内部使用的 Codex 智能体执行框架和云基础设施，变成了一项所有开发者都能直接调用的托管服务。

过去搭建一个能跑在生产环境里的 AI 智能体，团队往往需要自己拼装模型调用、工具协议、状态存储、重试逻辑和沙盒环境，工程量不小。Agents API 的思路是把这些”脏活”收拢到一个接口后面：开发者只需要指定任务、模型、工具以及运行环境，OpenAI 在自己的基础设施上负责跑通整个智能体循环。

一次调用创建生产级智能体

按照官方说法，开发者只需一次 API 调用，就能创建出达到生产环境水准的智能体。智能体可以在云端运行代码、处理文件、保存中间结果，并持续执行跨越数小时甚至数天的任务。

这种长时运行能力依赖两项关键设计。其一是上下文管理：当会话接近上下文窗口上限时，系统会自动压缩早期信息，保留关键内容，让任务能够跨越多个上下文窗口连续推进。其二是工具搜索与程序化工具调用：智能体按需加载工具定义，可以并行发起调用、串联多个操作，或先对返回结果做筛选再写入模型上下文，从而减少无效 Token 消耗。

多智能体协同也是首发能力之一。开发者可以把复杂任务拆成若干独立子任务，交给子智能体并行处理，再由主智能体协调汇总。OpenAI 给出的示例中，最多可配置 3 个并发子智能体。

沙盒可以自己选，也可以交给 OpenAI

在执行环境上，Agents API 提供了三条路径：使用 OpenAI 托管的沙盒、部署在开发者自有基础设施或虚拟私有云中，或者接入合作方提供的沙盒。

首批合作方包括 Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop 和 Vercel，各家提供不同的 CPU、GPU、内存以及文件与密钥存储配置。把”编排层”和”沙盒层”分开设计，意味着模型侧的智能体循环由 OpenAI 运维，而代码执行和数据文件可以留在开发者自己的环境里。

同步推出的 OpenAI Hosted Sandbox 服务，则面向不想自己搭沙盒的团队。开发者可以直接为智能体配置环境文件、软件包、技能和插件，用于运行代码、处理文件和生成产物，底层采用与 Codex 和 ChatGPT 相同的沙盒基础设施。需要注意的是，托管沙盒默认开启网络访问，开发者可关闭出站访问或改为白名单；闲置一小时的非活跃沙盒会被自动删除。

开源内核与两项现实约束

Agents API 基于开源的 Codex 执行框架打造。开发者可以查看公开代码库，了解协调模型调用、工具和上下文的核心逻辑，OpenAI 则负责维护这套框架，并随模型更新持续改进智能体能力。

计费方面，Agents API 本身不额外收费，开发者只需为实际消耗的模型 Token 和工具调用付费；若使用 OpenAI 托管沙盒，则按标准容器费率单独计费。

不过有两项限制值得提前评估。其一是数据驻留目前仅支持美国区域；其二是 Agents API 不支持零数据保留（ZDR），且改用自托管沙盒也不会让工作负载获得 ZDR 资格——对于处理受监管数据或高敏感数据的团队，这是实质性约束。

从产品节奏看，Agents API 承接了 OpenAI 此前的路线调整。今年 4 月，OpenAI 在 Agents SDK 中加入原生沙盒执行和更强的执行框架，但开发者仍需自行运维智能体进程；今年 6 月，OpenAI 宣布 Agent Builder 与 Evals 产品将在 11 月 30 日后从平台下线，引导基于代码的工作流转向 Agents SDK。如今 Agents API 的公测，等于给这批开发者补上了一个托管部署选项。

目前 Agents API 已向所有持有 OpenAI API 密钥的开发者开放公测，官方表示将在公测期间依据反馈持续迭代，并逐步推进正式发布。

纳维-斯托克斯存在性与光滑性问题是七个”千禧年大奖难题”之一，克雷数学研究所为每个问题提供 100 万美元奖金。纳维-斯托克斯方程被广泛应用于流体力学，但要给出严格的理论证明一直困扰着数学界。Buckmaster 与 Alpöge 在证明过程中混合使用了不同 AI 模型，其中主要依赖 OpenAI 的 Codex。

Buckmaster 在公开声明中表示，两人完成研究后得知，”有关研究进展的信息已经传到了 OpenAI”。在与 OpenAI 进一步沟通时，对方告知他们 OpenAI 已经完成了核心问题的完整证明，但当问及 OpenAI 何时开始研究这一问题，以及研究过程中涉及多少人工参与时，对方的回答开始变得含糊其辞。

Buckmaster 称，”后来得知，实际上有一个完整团队一直在研究这个问题，而且使用了数量惊人的计算资源”。最终双方确认，OpenAI 发送第一条提示词是在过去几天内，也就是研究信息传到 OpenAI 之后。按照 Buckmaster 的说法，这意味着 OpenAI 团队已经判断两人采用的方法是正确方向，并决定利用自身在计算资源方面的巨大优势，率先完成正式证明。

据 OpenAI 发布的文章，相关证明由一个尚未发布的新一代模型发现，过去一周该模型已经解决了一系列不同的数学未解问题。整个为期一周的研究过程总计消耗了 3000 亿个输出 Token，按照目前 Astra 的价格计算，如果全部按计算资源收费，成本约为 2250 万美元（约合人民币 1.51 亿元）。

署名问题成为另一争议焦点。Buckmaster 称，OpenAI 研究员 Sébastien Bubeck 曾两次要求将 Alpöge 从相关论文署名中移除，理由是 Alpöge 供职于 OpenAI 的竞争对手 Anthropic。当 Buckmaster 表示若 OpenAI 按这一方案发布成果将公开此事后，Bubeck 回应：”你为什么要毁掉自己的职业生涯？”随后又表示：”如果你不希望我友好，那我也没必要友好。” Bubeck 随后在社交平台发文，称相关指控”虚假且具有煽动性”，并表示自己遵循了学术规范。

OpenAI 在官方文章中淡化了直接接触 Buckmaster 一方数据的可能性，称在双方公开发布研究成果之前，研究人员和智能体没有通过任何方式看到对方的工作。不过 OpenAI 也承认，”虽然可能性很低，但无法完全排除从他们使用 OpenAI 产品过程中产生的去标识化数据曾用于模型改进”。

围绕 AI 在数学研究中扮演何种角色、OpenAI 的利益动机，以及学术成果优先权等问题，这一事件很可能再次引发广泛讨论。

主攻芯片设计、生命科学和金融服务

Friar 表示，OpenAI 目前重点布局芯片设计、生命科学和金融服务三个领域。随着企业越来越希望 AI 系统能够针对特定任务进行优化，公司也在探索更加行业化的解决方案。

与此同时，OpenAI 正在尝试按企业最终获得的业务成果，而不是模型的实际使用量来制定价格。企业客户对 AI 投资回报的要求越来越明确，这种模式成为 OpenAI 正在探索的方向。

这一转变背后是日益激烈的竞争：一方面，中国的开放权重模型持续发展；另一方面，Anthropic 等竞争对手也在争夺企业客户。AI 厂商需要证明产品能够带来可量化的商业价值。

9 个月完成自研芯片流片

Friar 透露，OpenAI 自身在使用 AI 开发芯片方面已经获得了积极经验。公司利用自研模型参与 Jalapeno 芯片的开发，并在 9 个月内完成了”流片”（tape out）。流片意味着芯片设计已经最终确定，并被送往晶圆厂进行实际生产。

这一案例也成为 OpenAI 向芯片设计行业推销 AI 能力的主要依据。

Luna 降价 80%，用量涨约 10 倍

开源和开放权重模型一直被广泛视为前沿模型的低成本替代方案。不过 Friar 表示，OpenAI 近期将旗下低成本 Luna 模型的价格下调了 80%，推动该模型的使用量增长了约 10 倍。

她还指出，对企业而言，直接部署 OpenAI 的低成本模型，有可能比通过云服务商运行中国开源模型更加便宜。她的原话是：”如果你部署 Luna，并将其与智谱（Z.ai）的 GLM 5.3 在云端环境中的成本进行比较，我们的价格更低。”

Codex 用户 2500 万，企业收入增速跑赢大盘

在开发者侧，OpenAI 的编程工具 Codex 目前拥有 2500 万用户。

企业业务的增长更为明显。Friar 透露，今年 6 月至 7 月期间，OpenAI 企业业务收入增长了 32%，同期整体年化收入的增幅为 20%。到今年年中，企业业务和消费者业务收入已经大致达到各占一半的水平，比公司原本计划在年底实现这一目标提前了半年。

成果定价能走多远仍是未知数

按业务成果收费的模式在企业软件领域并非首次出现，成败关键在于如何公平地定义和衡量”成果”。OpenAI 目前尚未披露该模式的具体指标与价格档位。

对缺少深度 AI 工程团队的企业来说，把基础设施、维护等成本打包进可预测的单价确实有吸引力；但受数据合规与供应商锁定考量影响的金融、医疗等行业，可能仍倾向于把模型部署在自己的基础设施上。价格战已经打响，最终比拼的仍是单位成本之下能否交付可量化的业务结果。

从 ChatGPT 到 Codex：一个写作者的转折

这位作者自 2023 年起将 ChatGPT 纳入日常工具栈，但作为文字工作者而非工程师，最初对 Codex 这种「智能体式编程应用」并不感冒。转机出现在 2026 年 4 月——Codex for Mac 加入了 Computer Use（计算机操控）能力，让 AI 得以在本地环境中替用户执行操作。正是这一变化，让他开始尝试用 Codex 完成实际的软件构建。

用自然语言「聊」出一个 Mac 应用

自 2026 年 5 月起，他开始每天使用 Codex，第一个项目是一个名为 Flow 的 Mac 应用，主要用来监控应用发布与更新动态。对他而言，向 Codex 描述每一个想要的功能与改动，就像给同事发消息一样自然。由于这是专为自己打造的第一个项目，应用图标也由他亲自手写首字母，并用苹果的 Icon Composer 制作完成。

不只是玩具：自造专属效率工具

在做出 Flow 之后，他又陆续构建了更多高度定制化的小工具。Better Remote 已在 Mac App Store 上架，核心思路是让 tvOS 设备用起来像另一个 Mac 应用；Better Battery 则针对他个人在 macOS 27 系统下对电池百分比指示可读性不佳的不满，在测试阶段自行做出可用方案，并开放给其他人免费使用。

他还尝试用 ChatGPT Sites 搭配自定义域名来分享这些成果。OpenAI 于 2026 年 8 月为 ChatGPT 增加了共享站点管理工具，使这一功能的可用性进一步提升。在他看来，这类工具的潜力令人兴奋，尽管仍处于非常早期的阶段。

背后：从 Workflow 到 Shortcuts 的传承

这一能力的来源并非凭空出现。早在 2014 年 12 月，iOS 8 上曾有一款名为 Workflow 的自动化应用发布；2017 年苹果将其收购，并在 2018 年随 iOS 12 以「快捷指令（Shortcuts）」之名推向大众。Workflow 的核心成员后来离开苹果创办公司，其预览过的现代 Mac AI 助手项目 Sky 最终被 OpenAI 收购，相关技术以 Computer Use 插件的形式在 2026 年 4 月随 Codex for Mac 落地。

也正是因为这段历史，他对把 AI 放在 Mac 后台代为操盘建立了天然的信任感。对他来说，Codex 最大的价值不在于替他写代码，而在于把「描述需求即生产工具」变成普通人也能做到的事——门槛的降低，正让非程序员拥有属于自己的软件成为可能。