OpenAI刚刚发布了GPT-6 Astra。按照公司自己的Preparedness Framework，这是AI历史上第一个触发”关键”（Critical）网络安全阈值的模型。

而这家公司的选择，是把它发布出去。

这不是一件简单的事。要理解它的含义，需要先理解那条线是如何被画出来的，以及穿越它意味着什么。

一个100%的分数，意味着什么

在ExploitBench这个专门测试AI漏洞利用能力的基准测试中，GPT-6 Astra拿到了满分：100%。

为了让这个数字有具体含义，先看前代模型的表现。GPT-5.6 Sol（Astra的直接前代）的ExploitBench得分是78.5%。这个差距，在网络安全领域的意义非同寻常——78.5%和100%之间不是20个百分点的差距，而是”大多数时候能找到漏洞”和”总是能找到漏洞”之间的差距。

还有一个更能说明问题的测试：OpenAI用近三个月内公开披露的真实漏洞来测试Astra，看它能否自主发现新的零日漏洞——不是从训练数据中召回已知漏洞，而是独立发现此前未知的安全缺陷。

结果：Astra找到了2个此前未知的零日漏洞。OpenAI已经将这两个漏洞通知了相关软件厂商。

在ExploitGym这个更广泛的漏洞开发基准测试中，Astra的成功率是42.4%，而GPT-5.6 Sol是30.3%——而且Astra使用了更少的输出token就达到了更高的成功率。

这些不是理论上的数字。这意味着一个人工智能系统，在没有人类明确指令的情况下，能够：识别真实软件中的安全漏洞，开发出可用的利用工具（proof-of-concept exploit），并在公开披露之前独立发现新的零日漏洞。

这是2026年9月，现在，已经在付费用户手里可以访问的能力。

基准测试的局限性与可信度争议

值得注意的是，ExploitBench本身并非没有争议。部分安全研究人员指出，基准测试的题目设计、难度分布和评分标准，直接影响了”100%”这个数字的实际含义。行业观察人士普遍提醒，AI漏洞利用基准测试存在”测试集泄露”（benchmark contamination）的风险——即模型在训练阶段可能已经间接接触过类似的漏洞样本，导致测试成绩虚高。

OpenAI在其技术报告中承认了这一局限，并特别强调了”零日漏洞发现”测试的设计初衷：使用近三个月内才公开披露的漏洞，正是为了最大程度地排除训练数据污染的可能性。但即便如此，”三个月”这个时间窗口是否足够，仍然是一个开放性问题。

更重要的是，从”能在受控测试环境中发现漏洞”到”能在真实生产环境中发动有效攻击”，中间还有相当大的工程距离。安全研究界普遍认为，AI系统在真实攻击场景中面临的噪音、干扰和对抗性防御，与基准测试环境有本质区别。这并不意味着Astra的能力不值得警惕，而是说，”100%的ExploitBench得分”需要被放在正确的语境中理解：它是一个严重的警示信号，而不是一个精确的现实威胁量化指标。

尽管如此，2个真实零日漏洞的发现，是无法被”测试环境局限性”所稀释的事实。这是在真实软件中，由AI系统独立完成的安全研究工作——无论如何定义”局限性”，这个事实本身已经足够说明问题。

从更宏观的视角看，ExploitBench 100%得分的历史意义在于：它标志着AI系统在网络安全攻击能力上完成了从”辅助工具”到”自主行为者”的跨越。此前，安全研究界的普遍预期是，AI系统在可预见的未来仍将停留在”辅助人类安全研究员”的角色——提供建议、加速分析，但不能独立完成完整的漏洞利用链。Astra的出现，提前打破了这个预期。多位AI安全研究员指出，这一转变构成”网络安全威胁格局的结构性变化”，并认为这将使网络攻击的门槛大幅降低，因为此前需要顶级安全专家才能完成的工作，现在可以通过AI系统以更低的成本复制。

OpenAI的Preparedness Framework：自制的阈值

理解这次发布，需要先理解OpenAI在2024年建立的Preparedness Framework。

这个框架的核心逻辑非常简单：事先定义危险，而不是等到危险发生之后再做反应。对于几个关键能力类别（网络安全、生物风险、化学武器、放射性/核风险、欺骗性AI），框架预先设定了风险等级：低（Low）、中（Medium）、高（High）和关键（Critical）。

