「91% 能跑，只有 25% 能上线」：LSCBench 把 AI 编程 Agent 的安全税算出来了

赵达

先摆两个数字：91.3%，25.1%。

前者是六个前沿 AI 编程 Agent 里最强者在功能测试上的通过率；后者是同一个 Agent 在”功能对了并且安全”这个综合指标上的得分。换句话说，它交出来的代码，十份里有九份能跑，但只有两份半能放心上线。剩下五个 Agent 更惨，综合得分在 16.4% 到 24.7% 之间——没有一个能过三分之一。

这组数字来自 10 月 14 日更新在 arXiv 上的研究《Last Secure Code Benchmark: Is the Code You Vibe Secure?》（编号 2610.14766v1，简称 LSCBench）。据多家转述，作者包括新加坡国立大学和阿里（Qwen 团队）的人。测试规模不小：450 个任务，全部脱胎于 150 个真实世界漏洞，覆盖 24 个 CWE（通用缺陷列表）类别、7 门语言（Java、C、C++、JavaScript、Python、PHP、Go）。

这个测试聪明在哪：任务里不提安全，评分时实弹打靶

LSCBench 的设计是我见过最”阴”的一次：交给 Agent 的任务描述只要求功能，安全一个字都不提。然后评分阶段，拿当初那个真实漏洞的原始攻击，直接去打 Agent 生成的代码——攻击能复现，安全项直接判失败，哪怕功能测试全绿。

注意这不是静态扫描找 eval、exec 这种危险函数，而是把真实 exploit 重放一遍。静态规则 Agent 背得滚瓜烂熟，真刀真枪的攻击可糊弄不过去。

为什么一定会这样：模型只优化看得见的东西

这个结果一点不意外。模型优化的是可见的测试：函数返回值对不对、接口通不通、demo 跑不跑。安全是隐式需求——没人会在需求文档里写”不许 SQL 注入”，就像没人会在施工合同里写”不许楼着火”一样，它被默认了。而 LSCBench 整套设计就是赌这个默认不成立。

举个它要抓的典型差距：需求是”按请求里的 ID 查用户”，Agent 大概率写出字符串拼接的 SQL：

-- 功能全对，安全判死刑
query = "SELECT * FROM users WHERE id = " + request.params.id

而安全工程师会默认写参数化查询：

-- 功能全对，安全也过
query = "SELECT * FROM users WHERE id = ?"
db.execute(query, [request.params.id])

两份代码跑同一个功能测试，查回来的都是正确的用户记录，只有后者能扛住攻击重放。就这一行之差，乘以几百个任务、几十个漏洞类别，就是 91% 到 25% 的落差。

先泼一盆冷水：25% 是下限，不是上限

数字很吓人，但解读要准。LSCBench 测的是”任务里不提安全”这种最不利的场景——真实工作中，你把安全要求写进 prompt，Agent 的表现会好一些。所以 25% 不是 Agent 的安全天花板，而是默认行为的地板：你不说，它就是这个水平。

另外两点要说明：第一，参测的六个 Agent 具体是谁，各家转述口径不一（有报道点名登顶的是某 Claude 系 Agent），我就不点名了，数字本身比名字重要；第二，这是 2026 年 10 月的快照，模型迭代速度摆在那，半年后重测数字大概率会变。但这不改变结论的方向——”默认输出不安全”是系统性的行为模式，不是某个模型的偶发 bug。

这个榜单会改变什么：行业该换记分牌了

过去几年，HumanEval、SWE-bench 把整个行业训练成只看”做出来没有”的记分牌，coding agent 的营销话术也全围着这个转：通过率、解决率、排行榜名次。LSCBench 的潜台词是：这个记分牌不完整。一个工具可以在上面很好看，同时交出来的代码十有八九通不过一次真实攻击。

厂商其实已经闻到味道了，只是还没人敢把安全通过率印在官网上：10 月 Chrome DevTools 给 coding agent 加了 Agent Plugins 1.0，里面有个 --no-javascript-evaluation 选项，让开发者可以禁止 Agent 在调试页面时执行任意 JS；GitHub 在给企业客户推 push attribution（提交者身份归因），因为 Agent 生成的变更规模已经让 Git 原有的信任模型吃不消了。方向一致：权限、归因、执行限制正在变成开发工具的一等公民。LSCBench 只是第一个把”账单”摆上桌面的。

跟我之前两篇连起来看：第三块拼图齐了

10 月 15 日我写过，AI 让代码量涨了 30%，但交付原地踏步——卡在”评审瓶颈”上。10 月 18 日写了 OpenCode 的 API Key 泄露事件。现在 LSCBench 把第三块拼图补上了：代码不光要有人审，审的人还得懂安全——而最强的 Agent 交出来的活，四分之三都带着洞。

三组外部数字放一起看更扎心：JetBrains 的调研说，现在 90% 的开发者每周都在用 AI 编程 Agent；BairesDev 的调研说，开发者每周大约 80% 的时间花在评审 AI 生成的代码上；Stack Overflow 2025 的调查里，81% 的开发者担心 AI 工具的安全和隐私问题。用得最猛的时候，恰恰是输出最不安全的时候——这笔”安全税”，以前没人定价，现在 LSCBench 给出了数字。

实战里怎么办：三条，不说废话

第一，把安全写进需求。 给 Agent 的任务描述里显式加上安全要求：参数化查询、输入校验、最小权限、敏感操作二次确认。不写，它默认不做——LSCBench 已经用 450 个任务证明了这个行为模式。别指望”它应该懂”，显式需求才进它的优化目标。

第二，测试绿了不等于能合。 Agent 交的 PR，默认按”功能对了、安全没看”处理。关键路径——鉴权、支付、数据读写、对外接口——人工审一遍，或者至少跑一遍安全扫描再合。评审时间省不掉，10 月 15 日那篇已经算过这笔账了。

第三，给 Agent 的缰绳收紧。 最小权限、沙箱里跑、不碰生产密钥和真实用户数据。VS Code 1.142 刚加了管理员对 Agent 权限的管控（我 10 月 16 日写过），Chrome DevTools 也在给 Agent 加执行限制——工具厂商已经在补这一课，你自己的工作流别落后。

一句话

功能正确是 Agent 的强项，安全是它的系统性盲区。以后评估 coding agent，别再只看”做出来没有”那种榜单了，加一个”做出来安不安全”的维度。LSCBench 干的就是这件事，数字很难看，但难看的数字比好看的榜单有用。

来源：

返回首页
赵达的个人网站 © 2009 - 2026 / Github - RSS

本站内容采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可