本文作者：jiachunpeng
YASA 社区核心贡献者，专注于程序分析技术。Github主页：github.com/jiachunpeng
前几天读到腾讯混元和复旦大学 2026 年 2 月发的论文 CL-Bench，结论很震撼：GPT-5.1 在"从上下文学习新知识"上只拿了 23.7 分（满分 100），10 个顶级模型平均 17.2。大模型并不能真正从上下文中学会新东西。
但这和日常体感完全矛盾，最近天天用 Cursor/Claude Code 上百K的上下文写代码、修 bug、总结文档，采用最新最好的模型，基本做到了给出详细计划和约束，AI 后台写代码，我自己干别的（比如，写这篇文章），只需要隔一段时间看看 AI 干的对不对。偶尔上下文太长注意力涣散让人恼火，但论文中 23.7% 准确率未免危言耸听了。
Anthropic 甚至推出了 Claude Code Security 做安全审计，一度引起我的失业危机。AI 真"无法从上下文学习"的话，这些工具怎么可能好用？
从“中年优化”的恐慌中深入思考，一个更实际的问题浮上来：对于做静态应用安全测试（SAST）的人来说，AI 到底意味着失业，还是一次工具进化的机遇？
一、GPT-5.1 只考了 23 分
CL-Bench 做了一件有趣的事，把 AI 从"开卷考试"的舒适区拖了出来。
过去测试 AI 长上下文能力，用的基本都是"大海捞针"：在 100K tokens 里藏一句话，看能不能找到。AI 几乎都能找到，于是行业信心满满地宣布"AI 能处理长上下文了"。
CL-Bench 的研究者不这么看。他们认为，找到一根针和理解一本书是完全不同的能力。为了验证这一点，他们设计了 1899 道题，每道题的知识都是全新创造的——虚构的法律体系、发明的编程语言、不存在的物理定律。要答对题必须真的从上下文中学会新知识并推理。
结果相当残酷：
| 模型 | 成绩 |
|---|---|
| GPT-5.1（最强） | 23.7% |
| Claude Opus 4.5 | 21.1% |
| GPT-5.2（更新版本） | 18.1% |
| 10 个模型平均 | 17.2% |
满分 100，最强模型只拿了 23 分。更有意思的是 GPT-5.2 反而比 5.1 差了将近 6 个百分点，更新了反而退步了。
二、论文到底做了什么
2.1 Context Learning：一个被忽视的能力层次
论文提出了一个能力分层，我觉得很有启发：
Prompt Engineering → In-Context Learning → Context Learning
"用指令调动已有知识" "给几个例子学会格式" "从上下文学会全新知识"
前两种能力现在的 AI 做得不错。但第三层 Context Learning 要求的是：给你一大段从没见过的专业知识，真正理解它然后解题。这不是"找一句话"（检索），也不是"模仿例子格式"（ICL），而是要习得新的知识体系。
论文还区分了 Context Engineering（上下文工程）和 Context Learning（上下文学习）。前者是 RAG、Agent 工具链这些，解决"如何给模型提供正确上下文"；后者是"模型拿到上下文后能不能真学到东西"。行业在关心"提供什么上下文"的同时，似乎忽略了后面这个更根本的问题。
2.2 Benchmark 设计与防作弊
CL-Bench 体量不小：500 个复杂上下文、1899 个任务、31607 个评分标准，每个上下文平均 20 小时专家工时。
"防作弊"策略很巧妙：纯虚构（发明法律体系）、篡改已有知识（改数学定义）、极冷门真实知识（刚发布的小众文档）。对照实验中去掉上下文让 GPT-5.1 裸答，成功率骤降到 0.9%，这就确认了模型没法靠"猜"和训练的知识过关。
2.3 四大类任务
pie title CL-Bench 上下文分布（500个）
"领域知识推理" : 190
"规则系统应用" : 140
"程序化任务执行" : 100
"经验发现与仿真" : 70
领域知识推理（190 个）：运用虚构专业知识解题，比如用虚构法律体系审判案件。
规则系统应用（140 个）：给一套全新形式化规则让模型应用，比如用发明的编程语言写代码。
程序化任务执行（100 个）：按操作手册完成任务。论文举了个虚构无人机 SDK 的例子，看似"照着手册做"，实际需要精确理解每个 API 的调用条件和参数约束。
经验发现与仿真（70 个）：最难的一类，前三类是演绎推理（给规则去应用），这类是归纳推理（给数据去发现规则）。所有模型平均只有 11.8%。
2.4 评估方法与实验设置
每个任务都是开放式论述题，平均 16.6 个评分点，全部通过才算成功。评分用 GPT-5.1 做 judge，交叉检验一致率和人工抽检准确率均超 90%。
实验覆盖 10 个最强模型（GPT-5.1/5.2/o3、Claude Opus 4.5、Gemini 3 Pro、Kimi K2、Qwen、DeepSeek 等），全部最高推理设置，每题跑三次取平均。上下文平均 10.4K tokens，最长 65K。
51.1% 的任务有多轮依赖，用标准多轮 API 格式实现：
messages = [
{ role: "system", content: "你是 XX 领域专家... + 完整的上下文知识" },
{ role: "user", content: "Task₁: 请判断..." },
{ role: "assistant", content: "标准答案₁（不是模型自己答的）" },
{ role: "user", content: "Task₂: 基于上题结论..." },
{ role: "assistant", content: "标准答案₂" },
{ role: "user", content: "Task₃: 现在请综合分析..." },
// → 模型从这里开始生成
]
前序用标准答案而非模型回答，是为了隔离评估。但不管分几条 message，Transformer 底层都拼成一个序列做 Attention，随轮次推进上下文自然膨胀，从 8K 涨到接近 65K。
2.5 几个有意思的发现
同一领域，出题方式不同差距巨大。 法律领域的"查条文判合规"GPT-5.1 拿了 44.8%，但"像律师一样分析案件"只有 22.8%。看起来能定点查找的规则比需要综合理解的知识好处理得多。
上下文越长，成绩越差，无一例外。 从 0-4K 的约 25% 跌到 32K+ 的约 8%，Claude Opus 4.5 跌幅最大。
思考模式收益很小。 GPT-5.1 的 High vs Low Reasoning 只差 2.5%，GPT-5.2 几乎为零。Kimi K2 收益最高达 5.7%，Qwen 3 Max 反而微降 0.4%。
错误类型值得注意。 55-66% 是"上下文被忽略"（信息在那里但没看到），60-66% 是"上下文被误用"（看到了但用错了）。"忽略率"和模型强弱相关，但"误用率"在所有模型上都稳定在 60% 以上，看到和理解之间还隔着一道沟。
SkyNet 无人机案例。 Gemini 3 Pro 正确拒绝了绕过安全检查的非法请求，但替代方案遗漏了文档里写着"强制法律合规步骤"的 API。4 个评分点只过了 2 个，而在安全领域，部分正确等于完全失败。
三、那为什么 Claude 用起来一点都不差？
论文说 AI 只能理解 17% 的上下文任务，但我天天在 Claude 里用 200K tokens 改代码，体验明明还不错？
仔细思考，其实这并不矛盾，Claude 做的事和论文测的事可能根本不在一个层面。CL-Bench 要求"学会"虚构法律、发明的编程语言这种全新知识；Claude 里绝大多数任务是"用已知的编程知识处理特定代码"，TypeScript 语法、React/Spring 框架、常见 bug 模式，这些在预训练中早就学过了。上下文只是告诉模型"这个项目长什么样"，提供检索性信息，不要求学全新知识。
所以同样 200K 上下文：修空指针 bug 又快又准（预训练够用），重构复杂架构就容易漏约束（需要理解散布各处的设计决策），用全新框架写代码则明显吃力（接近 Context Learning 场景）。
3.1 CL-Bench 的多轮设计其实已经在模拟 Agent
一开始我想"是不是 Coding Agent 通过分步执行绕过了瓶颈"，但仔细看会发现 CL-Bench 的多轮设计已经在模拟理想 Agent 了：
CL-Bench： Task₁ → 标准答案₁ → Task₂ → 标准答案₂ → Task₃ → ...
Agent： Step₁ → 工具结果₁ → Step₂ → 工具结果₂ → Step₃ → ...
结构非常相似，而且 CL-Bench 给的是标准答案，比 Agent 的工具输出还可靠。相当于一个永远不犯错的理想 Agent，即使在这种最优条件下，模型也只拿了 17-24%。
3.2 关键差异不在分步，而在"教科书"
比较两种 context 结构后，我觉得真正的区别在这里：
CL-Bench 的 context： Claude 的 context：
┌──────────────────────┐ ┌──────────────────────┐
│ 20K tokens 的"教科书" │ ← 全程重要 │ System 指令（很短） │
│ 虚构法律/新语言语法 │ │ │
├──────────────────────┤ ├──────────────────────┤
│ Task₁ + 标准答案₁ │ │ grep 结果 → 过期 │
│ Task₂ + 标准答案₂ │ │ read 文件 → 过期 │
│ Task₃ ← 当前问题 │ │ edit 结果 → 过期 │
│ ↑ 每步都得翻教科书 │ │ npm test 结果 ← 焦点 │
└──────────────────────┘ └──────────────────────┘
CL-Bench 每一步都离不开那本 20K+ tokens 的"教科书"，全程在场、全程重要，Attention 需要对它各个角落保持关注，这正是注意力稀释最致命的场景。
Claude 没有这本"教科书"。编程知识早在预训练阶段就内化到参数里了，上下文中只有按需获取的代码片段和工具输出，用完就衰减，每一步只需关注最近的结果。
所以我的理解是：Agent 模式的优势可能不在于"任务分解"（CL-Bench 已经分解了，照样 17%），而在于"不需要持续存在的密集新知识上下文"。
反过来说，如果某个领域的核心知识不在预训练范围内（企业私有安全规则、自定义框架约定），AI Agent 的表现大概率会向 CL-Bench 的 17-24% 靠拢。
四、从 Attention 机制到安全分析
4.1 为什么"找东西"行、"学东西"不行
为了搞明白上面的问题，我去补了一些 Attention 机制的知识。AI 回答问题时，通过 Self-Attention 扫视上下文所有 token，打"相关性"分数，加权汇总：
Attention(Q, K, V) = softmax(QK^T / √d_k) · V
Q 是"我在找什么"，K 是每个 token 的标识，V 是实际内容。softmax 把分数归一化为概率（总和为 1），按概率加权读取 V。
softmax 的"总和为 1"带来一个关键后果——注意力稀释：上下文越长，每个 token 分到的权重越低。4K 扩到 200K，关键 token 的比例被稀释几十倍。这应该就是论文里"越长越差"的数学根因。
值得一提的是，论文叫"Context Learning"，但 Transformer 推理时权重是冻结的，本质上还是推理而非学习（学习 = 修改权重）。问题的根源在于 W_Q/W_K 是预训练时学出来的——它们只对预训练中频繁共现的 token 对有强匹配信号，对从没见过的 token，QK^T 分数缺乏区分度，模型看到了但分不清哪个重要。这个影响还会逐层累积：第一层没被充分关注的 token，信息几乎不会写入残差流，后续所有层都看不到它了。这也就是我们说的，模型不能理解 context 里的新知识。
检索任务有个救命特性：目标 token 匹配分数远高于噪音时，softmax 会集中注意力，像暗房间里找亮着的灯，房间再大也一眼看到。这就是"大海捞针"表现好的原因。而"学习"任务没有这种显著信号，虚构法律体系的条文、判例、定义散布各处，没有哪段匹配分数特别高，注意力被均匀稀释，越大越难。
还有两个叠加因素：RoPE（旋转位置编码）让远距离 token 注意力天然衰减，这就是"Lost in the Middle"现象；Transformer 固定层数的 forward pass 不管任务多复杂都一遍过，检索够用了，但学习新知识体系需要的计算复杂度远超固定层数能提供的。所以 CL-Bench 的 17.2% 可能不是"窗口不够大"，而是"计算深度不够"。
Chain-of-Thought 是变相增加计算深度的方法，但论文发现只多了 2.5%，CoT 增加的是串行深度，Context Learning 还需要并行宽度，一步步想不等于能想到"要把第 3 页和第 15 页和第 7 页放一起看"。
4.2 基模在安全分析中看到的和看不到的
带着这些理解，可以推演一下 AI 做代码安全分析时的表现。漏洞路径 Source → 传播 → Sink 上，AI 的注意力分布大概是这样的：
graph LR
A["Source<br/>@RequestParam<br/>注意力: 强"] -->|"赋值"| B["a = b<br/>注意力: 弱"]
B -->|"调用"| C["svc.process(a)<br/>注意力: 弱"]
C -->|"返回"| D["Sanitizer?<br/>clean(x)<br/>注意力: 中"]
D -->|"传递"| E["dao.query(x)<br/>注意力: 弱"]
E -->|"拼接"| F["Sink<br/>execute(SQL+x)<br/>注意力: 强"]
style A fill:#d32f2f,color:#fff
style F fill:#d32f2f,color:#fff
style D fill:#ff9800,color:#fff
style B fill:#e0e0e0,color:#333
style C fill:#e0e0e0,color:#333
style E fill:#e0e0e0,color:#333
两端的 @RequestParam、executeQuery 在预训练中频率极高，AI 一眼看到。中间的普通赋值和方法调用没有安全相关的词汇特征，注意力直接滑过，但恰恰是这些灰色节点构成了判断漏洞是否真实存在的全部依据。
举个例子：controller 里有 @RequestParam id 和 db.execute("SELECT * FROM " + tbl)，AI 很可能直接报"SQL 注入"。但 tbl 实际来自 config.getTableName()，跟 id 无关。AI 看到 source 和 sink 就连线了，没追踪中间数据流。SAST 引擎则逐步追踪赋值，精确判断 tbl 来源与 id 无关。
4.3 Agent + grep 能缓解吗
采用 Agent 可以很大程度上缓解直接使用基模的注意力问题，Agent 一步步 grep 追踪传播链，简单场景下确实能发现问题。但真实代码库里有几个问题：
- 文本匹配 vs 语义分析：变量改名（
input→data→payload）grep 就跟丢了，进了 Map/List 容器更是断链。SAST 在数据流层面操作，不受变量名影响。 - 路径指数爆炸：数据流分析不是一条路径，而是一棵不断分叉的大树，每条分支都可能很深。SAST 的算法天然就是遍历整棵树的，Agent 一次只能沿一条分支往下追，树一大就顾不过来了。
- 追得越多，忘得越多：论文已经证明越长越差。追几十条路径后上下文塞满，准确率反而下降。
- 没有终止条件：SAST 的不动点算法在"没有新传播"时自动停止。Agent 只能主观判断"够了没"，安全审计中这种不确定性不可接受。
这些问题虽然都能通过巧妙设计 Agent 进行一定程度的缓解，但目前看仍然无法替代传统程序分析技术。
五、SAST 的未来：不是被 AI 替代，而是被 AI 增强
5.1 两种认知范式
聊到这里我越来越觉得，SAST 和 AI 其实不在一个维度上竞争。SAST 像数学证明——从公理出发沿推导规则走，结论可验证可复现，不需要"注意力"，百万行代码照样跑。AI 像经验丰富的老审计员——直觉很准但说不清为什么，也没法保证不遗漏。
短板恰好互补：
| SAST | AI | |
|---|---|---|
| 确定性 | 路径存在就能找到 | 陌生场景 55-66% 信息被忽略 |
| 完备性 | 枚举所有路径 | 只看"感觉重要的" |
| 可复现 | 同代码同结果 | 有随机性 |
| 语义理解 | 不理解代码意图 | 能判断函数在做什么 |
| 框架适配 | 需要手写规则 | 预训练覆盖主流框架 |
| 误报处理 | 高误报率 | 能结合业务上下文过滤 |
5.2 AI 可以做什么
这里只是直观浅略的例子，有兴趣的朋友可以在评论区留言或者加入用户交流群深入讨论，AI 到底能给程序分析带来什么
-
SAST 追踪到程序分析技术难以分析的函数时，AI 可以结合知识猜一下函数作用，比如 "它对 SQL 特殊字符做了转义，算 sanitizer"。这些可以有效利用 AI 的训练知识。
-
SAST 报了一条 SSRF 路径，AI 可以看路由配置和部署信息，判断"这个 endpoint 只有内网可访问，风险较低"。这种业务语境判断 SAST 做不了。
-
新框架发布时，AI 可以读文档提取"哪些 API 是 source、哪些是 sink、哪些有内置防护"，生成 SAST 规则配置。"从文档提取结构化信息"本质是检索任务，AI 做得不错。
这些场景有一个共同特点：SAST 已经帮 AI 找好了重点。回到 Attention 机制的原理，AI 对陌生信息"分不清轻重"是因为 W_Q/W_K 没有对应的匹配先验，但如果我们通过提示词人为标注重点（比如 [SOURCE]、[SINK]、[待判断sanitizer]），就相当于给陌生信息借了一个预训练中熟悉的信号强度，模型认识这些标记词，注意力自然会聚焦到被标注的内容上。只要每次给的重点不太多（标太多又会互相稀释），这个策略是有效的。
换句话说，SAST 充当了 AI 的"注意力导航仪，先系统性地找出所有可疑点，再逐个交给 AI 做精准的语义判断。
5.3 我们到底即将失业还是迎来机遇
纯 SAST 的精确度天花板已经接近（核心算法成熟几十年了），但误报率和框架覆盖面还有很大空间，这两个方向恰好是 AI 能帮上忙的。反过来，"纯 AI 安全扫描"在当前技术路线下，短期大概率不会成为主流，CL-Bench 揭示的 Attention 局限不是短期能突破的，论文自己也指出需要架构创新（显式记忆、多遍处理等），不是简单加大模型就行。
因此，SAST 短时间不会消亡，它会进化。AI 不是替代者，而是新器官。
六、一些零星的想法
-
在 CL-Bench 的任务中 GPT-5.2 不如 5.1，提醒我们模型迭代不是单调递增的。5.2 的失败模式是"无法维持因果链"和"违反明确约束"，在安全领域都是致命的。需要高可靠性的场景不能盲目追新。
-
很早之前有个榜单 DeepSeek V3 比 DeepSeek R1 编程能力差不多，有时还要更强，当时感触不深，这篇文章进一步强化这个印象，推理增强只多了 2.5%（GPT-5.1），而且 Kimi K2 有 5.7%、Qwen 3 Max 反而 -0.4%。这组数字让我觉得 Context Learning 的瓶颈可能不在"想得不够深"而在"看得不够全"。
-
全新场景中，55-66% 信息被忽略，编程辅助场景可以接受，安全扫描场景不可接受，一个被忽略的 SQL 注入路径就是一个可被利用的漏洞。
原文链接：mp.weixin.qq.com/s/LgHeoZqDA… 欢迎关注【开放式安全基础设施】公众号，与上千名技术精英交流技术干货&程序分析
