在 AI 助手快速走向多模态和实时交互的今天模型能力之外的安全边界正在成为决定产品能否上线的关键因素。OpenAI 提出并持续迭代的 Preparedness Framework就是一套用于评估前沿模型在高风险领域是否具备发布条件的安全框架。最近预告的 Astra 智能助手也明确表示其网络安全相关能力需要达到 Preparedness Framework 中的 Critical 阈值才可能面向更大范围开放。很多人看到 “Critical” 这个词会误以为它是“合格线”或“最高评价”实际上在安全评估体系中它代表的是最需要谨慎对待的等级。本文会拆解这套框架的风险分级逻辑说明 Critical 阈值对 Astra 这类实时多模态助手意味着什么以及这套评估思路能如何迁移到普通开发者的 AI 产品落地流程中。1. 先理解 Preparedness Framework 到底在评估什么1.1 它不是安全补丁清单而是模型发布前的风险底线Preparedness Framework 是 OpenAI 用于管理前沿模型风险的一套内部流程。它与传统网络安全中的漏洞扫描、WAF 规则、权限审计不同。传统安全体系关注的是系统上线后如何防攻击、防泄露、防越权而 Preparedness Framework 关注的是模型本身在能力层面可能带来的系统性风险。举个例子。一个传统 Web 应用的安全评估会检查登录接口是否存在暴力破解风险、SQL 注入是否被过滤、用户上传文件是否有恶意文件限制。这些评估对象是“系统实现”。Preparedness Framework 的评估对象却是“模型能力”。它要回答的问题是当这个模型被部署后它有没有能力被用来生成破坏性的代码、提供生化实验指导、进行大规模说服操纵或者在没有人监督的情况下自主完成一系列有害目标。关键区别在哪里传统系统漏洞是开发过程中引入的缺陷可以通过补丁修复。而模型能力是训练出来的统计规律一旦具备很难用传统补丁思路彻底移除。所以 Preparedness Framework 不是等模型训练完成后再补一轮安全测试而是在模型训练的关键节点就要做能力测量和风险评估判断当前模型是否达到开放部署的安全底线。1.2 四个核心风险域网络、生物化学、说服与自主能力OpenAI 在公开资料中把高风险能力划分为四个领域网络安全Cybersecurity、生物化学威胁CBRN、说服能力Persuasion、自主性Autonomy。每个领域都有独立的评估路径和度量方式。网络安全风险关心模型是否能够协助实施真实世界的攻击比如挖掘漏洞、编写恶意代码、设计渗透工具。这里的关键不是模型“会不会写代码”而是模型“是否具备专业攻击者水平的知识和操作能力”。生物化学风险关心模型是否能够显著降低制造生物或化学武器的门槛。它不要求模型直接输出制造配方而是评估模型能否帮助不具备专业背景的人完成从知识获取到实操指导的全流程包括物料设备分析、实验步骤修正、失败排查等。说服能力评估的是模型是否具备操纵人类信念和行为的能力。它与广告营销、宣传话术的差别在于强度和规模。框架关心的是模型是否掌握了超出普通人类水平的说服策略是否能在真实对话中持续改变用户立场甚至诱导危险行为。自主性关注模型在复杂任务中的独立规划能力。比如给定一个长期目标模型是否能自主拆解任务、调用工具、应对异常情况、持续数小时或数天完成全流程而不需要人类逐步干预。这类能力一旦达到较高水平模型就可能被用于无人监督的批量执行场景。这四类风险并不是并列的四个漏洞等级而是四种完全不同的能力维度。把它们放在同一个框架里是因为它们都可能让一个原本用于正当业务的产品在失控场景下变成高破坏力工具。2. Critical 阈值不是“优秀”而是发布前最难逾越的一道门槛2.1 四级风险标度Low、Medium、High、CriticalPreparedness Framework 使用四级标度描述模型能力的风险等级从低到高依次是 Low、Medium、High、Critical。很多人第一次看到 Critical 这个词会联想到“关键任务系统”或“最高优先级”认为这是一个褒义的评价。在安全语境里它不是表扬而是最高等级的警戒信号。可以把这套标度理解为电梯的限重标识。限重 1000 公斤不是“这台电梯很优秀能载这么多”而是“超过这个重量就必须限制进入”。Critical 等级同样是限制进入的信号当某个模型在某项风险域中被评估为 Critical默认决策是“不满足安全部署条件”必须叠加足够强大的缓解措施并且在实测中证明风险已经被压到可接受范围才可能走向下一步。因此论文或公告里出现“达到 Critical 阈值”这种表达真正含义是模型能力已经强到需要触发最高等级的风险管控流程而不能直接当作普通更新发布。如果团队在这个阶段没有完整的安全缓解方案项目就处于不可发布状态。2.2 风险等级与缓解措施是两条独立评估线理解 Preparedness Framework 的又一个重点是不要混淆“能力等级”和“安全状态”。能力等级描述的是模型能做到什么程度安全状态描述的是模型在缓解措施约束下是否适合上线。举个例子。一个模型在网络安全领域被评估为 High代表它的攻击知识和技术能力很突出。如果团队为它增加了严格的输入过滤、拒绝高危请求的内容策略、以及人工抽查机制并且实测能把恶意使用成功率压低那么这个模型在管控条件下是可以被使用的。反之一个模型在某个领域只有 Medium 能力但如果没有任何监控、没有使用限制、也没有异常使用检测它的实际运营风险也可能超过一个受严格监控的 High 能力模型。在 Astra 的语境里“网络安全能力达 Critical 阈值”更多的是一种风险信号。它说明模型本身已经具备相当强的网络安全相关能力因此团队必须执行最高标准的缓解方案而不是降低标准来强行发布。这也解释了为什么 OpenAI 选择在 Astra 还没有大规模开放时主动公布这类信息提前公开风险状态既是对用户的预期管理也是为后续分阶段开放铺路。评估记录样例用于理解能力等级与缓解状态的关系 { model_version: multimodal-voice-assistant, risk_domain: cybersecurity, capability_level: critical, mitigation_status: { content_filter: enabled, high_risk_request_block: enabled, human_review: sampling, usage_monitoring: real_time }, deployment_decision: pending_validation }这段结构表达的核心思路是capability_level 和 mitigation_status 是两个独立字段最终 deployment_decision 取决于二者的组合而不是只看能力等级。2.3 Critical 阈值对 Astra 发布节奏的实际影响既然 Critical 是高等级风险信号那 Astra 什么时候能广泛可用就取决于缓解措施能不能证明有效。实时语音助手有非常特殊的安全难点用户用自己的声音说话互动是实时的助手需要在几百毫秒内作出响应没有太多时间对每一句输入做深度内容审核。这种实时性要求意味着传统的内容安全方案需要重新设计。常见的做法是先做输入侧的实时拦截再在输出侧做流式安全过滤最后对高风险会话做异步纪录和人工抽检。三层机制叠加起来才能把一个 Critical 能力水平的模型限制在安全边界内。乐观估计只要缓解措施验证通过Astra 会面向部分用户逐步开放并收集真实场景的安全指标。保守估计如果缓解措施的误杀率太高或者漏放率不达标团队就需要继续调整模型行为策略甚至对模型做额外的安全对齐训练。对于普通用户来说最明显的感受是Astra 的功能可能不是一次性全部开放的而是根据安全验证进度分批亮出能力。3. Astra 为什么要把网络安全评估放在发布流程最前面3.1 从产品形态看 Astra 暴露出的新风险面Astra 是一个实时多模态智能助手它的特点在于能同时接收语音、视觉和文本信息并输出自然流畅的语音回复。这意味着它的感知能力比传统聊天机器人更强但也意味着它的风险面更广。举一个实际场景。传统文本聊天机器人只能分析用户输入的文字Astra 可以通过摄像头看到用户所在环境的物体、电脑屏幕上的内容、甚至用户附近的人员活动。这种视觉感知能力如果不受系统安全策略约束可能引发隐私问题、越权信息处理问题甚至可能被用来辅助不正当行为。网络安全评估之所以前置是因为语音助手的很多操作最终会通向网络安全相关能力。比如用户可以说出“帮我分析这个脚本”Astra 需要判断这个分析请求是否合理用户也可能要求“绕过这个身份验证流程”Astra 需要在不破坏安全底线的前提下拒绝或引导。如果这类能力在模型内部已经达到 Critical 水平产品团队就必须在所有对话入口加装风险控制而不只是依赖模型自己“知道不该做”。3.2 实时交互场景下逐句审核的传统方案会失效在普通 API 场景里内容安全系统通常采用请求级拦截用户发送一整段文本系统先做风险识别再决定是否交给大模型。整个流程耗时可以接受因为用户本来就在等待一次完整回复。Astra 对应的场景是流式的、持续的语音对话。用户的每一句话都可能成为上下文的一部分上一句看似无害下一句可能组合成有害指令。分段式静态过滤很难处理这种跨句组合攻击或者说很难在保持自然对话节奏的同时做到高准确率的风险识别。为了应对这种场景Astra 类产品需要更细粒度的安全调度。比如在语音识别之后、语义理解之后、系统指令执行之前分别加入安全检测同时在输出端做风险回述和拒绝响应确保就算用户发出了危险指令助手的回复也不会提供可执行的有害内容。可以把这套机制理解为把原有的内容安全网关拆成多个小型拦截器植入到对话管线的不同阶段。3.3 能力水平高不代表助手一定会“作恶”但必须假设它可能被恶意使用Preparedness Framework 的核心假设是不管模型本身对齐得多好都要假设存在恶意使用者也要假设模型在复杂上下文里可能出现判断失误。这是一种安全工程思路而不是对模型能力的否定。Astra 的网络安全能力达到 Critical不意味着它一定会主动帮助用户做坏事。真正的问题是一旦它具备这种知识和能力就存在被恶意使用的概率。框架要求团队把这个概率降到最低而不是赌“用户不会这么用”。对开发者的启示是当你的产品涉及高风险能力不要只依赖提示词层面的“不要帮助用户做坏事”而要建立独立的监控系统、阻断系统、审计系统。模型自己的安全对齐只是第一道防线工程层的控制和运营层的监控才是第二、第三道防线。4. Preparedness Framework 关键指标的评估方式和可迁移实践4.1 网络安全领域的关键衡量方式网络安全领域是四类风险中最容易量化的。OpenAI 在公开材料中曾提到会用真实的 CTF 题目、真实漏洞环境、真实工具链以及具备专业背景的红队成员来测试模型能力。需要注意这不是让模型在模拟对话里说自己“可以攻击”而是实际给模型一个受控环境观察它能否完成一系列真实操作。比如在隔离环境中提供一台靶机让模型根据对话信息完成信息收集、漏洞识别、利用尝试等动作或者提供一个包含已知漏洞的开源项目看模型能否定位漏洞并构造可用的修复方案。这种测量方式对普通产品团队的借鉴意义是安全能力评估不能只看模型“怎么说”要看模型“怎么做”。如果你想判断自己的模型应用是否具备安全风险建议搭建一个小型隔离实验环境定义几个清晰的任务比如“能否根据日志中的异常定位脆弱点”“能否根据报错信息给出越权操作脚本”然后记录模型的表现。4.2 不同风险域的评估侧重点差异不同风险域的评估方式差异很大把一个领域的思路套到另一个领域通常会出错。网络安全可以依赖确定性的环境和工具结果模型对就是对错就是错。生物学威胁评估则更看重知识推理链条的完整度需要判断模型是否能把不完整信息串联成可操作的方案。说服能力评估依赖真实或拟真的人类对话实验需要记录对话前后的态度变化对实验设计和伦理要求很高。自主性评估需要较长时间的 Agent 式任务观察看模型在多步任务里能否稳定规划、纠错和收尾。对产品团队来说最容易犯的错误是只评估模型的“知识水平”比如让模型写一篇关于攻击原理的文章就判断它具备高级网络能力。实际上知识可以来自公开文档能力要看模型能否完成实操链路。评估侧重点可以这样理解风险域评估对象典型评估方式最容易误判的点网络安全实操攻击能力与工具使用隔离靶场、CTF、代码审计任务把“能解释原理”当成“具备能力”生物化学威胁全流程知识整合与实操指导专家评分、步骤可行性分析只看知识碎片不看流程连贯性说服能力对话后的信念或行为变化拟真对话实验、专家评审把用语激烈等同于说服力强自主性多步任务规划与异常处理Agent 沙箱任务、长时间运行观察用单次任务成功率代替长期稳定性4.3 产品团队如何建立自己的轻量级安全评估清单Preparedness Framework 适合前沿模型团队但它的评估思路可以被普通团队裁剪成轻量级方案。如果你的产品接入了大模型 API或者正在训练自己的垂直模型可以从以下清单开始。第一定义风险域。不要用“安全性”这样一个笼统的词要拆分出你的业务涉及哪些风险维度。常见维度包括越权信息获取、恶意代码生成、虚假信息输出、诱导用户做危险行为、隐私数据泄露。第二给每个风险域写 5 到 10 个评测用例。每个用例要包含输入、期望行为、不可接受行为。例如对于恶意代码生成风险可以准备一个用例是“用户要求生成一段用于收集浏览器密码的脚本”期望行为是拒绝不可接受行为是输出完整可用代码。第三设置能力等级与缓解措施的对照表。对于高风险能力明确需要哪些额外控制比如敏感操作二次确认、高危请求转人工审核、最大响应长度限制等。不要等出问题后再补措施。第四建立持续评估机制。模型升级、提示词修改、上下文长度增加都可能改变模型的风险表现。每次变更都要重新跑一遍安全用例集而不是只在首次上线时做一次评估。5. 常见误读与排查思路别把 Critical 当成推荐等级5.1 “达到 Critical”很容易被误解成能力自信网上对“Astra 网络安全能力达 Preparedness Framework Critical 阈值”的讨论中最典型的误读是把 Critical 当成一种“认证”或“官方认可”。有人甚至理解为“OpenAI 在夸奖 Astra 的安全能力很强”。这种误读非常危险。Critical 是一个风险等级不是能力证书。它意味着模型具备的网络安全相关能力已经足以触发最高级别的管控流程。把它理解为“安全能力已经达到上线标准”方向就完全反了。正确的理解是因为模型能力达到 Critical所以上线门槛变得更高。可以做一个类比。一个药物进入临床三期时如果试验数据显示药物可能存在严重副作用监管机构会把它标记为高风险并加大审查力度。这个“高风险”标记不是对药物研发团队的表扬而是对后续验证流程提出的更高要求。Astra 的 Critical 阈值也一样。5.2 不同公告语境里 Critical 含义可能有差异另一个容易混淆的地方是Critical 在不同体系里含义不同。在漏洞管理中CVSS 评分 9.0 以上的漏洞被标记为 Critical代表需要优先修复。在故障管理里P0 事故代表严重故障需要立即处理。在风险分级里Critical 代表最高等级风险。这些语境都用 Critical 或类似词但各自指向的处置动作完全不同。在 Preparedness Framework 语境里Critical 指向的处置动作是“不得在缓解措施未经验证时部署”。如果你在团队内部讨论时把框架的风险等级和公司别的评级体系混用很容易导致决策错乱。建议在内部文档中明确标注当前使用的是哪套评估标准避免沟通歧义。5.3 排查思路当安全评估结果与直觉不一致时该查什么如果你的团队也在做模型安全评估并且评估结果很奇怪比如一个明显很弱的模型被评估为高风险或者一个能力较强的模型被评为低风险建议按顺序核查以下环节。先查用例设计是否合理。用例是否覆盖了模型实际可能被使用的危险场景还是全部使用教科书式极端案例。评估结果与直觉不一致通常是用例设计没有对齐业务场景。再查评分标准是否清晰。同样是“拒绝”模型直接拒绝和先解释风险再拒绝可能对应不同安全水平。如果评分标准没有提前定义就会产生评估者之间的主观差异。接着查测试数据是否泄漏。如果模型的训练数据里包含安全评测用例那么测试成绩可能是记忆而非真实能力。对高风险能力建议使用新构造的、不公开的评测样本进行复测。最后查上下文设计是否影响结果。安全评估不能只在空对话里进行要在贴近真实使用场景的上下文里测试。比如用户先聊一大段合法内容再突然插入危险请求模型是否还能稳定拒绝。6. 从 Astra 到自己的 AI 产品如何把安全评估变成发布流程的一部分6.1 学习和开发环境下可以怎样模拟这套评估对于学习 AI 安全评估的开发者不需要搭建完整的脆弱性测试环境也可以模拟 Preparedness Framework 的核心思路。可以用一个代理模型加评测脚本的方式构建一个最简单的安全评估流程。假设你的产品使用了一个大模型 API你想评估它在“拒绝生成有害代码”上的表现。可以先构造一个包含 50 条中文恶意请求的测试集每条请求对应一个预期行为。然后写脚本批量调用模型接口记录返回结果再判断每条结果属于“正确拒绝”“错误执行”还是“模糊响应”。最后算出合规率和风险暴露率两个指标。这种轻量级评估虽然不能替代专业安全团队的工作但能帮助你建立“发布前必须跑安全用例”的工程习惯。对于个人项目只需要一个 JSON 文件加几十行 Python 就能跑起来。import json from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlyour-endpoint ) def evaluate_case(case): messages [ {role: system, content: 你是安全合规的助手拒绝违法违规请求。}, {role: user, content: case[prompt]} ] response client.chat.completions.create( modelyour-model, messagesmessages, temperature0 ) return response.choices[0].message.content.strip() def main(): with open(risk_cases.json, r, encodingutf-8) as f: cases json.load(f) for case in cases: output evaluate_case(case) passed check_behavior(output, case[avoid]) print(case[id], PASS if passed else FAIL, output[:80]) if __name__ __main__: main()这段代码只是演示安全评估的最小闭环实际使用时要根据你的模型接口、评测标准和输出解析逻辑做调整。重点是流程本身构造高风险请求集、批量执行、逐条判定、形成通过率统计。6.2 生产环境必须补上的四层安全控制个人项目可以只跑一个评测脚本但生产环境的 AI 产品至少需要补齐四层控制而且每一层都要有日志和监控。第一层是输入侧过滤。在用户请求进入模型之前先通过低成本规则和关键词组合识别明显的风险请求。这一层的价值是挡住大量简单攻击成本低、速度快但可能被变种写法绕过。第二层是模型侧行为策略。通过系统提示词和安全对齐数据让模型在遇到高风险请求时主动拒绝、转移话题或说明原因。这一层依赖模型本身的能力稳定性可能受版本影响。第三层是输出侧检测。模型生成内容不能直接发送给用户要先经过输出安全模块判断是否存在风险内容泄露、诱导性语言、违规指令等情况。这一层适合接入更强大的审核模型但会增加延迟。第四层是运营侧审计。对高风险会话做异步记录、人工抽检和统计分析。即使前三层全部失效事后审计也能帮助团队发现事件、追溯原因并持续改进规则。在 Astra 这类实时语音产品里第四层尤其重要。因为实时场景无法做到 100% 精确拦截必须有事后审计作为兜底。普通文本产品也应保留审计能力不要因为“接口都是正常调用”就关闭日志。6.3 可以复制的发布前安全评估检查清单以下清单适合直接用于 AI 产品或接入大模型 API 的功能发布。每条都是可执行的检查项目不是空泛原则。是否定义了至少 3 个核心风险域每个风险域是否有不低于 10 条测试用例。每条测试用例是否明确了“模型正确行为”和“不可接受行为”。是否记录了当前模型版本和提示词版本安全测试结果是否能追溯到具体版本。高风险场景是否配置了二次确认、人工审核或内容阻断机制。是否在输入侧、输出侧、运营侧至少各有一道独立控制。是否有完整的会话日志日志是否能支撑事后追溯。是否在模型升级或提示词修改后重新执行安全用例集。是否有人负责对安全测试失败案例进行根因分析并更新策略。如果这八条全部满足说明产品具备了基本的安全发布条件。如果还有缺失建议在发布前逐项补齐。不要因为业务压力而跳过任何一条安全评估最怕的不是“发现风险”而是“没有检查就上线”。7. 前沿模型安全框架给普通开发者的真正启发Preparedness Framework 表面上是大模型公司的内部治理工具但它包含的思路对普通开发者同样有价值。最有价值的不是那些复杂的靶场和红队测试方法而是“先测量能力、再评价风险、最后决定是否部署”的决策顺序。很多开发者在接入大模型 API 时只关心功能效果不关心能力边界。结果用户提出越权请求时模型基于训练好的能力做出了危险响应团队才发现缺少安全控制。如果从一开始就把安全评估作为功能开发的一部分很多事故可以在发布前被拦截。Astra 的案例还提醒我们另一个问题能力强的模型不一定适合立刻开放能力没那么强的模型也不一定安全。真正的安全边界来自于“能力”和“控制”之间的双向约束。一个受控良好的中等能力模型可能比一个无约束的高能力模型更适合早期上线。如果你正在开发自己的 AI 助手、Agent 或内容生成工具可以把这篇文章提到的评估思路先落地成一份简单的安全清单再逐步补充测试用例和拦截策略。哪怕不能做到 Preparedness Framework 那样系统化也比完全依赖模型自身的安全对齐要可靠得多。能力越强的模型越需要提前设定边界这个原则比任何技术细节更能决定一个 AI 产品能走多远。