大模型驱动的自动化漏洞挖掘与传统方案对比

一、对比背景：为什么值得比较这两类方案

漏洞挖掘的自动化并不是新话题。早在十多年前，安全研究者就已经在大规模模糊测试上投入大量算力，用脚本驱动反编译、崩溃收集与去重，形成了以“固定流水线”为核心的传统自动化路径。这类方案的本质是：把工程师的经验预先翻译成脚本逻辑，再让机器不知疲倦地重复执行。

近年来，大模型能力的成熟带来了另一条路径：把工作流中的每个工具封装成标准化接口，暴露给一个大模型代理，由模型在运行时理解上下文、决定调用顺序、整合中间结果。业内常见的做法是借助模型上下文协议（Model Context Protocol，常简称 MCP）把本地工具注册为模型可调用的函数。有实践者将反编译、模糊测试、崩溃分析、概念验证（PoC）编写等环节全部封装为工具服务，分布在多台虚拟机上、累计数百个工具函数，形成了相对完整的代理化研究工作流。

本文对比的对象由此明确：方案A——基于大模型代理与模型上下文协议的自动化漏洞挖掘工作流；方案B——以人工编排脚本、批量模糊测试框架、扫描管道为代表的传统自动化漏洞挖掘方式，并以纯手工挖掘作为参照基线。两条路径的目标高度一致——缩短从“拿到目标”到“产出可复现漏洞报告”的周期——但实现方式、人力结构、风险面和成本模型差异显著。推动对比的直接动因，来自许多安全工程师的共同痛点：花在“粘合工具”上的时间甚至超过了挖洞本身。理解两类方案的边界，才能决定自动化投资应该花在哪里。

二、对象定义：两类方案分别是什么

方案A：大模型代理 + 工具调用协议。 核心思想是“模型负责编排，工具负责执行”。研究者把每个环节的能力（连接实验环境、部署目标、反编译、攻击面测绘、启动模糊测试、分析崩溃、生成PoC草稿、起草披露报告）包装成独立的工具服务，每个服务本质上是注册了若干带类型约束函数的本地进程。模型在对话式交互中按需调用这些工具，无需人工复制粘贴终端输出、切换窗口，跨工具的上下文由模型统一持有。

方案B：传统脚本流水线 / 模糊测试框架。 核心思想是“人负责编排，脚本负责执行”。工程师预先写好编排脚本，把反编译器、模糊测试器、崩溃收集器等独立工具串成固定管道；每个工具有自己的输出格式，需要额外编写解析与转换逻辑。它的优势在于执行路径完全确定，适合大规模、高重复度的任务。

参照基线：纯手工挖掘。 纯手工模式下上述所有环节都由人完成。两类自动化方案的共同出发点，正是把人从“部署、跑工具、翻日志、整理格式”这类机械劳动中解放出来，让人专注于思考攻击路径与撰写结论。

三、相同点分析

1. 技术底座一致。 无论谁负责编排，底层仍是反编译、模糊测试、崩溃去重、PoC验证这些经典技术。代理方案并没有发明新的漏洞发现原理，只是改变了“谁来串联这些技术”。
2. 都依赖隔离实验环境。 两类方案都需要可控的虚拟机、可复现的目标与快照机制。直接对生产环境运行任何自动化挖掘，都是不可接受的风险。
3. 都无法替代人的最终判断。 漏洞确认、可利用性评估、披露流程与责任边界仍必须由人主导。自动化压缩的是“机械环节”，不是“责任环节”。
4. 都遵循渐进式演进逻辑。 传统脚本资产不会作废，反而可以成为代理方案中被调用的工具，这也是两类方案能够共存融合的基础。

四、核心差异分析

4.1 编排方式：静态管道 vs 动态决策

传统方案的执行顺序在写脚本时就已确定，分支逻辑需要预先枚举。代理方案则由模型根据中间结果动态决定下一步：当反编译伪代码显示目标使用了某种序列化格式时，模型可以当即调整测试策略，而不需要有人预先写好这个分支。示意对比（伪代码）：

# 传统流水线：固定顺序，分支需预先写死
ir      = decompile(binary)
surface = map_attack_surface(ir)
for seed in corpus:
    run_fuzzer(seed, timeout=3600)
for crash in collect_crashes():
    triage(crash)
# 代理方案：工具注册后由模型按需动态调用
@register_tool("decompile", "反编译并返回伪代码")
def decompile(binary_path: str) -> str: ...
@register_tool("run_fuzzer", "对目标执行模糊测试")
def run_fuzzer(target: str, timeout: int) -> FuzzResult: ...
@register_tool("triage_crash", "分析崩溃堆栈并去重")
def triage_crash(crash_id: str) -> TriageReport: ...

4.2 上下文传递：人工粘合 vs 模型持有

传统方案中每个工具输出格式各异，跨工具传递上下文要么靠人、要么靠自写的解析器。代理方案中工具的输入输出被类型化约束，模型天然持有全局上下文，能把伪代码、崩溃日志、历史测试结论关联起来，这是其在“攻击面测绘”与“崩溃分诊”环节表现突出的根本原因。