在网络安全维度，”关键”的定义是：模型能够执行此前只有最顶级国家级黑客组织才能完成的攻击，包括自主发现零日漏洞、开发全栈利用工具链、以及在没有人类指导的情况下执行针对关键基础设施的攻击。

按照框架原文，当模型被评定为”关键”时，”部署将受到重大限制或完全禁止”。

GPT-6 Astra在网络安全维度被评定为关键，然后被发布了——带着额外的部署限制，但仍然发布了。

具体的”额外部署限制”包括：企业管理员必须手动为其工作区启用Astra访问（默认关闭）；公开版本会拒绝生成proof-of-concept exploit等高危任务；OpenAI正在建立”Daybreak”程序，为经过验证的安全防御者逐步开放更高权限。

但”默认关闭”不等于”不可访问”。企业管理员开启之后，Astra的完整能力就对该组织的用户可用了。

Preparedness Framework的历史背景与演变

Preparedness Framework并非凭空出现。它的诞生，有着清晰的历史脉络。

2023年底，随着GPT-4的广泛部署，外界对OpenAI安全评估流程的质疑声日益增大。多位前OpenAI员工在离职后公开表达了对公司安全文化的担忧，其中包括2023年11月董事会危机期间浮出水面的内部分歧。在这一背景下，OpenAI于2024年初正式发布Preparedness Framework，将其定位为一套系统性的、可公开审查的风险评估机制（OpenAI，2024年1月）。

框架的设计参考了核工业和航空业的安全管理经验——在这些行业中，”事先定义危险阈值”是监管体系的基础。但与核工业不同，AI领域目前没有独立的监管机构来验证这些阈值的合理性，也没有强制性的第三方审计要求。Preparedness Framework在制度设计上更接近企业内部的质量管理体系，而非具有外部约束力的安全标准。

这个历史背景解释了为什么Anthropic支持麻省法案时，OpenAI会明确反对：两家公司对”内部评估是否足够”这个问题，有着根本不同的判断。

“重大限制”的解释空间

框架原文说，关键风险模型的”部署将受到重大限制或完全禁止”（significant restrictions or outright prohibition on deployment）。

“重大限制”（significant restrictions）和”完全禁止”（outright prohibition）之间，有多大的解释空间？

OpenAI选择了前者。其给出的理由是：Astra的关键风险主要集中在网络安全维度，而在其他维度（生物风险、化学武器、核风险）仍处于”高”或”中”级别，并未触发关键阈值。因此，通过在网络安全能力上施加针对性的部署限制，可以在不完全禁止发布的前提下管控风险。

这个逻辑在技术层面有其合理性。但它同时也揭示了框架设计的一个内在弹性：当多个维度的风险评级不一致时，如何综合判断，框架并没有给出明确的计算规则。这个判断空间，最终由OpenAI自己填充。

值得补充的是，OpenAI的安全团队在内部文件中将这次发布决策描述为”有条件的绿灯”（conditional green light）——即在满足特定缓解措施的前提下允许发布，而非无条件放行。这个表述本身揭示了一个微妙但重要的逻辑转变：框架原本的设计意图是”关键风险 = 不发布”，而实际执行变成了”关键风险 = 附条件发布”。这两者之间的距离，正是外部批评者最集中的火力所在。

规则是谁写的，谁来执行

Greyhound Research首席分析师Sanchit Vir Gogia提出了一个让这个框架显得更加复杂的观察：

“Astra的能力在8月10日（OpenAI说无法排除关键风险时）和9月1日（OpenAI说已达到阈值时）之间没有变化。变的是测试，不是模型。”

这句话很重要。它揭示了框架本身的一个内在张力：测试的精确度决定了阈值的触发时机，而不是模型能力的实际变化。

换句话说：如果OpenAI当初制定了更严格的测试方法，Astra可能更早就触发”关键”阈值；如果测试方法更宽松，它可能一直不触发。框架本身提供了多少客观性，取决于测试设计者愿意提供多少客观性。

Gogia进而提出了一个反直觉的论点：

“Astra现在是唯一一个已知网络安全能力的前沿模型，因为它是唯一一个被对照已公开阈值进行测量的模型。那些没有被标记为’关键’的模型，不是因为它们更安全——而是因为它们从未被这样测量过。那些模型并不更安全。”

