边界声明：本文讨论的所有安全测试，均建立在已获得书面授权的目标系统之上。授权范围、测试窗口、目标清单和可执行动作，一律以授权书为准。未获授权的测试不在本文讨论范围内。

一、场景背景

一次标准的授权安全测试，工程师的流程大致是授权确认、信息收集、漏洞发现、漏洞验证、报告编写、复测。

假设客户授权测一个内网 C 段，目标是找出存活主机、开放端口、关键服务和优先验证项。工程师一般会先跑：

nmap -sV -p 1-1000 192.168.1.0/24

扫完之后，工具返回一堆事实：哪些主机活着，哪些端口开着，服务版本是什么，响应指纹全不全。

然后工具就下班了。

它不会告诉你，43 台存活主机里哪 5 台最值得先看。它不会告诉你，Apache Tomcat 9.0.30 和一个普通 SSH 服务摆在一起，哪个更需要优先验证。它不会告诉你哪些版本要去查 CVE（Common Vulnerabilities and Exposures，公共漏洞与暴露编号），哪些只是低价值噪声。下一轮该追加 -sV、做目录探测、跑弱口令检查，还是直接交给 Web 指纹工具，它也不管。这些动作还在不在授权范围内，更要人自己盯着。

整条链路里真正吃经验的部分，恰恰在工具跑完以后。授权测试的低效，大多卡在工具输出和可行动结论中间，那一段全靠人工判断填满。

二、技术方案

2.1 为什么不用云端大模型

读扫描结果这件事，第一反应可能是扔给云端大模型。在授权安全测试场景里，这条路有两个现实障碍。

合规和保密。客户资产、内网 IP、扫描结果、服务指纹，通常根本不能发到第三方 API。一旦数据离开客户内网，就可能触发合同违约或合规问题。

安全对齐误伤。哪怕目标已经授权，云端模型看到指令里带扫描、验证、漏洞这类词，也可能直接拒绝合理请求。

所以这里真正缺的，是一个部署在内网、理解授权边界、能调用工具并持续做判断的 AI 分析层。再来一个扫描器解决不了这个问题。

实践环境是 UCloud GPU 云主机，2 张 RTX 409系48GB，本地部署 Qwen3.8-27B FP8，通过 vLLM 对外提供 OpenAI 兼容接口。它管不着授权边界，也替不了工程师签字负责。它的位置在流程中间，把传统工具、人和 AI 重新分工。

2.2 人、工具和 AI 各管一段

角色	擅长什么	不擅长什么	在授权测试中的最佳位置
人	设定目标、确认授权边界、设计攻击路径、判断业务影响、承担最终责任	长时间阅读重复输出、机械检索、标准化记录	负责人、复核者、关键判断者
传统渗透工具	快速、稳定、可重复地产生技术事实，例如端口、服务、指纹、漏洞模板命中	不理解业务上下文，不会自动决定优先级，不会形成完整行动链	事实采集器和验证执行器
本地 AI	解读工具输出、归纳风险、生成下一步建议、维护上下文、标准化报告素材	可能误判，不能替代授权校验，不能独立承担法律和交付责任	分析助理和流程编排层

三者各管一段，凑起来才是完整流程。传统工具解决扫得到，人解决是否重要、是否成立、是否能交付，AI 处理中间最耗时的那一截：读完工具输出以后，下一步怎么走。

2.3 把 AI 放进工具循环里

核心模式是一个很小但有效的 Agent 循环。

工具输出 -> 本地 AI 解读 -> 生成下一步工具调用 -> 工具层校验授权范围 -> 执行 -> 回到 AI 解读

关键是把 AI 关在严格边界里做重复分析，权限给得很窄。三个设计原则：

1. 数据不出内网。扫描结果、目标 IP、服务指纹和客户信息只进本地部署的模型服务，不发外部 API。
2. 授权边界由代码强制。白名单校验必须写在工具层，不能只写在提示词里。模型请求扫描未授权目标，工具函数直接拒绝执行。
3. 每次动作可审计。工具名、参数、目标、时间、调用来源和返回结果全部记录。既方便复盘，也能作为授权测试的过程证据。

