AI 编码 Agent 在功能正确性这一项上已经做到了相当稳定的水平,但功能正确不等于安全。多项独立研究的结论高度一致:在最先进的模型上,40% 到 50% 的生成代码样本至少包含一个安全漏洞。这个数字在 Claude Fable、Claude Opus、GPT Sol 这些一线模型上同样成立。换句话说,企业每花一次 token 让 Agent 生成代码,差不多有一半的概率会顺便带一个可被利用的漏
AI 编码 Agent 在功能正确性这一项上已经做到了相当稳定的水平,但功能正确不等于安全。多项独立研究的结论高度一致:在最先进的模型上,40% 到 50% 的生成代码样本至少包含一个安全漏洞。这个数字在 Claude Fable、Claude Opus、GPT Sol 这些一线模型上同样成立。换句话说,企业每花一次 token 让 Agent 生成代码,差不多有一半的概率会顺便带一个可被利用的漏洞进去。这种代价在生产环境里是直接可量化的——它不是未来的隐患,而是明天就被扫描器报告出来的事。 Security Cards 项目背后是一个博士课题,主攻方向正是 LLM 生成代码的安全问题。研究里观察到的现象相当一致:这些模型往往缺乏库特定的安全知识。它们可能不知道某个配置项不再安全,可能漏掉某个版本之间的验证步骤,也可能完全没意识到两个相邻版本之间某个安全相关行为发生了改变。模型的训练数据是海量的、宽泛的,但具体到某一个库、某一个版本的某一个 API,这些信息要么不在训练集里,要么散落在文档、源码、测试、配置之间,模型很难把它捡起来。
二、Security Cards 是什么
Security Cards 的设计是给每个库生成一张张结构化的安全卡牌,卡牌本身是给 Agent 读的。每张卡包含一个清晰的 Use when 部分,说明它适用在哪些场景;一条或多条具体的可执行规则;以及配套的解释和短代码示例。每个库还有一张 Security Blueprint,提供高层概览,Agent 和开发者都可以从 Blueprint 入手,需要时再下钻到具体卡片。
数据来源是一个混合流程——确定性抽取加 AI 抽取,再叠多层自动化校验与人工审核。迭代到当前阶段后,需要人工介入的卡牌已经降到 10% 以下,但生成出来的安全指引,在 Claude Code + Opus 上跑 BaxBench 基准,能把不安全代码率砍掉 72% 以上。
使用方式很简单:装上 skill,Agent 就会自动遵循三步流程——读 Security Cards skill,根据用户提示与 skill 内容,拉取一个或多个库的相关安全卡,把这份安全指引当作上下文,再去实现或审查代码。整个过程里,skill 不会访问、不会传输用户代码——它只在 Agent 那一侧提供知识层,代码本身仍然只去它本来会去的地方。
三、BaxBench 的数据
BaxBench 是这套评估的核心基线。它由 ETH Zurich、LogicStar.ai、UC Berkeley、INSAIT 联合发布,包含 392 个任务,覆盖 28 个后端场景、14 个框架、6 种编程语言。每个任务给出文本描述与 OpenAPI 规范,要求 Agent 生成一个完整的后端应用,然后既跑功能测试,又跑端到端的漏洞利用测试。这个设计的好处是它同时衡量两件事:Agent 能不能写出能跑的代码,以及写出来的代码能不能被攻破。
Security Cards 项目在 BaxBench 上跑了 216 个任务,横跨 27 个场景、8 个框架、4 种语言,模型选了 Claude Code + Opus 4.7 与 Claude Code + Haiku 4.5 两个档位。三个被追踪的指标分别是:Insecure and correct——功能测试通过、但至少挂掉一条安全测试的比例,这是首要安全指标,因为它把安全失败从实现失败里剥离出来,直接衡量 Agent 完成功能任务却留下漏洞的频率;Secure pass@1——功能与安全测试同时通过的比例;Functional pass@1——功能测试通过的比例。
结果相当干净:Opus 4.7 上 Insecure and correct 从 23.9% 降到 6.6%,相对降幅 72.3%;Haiku 4.5 上从 35.6% 降到 14.3%,相对降幅 59.8%。Secure pass@1 分别提升了 21.4% 与 27.5%。Functional pass@1 的相对损失只有 0.5% 到 5.0%。换句话说,Security Cards 在几乎不牺牲功能正确性的前提下,把安全失败率砍掉了六到七成。
四、为什么结构化卡牌这件事有效
把这件事往后退一步,会发现它有效的原因并不神秘,而是工程上相当具体。
- 第一,模型的安全失败通常是知识失败,而非推理失败。Agent 知道要校验输入、要避免 SQL 注入、要正确使用加密 API,但它不知道某个具体的库在某个具体的版本里,某个具体的 API 已经被弃用,或者某个参数已经不再安全。把这一层知识显式地塞进上下文,推理失败立刻被回避。
- 第二,结构化的卡牌让检索变得精确。一张卡对应一个库、一组场景、一组规则。Agent 拿到任务之后,只需要拉相关的那几张卡,而不是把整个安全知识库都丢进上下文。这与 agent-desktop 用可访问性树取代截图是同一类思路——结构化访问优于模糊匹配,token 成本更低,误用率也更低。
- 第三,卡牌的写法本身是 Agent-native 的。Use when、规则、解释、代码示例,这套格式对 LLM 来说就是它最擅长消化的一类输入——比自由文本的安全建议更稳定,比纯规则列表更可读。
- 第四,卡牌的覆盖率是真实的工程问题,而不是概念演示。80 多个库、13 种语言,覆盖的是企业后端开发里真正高频使用的栈——Django、Flask、Spring、Express、FastAPI、SQLAlchemy 都在其中。这意味着卡牌不是一篇博客里的概念,是一个可以立刻被 CI、PR 检查、Agent 工作流调用的知识库。
五、对企业级代码审计的启示
把这件事映射到企业内部常见的代码审计与安全工程实践,会得出几条相当具体的判断。
- 第一,企业内部的安全审计,正在从事后扫描转向事前上下文。SAST、DAST、SCA 这些工具仍然必要,但它们捕获的是已经写出来的代码里的漏洞。Security Cards 这类项目把安全知识前置到 Agent 的上下文里,在代码生成的环节就避免漏洞进入代码库。两者不是替代关系,而是分层防御——前置避免大多数已知模式,后置捕获未知的与残留的。
- 第二,Agent 写的代码这个类目,在企业内部需要一个独立的安全治理策略。传统的代码审计基于开发者是人这一假设,审查的颗粒度、节奏、复审层级都是按人来设计的。Agent 生成的代码速度更快、批量更大、模式更一致,这要求审计流程具备更高的吞吐与更细的反馈粒度。Security Cards 提供的卡牌机制可以接入企业内部的安全知识库——企业内部常用的库、内部规定的安全模式、历史漏洞清单,都可以走同一套流程变成 Agent 可调用的卡牌。
- 第三,72% 这个数字给了一个相当具体的 ROI 锚点。一个企业内部代码审计流程,如果能在生成端把功能正确但有漏洞的比例砍掉六到七成,那么后置扫描的成本、修复成本、安全事件的概率,都会按这一比例下降。这件事在算账的时候是直接可量化的。
- 第四,卡牌的可信度取决于它的维护成本。Security Cards 项目目前把需要人工审核的卡牌比例降到 10% 以下,但这并不意味着企业可以照搬。每个企业内部的安全规范、内部漏洞库、合规要求,都需要走同样的自动化抽取加人工审核流程。这个流程本身的工程成本,以及它对内部安全专家时间的占用,是企业真正需要评估的项。
- 第五,卡牌与 Agent 的集成方式,正在变成一个新的标准件形态。npx skills add 一行命令安装,skill 文件被 Agent 自动发现并在相关任务里调用——这条工作链对企业内部意味着,可以照同样的模式分发企业内部的安全卡牌、合规卡牌、性能卡牌,而不是每加一类规则就改一次 Agent 的系统提示。skill 这一层抽象,实际上把知识与 Agent 解耦了。
把视角拉远一点,Security Cards 给出的最大启示不是某一种安全工程的新工具,而是一种更一般的规律:Agent 的能力边界,几乎总是由它能访问的结构化知识决定。Web 上是 DOM 与 ARIA,桌面上是可访问性树,代码上是安全卡牌。模型在持续变强,但决定落地质量的,始终是 Agent 能不能稳定地拿到刚好对的那一份上下文。Security Cards 把这件事具体到了 80 多个库、13 种语言、72.3% 这个数字——它把安全知识从一个不可调用的概念,变成了一个可以一行命令安装的工程产物。
结语:Agent 的能力边界由结构化知识决定
把视角拉远一点,Security Cards 给出的最大启示不是某一种安全工程的新工具,而是一种更一般的规律:Agent 的能力边界,几乎总是由它能访问的结构化知识决定。Web 上是 DOM 与 ARIA,桌面上是可访问性树,代码上是安全卡牌。模型在持续变强,但决定落地质量的,始终是 Agent 能不能稳定地拿到刚好对的那一份上下文。Security Cards 把这件事具体到了 80 多个库、13 种语言、72.3% 这个数字——它把安全知识从一个不可调用的概念,变成了一个可以一行命令安装的工程产物。