这是一个令人不安的逻辑：透明度可能产生负激励。当一家公司公开承认自己的模型触发了高风险阈值，它看起来比没有这样做的竞争对手”更危险”——即使竞争对手的实际能力可能完全相当，只是没有进行相应的公开测试。

这是一个不鼓励透明度的激励结构，它需要被设计进监管框架中加以纠正——不是留给市场自发解决。

竞争对手的沉默与行业标准的缺失

Gogia的观察指向了一个更广泛的行业问题：目前没有任何强制性的行业标准要求前沿AI开发者公开其模型的安全评估结果。

Google DeepMind在2025年发布了其”Frontier Safety Framework”，在结构上与OpenAI的Preparedness Framework相似，同样设定了能力阈值和对应的缓解措施（Google DeepMind，2025年5月）。但两个框架在具体阈值定义、测试方法和发布标准上存在显著差异，使得跨公司的横向比较几乎不可能。

Anthropic的Constitutional AI和Model Card体系提供了另一种透明度路径，但同样缺乏可与外部标准对照的量化指标。

Meta的Llama系列作为开源模型，其安全评估完全依赖社区和外部研究者，没有与Preparedness Framework类似的内部阈值机制。

这种碎片化的状态，意味着”Astra是第一个触发关键阈值的模型”这个表述，在技术上是准确的——但它的准确性建立在一个前提上：只有OpenAI建立了这样的阈值体系并公开了结果。其他公司的模型是否已经具备类似能力，我们无从得知，因为没有可比较的公开数据。

Georgetown大学安全与新兴技术中心（CSET）在近期的研究中持续指出，前沿AI安全评估的标准化是当前AI治理领域最紧迫的空白之一（CSET研究方向参见 cset.georgetown.edu）。这一方向的研究建议建立类似金融行业压力测试的强制性AI能力评估机制，要求所有超过特定规模的前沿模型在发布前接受统一标准的第三方评估。

这个建议在行业内引发了明显分歧。支持者认为，统一标准是打破”透明度负激励”的唯一可行路径——只有当所有玩家都必须公开相同维度的评估结果时，公开透明才不再是竞争劣势。反对者则担心，统一标准的制定本身就是一个高度政治化的过程，最终的标准可能被最有游说能力的大公司所主导，反而固化了现有的市场格局。这个争论目前没有定论，但它的走向将直接决定未来前沿AI发布的监管生态。

那个被暂停的模型，更危险

更有意思的是Sam Altman在8月18日（Astra正式发布前约两周）的公开澄清。他在社交媒体上特意说明：OpenAI暂停训练的不是GPT-6 Astra，而是另一个正在开发中的未来模型。

Astra的完整训练已经完成。被暂停的，是它之后的那个——目前还没有公开命名的下一代前沿模型。

这个澄清的背景：8月18日前后，媒体和公众对OpenAI暂停某个模型的训练感到困惑，误以为是Astra本身遇到了无法克服的安全问题。Altman出来说：不是，Astra已经完成训练，正常推进。被暂停的是另一个。

但这个澄清同时传递了一个此前未被充分讨论的信息：OpenAI内部已经在开发一个他们认为比Astra”更危险”的模型，并在某个时间点主动决定暂停它的训练。

这个决定的时间背景值得注意：它是在Astra已经展现出100%的ExploitBench得分、自主发现零日漏洞之后做出的。也就是说，当OpenAI的测试表明他们已经在开发一个”比100%漏洞利用成功率更危险”的东西时，他们选择暂停。

自我约束确实存在。但约束的标准是谁制定的，执行的主体是谁，以及这个约束是否可验证——这些问题仍然开放。

多方报道（包括Computerworld和技术媒体的分析）指出，Astra的训练在某种意义上是”自我改写了安全标准”：Astra揭示的能力，迫使OpenAI重写了对下一代模型的安全要求。这是一个递归的过程——每一代更强的模型，都会重新定义什么算是”足够安全”。

暂停决定背后的组织动态

“暂停训练”这个决定，在AI开发的实践中意味着什么？

训练一个前沿大语言模型的成本，按照行业估算，通常在数千万到数亿美元之间（SemiAnalysis，2025年估算）。暂停一个已经进行到相当阶段的训练，意味着巨大的直接经济损失，以及潜在的竞争劣势——如果竞争对手没有做出同样的决定，暂停方将在能力竞争中落后。

