2026-06-23 06:17:30 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文探讨了安全运营从依赖大屏展示转向引入AIAgent以提升执行效率的趋势。文章指出，传统大屏在展示整体态势方面价值有限，难以直接回答告警研判、攻击源判断等核心问题。其核心观点是，未来的安全运营应更注重可执行性，利用AIAgent重构工作流程：Agent能够自动化处理告警研判、跨系统日志关联、攻击链还原、报告生成及处置建议等重复性高的任务，从而将安全分析师从繁杂劳动中解放出来，使其专注于高价值的判断与决策。文章还详细阐述了Agent所需具备的数据接入、工具调用、知识库、权限控制与审计等能力，并提出了分阶段的落地路径。最后强调，Agent的目标不是替代分析师，而是改变其工作方式，成为高效的辅助工具。 综合评分： 85 文章分类： 安全运营,AI安全,解决方案,技术标准,WEB安全

cover_image

安全运营的下一步：不是大屏，而是 Agent

原创

JacobWang JacobWang

NowSec

2026年6月19日 08:00 陕西

在小说阅读器读本章

去阅读

很多安全团队都做过大屏。

大屏上有攻击趋势、告警数量、攻击源 IP、攻击类型分布、资产状态、风险态势、处置进度。它看起来很完整，也很适合汇报。

但在真实的安全运营中，大屏解决的问题其实很有限。

它能告诉我们「发生了什么」，但很少能直接回答：

这个告警到底要不要处理？
这些攻击是不是同一批源头？
某个 IP 是扫描器、误报，还是正在尝试攻击？
这次异常是否影响核心业务？
是否需要升级处置？
周报、日报、事件报告应该怎么写？
下一步应该查哪几个系统？

过去，安全运营很容易被建设成「展示型系统」。

下一步，安全运营应该从「展示」走向「执行」。

而这个变化的核心，不是再做一个更炫的大屏，而是引入真正能参与分析和执行的 AI Agent。

一、大屏的价值正在到达边界

安全大屏并不是没有价值。

它适合展示整体态势，也适合领导快速了解当前风险。例如今天有多少攻击、哪些资产受攻击最多、哪些攻击类型增长明显、哪些数据中心风险较高。

但大屏的天然问题在于：它通常是结果展示，而不是工作入口。

安全分析师真正需要的不是「看到更多图表」，而是「更快做出判断」。

例如 WAF 告警来了，分析师要判断这是不是有效攻击。只看大屏是不够的，还要继续查：

源 IP 历史行为；
攻击路径是否命中真实业务；
是否被拦截；
是否存在绕过尝试；
同一时间是否有其他攻击类型；
后端业务是否出现异常；
蜜罐、EDR、态势平台是否有相关线索；
是否需要上报；
是否需要形成事件记录。

这些动作才是安全运营的真实工作量。

大屏只负责「呈现」，但不负责「思考」和「推进」。

这就是为什么很多安全团队建了很多可视化系统，但分析师仍然很累。因为图表越多，可能只是把问题展示得更明显，并没有真正减少分析过程。

二、安全运营的核心矛盾不是看不见，而是查不完

过去我们总说安全运营缺乏可视化，缺少全局视角。

但现在很多企业的问题已经变了。

不是看不见，而是看见了太多。

WAF 有告警，蜜罐有告警，EDR 有告警，态势平台有告警，云平台有告警，主机有日志，网关有日志，Nginx 有访问日志，业务系统也有异常日志。

数据越来越多，但真正能形成结论的分析能力并没有同比增长。

这就造成了几个典型问题。

第一，告警数量多，但有效告警少。分析师每天要在大量重复扫描、探测、误报、低危行为中筛选真正有价值的事件。

第二，线索分散。一个攻击行为可能同时出现在 WAF、蜜罐、EDR、流量日志、业务日志里，但这些系统之间并不天然打通。

第三，人工关联成本高。分析师需要来回切换系统，复制 IP、时间、URL、站点名称、资产信息，再手工拼出攻击路径。

第四，报告输出占用大量时间。日报、周报、事件通报、复盘材料，看起来是文档工作，实际上背后需要大量数据筛选、归类和总结。

第五，经验难以沉淀。老分析师知道某类攻击该怎么查，但这种经验往往停留在个人脑子里，难以变成标准化流程。

