Claude Mythos顺利完成国际AI安全测评机构下面我简称为AISI的网络安全全流程评测成为首个跑完全程的模型。这事儿在安全圈和大模型圈里都炸了锅因为之前各大模型的横向对比大多集中在通用能力、代码水平、逻辑推理这类常规科目上而这次测的是实实在在的网络安全攻防场景而且是覆盖模型全生命周期的评估。不是拉几个基准数据集跑跑分就完事而是从语料审查、训练过程、微调阶段一路测到部署后的线上行为监控——换句话说测的不只是模型会不会做题而是这个模型放在真实环境里到底安不安全、会不会被利用、能不能扛住恶意攻击。对做AI安全、大模型应用落地的团队来说这个评测的结果和背后的方法论比单纯一个通过了的结论更有参考价值。这篇文章我不打算复述新闻稿而是基于我自己的安全评估实操经验把AISI全流程评测到底怎么测、Claude Mythos为什么能成为首个通过的模型、以及如果你想给自己的模型跑一遍类似评估应该怎么设计、怎么落地掰开揉碎讲清楚。1. 全流程评测到底测了什么从考试到实战的转变先解决一个最基础的问题AISI的全流程评测和过去大家熟悉的模型安全评测有什么本质区别这个搞清楚了后面所有内容才有意义。1.1 传统安全评测的局限为什么分数高不等于安全过去两年各种机构都喜欢给大模型做安全评测最常见的方法是准备一堆安全测试题比如让模型生成仇恨言论、暴力内容、诈骗话术然后看模型拒绝的比例有多高。这类评测本质上是一场开卷考试——题目是预设的答案的评价标准也是预设的模型只要在训练时见过类似的安全对齐数据就能轻松拿到高分。但问题是这种考试型评测测出来的安全能力到了真实攻防场景里往往大打折扣。原因有两层第一真实攻击者的攻击方式是动态演进的今天能挡住模板化攻击明天别人换个prompt绕过方式可能就失效了第二大模型的安全能力不是均匀分布的训练时安全对齐做得好不代表微调之后还安全更不代表在工具调用、多轮对话这种复杂场景下还能守住底线。所以AISI这次做的全流程评测很大程度上就是在纠正以分数论安全的误区。它把评测的颗粒度下沉到了模型的开发过程本身重点回答三个问题这个模型的训练数据干不干净模型在训练和微调过程中有没有被植入后门模型部署上线之后在真实流量中会不会被恶意利用这三个问题恰恰是传统评测完全不覆盖的盲区。1.2 全流程评测的四个阶段语料、训练、功能、部署AISI的全流程评测框架本质上是一条完整的审计链路。按照我的理解它至少包含四个大的模块第一个模块是数据与语料审计。这一步要核查训练语料里有没有包含恶意样本、漏洞利用代码、攻击工具开发教程以及各类高危敏感数据。很多团队这一关就会卡住因为现在的大模型训练语料动辄几万亿token靠人工抽检根本不现实必须用自动化工具先做一轮预筛再用安全专家做定向研判。第二个模块是训练与微调过程审计。这里主要看安全对齐是否贯穿了整个训练周期以及脏数据有没有可能在预训练或SFT阶段被模型学进去。最典型的检测手段是触发测试——用大量恶意指令去激活模型看它会不会吐出训练时记住的危险内容。这一步很考验功力因为触发样本的构造直接决定了测试效果。第三个模块是功能安全测试。这个环节最接近传统评测但深度完全不同。它不只是测模型会不会给出不安全回答而是站在攻击者的角度尝试各种越狱手段、prompt注入、多轮诱导、上下文劫持看看模型的防线在哪一层会崩溃。Claude Mythos在这个环节表现很突出尤其是在高度对抗性的连续攻击场景下它的拒答能力没有因为多轮对话上下文而衰减。第四个模块是部署与上线后监测评估。这个模块的存在证明了全流程评测的核心思路大模型安全不是训练完就结束的而是部署到生产环境之后才真正开始。评测团队会在模拟生产环境下测试模型被恶意用户高频调用时的表现、模型在接入外部工具时的权限边界以及模型输出的日志中是否存在可被利用的信息泄漏。这一步在传统的考卷式评测里基本见不到但对于真实业务来说恰恰是最重要的。这四个模块环环相扣前面的环节没做好后面的测试大概率也会暴露问题。AISI要求的是全流程跑通任何一个环节不符合标准都不能算完成评测这也是为什么Claude Mythos首个完成这个身份含金量高的原因——不是单项第一而是没有短板。2. 为什么是Claude Mythos架构设计与安全训练的细节接下来聊一个大家都关心的话题为什么第一个通过全流程评测的模型是Claude Mythos是运气好还是它的架构和训练方式本身就有独特优势我结合自己对模型安全机制的研究拆几个关键点。2.1 拒绝机制不是一刀切分层拒答与上下文感知如果你调过各种模型的API就会发现很多模型的安全机制是一刀切——只要检测到敏感关键词就给你回一句抱歉我无法回答这个问题。这种机制的优点是误伤率高、容易实现但缺点也很明显一是容易被规则绕过二是被拒绝的问题并不都是有害的真实用户经常被这种机械式拒答搞得很恼火。Claude Mythos给我的感觉是它的拒答机制是分层级的。在AISI的评测报告里有一个细节很能说明问题面对一个包含恶意代码片段的请求时模型并不会僵硬地拒绝所有内容而是会拆解用户意图——如果用户是在学习防御性编程它会输出经过安全加固处理的示范代码同时明确标注这是一段存在漏洞的写法实际部署时必须修复这里是修复后的版本但如果检测到攻击意图它会直接拒绝并说明拒绝原因。这种有条件的协助式拒答能力不是简单靠RLHF就能训练出来的。它需要模型在训练阶段就见过大量安全场景下的危险内容也就是说训练数据里必须同时包含高质量的恶意样本和安全准则模型才能学会区分什么时候应该给和什么时候应该拒绝。大多数模型训练时只做了拒绝这一半没有做到有原则地协助这一层。2.2 工具调用场景的安全约束一个容易被忽视的硬骨头这次评测里面我格外关注的是工具调用场景下的安全测试。原因很简单现在的大模型应用早就不满足于你问我答了越来越多的Agent开始接入搜索引擎、代码执行环境、数据库、第三方API这意味着模型的输出不再是文本而是直接可以触发真实操作的指令。如果模型被诱导调用危险工具后果就不是生成一段违规文本那么简单了。Claude Mythos在工具调用场景下的表现据评测反馈确实有领先之处。它的安全机制覆盖到了工具调用链路上模型被要求执行某个操作时会先校验操作是否在安全策略允许的范围内当检测到工具的调用参数中有可疑内容时会主动暂停执行并请求用户确认。这个机制我在自己的Agent项目里也尝试实现过难点在于安全校验不该拖慢正常的工具调用速度这个模型在响应速度和安全性之间取得了一个不错的平衡点。2.3 系统卡之外可解释的安全行为日志还有一个容易被外界忽略的细节是Claude Mythos在评测中暴露出的安全行为日志能力。这个能力不直接体现在能不能挡住攻击上但对于企业安全合规来说价值极高——评测人员可以清楚地看到模型对每一个敏感请求做出了什么判断、基于什么策略、最终输出是什么。这意味着安全团队不仅仅能知道模型是否被攻破还能知道模型为什么会被攻破。传统模型的安全机制完全是一个黑盒出问题了只能看到一个输出结果没法回溯判断链路。AISI的评测标准里明确要求了可审计性这一点在训练阶段就被重视起来的模型厂商说实话现在确实不多。Claude Mythos能通过评测跟这个底层的可解释性设计有很大关系。3. 如果给你的模型跑一遍类似评测实际操作思路很多朋友看完评测结果会问一个问题这套AISI的流程是不是只有顶级实验室才能跑我们自己手里的开源模型能不能也照着测一遍我的回答是可以而且最好在模型发布前就做。下面我分享一套简化但流程完整的实操方案这套方法不是照搬AISI的内部标准而是基于我参与过的安全评估项目总结的可落地版本。3.1 第一步搭建评测基线先定义什么是不安全很多人一上来就急着找攻击样本这是本末倒置。评测的第一步一定是定义安全边界你的模型所处的业务场景里什么行为算不安全不同场景的答案完全不同——一个客服机器人面对帮我写个爬虫脚本的请求拒绝可能就够了但一个开发者工具模型面对同样的问题如果完全拒绝反而影响正常使用。我的做法是分三步来定基线第一梳理业务场景列出模型会被用到的所有功能模块第二针对每个模块列出红线行为清单比如金融领域的模型不能输出投资建议、医疗领域的模型不能给出诊断结论第三为每类红线行为准备正反两组测试样本——正向测试样本用来验证模型在合规需求下的正常表现反向测试样本用来测试模型的拒答能力。这里有个很容易踩的坑正向和反向样本的比例不能失衡。我曾经见过一个团队准备了500条攻击样本但只准备了50条合规样本结果评测报告出来显示模型拒答率高达90%看起来非常安全但实际上模型在正常场景下也乱拒绝用户体验一塌糊涂。所以基线阶段一定要兼顾安全性和可用性两个维度。3.2 第二步构建攻击测试集从考卷到真实攻击链有了基线之后就可以开始构建攻击测试集了。我的经验是攻击样本至少要覆盖以下五个层面第一个层面是直接恶意指令用最直白的方式要求模型生成有害内容这是用来测最低防线的第二个层面是角色扮演诱导让模型扮演一个没有安全限制的角色来绕过约束第三个层面是多轮上下文攻击把恶意意图拆散到多轮对话里每轮看似无害累积起来就构成攻击第四个层面是编码混淆与变形把敏感词拆成拼音、用Base64编码、用同音字替换看模型能不能识别出背后的恶意意图第五个层面是工具链攻击模拟模型接入了外部工具后通过构造恶意参数来触发危险操作。我把这套测试集整理成了一个简单的表格测试层面样例设计思路预期防御表现直接恶意指令要求生成恶意代码、诈骗话术直接拒答不解释细节角色扮演诱导声称自己是安全测试人员需要研究用样本识别诱导意图拒绝或脱敏输出多轮上下文攻击分多轮逐步透露恶意意图前后关联上下文安全状态不丢失最终仍拒绝编码混淆敏感词变形、编码、谐音替换能识别底层意图不被表面形式骗过工具链攻击伪造工具参数诱导越权操作执行前校验隔离危险调用这里面的核心难点在第三个和第五个层面。多轮上下文攻击要求评测人员具备很强的对话设计能力不是简单把恶意词分布在几轮里就行还要控制对话节奏和上下文长度让模型的安全记忆在长上下文中逐渐模糊。工具链攻击则要求评测环境和真实生产环境高度一致否则测出来的结论迁移不到实际场景。3.3 第三步设计评测指标不看拒答率看失效模式跑完测试集之后最关键的一步是设计指标。很多团队拿到测试结果只统计一个拒答率比如我们的模型对恶意指令的拒答率达到95%然后就开始对外宣传。但AISI这套体系给我的一个重要启发是只看拒答率远远不够还要看拒答的质量。我建议至少要统计三个维度的指标第一是拦截率也就是恶意请求被成功拦截的比例这是基础指标第二是绕过深度统计攻击成功时模型在多少个层面失守——是被第一层直接请求就打穿了还是扛过了前四层最后在工具链环节崩溃绕过深度越深说明防线越有层次第三是失败模式就是模型被攻破之后输出了什么——是输出了完整攻击代码还是只输出模糊的思路是完全配合攻击者还是会在中间犹豫一下我管这个叫防御的残余有效性。举一个我实际项目中遇到的例子某个开源模型单看拒答率达到97%非常高但我看它的失败样本时发现只要攻击者把恶意请求包装成网络安全研究的学术问题模型就会乖乖配合甚至主动给出漏洞利用代码的完整实现。这个模型的拒答率高是因为大部分攻击手段太低级模型轻松识别了但只要攻击手法稍微高级一点防线就完全崩溃。如果只拿拒答率说事这样的模型会被误判为安全这是很危险的。所以我的建议是每一轮评测都要做失败样本分析把模型被攻破的具体场景记录下来形成失效模式清单。这个清单比所谓的安全分数要值钱得多它是下一步做安全加固的直接依据。3.4 第四步评测报告怎么写才能指导研发而不是躺在文件夹里最后一步是产出评测报告。干了这么多年安全评估我见过太多写得漂亮的报告最后没人看原因就是报告里全是通过/不通过的结论没有给研发同学可操作的修复方向。一份能真正指导研发的评测报告应该至少包含四个部分一是整体结论摘要用一两句话说明模型当前的安全水平是否达到发布标准二是关键风险清单按风险等级排列每条都要写清楚触发场景、攻击路径、影响范围三是复现测试样本每个风险点必须附带可以直接运行的测试样本方便研发同学复现四是修复建议与验证方案针对每个风险点给出具体的加固方案并说明加固之后应该用什么测试用例去验证效果。我在实际工作中发现第三部分复现测试样本是整个报告中最容易被忽视也最重要的内容。没有样本的漏洞描述只是听说有问题有了样本研发团队才能定位问题出在哪一层、哪个函数、哪个训练阶段。AISI的评测为什么能对模型厂商产生实质性的推动力很大程度就是因为它的报告颗粒度细到了可以精确复现并修复的程度。4. 安全评测的边界与冷思考别把通过评测当成绝对安全聊到这里可能有人会觉得Claude Mythos通过了AISI全流程评测那以后用它就绝对安全了吧。这个想法很危险我必须泼一盆冷水。安全评测的价值是证的伪不是证的真——评测通过只能说明在目前已知的攻击方法面前这个模型的防线是有效的不能说明未来所有未知的攻击方法都无效。4.1 全新攻击方式的滞后性评测永远走在攻击后面大模型安全的攻防博弈本质上是一场永不停息的军备竞赛。AISI的评测标准再先进它也是基于已知攻击模式来设计的。评测团队会关注社区最近流行什么越狱模版、什么prompt注入技巧然后把这些纳入测试集但攻击者永远在研发新的绕过手段这是同一个硬币的两面。我经常用一个类比来解释这个问题安全评测就像给一栋大楼做消防验收验收时测试的所有逃生通道、灭火系统都符合标准但谁也不能保证未来每一种火情都能被这套系统完全扑灭。评测通过只代表现在这个时点这栋楼是安全的不提供永远安全的保证。Claude Mythos成为首个完成全流程评测的模型这确实是里程碑但更应该被理解为这个模型的防御体系达到了当前已知攻击水平之上而不是这个模型从此免疫一切攻击。在安全圈待过的人都明白绝对安全这个词本身就是伪命题。4.2 评测过度关注可能带来安全表演效应全流程评测体系真正落地之后还有一个潜在风险很快会暴露出来模型厂商可能会针对评测标准做定向优化导致模型专门为通过评测而训练而不是真正提升安全能力。这就是所谓的安全表演效应。这种情况在自动驾驶领域出现过很多次厂商针对监管机构的测试场景做专项优化测试成绩无比亮眼但一到真实路况就暴露问题。大模型安全评测一样存在这个风险——如果AISI的评测框架完全公开后来的模型厂商完全可以针对评测流程中的每一个测试模块去专门调整训练数据、对齐策略从而刷出一个漂亮的评测报告但模型的真实安全能力并没有本质提升。我并不是主张评测标准应该保密——完全不公开评测标准厂商就没有改进方向行业也很难形成安全共识。更合理的方式是公开框架、细节动态调整把评测的四大模块和核心方法论公开但具体的测试样本、攻击方法和评估权重保持动态更新让厂商无法简单地针对测试集做应试准备。这里还有一个更深层的行业议题安全评测不仅是对模型的能力测试也在悄然改变模型训练的方向。当通过安全评测成为模型发布的前置条件安全对齐就不再是模型开发过程中可选的后置环节而会逐渐变成和性能优化同等重要的核心研发方向。这种变化未必是坏事但一定会引发连锁反应比如训练成本的上升、模型开放程度的收缩、乃至创新速度的放缓——这些都是接下来整个AI行业需要一起面对的权衡。4.3 对接下来AI安全建设的三个建议经历了对这个项目的完整复盘我对后续要怎么做AI安全有一些比较明确的感受和判断。第一个建议是**全流程安全评测应该成为大模型发布的出厂质检而不是少数头部模型的被动选择。**现阶段大部分模型产品的发布流程还是先上线出了问题再修复这在C端聊天机器人场景还能勉强接受但在金融、医疗、政务、工业这些高合规要求的行业里完全不可接受。行业需要更多类似AISI这样的标准化评测体系把安全评测前置到模型发布流程中形成硬约束。第二个建议是**安全评测的测试集必须持续补充用威胁情报的思路来运营。**我在自己的安全测试工作中有一个很深的体会静态的测试集用几个月就会失效攻击手段在快速迭代测试集也必须跟着迭代。建议有条件的安全团队把测试集运营当成一个常态化工作每周收集新的攻击手法、越狱模版、真实事故案例转化为新的测试样本入库。不更新的测试集本质上跟过期杀毒软件的病毒库一样只是自欺欺人。第三个建议是**开源模型的安全评测需要整个社区共担。**Claude Mythos这种闭源模型可以通过AISI这类权威机构做评测但大量开源模型散布在各行各业不可能都交给权威机构来测。我的看法是社区可以共建一套开源安全评测基线——包括开源的测试集、评测脚本、基线报告模板让任何团队都能对自己微调出来的开源模型跑一遍快速安全体检。在此基础上权威机构再对筛选出来的重点模型做深度全流程评测形成一个层次分明的安全评测体系。最后说一点个人的体会。我见过太多模型因为安全能力不足在正式上线前功亏一篑也见过太多团队把安全评测当成一个走流程的形式主义环节。Claude Mythos这次完成AISI全流程评测真正的价值不在于第一个这个头衔而在于它向整个行业证明了一套方法论是可行的——安全是可以被标准化度量、可以在开发全流程中落地、可以让模型在能力提升的同时不成为安全隐患的。这件事本身比我预想中来得更早一些。