安全 Agent 系列（二）：安全 Agent 越复杂，能力就越强？

原创

木火纪
木火纪

木火纪

2026年10月28日 15:40
浙江

去阅读

引言

随着大语言模型逐渐进入网络安全领域，安全 Agent 已经形成多种不同的技术实现方式。有些系统只在传统安全工作流中增加几个 AI 分析节点，有些由单个 Agent 自主选择工具，还有一些采用多 Agent 协作架构，让不同智能体分别承担资产发现、漏洞分析、事件调查和结果验证等任务。

本文是安全 Agent 系列的第二篇，主要介绍当前常见的技术模式、工作流组织方式和完整系统架构，适合希望进一步理解 Agent 技术实现的安全工程师及 IT 开发人员。文章将结合渗透测试和安全运营场景，解释不同架构的适用范围，以及构建安全 Agent 时需要考虑的主要技术问题。

安全 Agent 的四种模式

从执行流程和决策权限来看，目前的安全 Agent 可以归纳为四种常见模式：固定工作流结合 LLM、单 Agent 动态决策、多 Agent 协作以及人机协同。

这是一种便于工程分析的分类方式，实际产品往往会组合使用多种模式。

固定工作流与 LLM

这是目前较容易实现和落地的模式。

系统仍然使用传统程序或工作流引擎控制执行顺序，在需要复杂分析的环节调用 LLM。

例如，某企业的 SIEM 产生了一条异常登录告警，系统可以按照以下流程执行：

接收告警 → 查询登录日志 → 获取账号信息 → 检索威胁情报 → LLM 分析 → 生成调查报告。

其中，日志查询、账号检索和威胁情报调用都可以由传统程序完成，模型只需要分析经过筛选的证据。

这种模式的主要特点是执行路径明确、结果容易追踪、成本相对可控。模型即使出现错误，也通常只影响局部分析节点，便于进行重试、验证或人工复核。

对于 SOC 告警分类、漏洞报告整理、日志分析和威胁情报汇总等任务，固定工作流结合 LLM 是值得优先考虑的实现方式。

不过，其灵活性受到预设流程限制。当任务出现没有覆盖的情况时，需要新增规则、调整工作流或转交人工。

单 Agent 动态决策

单 Agent 模式由一个主要 Agent 负责整个任务的规划、工具选择和执行控制。

例如，针对授权 Web 系统开展安全评估，Agent 可以先调用资产探测工具，再根据发现的服务决定后续检查方式。

假设识别到某个 Web 应用使用了特定框架，Agent 可以选择对应的技术栈检查工具；如果工具没有返回有效结果，则根据错误信息调整参数，或者选择其他验证方式。

这一模式具有较强的灵活性，能够处理部分事先难以完整定义的任务。

其典型执行过程是：

理解任务 → 制定计划 → 调用工具 → 分析结果 → 更新计划 → 继续执行。

单 Agent 的优势是架构相对简单，开发和维护成本通常低于复杂的多 Agent 系统。

但如果任务涉及大量资产、长时间执行和多种专业分析，单个 Agent 需要管理的上下文会不断增加。模型可能忽略早期证据、重复调用工具，或者在任务执行过程中偏离原定目标。

因此，单 Agent 更适合任务范围相对明确、工具数量有限、能够设置清晰停止条件的场景。

Multi-Agent 多智能体协作

Multi-Agent 模式将复杂任务拆分给多个具有不同职责的 Agent，通过协作完成最终目标。

例如，在自动化渗透测试场景中，可以设置不同的角色：

资产分析 Agent： 负责目标资产发现、服务识别和基础信息整理。

漏洞分析 Agent： 根据资产特征选择检测方法，分析潜在漏洞。

验证 Agent： 根据授权范围执行必要的验证，并检查证据是否支持漏洞结论。

报告 Agent： 汇总经过验证的信息，生成测试报告。

系统还可以设置一个 Supervisor（监督与调度 Agent），负责分配任务、协调各个 Agent 的执行顺序和整合结果。

