聊到AI Agent在渗透测试里的落地我印象最深的不是模型有多强而是“规划-执行-反馈”这条链路打通起来有多麻烦。HackerAI 是我在授权环境里做的一个实验性项目核心目标不是搞一个能自动打点的黑盒工具而是把 AI 智能体作为调度中枢把资产测绘、漏洞扫描、结果研判、报告生成这四个环节串成一条相对自动化的流水线。先解释一下标题里的“代理架构”。这里的“代理”指的是 Agent 智能体不是传统意义上的网络代理服务。HackerAI 的定位是让大语言模型LLM去理解任务目标、拆解执行步骤、调用现成安全工具然后根据返回结果动态调整下一步判断。你可以把整个架构理解成一个“会思考的调度室”而不是一堆脚本的堆叠。对做安全测试、安全运维、红队蓝队建设的朋友来说这篇内容值得花几分钟看完——它讲的是思路和可复现的工程细节而不是某个测试框架的广告。1. 整体架构设计为什么用 AI Agent 替代线性脚本1.1 传统自动化脚本的瓶颈以前做一次常规安全评估我通常会把流程固化成一个“接力棒式”的脚本先跑一轮资产发现把结果存文件再喂给端口扫描工具扫完再交给漏洞扫描器最后人工筛选高危项。这个过程最大的问题不是慢而是每一步之间的“语义断层”。举个例子资产发现阶段扫出一个新的子域名脚本只会把它写进列表不会意识到“这个子域名没有接入单点登录系统”“它可能是某个测试环境的入口”。等到了漏洞扫描阶段扫描器打了全量流量过去系统可能直接崩了或者把生产环境的服务搞出误报。软件跑得很辛苦但干活的逻辑是“死”的。也就是说传统自动化工具擅长把一件事做深做透却不擅长在多个任务之间做判断。当一个任务的输出依赖对另一个任务结果的理解时脚本就卡壳了。而渗透测试恰恰是这种“千变万化”的工作目标资产长什么样、边界在哪里、测试到什么程度该停手都需要临场判断。1.2 AI Agent 带来的三个核心变化HackerAI 采用 AI Agent 架构本质上是把“判断”这件事从人手里移交给模型但又不是完全放养。我总结下来相比传统脚本有三个显著变化。第一任务可拆解。你给 HackerAI 一个总目标比如“对 XX 系统做一次授权范围内的风险评估”它会自己拆成多个子任务先摸资产再识别服务再挑选合适的检测策略最后汇总结果。拆完之后它会评估自己缺什么信息再挨个去调用工具补齐。第二结果可理解。扫描工具返回的 JSON 日志通常是又臭又长脚本拿到它只能做关键词匹配。Agent 可以把这段结果“读”进来结合上下文理解它意味着什么。比如某个扫描条目标记为“可能存在信息泄露”Agent 发现该路径返回了真实的用户邮箱就会主动调整风险等级而不是机械地照搬扫描器的评级。第三操作可回溯。Agent 的每次推理、工具调用、结果分析都会被记录成结构化的执行轨迹我后来排查问题、复盘误报时靠的就是这些轨迹。传统脚本打一条命令就结束了但 Agent 架构天然自带“过程审计”属性这在安全测试场景里尤其珍贵。1.3 HackerAI 的四层逻辑架构整个 HackerAI 项目在结构上分成四层我画在自己笔记本上大概长这样任务编排层Orchestrator接收人工下达的评估目标维护一个任务状态机是全部逻辑的“大脑”。意图理解层Planner把自然语言目标转成具体的执行计划每一步都对应一个工具调用或信息查询。工具执行层Executor统一封装底层安全工具以标准化接口暴露给编排层。扫描器、指纹识别工具、域名枚举工具都被包在这里。结果研判层Reasoner对工具输出做二次分析生成结构化的风险事件并输出修复建议。这样分层的好处是“各层能独立替换”。比如今天觉得 A 扫描器不好用想换 B只需要改 Executor 里的适配器Planner 和 Reasoner 完全不用动。又比如想把基座模型从云端 API 换成本地部署也只动最上层不影响下面工具的调用。这个设计思路其实借鉴了后端开发里的“依赖倒置”原则上层不要直接依赖具体的工具而是依赖抽象接口。刚开始我觉得这是过度设计但后来模型推理出错、要换工具做对比实验的时候我无比庆幸当初这么分了层。2. 核心模块拆解从侦察到报告的完整编排2.1 资产信息收集与授权边界判断很多自动化测试框架把信息收集做成“无脑拉网”只要给一个根域名就递归枚举子域、解析 IP、识别指纹能收集多少收多少。HackerAI 的第一版也这样结果很快出了问题某次测试中 Agent 顺着一个子域关联到了合作的第三方系统而那个系统不在授权范围内。还没等我们反应过来扫描流量已经打了过去。所以我后来在编排层加了一道硬性门禁授权范围判定。目标清单在任务开始前以结构化文件注入系统提示词和内存数据库中Agent 拿到任何一个新资产后必须先把资产与授权清单做一次匹配匹配不上就直接跳过不能“顺便看看”。这一步看着简单但在 Agent 架构里很容易被忽略——模型默认的倾向是把任务“完成得更多”而不是“完成得更克制”。实际操作中我把授权范围文件设计成了 JSON 格式包含精确的域名列表、IP 网段以及可执行动作的枚举。比如某些资产只允许做被动指纹识别不允许主动探测那 Agent 在调用工具时如果试图执行动作列表之外的操作工具执行层会直接返回一个“permission denied”。2.2 扫描任务分发与工具调用任务分发层负责把 Agent 的意图翻译成工具可执行的指令。项目里我把工具统一抽象成三类探测类、扫描类、验证类。每类工具只暴露少数几个参数参数也尽量用枚举值而不是自由文本。为什么这样设计因为 LLM 在生成结构化的工具调用参数时如果参数是开放的很可能生成一个不符合规范的路径或格式。比如让模型填一个“扫描配置文件路径”它可能编一个不存在的路径。但如果你把参数收敛成 quick / full / safe 三个枚举模型几乎不会出错。我最初阶段很多工具执行失败的日志根因都是参数太自由收敛之后异常率肉眼可见地下降。工具执行层还有一个功能是做“结果裁剪”。扫描器输出的完整结果可能几千行全塞进上下文既不经济也容易把真正关键的信息淹没。所以 Executor 在返回结果前会对原始输出做一层摘要提取目标地址、开放端口、服务类型、风险等级、时间戳最多保留前 50 条记录。大模型只看到摘要如果它觉得某条记录需要深入再单独发起一次明细查询。2.3 结果研判与报告生成安全评估最花时间的就是结果研判。扫描器报了一堆中低危真正需要人工确认的可能就两三条。HackerAI 的 Reasoner 层做的事本质上是一个“智能筛选器”它把扫描器的原始风险条目和资产的实际业务场景结合起来判断这个风险到底能不能被利用、影响面有多大。举个例子扫描器报告某管理后台的登录接口没有加验证码风险评级是“中危”。Reasoner 结合上下文后分析该接口绑定了内网 IP 白名单且登录失败后会自动锁定账号实际可利用性较低。于是把这条风险降为“低危”并在报告里做了说明。这个逻辑在人看来很直接但对脚本来说几乎无法实现——它不理解“白名单”和“锁定策略”的意义只会照搬扫描器的评级。报告模块也很有意思。传统报告是统一模板所有系统、所有测试结果都套同一个结构。HackerAI 会根据测试中真正发现的问题动态调整报告章节如果这次测试没有发现注入类风险报告就不会机械地保留那一节而是用一小段说明“未发现相关风险推测原因是什么”。测试负责人要看的不是千篇一律的模板而是针对当前系统的有效结论。报告同时支持导出成 Markdown 和 PDF方便直接归档。2.4 人工审批与熔断机制做一个全自动的 AI 安全测试系统最怕的就是失控。哪怕授权范围写得再清楚也不能保证模型每次决策都合理。所以 HackerAI 从第一版就设计了两个安全阀人工审批节点和熔断机制。人工审批节点设置在“高风险操作”前。Agent 计划执行任何可能产生较大影响的动作时比如端口全量扫描、登录接口尝试、文件读取探测都会先暂停生成一个审批请求推送到我配置的即时通讯机器人上。我点了通过任务才继续。这样做的代价是速度变慢但换来的是可控。实测下来真正需要人工介入的比例并不高大约在一轮任务 20 到 30 个工具调用里只有两三个触发审批而且大多是“安全通过”的例行确认。熔断机制则是监控执行轨迹的“健康状态”。如果一段时间内工具报错率过高、Agent 反复执行同一失败操作超过次数阈值或者输出内容出现明显乱码编排层会自动终止当前任务并通知管理员。坦白说这个机制在早期救过我很多次。有一次模型因为上下文过长状态错乱开始重复调用一个探测工具如果没有熔断我可能要到第二天看日志才能发现。3. 工具选型与关键配置复现 HackerAI 的关键决策3.1 基座模型的选型思路选基座模型时我纠结了很久。用云端 API 的优势是推理能力稳定上下文窗口大不容易出现低级逻辑错误劣势是数据要出网对很多企业内部场景来说把扫描结果发到外部接口是不可接受的。用本地部署模型则反过来数据安全可控但推理能力和上下文长度普遍受限。HackerAI 最终采取的是“双轨制”内部 Demo 环境数据不敏感用云端模型跑方便快速迭代提示词真正做企业内部评估时切换到本地部署的开源权重模型参数规模大概在 70B 级别配合量化压缩部署在一张具备一定显存大小的专业显卡上。实测本地模型在任务规划和工具调用规范度上比云端模型差一点但通过把工具调用协议写得足够严谨、把提示词里给足示例最终还是能达到可用的程度。这里我想给后来者一个建议别一上来就追大参数模型先确认你的场景是不是真的需要那么强的推理能力。在我这个项目里任务规划已经比较结构化模型真正需要动脑的地方主要是结果研判那部分我可以拆分出来单独用更强或者更合适的模型其余环节用轻量模型完全够。把不同的 Agent 任务路由给不同能力的模型性价比会高很多。3.2 工具调用协议的三种选择AI Agent 要调用外部工具市面上有三条主流路线ReAct 提示词模式、函数调用模式、消息总线模式。我在 HackerAI 里都分别试过各自的坑都踩了一遍。ReAct 模式最省事只需要把工具说明写在系统提示词里让模型以特定文本格式输出来表示“我要调用某个工具”。它的问题是不稳定——模型偶尔会输出格式错误的动作标签解析失败就要重试重试多了上下文就脏了。函数调用模式是后端起家的模型输出严格的结构化 JSON天然规避了格式错误。我用 Python 写了一个执行器去解析返回值这种方式最稳定也是我最终的主力方案。缺点是需要依赖特定模型对函数调用特性的支持换成传统模型可能不兼容。消息总线模式最复杂它把 Agent、工具、日志系统都挂在消息队列上事件驱动地流转。这个模式扩展性最好但对小项目来说完全是过度设计维护成本高到离谱。我后来只在日志收集这一个环节保留了消息总线核心执行链路还是走函数调用。3.3 提示词工程把“授权边界”写进系统层大模型在安全测试场景里有个天然的行为倾向遇到任务就执行不太会主动思考“我有没有权限做这件事”。所以 HackerAI 的提示词工程里授权边界不是可有可无的装饰而是强制在系统提示词里用最高优先级声明。我整理的提示词模板里开头就是几段“硬约束”。比如只能对授权清单中列出的目标采取动作如果目标不在清单内直接返回“目标不在授权范围”不得自行扩展所有工具操作必须经过工具执行层的权限校验任何时候不得执行拒绝服务性质的操作。这些约束不只是写给人看的更多的是为了让模型在推理时有一个“否决项”先挂在前面。我还做了两个细节。第一在提示词里给模型一个“安全默认值”原则当信息不足、目标不明时默认停止而不是默认继续。第二规定 Agent 在执行每一步之前先输出一个简短的“意图声明”说明自己准备做什么、依据是哪条授权相当于给每一步操作留下可审查的思考过程。这个设计在后期间查问题时帮了大忙很多误判在“意图声明”阶段就能发现是哪里想歪了。3.4 一个可落地的配置示例这里给出一个配置层面的简化示例方便你理解整个系统大概长什么样。首先是在工具执行层我用一个装饰器统一做权限校验AUTHORIZED_TARGETS {example.internal, 192.0.2.0/24} ALLOWED_ACTIONS {passive_probe, scan_quick, scan_full, validate} def check_permission(action, target): if target not in AUTHORIZED_TARGETS and not ip_in_networks(target): return False, target_out_of_scope if action not in ALLOWED_ACTIONS: return False, action_not_allowed return True, ok def secure_call(action, target): allowed, reason check_permission(action, target) if not allowed: return {status: denied, reason: reason} # 实际工具调用逻辑...然后是函数调用协议的定义。我通过一个 JSON Schema 来描述工具参数模型只按这个 Schema 输出 JSON{ type: object, properties: { action: { type: string, enum: [passive_probe, scan_quick, scan_full] }, target: { type: string, description: 必须在授权清单内的域名或IP }, profile: { type: string, enum: [safe, default, aggressive] } }, required: [action, target] }从配置上你就看得出来所有动作都经过了一道强制门禁。每当 Agent 试图调用不在枚举范围内的动作时调用直接失败而不是静默忽略。这种“显式拒绝”比我之前做的“隐式放过”安全得多。之前我尝试过只靠提示词里的文字约束来管行为后来发现模型偶尔心情不好就不遵守。只有代码层面强制执行才是真正稳定的。4. 实操过程实录一次授权范围内的 API 安全评估4.1 任务背景与授权范围为了验证 HackerAI 项目的实际表现我在一套隔离的演练环境里做了一次完整的测试。模拟场景是某企业内部的一个 API 网关系统该系统包含若干子服务其中部分服务对内部员工开放部分只对合作方开放。测试目标很明确在授权范围内找出这个 API 网关存在的配置问题和潜在信息泄露点并输出可执行的修复建议。授权范围清单里只包含该企业名下的三个主域名和两个内部网段。任务开始前我把这些范围写进了权限配置文件并手动确认了一次边界没有写错——这一步千万不能省我曾经因为网段掩码写错把一段不属于他们的 IP 放进了清单第一次测试立刻踩了红线从那以后每次上线前我都要人工核对两遍。过程中我扮演的是“外部安全评估人员”的角色但在 HackerAI 里我预设了一个“只看不做”的约束默认只进行被动的指纹识别和低强度的扫描任何可能对业务造成影响的尝试都要经过我在终端上的二次确认。4.2 分阶段执行过程第一阶段是资产梳理。HackerAI 根据根域名调用了资产测绘工具做子域枚举结果返回了十几条记录。Agent 没有急着把这些记录全部列为测试目标而是先做了一件事把每条记录和授权清单做比对自动剔除了解析到非授权 C 段地址的记录最终保留了 8 个有效子域。第二阶段是服务识别。Agent 对保留的域名逐一访问提取了返回头、页面元数据、API 文档路径等基础信息。这里有个细节让我印象很深——它发现某个子域返回的响应头里暴露了一个版本号于是主动把这个信息标记为“低风险信息泄露”并在知识库里检索了这个版本对应的已知问题列表。我当时看到日志里这一步明显感觉到这不是简单的工具调用能完成的“意识到版本号有意义”这本身就是模型理解的结果。第三阶段是漏洞扫描。Agent 选择对其中两个看起来承担对外业务的服务执行了快速扫描对另外几个内部子服务只做了低强度探测。这个选择不是随机的它的推理过程是对外服务暴露面大优先级高内部服务有额外网络层防护可以做低成本快速排摸。虽然事后看这个决定还有优化空间但在无人干预的情况下模型能够依据有限的上下文做出优先级判断已经达到了我设想的用途。扫描过程中熔断机制触发了一次。有个服务在接收到扫描请求后响应超时Agent 判断服务可能不稳定主动降低了扫描强度。如果没有熔断和状态监控扫描器可能会继续全强度请求这个服务影响业务响应。这次触发让我看到安全机制确实在起作用。第四阶段是结果汇总。Agent 把筛选出的风险条目按严重程度分级每个条目附上了响应的证据、影响分析和修复建议。整个报告生成没有人工干预我最后大概只花了 20 分钟复核了一遍它的建议有没有明显错误。4.3 效果对比AI 编排 vs 纯人工同样的测试范围我让另外一位团队成员用传统方式走了一遍流程粗略对比在下面环节传统人工HackerAI 辅助资产梳理约 1 小时约 8 分钟服务识别约 2 小时约 25 分钟扫描策略制定约 30 分钟自动生成结果研判约 3 小时约 30 分钟报告初稿约 2 小时约 5 分钟当然这个对比不太公平因为传统方式里那位成员需要边测边记录本来就慢一些。但要看到 AI 的真正价值不是把“耗时”压下去而是把人从机械重复里解放出来。测试人员不需要盯着扫描日志一行行翻而是可以专注于 Agent 提交的审批请求和最终报告。我用下来最大的体感是这类项目不是要“替代渗透测试人员”而是把 80% 的重复劳动接走让人集中精力处理 20% 真正需要判断力的内容。4.4 现场遇到的两个小问题第一次跑完整流程时Agent 在报告阶段引用了一个知识库中不存在的漏洞项描述看着很合理但纯属它自己“编”的。后来我加了“引用追溯”机制报告中所有漏洞描述必须引用实际扫描返回的记录 ID查不到 ID 的自动剔除。这也是 LLM 常见的幻觉问题安全场景下必须用程序约束去兜底不能指望模型自己不说瞎话。还有一次是工具适配问题。某个指纹识别工具需要先登录目标系统才能拿到信息但 Executor 没有做会话保持导致 Agent 调用它的预期结果是拿到登录后的页面拿到的却是登录跳转页。这类工具适配问题只有跑真实任务才能暴露出来。所以如果你要复现类似项目我建议一定要准备一个专门的演练环境反复跑几轮让工具链的适配问题充分暴露。5. 常见问题与避坑指南5.1 上下文丢失与状态错乱Agent 在一次任务里要调用几十次工具每次把结果都塞进上下文很快就超过模型的上下文窗口到达上限后模型会“忘记”之前跑过的结果甚至开始重复询问已经知道答案的问题。我最初的处理方式是把每个工具的完整输出都返回给模型这个思路是错误的。后来我改成了两层记忆机制核心的状态摘要一直保留在上下文头部次要的原始结果存到外部向量库只按需检索。同时规划了一个清理策略:不再需要的中间结果会随新的关键信息加入一起被摘要化压缩。5.2 工具调用幻觉模型编造工具输出是另一个高频问题经常发生在 API 返回异常或者网络超时之后。正常情况下工具调用失败了应该返回一个错误码但模型有时会在“不顺”的情况下直接“脑补”一个结果出来这比报错可怕得多——要是真拿这结果去做判断整个评估结论就歪了。我的对策是升级工具执行层的返回值协议明确标注“成功/失败/超时”三种状态并规定如果返回状态不是成功Reasoner 层不允许对结果做进一步分析只能触发纠错重试或向管理员报告。逻辑上强制砍断“失败后瞎编”的可能。5.3 误报被进一步放大扫描工具本来就容易误报AI Agent 加入之后反而可能出现“模型相信扫描器误报、并煞有介事地在报告里补充影响分析”的情况。扫描器说这里有漏洞模型就跟了一句“该漏洞可能导致数据泄露”听着非常吓人但那可能只是扫描器匹配到了错误的正则。这个问题的根源是模型太“听话”了把工具的原始输出当成事实。我后来在提示词里加了一条规则“扫描结果只是待核实的证据不是结论最终判定必须经过独立推理不能直接沿用工具的风险等级。”同时让 Agent 在输出高风险条目时强制附上原始响应信息的片段作为佐证不做佐证的条目默认降级。这套组合下来误报对报告的污染小了很多。5.4 合规与伦理边界我必须把这条放在最后但最醒目的位置AI 安全测试项目再怎么自动化都需要有明确的授权边界。我在 HackerAI 上做的所有实验包括模拟测试环境里的这套流程都在事前签了明确的委托授权。Agent 自动化程度越高越要有清晰的权限管控和审计日志否则一旦“跑飞”到了不该碰的系统上后果不是技术层面兜得住的。这个项目内部起名 HackerAI更多是致敬白帽文化里“黑客精神”的本义——在知情、授权、协作的前提下通过探究系统缺陷让系统变得更安全。测试的意义永远是暴露问题、加固防线而不是破坏。任何以搞垮系统为目标的使用方式都违背了这个项目当初立项的初衷。自动化技术放大了安全专家的效率同时也会放大错误操作的破坏力所以我建议任何想复现类似项目的团队第一优先级永远是先把权限门槛和审计链路做完再谈智能化。6. 经验沉淀与后续可以怎么玩HackerAI 从立项到跑通我最深的一条体会是AI Agent 在安全领域的价值不是“取代安全专家”而是“把安全专家从脏活累活里捞出来”。判断一个任务值不值得交给 Agent只需要问一个问题——这个任务需要频繁根据现场情况调整决策吗如果不需要写个静态脚本就够了上 Agent 反而是累赘如果需要AI 的适应能力就立刻体现出价值。后面我打算把两个方向做完备一是把报告模块和资产管理平台打通让 Agent 生成的风险条目能自动同步到工单系统而不是只停留在 PDF 里二是在现有的授权边界校验之外增加一个“行为基线”模块通过分析 Agent 历史执行轨迹来识别异常决策。目前我的做法还停留在静态规则阶段后面希望能做成动态的。说到底HackerAI 这类项目最让我兴奋的地方不是“AI 能自动跑安全测试”这个结果而是它把安全测试从“人找工具”变成了“工具配合人思考”。如果你也想在自己的授权测试环境里折腾一个类似的 Agent 编排层我的建议很直接先把权限门禁和工具封装备好再去调模型提示词。否则后面每踩一个坑都可能是在替前面的懒惰买单。
