在现代企业安全运营中心（SOC）中，安全分析师每天都面临着海量的告警。一个高级持续性威胁（APT）或勒索软件攻击，往往会在防火墙、EDR、邮件网关和域控日志中留下支离破碎的痕迹。传统的 SIEM 平台虽然能聚合这些日志，但将这些孤立的“点”连成完整的“攻击链路”，依然高度依赖分析师的个人经验和手工查询。

为了探索自动化溯源的可行性，我们构建了一个基于 Multi-Agent（多智能体） 和 Neo4j 图数据库的安全事件自动分析溯源 POC 系统。本文将详细探讨为什么选择“图+AI”的架构，多智能体协同的设计思路，以及未来的演进方向。

一、 为什么是“Agentic + 图搜索”？

安全事件的本质是建立在**实体（Entity）与关系（Relationship）**之上的。攻击者（实体 A）通过某个漏洞（关系 R），控制了某台主机（实体 B），进而在主机上执行了恶意进程（实体 C）。

传统的以表格和关系型数据库为核心的日志系统，在进行多跳（Multi-hop）的溯源时（例如：查找“与下载了可疑文件的机器通过 RDP 通信过的所有其他机器”）会产生性能灾难（复杂的 JOIN 操作）。而**图数据库（如 Neo4j）**天生就是为了表达复杂网状关系而设计的。

引入大语言模型（LLM）与图数据库结合（Graph RAG 模式的变种），带来了化学反应：

1. 语义理解与查询生成：AI 可以理解分析师的自然语言意图，并将其自动转化为精准的 Cypher 图查询语句，极大地降低了非专业人员直接操作复杂图数据库的门槛。
2. 多跳查询性能优化：在处理 5 跳甚至更深度的复杂关联查询时，图数据库的原生深度搜索往往会遭遇巨大的性能瓶颈。通过 AI 智能体将长链条查询拆解为多个子步骤（例如先查 A->B，再根据 B 的结果查 B->C），可以有效规避“路径爆炸”问题，提升系统的响应速度和鲁棒性。
3. 海量图谱中的线索提纯：面对图数据库返回的庞杂数据，AI 能够像资深专家一样进行研判，剔除误报，提取有价值的上下文。

二、 核心实现思路：模拟专家思维的多智能体协同

先看下实例效果，直接上代码

本系统设计的核心，是让不同的 Agent 扮演 SOC 团队中的不同角色。系统包含 五个核心 Agent 和一个全局的状态总线（State）。

2.1 状态总线 (InvestigationState)：一切协作的基石

在 LangGraph 框架下，所有 Agent 不直接互相通信，而是通过读写同一个状态总线（State）来协作。这就像是案件调查室里的一块“大白板”。

