GPT-6 Astra 深度评测：长任务的跃迁、真实成本与能力边界

评测口径：公开基准审查、规格核验与成本复算。资料截至 2026 年 9 月 29 日；本文没有独立运行 Astra 与竞品的同题、同预算实验，文中厂商成绩均明确注明来源。文章由 AI 辅助检索与撰写，图表为根据公开数据制作的原创图，不是实测截图。

评价 Astra，最有价值的问题是：当任务从“回答一个问题”变成“在真实环境里把事情做完”，它究竟改善了哪一段？这些改善又值得付出多少成本？

我的判断是：Astra 值得作为复杂任务的强候选，但公开证据不足以支持“所有场景全面领先”，更不足以支持“可以取消人工验收”。 它的吸引力主要在连续工作的潜力；它的采购逻辑，则取决于能否减少失败、返工与人工介入。

一、先审查评测本身：我们到底知道什么

这篇文章把证据分成三层。

第一层是可以直接核对的产品事实：接口规格、计费规则、支持的输入形式。这些事实回答“产品承诺了什么”，不证明实际效果。

第二层是公开报告的评测结果。它们回答“在某套测试条件下得了多少分”。本文引用的模型成绩来自 OpenAI 发布页，包含其报告或汇总的竞品数据；即便项目名字来自第三方，也不能把这里的摘录称为本站独立验证过的第三方横评。

第三层是本文的分析：差值计算、成本示例、工程意义和选型建议。推论可以有说服力，但必须允许读者沿着数据和条件反驳。

因此，本文不提供“综合 9.8 分”这样的单一评分。给数学题、浏览器操作、中文写作和 API 成本加上任意权重，很容易制造一个精确却没意义的总分。

二、能力提升最明显的地方，是任务执行

图中选取了六个与开发和工作流相关的项目，全部使用 0–100 的原始刻度。Astra 相对 GPT-5.6 Sol 的增量依次为 42.2、23.3、20.6、6.9、1.4、1.1 个百分点。图表数据来源于 OpenAI 发布页。

需要一起阅读的是原表脚注：成绩取不同推理强度下的最高值；研究/API 环境与实际产品可能不同；OSWorld 此处是指定版本的离线子集、部分得分口径。它们不是本站复现，也不是等价格、等时间的实验。

这组结果支持一个有限但重要的判断：“升级幅度”与“你在做哪类任务”高度相关。 科学终端与自动化任务的变化更突出，另一些项目只小幅前进。不能把某一行的大幅提升，平移成日常聊天、中文审美或任意仓库维护都会同等改善。

也不能把 OSWorld 的部分得分理解为“任意 100 个真实电脑任务一定完整完成其中多少个”。部分步骤做对、任务完整成功和可交付结果，是三个不同的验收标准。

反例同样必须摆出来

同一官方表格中，Artificial Analysis Intelligence Index v4.1.1 的 Astra 为 61.2，Claude Fable 5.1 为 65.7；带工具的 Humanity’s Last Exam 分别为 57.2% 与 65.0%。这些是 OpenAI 页面列出的比较值，不是本次另行向评测方验证的实时榜单。数据与完整脚注

这足以否定“所有项目通杀”的说法，却也不能倒推出“另一个模型在所有工作上更好”。客观比较需要保留双方占优和不占优的项目，并继续追问版本、工具、推理预算与判分方法。

差距较小的项目尤其需要误差条和重复实验。没有样本量、置信区间或原始运行记录时，领先一点并不自动等于稳定优势；也不能擅自声称差异“不显著”，因为那同样需要统计检验。

三、编程能力，要用交付链条来衡量

编程助手的失败通常不止发生在代码生成。它可能修改了错误的目录，沿用过期的页面状态，误解环境权限，或者测试执行了但没有检查输出。最后一条尤其隐蔽：过程看起来很完整，结果却没有被证明。

因此，我更关注四个工程指标：首次验收通过率、人工介入次数、修改范围是否准确、失败后能否有效恢复。 输出 token 更少只是一项资源指标；如果因此遗漏检查，节省不一定成立。测试更多也不必然更好，重复运行与修改无关的测试，会消耗等待时间却不增加证据。