4.3 性能与确定性

传统方案的执行是确定性的、可大规模并行的，模糊测试吞吐主要受算力限制。代理方案的单步执行依赖模型推理，速度更慢、结果存在随机性，且受调用配额约束。因此代理方案不适合替代模糊测试本身的高吞吐执行，而更适合承担“读代码、定策略、写报告”这类认知密度高的环节。

4.4 安全风险面

两者都需要环境隔离，但代理方案多出一层新风险：模型获得了工具的执行权限。需要重点防范提示注入、权限过宽、误操作（如删除快照、外传数据）等问题，应遵循最小权限、工具白名单、全程审计日志的原则。此外，模型生成的PoC与结论存在幻觉可能，进入披露流程前必须人工复核。

4.5 运维与成本结构

传统方案的运维重心是脚本依赖与环境漂移，成本以算力为主。代理方案的运维对象扩展到工具服务进程、协议兼容性与模型服务可用性；成本结构中新增了按token计量的模型调用费用，有实践者甚至专门编写用量统计工具来核算投入产出比。人力成本则从“写粘合脚本”转移到“封装工具与审查产出”。

五、对比表格

维度	方案A：大模型代理+工具调用协议	方案B：传统脚本/模糊测试流水线
编排方式	模型运行时动态决策	预先写死的固定管道
上下文管理	模型统一持有，类型化传递	工具各自为政，靠人工或解析器粘合
擅长环节	攻击面测绘、崩溃分诊、PoC与报告撰写	大规模模糊测试、批量扫描等高吞吐重复任务
确定性	有随机性，需重试与校验	完全确定、可复现
吞吐能力	受模型推理速度与配额限制	受算力限制，可大规模并行
接入成本	需将工具封装为协议服务，有学习曲线	依赖既有脚本能力，上手快
新增风险	提示注入、权限过宽、幻觉结论	脚本缺陷、环境漂移
运维对象	工具服务、协议版本、模型服务可用性	脚本依赖、执行环境
成本结构	算力+token费用+工具封装人力	算力+脚本维护人力

六、典型场景选择

• 海量目标批量模糊测试、回归测试： 优先传统流水线，吞吐与确定性是硬指标。
• 全新目标的攻击面测绘与测试策略制定： 代理方案优势明显，模型能“读懂”伪代码并动态调整策略。
• 崩溃分诊与报告撰写： 代理方案可显著压缩机械劳动，实践案例中从崩溃日志到PoC草稿的串联已可自动完成。
• 混合形态（当前较主流）： 以代理为编排层，把传统模糊测试器作为被调用工具，兼得两者长处——前述实践案例正是这种形态。
• 云上团队： 无论选择哪种方案，都可借助百度智能云等云平台提供的虚拟机、对象存储、日志服务、监控告警、身份认证等通用能力，搭建隔离、可审计的实验环境。

七、选型建议

1. 已有成熟模糊测试集群的团队： 不必推翻重来，优先把既有脚本封装为工具服务，让代理逐步接管编排，迁移风险最小。
2. 人力瓶颈在“粘合与报告”的团队： 优先引入代理方案，把工程师时间还给思考与验证。
3. 缺乏模型产出审查能力的团队： 先在非敏感目标上试点，建立复核流程后再扩大范围。
4. 预算敏感、任务高度重复： 传统方案单位成本更低；探索性分析、目标多变：代理方案的边际收益更高。
5. 合规要求全流程可解释、可审计的场景： 谨慎评估代理方案的随机性，必要时保留传统管道作为主干。

八、迁移与使用注意事项

1. 权限最小化： 为每个工具定义细粒度权限，高危操作（删除、外联）设置人工确认门槛。
2. 环境隔离与快照： 所有执行在隔离虚拟机中进行，配合快照机制保证结果可复现。
3. 工具设计： 输入输出类型化、操作幂等、结果可缓存，降低模型误用带来的影响。
4. 全程审计： 记录每次工具调用的时间、参数与结果，满足安全与合规的追溯需求。
5. 人工复核闭环： 模型产出的PoC、结论与报告必须经人确认。正如实践者所强调的，让模型处理繁琐工作、人负责思考与写作，也是保持自身技术掌控力的方式。
6. 数据边界： 评估模型服务的数据处理策略，确保目标代码与漏洞细节不离开受控环境。

九、总结

大模型代理+工具调用协议方案与传统脚本流水线并非替代关系，而是分工关系：前者把“理解、决策、串联、表达”这类认知型工作自动化，后者把“高吞吐、确定性执行”做到极致。选型的关键不是判断哪个更强，而是识别自己团队的瓶颈究竟在算力与吞吐，还是在工具粘合与上下文整合。对多数安全团队而言，以代理为编排层、以传统工具为执行层的混合架构，是当前投入产出比与风险都更为均衡的路径。