这种模式能够减少单个 Agent 承担的职责，并允许不同任务使用不同的模型、工具与上下文。

但 Multi-Agent 同时引入了更多工程问题，包括 Agent 之间的状态同步、信息传递、任务冲突、重复执行、模型成本和错误传播。

例如，资产分析 Agent 发现某个开放端口后，漏洞分析 Agent 可能需要获取对应的服务指纹及原始证据。如果共享信息不完整，后续分析就可能出现错误。

此外，多个 Agent 并不意味着系统一定更智能。 如果任务可以通过简单工作流完成，增加多个 Agent 往往只会提高系统复杂度和运行费用。

Multi-Agent 更适合专业职责差异明显、任务可以拆分，且确实需要并行处理或动态协作的复杂场景。

Human-in-the-Loop 人机协同

人机协同主要解决 Agent 自主执行与企业安全控制之间的关系。

在生产环境中，Agent 可以执行的操作往往具有不同风险等级。

例如，读取日志、查询资产、检索威胁情报通常属于相对低风险操作；隔离终端、禁用账号、修改防火墙策略则可能直接影响业务。

因此，系统可以让 Agent 自动完成调查和分析，在执行高风险操作前暂停任务，等待安全工程师审批。

以疑似终端入侵事件为例，Agent 可以自动完成进程分析、登录记录检查、网络连接关联和威胁情报检索。当系统判断需要隔离终端时，先提交调查证据和操作建议，由授权人员决定是否执行。

审批通过后，工作流继续运行，并保存操作记录。

这种模式能够将 Agent 的分析能力与企业的权限管理、变更流程和审计体系结合，适合安全运营和应急响应场景。

四种模式的适用范围

不同模式之间没有统一的优劣排序，关键在于任务特征、运行成本和风险要求。

从现有工程实践来看，固定工作流结合 LLM 和人机协同的生产落地路径相对清晰。单 Agent 已适用于部分工具驱动和动态调查任务，而完全自主的复杂渗透测试仍面临可靠性、泛化能力和执行安全方面的挑战。

需要强调，人机协同可以嵌入其他三种模式，实际系统通常同时具备多种架构特征。

安全 Agent 的工作流编排

除了按照 Agent 数量与决策方式划分，还可以从任务组织方式理解 Agent 架构。

Anthropic 在《Building Effective Agents》中总结了 Prompt Chaining、Routing、Parallelization、Orchestrator-Workers 和 Evaluator-Optimizer 等常见模式。这些模式可以作为独立工作流，也可以组合到更复杂的 Agent 系统中。

顺序执行

顺序执行将任务拆分为相互依赖的多个步骤，前一步的输出作为后一步的输入。

例如，安全报告生成可以分为：提取检测结果、分析风险、整理证据、生成报告、检查内容。

这种方式适合处理步骤明确的任务，也便于在各个环节加入规则验证。

路由分发

路由模式根据任务类型选择不同的处理流程。

例如，SOC 收到不同类型的告警，可以先进行分类：异常登录进入身份安全调查流程，恶意文件进入终端分析流程，Web 攻击进入流量分析流程。

路由判断可以由规则引擎完成，也可以在分类困难时使用 LLM。

合理的路由设计能够减少模型需要处理的无关信息，并降低工具选错的概率。

并行执行

并行模式让多个相互独立的任务同时运行。

例如，在授权范围内对一批资产开展检查时，端口探测、历史资产信息查询和部分情报检索可以并行执行。

并行处理可以减少总执行时间，但需要控制工具并发、API 限流及目标系统负载。

调度与协作

在 Orchestrator-Workers 模式中，调度组件根据任务情况动态分解工作，再分配给不同执行单元。

例如，一个复杂的安全事件同时涉及账号异常、终端恶意进程和云平台权限变化。调度 Agent 可以组织不同的专业分析任务，并在全部结果返回后进行综合判断。

这种方式适合需要根据调查结果动态生成子任务的场景。