所以，安全运营真正需要的不是更多图，而是一个能帮助分析师完成调查、关联、判断和输出的执行层。

这正是 Agent 可以切入的地方。

三、Agent 和普通 AI 助手有什么区别？

很多人一提到 AI，就想到「问答助手」。

比如问它：「这个告警是什么攻击？」它回答：「这可能是 SQL 注入。」

这种能力有用，但还不够。

安全运营需要的不是一个只会回答问题的聊天框，而是一个能完成任务的 Agent。

二者区别很明显。

普通 AI 助手更像顾问，负责解释和建议。 Agent 更像初级分析员，负责拆解任务、调用工具、读取数据、整理证据、生成结论。

例如面对一个 WAF 告警，Agent 不应该只是解释「目录穿越是什么」，而应该继续做这些事：

查询该源 IP 近 24 小时行为；
判断是否攻击多个站点；
统计命中的攻击类型；
检查是否全部被拦截；
查询同一目标是否还有其他异常；
关联蜜罐或 EDR 是否存在同源行为；
形成一段可直接写入事件记录的结论；
给出是否需要上报、是否需要继续观察的建议。

这才是安全运营需要的 AI。

不是「告诉我知识」，而是「帮我把这件事查清楚」。

四、Agent 可以重构哪些安全运营场景？

1. 告警研判

这是 Agent 最容易落地的场景。

传统告警研判依赖人工查看字段和日志。Agent 可以把固定动作自动化：

提取源 IP、目标 IP、URL、攻击类型、风险等级；
查询历史攻击次数；
判断是否为批量扫描；
检查是否命中核心站点；
判断是否被拦截；
结合规则输出初步结论。

例如：

该源 IP 在 30 分钟内访问 12 个站点，主要命中目录穿越和信息泄露规则，所有请求均已被 WAF 拦截，暂未发现后端异常，建议判定为自动化扫描行为，持续观察即可。

这类结论，过去可能需要分析师手动查几分钟。Agent 可以在几秒到几十秒内形成初稿。

2. 多系统日志关联

安全事件很少只存在于一个系统里。

WAF 看到的是 Web 攻击行为，蜜罐看到的是诱捕交互，EDR 看到的是主机行为，Nginx 看到的是访问链路，态势平台看到的是汇总事件。

Agent 的优势在于可以跨系统查询和组织证据。

例如一个源 IP 触发 WAF 告警后，Agent 可以继续问：

这个 IP 是否访问过蜜罐？
是否触发过 EDR 告警？
是否命中过多个数据中心？
是否访问过后台路径？
是否存在同网段批量扫描？
是否与历史攻击 IP 有相似行为？

这些工作对人来说不难，但重复性很强。

Agent 可以把这些操作流程化，让分析师只看整理后的证据链。

3. 攻击链还原

单条告警的价值有限，攻击链才有判断意义。

例如一次真实攻击可能经历：

资产探测 → 敏感路径扫描 → 参数测试 → 漏洞利用 → WebShell 上传 → 横向移动

传统大屏通常只能展示某个时间段内的攻击数量，很难自动还原攻击链。

Agent 可以基于时间、源 IP、目标资产、URL、攻击类型、响应状态等字段，把分散日志串起来，生成一个相对完整的过程描述。

例如：

攻击者首先对 /admin、/login、/api 路径进行探测，随后尝试访问备份文件和配置文件路径，之后对 userId、id、file 参数进行注入测试。整体行为符合自动化漏洞扫描特征，暂未观察到成功利用迹象。

这类输出比单纯的柱状图更有运营价值。

4. 日报、周报和事件报告生成

安全运营中大量时间消耗在报告上。

报告不是简单复制数据，而是要把数据变成结论。

例如 WAF 周报需要说明：

本周总请求量；
异常请求量；
拦截数量；
攻击类型分布；
TOP 站点；
TOP 源 IP；
高风险事件；
处置情况；
趋势变化；
下周关注点。

这些内容非常适合 Agent 处理。

因为它既需要结构化统计，也需要自然语言总结。传统脚本可以生成 Excel 和图表，但很难写出较自然的分析结论。大模型可以写总结，但如果没有数据接口，就容易空泛。

Agent 的理想方式是：

