实习手记 ：从传统SOC痛点出发，我们为什么要在项目中引入AI Agent？

背景碎碎念：入职实习做 Agent SOC 平台开发也有一段时间了。每天看着导师和团队跟各种安全告警、ELK 查询、威胁情报 API 打交道，我深刻体会到了传统安全运维的痛点。今天这篇博客，就想结合自己的实习开发视角，记录一下我们为什么要做这个项目，以及整体的宏观架构设计长啥样。

01. 现实中的 SOC：每天都在“海量告警”里捞针

在做这个项目之前，我对 SOC（安全运营中心）的印象还停留在电影里那种大屏幕、炫酷攻击地图的层面。但真正深入开发后才发现，真实的日常其实是：满屏的 Alert Fatigue（告警疲劳）。

我们目前主要的 SIEM（安全信息和事件管理）平台是 ELK（Elasticsearch, Logstash, Kibana）。全网的防火墙、EDR、主机审计日志源源不断地汇聚过来，通过各种告警规则哗哗地往外吐。

作为开发人员，我在调研和写业务逻辑时，发现传统 SOC 面对的痛点实在太典型了：

1. 误报率高，人工成本大：分析师每天上班第一件事就是面对成百上千条告警。是不是攻击？得一条条点开看。
2. 割裂的研判链路：

• 在 Kibana 看到一个可疑外联 IP 告警。
• 复制 IP $\to$ 切到网页去 VirusTotal 或 OTX 查情报。
• 再切到内部资产系统（CMDB）看这台机器是哪个部门的、归属谁。
• 最后结合 MITRE ATT&CK 框架去写研判报告。
• 整个过程全靠分析师人工手动“串联”，工具之间是孤岛，极度依赖个人的经验和体力。

3. 传统 SOAR 的死板：虽然可以用传统的自动化脚本（Playbook）做一些固定的阻断，但安全对抗是动态的。面对复杂多变、需要结合上下文进行“推理”的事件，老一套的自动化脚本根本不够灵活。

02. 破局：让 LLM 成为我们的“数字安全分析师”

大模型火了之后，团队自然而然地开始思考：能不能用 AI Agent 来接管这套繁琐的研判流程？

理想中的画面是：当 ELK 报出一条可疑告警时，AI 不仅能看懂，还能像一个初级安全分析师一样，自己去调工具查情报、翻资产库、做关联分析，最后输出一份结构化的研判结论。

为了落地这个想法，我们在架构上做了一次重新梳理：

在这个架构里，数据和控制流向非常清晰：

• 输入端：ELK 产生原始告警 $\to$ 消费并清洗成规范的 Prompt 上下文。
• 思考端：DeepAgents 接收告警，自己拆解步骤（比如：“我得先查情报，再查资产，最后做综合研判”）。
• 执行端：Agent 按需动态去调右侧的工具箱（API）。
• 输出端：生成研判报告，让人工安全专家来做最后把关（Human-in-the-loop）。

03. 为什么在框架上我们选择了 LangChain + DeepAgents？

在技术选型阶段，导师带我对比了几种方案。我们最终落脚在 LangChain 体系下的 DeepAgents 框架，主要有这么几个现实考量：

1. 极其友好的 Tool Calling（工具调用）能力：
   安全开发最痛苦的就是要对接各种杂七杂八的异构 API。LangChain 的 @tool 装饰器和 Pydantic 参数校验，能让 LLM 非常稳定地把自然语言转化为规范的结构化参数去调我们的工具。
2. 完美的 ReAct 范式支持：
   安全研判很少是一步到位的。比如查完情报发现是个内网代理，Agent 需要有“动态改变计划”的能力（即 Reasoning + Acting 的循环）。DeepAgents 在这方面支持得很好，能够支撑多步迭代的复杂任务。
3. 状态与上下文管理：
   在长链路的研判过程中，Agent 必须记住前面几步查出来的关键证据（比如恶意哈希值、攻击者的 IP 节点）。LangChain 的 Memory 机制帮我们省了很多自己去维护对话上下文的麻烦。

04. 实习小结与下一步

第一阶段的架构设计和选型差不多就是这样。把大模型和真实的 SIEM（ELK）结合起来，远比写普通的 CRUD 更有挑战，每天都能学到很多安全领域和 AI 工程化结合的新东西。

不过，架构图画得再好，落地也是一步步来的。告警数据到底是怎么从 Elasticsearch 稳妥地流转到 Agent 手里的？中间的上下文又是怎么清洗和构建的？

这就是我接下来要在第二篇博客里记录的重点内容了：《实习手记：从 ELK 到 Agent 的“最后一公里”数据消费实战》。保持学习，继续敲代码！