生成与验证循环

Evaluator-Optimizer 模式通过生成、检查与反馈形成迭代。

例如，一个 Agent 负责分析漏洞证据，另一个验证组件检查证据是否完整、结论是否符合验证标准。如果发现信息不足，则将具体问题返回给分析 Agent。

验证组件可以是规则程序、专业模型或人工审核，不必全部依赖 LLM。

对于安全领域，这种模式尤其重要，因为安全结论需要事实证据支持。模型生成的解释不能直接替代漏洞验证结果。

安全 Agent 的完整技术架构

无论采用哪种模式，一个需要长期运行的安全 Agent 都需要解决任务管理、决策、工具执行、状态存储、结果验证及安全控制等问题。

从工程角度，可以将系统划分为六个主要层次。

任务入口层

任务入口负责接收用户或其他系统提交的安全目标。

例如，用户通过 Web 页面提交授权扫描任务，或者 SIEM 在触发告警后通过 API 启动调查。

任务信息应当包含目标范围、执行权限、优先级和限制条件。

对于安全测试类任务，授权资产范围、允许使用的工具及操作边界都需要在任务开始前确定。

决策编排层

决策编排层负责决定任务如何执行。

其中，LLM 可以承担任务理解、工具选择和复杂结果分析；Planner 负责维护执行计划；Workflow Engine 则管理流程、条件分支、重试和任务状态转换。

这些职责可以由一个 Agent 实现，也可以分别由模型和确定性程序承担。

例如，模型决定查询某个账号最近的登录行为，工作流负责执行顺序和失败处理，执行器负责调用实际的日志系统。

模型负责生成决策，工作流负责控制执行过程，具体操作由工具执行器完成。

这一分工有助于降低模型错误对底层系统产生的影响。

工具执行层

工具执行层连接传统安全能力。

在攻击面管理和安全测试中，可以接入 Subfinder、Nmap、httpx、Nuclei 等工具；在安全运营中，可以连接 SIEM、EDR、云安全平台、工单系统及威胁情报接口。

工具通常需要经过标准化封装，明确名称、用途、参数、返回结构及错误信息。

执行器还需要处理超时、异常退出、并发控制和调用权限。

对于可能造成业务影响的安全操作，应当使用受限执行环境，并根据任务权限控制可执行的命令或 API。

状态与知识层

Agent 在执行多步骤任务时，需要持续保存状态。

例如，一个资产扫描任务可能已经完成 200 台服务器中的 120 台。如果进程中断，系统应能够恢复剩余任务，而无需重新执行全部扫描。

状态数据库可以保存任务 ID、扫描对象、工具调用记录、执行结果、完成进度和后续计划。

知识系统则提供漏洞资料、历史事件、处置手册和企业安全策略等参考信息。

这里需要区分几个概念：

State（状态）： 当前任务执行到了哪里，哪些步骤已完成。

Memory（记忆）： 当前任务或历史任务中可复用的上下文和经验。

RAG（检索增强生成）： 在需要时从外部知识源检索相关内容，为模型提供参考。

对于 IP、端口、资产编号和执行时间等结构化信息，普通数据库通常更合适；对于历史案例和自然语言文档，可以根据需要采用全文检索或向量检索。

结果验证层

结果验证层直接影响安全 Agent 的输出质量。

例如，Nuclei 发现某个潜在漏洞后，模型可以解释其风险，但漏洞是否真实存在，还需要检查对应证据和验证条件。

因此，系统应当区分待验证发现、已确认问题和无法确认的结果。

一种常见的状态流程是：

待分析 → 疑似风险 → 验证中 → 已确认 / 未证实 / 无法判断。

结果验证可以使用规则引擎、独立验证工具、模型交叉检查或人工复核。

对于需要提交正式安全报告的系统，应该保留原始工具输出和必要的验证证据，避免仅依据模型生成的文字得出最终结论。

安全治理层

安全治理贯穿整个 Agent 执行过程。

