1. GPT-6 系列全解读：Astra、Sol 与 Luna 如何分工

[!abstract] 速览

• GPT-6 用 Astra、Sol、Luna 三个档位覆盖从最难的科研与工程任务，到边界明确的高频步骤；9 月 29 日的 6.1 Sol 又单独改写了 Sol 这一档。
• 9 月的发布面向 Work、Codex 与开发者，10 月 7 日才把对话调校版本带进普通 Chat；入口不同，体验与基准数字不能互相代入。
• 三档模型的 API 价格差距明显，上下文上限相同，但输入超过 272K 会触发更高的长上下文费率。
• Astra 的 Critical 评估针对 9 月版本，10 月 Chat 版的评估为 High，两者对象与测试条件不同。
• 推荐路径是先用 6.1 Sol 跑通真实任务，再分别验证 Astra 能救回哪些难题、Luna 能接住哪些简单步骤。

1.1. 为什么值得关注

**GPT-6 最值得理解的变化，是把不同强度的智能分配给不同的工作。**Astra 面向难题，Sol 把复杂任务带到更可持续的成本区间，Luna 承接目标明确的高频步骤；9 月 29 日的 6.1 Sol 又让这条分工线发生变化。读者需要的不是一张总分榜，而是一套能解释「什么时候值得多付钱、什么时候应该换方法」的判断框架。

本专题以 2026 年 10 月 23 日为资料核对时点，串联 9 月发布、6.1 Sol 迭代及 10 月普通 Chat 更新。正文分别标明官方事实、实测观察与编辑建议，尤其区分模型版本、产品入口、API 价格和整项任务成本。

[!tip] 核心判断
与其把它当成一次全面换代，不如当成一次按任务强度重新分配预算的调整：最难的交给 Astra，常规复杂任务交给 6.1 Sol，标准明确的高频步骤交给 Luna。

1.2. 事件时间线

1. 2026-09-01：OpenAI 发布 Astra 能力与前沿保障背景说明，为正式发布交代安全准备。
2. 2026-09-03：GPT-6 Astra 发布，官方同步说明 Critical 网络安全能力评估及安全措施。
3. 2026-09-22：GPT-6 Sol 与 Luna 发布，扩展系列的能力和成本档位。
4. 2026-09-29：GPT-6.1 Sol 发布，更新 Sol 档位；dots 的官方介绍展示 Astra 的常驻 Agent 产品方向。
5. 2026-10-02：官方发布系列使用指南，说明模型选择、推理强度、长运行任务与生产实践。
6. 2026-10-07：GPT-6 与 Intelligent UI 开始进入普通 Chat；官方明确该次更新不更换 Work、Codex 的模型。

1.3. 核心变化与亮点

1.3.1. 先看清命名：三个档位，一条持续更新的产品线

读懂 GPT-6，首先要分清「代际」「档位」和「版本」。Astra 是高能力档位；Sol 面向复杂工作的成本与能力平衡；Luna 面向目标明确、可重复的大规模任务。9 月 29 日推出的 GPT-6.1 Sol 是 Sol 档位的迭代，不是整个系列同时升级到 6.1。对新项目而言，比较的重点应当是 Astra、6.1 Sol 与 Luna，而不是只盯着最初发布的 6 Sol。

官方卡片展示的是三个能力与成本档位。图中 Sol 已是 6.1 版；价格是每百万 Token 的标准费率，不是一次任务的总成本。

更容易混淆的是 模型与产品入口的关系。9 月发布首先服务于 Work、Codex 和开发者；10 月 7 日的更新则把针对日常对话调校的 GPT-6 带到普通 Chat，并引入 Intelligent UI。官方说明该次更新没有替换 Work、Codex 所用版本；10 月系统卡也明确区分 September 与 October 两组模型。因此，Chat 里的体验、Codex 的工程表现和 API 的基准数字，不能不加区分地相互代入。

1.3.2. Astra 的变化：从写出答案，走向操作软件并检查结果

Astra 的重点是复杂工作中的连续执行：读懂屏幕、使用专业软件、修改产物、检查结果，再继续迭代。OpenAI 发布时报告，Astra 在 Terminal-Bench 4.0 达到 57.9%，在 OSWorld 2.0 离线子集取得 72.6% 的部分得分。前者考察复杂终端任务，后者考察计算机操作；两项分数都不是「任意任务一次成功的概率」，也不能直接与不同版本基准横比。

官方网站案例展示了同类任务的产物差异。它有助于理解视觉判断与执行闭环，但属于厂商演示，不能替代独立、同条件的测试。