调用数据接口 → 生成统计结果 → 识别异常变化 → 组织图表和文字 → 输出周报初稿

这样分析师只需要审核和补充，而不是从零开始写。

5. 处置建议和流程编排

Agent 还可以根据事件类型给出处置建议。

例如：

扫描类事件：观察、归并、必要时加入监控名单；
SQL 注入：确认是否拦截，检查是否命中真实业务接口；
信息泄露：确认路径是否真实存在，必要时通知业务整改；
文件上传：检查是否产生异常文件，联动主机侧排查；
暴力破解：关联登录日志和账号状态；
蜜罐命中：确认是否存在内网横向移动迹象。

需要注意的是，Agent 不应该一开始就直接执行高风险动作。

比较合理的路径是：

先辅助分析 → 再生成建议 → 再进入半自动处置 → 最后才是策略化自动处置

也就是说，Agent 可以先成为「分析助手」，再逐步成为「执行助手」。

五、Agent 不是替代分析师，而是改变分析师的工作方式

很多人担心 AI Agent 会不会替代安全分析师。

从短期看，更现实的变化不是替代，而是分工重构。

低价值、重复性、规则明确的工作，会逐渐交给 Agent：

初步告警分类；
日志字段提取；
多系统查询；
历史行为统计；
报告初稿生成；
常见事件处置建议；
知识库检索和标准话术生成。

而分析师会更多承担高价值判断：

判断是否为真实攻击；
判断是否升级事件；
判断业务影响；
判断处置动作是否可能影响生产；
判断是否需要跨部门协同；
判断是否需要调整策略和规则。

换句话说，Agent 负责把证据摆上桌，分析师负责做判断。

这才是比较健康的安全运营模式。

六、建设 Agent 化安全运营系统，需要哪些能力？

如果要真正落地，不是接一个大模型接口就够了。

一个可用的安全运营 Agent，至少需要以下几层能力。

1. 数据接入能力

Agent 必须能访问安全运营数据，例如：

WAF 告警；
蜜罐告警；
EDR 事件；
资产信息；
站点信息；
Nginx/Tengine 访问日志；
态势平台事件；
工单和处置记录；
威胁情报数据。

没有数据，Agent 就只能空谈。

2. 工具调用能力

Agent 不能只会聊天，还要能调用工具。

比如：

查询某个 IP 的历史攻击；
查询某个站点近 7 天风险趋势；
查询某个 URL 是否多次命中规则；
调用威胁情报接口；
生成 Excel 报表；
生成事件摘要；
创建工单草稿。

工具调用能力决定了 Agent 能不能真正进入工作流。

3. 知识库能力

安全运营有大量本地知识：

攻击类型解释；
内部处置流程；
上报口径；
数据中心信息；
站点负责人；
工单规范；
历史典型事件；
周报模板；
重保期间策略要求。

这些知识不能完全依赖大模型记忆，而应该沉淀成可检索的知识库。

Agent 每次分析时，都应该结合本地知识库，而不是凭感觉生成答案。

4. 权限控制能力

Agent 能调用越多工具，权限风险越高。

所以必须做权限分级：

只读查询；
报告生成；
工单创建；
策略建议；
策略修改；
联动处置。

前期建议只开放只读能力和报告生成能力。涉及封禁、策略变更、隔离主机等动作，必须保留人工确认。

5. 审计能力

Agent 做过什么，必须可追溯。

包括：

查询了哪些数据；
调用了哪些工具；
生成了哪些结论；
使用了哪些证据；
是否触发了处置动作；
人工是否确认。

安全运营本身就要求可审计，Agent 更不能成为黑盒。

七、Agent 化安全运营的落地路径

企业不应该一上来就做「全自动 SOC」。

更合理的落地路径是分阶段推进。

第一阶段：报告型 Agent

先从低风险场景入手。

例如：

自动生成日报；
自动生成周报；
自动总结攻击类型分布；
自动输出站点 TOP5；
自动生成事件描述。

这个阶段主要目标是减少文档工作量。

第二阶段：研判型 Agent

接着让 Agent 参与告警分析。

例如：

单条告警解释；
源 IP 行为画像；
攻击类型归并；
误报初筛；
风险等级建议；
事件摘要生成。

这个阶段主要目标是减少重复查询和初步判断成本。

