工作原理

面临的问题

SOC 淹没在告警之中。单次扫描就能产生数以千计的告警，被升级的告警中大多数最终都是良性的，而分析师则在清理一个几乎全是噪声的队列中耗尽心力。困难之处不在于检测，而在于快速且安全地判断出所有触发的告警中究竟哪些才真正重要。

SOC 分诊的三代演进

分诊工具历经三代，每一代都修复了上一代的问题，同时又留下了自己的盲点。

第一代是规则：SIEM 中的特征与关联规则，以及 SOAR 中的确定性自动化。它快速、可审计且可预测，正因如此它至今仍运行在一切之下。但它也很粗糙。规则会对任何与之匹配的东西触发，因此噪声很大，人工仍然几乎需要阅读所有内容。它就像一个烟雾报警器：可靠，但无法分辨真正的火灾和烤糊的面包。

第二代加入了机器学习：有监督分类器、异常检测，以及用户行为分析——它们学习正常的样子，并对偏离正常的情况打分。这对队列进行了排序并把异常项浮现出来，但它需要标注数据，会随着环境变化而漂移，并且给你的是一个分数而非一个理由。它就像一个垃圾邮件过滤器：它把邮件堆分好了类，但给你的是一个数字，而不是一个解释。

第三代是语言模型，它能在上下文中对告警进行推理，并用通俗语言解释自己。第一波 AI SOC 工具以最显而易见的方式使用它们：把一个模型对准每一条告警，输入提示词，输出裁决。问题在于，一个孤立地阅读单条告警的模型没有分析师此前所做决定的记忆，没有对组织自身状态的全貌（因此它无法把一次经过批准的变更与一次看起来一模一样的攻击区分开），无法保证它不会自信地把一个真实指标误判关闭，也感知不到周围的其他告警。对每一条原始告警都运行一个前沿模型也很昂贵，而昂贵会促使团队在最需要判断力的那些案例上转而使用更弱的模型。它就像一位入职第一天的敏锐分析师：他能对任何单条告警进行出色的推理，但对昨天的事情毫无记忆，也没人把变更日历或资产清单交到他手上。

每一代都确实在某方面做得很好，没有哪一代是错的。问题在于大多数产品只挑选其中一代，并单靠它支撑。

SocTalk 的不同之处

SocTalk 是智能体的一代。第一波把一个模型对准一条告警，而 SocTalk 则围绕模型运行一个智能体循环：模型主导一次确定性的调查，对整个已关联的案例进行推理，并返回一个驱动受治理行动的裁决，同时由人工对任何危险操作进行把关。所有这一切都运行在确定性护栏之内。它用代码保留了规则时代的各项保证，并刻意跳过那个不透明的中间层。机器学习本想完成的噪声压缩，在这里改由确定性方式完成——通过合并、关联和基于规则的关闭——因此决策路径上没有任何一环是经过训练的黑盒。模型只被花费在那些模棱两可的案例上。然后在此之上加入了前几代都不具备的两样东西：流水线会记住分析师所做的决定，并且由人工对任何触及生产系统的操作进行把关。

换句话说，模型是一个组件，而非整个系统。噪声在任何模型运行之前就被压缩掉。模型被赋予真实的组织上下文。那些安全攸关的决策处于一道安全底线之后——这是一小组用代码写就的硬性否决，规则和模型都无法将其关闭，就像一个断路器无论线路那头在要求什么都会切断电源。分析师的决定会被记住。而裁决驱动受治理的行动，即系统的 SOAR 层，由人工审批任何危险操作。其结果是：模型对模棱两可的中间地带进行推理，而那些必须被保证的部分始终得到保证。

两个平面和一个沉淀窗口

流水线跨越两个平面（或者说阶段）运行，弄清楚哪个是哪个，就能解释大部分的设计。

接入平面位于服务端，完全确定性。当一个适配器（租户侧的采集器，负责转发 Wazuh 及类似告警）投递一批事件时，这些事件会被去重、合并、关联、去冲突，并且在许多情况下无需任何模型运行就得到解决。没有模型触及这个平面。

图平面是智能体循环，每个租户一个，作为独立进程运行。这里是模型进行推理的地方，并且它只在两个角色上咨询模型：路由和最终裁决。许多案例所需甚至更少，无需任何模型调用就基于确定性策略关闭。该循环本身不保留任何数据库：案例在运行开始时被交给它，其结果在运行结束时被交回，而它的富化通过对 SIEM 和威胁情报服务的工具调用来完成。

