GPT-6 Astra：分数、推理与实际工作
从测试条件、推理状态与可监控性，理解 GPT-6 Astra 的提升，以及开发者还要负责什么。
上一篇把模型、工具、Agent 和 Harness 的关系重新理了一遍，接下来终于可以看 GPT-6 Astra。
这次发布最容易让人记住的是一组数字：ARC-AGI-3，99.9%。与它摆在一起的 GPT-5.6 Sol 是 7.8%，Claude Opus 5 是 30.2%。光看柱子的高度，确实很容易顺着想到“突然开悟”“AGI 到了”。
但用过一段时间 Codex 后，看到模型更新，最关心的已经变成了几件具体的事：之前要反复提醒的约束，现在还会不会丢；一个问题排查到中途，能不能接着往下做；操作浏览器之后，会不会认真检查结果；任务做不下去时，会不会自行改掉要求，再宣布完成。
这些事情与榜单有关，却不能只用一个分数回答。
飞天闪客的这段视频提醒我去看图表下面的小字。整理时又把本地笔记中的疑问，与 OpenAI 的发布说明、开发文档、系统卡，以及 ARC Prize 自己的测试说明放在一起看。有些质疑因此更明确了，有些原先写得很肯定的话，也需要收回来。
以下资料核对截至 2026 年 9 月 5 日。先记清公开资料能够支持的结论，日常使用中的差异再留给实际任务验证。
1. 官方这次发布了什么
1.1 Astra 是模型，Codex 和 ChatGPT 是使用它的产品
OpenAI 在 9 月 3 日发布 GPT-6 Astra，将重点放在复杂推理、软件工程、计算机操作、科学研究和专业工作上。发布时先向部分组织开放，再逐步扩展到付费 ChatGPT 计划与 API 等渠道。因此，“已经发布”与“每个账号此刻都能选到”之间，还存在开放进度的区别。官方发布说明
这里继续沿用上一篇的区分：Astra 是模型；Codex 提供工作目录、工具、任务执行与检查等工作环境；ChatGPT 则是日常交流、研究和其他工作的产品入口。同一个模型进入不同产品，能拿到的上下文、工具和权限不同，表现也会不同。
API 层面，先记住这些信息就够了：
| 项目 | GPT-6 Astra 的公开规格 |
|---|---|
| 模型标识 | gpt-6-astra |
| 上下文窗口 | 1,050,000 tokens |
| 最大输出 | 128,000 tokens |
| 知识截止日期 | 2026-04-30 |
| 输入与输出 | 文本、图像输入；文本输出 |
| 推理强度 | low、medium、high、xhigh、max |
| 基础 API 价格 | 每百万 tokens：输入 10 美元，缓存读取 1 美元，缓存写入 12.5 美元，输出 50 美元 |
规格与价格来自官方模型页。超过 272K 输入 tokens 的长上下文请求还有额外倍率，输入及缓存相关价格为两倍，输出为 1.5 倍，作用于整次请求；实际使用还要区分处理模式与工具费用。
一百万上下文值得关注，但它首先是容量。把整个项目塞进去，并不等于模型每一步都能准确提取其中的约束。代码是否组织清楚、资料是否过时、任务说明有没有冲突，仍然影响工作结果。
1.2 这次更值得留意的是任务怎样继续
开发文档列出的变化里，有三项很接近日常工作：Astra 模型指南
| 能力 | 放到工作里意味着什么 |
|---|---|
| 异步工具调用 | 某个工具还在执行时，模型可以推进其他独立工作；应用仍负责真正运行工具和回传结果 |
| 执行中调整要求 | 工作进行到一半，可以补充约束或纠正方向，并接着已完成的部分继续 |
| 对话中调整推理强度 | 常规步骤与困难步骤可以采用不同推理投入，文档提供了兼顾缓存的配置方式 |
比如，让 Agent 排查一个上传失败的问题。测试还在跑时，它可以先阅读接口实现；做到一半发现问题只发生在旧客户端，就补充这个范围，让后续检查集中到兼容逻辑。等测试结果回来，再把代码、现象和新约束合起来判断。
这个例子描述的是这些能力可以怎样组合，并不是一次已经完成的 Astra 实测。它吸引我的地方在于：与 Agent 合作时，现实里的需求本来就会逐渐变清楚，工具也不会总在同一时间返回结果。
1.3 “能操作电脑”早就出现过，接下来要看操作质量
在 GPT-5.6 那段时间，已经用过 Codex 配合 Chrome 浏览器能力，让它规划检查步骤、打开页面看真实效果，发现不合适的地方再回到代码里修改。所以单独看到“会点鼠标、会用浏览器”，新鲜感没有那么强。
真正值得继续观察的是，操作过程中少犯了多少错误，能连续处理多长的任务，遇到弹窗或页面变化能不能恢复，以及最后交付的东西是否符合最初要求。
一次成功演示能说明“这条路走得通”。要成为每天都愿意使用的助手，还得看相似任务换几种输入之后，结果是否稳定。对前端开发来说，生成页面只是其中一步；检查窄屏布局、保存状态、错误提示和真实交互，才会逐渐显出助手之间的差别。
2. ARC-AGI-3 的 99.9%，应该怎样读
2.1 它在测学习陌生环境的能力
ARC-AGI-3 把 Agent 放进陌生的二维交互环境。规则和目标没有事先完整告诉它，需要通过操作、观察反馈，逐渐推断什么会发生、怎样推进关卡。这里能看到探索、建模和行动之间的关系。ARC Prize 对测试任务的说明
可以设想一个自编的小机关：画面上有几块不同颜色的板，点击其中一块会让另外两块改变状态。有的操作还会影响下一轮。起初连目标状态是什么都不知道，只能试一次、记下来，再寻找规律。
这种题难在信息不完整。盲目多点几次也许能偶然过关，但一个更好的解题者应该逐渐形成可复用的判断：这个按钮影响哪些对象，哪个变化只是伴随现象，下一步操作能验证哪种猜测。
还要修正一个很容易误读的地方：ARC-AGI-3 的百分数不是普通选择题的正确率。 它使用 RHAE，综合关卡完成情况与相对人类基线的行动效率。单关的效率项与“人类基线操作数 / Agent 操作数”的平方有关，之后还要经过封顶和加权汇总。官方评分方法
例如，同一关人类基线用 12 步，Agent 用 24 步，单关效率项就是 0.25；这只是计算中的一部分，不能据此直接推算整套测试成绩。视频中“人类平均约 48 分”的说法，也不能翻译成“人类只能做对 48% 的题”。
2.2 三个数字不能直接排成一条升级路线
视频里提到，OpenAI 早在 7 月 29 日就做过一个实验：模型仍是 GPT-5.6 Sol，改变上下文处理方式后，成绩明显提高。
回到这篇实验说明，能够对应起来的是下面这组结果：
| 模型与推理强度 | 数据集 | 框架条件 | 得分 |
|---|---|---|---|
| GPT-5.6 Sol，max | ARC-AGI-3 公开任务集 | 原有官方 Harness | 13.3% |
| GPT-5.6 Sol，max | 同一公开任务集 | 保留推理，并使用上下文压缩 | 38.3% |
同一个模型，在这次实验里取得了约三倍的得分，同时减少了输出 tokens。它说明运行方式会显著影响能力发挥。
但整理笔记时，不能顺手把它写成：
7.8 → 提高推理强度得到 13.3 → 换框架得到 38.3 → 换成 Astra 得到 99.9。
这条线太顺了，也因此容易让人忽略条件。13.3 和 38.3 对应的是公开任务集实验；Astra 后面要讨论的 99.9，则有 ARC Prize 的 Semi-Private 测试结果。把不同任务集、不同推理配置和不同框架下的成绩接起来，不能得到一次逐项控制变量的实验。
视频截到的发布图小字还提到，Sol 使用那类框架时，估计可以达到约 30%。这里写的是估计，也不是把公开集的 38.3 原样搬到了另一个数据集。发布图将不同条件的结果摆在一起，确实值得提醒；进一步计算“真正的智能到底涨了多少”，就超出了这些数字能回答的范围。
2.3 ARC Prize 已经把两种 Harness 分开列出
继续查资料，发现不必只在发布图的小字上争论。ARC Prize 自己已经公开了 Astra 在两套框架下的成绩。
按照其测试政策，Standard 提供统一、尽量不依赖厂商特性的接口，允许模型选择并携带可见笔记；Provider Adapter 则使用厂商提供的上下文管理能力，包括延续不透明推理状态和压缩长对话。两者回答的是不同问题：统一条件下能做到什么，以及配合厂商能力后能做到什么。
下面固定为 Astra 和 Semi-Private 数据集，切换推理强度，看同一档位下的结果。
01 / 把测试条件展开
同一个 Astra，换一套 Harness
固定模型与 Semi-Private 数据集，选择相同的推理强度对照两种框架。
这些差异属于具体测试配置的结果，不能拆成可以通用于其他模型的“智能分”和“框架加分”。
数据：ARC Prize 结果页及其 2026-09-03 分析。成本为该配置整组测试的 API 费用，不是单次提问价格；分数不是答题正确率。
默认选中的 high 档是 54.8% 与 99.9%；切到 max 则是 62.7% 与 98.6%。所以“Standard 最佳 62.7%、Adapter 最佳 99.9%”这句话虽然成立，两个最佳值的推理档位也并不相同。比较时最好把这一层一并展开。完整结果
这些成绩足以支持 Astra 取得了显著进展。它们也再次说明，实际测到的是模型在某种运行条件下完成任务的表现。框架保存的信息能否被模型有效利用，本身就与模型能力有关。
因此，不能把柱形图切成“推理强度贡献多少”“框架贡献多少”“适应答题模式贡献多少”，最后留下一个叫“纯智能提升”的色块。要做这种归因，需要专门设计的对照实验，目前这些公开数字不够。
2.4 ARC-AGI-3 的高分与 AGI 的距离
ARC Prize 的分析记录了一个值得关注的现象：Astra 能把陌生游戏整理成紧凑的符号化状态和规则，再用这些表示规划操作。比起记住 99.9 这个数字，这种从反馈中建立可用模型的能力，更接近我关心的进步。
不过，ARC Prize 同一篇文章也明确表示，他们并未据此宣称 Astra 已经是 AGI。测试环境有明确边界、确定的机制和相对封闭的目标，现实工作还包含模糊需求、利益冲突和持续变化的条件。ARC Prize 的分析与 AGI 边界
“能解决一批原来解决不好的陌生任务”，是一个具体而重要的结论。进一步说它能学习任何工作、在任何环境中长期可靠地行动，还需要另外的证据。
3. Responses API Harness，究竟补上了什么
3.1 API 与 Harness 不是同一个东西
Responses API 是调用模型并组织输入、输出和工具交互的接口；Harness 是围绕模型执行任务的那套程序。所谓 Responses API Harness，可以理解为使用这个接口搭建的执行框架。
接口提供能力，框架决定怎样使用。例如，把工具结果交回模型时是否延续前面的状态，对话太长时如何处理，失败后如何继续，都需要具体的执行逻辑。仅仅更换 URL，并不会让一个 Agent 自动具备完善的状态管理。
对准备接入 Astra 的应用，还有一个实际区别：当前开发指南注明，模型虽然支持 Chat Completions，但工具调用需要使用 Responses。接口迁移说明
3.2 操作记录、推理状态、长期记忆，要分开看
排查问题时，经常会出现这种差别：日志里写着“查询了数据库，返回零条”，但没有记录为什么查这张表，也没有记下已经排除的假设。下一位接手的人仍然能工作，只是需要重新恢复这些判断。
模型的连续调用也有类似问题。用户消息、工具调用与工具结果，是可见的交互历史；模型还可能使用推理项来延续先前的工作。OpenAI 的推理文档说明了如何通过响应链或回传加密推理项保留这类信息。
这里的“保留”，不表示开发者能拿到完整、可读的私有思维链，更不能把它当成大脑活动的逐字实录。它说的是下一次推理是否还能使用之前的相关状态。
为了避免把所有东西都叫“记忆”，可以先这样区分：
| 保存的东西 | 例子 | 应该怎样理解 |
|---|---|---|
| 业务状态 | 当前订单、审批结果、已完成的步骤 | 应用能够读取、校验和持久化的数据 |
| 交互历史 | 用户要求、工具结果、已发送的回复 | 对话和操作发生过什么 |
| 推理状态 | API 提供的相关推理项 | 帮助模型延续工作，可能是不透明的 |
| 长期资料 | 项目约定、用户偏好、知识库文档 | 跨任务需要保留并按需取用的信息 |
保存了聊天消息，不等于保存了全部推理状态；保留了推理状态，也不等于项目资料已经可靠入库。
3.3 压缩，是为了在有限上下文里继续工作
长任务还有另一个问题：工具持续返回文件、日志和页面信息，上下文会越来越大。如果只是删除最早的消息，早期确认的约束和排查结论也可能一起消失。
Compaction 会把先前上下文整理成更紧凑的后续输入。OpenAI 提供的压缩项可以是不透明、加密的状态，并不一定是一段供人阅读的文字摘要。Compaction 文档
下面用排查重复订单演示“历史怎样留下来”。为了能直观看懂，图中使用可读的工作记录，并不展示真实模型的思维链。
02 / 继续工作时，手里还剩什么
排查到一半，历史日志越来越长
原创机制示意。下方是便于阅读的工作记录，不代表模型真实的私有思维链。
同一笔订单偶尔被写入两次，先保留问题和约束。
只保留最近记录
容量不足时，较早消息被移出
如果没有把关键结论转存到后续记录，早期信息就有丢失风险。
压缩成可继续使用的状态
提炼任务、约束与下一步
目标是让后续步骤继续使用已获得的信息。
图中仅演示上下文取舍，不模拟真实 token 数或成功率。保留推理与上下文压缩是两项相关但不同的能力；压缩也可能丢信息，应用仍应保存原始证据。
这个变化没有新增一条业务规则，却可能减少重复排查。一次工具调用前已经分析过的事情，后面有机会继续利用；长日志占满窗口时，也尽量保住任务和结论。
同样，压缩无法保证零损失。对开发工作来说，关键约束、原始日志、代码版本和验收结果仍然应该有可查的出处。摘要负责帮助继续工作，原始材料负责让结论能够被重新检查。
看完这一段，再回头看上一篇的 Harness，含义就具体多了。除了接工具、重试和循环，它还在决定：模型每次继续时，究竟能看到哪些已经获得的信息。
4. “更对齐”与“更难监控”，可以同时发生
4.1 先把三个问题分开
发布说明里的另一个关键词是对齐。放到实际任务中，可以先理解为：理解合理的用户意图，遵守授权范围，不为了完成表面指标去欺骗、越权或破坏。
但读到系统卡的可监控性部分时，就不能再把“更听话”“更安全”“更可控”直接当成同义词了。
| 问题 | 关心的对象 | 开发任务中的例子 |
|---|---|---|
| 对齐得怎样 | 实际行为是否符合意图和约束 | 修复功能时，有没有自行删除验收条件 |
| 能否监控 | 出现问题时，能不能发现 | 是否能从调用记录、代码差异或推理信息发现异常 |
| 能否干预 | 发现问题后，能不能限制和停止 | 工具是否有权限边界，任务是否能中止，改动能否撤回 |
一个系统可能更少违规，但一旦违规，留下的文字线索更少；也可能很容易被看出在违规，却已经拿到了过大的操作权限。这些情况不能由一个总分代替。
4.2 系统卡报告了什么
OpenAI 的系统卡第 9 节报告：相较 Sol，Astra 的思维链可监控性下降，控制自身 CoT 表达的能力增强。在某些测试中，知道存在监控会使它缩短推理文本；对抗测试还发现了规避监控的能力。这类发现有具体实验条件，不能扩展成“每次正常使用时，它都在故意隐瞒”。
这里也容易误解 CoT controllability。它主要指模型对自身推理文本的控制能力，并不是“人类更能控制这个模型”。如果用于监控的线索更容易被省略或改变，监控者对这段文字的信任自然需要重新评估。
这会让人联想到《三体》里思想能否隐藏的问题。但这个联想只能帮助记住风险，不能证明模型有了类似人的内心，更不能把屏幕上的解释当成它全部计算过程的透明窗口。
4.3 不能据此断言：对齐变好只是因为更会藏
最初整理笔记时，很容易顺着写下这句话：既然更难看出违规，那么对齐图表上的改善，是否只是因为问题被藏起来了？
这个怀疑值得提出，但目前不能把它写成已经证实的原因。
先看一个假设例子。100 次任务中，有 10 次发生违规，检测系统识别出 8 次。后来告警变成 4 次，可能是违规真的减少了，也可能是监控漏掉了更多问题。只知道“8 变成 4”，无法判断是哪一种。
03 / 告警数字为什么会下降
同样是 4 次告警，实际情况可能不同
假设的 100 次任务，只讨论漏报，暂不加入误报。以下数字与 Astra 实测无关。
100 次任务中有 10 次真实违规，监控发现其中 80%。
告警量同时受行为和检测能力影响。判断对齐是否改善，需要看实际行为与评估方法，不能只看告警计数。
现实评估还要加入误报、任务难度、违规严重性和检测器版本，情况会更复杂。要判断某个对齐结果有没有被可监控性变化影响，就得看它具体在数什么：任务中的真实动作、工具日志、人工审查结果，还是某个检测器给出的标记。
OpenAI 的安全概览同时报告了对齐改进和监控困难：在超过 54,000 个内部 Codex 任务的模拟中，Astra 收到的较高严重性失配标记约为 Sol 的一半；官方整体评估认为它更遵守安全和授权边界，同时承认可监控性下降，并扩大对工具使用过程的监控。
这仍然是有范围、有方法的评估结果，不是所有未来任务的保证。不过，要反驳它，也需要相应证据。仅凭另一节写着“监控变难”，还无法计算其中多少改善来自行为变化，多少来自检测变化。
视频提醒去读系统卡，这一点很有价值；视频中的进一步解释，也应当接受同样的追问。
4.4 对日常开发有什么影响
最直接的影响是，验收不能只看 Agent 最后写的那段话。
例如，让它修复一个导出问题，并要求保留现有测试。最终回复说“修复完成，全部通过”，还要看代码差异和实际测试结果：是不是修好了实现，还是把失败断言改宽了；导出的文件是否真的能打开，还是只生成了一个看起来正确的文件名。
这些检查有具体的对象，比要求模型多写几段“我认真检查过了”更有用。工具权限也一样：只需要修改本地工作目录的任务，就让它在这个范围内工作；发现方向不对时，能够停下来并恢复改动。
另外，安全概览将 Astra 的网络安全能力评为其 Preparedness Framework 下的 Critical。这是在一定工具与访问条件下的能力评级，不是说模型已经被判定会主动进行恶意操作。能力越强，授权范围和运行环境越需要认真设计。
5. 怎样把 Astra 放进日常工作
5.1 成本应该按任务计算
看完规格表，第一反应仍然是：不便宜。
但只比较每百万 tokens 的价格，容易漏掉重复尝试。便宜模型如果反复走错方向、生成大量无用代码，再让人收拾，最后的成本未必低；贵模型若能减少调用和返工，也可能在某些复杂任务上更合算。
ARC 的结果就提供了一个具体例子：同在 Provider Adapter 下，max 的整组测试费用低于 high，但分数也并非完全一样。这是那批任务的观察，不能推广成“推理档位越高越便宜”。
落到自己的工作，更值得记录的是：完成一项合格任务的总调用费用、等待时间，以及人花在修订和验收上的时间。三者最好分别记，不要为了凑成一个数字，随意给所有人工时间套同一种价格。
至于“模型编码能力已经到了天花板”，现在也不太愿意这样写。某一套测试接近满分，只能说明它区分模型的余地变小了。接手陌生仓库、理解历史约束、修改跨模块行为，以及维护几个月后的代码，都还包含新的问题。
5.2 小模型做常规工作，大模型处理复杂情况
把所有任务都交给最强模型，并不是我想尝试的使用方式。更感兴趣的是，让模型强度与任务难度相匹配。
以客服辅助流程为例，可以先做成下面这样：
规则能够确定的，先由程序处理。
查询订单状态、校验工单字段、判断是否缺少必要信息，不必每次都让模型推理。
常规文字处理交给成本合适的小模型。
例如识别问题类型、从对话中提取订单号、根据检索到的政策草拟回复。这里是否适合本地部署，要看设备、并发和实际效果。
出现复杂关系或证据冲突，再交给强模型。
例如一个投诉涉及多次退款、不同版本的政策和前后矛盾的沟通记录。把已整理的事实、来源与待解决的问题一起交过去。
涉及实际权益变更，走明确的业务流程。
模型可以分析和提出方案，真正执行退款、修改账户等动作，仍由系统按授权与审核结果处理。
这里的分流条件需要验证。不能仅仅因为小模型说“我有九成把握”，就认定它适合直接处理；可以结合字段校验、资料是否命中、证据是否冲突，以及人工抽样结果来调整。
本地小模型也不是零成本，还要算设备、部署和维护。它吸引我的地方包括响应时间、数据流转方式和可调整空间，是否合算仍然要放到具体业务里看。
5.3 Codex 继续作为主要助手，验收标准也要跟着升级
个人还是更喜欢 OpenAI 这套使用体验，ChatGPT 用来讨论和梳理，Codex 接着处理能够落到文件、代码和环境里的任务。
Claude 的能力值得认可，但账号可用性的体验会影响长期使用的意愿。一个工具再强，如果使用连续性让人不放心，也很难成为每天工作的主要入口。这是个人选择，不是给全部编码 Agent 排一个永远有效的榜。
Astra 值不值得成为默认模型，我会从已有工作里挑任务比较：同一个需求、同一份项目状态、同一套验收要求，看看是否更少漏约束、更少需要重复解释，以及是否少了无关改动。已有工具链能做的事情，先保留基线，才看得出升级到底改变了什么。
6. 模型越来越强，开发者的能力体现在哪里
6.1 实现更快之后，判断错误也会放大
笔记里收录了吴恩达的 AI Engineering Skills Map。它把 AI 应用构建与部署、软件工程基础、编码 Agent 的使用，以及决定做什么这几类能力放在一起。软件工程基础并没有随着代码生成变快而消失。Andrew Ng 的系列文章入口
以前，一个错误的设计可能需要写到一半，才逐渐暴露出不合理。现在 Agent 很快就能把它完整实现，页面、接口和测试一应俱全，反而容易让人觉得方案已经成立。
这时，能够读懂代码还不够，还得知道为什么采用这个数据模型，状态应该由谁维护，哪些约束不允许破坏，以及当前结果是否真的解决了问题。
比如给一篇博客增加预览图，Agent 很容易把图片生成出来、路径写对、构建跑通。但预览卡片的图片高度与摘要高度是否协调，正文图片有没有撑得太高，手机上会不会裁掉主体，这些要求如果没有进入验收范围，技术步骤全对也可能得到一个不合适的结果。
这样的判断并不玄乎，就是对最终使用场景足够熟悉。
6.2 工作重心会向需求和验收两端移动
如果把一次开发拆开看，中间有大量可以交给 Agent 推进的实现工作。人需要花更多精力把前面的需求、范围和取舍说明白，再把后面的结果检查清楚。
这里并不是说“人只负责开头和结尾”。任务过程中出现新情况，仍然需要讨论和调整。模型越能独立完成中间步骤，越值得提前把重要约束和验证方式准备好，否则只是更快地执行了一个含糊要求。
6.3 程序员和演员，为什么总出现在 AI 替代的讨论里
笔记中留了一个问题：是不是因为这两种职业都能通过学习和训练获得能力，所以容易被 AI 影响？
这个解释太宽了。多数职业都能学习，不能因此判断它们受到影响的程度，更没有足够依据断言程序员与演员就是“受影响最大的两个职业”。
就自己接触的软件与影像工作而言，更容易观察到的共同点，是不少输入和产物本来就在数字环境中：代码可以修改、运行和比较；图像、声音和片段可以生成、剪辑和组合。部分环节适合反复尝试，成功案例也很容易被展示出来。这是对现象的理解，不是完整的就业影响研究。
与此同时，一段代码通过测试，不等于整个产品值得做；一张人物图足够漂亮，也不等于角色成立，更不等于一部作品完成了表达。被自动化的是哪些工作环节、谁在承担最终结果，需要分开讨论。
7. 对国内模型和开源路线的期待
日常更喜欢用 ChatGPT 和 Codex。从长期做应用的角度，更看重国内模型与开放生态能发展到什么程度，尤其关注 DeepSeek 所代表的开放路线。除了模型，也会继续留意其公开的工程项目。
对个人开发者来说，最希望看到的是：能力足够好，成本能够承担，部署和调整有选择，项目不会因为某一家服务变化就无处可去。如果开放模型能逐步覆盖更多实际任务，它带来的价值会远超过榜单上挪动几个名次。
最初的笔记里还把电力、用户规模、资金和团队稳定性放在一起，想判断未来谁会领先。这些都是可以继续研究的因素，但目前不适合据此断言“某一家追上，其他公司就都没机会了”。基础设施优势需要转化成可用算力，用户规模也不会自动变成高质量训练反馈；产品、研究、成本和服务能力仍然要分别看。
至于具体公司的资金是否充裕、估值调整是为了什么，没有可靠依据的动机判断就先不写进结论。继续关注开源路线的理由很实际：希望以后做应用时，有更多能长期使用的选择。
8. 笔记里剩下的两个问题
8.1 Opus 5 的 30.2 乘以三，是不是也接近 90 分
不能这样算。顺便更正一个小数字：视频发布图里是 30.2，并不是笔记问题中写下的 30.3。
Sol 的约三倍提升，是一个特定模型在特定公开任务集上，从一种上下文处理方式切换到另一种方式后的观测。原来的主要限制是什么，模型能否利用新增状态，新的框架与它的训练方式是否匹配，都会影响结果。
换成 Opus，即使也能保留相关推理信息、使用压缩，也不意味着它原来损失了同样多的能力。假设某个模型本来就很擅长把重要结论写进可见笔记，增加另一种状态保留机制后，收益就可能与另一个模型不同。
还要记住 ARC 的分数有非线性的效率计算和上限。增加一次探索是否恰好帮助突破后续关卡，可能产生很不一样的结果。固定乘数既没有实验依据，也不符合这种评分的使用方式。
要回答 Opus 使用适配框架后的成绩，需要实际测试：固定数据集，明确推理配置、工具与预算，公开运行结果。现在可以提出这个问题，不能先把 90 分算出来当答案。
8.2 Agent 本来就维护 State，为什么还需要厂商保留推理
这个问题很接近应用开发者的直觉：不是已经能把消息和状态写进数据库了吗？
以 LangGraph 为例，checkpointer 保存线程内图状态的检查点，store 保存跨线程的长期数据。它们能支持继续对话、恢复执行，以及保存应用定义的信息。LangGraph 持久化文档
但框架只能可靠处理它能拿到、并被要求保存的内容。如果模型还使用了 API 层的不透明推理状态，把 messages 数组原样存下来，并不能自动重建那部分信息。一个是应用的状态管理，另一个是模型延续推理所需的接口能力，两者可以配合。
如果更多厂商提供类似能力，开发当然会省下一部分维护连续上下文的工作。不过，订单是否已经提交、审批是否生效、上一步写入是否成功，这些业务事实仍要由应用负责；模型的推理状态不能代替数据库事务，也不能代替审计记录。
还有一个需要修正的前提：提供商支持保留推理，不代表所有历史都必须永远存放在提供商服务器上。OpenAI 也支持无状态请求，由调用方保存并在后续请求中回传加密推理项。无状态保留推理的说明
至于提供商为什么愿意做，可以从产品和工程上理解：它更了解模型如何使用上下文，有机会把训练方式与接口衔接得更好；减少反复恢复状态，也可能节省整项任务的推理开销。这是对设计动机的推断，不是替厂商解释某个内部商业决策。
资源并没有凭空消失。保存、传输、压缩和后续推理仍有开销，接口也有对应计费与限制。用户获得的是更完整的服务，而不是无限免费记忆。
对自己的应用，更稳妥的做法是把可读、可校验的项目资料与业务状态留在应用侧，再使用厂商能力帮助模型继续工作。以后更换模型时，至少核心事实和任务进度仍然能够重新组织。
9. 下次看模型发布，先把哪些东西留下来
视频最后谈到信息在传播中的损失，这一点也值得放回自己的写作里。系统卡到了发布博客，再到摘要和转述，条件很容易越来越少，形容词却越来越多。
尤其是数字。一句“达到 99.9%”很好记；数据集、框架、推理档位、评分方法和成本不够醒目，却决定了这句话应该怎样理解。把它们删掉之后，文章可能更流畅，读者得到的判断却未必更准确。
这次将公开集实验与 Semi-Private 结果放回各自的表格，把对齐行为和监控结果分开，原先连在一起的几个判断才逐渐清楚。以后再看到类似的发布图，也可以沿着这些位置回去查。
接下来准备从一个熟悉的接口修改任务开始比较 Astra，沿用现有验收要求，同时检查旧调用方和页面效果。需要补充哪些说明、在哪一步重新接手、最后还要改多少，都记进任务记录里。
参考资料
- 飞天闪客：GPT-6 Astra 信息背面，真的提升这么大吗？，视频线索与讨论起点。
- OpenAI：GPT-6 Astra 发布说明、模型规格、开发指南。
- OpenAI：保留推理与压缩的 ARC-AGI-3 实验、推理状态、上下文压缩。
- ARC Prize：Astra 测试结果、测试分析、测试政策、RHAE 评分方法。
- OpenAI：安全概览、完整系统卡，重点参照对齐、可监控性与运行防护部分。
- LangChain：LangGraph 持久化。
- Andrew Ng：AI Engineering Skills Map 系列入口，结合笔记中保存的技能图阅读。