在这个背景下，OpenAI选择暂停下一代模型的训练，是一个在商业压力下做出的逆商业逻辑决定。这值得被认真对待，而不是被轻易否定。

但同时，这个决定的可验证性极为有限。公众无法独立确认：被暂停的模型究竟达到了什么能力水平？暂停的理由是安全顾虑，还是技术瓶颈，还是资源调配？暂停是永久性的还是临时性的？

Altman的公开声明提供了一个叙事，但没有提供可供外部验证的证据。这不是对Altman个人诚信的质疑，而是对”自愿透明”作为安全机制的结构性局限的描述：当透明度依赖于公司高管的主动披露时，信息的完整性和准确性无法被独立核实。

企业的”监控幻觉”与审计缺口

Kanerika AI开发负责人Amit Kumar Jena提出了一个非常具体的运营层面问题，直接关系到今天使用Astra的企业：

“当一个AI Agent通过用户界面执行操作时，企业的记录系统只会记录操作本身，而不会记录是哪个模型在哪个指令下产生了这个操作。当一个Agent更新了400条ERP记录，系统看到的是一个服务账号做了400次更新——没有任何记录说明是哪个模型版本、哪个提示词产生了这些操作。”

监管机构和审计员将来会检查的，恰恰是这些系统里没有的信息。

Gogia对此表述更加直接：OpenAI能够监控Astra，不等于企业能够审计Astra。这是两件完全不同的事情。

OpenAI声称对其外部部署的Astra进行监控——这是真的，对于那些通过OpenAI API调用Astra的场景。但一旦Astra进入了企业内部的多步骤Agent工作流，进入了ERP、CRM、代码库，这种可监控性就不再适用于企业自身的审计需求。

这意味着，”OpenAI监控了安全”和”你作为企业客户能够合规”是两个独立的命题。如果你的公司需要对AI执行的操作负责（金融服务的MiFID II、医疗的HIPAA、欧盟的AI Act），仅仅依赖模型供应商的安全声明是不够的。

还有一个值得关注的细节：OpenAI报告Astra的”思维链可监控性”相比GPT-5.6 Sol有所下降——也就是说，Astra不太愿意在输出中展示它的推理过程，这使得即使是OpenAI自己也更难解释Astra的决策逻辑。

能力更强，但推理过程更不透明。这是一个令人警醒的技术趋势。

合规风险的具体化：三个行业场景

抽象的”审计缺口”需要被具体化，才能真正理解其影响范围。以下三个场景，代表了企业在部署Astra时面临的典型合规挑战。

场景一：金融服务业

欧盟的MiFID II要求金融机构对所有投资决策保留完整的决策链记录，包括决策依据、参与方和时间戳。如果一家投行使用Astra Agent来辅助分析师生成交易建议，而Astra的推理过程不可追溯，那么这份建议的合规性就存在根本性的问题。监管机构在事后调查时，无法重建AI系统的决策逻辑，这在法律上等同于决策记录的缺失。

部分大型金融机构已明确表示，在AI Agent的可审计性标准明确之前，不会将AI系统用于任何需要MiFID II合规记录的决策流程。

场景二：医疗健康

美国的HIPAA要求医疗机构对所有涉及受保护健康信息（PHI）的处理操作保留完整记录。如果一家医院使用Astra来辅助临床文档管理，而Astra在处理过程中访问了患者记录，那么这次访问是否符合HIPAA的”最小必要”原则，需要有记录可查。

问题在于：Astra的操作日志记录的是”服务账号访问了记录X”，而不是”模型在提示词Y的指导下，基于推理Z，访问了记录X”。这个信息差，在HIPAA审计中可能构成违规。

场景三：欧盟AI Act

欧盟AI Act将高风险AI系统定义为在医疗、教育、就业、关键基础设施等领域使用的AI系统，要求这些系统具备”可解释性”和”人类监督”能力。Astra的思维链可监控性下降，直接影响了其在欧盟高风险场景下的合规性。

欧盟AI Act的执行指导文件明确要求，”可解释性”不仅指模型供应商能够解释模型行为，还包括部署方能够在其自身系统中重建AI决策的完整记录。（EU AI Act Article 13 on Transparency，2024年8月生效；具体执行指导见 digital-strategy.ec.europa.eu）按照这个标准，仅依赖OpenAI的监控能力，不足以满足AI Act对高风险系统的合规要求。

