让 AI 自己批改自己的作业？Snyk Evo 说这事不能这么干
Snyk 发布 Evo Agentic AppSec：写代码的 Agent 不能当裁判，拆解 49.7% 发现消失、修 1 进 8 与 slopsquatting。
我被一个数字整不会了。
49.7%。
据 Snyk 10 月 15 日的新闻稿，拿大模型做代码安全评审，有 49.7% 的发现，在下一次运行的时候会“消失”。
就是同一段代码，你让 AI 查一遍，它说这里有洞。
你再让它查一遍，它说没有了。
洞没修，代码没动，洞没了。
冒昧了。
这不是查漏洞，这是抽盲盒。
01
先说清楚发生了啥。
2026 年 10 月 15 日，Snyk 在波士顿发了新闻稿，宣布一个东西，叫 Evo Agentic AppSec。
翻译成人话，就是一组 AI 安全 Agent。
它们干三件事：找洞、修洞、拦截。
而且号称能跟上 AI Agent 写代码的速度。
听起来是不是特别像又一个“AI 扫一扫 PR”的产品？
不是。
这次 Snyk 押的点很有意思，核心就一句：
写代码的 Agent，不能当裁判。
新闻稿里说，结果要由独立于生成 Agent 的机制来验证。
Snyk 的 CTO Manoj Nair 有一句原话，我觉得是整篇新闻稿最值钱的一句（据新闻稿原文翻译）：
“让模型给自己的作业打分，不是安全方案，而是一个配了仪表盘的利益冲突。”
这句话，做风控的人听了会点头。
为什么？
因为风控行业最基础的规矩，就是谁发起交易，谁就不能审批这笔交易。
运动员兼裁判，比赛就没有意义了。
02
那为什么这事突然变得这么急？
因为账算不过来了。
我们看几个 Snyk 新闻稿里给的数字（以下都是 Snyk 自己的研究和产品数据，不是第三方统计）：
过去一年，客户侧新检出的 critical 和 high 级别漏洞，增长了大约 10 倍。
按 Snyk 的产品数据分析，大约每修复 1 个漏洞，就会新引入大约 8 个。
修 1 个，进 8 个。
这什么概念？
这就是你家漏水，你拿盆接了一盆，天花板又裂了八条缝。
你说这盆还接不接？
接，肯定得接。
但光接盆，这房子早晚得泡汤。
代码是 Agent 写的，写得飞快。
查漏洞要是还靠人一个一个看，或者靠一个查两遍结果不一样的 AI，那就是人家开高铁，你骑共享单车追。
追不上的。
03
再看另一笔账。
Snyk 新闻稿里还有一组数字，我看完后背有点凉。
近 10,000 个开发者环境分析下来，跑 MCP server 的开发者里，大约每 12 个就有 1 个有 high 或 critical 级别的发现。
1/12，换算一下大约是 8%（自算）。
近 4,000 个 agent skills 审计下来，36% 至少有一处安全缺陷。
按 4,000 粗算，就是一千四百个左右（自算，原文是“近 4,000”，实际数量会少一点）。
还有更刺激的。
Snyk 说 2026 年已经响应了 18 起高关注的恶意软件攻击，并且预计开源仓库里的恶意包，一年要涨 500% 以上。
这里面有个新玩法，叫 slopsquatting。
啥意思？
AI 写代码的时候，有时候会幻觉出一个根本不存在的包名。
然后坏人就去把这个包名抢注了，往里面塞恶意代码。
下一次 AI 再幻觉出同一个名字，开发者一装——
中奖了。
这就是黑产的精髓：不用攻破你，等你自己把门打开。
以前钓鱼要骗人点链接。
现在连人都不用骗，骗 AI 就行。
AI 还不会怀疑。
04
那 Snyk 这次拿出来的是啥？
据新闻稿，一共五个 Agent：
Evo Code Scanning Agent：前沿推理加静态分析，专门盯访问控制、鉴权逻辑这种靠模式匹配很难抓的问题。
Evo Dependency Firewall：安装的时候就拦截恶意或者违规的包，就包括刚才说的 slopsquatting。
Evo Agentic Security Review：给整个仓库做应用建模和威胁建模，出一份带证据的评审。
Evo Remediation Agent：自己跑修复闭环，首发先搞 Snyk Open Source，可能把构建搞坏的修复，进审批队列，等人点头。
Evo Secrets Detection：管传统开发和 Agent 开发路径上的凭据泄露。
说白了，这套东西的思路是：
AI 不是直接当判官，而是去操作 Snyk 原来那些确定性的引擎，比如 Snyk Code、Snyk Open Source。
什么叫确定性？
就是同一段代码，查一百遍，结果一样。
这就把开头那个 49.7% 的问题给绕过去了。
AI 负责跑得快、理解上下文、干杂活。
规则引擎负责给结果兜底。
一个负责腿，一个负责秤。
这个分工，我觉得是对的。
05
最能说明问题的，是修复这块。
Snyk 新闻稿里有个研究叫 VulnBump。
结论是：只靠大模型去修漏洞，能产出“可合并”修复的比例是 59.6%。
Evo Remediation Agent 在同一个“可合并”标准下，做到了 90%。
差了大约 30 个百分点（自算，90 − 59.6 = 30.4）。
注意，这是 Snyk 自己的研究、自己定的标准、自己报的数。
自己出题、自己考试、自己公布成绩。
讽刺不讽刺？
有一点。
一个主打“生成方不能当裁判”的产品，最亮眼的成绩，也是自己给自己打的分。
这不是说数字一定有问题，而是在有独立复现之前，大家看看就行，别当行业结论。
不过有一个细节我是认可的：
Nair 的说法是，预防（也就是在编码 Agent 写代码的环节里拦住）可以不经人签核，但修复已经上线的代码，必须赢得负责人的信任。
翻译一下：
没进门的东西，拦了就拦了。
已经住进去的东西，要动，得先问房东。
这就是风控里很朴素的一条：拦截可以自动，处置要有授权。
06
最后说说，这东西现在能不能用。
别一看新闻稿就以为全都上线了。
据 Snyk 新闻稿：
Evo Code Scanning、Dependency Firewall、Agentic Security Review，是给选定客户的 experimental preview。
Evo Remediation Agent 是 open preview。
Secrets Detection、Evo ADS、Evo Continuous Offensive Security 是 GA，也就是正式可用（ADS 之前已经发过，Offensive Security 是 2026 年 8 月就 GA 了）。
也就是说，这次新闻稿里最核心的那几个新 Agent，大部分还在预览。
客户数方面，Snyk 自己的说法是底层引擎有 4,800 多家客户，Snyk Studio 被 1,600 多家客户采用。
这些都是厂商自报，没有第三方核实。
07
那么问题来了，这事跟普通开发者有啥关系？
关系挺大的。
你现在用 AI 写代码，不管你用的是哪家的工具，都绕不开一个问题：
谁来查 AI 写的东西？
如果答案是“另一个 AI 随便扫一扫”，那你开头那 49.7% 就是你的真实处境。
如果答案是“我自己看”，那修 1 个进 8 个的速度，你看得过来吗？
Snyk 这次给的答案，不一定是最终答案。
但它至少把一个常识重新摆上了桌面：
写的和查的，不能是同一个。
这个道理，银行懂了几十年了。
审计懂了几十年了。
风控懂了几十年了。
到了 AI 写代码这儿，大家一兴奋，好像全忘了。
现在又得有人出来提醒一遍。
只能说，我爱这个魔幻的世界。
来源：Snyk 官方新闻稿。VulnBench、VulnBump 等数据为 Snyk 自家研究，尚待第三方复现；Manoj Nair 引语为作者据英文原文翻译；“约 1,400”为作者自算；多数 Agent 仍处 experimental/open preview。