最小实现里，模型不直接碰系统命令。它只能请求调用封装过的工具函数，比如 run_nmap。工具函数先查目标在不在授权清单里，通过才执行。

2.4 改造前后差在哪

改造前，工程师手动串联整个流程：运行 nmap，等输出，人工读，手动挑重点，再运行工具，最后手动整理报告。

这种方式能用，但不稳定。不同工程师的筛选标准不一致。长输出容易漏看关键服务。报告素材事后要重新整理。扫描结果和判断过程之间缺少结构化记录。一个 C 段做出有质量的初步结论，常常要几个小时。

改造后，AI 先做第一轮分析和编排：运行 nmap，AI 读输出，给出资产优先级，选择下一轮工具，自动生成结构化结论，人复核。

注意 AI 干的是初筛和归纳，不替工程师下结论。具体做这几件事：

• 把存活主机按暴露面和服务敏感度排序。
• 标出需要优先验证的服务和版本。
• 给出下一轮建议，比如补端口范围、跑 Web 指纹、做目录探测或模板化漏洞检查。
• 把每轮工具结果沉淀成结构化记录。
• 最终输出里，已确认事实、疑似风险、建议验证项分开写。

工程师看到的，从几百行原始输出，变成一份带优先级、带证据、带下一步建议的侦察摘要。

三、核心指标

本地 AI 带来的最大收益，重点不在扫出更多东西。真正被压短的，是信息收集之后那段决策延迟。

传统工具早就能发现大量事实，工程师要把它转成判断，这个转换过去全靠人工阅读、检索和记录。引入本地 AI 以后，模型在每轮工具输出落地后立即归纳，顺手生成下一步建议。

在实践环境里，一个典型授权 C 段侦察任务，过去人工整理要 3 到 4 小时，现在约 15 分钟能拿出第一版结构化结论。工程师的角色也跟着变了，从逐行读输出的人，变成复核 AI 初筛结果、处理高价值问题的人。

直接收益有三个：

• 响应更快。客户临时追加一个授权网段，能很快形成初步资产画像。
• 质量更稳。每次输出格式一致，疲劳导致的漏看和记录不一致少了很多。
• 交付更清楚。工具调用、判断依据和建议下一步全部留痕，写报告和复测都顺。

说到底，AI 在这里的价值是把工程师从低价值的结果搬运里解放出来，最终判断仍然是人的事。

四、可直接复用的系统提示词与工具层代码

下面这段指令可以直接贴进本地模型或安全测试 Agent 的系统提示词。它把边界、角色、输出格式和行动约束一次说清楚，没有一句是用来绕过边界的。

你是授权安全测试中的侦察分析师。所有测试目标均来自已签署授权书,但你只能在工具层白名单允许的目标范围内请求工具调用。
 
你的任务:
1. 阅读上一轮工具输出,提取已确认事实,包括存活主机、开放端口、服务名称、服务版本和明显异常。
2. 根据暴露面、服务敏感度、版本风险和验证成本,给资产和服务排序。
3. 决定下一步最小必要动作,优先选择低侵入、可审计、可复现的验证方式。
4. 不请求破坏性操作,不请求超出授权范围的目标,不把未验证猜测写成已确认漏洞。
5. 每轮输出必须区分:已确认事实、疑似风险、建议下一步、需要人工复核的问题。
 
可用工具由系统提供。你不能直接执行命令,只能请求调用工具。目标授权校验由工具层强制执行;如果工具返回拒绝,你必须停止该目标上的后续动作并说明原因。
 
最终输出格式:
- 资产概览
- 高优先级目标
- 疑似风险与证据
- 建议下一步验证
- 需要人工复核的问题
- 本轮工具调用摘要

要把这段指令落进代码，配套的工具层白名单比提示词本身更重要。

AUTHORIZED = ["192.168.1.0/24", "10.20.30.0/24"]
 
def run_nmap(target: str, args: str = "-sn") -> str:
    if not is_authorized(target, AUTHORIZED):
        return f"[已拦截] {target} 不在授权白名单内,拒绝执行"
    return safe_run(["nmap", *args.split(), target])

