同一个攻击出现两次，安全分析师还要从零查起吗？

一个安全分析师花时间查完可疑的 PowerShell 活动，弄清发生了什么，也把处置过程记录了下来。几天或几周后，另一台机器上出现类似告警。团队明明已经学到过东西，但只看到这条新告警的 AI 助手，未必拿得到上一次调查的结论。

SentinelOps 就是为了解决这个问题而搭起来的。它是一个 AI 辅助的事件响应应用，用 Google Gemini 做分析，用 Hindsight 做持久的组织记忆。目标不是让 AI 自己拍板安全决策，而是把相关的历史发现带进新一次调查，给分析师一个更好的起点。

它按 SOC 分析师的流程来设计

界面包含总览仪表盘、事件中心、AI 调查视图、组织记忆区和学习分析几个部分。前端用 React 和 TypeScript，后端用 Node.js 和 Express，负责串起事件流程以及调用 AI 与记忆服务。Gemini 分析当前告警，Hindsight 存取过往调查的信息，事件记录目前存在本地 JSON 文件里。

把集成放在后端是刻意的选择：API 凭证可以从环境变量加载，不必暴露在浏览器里；应用也有了统一的地方来校验进来的告警、准备调查上下文、处理分析师反馈。

为什么单独加一层记忆

把告警丢给大模型问它怎么办，对眼前这条告警或许够用，但模型并不会自动获得团队此前的调查记录。作者不想用“每次请求都附上全部事件历史”的办法解决，而是要一个独立的记忆层，保存有用的结论，并在新告警出现时返回相关信息。

Hindsight 在流程里承担三个操作：

• Retain：把已完成调查中的有用信息存下来，包括分析师的判定、根因笔记和响应动作。
• Recall：调查新事件时检索相关信息。
• Reflect：当问题超出单次事件范围时，把多条已存记忆的信息汇总起来。

分工因此比较清楚：Hindsight 提供历史上下文，Gemini 借助应用提供的证据和上下文，对当前告警做推理。

先召回，再问 Gemini

整个集成里最关键的是顺序。分析师开始调查时，后端先根据告警构造查询，向 Hindsight 要相关记忆，再把拿到的记忆连同当前告警一起交给 Gemini。

Hindsight 的调用被单独放在一个文件里，没有和事件路由的代码混在一起。项目使用 @vectorize-io/hindsight-client 包，端点、API 密钥和 bank 配置都在服务端提供。分析师提交反馈时，后端整理出一份事件摘要发给 Hindsight，并带上上下文和元数据，让这条记忆和它来自的工作类型关联起来。

有一个实现细节需要说清楚：当 Hindsight 没有返回记忆时，SentinelOps 有本地记忆兜底。这能让演示继续跑下去，但也意味着结果的来源很重要——Hindsight 返回的记忆和本地事件库里的匹配，不该被当成同一种东西呈现，界面和日志要把这个区别标出来。

FIN-SRV-04 与 FIN-SRV-07

主要演示围绕两次相关事件展开。第一条告警在 FIN-SRV-04，涉及与 WMIC 父进程关联的可疑 PowerShell 活动。分析师调查后记录判定、根因和遏制动作，SentinelOps 再通过 Retain 把结果送进 Hindsight。

之后 FIN-SRV-07 上出现类似模式。SentinelOps 不会把它当成与之前完全无关的告警，而是用新告警构造召回查询。如果 Hindsight 把先前那次事件作为相关信息返回，Gemini 就能多一层上下文：团队此前观察到了什么、涉及哪个账号、采取了哪些响应步骤。

这不代表第二条告警会自动得到同样的判定，分析师仍要复核新证据。价值在于，上一次调查能帮下一次更快问对问题，而不是让团队把每个细节重新挖一遍。

分析师始终在环里

Gemini 给出答案，流程并没有结束。分析师要判断这条告警是恶意、良性还是仍未解决，再补上以后可能有用的发现。完整循环是：接收并校验告警、召回相关历史、用 Gemini 分析当前证据、把结果呈现给分析师、收集反馈、保留结论。正是这份反馈，让下一次调查有东西可召回。

应用被刻意限制在只给建议的范围内：它可以提供调查发现和响应建议，但不该自行执行禁用账号、删除文件这类破坏性动作，那些决定需要人工复核和相应的操作管控。

学到的事和待补的课

作者最大的体会是：加一个记忆服务，不等于建成了一个会从过往工作中学习的系统。应用必须决定什么值得保留、什么时候召回、怎么把检索到的信息送进推理环节。信息来源也要保持清晰——当前告警、Hindsight 返回的记忆、本地兜底匹配、Gemini 的结论，是四样不同的东西，分析师应该能分辨每条信息从哪来。

离生产级 SOC 还有距离：事件记录存在本地 JSON 文件里，而不是为并发使用设计的数据库；认证、授权、审计日志、错误处理和更广泛的集成测试都需要补强；兜底路径要保持可见，免得服务故障被误认为记忆检索成功。下一步是用更多类型的告警测试流程，提升记忆来源的可见性，让人能查清究竟是哪些历史细节影响了某条建议，并用更广的事件集评估系统，而不只依赖演示场景。

对作者来说，SentinelOps 的意义很简单：一次调查应该留下有用的知识。类似告警再次出现时，下一位分析师不必从零开始。Hindsight 让这段历史可以被应用取用，而最终决定仍然由分析师负责。