Agent 可能需要调用安全设备 API、读取企业内部日志，甚至执行终端隔离等操作。这些能力需要受到身份认证、权限策略和审批机制约束。

系统应当提供最小权限、工具调用限制、敏感操作审批、凭据保护、执行日志以及资源预算等能力。

同时，外部网页、日志、邮件和工具响应都可能包含不可信内容。Agent 必须区分用户授权指令与外部数据，避免工具返回内容诱导模型执行越权操作。

对于生产环境，安全策略需要由应用程序和执行平台落实，不能仅依赖提示词。

架构设计中的三个关键问题

理解系统分层后，还有三个问题需要特别关注。

哪些任务交给 LLM

安全 Agent 的性能与成本，很大程度上取决于模型参与了多少工作。

对于 DNS 解析、数据去重、端口扫描和明确的规则匹配，传统程序通常具有更稳定的性能和更低的成本。

对于非标准响应分析、复杂证据关联和下一步调查规划，模型能够发挥更大的作用。

例如，一次扫描发现数千个 URL，可以先通过规则完成筛选和分类，再将少量异常结果提交给 LLM。让模型逐条阅读所有原始结果，通常会增加成本和上下文负担。

因此，设计 Agent 时应先明确任务中哪些环节真正需要模型判断。

如何管理长时间任务

安全任务可能持续数小时，涉及大量工具调用和中间结果。

如果系统完全依赖模型上下文记录进度，就容易出现上下文膨胀、信息丢失和重复执行。

更合理的方案是将任务状态持久化，并根据需要从数据库提取相关信息。

同时，工作流应当设置检查点，在任务失败或中断后能够恢复执行。

例如，LangGraph 提供状态持久化和中断恢复机制，使开发者可以围绕节点和状态构建长时间运行的 Agent 工作流。

如何控制执行风险

Agent 的决策可能出现错误，因此需要明确执行权限与操作边界。

例如，在授权扫描场景中，可以限制 Agent 只能访问指定资产，并设置请求速率和并发数量。

在 SOC 场景中，可以允许 Agent 自动查询日志和威胁情报，但对隔离终端、封禁账号和修改网络策略等操作设置人工审批。

系统还需要设置最大执行步数、超时、重试上限和预算限制，避免 Agent 在错误判断后持续循环。

这些控制能力会直接影响 Agent 能否安全、稳定地运行。

如何选择合适的架构

对于安全工程师和开发团队，选择 Agent 架构时，可以先从任务特征入手。

如果任务步骤明确，主要需求是解释结果或生成报告，可以优先采用固定工作流与 LLM 节点。

如果任务需要根据中间结果动态选择工具，且规模相对可控，可以采用单 Agent 架构。

如果任务涉及多个专业领域，需要大量并行处理或动态分工，可以进一步评估 Multi-Agent。

如果 Agent 将接入生产系统，并可能执行具有业务影响的操作，则应加入相应的人机协同、权限控制和审批机制。

对于大多数初期项目，建议先实现工具接口、状态管理、决策循环和结果验证，再逐步增加复杂的编排功能。

架构复杂度应当由任务需求决定，并通过实际效果验证其必要性。

总结

目前安全 Agent 已形成多种技术模式，包括固定工作流结合 LLM、单 Agent 动态决策、多 Agent 协作和人机协同。不同模式在灵活性、执行效率、成本、可靠性和安全治理方面各有特点，实际产品通常会组合使用。

从完整架构来看，一个安全 Agent 需要将模型决策、工具执行、任务状态、知识检索、结果验证和安全治理组织成可持续运行的系统。模型能力决定了部分复杂任务的分析上限，工作流设计、工具质量和工程控制则直接影响系统的稳定性及实际执行效果。

对于准备开发安全 Agent 的工程师，理解这些模式和组件之间的关系，有助于判断哪些能力可以使用传统程序实现，哪些环节需要 LLM，以及何时有必要引入更复杂的 Agent 框架。