两者之间坐落着一个可选的沉淀窗口。当租户配置了它时，一次被提升的运行会被短暂延迟押后，好让一阵关联告警先累积起来，从而让模型一次性审视整个事件，而不是随着每个碎片抵达而逐一审视。高严重性的告警会绕过这段等待。

对裁决采取行动是在运行完成后，回到服务端确定性地发生的。这使模型置身于那个触及外部系统的循环之外。

进入时：确定性漏斗

许多告警在任何模型被咨询之前就已解决，这有助于保持流水线的经济性和速度，而且这一切都是确定性代码。

**合并与去重压平风暴。**去重会丢弃携带了已见 ID 的重放事件。合并随后把五分钟窗口内来自同一资产上同一规则的重复告警归组为单个案例，于是同一检测的一阵爆发就变成一个案例，而不是成千上万个。模型和分析师看到的是每个事件一个案例，而不是原始的信息洪流。（IR 内核中的关联与合并）

**关联使一个事件对应一个案例。**在启用实体关联的情况下，一条与某个进行中的调查共享强实体（一个可靠的标识符，如主机或文件哈希）的新告警会作为证据附加到该调查上，而不是启动一次全新的、无上下文的运行。若某个来源开始主导关联，例如一个触及一切的扫描器 IP，它会被降级，以免它把无关的告警拉进同一个案例。关联先于关闭路径运行，因此一条看似良性但实属某个活跃事件的告警不会被悄悄压制。

**交战去冲突把经批准的测试挡在队列之外。**当启用它时，一个已声明的渗透测试或红队窗口会按来源、主机、技术和时间进行匹配。窗口内的活动会被标记并审计，但绝不会被自动关闭；而测试人员越出范围的活动会被强制转交人工查看，而非关闭。有关交战如何声明与审查，参见用户与角色。

**确定性关闭处理显而易见的案例。**低严重性、高置信度的误报按规则关闭，而一个反复出现的良性形态可以参照先前的一个决定来关闭，两者都无需模型。误报关闭区间和运营关闭路径刻意排除任何映射到 ATT&CK 技术（一个标准的攻击技术 ID）的告警，因此一条映射了技术的告警不会被当作例行噪声关闭。

**接入安全底线守护这一切。**任何确定性关闭都不得越过一个已知指标（一个可疑的可观测项，如恶意 IP 或文件哈希）、一个活跃事件或一个终止开关（一个中止自动化行动的操作员设置）而触发；此外还有一个数量上限充当断路器，使一条失控的规则降级为"由人工查看"，而不是大规模压制。

任何在漏斗中幸存下来的告警都会被提升：它成为一个调查，被排定进行一次分诊运行。

分诊运行：两个模型角色，以及大量的确定性

这次运行是一个智能体循环，但模型在其中的足迹既小又刻意。

循环以一道确定性关卡开场。如果告警匹配某个分诊策略，且其处置（要采用的结果：关闭、升级或索取更多信息）是有保证且无异议的，它就在那里被了结，模型根本不会被咨询。

对于其余的一切，一个主管决定接下来做什么。这是两个模型角色中的第一个，它的全部工作就是路由：调查、富化、补充上下文、决定或关闭。它本身不做任何领域工作，并且在作出决定之前可能会经过好几个路由回合。

它所路由到的工作是确定性的。富化步骤从 SIEM 拉取主机和进程上下文，通过 Cortex 分析器检查可观测项的声誉，并在 MISP 中查找威胁情报上下文。这些是工具调用和启发式方法，不是模型调用。关于 AI 分诊的一个常见误解是：以为模型在做富化。但在这里它不做：富化是确定性的工具编排，模型只读取结果。

在此过程中，运行会收集它的授权上下文：那些说明此活动是否经过批准的组织状态事实（变更工单、已批准的维护、账户和资产上下文）。授权正是让流水线得以把一次经授权的变更与一次产生逐字节相同告警的攻击区分开来的东西——这一区分是任何声誉查询都无法做到的。

当主管掌握了足够信息，它就交棒给裁决，即第二个模型角色。这是唯一一处由推理模型权衡运行所收集的一切并提出一个处置的地方：关闭、升级或索取更多信息。

