本文要点
- 从9月3日模型首发，转为9月9日面向工作场景的采用说明。
- 从能力叙事，补齐ChatGPT Work、Codex和API三个入口。
- 从单一跑分，加入价格、任务成本、企业默认关闭和安全基准。
阅读辅助
先看数字、证据和来源，再读正文。
9月9日新增内容定位为工作场景说明，Astra主发布属于背景。
2026-09-03 · OpenAI发布GPT-6 Astra主公告，9月9日工作说明称其为上周已介绍的模型。
9月9日新增的是工作场景说明
OpenAI在9月9日新增的《GPT-6 Astra: The next generation in intelligence for work》，新闻点落在企业工作场景。页面开头的英文是“Last week we introduced GPT-6 Astra”，也就是“上周我们介绍了GPT-6 Astra”。这句话把9月9日文章限定成工作场景跟进：OpenAI把Astra放进ChatGPT Work、Codex和API的企业使用语境里，补齐可用入口、价格、工作基准、工程案例和管理员默认开关。
已确认事实可以压缩成四组。第一，Astra现在可用于ChatGPT Work、Codex和API。第二，API起价是每百万输入token 10美元、每百万输出token 50美元。第三，OpenAI给出多组工作流数字，包括Excel相关挑战约为获胜人类选手4倍速度，开发者视频4天超过55万次观看，allocator案例让Codex测试环境turn latency下降25倍但峰值内存约增加30%。第四，企业访问在launch时默认关闭，需要管理员启用。
不确定部分主要在基准和成本解释。Terminal-Bench 4.0的57.9%、DeepSWE v1.1的74%、以及computer use safety benchmark里unintended outcomes分别少89%和74.7%，都来自OpenAI页面口径。它们对采购评估很有用，但仍要等第三方榜单、公开任务集和复现实验确认，尤其是estimated API cost per task并不等同于企业长任务的完整拥有成本。
这条新闻最直接影响的是企业管理员、Codex用户和API开发者。管理员要处理默认关闭后的启用流程和风险审计。开发者要按长任务、工具调用、缓存、重试和失败恢复重算成本。模型团队则会注意到，Astra的叙事已经从“最强模型”转向“能不能在工作流里交付稳定结果”。
关键事实表
OpenAI这篇工作说明把产品可用性、价格、性能和安全放在同一页。它的写法更接近企业采购材料，而不是单纯的模型发布稿：先声明可用入口，再列举专业工作、软件工程、网络安全和科学任务，随后用Codex案例和benchmarks说明为什么它适合高价值工作。
| 项目 | OpenAI页面口径 | 早报采用表述 |
|---|---|---|
| 发布时间关系 | “Last week we introduced GPT-6 Astra” | 9月9日是工作场景说明 |
| 可用入口 | “now available in ChatGPT Work, Codex, and the API” | 可用于ChatGPT Work、Codex和API |
| 企业访问 | “Enterprise access is off by default at launch” | 企业访问launch时默认关闭 |
| API价格 | “Pricing starts at $10 per million input tokens and $50 per million output tokens” | 起价为每百万输入token 10美元、输出token 50美元 |
| Terminal-Bench成本 | “estimated API cost per task” lower by 9% and 63% | 估算API单任务成本分别低约9%和63% |
这张表的核心是状态动词和比较基准。OpenAI用了introduced、now available、starts at、off by default at launch、estimated这些词，分别对应背景、当前可用、起价、发布时默认状态和估算成本。早报不把“上周介绍”改写成“今天发布”，也不把“默认关闭”改写成“默认开放”。同样，成本差异只对应官方自报的estimated API cost per task，不能外推到人工管理、失败重试、企业审计、数据处理和内部集成的总成本。
工作流叙事如何落到Codex
Astra工作说明里最有企业感的部分，是它把模型能力落到Codex和工程任务。OpenAI给出的allocator案例属于内部工程流故事，不能当作通用benchmark：模型在Codex测试环境中切换allocator后，turn latency下降25倍，但峰值内存约增加30%。这个数字组合比单独的“速度提升”更重要，因为它同时暴露了优化收益和资源代价。
对开发者来说，turn latency下降会改变交互节奏。过去高能力Agent若每轮反馈太慢，用户会把它当成离线批处理；一旦单轮延迟大幅下降，它更接近可持续监督的结对工程工具。可是峰值内存约增加30%也提醒用户，性能优化不是免费午餐。企业如果把类似工作流放进CI、测试沙箱或大规模代码迁移，需要同时计入并发、内存上限、实例规格和排队策略。
OpenAI还把开发者视频观看量写进页面，称GPT-6 Astra Developer First Impressions视频4天内超过55万次观看。这个数字不能证明转化率，却说明发布后开发者注意力很集中。与传统模型公告相比，工作说明更像在回答“开发者已经看到了，企业怎么把它放进正式流程”。这就是它和9月3日Astra主发布的区别：主发布解决模型身份，9月9日页面解决使用路径。
基准数字需要分层读
Terminal-Bench 4.0和DeepSWE v1.1是这篇文章里最容易被传播的数字。OpenAI称Astra在Terminal-Bench 4.0达到57.9%，对比GPT-5.6 Sol2的37.3%和Claude Fable 5.1的55.8%。同一段还称，Astra的estimated API cost per task分别比Sol2低约9%，比Claude Fable 5.1低约63%。DeepSWE v1.1方面，OpenAI引述Datacurve口径称Astra达到74%。
| 指标 | Astra | 对照对象 | 早报判断 |
|---|---|---|---|
| Terminal-Bench 4.0 | 57.9% | Sol2 37.3%；Claude Fable 5.1 55.8% | Astra分数领先Sol2，略高于Fable |
| 估算API单任务成本 | OpenAI称更低 | 比Sol2低约9%；比Fable低约63% | 只代表官方估算API任务成本 |
| DeepSWE v1.1 | 74% | OpenAI引述Datacurve口径 | 需要复查榜单设置和可复现性 |
| 内部安全基准 | unintended outcomes更少 | 比Sol少89%；比Fable少74.7% | 仍需公开任务集定义 |
这里不能只看最高分。Terminal-Bench关注的是终端环境中的真实工程任务，分数变化会影响模型是否能被放进Codex类工作流。但企业决策还会问三件事：任务是否覆盖自己的代码栈，工具权限如何隔离，失败时谁来承担回滚和审计。DeepSWE同样如此。一个74%的指标如果建立在特定任务集、特定提示策略和特定工具环境上，外部团队必须先复查设置，再决定是否把它当成迁移依据。
成本对比也要保持窄口径。OpenAI的“lower estimated API cost per task”不是“总成本更低”的充分证据。API账单只是一部分，企业还要付上下文整理、测试环境、权限网关、人工验收、数据脱敏和失败任务回放的成本。如果Astra以更少轮次解决高价值任务，API成本下降会被放大；如果它在长链任务里更频繁调用工具，实际账单可能和页面估算不同。
安全默认值比跑分更接近采购问题
企业访问launch时默认关闭，是这篇文章里最不适合被忽略的产品细节。OpenAI可以同时说Astra可用于ChatGPT Work、Codex和API，也可以把企业访问默认设为关闭；二者并不矛盾。可用性说明的是产品入口已经存在，默认关闭说明企业租户需要管理员决定是否启用。
这会改变Astra的企业传播路径。对于个人开发者和小团队，API价格和Codex能力可能是第一优先级；对于大企业，默认关闭意味着安全、法务、IT和业务负责人要先定义谁能用、能接触哪些数据、是否允许电脑使用、是否纳入审计、如何处理提示词和执行日志。Astra越强调computer use、browsing、professional work、software engineering、cybersecurity和science，管理员越不能把它当成普通聊天功能处理。
OpenAI在安全概览和工作说明中给出的computer use safety benchmark，也应放在这个语境下看。官方称Astra产生unintended outcomes的频率比GPT-5.6 Sol少89%，比Claude Fable 5.1少74.7%。这说明OpenAI想把安全改进和工作场景放到同一套采购叙事里：不是只说模型更强，还说它在电脑使用任务中更少产生非预期结果。边界在于，这仍是内部安全基准。读者要等任务定义、样本规模、风险分类和外部复查，才能判断它能否代表企业真实风险。
这篇Astra工作说明把增量放在企业可执行约束上：入口、价格、管理员默认值、工程延迟、任务成本和安全基准都被放到同一张采用清单里。
早报判断是，Astra正在被包装成工作流模型，而不是单纯的聊天模型。它的竞争对象不只是其他模型的跑分，还包括企业内部流程里一整套隐性成本：谁批准访问，谁审计工具动作，谁复核代码改动，谁为失败任务买单。OpenAI给出的价格和benchmarks会帮助采购方做第一轮筛选，但真正决定采用速度的可能是默认关闭后的组织流程。
当前最大风险是厂商自报数字被过度外推。Terminal-Bench、DeepSWE和内部安全基准都值得记录，因为它们对应真实工作任务；但它们还不是独立复现后的行业共识。Astra如果要成为企业级工作模型，下一步需要拿出更清楚的任务集、失败率、审计接口和端到端成本账本。
接下来看什么
管理员控制是最先落地的验证点。OpenAI已经写明企业访问在launch时默认关闭，接下来要看ChatGPT Work租户里具体有哪些开关、日志和审批项。若管理员只能做粗粒度启停，Astra在高风险团队里的使用会被限制；若能按团队、数据源、工具权限和任务类型配置，它才更像企业工作平台的一部分。
Benchmarks需要外部复现。Terminal-Bench 4.0的57.9%和DeepSWE v1.1的74%都要看提示词、工具环境、超时、重试次数、人工介入、失败任务计分和成本计算方法。尤其是estimated API cost per task，必须和真实长任务的上下文长度、缓存命中、工具调用次数放在一起看。
Codex案例还需要更多审计材料。allocator案例把收益和代价同时写出，是一个好的信号：turn latency下降25倍，峰值内存约增加30%。如果OpenAI后续能披露更多类似案例，包括任务难度、代码规模、回归测试、错误回滚和人工验收比例，企业会更容易把Astra放进正式工程流程。
安全基准的透明度也要继续看。unintended outcomes少89%和少74.7%听起来很强，但它依赖内部computer use safety benchmark的定义。后续应验证任务集是否覆盖真实企业误操作，风险分类是否稳定，第三方是否能在相近环境下复查同一方向的下降。
这条跟进的结论因此很克制：Astra已经从首发公告进入企业使用说明阶段，OpenAI给出了足够多的采购变量；但这些变量还需要从官方页面走进第三方复现、管理员控制台和真实账单。今天能确定的是新闻锚点和官方口径，不能提前替企业市场宣布采用结果。