那次重新定级给的是裁决，不是记录

一个 AI 智能体把 9,967 条 HIGH 级云端安全发现重新定了级，改掉了其中 75.1%——而那个将会跑得比研究本身更远的标题，「AI 让你的安全积压变小」，恰恰是数据不支持的那一个。58.5% 降了。16.6% 升了。同一研究团队已发布的基准把智能体的裁决放在 94%，而把裁决底下那个答案放在 78%，这恰好告诉你你买到的是什么：一份给你队列用的排序，而它建在一份记录之上——当有人追问「为什么一条 HIGH 被悄悄改成了 LOW」时，那份记录你可能复原不出来。

一眼看完

同一团队相隔九个月发布的两件工作，而它们只有合起来读才有用。前一件是挂在 arXiv 上、按同行评议体例写的基准；后一件是今天登上行业媒体的厂商研究，而我找不到对应的原始论文。这份不对称值得记住。

量的是什么	范围	结果	它许可你做什么
给 HIGH 级云端发现重新定级	9,967 条 HIGH 级发现，两个商业平台，八套生产环境	75.1% 改了级——58.5% 降，16.6% 升	给一个队列重排序
发现为何被降级	所有降级中最大的单一模式	32.3% 是惰性资源——什么都没挂，或者已成孤儿	删资源，而不是驳规则
跨厂商的身份推理	八个已集成平台上的 50 项以数据为依据的任务	全上下文下答案正确率 78%；彻底失败降到 4%	校准你该多信上面那一行
裁决与其背后的答案	同一基准，最强配置	裁决 94%，对答案正确率 78%	什么都不许可——它是那张警示标签

四分之三的发现动了。而没人会去引用的，是第三根条。

被讲出来的故事是降级；真正的故事是升级

把 58.5% 当作一句产品主张来读，它说的是：买这个，你的 HIGH 队列砍一半。再读 16.6%，这句主张就塌了——因为一个只会把发现往下挪的工具，与一个学会了说「大概没事」的工具在输出上无从分辨，而后者正是把一个语言模型对着一堆「有人希望它变短」的积压时最可能出现的失效模式。正是那些升级，让这个结果成为一项关于「测量」的论证，而不是一项关于「数量」的论证。

它们也改变了谁该在意。如果这个智能体只会排序，这就是一则给安全团队看的效率故事。而因为它既升也降，诚实的读法是：你扫描器里的那个严重度字段从来就不是对你风险的测量——它是那条触发了的规则的一个属性。Sola 报告称，它考察的每一条厂商规则，都对自己命中的每一个失败实例发出同一个严重度，规模上是数百条规则覆盖数万条发现。一条规则一个数字，然后套到这条规则历史上命中过的每一套环境。那是一个取了「严重度」这个名字的常量。

这并不是什么丑闻；这是一条只对着一个资源求值的规则唯一能做的事。CVSS 一脉里的严重度是某个漏洞类别的属性，而从「这个类别很严重」走到「这个实例在这里很严重」，需要的是规则根本没有的那些事实：这东西可不可达、有没有什么挂在它上面、它前面有没有一道控制。智能体的贡献不是更好的判断。是那次联接。

这套设计里最好的部分是那条不对称证据规则

那次联接就是产品。而中间那个方框里的不对称，是让它不至于变成一台驳回机器的东西。

被报告的那套证据规则，无论你怎么看那个标题，都值得照抄。要降一级，智能体必须观察到一项抵消利用路径的性质——该资源从互联网不可达、没有活的服务应答、源地址范围很窄、有一道账号级控制挡着。要升一级，它需要有证据表明这个条件在这套环境里更糟，并且还要检查前面没有防火墙或白名单之类的护栏。除此之外的一切，都维持厂商定级。

这份不对称把大多数分派自动化弄反了的那件事编码进去了。默认不是「做决定」；默认是「服从既有定级」，而两个方向都得自己挣来那次移动。这也是为什么维持原级的那 24.9% 是健康的迹象、而不是软弱的迹象——一个把一切都挪动了的重定级器，就是一个没有阈值的重定级器。

请注意那个占主导的降级理由究竟是什么。32.3% 的情形涉及惰性资源：什么都没挂，或者已成孤儿。这个发现不是「这条 HIGH 判错了」。它是「你在花钱让一个扫描器对着你忘了删的基础设施生成 HIGH」，而正确的回应是一轮删除冲刺，不是改一个严重度。藏在你三分之一积压里的那套失败分类法，结果是一个披着安全标签的资产生命周期问题。

裁决 94%、答案 78%：这道缺口就是全部的保留意见

第一列是一个有三种取值的标签。第二列才是审计人员会读的东西。

同一团队的 Cross-Vendor Sola ISPM Benchmark——八个已集成平台（含 AWS、Okta、Azure AD 与 Google Workspace）上的 50 项以数据为依据、需要多跳实体解析的任务——报告其最强的全上下文配置答案正确率为 78%，彻底失败降到 4%。厂商自己对这份工作的介绍文章引用的是 94% 的裁决对那 78%。把这两个数字并排放着，你就得到了两项研究里最有用的那一句话：这个智能体在「得出对的结论」上，远胜于在「握有对的理由」上。

