安全 Agent 的工程化闭环：从一次性 Prompt 到可恢复的漏洞分析系统

最近一段时间，AI Agent 在安全领域的讨论明显变多了。代码审计、漏洞挖掘、渗透测试、应急响应、二进制分析，几乎每一个安全方向都开始尝试把大模型接入原有工作流。

但很多讨论容易走向两个极端。

一种极端是把 Agent 理解成“会调用工具的大模型”。给它一个任务，让它自己想、自己查、自己调用命令，最后返回一个结果。这个理解并不算错，但太底层。它只描述了 Agent Loop 的运行方式：模型输出工具调用，工具返回结果，模型继续推理，直到任务结束。

另一种极端是把 Agent 包装成“自动攻击系统”。仿佛只要输入一个目标，系统就能自动完成侦察、分析、验证、报告，甚至自动形成攻击链。这类表达很吸引人，但容易忽略安全场景中最关键的问题：边界、授权、证据、误报、状态恢复、过程审计，以及失败后的可控降级。

真正值得关注的，不是“模型能不能自动做安全”，而是“安全任务能不能被工程化为一个稳定闭环”。

换句话说，安全 Agent 的核心，不是 Prompt，而是 Loop。

一、从 Prompt 到 Loop：安全 Agent 的真正变化

传统使用大模型的方式，本质上是一次性问答。

我们把一段代码、一段日志、一个报错或者一个漏洞描述丢给模型，然后等待它输出分析结果。如果结果不满意，就继续追问：“再检查一下”“有没有遗漏”“这个结论可靠吗”“请给出修复建议”。

这个过程看似是人在使用 AI，其实更像人在手动维护一个循环：

提出任务。
等待输出。
人工检查。
发现问题。
继续追问。
再次检查。
直到结果勉强可用。

这就是典型的人在环路中。问题在于，人类承担了太多重复的控制动作：判断是否继续、判断是否跑偏、判断是否需要换工具、判断是否已经有足够证据、判断是否可以生成报告。

Loop Engineering 想解决的正是这个问题：把这些重复控制动作从人的手里拿出来，固化为系统的一部分。

在安全场景下，这一点更加关键。因为安全分析天然不是单步任务，而是长链条任务。

一次代码审计至少包含项目结构理解、入口点识别、权限模型分析、危险函数定位、数据流追踪、漏洞假设生成、证据收集、误报排除、影响评估、修复建议生成等多个阶段。一次漏洞挖掘也不是简单地“找漏洞”，而是不断提出假设、验证假设、否定假设、保留证据、更新优先级。

如果这些步骤完全依赖人手动推动，Agent 只是一个增强版聊天窗口。

如果这些步骤被设计成可重复运行的闭环，Agent 才开始接近一个工程系统。

二、安全 Agent 不是一个模型，而是一组角色、工具和状态

很多人讨论 Agent 时，容易把焦点放在模型能力上：用哪个大模型，多少参数，上下文多长，推理速度多快，能不能调用工具。

这些当然重要，但不是系统的全部。

一个真正可用的安全 Agent，至少应该包含四类核心元素：

第一是角色分工。

安全分析不是单一动作。规划者负责拆解任务，检索者负责定位上下文，审计者负责提出漏洞假设，验证者负责检查证据是否成立，报告者负责把结论转成可读交付物，监督者负责判断流程是否跑偏。

这些角色不一定都要由不同模型承担，也不一定需要真的启动多个独立 Agent。但在架构设计上，它们必须是分离的。否则系统很容易变成一个模型同时负责猜测、执行、判断和总结，最后既不可控，也不可解释。

第二是工具边界。

安全 Agent 必然要接触工具。代码检索、依赖分析、静态扫描、测试执行、日志解析、知识库查询、报告生成，都可以成为工具调用对象。

但工具不是越多越好。工具越多，系统的不可控面越大。安全 Agent 需要明确工具白名单、参数约束、目录边界、运行超时、资源限制和输出格式。尤其在授权安全测试场景中，工具调用必须服务于验证和分析，而不能让模型无约束地扩大测试范围。

第三是状态管理。

这是很多 Agent 原型最容易忽略的一点。

安全任务通常跑不完一轮就结束。大型代码仓库可能需要分阶段分析，长时间测试可能会中断，模型上下文也不可能装下所有历史信息。如果系统没有状态管理，每次重启都等于从头再来。

因此，安全 Agent 必须把过程状态显式保存下来：当前任务是什么，分析到哪个模块，已经读过哪些文件，提出过哪些漏洞假设，哪些假设被否定，哪些证据还不充分，哪些结果可以进入报告，哪些需要人工复核。

没有状态，就没有长程任务能力。

第四是反馈闭环。

安全 Agent 最核心的能力不是“一次输出正确答案”，而是“根据反馈持续收敛”。