中文实测提供了另一种观察：作者与 Astra 反复调整平面图、Blender 场景、材质和灯光，最后导入 Unreal Engine。重要的不是一张漂亮效果图，而是中间产物能够继续编辑，模型也能借助预览纠错。这个案例里同时有大量人工定方向、确认方案和检查细节的过程；把它缩写成「一句话自动完成建筑设计」会丢掉最有价值的信息。

Garden House 是人机多轮协作后的概念场景，展示可编辑 3D 产物与视觉检查的结合；它不是经过结构与建筑规范审核的施工方案。

1.3.3. Sol 与 Luna：把能力放到值得付费的地方

**Sol 适合需要判断、跨步骤推进、但又必须控制成本的工作。**6.1 Sol 的官方评测显示，它在一些编码与计算机操作任务上接近 Astra，但这不代表两者在所有难题上等价。例如，发布文明确保留了 Astra 在最难科学任务中的优势。这里应当读出的是成本—效果曲线移动，而不是「便宜模型全面取代旗舰」。

Luna 适合验收标准清晰的高频步骤：提取发票字段、分类请求、生成结构化摘要、处理格式一致的文档。它也支持推理和工具使用，不能简单理解成「不能思考的小模型」；但步骤便宜不等于整条工作流便宜，错误分类、遗漏字段或反复重试，可能把节省的 Token 费用全部吃掉。

原始 6 Sol 与 Luna 在 9 月 22 日一同发布，随后 Sol 很快迭代。这也解释了为什么同一周的媒体报道容易把「新模型」「更便宜」和「不同产品上线」混在一起：报道适合看事件全貌，选型仍要回到准确的模型 ID、日期与运行环境。

1.3.4. 价格、长上下文与推理强度，要放进同一本账

[!note] 价格口径
表内是 2026 年 10 月 23 日核对的 API 标准文本价格，单位美元／百万 Token，基准为输入不超过 272K Token 的请求。产品订阅额度、工具费用、缓存写入、加速模式、批处理和长上下文计费另算。

模型	定位	上下文窗口（Token）	未缓存输入	缓存读取	输出	适合先验证的工作
GPT-6 Astra	高能力档，面向难题	1,050,000	$10	$1	$50	难题、复杂调试、需要最高能力的工作
GPT-6.1 Sol	成本与能力的平衡档	1,050,000	$2	$0.10	$10	复杂编码、研究与多步业务任务
GPT-6 Luna	高频、边界明确的档位	1,050,000	$0.10	$0.01	$0.50	高频、可重复、边界明确的任务

当前模型目录列出的三者上下文窗口均为 1,050,000 Token，最大输入为 922,000 Token，最大输出为 128,000 Token；能装下不等于值得全部装进去。例如，6.1 Sol 的模型文档明确：输入超过 272K 后，整次请求按更高的长上下文费率计价。长上下文、输出上限和计费门槛是三个不同概念，迁移时应逐项检查，可对照 API 模型目录。

三者当前 API 的基础模态都是文本、图像输入与文本输出；产品里能使用音视频工具，不等于这些模型接口原生生成音频或视频。

开发者真正能调的也不只有模型：推理强度决定愿意让模型花多少计算，速度模式决定是否为更快的生成支付额外费用，上下文组织则决定有多少内容需要重复处理。较高的 reasoning effort 不保证每次都更正确；应在同一组真实任务上测量收益，而不是把所有开关一律调到最高。

1.3.5. 生产选型：先量任务，再决定是否路由

一个可行的起点是用 6.1 Sol 跑通代表性任务，再分别测试 Astra 能救回哪些困难样本、Luna 能稳定接住哪些简单步骤。保留相同工具、权限、超时和验收标准，同时记录人工返工与重试；否则，比较出来的可能是环境配置差异，而不是模型差异。这是本专题的工程建议，需用自己的任务数据验证。

LangChain 的 Open SWE 案例说明了这条路线如何落地：在 973 个线程的 A/B 测试中，路由组的线程成本中位数从 $2.61 降到 $0.94；合并 PR 的比例没有出现统计上显著的差异。但该实验的组合是 GLM-5.3-Flash、GPT-5.6 Sol 与 GPT-6 Astra，不是 Astra／6.1 Sol／Luna 三者的直接横评。它支持的是「按任务分配预算」的方法，不能拿来证明本专题三档模型的具体节省比例。

[!warning] 数据边界
Open SWE 实验用的是 GLM-5.3-Flash、GPT-5.6 Sol 与 GPT-6 Astra，并非本文三档模型的横评；它的降本幅度不能直接外推。