这不是这款产品的某个怪癖。这是生成器–验证器差距在人们容易忘掉的那个方向上冒了出来——一次裁决是从三择一里出来的一个词元，而一个经机会校正的三择一起点就是 33%，所以一个高裁决率很便宜就能达到、却很贵才能解释。证据链才是贵的那部分，而它正是会退化的那部分。

基准也告诉了你为什么。加入结构化的关系上下文把答案正确率相对提升了约 34%，并把探索性查询砍掉了约 70%，而增益最大的那部分被归因于跨厂商的图拓扑。换句话说，智能体的准确率在很大程度上是「你有没有把账号、身份与资源之间的关系交给它」的函数——这是一个支持给你的资产面建一张图、并反对指望一个模型靠戳 API 把它重新发现出来的论据。同一个发现，也正是让图形态检索在这个领域里尤其值回其复杂度的那个发现。

那么一次重新定级，你究竟可以拿它做什么？

要紧的那个区分是「给工作排序」与「把工作关掉」，而它几乎精确地映射到上面那两个数字上。一个你信到 94% 的裁决，足以决定一个人先看什么。一份你只信到 78% 的记录，不足以成为一条发现就此不再存在的理由。

用途	需要什么	裁决够不够？	为什么
给今天的队列排序	一个相对排名	够	排错的代价是几分钟；那条发现明天还在那儿
抑制一整类告警	一条你说得出口的规则	不够	抑制是永久且无声的；它需要那个理由，不是那个标签
关闭一条发现	一份可审计的记录	不够	这就是那个 78% 的列，也是评估师会回头念给你听的那一列
升一级严重度	一次可复现的暴露检查	够，连证据一起	过度升级会自我纠正；那 16.6% 是犯错更便宜的方向

对任何要把这个接进真实流水线的人，有四件事随之而来。

把证据当作一等物件来存，而不是存成一段理由字符串。如果大约一半的裁决靠的是在被标记资源之外收集到的证据，那么你扫描器写下的那条以资源为范围的记录就装不下这个理由。请把那些具体的观察持久化下来——哪个 API、哪个账号、哪个时间戳——并与发现 ID 关联，这正是把它变成一条关于一次决定的审计轨迹、而不是一条关于某次决定的日志的东西。一次其正当理由是一段散文的降级，就是一次你将来要从零重打一遍的降级。

重新定级，绝不抑制。你要防的那种失败不是一个错的数字；而是一个错的数字让那条发现再也不会被看一眼。请把厂商严重度留在它自己的字段里，把智能体的定级写进第二个字段，然后按第二个排序——这样把整个实验回退就只是改一句查询，而不是一次恢复。

把证据的陈旧程度当作裁决的一部分。那张清单上的每一个降级理由都是一项可变性质。「从互联网不可达」为真，直到有人挂上一个负载均衡器——而那条发现的定级并不知道这事发生了。一次重新定级需要一个有效期，而这件事最要紧的那些环境，恰恰是变化最快的那些。

在采用任何人的数字之前，先量你自己的一致性。抽 200 条发现，让两位工程师独立定级，然后把两人都与智能体比一遍。如果你自己的人之间的分歧大于智能体与他们的分歧，那么有意思的缺陷就在你的评分细则里。这项练习就是裁判校准那一步，而跳过它，正是一个 75.1% 的标题变成一次采购决定的方式。

关于这项研究本身的证据标准，还有一条告诫。那个基准挂在 arXiv 上、在体例上可复现；而那项重新定级研究是以厂商研究的身份登上媒体的，我找不到原始论文，也找不到独立复现。两者都可能完全扎实。但一项其自身结论就是「裁决跑在记录前面」的研究，是一项该用它自己的标准来读的研究；而那个 75.1% 今天诚实的身份是：一个来自利益相关方的醒目结果，尚未被复现。

常见问题

这是不是意味着云安全厂商一直在虚高严重度？

不是——这意味着一条只对着一个资源求值的规则，根本无从知道它周围的环境，所以它只能发出一个单一评级。严重度字段是规则的属性，不是对你风险的测量，而这一点从来如此。

为什么那 16.6% 的升级比那 58.5% 的降级更要紧？

因为它是智能体有阈值、而不是有偏向的证据。一个只会把发现往下挪的分派工具，与一个学会了说「大概没事」的工具产出相同的输出，而单看降级率是分不开这两者的。

我能拿智能体的重新定级去关闭发现吗？

就这些数字而言不行。裁决被报告为 94%，而它背后的答案是 78%，而关闭恰恰是那个依赖记录、不依赖标签的用途。请拿它来给队列排序，以及决定一个人先读什么。

这项研究提示的那个最高价值的改动是什么？

把你资产面的关系交给智能体，而不是让它自己去发现。在那个基准里，结构化的关系上下文把答案正确率相对提升了约 34%、把探索性查询砍掉了约 70%，这比它报告的任何一次模型选择的效应都更大。

降级里真有 32.3% 只是孤儿资源？

那是被报告的最大单一模式，而它把三分之一的积压重新框成了一个资产生命周期问题、而不是一个安全分派问题。正确的回应是把那些资源删掉，这会永久地、并且以一个任何人都能审计的理由，把那些发现一并消掉。