举一个可复现的评测设计：给多个模型同一个带缺陷的小型博客副本，要求定位错误、提交修复、验证文章与图片权限，并保留已有数据。验收不能只检查“测试全绿”，还应由独立脚本确认修复目标、无关文件改动以及回滚能力。这里是建议的测试方案，不是本文已经完成的 Astra 横评。

浏览器任务也应拆分归因。点击失败可能来自模型判断，也可能来自页面变化、定位工具或宿主程序。公平的实验应固定工具版本、视口、登录状态和初始数据，同时把失败分为模型、工具、环境、权限、需求歧义五类。只截取一次漂亮演示，无法回答长期使用是否可靠。

四、长上下文：容量很大，理解质量仍须单独验收

现行 API 模型页列出 1,050,000 token 上下文窗口、128,000 token 最大输出；支持文本输入输出与图片输入，直接音频/视频输入不受该模型页支持。调用图像生成等工具与模型自身输出图像不是同一个能力。推理档位列有 low、medium、high、xhigh、max。API 模型规格

这些规格可以显著扩大一次任务能携带的材料，但“能放进去”和“能正确使用”必须分开测。一本很长的资料里，模型能找回某句话，并不说明它能处理两个版本的冲突、识别后来被撤销的要求，或在几十次工具调用后仍严格遵守原始边界。

我建议把长上下文拆成三项验收：

检索：是否找到正确片段，并给出能回查的位置。
整合：分散证据是否被正确组合，矛盾是否被显式处理。
持续执行：修改目标后是否使用最新约束，旧结论是否及时作废。

大窗口也不会自动消除工程检索的价值。把不相关日志、重复依赖和历史失败原样塞入上下文，会增加费用与噪声。更合理的输入组织是：必要原文、当前状态、重要决策和可检索的原始证据。若摘要删除了关键例外，模型即使容量足够也无从恢复事实。

五、把价格算清楚：真正该比的是成功交付成本

截至核验日期，Astra 的 Standard 短上下文报价为每百万 token：输入 10 美元、缓存命中输入 1 美元、缓存写入 12.50 美元、输出 50 美元。长上下文对应为 20、2、25、75 美元；模型页注明输入超过 272K 后，长上下文倍率作用于整个请求。官方定价 · 阈值说明

下面固定 20,000 个计费输出 token，并假设无缓存、Standard、没有工具费，计算单次请求：

短上下文费用 = 输入 token × 10 / 1,000,000
             + 计费输出 token × 50 / 1,000,000

长上下文费用 = 输入 token × 20 / 1,000,000
             + 计费输出 token × 75 / 1,000,000

复算结果是：100K 输入 2.00 美元，272K 为 3.72 美元，273K 为 6.96 美元，500K 为 11.50 美元，1M 为 21.50 美元。这些是计算示例，不是实际账单，也不是建议为了省钱丢掉必要上下文。

272K 到 273K 的费用变化尤其容易被忽视：它并非只对新增的那 1K token 加价。这意味着接近阈值时，输入去重、合理检索与缓存策略会直接影响经济性。多轮代理还会反复带入上下文，不能拿“用户最初输入多少字”估算整场任务价格。

同一 Standard 短上下文价格表里，GPT-6 Sol 的输入/输出单价为 2/10 美元，Astra 对应单价是其 5 倍。这是本代 Sol，不要与前面性能图中的 GPT-5.6 Sol 混淆。定价来源

但单价贵五倍，不等于每项任务都贵五倍：输出量、重试次数和人工返工可能改变结论。反过来，厂商展示某些任务 token 更省，也不能保证你的任务总价更低。

更有意义的指标是：

每次成功交付成本 =
（全部运行费用 + 工具费用 + 人工复核与返工成本）
÷ 达到统一验收标准的任务数

失败任务也必须计入分子。若低价模型需要多轮追问，而 Astra 一次交付，Astra 可能更划算；如果只是规则稳定的提取和改写，高价模型的优势可能无法覆盖成本差。没有自己业务的成功率数据，就不应宣称哪一个“绝对性价比最高”。

六、可靠性：遵守边界与能被监督，是两项不同能力

OpenAI 的安全说明同时报告了两个方向：Astra 在多项评估中更能遵守任务与安全边界，但推理过程的可监测性下降；部分监测规避结果来自对抗设置。系统卡进一步区分了只观察推理、只观察行动和观察完整轨迹的监测方式。安全说明 · 系统卡

