1. 为什么我要折腾一个全栈安全渗透测试平台安全渗透测试这个行当干了十来年最大的感受就是工具太碎。信息收集用一套漏洞扫描用一套API 测试再换一套报告生成又得手动拼。每次接一个新项目光是把环境搭起来、把各个工具串成流水线就得花掉大半天。更别提现在业务系统越来越复杂前后端分离、微服务、多端适配传统的手工测试方式根本跟不上节奏。去年年底我开始琢磨一件事能不能把渗透测试的完整流程从资产发现到报告输出全部塞进一个平台里再用 AI 智能体把那些重复性高、逻辑判断密集的环节自动化掉。这个想法落地之后就有了今天要聊的这个项目——一个覆盖十六大安全领域、集成 7900 多个 API 接口、内置 4 大 AI 智能体的全栈安全渗透测试平台。先说清楚这个平台能干什么。它本质上是一个 Web 应用前端用 Vue 3 加 TypeScript后端用 Golang 写核心调度和扫描引擎移动端用 UniApp 做了一套轻量级的监控面板。平台把渗透测试拆成十六个领域模块包括信息收集、端口扫描、Web 漏洞检测、API 安全测试、弱口令爆破、目录枚举、子域名发现、SSL 证书分析、CORS 配置检查、JWT 令牌测试、GraphQL 接口探测、WebSocket 安全评估、文件上传漏洞检测、SQL 注入检测、XSS 跨站脚本检测、命令注入检测。每个模块背后都对接了多个开源工具和自研脚本通过统一的 API 网关对外暴露能力。那 7900 多个 API 是怎么回事这不是我一个个手写的而是把各个安全工具的原生接口、第三方威胁情报平台的查询接口、以及平台内部的服务调用接口全部做了标准化封装。比如调用一个端口扫描底层可能走的是 Nmap 的 XML 输出解析也可能是 Masscan 的高速扫描结果但对外只暴露一个统一的 RESTful 接口。这样做的好处是前端和 AI 智能体不需要关心底层用的是哪个工具只需要按统一格式发请求、收结果就行。4 大 AI 智能体是整个平台的核心差异化所在。第一个是侦察智能体负责根据目标域名自动规划信息收集路径决定先查 Whois 还是先跑子域名枚举遇到 CDN 怎么绕过碰到 WAF 怎么调整策略。第二个是漏洞分析智能体它不直接发起攻击而是对扫描结果做二次研判把误报率高的告警过滤掉把真正有利用价值的漏洞按风险等级排好序。第三个是报告生成智能体它能把技术细节翻译成业务语言自动生成包含修复建议的渗透测试报告。第四个是任务调度智能体它根据目标资产的规模和类型动态分配扫描资源避免把目标打挂也避免浪费时间在无意义的探测上。这套东西适合谁来参考如果你是有一定安全基础、想了解 AI 智能体怎么跟安全工具链结合的工程师这篇文章会对你有帮助。如果你是全栈开发者想看看 Golang 和 Vue 怎么在安全场景下配合也能找到可复用的思路。哪怕你只是对 AI 智能体的工作流搭建感兴趣里面关于任务编排和结果研判的部分也值得一看。2. 平台整体架构与技术选型背后的逻辑2.1 为什么是 Vue Golang UniApp 这套组合前端选 Vue 3 加 TypeScript原因很直接安全平台的界面交互复杂度高实时性要求强。扫描任务跑起来之后前端要能实时展示进度、动态更新漏洞列表、支持多任务并行切换。Vue 3 的响应式系统和 Composition API 在这种场景下比 React 更顺手TypeScript 则保证了接口定义和数据结构的一致性。我试过用 React 重写一版光是状态管理就多写了不少样板代码后来还是切回了 Vue。后端选 Golang核心考量是并发性能和部署便利性。渗透测试平台天然是高并发场景一个扫描任务可能同时发起几百个 HTTP 请求还要处理 WebSocket 实时推送。Golang 的 goroutine 在这种场景下优势明显单机跑几千个并发连接毫无压力。另外 Golang 编译出来是单个二进制文件部署到客户现场或者云服务器上都很方便不需要折腾运行时环境。Python 虽然安全工具生态更丰富但在高并发调度和内存占用上确实不如 Golang 稳。移动端用 UniApp主要是为了满足“随时随地看扫描进度”这个需求。安全工程师不可能一直坐在电脑前有时候在外面吃饭或者通勤路上想看一眼任务跑得怎么样了掏出手机就能看。UniApp 一套代码能同时出 iOS、Android 和小程序版本开发成本低维护也方便。监控面板的功能不复杂主要是任务状态、漏洞统计和告警推送UniApp 完全够用。数据库层面主库用 PostgreSQL因为 JSONB 字段类型特别适合存扫描结果的原始数据查询效率也高。缓存和任务队列用 Redis扫描任务的排队、去重、限流都靠它。对象存储用 MinIO存扫描截图、报告文件、日志归档这些大文件。这套组合在我实际跑下来单节点支撑日均上千个扫描任务没什么压力。2.2 十六大领域模块的拆分原则十六个领域模块不是拍脑袋定的而是按照渗透测试的标准流程PTES和常见攻击面来划分的。我把它们分成四大类第一类资产发现类包括信息收集、子域名发现、端口扫描、目录枚举。这类模块的目标是把目标的攻击面尽可能完整地画出来。信息收集模块会调用 Whois、DNS 查询、备案信息查询、GitHub 泄露搜索等接口子域名发现模块集成了证书透明度日志查询、DNS 字典爆破、搜索引擎爬取三种方式端口扫描模块封装了 Nmap 的常用扫描策略和 Masscan 的高速模式目录枚举模块则对接了 Dirsearch 和 Gobuster 的字典库。第二类Web 应用安全类包括 Web 漏洞检测、SQL 注入检测、XSS 跨站脚本检测、文件上传漏洞检测、命令注入检测。这类模块是传统 Web 渗透的核心。每个模块都不是简单调个工具就完事而是做了结果聚合和去重。比如 SQL 注入检测底层会同时跑 SQLMap 的批量模式和自研的基于报错特征的快速检测脚本然后把两边的结果做交叉验证降低误报。第三类API 与协议安全类包括 API 安全测试、JWT 令牌测试、GraphQL 接口探测、WebSocket 安全评估、CORS 配置检查。这类模块是近几年随着前后端分离和微服务架构普及才变得重要的。API 安全测试模块支持 OpenAPI/Swagger 文档解析能自动生成测试用例JWT 测试模块会检查令牌的签名算法、过期时间、敏感信息泄露等问题GraphQL 探测模块能识别 introspection 是否开启、是否存在批量查询攻击风险。第四类基础设施安全类包括弱口令爆破、SSL 证书分析。弱口令爆破模块支持 SSH、RDP、MySQL、Redis、MongoDB 等常见服务的口令测试内置了常用弱口令字典和动态限速策略。SSL 证书分析模块会检查证书链完整性、协议版本、加密套件强度、HSTS 配置等。这样拆分的逻辑是每个模块的输入输出格式统一但内部实现可以独立演进。比如以后要加一个“容器安全检测”模块只需要按照同样的接口规范实现一遍注册到 API 网关就行不需要动其他模块的代码。2.3 7900 API 的标准化封装策略7900 多个 API 听起来吓人但其实大部分是自动生成的。我的做法是定义一个统一的接口描述文件用 YAML 写里面声明每个 API 的路径、方法、参数、返回值结构、限流策略、鉴权方式。然后写了一个代码生成器根据这个描述文件自动生成 Golang 的 handler 层代码和 Vue 的 API 调用层代码。具体来说每个底层工具或外部服务都对应一个适配器Adapter。适配器负责把统一格式的请求翻译成底层工具能理解的参数再把底层工具的原始输出解析成统一格式的响应。比如端口扫描适配器接收的是{target: example.com, ports: 1-1000, speed: fast}这样的标准请求内部根据 speed 参数决定调用 Nmap 还是 Masscan最后返回{open_ports: [{port: 80, service: http, banner: ...}]}这样的标准响应。这样做的好处有三个第一前端不需要知道底层用的是 Nmap 还是 Masscan只需要按统一格式调第二AI 智能体在做任务规划时只需要查询 API 目录就能知道平台具备哪些能力第三以后替换底层工具时只需要改适配器上层代码完全不用动。注意API 标准化封装时一定要把超时控制和重试策略做在适配器层不要让底层工具的默认超时行为暴露给上层。我踩过的坑是某个扫描工具默认超时是 30 分钟结果一个任务卡住之后整个任务队列都堵了。3. 4 大 AI 智能体的工作流设计与实现细节3.1 侦察智能体怎么让 AI 决定先扫什么侦察智能体的核心任务是根据目标的基本信息自动规划信息收集的路径和优先级。它的输入是一个域名或 IP 段输出是一个有序的任务列表每个任务包含要调用的 API、参数、预期耗时、依赖关系。工作流是这样的首先智能体调用 Whois 查询和 DNS 解析拿到目标的基本注册信息和 IP 地址。然后它根据 IP 地址判断是否属于云服务商比如 AWS、阿里云、腾讯云如果是就优先跑子域名枚举因为云上的资产通常有更多暴露面。接着它检查目标是否使用了 CDN如果用了就调整端口扫描策略避免扫到 CDN 节点而不是真实服务器。这里面的决策逻辑不是硬编码的 if-else而是用了一个轻量级的规则引擎加 LLM 推理。规则引擎处理确定性的判断比如“如果 IP 属于云服务商则优先子域名枚举”。LLM 处理模糊判断比如“根据 Whois 信息中的注册邮箱和注册时间判断这个目标可能是大型企业还是个人站点从而决定扫描的激进程度”。我实测下来侦察智能体最大的价值不是省了多少时间而是避免了“一上来就全量扫描”的粗暴做法。以前手工测试时经常是 Nmap 全端口扫一遍结果触发了目标的安全告警后面再想深入测试就难了。智能体会先做低噪音的被动信息收集再根据收集到的信息决定主动扫描的范围和强度。3.2 漏洞分析智能体误报过滤与风险排序漏洞分析智能体是整个平台里我最花心思做的部分。安全扫描工具的通病是误报率高一个中等规模的 Web 应用扫出来几百条告警是常事但真正有利用价值的可能就几条。人工研判这些告警非常耗时而且依赖经验。我的做法是智能体不直接看扫描工具的原始输出而是把告警信息、目标的技术栈指纹、历史漏洞数据、以及公开的漏洞利用信息CVE、Exploit-DB一起作为输入让 LLM 做综合判断。具体流程分三步第一步上下文增强。把告警对应的 URL、参数、HTTP 响应片段、目标使用的框架和中间件版本全部整理成结构化的上下文。比如一个 SQL 注入告警上下文里会包含注入点 URL、payload、响应时间差异、数据库报错信息、目标是否使用了 WAF。第二步误报判定。LLM 根据上下文判断这个告警是真漏洞还是误报。比如如果响应中出现了数据库报错但报错内容是“语法错误”而不是“SQL 语法错误”那很可能是误报。再比如如果目标使用了 WAF而且 payload 被拦截了那这个告警的利用价值就很低。第三步风险排序。对于判定为真漏洞的告警智能体会根据漏洞类型、利用难度、影响范围、目标业务重要性四个维度打分然后按分数从高到低排序。利用难度低、影响范围大、目标业务重要的漏洞排在最前面。实操心得LLM 做误报判定时一定要给它足够的上下文但也不能太多。我试过把整个 HTTP 响应都塞进去结果 LLM 被无关信息干扰判定准确率反而下降。后来改成只给关键片段报错信息、响应时间、状态码准确率明显提升。3.3 报告生成智能体从技术细节到业务语言报告生成智能体的任务是把技术性的漏洞描述翻译成业务人员能看懂的语言同时生成修复建议。这个智能体的输入是漏洞分析智能体输出的排序后的漏洞列表输出是一份完整的渗透测试报告。报告的结构是这样的首先是执行摘要用非技术语言说明本次测试发现了哪些风险、整体安全状况如何、最紧急的修复项是什么。然后是漏洞详情每个漏洞包含漏洞名称、风险等级、影响范围、复现步骤、技术细节、修复建议。最后是附录包含测试范围、测试方法、工具列表。LLM 在这里的作用主要是两个一是语言翻译把“SQL 注入”翻译成“攻击者可以通过在输入框中构造特殊字符直接读取或修改数据库中的数据”二是修复建议生成根据目标的技术栈比如用的是 Java Spring 还是 Python Django给出针对性的修复方案。我试过让 LLM 直接生成完整报告效果不太稳定有时候会编造不存在的漏洞细节。后来改成“模板 LLM 填充”的方式报告的整体结构用固定模板LLM 只负责填充每个漏洞的描述和修复建议。这样既保证了报告的规范性又利用了 LLM 的语言能力。3.4 任务调度智能体资源分配与风险控制任务调度智能体负责根据目标资产的规模和类型动态分配扫描资源。它的核心逻辑是在保证扫描覆盖率的前提下尽量降低对目标的影响同时避免浪费平台资源。具体策略包括并发控制根据目标是否使用了 WAF、是否属于生产环境动态调整并发请求数。生产环境默认并发不超过 10测试环境可以放到 50。速率限制对同一个目标 IP每秒请求数不超过设定阈值避免触发目标的安全告警。任务优先级高优先级的任务比如客户明确要求先测的模块优先分配资源低优先级的任务排队等待。失败重试对于因网络波动导致失败的任务自动重试但重试次数不超过 3 次且每次重试间隔递增。这个智能体还负责监控目标的状态。如果发现目标响应时间突然变长或者返回大量 5xx 错误它会自动暂停扫描任务避免把目标打挂。这个功能在实际项目中救过我一次有个客户的生产环境比较脆弱扫描到一半响应变慢调度智能体自动暂停了任务等目标恢复后才继续客户完全没感知到。4. 核心模块实操从零搭建一个 API 安全测试流程4.1 环境准备与依赖安装先说一下基础环境。我用的是一台 8 核 16G 的云服务器操作系统是 Ubuntu 22.04。为什么选 Ubuntu 而不是 CentOS因为安全工具生态对 Ubuntu 的支持更好很多工具的官方文档和社区教程都是基于 Ubuntu 写的踩坑少。安装依赖分三步第一步装 Golang 和 Node.js。Golang 用 1.21 版本Node.js 用 18 LTS 版本。这两个版本是我实测下来最稳定的太新的版本有时候会有兼容性问题。# 安装 Golang wget https://go.dev/dl/go1.21.0.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.21.0.linux-amd64.tar.gz echo export PATH$PATH:/usr/local/go/bin ~/.bashrc source ~/.bashrc # 安装 Node.js curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - sudo apt-get install -y nodejs第二步装 PostgreSQL 和 Redis。PostgreSQL 用 15 版本Redis 用 7 版本。这两个都是长期支持版本稳定性和性能都经过验证。sudo apt-get install -y postgresql-15 redis-server sudo systemctl enable postgresql redis-server sudo systemctl start postgresql redis-server第三步装安全工具。平台本身不重复造轮子底层扫描能力还是靠成熟的开源工具。需要装的有Nmap、Masscan、Dirsearch、SQLMap、Gobuster、WhatWeb、Wappalyzer命令行版。这些工具通过适配器接入平台平台只负责调度和结果聚合。sudo apt-get install -y nmap masscan whatweb pip install dirsearch sqlmap go install github.com/OJ/gobuster/v3latest注意Masscan 需要 root 权限才能跑建议用 sudo 或者给二进制文件设置 setcap。另外 Masscan 的默认速率是 100 包/秒实际使用时根据目标网络情况调整别一上来就拉满。4.2 API 安全测试模块的配置与调用API 安全测试模块是我用得最多的模块之一。它的核心能力是解析 OpenAPI/Swagger 文档自动生成测试用例然后对每个接口做安全检测。检测项包括未授权访问、越权访问、参数注入、敏感信息泄露、速率限制缺失、CORS 配置错误。配置流程是这样的首先在平台的“API 测试”页面上传目标的 OpenAPI 文档JSON 或 YAML 格式或者直接填入 Swagger UI 的 URL。平台会自动解析文档提取出所有接口的路径、方法、参数、请求体结构。然后配置测试策略。平台提供了三种预设策略快速扫描只测未授权访问和敏感信息泄露适合初步排查标准扫描在快速扫描基础上增加参数注入和 CORS 检查深度扫描会测试越权访问和速率限制需要提供多个角色的认证令牌。最后点击“开始测试”平台会调用任务调度智能体把测试任务拆分成多个子任务分发给不同的工作节点执行。测试过程中前端会实时展示每个接口的测试状态和结果。我实测下来一个中等规模的 API大约 200 个接口标准扫描大概 15 分钟能跑完深度扫描需要 40 分钟左右。误报率方面未授权访问的误报率最低基本在 5% 以下参数注入的误报率稍高大约 15%需要人工复核。4.3 扫描结果的数据结构与存储设计扫描结果的数据结构设计很关键直接影响到后续的查询、统计和报告生成。我用的是一张主表加多张从表的设计。主表scan_tasks存任务级别的信息任务 ID、目标、扫描类型、状态、开始时间、结束时间、创建人。从表scan_results存每个漏洞的详细信息结果 ID、任务 ID、漏洞类型、风险等级、URL、参数、payload、证据、修复建议。另外还有一张scan_logs表存扫描过程中的日志用于排查问题。PostgreSQL 的 JSONB 字段在这里帮了大忙。scan_results表里有一个raw_data字段类型是 JSONB存的是底层工具返回的原始数据。这样既保留了完整信息又不需要为每种工具单独建表。查询的时候可以用 PostgreSQL 的 JSONB 操作符直接查比如raw_data-banner就能取出 banner 信息。CREATE TABLE scan_results ( id BIGSERIAL PRIMARY KEY, task_id BIGINT REFERENCES scan_tasks(id), vuln_type VARCHAR(64) NOT NULL, risk_level VARCHAR(16) NOT NULL, url TEXT, parameter VARCHAR(256), payload TEXT, evidence TEXT, raw_data JSONB, created_at TIMESTAMP DEFAULT NOW() ); CREATE INDEX idx_scan_results_task_id ON scan_results(task_id); CREATE INDEX idx_scan_results_vuln_type ON scan_results(vuln_type); CREATE INDEX idx_scan_results_risk_level ON scan_results(risk_level);实操心得JSONB 字段虽然灵活但不要什么都往里塞。经常需要查询和过滤的字段还是单独建列并加索引。我一开始把风险等级也放在 JSONB 里后来发现按风险等级筛选时性能很差改成单独列之后查询速度快了十几倍。4.4 AI 智能体的接入与提示词工程AI 智能体的接入方式有两种一种是通过 OpenRouter 这样的 API 聚合平台调用多家大模型另一种是直接调用 DeepSeek 的 API。我两种都试过OpenRouter 的好处是可以在不同模型之间切换比如侦察智能体用推理能力强的模型报告生成智能体用语言能力强的模型。DeepSeek 的好处是成本低适合大规模调用。提示词工程是智能体效果的关键。我总结了几条经验第一角色设定要具体。不要只说“你是一个安全专家”要说“你是一个有十年经验的 Web 渗透测试工程师擅长从扫描结果中识别真实漏洞”。角色越具体模型的输出越专业。第二输出格式要约束。要求模型按 JSON 格式输出并给出字段定义。这样后续程序处理起来方便也减少了模型自由发挥的空间。第三少样本示例。在提示词里给两三个输入输出的例子模型就能很好地理解任务要求。比如漏洞分析智能体我给了一个真漏洞的例子和一个误报的例子模型的判定准确率明显提升。第四分步推理。对于复杂判断要求模型先输出推理过程再输出结论。这样即使结论错了也能从推理过程中找到原因方便调试。# 漏洞分析智能体的提示词模板示例 prompt_template 你是一个资深Web安全工程师负责对扫描工具的告警进行研判。 输入信息 - 漏洞类型{vuln_type} - 目标URL{url} - 参数{parameter} - Payload{payload} - 响应片段{response_snippet} - 目标技术栈{tech_stack} 请按以下步骤分析 1. 判断该告警是否为误报说明理由。 2. 如果是真漏洞评估其利用难度低/中/高。 3. 评估影响范围单点/局部/全局。 4. 给出风险等级严重/高/中/低/信息。 输出格式JSON {{ is_false_positive: true/false, reason: 判断理由, exploit_difficulty: 低/中/高, impact_scope: 单点/局部/全局, risk_level: 严重/高/中/低/信息 }} 5. 实际运行中踩过的坑与排查技巧5.1 扫描任务卡死与超时处理平台刚上线的时候最常遇到的问题就是扫描任务卡死。表现是任务状态一直显示“运行中”但没有任何进度更新也不结束。排查下来原因主要有三个原因一底层工具没有超时控制。比如某个目录枚举工具遇到一个响应极慢的 URL会一直等下去。解决方案是在适配器层强制加超时用 Golang 的context.WithTimeout控制每个子任务的执行时间超时后强制终止并记录日志。原因二网络连接泄漏。高并发场景下如果 HTTP 连接没有正确关闭会导致连接池耗尽后续请求全部阻塞。解决方案是确保每个 HTTP 请求都正确关闭 response body并且设置合理的连接池大小和空闲连接回收时间。原因三死锁。任务调度智能体在分配资源时如果多个任务同时竞争同一个资源可能会死锁。解决方案是引入资源锁的超时机制获取锁超过一定时间就放弃并重试。排查技巧遇到任务卡死先看日志里最后一个成功执行的步骤是什么然后检查那个步骤对应的底层工具是否还在运行。如果工具已经退出但任务状态没更新那就是状态同步的问题如果工具还在运行那就是超时控制没生效。5.2 API 调用频率限制与重试策略平台需要调用大量外部 API比如威胁情报查询、CVE 信息获取、DNS 查询等。这些外部服务通常都有频率限制超限之后会返回 429 错误。我踩过的坑是一开始没有做频率控制结果某个情报平台的 API Key 被封了。后来我加了三层保护第一层本地令牌桶每个外部服务对应一个令牌桶控制调用速率。第二层指数退避重试遇到 429 错误时等待时间按 1 秒、2 秒、4 秒、8 秒递增最多重试 3 次。第三层降级策略如果某个外部服务连续失败超过阈值自动切换到备用数据源或者跳过该步骤继续执行。// 指数退避重试的简化实现 func retryWithBackoff(fn func() error, maxRetries int) error { for i : 0; i maxRetries; i { err : fn() if err nil { return nil } if !isRateLimitError(err) { return err } waitTime : time.Duration(1uint(i)) * time.Second time.Sleep(waitTime) } return fmt.Errorf(max retries exceeded) }5.3 误报过滤的边界情况处理误报过滤是漏洞分析智能体的核心功能但有些边界情况需要特别处理。情况一WAF 拦截导致的误报。如果目标使用了 WAF扫描工具的 payload 被拦截了工具可能会误判为“不存在漏洞”。但实际上漏洞可能存在只是被 WAF 挡住了。解决方案是智能体在判定时会检查响应中是否有 WAF 特征比如特定的拦截页面、状态码 403 等如果有则标记为“需人工验证”而不是直接判定为误报。情况二时间盲注的误判。时间盲注的检测依赖响应时间差异但网络波动也会导致响应时间变化。解决方案是智能体会要求扫描工具对同一个 payload 重复测试多次只有响应时间稳定地出现差异才判定为真漏洞。情况三版本号误报。有些扫描工具会根据 HTTP 响应头中的版本号判断是否存在已知漏洞但版本号可能被伪造或修改。解决方案是智能体会结合多个指纹信息响应头、HTML 特征、JavaScript 文件哈希综合判断而不是只看版本号。5.4 常见问题速查表问题现象可能原因排查方法解决方案任务一直显示运行中底层工具超时未控制检查工具进程是否还在适配器层加 context 超时API 返回 429调用频率超限查看调用日志令牌桶限流 指数退避重试扫描结果为空目标不可达或 WAF 拦截手动 curl 测试目标检查网络连通性调整扫描策略误报率突然升高目标技术栈变更对比历史扫描结果更新指纹库重新校准智能体报告生成失败LLM API 调用失败查看 API 返回错误检查 API Key 和配额增加重试数据库连接超时连接池耗尽查看数据库连接数增大连接池检查连接泄漏前端页面卡顿结果数据量过大查看浏览器控制台分页加载虚拟滚动移动端推送延迟WebSocket 断连检查网络状态增加心跳保活断线重连6. 平台扩展与二次开发建议6.1 怎么加一个新的安全检测模块加新模块的流程我走过好几遍总结下来就四步第一步定义 API 描述。在api-specs/目录下新建一个 YAML 文件声明模块的名称、版本、接口路径、参数、返回值。比如要加一个“容器安全检测”模块就定义/api/v1/container/scan接口接收镜像名称和扫描策略返回漏洞列表。第二步实现适配器。在adapters/目录下新建对应的 Go 文件实现Scan方法。适配器负责调用底层工具比如 Trivy 或 Clair解析输出转换成统一格式。第三步注册模块。在平台的模块注册中心里把新模块的信息加进去。注册之后前端会自动出现对应的菜单项AI 智能体也能在任务规划时发现这个新能力。第四步编写测试用例。至少覆盖正常扫描、目标不存在、工具执行失败三种场景。我吃过亏有个模块没写异常测试上线后遇到工具崩溃的情况整个任务队列都堵了。6.2 智能体提示词的迭代优化方法提示词不是写一次就完事的需要根据实际效果持续迭代。我的做法是建立一个“提示词版本库”每次修改都记录版本号、修改内容、测试效果。测试效果用两个指标衡量准确率判定正确的比例和召回率真漏洞被找出来的比例。迭代的时候每次只改一个变量。比如这次只改角色设定下次只改输出格式这样才能知道是哪个改动带来了效果变化。我试过一次改了好几个地方结果效果变差了但不知道是哪个改动导致的只能全部回滚重来。另外不同模型对提示词的敏感度不一样。同一个提示词在 DeepSeek 上效果很好换到另一个模型上可能就差很多。所以如果平台支持多模型切换最好为每个模型单独调一版提示词。6.3 性能优化的几个关键点平台跑起来之后性能瓶颈主要出现在三个地方第一个是数据库查询。扫描结果表的数据量增长很快一个中等规模的项目就能产生几十万条记录。优化手段包括按任务 ID 分区、对常用查询字段加索引、冷数据归档到单独的表。我实测下来分区之后查询速度提升了 5 倍以上。第二个是 API 网关的吞吐量。7900 多个 API 同时对外服务网关的压力很大。优化手段包括启用 HTTP/2、增加连接复用、对静态资源做 CDN 缓存、对高频接口做结果缓存。Redis 缓存帮了大忙把一些不常变化的查询结果缓存起来数据库压力小了很多。第三个是 AI 智能体的调用延迟。LLM 的响应时间通常在几秒到几十秒之间如果串行调用整个任务流程会很慢。优化手段是并行化把可以独立判断的告警分组同时发给多个智能体实例处理最后汇总结果。我试过把 100 条告警分成 10 组并行处理总耗时从 5 分钟降到了 40 秒。6.4 安全合规与使用边界最后说一个很重要但容易被忽略的问题平台的使用边界。这个平台是给授权的安全测试用的不是给未授权的攻击用的。我在平台里加了几道限制第一目标白名单。只有添加到白名单里的域名或 IP 才能被扫描添加时需要填写授权证明。第二操作审计。所有扫描操作都记录操作人、时间、目标、扫描类型日志保留至少 6 个月。第三速率硬限制。即使调度智能体想提高并发也不能超过平台设定的硬上限防止对目标造成过大影响。第四敏感操作二次确认。弱口令爆破、SQL 注入检测这类高风险操作需要二次确认才能执行。这些限制在实际项目中帮我避免了很多麻烦。有一次客户误把生产环境域名加进了扫描列表平台的白名单机制直接拦住了没有造成任何影响。个人体会做安全工具的人自己首先要有安全意识。平台能力越强越要加好护栏。我见过太多因为工具滥用导致的法律纠纷最后吃亏的都是工具的使用者。技术本身没有对错但使用技术的方式有边界。