路由组总体更便宜，但不同档位成本差异很大。这是特定团队、特定时间段的线上实验，不是所有 Agent 都能复现的降本承诺。

建议同时看四个结果：任务是否被验收、端到端耗时、每次成功任务成本、人工接管次数。缓存更适合复用稳定前缀，压缩与持久状态帮助长任务继续；模型换挡、工具定义变化和无效上下文则可能破坏复用。先把成功的定义写清，再优化预算。

1.3.6. 生态落地：同一模型，放进不同系统会有不同能力

Codex 把模型接入仓库、测试、审查和软件操作；Agents API 把长运行任务的执行环境与编排提供给开发者，发布时仍是 public beta；dots 则把常驻执行、云端电脑和插件连接组织成产品。它们都能放大模型价值，但不是模型本身的同义词。不能因为 Astra 支持 computer use，就假设每个 API 请求自动拥有浏览器、账号权限或持续运行的环境。

OpenAI 的内部研究文章记录了编码 Agent 如何参与日常研究，但这是厂商内部的工作观察；Noam Brown 的访谈也强调，训练环境、可验证反馈与研究判断仍然影响效果。将这些材料合起来看，合理的结论是工作流程正在改变，而不是「自主研究已经没有瓶颈」。

1.3.7. 技术依据与安全：能力增长，也扩大了需要管理的边界

本专题核查到的核心技术依据是官方发布、API 文档、系统卡及其增补；本次没有找到可据以完整复现 GPT-6 训练的独立技术论文或开放权重。已披露的评测和对齐方法，不能被扩写成未公开的参数规模、模型架构或训练配方。

Astra 达到 OpenAI Preparedness Framework 的 Critical 网络安全能力阈值。这是厂商在特定框架下对能力与风险的评估，不是对真实部署安全性的保证。官方同时报告了更强的边界遵守和越狱抵抗，也承认某些对抗条件下思维链更难监测；「更对齐」与「已解决对齐」之间仍有距离。

Hugging Face 事件、后续失准报告框架与外部研究者的批评，提供了必要的反向材料。历史事件不能直接归罪于 Astra，但能解释为什么部署方仍需限制权限、观察真实行为、保留审计与停止机制。Computerphile 对事件透明度和监控责任的追问，是外部评价；具体归因应与官方报告并列阅读。

还要区分 9 月 Astra 的 Critical 评估与10 月 Chat 版 Sol/Luna 的 High 评估；对象、版本和测试条件不同，不应混成一个「GPT-6 安全等级」。更强的模型值得更好的测试，也值得更清楚的授权边界。可查阅 10 月安全系统卡。

[!warning] 未证实与易混淆
目前没有可据以完整复现 GPT-6 训练的独立论文或开放权重；9 月 Astra 的 Critical 评估与 10 月 Chat 版的 High 评估对象不同，不能合并成一个「GPT-6 安全等级」。

1.4. 各方观点

1.4.1. 官方立场

6.1 Sol 在部分编码、计算机操作与专业任务上接近 Astra 的表现，但最难的科学研究任务仍有理由选择 Astra。

— OpenAI（观点转述）

1.4.2. 工程实践

模型路由应当理解具体任务；降低成本必须同时观察真实任务结果，不能只看模型价目表。

— Sydney Runkle、Eugene Yurtsev／LangChain（观点转述）

1.4.3. 研究审慎

Agent 的效果受到训练环境、反馈与研究判断的约束；能力增长并没有让这些瓶颈自动消失。

— Noam Brown／访谈中文整理（观点转述）

1.4.4. 外部批评

讨论 Agent 风险时，不能只寄希望于对齐训练，还应追问行为监控、事件披露与开发方责任。

— Computerphile 节目嘉宾（观点转述）

1.5. 编辑后记

1.5.1. 怎么开始，怎样判断是否值得升级

先选一项你能亲自验收的真实工作：一份带来源的研究简报、一个有测试的缺陷修复，或一批能核对正确性的结构化抽取。记录当前模型的结果，再测升级带来的改善。不要同时更换模型、工具和流程，否则很难知道收益来自哪里。

后续最值得追踪的不是某个榜单是否再高一分，而是困难样本能否被稳定救回、重复任务是否更少返工、长期运行是否仍然守住授权边界。这也是本专题推荐按任务分档，而不是只按模型名付费的原因。

继续读：AI Agent 评测体系、Harness Engineering、AI Computer Use。