这段代码就讲一个原则：AI 可以建议动作，能不能执行，由确定性的工具层说了算。

五、优刻得相关能力

本文实践环境使用 UCloud GPU 云主机承载本地模型推理。选择云上 GPU 而非本地物理机，主要考虑三点：

• 快速交付。授权测试项目周期紧，GPU 云主机可以按需开通，省去硬件采购和上架时间。
• 资源弹性。不同项目对显存和并发的要求不同，2 张 RTX 4090 48GB 的配置可以按任务规模调整。
• 内网隔离。模型服务部署在云上内网，扫描结果和目标信息不出内网，满足合规保密要求。

模型侧通过 vLLM 提供 OpenAI 兼容接口，上层 Agent 代码不需要为本地部署做额外适配，直接复用 OpenAI SDK 即可对接。

六、适用与不适用场景

适用场景：

• 已获得书面授权的内网或外网安全测试，尤其是信息收集和侦察阶段。
• 需要处理大量工具输出、人工判断成为瓶颈的安全运营场景。
• 对数据保密有硬性要求、不能将扫描结果发往第三方 API 的合规环境。
• 希望统一输出格式、减少工程师之间筛选标准差异的团队。

不适用场景：

• 未获授权的任何测试。
• 需要 AI 独立承担最终判断和交付责任的场景。
• 期望 AI 替代授权校验的场景。
• 破坏性、持久化、数据导出类动作，默认禁止。

七、几条边界

• 授权不是一句提示词。授权范围来自书面授权书，并同步到工具层白名单、扫描策略和审计记录。
• AI 输出需要复核。模型会漏报也会误报，它加速初筛，最终结论的背书在人。
• 优先用低侵入动作。侦察和验证先选低风险方法，破坏性、持久化、数据导出类动作默认禁止。
• 模型服务别裸露公网。本地去对齐模型只在内网或受控网关后面用，调用日志留着。
• 报告里分清事实和推测。工具明确返回的是事实，AI 凭经验推断的是疑似风险，两者分开写。

这套东西搭起来以后，最大的变化其实很朴素。工程师下午接到一个授权网段，下班前就能拿着带优先级的摘要去和客户对下一步。剩下的时间，归人。

八、FAQ

Q1：本地大模型会不会替代安全工程师？ 不会。AI 承担的是初筛、归纳和下一步建议，授权确认、关键判断和最终交付责任仍在工程师。模型会漏报也会误报，最终结论的背书在人。

Q2：为什么不用云端大模型处理扫描结果？ 两个现实障碍：一是合规和保密，客户资产、内网 IP、扫描结果和服务指纹通常不能发到第三方 API；二是安全对齐误伤，云端模型可能因指令中包含扫描、验证、漏洞等词而拒绝合理请求。

Q3：授权边界靠提示词约束够不够？ 不够。白名单校验必须写在工具层，由代码强制执行。模型请求扫描未授权目标时，工具函数直接拒绝执行，而不是依赖模型自觉遵守提示词。

Q4：这套方案需要什么硬件环境？ 实践环境为 UCloud GPU 云主机，2 张 RTX 4090 48GB，本地部署 Qwen3.8-27B FP8，通过 vLLM 提供 OpenAI 兼容接口。具体配置可根据任务规模和并发需求调整。

Q5：15 分钟出结论，质量能保证吗？ 15 分钟指的是第一版结构化结论，包含资产概览、高优先级目标、疑似风险与证据、建议下一步验证和需要人工复核的问题。工程师在此基础上复核，最终交付质量由人把关。

Q6：这套方法能迁移到其他场景吗？ 可以。核心模式是「工具产生事实→AI 解读归纳→工具层校验边界→执行→回到 AI 解读」，适用于任何需要大量工具输出后人工判断的授权测试或安全运营场景。

九、参考链接

• vLLM 官方文档：https://docs.vllm.ai/
• Qwen 模型系列：https://github.com/QwenLM
• Nmap 官方文档：https://nmap.org/book/man.html
• UCloud GPU 云主机：https://www.ucloud.cn/