第三阶段：关联型 Agent

再进一步，让 Agent 跨系统关联。

例如：

WAF + 蜜罐；
WAF + EDR；
态势平台 + WAF；
Nginx 日志 + 业务异常；
攻击源 IP + 威胁情报；
告警 + 工单 + 历史事件。

这个阶段主要目标是形成证据链。

第四阶段：处置型 Agent

最后才考虑半自动处置。

例如：

创建工单；
生成上报内容；
提供策略调整建议；
生成封禁建议；
生成业务侧整改建议；
对高风险动作请求人工确认。

这个阶段必须谨慎，不能让 Agent 直接操作生产系统的关键策略。

八、为什么「不是大屏，而是 Agent」？

因为大屏是给人看的，Agent 是帮人干活的。

大屏解决的是展示问题。 Agent 解决的是工作流问题。

大屏告诉你「攻击变多了」。 Agent 应该告诉你「哪些攻击值得处理」。

大屏告诉你「某个站点告警最多」。 Agent 应该继续分析「是不是业务暴露面变大，还是被同一批 IP 扫描」。

大屏告诉你「SQL 注入数量上升」。 Agent 应该继续判断「是否命中真实接口，是否全部拦截，是否存在绕过尝试」。

大屏告诉你「某个数据中心风险较高」。 Agent 应该继续关联「具体站点、攻击源、攻击类型、处置建议和报告内容」。

安全运营的下一步，不是把图表做得更炫，而是把分析过程变得更短。

过去的安全建设强调「可视化」。未来的安全建设会更强调「可执行」。

九、Agent 也会带来新的风险

当然，Agent 不是万能解药。

如果数据质量差，Agent 只会更快地产生错误结论。

如果日志不完整，Agent 可能误判攻击链。

如果权限过大，Agent 可能误触发高风险动作。

如果知识库过时，Agent 可能沿用错误流程。

如果没有审计，Agent 的分析过程就无法复盘。

所以，Agent 化安全运营的关键不是「让 AI 更自由」，而是「让 AI 在边界内工作」。

比较稳妥的原则是：

能查询，不轻易修改； 能建议，不直接处置； 能生成草稿，不自动上报； 能关联证据，不替代最终判断。

在安全运营场景里，AI Agent 最重要的价值不是完全自治，而是把人从重复劳动中释放出来，让人专注于真正需要经验和判断的部分。

十、未来的 SOC 会是什么样？

未来的 SOC，可能不再是一个人盯着十几个系统轮流查。

更可能是这样的：

告警进入系统后，Agent 自动完成初步研判。

它会查询历史日志，关联资产信息，补充威胁情报，匹配历史事件，判断攻击路径，生成证据摘要，并给出处置建议。

分析师打开事件时，看到的不再是一堆原始日志，而是一份结构化调查结果：

事件结论： 疑似自动化扫描，暂未发现成功利用。 &nbsp;关键证据： 1. 源 IP 在 1 小时内访问 8 个站点； 2. 主要命中目录穿越和信息泄露规则； 3. 请求均已被 WAF 拦截； 4. 蜜罐未发现同源交互； 5. EDR 未发现目标主机异常； 6. 后端业务日志未见 5xx 异常升高。 &nbsp;建议动作： 持续观察，归并为扫描类事件，暂不升级。

这才是安全运营真正需要的界面。

不是大屏，而是结论。不是图表，而是证据。不是堆数据，而是推进处置。

结语

安全运营过去很长一段时间都在追求「看得见」。

于是我们建设日志平台、态势感知、大屏、报表、指标体系。

这些东西仍然重要，但它们只是基础。

下一阶段，安全运营要解决的是「看见之后怎么办」。

AI Agent 的价值就在这里。

它可以把分散的数据串起来，把重复的查询自动化，把模糊的告警整理成证据，把复杂的日志转化成结论，把繁琐的报告变成初稿。

所以，安全运营的下一步，不是再做一个更大的大屏。

而是构建一个真正能参与研判、关联、总结和执行的 Agent。

未来的安全运营中心，不应该只是一个展示风险的地方。

它应该是一个能持续分析风险、推动处置、沉淀经验的智能工作流系统。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：NowSec JacobWang JacobWang《安全运营的下一步：不是大屏，而是 Agent》