以本系统的 [InvestigationState](file:///home/soc/Desktop/lab/state/investigation_state.py#37-71) 为例：

class InvestigationState(TypedDict):
    user_question: str               # 用户的初始问题
    investigation_goal: str          # Coordinator 提取的目标
    key_entities: list[dict]         # 核心实体（如 IP、用户名）
    current_plan: str                # Planner 的当前分析思路
    query_instructions: str          # Planner 下发给 Retriever 的查询指令
    queries_executed: list[dict]     # 已经执行过的历史查询结果
    evidence_collected: list[dict]   # Analyzer 提炼出的确凿证据
    iteration_count: int             # 循环迭代次数防死循环
    # ...

工作原理举例：

1. 分析开始时，白板上只有 user_question: "查一下 10.10.3.50"。
2. Coordinator 拿到白板，提取出 IP，在白板上写下 key_entities: ["10.10.3.50"]。
3. Planner 看到完整的白板，将自己的分析思路写在 current_plan 中，并生成查询指令覆盖 query_instructions。
4. Retriever 拿走指令，执行完数据库查询后，将结果追加到 queries_executed 这个列表中。
5. Analyzer 审查那些结果，如果有发现，就将高亮线索追加到 evidence_collected 中。

这种“单向数据流”与“状态追加”的设计，保证了哪怕经历几十轮循环，Agent 都拥有完整的上下文，不会“失忆”。

2.2 五大智能体角色分工与核心 Prompt 解析

系统编排了以下五个关键角色：

1. Coordinator (协调员)

   • 职责：大堂经理，负责处理用户的非结构化输入，归类安全事件并提取实体定下基调。
   • 核心 Prompt 节选：

     “Your job is to: 1. Classify the investigation type based on the user’s question. 2. Extract key entities (IPs, hostnames, usernames, hashes, etc.). 3. Define a clear investigation goal… Output Format (strict JSON)”

2. Planner (规划师)

   • 职责：经验老道的“老猎手”。基于白板上的 evidence_collected，决定下一步“查什么”。系统特别支持 Planner 思考并下发多个**并行查询（Parallel Queries）**以提高效率。
   • 核心 Prompt 节选：

     “You operate in a ReAct loop. 1. Observe: Review all evidence collected so far. 2. Think: Reason about what is unknown. 3. Act: Produce one or more query instructions. IMPORTANT: You can and SHOULD generate multiple independent queries (up to 3) per iteration when they don’t depend on each other’s results…”

3. Retriever (检索员 / 数据库专家)

   • 职责：懂技术的“跑腿员”。将 Planner 的自然语言转化为 Neo4j 的 Cypher 并并发执行。
   • 核心 Prompt 节选 (针对 Custom Query)：

     “You are a Cypher query generator for Neo4j. Generate a READ-ONLY Cypher query. ONLY use MATCH, OPTIONAL MATCH, WHERE, RETURN. NEVER use CREATE, DELETE… Use parameter binding ($param).”

4. Analyzer (研判分析师)

   • 职责：负责“去伪存真”，将包含大量噪音的数据库回包转化为实打实的 Evidence，并决定是否结束调查。
   • 核心 Prompt 节选：

     “Your job is to analyze the LATEST batch of query results in the context of the overall investigation… Cross-correlate findings across the different queries. Assess how these findings contribute to answering the investigation goal. Output new_evidence matching the criteria.”

5. Reporter (报告生成员)

   • 职责：最终的汇报者。当迭代结束，它汇总白板上所有的 evidence_collected，梳理成人类易读的技术报告。
   • 核心 Prompt 节选：

     “Produce a comprehensive investigation report based on all evidence. Produce a report in Markdown format with: Executive Summary, Investigation Timeline, Key Findings, Attack Path / Relationship Map, Impact Assessment, IOC List…”

2.3 深入理解：一个完整的 Agent 交互实例

假设系统收到指令：“发现 10.10.3.50 有可疑行为，请排查。”

1. Coordinator 启动：识别 investigation_type: "attack_path"，提取实体 [{"type": "IP", "value": "10.10.3.50"}]。
2. 【迭代 Round 1】Planner 推理：
   • Thought: “我只知道一个 IP，我得先看看这台机器触发了什么告警，有没有什么异常网络连接。”
   • Action: 下发两个并行指令：(A) 查询主机关联告警。 (B) 查询主机对外的网络连接。
3. Retriever 执行：并发将 (A) 和 (B) 翻译成 Cypher 查询。发现 (A) 有一个可疑附件执行告警，发现 (B) 有对可疑 IP 185.x.x.x 的访问。
4. Analyzer 研判：
   • Analysis: 发现了初始入口（钓鱼邮件附件）及 C2 远控 IP。
   • 写入 Evidence: “主机 10.10.3.50 点击了名为 XX.pdf.exe 的木马，并远控连接了 185.x.x.x。”
   • 决策: 链路未闭环，进入 Round 2，让 Planner 接着查这个木马。
5. 【迭代 Round 2】Planner 再次推理：
   • Thought: “基于已收集的证据，用户被植入了木马。我要查这个木马进程（文件 Hash）后续执行了什么命令，有没有发生横向移动（Lateral Movement）。”
   • Action: 下发指令：查询该木马进程派生的子进程树。
6. (循环继续，直到 Analyzer 判断链路穷尽或达到阈值)
7. Reporter 总结：拿到完整的证据链，撰写 Markdown 报告，附带完整 IOC 和时间线。

2.4 动态图谱的端到端生成

我在系统前端实现了一个非常酷炫的 Palantir Gotham 风格的动态图谱，在 Retriever 每次动作后，提取所有提及的节点 ID，向 Neo4j 发起一次“子图查询”，这部分内容完全是给人看的，所以查询子图这个步骤非常重要，否则结果看起来都是单个点没法连成图。

# Retriever 核心数据推送逻辑示意
all_known_ids = state["key_entities"] + [e["id"] for e in state["evidence_collected"]]
# 抓取这些实体间的关系边
cypher = "MATCH (a)-[r]->(b) WHERE a.id IN $ids OR b.id IN $ids RETURN a, r, b"
subgraph_data = neo4j_client.run(cypher, ids=all_known_ids)
# 通过 event_bus 或 SSE 实时推送到前端 D3.js 引擎
event_bus.publish("graph_update", subgraph_data)

这使得前端的攻击链路在分析过程中像破案一样“逐渐点亮”。

为什么不用 Dify 这类拖拽式编排平台？

在构建此项目之初，我们也考虑过使用 Dify、Coze 等成熟的低代码 AI 编排平台。然而，针对复杂的攻击溯源分析，这些平台表现出了明显的局限性：

• 状态管理与循环的僵化：攻击溯源是一个循环迭代的探索过程。分析师查到一个 IP，可能会根据结果再去查关联的文件 Hash，如果找不到线索，可能又要退回到上一步查其他机器。拖拽式平台基于 DAG（有向无环图）的逻辑很难表达这种充满条件分支、灵活退回和动态深度迭代的状态机（State Machine）。
• 细粒度的子任务并发控制：在溯源时，我们经常需要“兵分多路”——同时查询一台主机的网络连接、进程树和关联告警。使用代码级别的多智能体框架（如 LangGraph），我们可以轻松实现节点的并行执行和结果聚合，而在 Dify 中处理复杂的异步并发往往力不从心。
• 底层图数据库集成的深度：我们需要在 Agent 执行过程中，不仅获取数据文本，还要实时抽取图谱的节点/边数据推送到前端渲染 D3.js 动态图谱。代码框架允许我们在工具层（Tools）深度定制，抓取原生的图谱结构并利用 SSE（Server-Sent Events）实时流式推送到前端，这也是标准闭源/低代码平台很难做到的环境级控制。

因此，使用 LangGraph 等原生的 Multi-Agent 代码框架，是我们实现复杂推理逻辑的必然选择。

为什么标准的 GraphRAG 无法胜任端到端溯源？

很多人会问：“既然已经有了 GraphRAG（基于图谱的检索增强生成），直接用它不就行了吗？”

实际上，标准的 GraphRAG 模式在处理攻击溯源时存在明显的“能力陷阱”：

1. 检索 vs. 推理 (Retrieval vs. Reasoning)：GraphRAG 的本质是“找到相关的知识块并总结”。而溯源本质上是一个探索性的推理过程。溯源的目标往往是未知的（Unknown Unknowns），你无法在第一步就精准地检索出所有证据。溯源需要根据第一步的结果（由 Analyzer 判定）动态决定第二步的动作（由 Planner 规划），这种“观测-思考-行动”的闭环是标准 RAG 架构所缺失的。
2. 局部视野 vs. 深度追踪：普通的 GraphRAG 往往采用“社区发现”或“局部邻居检索”。但在安全场景下，一个关键的横向移动可能隐藏在万千关系中。标准 RAG 很难在没有明确指引的情况下，自主地沿着某个特定的长链条（如：Process A -> Shell B -> Network C -> Remote Host D）进行数十步的深度追踪，它更容易迷失在节点的广度扩张中。
3. 缺乏“中间状态”的沉淀：溯源过程中会产生大量的中间假设（如：“我怀疑这个 Hash 是木马”）。标准的 GraphRAG 是单次生成的，很难像 Multi-Agent 这样通过维护一个持久化的“调查白板（State）”来不断修正和完善这些假设。

简而言之，GraphRAG 是一个强大的图书馆管理员，而我们需要的是一个能够自主思考、反复深入犯罪现场的私家侦探。

三、 下一步：迈向完全自治的安全副驾驶

这个POC 验证了在一个比较完整的数据链条上应用多智能体+图数据库的效果还不错，但真实攻击分析远比单纯在图上跑遍历复杂得多。接下来几个演进方向，我觉得是最值得先搞的：

1. 优化接入告警数据质量
   现在系统主要在已经建好的图谱上操作，相当于事后分析，能不能在发现可疑 IP 时，直接去捞相关告警？或者原始日志。将原始告警信息转化为图数据这一步非常关键，否则一定是garbage in garbage out，这一步做扎实了，溯源的颗粒度能提升不少。
2. 外部威胁情报得跟上
   溯源很多时候靠的是外部知识库或工具，新增一个对接 VirusTotal、AlienVault 这类平台的 MCP，当分析过程中遇到未知哈希或域名时，自动查一圈情报，打上“恶意/白名单”标签，辅助后续判断。这块实现难度不大，关键是响应速度要跟上分析节奏。
3. 让 Agent 具备“动手”能力
   这是最让人期待的一步，目前系统是只读的分析模式，真正要发挥作用，得能执行操作，结合 OpenClaw的思路，以后可以直接把图数据库和各种工具直接给OpenClaw这类“完全体”，却数据找数据，缺工具OpenClaw直接自己写自己用。当然，这一步步子迈得最大，落地风险也最高，得从简单场景开始试。

结语

从“单体大模型对话”迈向“Multi-Agent 自动推理编排”，我们正在赋予 AI 类似安全研究团队一样的分工与协作能力。图数据库是这支 AI 战队的战场沙盘，而 LangGraph 等代码级编排框架则是他们的通信电台，未来的 SOC 将不再是告警的海洋，而是一支由你指挥、由 AI 特种兵执行的攻防作战部队。