2026 年，由 Steinberg 与 Gal 提交的 MOSAIC-Bench（arXiv 2605.03952）把「编码智能体是否会被诱导写出漏洞」这件常被口头讨论的事，做成了可复现的基准。它的核心方法是组合式漏洞诱导：不是用一个固定的恶意提示，而是把多个攻击片段拼装成一条三阶段攻击链，逐步把原本谨慎的智能体带离安全轨道。整套基准包含 199 条这样的攻击链，覆盖从诱导入手到最终提交危险改动的完整路径。
199 条三阶段攻击链，测的是「端到端失守」
传统的安全评测常停留在单轮提示能否骗过模型；MOSAIC-Bench 要测的是端到端：智能体从接收任务、检索上下文、编写代码，到最终把改动作为补丁提交，整条链路上有多少环节会被攻破。三阶段的设计让攻击可以层层递进——先建立可信语境，再引入看似合理的偏差，最后在提交环节放大风险。这种组合式思路更贴近真实威胁：攻击者很少一次得手，而是靠多步铺垫逐步削弱防御。
在被测的 9 个编码智能体上，端到端攻击成功率（ASR）落在 53% 到 86% 的区间。这个跨度本身就有信息量：同样是编码智能体，有的把近九成攻击链跑通，有的只失守一半出头，说明「是否做安全加固」与「加固做到哪一层」会显著改变结果。对采购方，这份区间比任何单点演示都更有参考价值——它把「编码智能体可能不安全」从印象变成可比较的梯度。
评审智能体也会放行漏洞
MOSAIC-Bench 还顺带测了另一类角色：负责审查代码的智能体。结果中，评审智能体对含有漏洞的差异（diff）放行的比例达到 25.8%。这意味着风险不只出现在「写代码的人」，也出现在「审代码的人」——当智能体既写又审，漏洞可能在两个环节同时漏网。这一发现对「用智能体做代码评审」的实践是一记提醒：评审智能体若沿用与编码智能体相同的脆弱假设，就会把单点失守变成双重失守。
把视线拉回整体，MOSAIC-Bench 的价值在于提供了一把可复用的尺子。过去判断编码智能体安不安全，多依赖零散的 anecdote；现在可以用统一的攻击链集合去横向比较不同模型、不同加固策略下的端到端表现。对开发者，这意味着安全评测可以像功能测试一样纳入 CI：每次模型或提示词变更，都跑一遍组合式攻击链，看失守率是否抬头。当然，基准本身也有局限——攻击链是固定的，真实攻击者会自适应，长期看需要持续扩充与演化。
需要谨慎对待的边界
客观地说，53%–86% 的 ASR 与 25.8% 的评审放行率是基准口径，实际部署中的失守率还受代码库上下文、权限边界与人类兜底流程影响。基准测的是「在没有额外防护下智能体能走到哪」，不等于「上线后一定会出事」。另一方面，攻击链集合需要随新技法更新，否则评测会随时间失真。对工程团队，更务实的取舍是把 MOSAIC-Bench 当作上线前的红队项之一，与静态分析、人工评审、最小权限策略配合使用，而不是把它当成充分的安全证明。对国内代码智能体团队，MOSAIC-Bench 这类基准提示：安全评测应当前置到研发闭环里，而不是等产品上线后再补，否则失守率会成为规模化之前最难啃的硬指标。它同时也给采购方一个可操作的验收项：在选型时直接问厂商，能否跑通公开的组合式攻击链基准。对安全团队而言，把基准从论文里的数字变成 CI 里的门禁，才是它真正落地的标志。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。