代码审查智能体跑得越快，企业越该留住漏洞证据链

两天找到100多个关键漏洞，听起来像安全团队终于等来了“代码雷达”。但我更在意另一个问题：当智能体把告警数量推到人工看不过来的规模，团队凭什么相信其中一条值得半夜拉起研发？8月18日，Google Threat Intelligence公开了其内部多智能体代码审查框架 AVDH 的方法与个案：在一次涉及被盗企业代码库的事件响应中，它在两天内发现100多个经确认的关键漏洞；其过往工作还促成12个已分配 CVE。这里的数字属于该团队披露的具体实践，不等同于任何企业部署后都能获得的效果。来源：Google Cloud，2026年8月18日

这件事的价值，不是又多了一个会找 Bug 的模型，而是它把“发现漏洞”拆成了能被追问、能被推翻、也能被交给专家复核的过程。对准备将智能体接入研发、运营甚至营销生产链的企业而言，这同样是一条很重要的生产原则：自动化结果不能只交答案，还要交证据。

先画对“地图”，再让智能体找问题

许多企业把 AI 审查理解为“把整个仓库塞进去扫描”。AVDH 的顺序恰好相反：先由探索智能体识别系统用途、文档、排除目录和专业领域，再汇成威胁模型；在继续分析前，顾问先审核这张模型。原因很朴素：没有攻击面、业务逻辑和可达性这些上下文，模型即使找到了可疑代码，也可能把只有管理员能访问的路径、从未执行的测试代码，和真实暴露面混在一起。

真正有用的智能体，不是从第一分钟就给结论，而是先让团队确认：它此刻究竟在看什么、为什么看、哪些范围不该看。

随后，框架再并行寻找入口点与用户输入，并把跨文件的权限、路由、清洗逻辑补齐。Google 的描述提醒我们：漏洞常藏在多层函数调用和多个文件之后；脱离上下文的单点判断，既容易漏报，也容易误报。来源：Google Cloud，2026年8月18日

把“可能有问题”与“可以处置”隔开

更值得借鉴的是它不让同一个智能体既自由猜想又给自己盖章。访问控制和数据流智能体先广泛生成假设；之后由多名验证智能体独立核验，再由综合智能体按威胁模型给出三种结果：确认、证伪或拒绝。到了最后，专家还会动态复现攻击路径、运行 PoC；不能通过测试的发现被丢弃。来源：Google Cloud，2026年8月18日

这给企业一个反常识判断：高质量并不等于让智能体少说“不确定”。恰恰相反，系统应允许它提出足够多的候选，再把“候选”“证伪”“已确认”分开流转。否则，看似节约人力的自动化，只是把筛选成本和业务风险一起转移给接收结果的人。

企业可以先建立一张“漏洞证据链卡”

我建议把每个可升级的发现固定成一张卡，而不是一段漂亮摘要。组织层写清系统范围、风险等级、升级责任人与对外披露边界；业务工作台沉淀架构文档、资产清单、软件物料清单、规则版本和历史处置；智能体层必须回传入口点、关联代码、数据或控制流、验证结论、置信依据和待人工确认项。没有这些字段，就不允许自动进入修复排期。

这也是 STARBOX 更关心的落地方式：组织不是把一个“万能安全 Agent”丢给团队，而是在 BOX 中把可信知识、场景模板、权限与验收样例组织起来，让不同智能体在清晰边界内协作。DDABC 的反馈链路则应收集误报、遗漏、人工改写和复现结果，回写到规则、知识或流程中。它的目标不是让机器替人背书，而是让人的专业判断被稳定地放大和复用。

从一个高价值场景开始，而非一口气接管安全

第一步，可以选一类边界明确、人工复核已经成熟的任务，例如某个服务的鉴权检查或发布前代码审查；第二步，为已知漏洞和无漏洞样本建立可复跑的基准；第三步，再看每次版本更新后，误报、漏报、复核耗时和修复闭环是否真的改善。Google 也强调其评估需配合人工审阅，并用经专家验证的合成代码库避免模型只是在“背答案”。来源：Google Cloud，2026年8月18日

智能体会让企业更快发现异常，但只有当每个结果都能回到证据、责任与验证，速度才会变成安全能力。下一次你评估一个 AI 审查工具时，不妨少问一句“它能找到多少 Bug”，多问一句：当它说“这里有问题”，我们能否清楚地知道为什么相信它、谁来决定下一步？