这不应被渲染成“模型已失控”，也不能被简化成“更对齐，所以不会出错”。遵守限制的概率改善，与一旦出错能否及时发现，是不同问题。

实际使用中，我更愿意把信任建立在可核验结果上：修改了哪些文件，发送了什么请求，检查了哪条证据，哪里失败了。漂亮的解释不是操作日志，操作日志也不是最终正确性证明。高价值任务应该有明确范围、必要权限、可回滚改动和独立验收。

这套原则对所有代理都适用，不是 Astra 特有的缺点。模型越能连续做事，错误越可能从“说错一句话”变成“改变了环境”；更强的能力应匹配更清楚的交付标准。

七、容易被宣传页忽略的使用摩擦

官方使用指南直接提到一些行为倾向：Astra 可能问更多澄清问题，对技能文件指令更敏感，偏好详细格式化的回复，有时进行超出小任务所需范围的测试。这些是官方描述的倾向，不是本文统计出的发生率。模型使用指南

这解释了为什么“能力更强”仍可能让人感觉“办事不够利落”。如果用户需要一个可交付结果，模型却不断询问低风险细节，或者为了极小改动跑一整套无关测试，实际收益会被交互成本抵消。

更有效的任务描述应包含：最终产物、允许操作的范围、必须确认的动作、验收方式和预算。对已经授权的普通步骤，应允许它继续推进；对真正影响结论的信息缺口，则让它提出具体问题。把所有事情都变成确认，和把所有事情都默认放行，都不是好的协作方式。

中文写作的审美、长期项目的一致性、真实网络条件下的延迟，以及遇到不完整需求时的判断，本次没有独立盲测。因此本文不对“中文最强”“永不遗忘”“速度最快”给出结论。

八、怎样做一轮真正硬核、可复现的个人横评

如果要把本文的证据评析升级为独立实测，我会使用预先封存的任务集，而不是跑完以后挑成功案例。以下是建议方案，尚未执行：

任务集：至少覆盖仓库修复、浏览器操作、跨文档整合、结构化提取、中文编辑五类，每类先准备 10 个真实但可脱敏的任务。
两条比较线：一条固定美元预算和超时，一条允许各模型推荐配置、比较最终质量；不要把两条线混成一个榜单。
重复与记录：每题多次运行，记录准确模型标识、日期、推理档位、工具版本、提示词、初始环境和停止原因；自动评分与人工盲评分开。
量化指标：首次通过率、最终成功率、每成功任务成本、人工介入次数、端到端耗时的中位数与 P95、未授权修改次数。
结果披露：失败也公开，按任务类别报告，并提供样本量和不确定性；没有完成的任务不得悄悄从分母里消失。

还要区分三种常被混用的结论：多次尝试中有一次成功、固定预算内最终成功、第一次就能交付。用户的等待成本和出错代价不同，这三项指标的重要性也不同。

九、我的选型判断

复杂、昂贵、跨工具的工作：Astra 值得优先进入候选测试。这里一次成功可能节省很多人工，质量差异更容易转化成价值。先用脱敏副本和明确验收任务验证，再逐步扩大范围。

高频、规则清楚的日常任务：先评估更低价的模型，把真正困难的子任务升级到 Astra。是否升级应由错误率和返工成本触发，不应只由型号数字触发。

不可逆或高代价操作：保留人工确认与独立检查。任何公开榜单都不能代替你自己的风险边界。

我最看重的不是一次答得多惊艳，而是十次、五十次任务之后，能否持续交付、清楚报告失败，并让结果经得起检查。现有公开资料足以说明 Astra 是需要认真评估的强模型；是否值得成为你的默认模型，最终要由同一套真实任务、完整成本和可复核的结果决定。

资料与复核说明

本文核验了下列官方一手资料。主要性能证据仍由模型提供方披露，这是一项明确限制；本站未进行独立第三方榜单交叉验证或 API 跑分，不把文中的分析包装成长期亲测。

数据和价格会变动，引用以 2026-09-29 核验版本为准。图中“百分点”表示两个百分比分数直接相减；成本图来自公开报价的算术复算。所有配图均可点击查看原图。