反馈可以来自测试结果、静态分析结果、编译结果、单元测试、规则引擎、人工标注、历史漏洞库，也可以来自系统自身的验证器。每一次反馈都应该改变下一轮分析的优先级，而不是简单地追加到聊天记录里。

这就是安全 Agent 和普通 AI 助手的关键差异：它不是一次性生成器，而是一个会被证据驱动的闭环系统。

三、一个面向源代码漏洞挖掘的 Agent 闭环

以源代码漏洞挖掘为例，一个比较稳妥的安全 Agent Loop 可以拆成八个阶段。

第一阶段是任务初始化。

系统读取项目目录、语言栈、依赖文件、配置文件、路由定义、权限相关模块和测试入口，形成项目画像。这个阶段不直接判断漏洞，而是建立地图。没有地图，后面的分析很容易变成随机游走。

第二阶段是资产和入口识别。

对于 Web 项目，入口可能是 Controller、Route、API Handler、Middleware、RPC 接口。对于命令行工具，入口可能是参数解析和文件处理逻辑。对于服务端程序，入口可能是网络协议处理、任务队列、插件加载、模板渲染、反序列化流程。

安全 Agent 首先要知道攻击面在哪里，而不是一上来就扫描所有文件。

第三阶段是安全语义建模。

系统需要识别认证、授权、数据校验、敏感操作、文件读写、命令执行、网络请求、模板渲染、数据库访问等安全相关语义。这个阶段的目标不是发现具体漏洞，而是把代码中的安全关键点结构化。

第四阶段是漏洞假设生成。

基于项目画像和安全语义，Agent 生成候选漏洞假设。例如：某个接口是否缺少权限检查，某个参数是否进入敏感操作，某个文件路径是否缺少规范化，某个异步任务是否绕过了认证上下文。

这里的重点是“假设”，不是“结论”。安全 Agent 应该先生成待验证对象，而不是直接输出漏洞报告。

第五阶段是证据检索。

对每一个漏洞假设，系统回到代码中收集证据：调用链、数据流、权限检查位置、输入来源、过滤逻辑、异常处理、配置条件、可达路径。证据必须尽量结构化保存，而不是只放在模型上下文里。

第六阶段是验证与反证。

这是安全 Agent 最容易拉开差距的地方。一个不成熟的系统只会证明自己是对的，而一个成熟的系统必须主动寻找反证。

比如，一个看似缺少权限检查的接口，可能在上层路由中已经统一鉴权；一个看似危险的文件写入，可能路径已经被严格限制；一个看似可控的命令参数，可能只来自枚举值。

所以验证阶段不能只问“为什么这是漏洞”，还要问“什么条件下它不是漏洞”。

第七阶段是风险归并。

安全分析中大量结果会重复。多个入口可能落到同一个漏洞点，多个漏洞点可能属于同一种根因。Agent 需要把候选结果归并为更清晰的缺陷单元，区分根因、触发入口、影响范围和修复位置。

这一步决定了报告是否可读。否则系统很容易输出一大堆看似很多、实际重复的发现。

第八阶段是报告生成与人工复核。

最终报告应该包含结论、证据、影响、复现条件、修复建议和不确定性。对于证据不足的结果，不应该硬写成确认漏洞，而应该标记为“需要人工复核”。对于高风险结论，系统还应该保留完整的证据链，方便安全人员快速复查。

这样，一个安全 Agent 才不是简单地“帮我找漏洞”，而是形成了一个从项目理解到证据验证再到报告输出的闭环。

四、为什么安全 Agent 必须可恢复

安全任务和普通问答最大的区别之一，是过程成本很高。

一个 Agent 可能已经分析了几百个文件、构建了项目地图、排除了几十个错误假设、保留了几个高价值候选点。如果这个过程因为会话中断、上下文超限、工具失败或者环境重启而丢失，那么前面的成本就全部浪费了。

因此，可恢复性不是产品体验问题，而是安全 Agent 的基础能力。

一个可恢复的安全 Agent 至少应该保存几类状态：

项目画像，包括语言、框架、入口、依赖和关键模块。

分析轨迹，包括读过哪些文件、执行过哪些工具、得到过哪些中间结论。

漏洞假设池，包括每个假设的状态：待验证、证据不足、已否定、可疑、已确认、需要人工复核。

证据库，包括代码片段位置、调用链、配置条件、日志结果和测试反馈。

任务队列，包括下一步要分析什么、优先级如何、为什么排在前面。

报告草稿，包括已经确认的发现和暂时不能下结论的风险点。

有了这些状态，Agent 才能从“会话型助手”变成“任务型系统”。它可以中断后继续，可以换模型继续，可以换机器继续，也可以让人接管后继续。

这对于离线环境尤其重要。断网、算力有限、模型本地部署、工具链提前准备、镜像无法随时更新，这些都会让任务恢复能力变得更加关键。一个离线安全 Agent 如果不能恢复进度，本质上很难承担长周期分析任务。

五、监督器比主 Agent 更重要