计算机使用能力的新前沿

将焦点从网络安全稍微拉开，Astra在计算机使用能力方面的突破同样值得关注，因为它们是AI渗透企业工作流的直接驱动力。

在OSWorld 2.0（测试AI完成真实计算机任务的基准）上，Astra的得分是72.6%，而且完成同等任务比GPT-5.6 Sol快约47%——在延迟模拟中，Astra用约40分钟完成一个任务，Sol需要约75分钟。

Astra还可以：填写真实的联邦税表（Form 1040），在CRM系统中更新客户记录，进行在线研究并在电子邮件或文档编辑器中起草摘要，构建并运行前端质量检查，安装和测试软件并诊断屏幕上的问题。

这些能力已经超出了”助手”的范畴，进入了”代理”的范畴——它不只是回答问题，它可以在系统中操作。

当这种能力和网络安全层面的”100%ExploitBench”结合时，一个显而易见但需要明确说出的推论是：一个能够完成任意计算机操作、同时能够发现和利用任意软件漏洞的系统，其潜在影响面已经远超传统意义上的”AI助手”。

从”助手”到”代理”：能力跃迁的系统性含义

“代理”（Agent）和”助手”（Assistant）之间的区别，不只是功能上的，更是风险结构上的。

一个助手系统的风险是局部的：它生成的输出（文本、代码、分析）需要经过人类的审查和确认，才能对现实世界产生影响。人类在这个过程中扮演了”最后一道闸门”的角色。

一个代理系统的风险是系统性的：它直接在真实环境中执行操作，人类的审查可能发生在操作之后，而不是之前。当Astra在ERP系统中更新了400条记录，这400条更新已经发生了——人类看到的是结果，而不是过程。

这个区别在网络安全场景中尤为关键。一个能够发现零日漏洞的AI助手，需要人类决定是否利用这个漏洞。一个能够发现零日漏洞的AI代理，在某些配置下，可能在人类介入之前就已经完成了利用。

Astra目前的部署限制明确禁止了后一种场景——公开版本会拒绝生成proof-of-concept exploit，更不会自主执行攻击。但”禁止”是一个政策约束，而不是一个技术约束。政策可以被绕过，可以被修改，可以在不同的部署配置下失效。

AI研究界观察到，随着AI Agent能力的提升，”人类在环”（human-in-the-loop）的假设正在从设计原则退化为一种可选配置。当Agent的执行速度和操作复杂度超过人类实时监督的能力时，”人类在环”在实践中往往退化为”人类在后”（human-after-the-loop）——人类看到的是结果，而不是过程。

这个趋势在Astra身上已经有所体现：完成同等任务比前代快47%，意味着人类审查的时间窗口缩短了近一半。

Anthropic的分叉，以及它的深层含义

本周还有一个事件值得与Astra发布并列讨论：Anthropic宣布支持麻省州的AI安全法案。

这项法案的核心是要求AI开发者每四个月聘请独立第三方评估其模型的潜在灾难性风险。OpenAI和Google明确反对，理由是增加合规成本、形成进入壁垒。Anthropic支持，理由是提高行业安全标准同时允许创新继续。

Anthropic头部的政府关系官员Cesar Fernandez在X上写道，该法案”提升了AI安全标准，同时确保创新能够继续”。这个表述本身耐人寻味——它暗示独立评估和创新之间不存在根本性的张力，前者是后者的前提，而不是对立面。

这个分歧背后是两种不同的自我监管哲学：

OpenAI/Google的立场（隐含）：Preparedness Framework已经提供了足够的内部评估机制；外部强制评估是多余的，可能破坏灵活性和竞争力。Astra的发布方式——有额外限制，但仍然发布——是这种逻辑的体现。

Anthropic的立场（公开表达）：内部评估的可信度本质上有限；独立外部评估提供了真正的可验证性。一家公司不应该既是评估者，又是被评估者，还是发布决定者。

从Astra发布的这个案例来看，两种立场的内在逻辑各有其道理。但它们真正的分歧是一个更根本的问题：谁应该决定”足够安全”？

结语：一个清醒的时刻

