近些年，安全圈每年都有一个极其忙碌的时刻，就是“护网”时刻。这期间，“红”，“蓝”双方你攻我防，各显身手。其中，“蓝”方服务人员，为有效防护，还不得不花费大量精力去分析网络流量，摸清攻击行为，为下一步如何防护做好准备。这少不了要对PCAP包进行深度分析。

实际参与过相关工作的人员大多会有类似的感受：真正消耗时间的，并不只是“看懂一段流量”，而是围绕它展开的一整套分析过程。从链路层一路跟到应用层，不断切换视角、筛选条件、定位关键字段，有时还要反复回溯和验证。这个过程本身并不复杂，但步骤繁多，而且高度依赖个人经验。

更现实的一点是，这些分析工作往往是一次性的。同样类型的流量问题，下次出现时，仍然需要重新走一遍路径。分析过程很少被系统化地保留下来，大部分只存在于操作习惯或者临时记录中。久而久之，就形成了一种常见状态：工具很成熟，数据也不缺，但分析这件事，本身却始终停留在“人去完成”。

也正是在这样的背景下，一个更基础的问题开始变得值得思考： 既然流量分析本身有清晰的步骤和路径，那这些过程，是否可以被整理、串联，甚至交给系统来完成

通过观察，我们会发现平时做的很多分析，其实都有一个相对固定的“走法”。

从原始流量进入，先做基础解析，再逐层深入，在关键位置做筛选、判断和提取，最终得到想要的结果。不同的人操作方式可能不一样，但背后的逻辑往往是相似的。

问题在于，这些“走法”很少被明确表达出来。更多时候，它们存在于个人经验中： 什么时候该看哪一层，什么时候该加过滤，哪些字段值得关注，这些判断都是在操作过程中临时完成的。一旦换一个人，或者隔一段时间再来，往往需要重新熟悉一遍。

从这个角度看，流量分析并不缺能力，缺的是：

对分析过程本身的组织。

基于这个观察，我们在HuggingFists系统中加入了一套基于Wireshark的协议分析算子包。使用者可以通过可视化的拖拽算子来构建流量分析链路。我们没有改变具体的分析能力，而是改变了这些能力的使用方式。

简单来说，就是把原本分散的分析动作，整理成一条可以流动的链路。

在这条链路中：

• 数据从输入开始（pcap 或其他数据源）

• 经过不同层级的解析（从链路层到应用层）

• 在关键节点进行筛选、提取或判断

• 最终输出为结构化结果或后续处理对象

每一个步骤都不复杂，但关键在于：

这些步骤被明确地连接在了一起。

这样一来，分析不再是“在工具中来回穿梭操作”，而变成了一条可以被看见、可以被复用的处理路径。

例如上图，从以太网帧开始，逐步解析到 IP、TCP，再到具体的应用层协议，在某些节点做过滤，在另一些节点提取字段，最终输出结果。整个过程不再依赖人工在不同界面之间切换，而是沿着一条确定的路径向前推进。

当分析被这样组织起来之后，变化逐渐显现出来：

分析不再是一次性工作，分析链路被保留了下来，它可以在后续场景中直接复用。相似的问题，不需要从头再来； 分析经验也不再只是个人能力，而是被沉淀为了一种“可执行的结构”。

在对流量进行初步分析后，我们还可以结合HuggingFists的即有能力继续延伸处理。分析的结果，可以进一步解析，处理，然后写入数据库、文件或其他系统。原本停留在Wireshark等工具界面的结果，变成可以被持续利用的数据。

再往前延伸，我们会发现，这种“链路”的意义就不止于分析本身了。

当这些处理过程被结构化之后，它就不再只是一个“操作流程”，而更像是一组可以被调用的能力。人可以使用它，系统也可以使用它。

这在最近一段时间的实践中变得尤为明显。

随着大模型的应用逐渐增多，很多人开始尝试用它来做自动化分析。但很快会遇到一个问题：模型可以理解问题，却不太擅长稳定地执行复杂流程。尤其是在涉及多步骤处理、数据转换等场景时，单纯依赖生成式能力，很难做到可控。

而如果这些处理步骤本身已经被整理成链路，那么情况会有所不同。

模型可以负责理解任务、做出决策，而具体的执行，则交给这些已经定义好的链路来完成。换句话说：

模型负责“想”，链路负责“做”。

更重要的是，这种执行方式是可控的。

链路中的每一个节点能力是确定的，数据流转是明确的，整个过程是可以观察和验证的。自动化不再是完全不可预测的生成行为，而是在一个相对稳定的边界内完成。

---

HuggingFists提供的这套方案，并没有引入新的分析能力，而是为这些已有能力提供了一种新的组织与交互方式。将流量分析工作进行了链路化表达，可以有效提升流量分析的效率。

如果你在实际工作中也有类似的分析需求，可以尝试这种方式看看效果。我们会在近期发布新版系统，开放相关能力供体验使用。

另外，也感谢李*淼博士提供的思路支持，才有了HuggingFists当前这套方案的落地。