随后确定性再次接管。裁决是一个提议，而非一次提交。一道分诊策略护栏只能抬高模型的决定，绝不能降低它：一个越过恶意信号或一条相矛盾的授权记录的关闭提议会被转为升级，而护栏的词汇表使得压制根本无法被表达出来。如果一个关闭提议触及一项敏感资产，它会被押后等待人工签字。模型提议；确定性代码处置。

各项保证：三处的安全底线

"授权（以及模型）绝不能越过一个已知的恶意信号、一个未经验证的指标或一个活跃的相关案例而关闭"这条规则，并不是靠提示词的措辞来托付的。它在代码中强制执行，位于关闭路径上三个相互独立的点：

• 在接入时，任何确定性关闭之前，以一个已知指标、一个活跃事件、一个终止开关和数量上限为键。
• 在运行期间，当模型提出关闭时，以一个已知指标、一个未经验证的指标和一条相矛盾的授权记录为键。这是唯一一处会咨询授权的底线。
• 在服务端，当关闭被提交时，以终止开关、另一个共享相同实体的活跃案例以及数量上限为键。

每条关闭路径都在它自己的点上设了底线：一次确定性的接入关闭要过第一道，而一个模型提出的关闭要过第二道、然后过第三道。授权可以在中间那道底线上降低嫌疑，但它绝不能说服其中任何一道放过一个已知指标或一个活跃的相关案例。有关佐证证据如何在不越过恶意信号的前提下降低嫌疑，参见授权。

对裁决采取行动

一旦运行完成，服务端就提交处置并对其采取行动，确定性地、在一个事务中完成。

一次升级会落入人工审查队列，并附上真实的证据。当运行是专门因为缺少授权而停滞时，该审查会携带一个类型化的授权问题，而分析师的回答会被保存为一个可复用的事实，因此只要那份授权仍然成立，同样的活动就不会被再次询问。这种"只问一次"的记忆在授权页面中有描述。

裁决还会驱动响应 Playbook。这是系统的 SOAR 层，正是一位 SOAR 分析师会认得的那种确定性、受治理的自动化，只不过它由一个经过推理的裁决驱动，而非一条脆弱的规则，也正是"受治理的行动"这一立场显现之处。安全的动作，比如写一条备注或通知一个 webhook，会自行运行。触及生产系统的动作，比如隔离一个端点或禁用一个账户，绝不会自行运行：它们会被作为一个提议提出，由分析师先行审批。一次关闭最多只能加注释；一个派发终止开关会立即停止活跃的响应动作（影子审计仍可记录本会触发什么）；并且整个派发发生在服务端，绝不来自模型的循环。

最后一处确定性的点缀处理时序问题。如果在运行进行中有新的关联证据到达且案例仍然打开，就会针对现在这幅已完整的图景启动一次后续运行，从而使一条迟到的告警不会被搁置在它本该归属的案例之外。

是什么让它与众不同

综合起来看，有几项特性使它区别于把一个模型对准每一条告警：

• **许多告警从不抵达模型。**去重、合并、去冲突和确定性关闭在接入时就解决了其中许多，因此模型只被花费在模棱两可的案例上。
• 一次运行只在两个角色上咨询模型，即路由和最终裁决，而许多案例无需任何模型调用就确定性地关闭。富化是确定性的工具编排，而不是逐条告警的模型分类。
• **一个事件就是一个案例。**合并与关联给模型的是整幅已关联的图景，而不是一条被剥离了上下文的孤零零的告警。
• **模型提议，代码处置。**一道护栏和一道三处的安全底线，使模型在结构上不可能越过一个已知指标、一条相矛盾的授权记录或一个活跃的相关案例而关闭。
• **流水线会对授权进行推理。**它能把一次经批准的变更与一次看起来一模一样的攻击区分开来——这是声誉和特征单靠自己无法作出的判断。
• **它会记住。**分析师的一次授权决定会成为可复用的记忆，因此只要那份授权仍然成立，队列就不会再问一个已经回答过的问题。

接下来去哪里

每个阶段都有自己的页面和代码：

• 授权 —— 组织状态推理和"只问一次"的记忆。
• 分诊策略 —— 运行上的确定性护栏。
• 响应 Playbook —— 把一个裁决转化为受治理的行动。
• 人工审查 —— 审查队列和分析师的决策路径。
• AI 流水线 —— 更详细的智能体图。
• 架构 —— 部署与数据模型。

流水线代码位于 src/soctalk/core/ir/（接入平面）、src/soctalk/graph/ 和 src/soctalk/supervisor/（图平面），以及 src/soctalk/response/（响应）之下。