很多 Agent 系统喜欢强调主模型有多强，但在安全场景中，监督器往往比主 Agent 更重要。

主 Agent 负责执行任务，而监督器负责判断执行是否还值得继续。

它需要回答几个问题：

当前分析是否陷入重复？

模型是否一直在阅读无关文件？

工具调用是否失败过多？

候选漏洞是否缺少证据？

报告是否把假设写成了结论？

任务是否越过了授权边界？

是否应该切换策略？

是否应该请求人工介入？

没有监督器的 Agent，很容易出现两类问题。

第一类是过度自信。模型发现一个疑似问题后，直接把它写成高危漏洞，但证据链并不完整。

第二类是无效循环。模型不断重复读取相同文件，反复生成相似结论，消耗大量上下文和算力，却没有推进任务状态。

监督器的价值就在于把这些失控行为变成可观测事件。它不需要比主 Agent 更聪明，但必须更稳定、更保守、更规则化。

安全 Agent 的设计原则应该是：主 Agent 可以发散，监督器必须收敛。

六、策略库不是规则库，而是经验的结构化沉淀

安全 Agent 不能只靠模型临场发挥。模型可以理解上下文，但长期能力来自经验沉淀。

这里的策略库不是传统意义上的正则规则库，也不是简单的漏洞模板库。它更像是一组可复用的分析方法。

例如：

遇到多租户系统时，优先检查资源 ID 是否绑定当前用户或组织。

遇到插件系统时，优先检查插件加载、权限隔离和动态执行边界。

遇到文件上传时，优先检查扩展名、内容类型、存储路径、访问路径和后续解析链路。

遇到管理后台时，优先检查普通用户是否能访问管理接口或触发后台任务。

遇到异步任务时，优先检查任务创建者、执行者和权限上下文是否一致。

这些策略不是直接给出漏洞，而是指导 Agent 生成更好的假设。它们的价值在于减少随机探索，提高分析优先级。

更进一步，策略库还应该能从历史任务中更新。某个项目中被证实有效的分析路径，可以沉淀成新的策略；某类频繁误报的模式，也可以沉淀成反证规则。

这才是真正有意义的“自进化”：不是让模型无限自由发挥，而是让系统从每次任务中提炼可复用经验。

七、安全 Agent 的能力边界

安全 Agent 的能力越强，边界越重要。

在授权代码审计和内部安全测试中，Agent 可以显著提高效率。它可以帮助安全人员快速理解项目结构，聚焦高风险模块，生成漏洞假设，收集证据，整理报告。

但这不意味着系统应该无约束地自动化攻击行为。

一个负责任的安全 Agent 应该默认具备以下限制：

只在授权范围内运行。

默认不扩大目标边界。

默认不执行破坏性操作。

高风险验证需要人工确认。

报告中区分“确认漏洞”“疑似风险”和“需要复核”。

所有工具调用保留日志。

所有结论必须有证据来源。

敏感能力不应该无门槛释放。

这不是削弱 Agent 的能力，而是让能力可以被真实使用。安全领域最不缺概念演示，真正缺的是能放进工程环境、能被审计、能被复查、能被长期维护的系统。

八、我们真正需要的不是“全自动”，而是“高质量半自动”

很多人喜欢用“全自动”来描述安全 Agent，但从工程角度看，高质量半自动可能更现实，也更可靠。

安全分析中最有价值的部分，并不是让系统完全替代人，而是让系统承担重复劳动，让人保留关键判断权。

Agent 适合做的是：

阅读大量代码。

建立项目地图。

检索相关上下文。

生成候选假设。

收集证据链。

排除明显误报。

归并重复结果。

整理报告初稿。

人更适合做的是：

判断业务影响。

确认授权边界。

审查高危结论。

决定是否进一步验证。

和开发团队沟通修复方案。

判断哪些风险值得投入。

这种分工比“全自动攻击”更接近真实安全工作的需求。真正有价值的 Agent，不是替人做决定，而是把人从低价值重复劳动中释放出来，让人专注于判断、取舍和责任。

九、结语：安全 Agent 是闭环系统，不是聊天机器人

安全 Agent 的发展方向，不应该停留在“模型会不会调用工具”，也不应该停留在“能不能一次性挖出漏洞”。

更重要的问题是：

它能否稳定运行长任务？

能否保存和恢复状态？

能否区分假设与结论？

能否主动寻找反证？

能否把经验沉淀成策略？

能否在授权边界内运行？

能否生成可复查的证据链？

能否让人更少做重复劳动，而不是让人承担更多验收成本？

如果这些问题没有解决，那么 Agent 只是一个包装更复杂的对话框。

如果这些问题被系统性解决，那么 Agent 才真正成为安全工程中的新基础设施。

所以，安全 Agent 的关键不是让模型更像一个“黑客”，而是让安全分析更像一个可运行、可恢复、可验证的工程闭环。