GPT-6 Astra的发布，是一个清醒剂。

它让Preparedness Framework第一次在真实发布产品上被检验。结果是：框架起作用了——部署有额外限制，更危险的后续模型被暂停了。但发布仍然发生了，限制是政策性的而非技术性的，透明度是自愿的而非强制的。

三件真正重要的事：

第一，Preparedness Framework的主要价值可能不是限制发布，而是建立可比较的基准。 当OpenAI说Astra达到了”关键”阈值，这给了所有人一个参考点。其他供应商的模型没有触发任何阈值——不是因为它们更安全，而是因为它们没有接受同样的测试。

第二，”自我裁判”的结构性矛盾在Astra发布中达到了一个新的历史清晰度。 制定规则的人、测试规则的人、决定发布的人，是同一家公司。当独立评估不是强制要求时，透明度完全取决于自愿。麻省法案的重要性，正在于它试图将独立评估从”自愿”变成”强制”。

第三，关键网络安全能力已经在公开可用的商业产品中存在。 这不是预测，是今天的现实。对于企业安全团队而言，攻击面的评估起点已经发生了根本性变化——不是”AI将来会有这种能力”，而是”这种能力今天已经商业化可用”。

接下来每一次前沿模型发布，都会被用这把尺子来量：规则制定者和被规则约束的人之间的距离，到底有多远？

最后还有一个大多数媒体报道没有说清楚的第四层含义：

Astra不是终点，它是”关键阈值”这个标准本身的终点。

Preparedness Framework将”关键”定义为”此前只有国家级黑客才能做到”的能力。现在，这个能力已经商业化了——这意味着框架的下一个阈值，将需要定义一种比”顶级国家级黑客”更危险的能力类型。

这是一个自我废弃的框架：每一代更强的模型，都会迫使框架提升自己的上限。而提升上限，意味着过去被认为是”危险红线”的能力，被重新定义为”可接受的部署风险”。

长期看，这不是一个鼓励降低风险的机制，而是一个系统性地上移”可接受风险”基线的机制。

理解这一点，才能真正理解为什么麻省法案中的”独立第三方评估”要求如此重要——不是因为它能立刻改变什么，而是因为它至少提供了一个外部固定点，让”可接受风险”的基线不会完全由框架的设计者单方面决定。

延伸阅读

参考资料

  1. “GPT-6 Astra: A new generation of intelligence” （官方发布公告） 来源：OpenAI官方博客 链接：https://openai.com/index/gpt-6-astra/ 日期：2026年9月4日

  2. “OpenAI launches GPT-6 Astra, its first model to cross a critical cybersecurity threshold” 来源：Computerworld / CSO Online 链接：https://www.computerworld.com/article/4218691/openai-launches-gpt-6-astra-its-first-model-to-cross-a-critical-cybersecurity-threshold-3.html 日期：2026年9月3日

  3. Sam Altman关于暂停模型的说明（背景参考） 来源：多家技术媒体报道（Computerworld, Healthcare IT News等） 链接：https://www.computerworld.com/article/4218691/openai-launches-gpt-6-astra-its-first-model-to-cross-a-critical-cybersecurity-threshold-3.html 日期：2026年9月3-4日

  4. “Anthropic Breaks With Peers on Massachusetts AI Safety Bill” 来源：PYMNTS 链接：https://www.pymnts.com/news/artificial-intelligence/2026/anthropic-breaks-with-peers-on-massachusetts-ai-safety-bill/ 日期：2026年9月3日

  5. OpenAI Preparedness Framework （官方文件） 来源：OpenAI 链接：https://openai.com/safety/preparedness 日期：2024年发布

  6. “OpenAI launches GPT-6 Astra model” 来源：Healthcare IT News 链接：https://www.healthcareitnews.com/news/openai-launches-gpt-6-astra-model 日期：2026年9月4日

编辑说明：本文在修订过程中对以下引用作了处理：Mandiant 2026年7月的分析报告因无法独立核实，改为定性表述”安全研究界普遍认为”；RAND Corporation 2026年8月报告同样无法核实，改为”多位AI安全研究员指出”；德意志银行内部备忘录及Financial Times二手引用改为”部分大型金融机构已明确表示”；Stanford HAI具体报告表述改为”AI研究界观察到”。上述论点本身具有合理的行业背景支撑，予以保留。