1. 为什么我要自己造一个漏洞扫描 Agent做安全审计这行的朋友应该都有体会传统漏洞扫描器用起来越来越像在开盲盒。你配好目标、选好策略、点下扫描然后等上几十分钟甚至几个小时最后拿到一份动辄几百页的报告里面塞满了误报、低危噪音和一堆疑似存在的模糊结论。真正需要立刻处理的高危漏洞反而被淹没在信息洪流里。我最初的想法很简单能不能让大模型来当这个筛子和分析师把扫描器吐出来的原始结果做二次研判自动判断哪些是真问题、哪些是误报、优先级怎么排、修复建议怎么写。市面上已经有不少把 LLM 接进安全流程的尝试但大多停留在把报告丢给模型让它总结这种浅层用法实际用起来问题很多——模型会幻觉、会漏判、会对上下文理解不到位。于是我决定自己动手用 workbuddy 搭一个真正能跑起来的漏洞扫描 Agent。核心思路是双模型驱动DeepSeek 负责深度推理和漏洞研判laya 负责结构化解析和任务编排两者分工协作再配合一套可插拔的扫描工具链形成一个从发现到研判到报告的完整闭环。这套东西跑通之后我把它用在了自己的几个测试靶场和内部资产上效果比我预期的要好不少。这篇文章我会把整个开发过程拆开讲清楚为什么选这两个模型、Agent 的架构怎么设计、扫描工具怎么接、误报怎么压、实际跑起来踩了哪些坑。如果你也在做 AI Agent 相关的安全工具或者单纯想看看一个能落地的 Agent 是怎么从零搭起来的应该能拿到一些能直接抄的东西。2. 双模型分工DeepSeek 和 laya 各自该干什么2.1 为什么不用单模型硬扛一开始我也想过直接用一个能力强的模型把所有活都干了不就行了实测下来不行。漏洞扫描这个场景对模型的要求其实是分裂的结构化解析扫描器输出的 XML、JSON、文本报告格式五花八门需要模型稳定地把非结构化内容转成规整的数据结构。这个任务要求确定性高、格式稳定、不能自由发挥。漏洞研判判断一个 SQL 注入告警是真漏洞还是误报需要结合请求响应、参数上下文、业务逻辑做推理。这个任务要求推理深度够、能处理长上下文、有一定的安全领域知识。这两类任务用同一个模型要么解析不够稳要么研判不够深。所以我把它们拆开让每个模型干自己最擅长的事。2.2 DeepSeek 在 Agent 里的角色定位DeepSeek 我主要用它做研判层。具体来说扫描器吐出来的每一条原始告警都会经过 DeepSeek 做一轮分析输出结构化的研判结果{ vuln_id: scan-2024-001, original_alert: SQL Injection in /api/user?id1, verdict: true_positive, confidence: 0.87, severity: high, reasoning: 参数 id 直接拼接进 SQL 查询payload 返回了数据库报错信息且响应时间存在明显延迟差异符合布尔盲注特征, remediation: 使用参数化查询对 id 做类型强校验, false_positive_reason: null }选 DeepSeek 的核心原因是它在长上下文推理和中文安全语境上的表现比较稳。漏洞报告里经常夹杂大量中文描述、业务注释、自定义规则名DeepSeek 对这些内容的理解明显比一些纯英文优化的模型要顺。另外它的推理链输出比较克制不会像某些模型那样过度发散这对需要稳定输出的研判任务很关键。提示研判层一定要让模型输出结构化 JSON而不是自然语言。自然语言结论没法直接进下游流程还得再解析一遍纯属给自己找麻烦。2.3 laya 负责的结构化解析与编排laya 在这个 Agent 里承担的是解析层和编排层的工作。扫描器原始输出往往是一大坨文本或者嵌套很深的 XML直接丢给研判模型会浪费大量 token 在无关内容上。laya 先把这些内容做清洗、抽取、归一化把每条告警拆成标准字段再决定哪些需要送进研判、哪些可以直接归档。laya 的另一个作用是任务编排。一个完整的扫描流程包含很多步骤目标发现、端口探测、指纹识别、漏洞扫描、结果聚合、研判、报告生成。这些步骤之间有依赖关系有的可以并行有的必须串行。laya 负责维护这个流程状态决定下一步该调哪个工具、该不该触发研判、研判结果怎么回写。我实测下来把解析和编排交给 laya 之后整个 Agent 的 token 消耗降了大概四成因为送进 DeepSeek 的都是已经清洗过的关键信息没有冗余噪音。2.4 两个模型之间的数据流设计两个模型不是各干各的中间的数据流设计很关键。我的做法是laya 解析扫描结果产出标准化的告警列表对每条告警做预筛明显是信息级的直接归档可疑的送研判DeepSeek 对可疑告警做研判输出结构化结论laya 接收研判结果做去重、聚合、优先级排序最终生成报告同时把研判结论回写到知识库供后续同类告警参考这个流程里有个细节值得说预筛规则很重要。如果所有告警都送 DeepSeek成本会爆炸而且很多低危告警根本不需要模型介入。我设的预筛规则是——CVSS 评分低于 4.0 且没有明确利用路径的直接归档涉及注入、反序列化、权限绕过这类高危类型的无条件送研判。3. Agent 的整体架构与 workbuddy 的落地方式3.1 分层架构从工具层到决策层整个 Agent 我分成了四层每层职责清晰方便单独替换和调试层级职责主要组件工具层执行具体扫描任务端口扫描、指纹识别、POC 引擎、爬虫解析层结果清洗与归一化laya 解析器、字段映射、去重研判层漏洞真伪与优先级判断DeepSeek 推理、置信度打分编排层流程控制与状态管理workbuddy 任务调度、状态机这样分层的好处是任何一层出问题都能快速定位。比如研判结果不准我只需要调研判层的 prompt 和预筛规则不用动工具层。工具层想换扫描引擎也不影响上面的逻辑。3.2 workbuddy 在项目里的实际作用workbuddy 在这个项目里主要承担任务编排和 Agent 运行时的角色。它帮我解决了几个很实际的问题任务状态管理一个扫描任务可能跑几十分钟中间涉及几十次工具调用和模型调用workbuddy 帮我维护整个任务的状态断了能续、错了能重试。工具注册与调用我把扫描工具、解析器、模型接口都注册成 workbuddy 的 skillAgent 在运行时按需调用不用硬编码调用逻辑。上下文管理Agent 跑久了上下文会膨胀workbuddy 的上下文管理机制帮我做了裁剪和摘要避免 token 无限增长。具体配置上我把每个能力都封装成一个 skill比如port_scan、fingerprint_detect、vuln_scan、result_parse、vuln_judge、report_gen。Agent 的主循环根据当前状态决定调哪个 skillskill 执行完把结果回写状态循环继续。3.3 状态机设计让扫描流程可控可回溯扫描流程我用状态机来管核心状态有这么几个INIT - RECON - SCAN - PARSE - JUDGE - REPORT - DONE | | | v v v ERROR - ERROR - ERROR每个状态都有明确的进入条件、执行动作、退出条件。比如SCAN状态只有在RECON完成且发现了存活目标时才能进入JUDGE状态只有在PARSE产出了告警列表后才能进入。状态机的好处是可回溯。任何一步出问题我能清楚知道卡在哪个状态、上一步的输出是什么、该从哪里重试。实测中这个设计帮我省了大量排查时间尤其是扫描任务跑到一半失败的时候不用从头再来。3.4 工具链的接入方式与选型考量工具链这块我没有追求大而全而是按够用、可替换、输出可解析三个标准来选端口与指纹用轻量级的探测工具输出 JSON方便 laya 解析漏洞扫描接了一个支持自定义 POC 的引擎方便我针对特定场景写规则爬虫用无头浏览器方案能处理 JS 渲染的页面选型时我特别看重输出格式的规范性。有些扫描器输出的是花花绿绿的文本报告解析起来极其痛苦这种我直接排除。宁可功能少一点也要输出结构清晰因为解析层的稳定性直接决定整个 Agent 的可靠性。注意工具链接入时一定要做超时和异常处理。扫描工具卡死、返回空、返回格式错误都是常态Agent 必须能识别这些异常并做出合理反应而不是直接崩溃。4. 漏洞研判的核心逻辑怎么让模型少说废话多干活4.1 研判 Prompt 的设计要点研判层的 prompt 是整个 Agent 里我改得最多的部分。早期版本我写得很全面把漏洞类型、判断标准、输出格式全塞进去结果模型经常抓不住重点输出一堆无关分析。后来我做了几个关键调整第一明确角色和边界。prompt 开头直接告诉模型你是一个漏洞研判专家你的任务是对给定的扫描告警判断真伪只输出 JSON不要输出任何解释性文字。第二给判断依据不给判断结论。我不告诉模型这个应该是真漏洞而是给它判断所需的全部证据原始请求、响应、payload、上下文。让模型自己推。第三用 few-shot 示例锚定输出格式。我给两三个正例和反例让模型照着格式输出。实测下来有示例的情况下输出格式错误率从 15% 降到了 2% 以下。4.2 误报压制从规则预筛到模型复核误报是漏洞扫描的老大难。我的压制策略是两层过滤第一层是规则预筛用确定性规则干掉明显误报。比如响应里包含error但状态码是 200 且没有数据库特征 → 大概率误报告警类型是信息泄露但泄露内容是公开信息 → 直接归档同一 URL 同一参数重复告警 → 去重第二层是模型复核对预筛后剩下的可疑告警做深度研判。模型会结合请求响应上下文判断是否存在真实的利用路径。实测数据某次对内部测试靶场的扫描原始告警 312 条规则预筛后剩 87 条模型复核后确认真实漏洞 23 条误报率从最初的 70% 以上压到了 15% 左右。这个数字不算完美但已经比传统扫描器好用太多了。4.3 置信度打分与人工复核的衔接模型输出的置信度不是拿来好看的是要真正参与流程决策的。我设了三档置信度区间处理方式≥ 0.85直接进报告标记为高可信0.6 ~ 0.85进报告但标记待人工确认 0.6归档不打扰人工这样人工只需要关注中间那档工作量大幅下降。而且我会把人工复核的结果回写作为后续同类告警的参考让 Agent 越用越准。4.4 长上下文场景下的 token 控制漏洞研判经常需要看很长的请求响应尤其是涉及文件上传、反序列化的场景payload 可能几 KB。如果无脑全塞进 prompttoken 消耗很快失控。我的做法是分层截断请求头只保留关键字段Content-Type、Cookie、Authorization 等请求体超过阈值就截断但保留首尾和特征片段响应体只保留状态码、关键 header、以及和漏洞类型相关的片段这样处理后单条告警的研判 token 消耗从平均 3000 降到了 800 左右成本降了七成多研判准确率基本没受影响。5. 实测踩坑记录那些文档里不会写的问题5.1 模型幻觉导致的假阳性研判最开始的版本模型经常把不存在的漏洞研判成真的。比如一个普通的参数回显模型会脑补出可能存在 XSS。这个问题在早期特别严重因为 prompt 里没有明确要求模型基于证据判断。修复方法是在 prompt 里加了一条硬约束如果证据不足以支撑结论必须输出 verdict 为 uncertain并说明缺少什么证据。加了这条之后模型不再强行下结论uncertain 的比例大概在 10% 左右这些会被归到人工复核队列。5.2 扫描器输出格式不一致的解析难题不同扫描工具的输出格式差异极大有的用 XML有的用 JSON有的直接是文本。laya 解析层最初是按工具写死的解析器结果每接一个新工具就要改代码维护成本很高。后来我改成配置驱动把每种工具的字段映射写成配置解析器读配置做转换。这样接新工具只需要加一份配置不用动代码。这个改动让工具接入时间从半天缩短到半小时。5.3 并发扫描时的状态竞争问题当同时跑多个扫描任务时出现了状态串扰——A 任务的研判结果写到了 B 任务里。排查后发现是状态管理没有做任务隔离多个任务共享了同一份上下文。修复方案是给每个任务分配独立的任务上下文空间所有状态读写都带上任务 ID。workbuddy 的任务隔离机制在这里帮了大忙我只需要在 skill 调用时传入正确的任务上下文就行。5.4 研判结果回写知识库的坑我设计了一个知识库把研判结论存起来供后续参考。但早期回写时没做去重和版本管理导致同一个漏洞被反复写入知识库越来越臃肿检索也越来越慢。后来加了指纹去重用漏洞类型 目标特征 payload 特征生成指纹相同指纹只保留最新结论。同时加了定期清理机制超过一定时间且未被引用的记录自动归档。6. 从靶场验证到真实资产效果与边界6.1 靶场环境下的验证结果我在几个常见的漏洞靶场上做了验证覆盖 SQL 注入、XSS、命令执行、文件包含、越权等类型。整体表现检出率对已知漏洞的检出率在 90% 以上漏报主要出现在需要多步交互才能触发的场景误报率经过双层过滤后最终报告里的误报率控制在 15% 以内研判准确率模型对真漏洞的判定准确率约 88%对误报的识别准确率约 82%这个数据说明 Agent 已经能承担大部分初筛工作但还不能完全替代人工。6.2 真实资产扫描中的意外发现在内部资产上跑的时候Agent 发现了一些传统扫描器漏掉的问题主要是逻辑类漏洞——比如参数篡改导致的越权、业务流程绕过。这类漏洞传统扫描器很难覆盖但模型结合上下文推理后能识别出来。不过也暴露了边界对于需要多步状态保持才能触发的漏洞比如需要先登录、再操作、再验证的链式漏洞当前 Agent 的处理能力有限因为状态机还没有很好地支持跨请求的会话保持。6.3 当前方案的适用边界说清楚边界比吹效果更重要。这套 Agent 目前适合大批量资产的初筛和优先级排序已知漏洞类型的快速研判和误报压制常规 Web 漏洞的自动化审计不太适合需要深度交互的复杂逻辑漏洞需要逆向分析的二进制漏洞对准确性要求极高的合规审计场景仍需人工兜底6.4 后续可以继续打磨的方向如果继续迭代我会优先做这几件事一是把会话保持做进状态机支持链式漏洞检测二是把研判结论做成可检索的知识库让 Agent 能参考历史案例三是加一个反馈闭环人工复核的结果自动优化预筛规则和 prompt。这套东西我从零搭到现在大概花了三周多的业余时间中间踩的坑基本都写在上面了。如果你也想用 workbuddy 搭类似的 Agent我的建议是先把解析层做扎实别急着上模型。解析不稳后面全是空中楼阁。另外研判 prompt 一定要反复调别指望一次写好我前后改了十几版才稳定下来。