现代漏洞管理面临一个残酷的现实：根据Mandiant M-Trends 2026报告，漏洞的平均利用时间已经降到了-7天，意味着漏洞在被发现前一周就已经被攻击者利用。安全团队的传统做法根本跟不上这个节奏，即使引入LLM代理自动挖洞和修复，如果缺乏成熟的集成流程，反而会引入新的架构风险，比如代理被提示注入劫持、泄露敏感代码、或者生成破坏性命令。核心痛点在于：如何让AI加速的同时，不把安全工具本身变成攻击入口。

Mandiant的解法是一套分层操作护栏。首先，基于Google的Secure AI Framework，把代码库本身视为不可信输入，必须在代理层之前用确定性策略引擎和专用守卫模型（如Model Armor）过滤敏感数据和恶意注入。代理工作负载必须运行在严格隔离的沙箱容器中，权限动态限制，且使用短期的JIT令牌绑定到特定仓库和分支，防止横向移动。对于企业级漏洞管理，先用RBVM（基于风险的漏洞管理）公式对资产、威胁和漏洞严重性加权评分，将海量发现归一化，再让LLM辅助合成非结构化威胁情报来加速优先级排序。对于产品安全，优先针对记忆不安全语言（C/C++）的代码库进行代理审计，因为这类漏洞有明确的“崩溃或不崩溃”的二进制判定，可以配合自动沙箱生成可复现的PoC。同时，必须设置执行超时和迭代限制，防止代理陷入无限循环浪费资源。

这篇文章最核心的洞察是：LLM在漏洞发现上擅长局部语法异常，但无法理解架构层面的业务意图。因此，人类威胁建模仍然是不可替代的环节——比如问“为什么这个微服务有宽泛的数据库读取权限？”这种问题。长远来看，LLM的真正价值可能不是替代安全工程师，而是帮助将记忆不安全代码库迁移到Rust等安全语言，把过去不现实的工程需求变成可操作的任务。对于安全团队，部署AI代理不是减少工作量，而是把工作从手动挖洞转向验证AI生成的PoC是否真正可被利用。这篇文章给出了一个务实的路径：在保持架构可控的前提下，用AI缩小攻击面，同时通过设计消除整类漏洞。