Flowsint：从入门到架构与扩展的 OSINT 图调查平台指南

目标读者：安全研究人员、OSINT 从业者、开发者、需要理解图调查平台架构的技术读者
前置知识：Docker 基础、Web 应用常识、Pydantic / FastAPI 基础概念更佳
文档范围：本文严格基于公开可验证资料撰写，主要参考 Flowsint 官方 GitHub README 与 flowsint.io 文档；对动态数据不做武断固化

🎯 学习目标

完成本文后，你将能够：

• ✅ 说清楚 Flowsint 到底解决什么问题，以及它不解决什么问题
• ✅ 从用户视角理解 Investigation、Entity、Enricher、Flow 的完整工作链路
• ✅ 从开发视角理解 flowsint-app、flowsint-api、flowsint-core、flowsint-enrichers、flowsint-types 的职责划分
• ✅ 理解 Flowsint 的类型系统、Tool 抽象层、Enricher 两阶段执行模型
• ✅ 按官方推荐方式完成部署、创建第一条调查、运行第一个 enricher
• ✅ 基于官方开发文档扩展新类型、新工具、新 enricher
• ✅ 了解项目的伦理边界、适用场景与常见误区

一、先给结论：Flowsint 是什么，适合谁

Flowsint 是一个面向 图调查（graph-based investigation） 的开源平台。它把域名、IP、组织、邮箱、手机号、网站、加密钱包等对象建模为图里的实体，再通过一系列 Enricher 把“一个线索”扩展成“更多可追踪的关系”。

如果你只想要一个“单命令跑一下结果就结束”的小工具，Flowsint 可能显得偏重；但如果你关心的是：

• 把零散线索持续沉淀成一张可反复探索的关系图
• 在不同数据源、不同工具之间保持统一的数据模型
• 让调查流程可复用、可链式编排、可扩展
• 在本地保存调查数据，而不是把关键数据直接丢给第三方 SaaS

那么 Flowsint 的设计思路就非常值得研究。

官方 README 对它的定义是：

Flowsint is an open-source OSINT graph exploration tool designed for ethical investigation, transparency, and verification.

这句话里最重要的不是 “OSINT”，而是后面的三个关键词：

• ethical investigation：强调合法、合规、可辩护的调查边界
• transparency：强调调查过程应尽量可解释，而不是黑箱输出
• verification：强调结果应该能被复核，而不是“模型说了算”

二、Flowsint 解决的核心问题

很多 OSINT 工具的问题，不在于“查不到”，而在于“查到了以后很难组织”。常见痛点包括：

2.1 它擅长什么

根据官方文档，Flowsint 适合以下方向：

• 网络安全研究与威胁情报
• 记者或调查人员的公开信息核验
• 执法或反欺诈团队的合法取证支持
• 企业内部数字风险分析

2.2 它不是什么

理解这点很重要。Flowsint 不是：

• 不是“一键给你全部真相”的 AI 侦探
• 不是替代判断的自动决策系统
• 不是默认离线的纯本地分析器
• 不是可以绕开法律边界的“万能侦查平台”

原因很简单：很多 enrichers 依赖外部 API、Docker 工具或公开服务；而且项目明确禁止未经授权的入侵、监视、骚扰、doxxing、政治操纵和违反隐私法规的使用方式。

三、从 0 到 1：15 分钟看懂用户工作流

如果你第一次接触 Flowsint，不必先研究源码。先把“用户如何使用它”搞明白。

3.1 官方前置要求

根据 quickstart 文档，安装前需要准备：

• Docker 与 Docker Compose
• Make
• Git

3.2 官方安装方式

生产方式的最短路径是：

git clone https://github.com/reconurge/flowsint.git
cd flowsint
make prod

开发方式则是：

git clone https://github.com/reconurge/flowsint.git
cd flowsint
make dev

官方文档说明，应用应自动打开到 http://localhost:5173；README 则给出了注册入口 http://localhost:5173/register，并明确说明 默认没有现成账号和凭证，需要自己注册。

3.3 第一次调查怎么做

按照 quickstart 的路径，最小闭环如下：

1. 登录或注册
2. 创建新的 investigation
3. 添加第一个实体，例如一个域名
4. 右键打开上下文菜单
5. 对该实体运行某个 enricher
6. 观察图里新生成的实体和关系

官方给出的第一个典型例子是：先添加 example.com，再运行 domain_to_subdomains，让子域名自动出现在图里。

3.4 这个交互为什么好用

因为它把调查动作收敛成了统一模式：

输入一个实体
→ 选择一个 pivot / enricher
→ 拉取外部信息
→ 转成结构化类型
→ 写入图
→ 继续从新节点扩展

对调查者而言，这比单纯打开很多网站分别查询更可持续；对开发者而言，这比“每个脚本各写一套逻辑”更容易维护。

四、理解 Flowsint，先理解 6 个核心概念

4.1 Entity：调查对象

实体是图中的节点来源，例如：

• Domain
• Ip
• ASN
• CIDR
• Website
• Email
• Phone
• Organization
• Individual
• CryptoWallet

这些并不是随便写的字符串，而是由 flowsint-types 中的 Pydantic 模型定义。

4.2 Type：统一数据模型

Flowsint 的类型系统建立在 Pydantic 之上。官方开发文档明确指出：

• 每个类型都继承自 FlowsintType
• 每个类型都必须用 @flowsint_type 装饰器注册
• 每个类型必须定义一个 primary field
• 每个类型都需要生成一个面向 UI 的 nodeLabel

这四件事直接决定了数据是否能被 API、图数据库和前端一致理解。

官方 managing-types 文档还提到，项目当前内置了 39 个 built-in types，覆盖网络实体、身份信息、安全数据、金融数据和加密资产等类别。这也解释了为什么 Flowsint 能比较自然地承接跨领域线索。

4.3 Pivot：从 A 推到 B 的方法

官方 “Enrichers” 文档把 pivot 定义为：从一个输入元素 A 推导出一个或多个输出元素 B 的方法。

例如：

domain
→ DNS resolution
→ IP

或者：

website
→ crawler
→ emails / phones / links

你可以把 pivot 理解为“调查中的一个可复用动作”。

4.4 Enricher：高层业务逻辑

Enricher 不是简单的 API 调用器，而是一个 知道输入类型、输出类型、图关系、参数和日志 的高层工作流单元。

它做的事情通常包括：

1. 接收某个类型的输入
2. 调用工具或 API 拉取数据
3. 把原始结果转换为 Flowsint 类型
4. 创建图节点和关系
5. 返回结构化结果

4.5 Tool：底层能力封装

Tool 是更底层的抽象。官方文档明确区分：

• Tool：负责调用 Docker、外部 API、Python 库或系统能力，返回原始结果
• Enricher：负责把 Tool 结果编排成调查工作流，并创建图

换句话说，Tool 关心“怎么拿数据”，Enricher 关心“拿到数据后怎么落成调查结果”。

4.6 Flow：多个 enrichers 的链式编排

Flows 文档给出的定义非常直接：Flow 就是多个 enrichers 的链式连接，前一个输出作为后一个输入。

这意味着 Flowsint 不只是做“一跳 enrich”，还支持把调查过程沉淀成可复用的 pipeline。

五、整体架构：模块划分与运行路径

README 给出了项目的核心模块：

• flowsint-core：核心工具、orchestrator、vault、Celery tasks、基类
• flowsint-types：Pydantic 类型定义
• flowsint-enrichers：enricher 模块、扫描逻辑、tools
• flowsint-api：FastAPI 服务、API 路由、schema
• flowsint-app：前端应用

官方 README 中的依赖链可概括为：

flowsint-app
    ↓
flowsint-api
    ↓
flowsint-core
    ↓
flowsint-enrichers
    ↓
flowsint-types

5.1 从用户点击到图更新，链路怎么走

更接近运行时的理解方式，可以把它看成下面这条链：

前端添加实体
→ API 接收请求
→ Core 调度 enricher
→ Enricher 调用 Tool / API / Docker
→ 结果转为 Pydantic 类型
→ 创建 Neo4j 节点和关系
→ 前端刷新图视图

README 同时说明，核心模块还负责 PostgreSQL、Neo4j、认证、日志和配置管理，因此它本质上是系统的“编排层”。

5.2 为什么这种架构合理

这种拆分有三个明显好处：

• 类型和业务逻辑分离：数据模型不会和具体调查逻辑纠缠在一起
• 工具和业务逻辑分离：替换数据源时，往往只需要换 Tool，不必重写整个系统
• 前后端和调查逻辑分离：前端 UI 不必了解每个数据源的细节

5.3 你最应该重点理解哪两层

如果你是使用者，重点看：

• flowsint-enrichers
• flowsint-types

如果你是开发者，重点看：

• flowsint-core
• flowsint-enrichers
• flowsint-types

因为真正让 Flowsint 与普通 OSINT 工具拉开差距的，不是界面，而是 类型系统 + 图编排 + 可扩展的 enrichers。

六、类型系统原理：为什么它不是“随便存个 JSON”

官方 managing-types 文档透露了很多关键设计。

6.1 每个类型都继承 FlowsintType

类型系统的基础不是裸 BaseModel，而是 Flowsint 自己封装的 FlowsintType。这意味着它除了拥有 Pydantic 的校验、序列化能力之外，还内建了面向图和 UI 的约束。

6.2 primary field 决定节点唯一性

每个类型必须且只能有一个 primary field，例如：

• Domain.domain
• Email.email
• Ip.address

这个字段会被用于图数据库里的唯一性判断。文档明确说明，图服务在创建 Neo4j 节点时会依赖它做关键键值提取。

6.3 nodeLabel 决定图上显示什么

用户在图上看到的不是一大坨原始 JSON，而是 nodeLabel。官方建议每个类型通过 @model_validator(mode='after') 计算出对人类友好的标签。

这看起来是 UI 细节，实际上影响很大：

• 标签太短，用户不知道节点是什么
• 标签太长，图会难读
• 标签没有处理 None，展示会很难看

6.4 注册机制让类型可被全系统发现

官方文档明确要求：

• 用 @flowsint_type 注册类型
• 在 flowsint_types/__init__.py 里导出
• 必要时把类型加入类型分类定义

这说明 Flowsint 的类型不是“写完类就结束”，而是要进入一整套发现与暴露机制。

6.5 一个最小类型长什么样

下面的骨架遵循官方文档的写法：

from pydantic import Field, model_validator
from typing import Self
from .flowsint_base import FlowsintType
from .registry import flowsint_type

@flowsint_type
class Vehicle(FlowsintType):
    license_plate: str = Field(
        ...,
        description="Vehicle license plate number",
        title="License Plate",
        json_schema_extra={"primary": True},
    )

    @model_validator(mode="after")
    def compute_label(self) -> Self:
        self.nodeLabel = self.license_plate
        return self

这段代码体现了 3 个硬要求：

• 继承 FlowsintType
• 声明 primary field
• 实现 compute_label

七、Enricher 原理：Flowsint 真正的核心

如果说类型系统定义了“数据长什么样”，那 enricher 定义的就是“调查怎么推进”。

7.1 Enricher 是两阶段执行模型

官方 managing-enrichers 文档给出的关键结论是：每个 enricher 都遵循 scan + postprocess 两阶段模型。

第一阶段：scan

这一阶段负责：

• 调用工具
• 调用外部 API
• 处理返回结果
• 生成输出类型对象

它的重点是“拿数据”和“整理数据”。

第二阶段：postprocess

这一阶段负责：

• 创建图节点
• 创建图关系
• 写入调查可视化所需的结构

它的重点是“把结果落成图”。

这种分层很聪明。因为很多逻辑其实不应该掺在一起：

• 采集逻辑失败，不代表图逻辑有问题
• 图关系设计调整，不代表采集逻辑需要重写

7.2 一个最小 enricher 长什么样

官方文档里的最小结构如下：

from typing import List
from flowsint_core.core.enricher_base import Enricher
from flowsint_enrichers.registry import flowsint_enricher
from flowsint_types import Domain, Ip

@flowsint_enricher
class DomainToIpEnricher(Enricher):
    InputType = Domain
    OutputType = Ip

    @classmethod
    def name(cls) -> str:
        return "domain_to_ip"

    @classmethod
    def category(cls) -> str:
        return "Domain"

    @classmethod
    def key(cls) -> str:
        return "domain"

    async def scan(self, data: List[InputType]) -> List[OutputType]:
        pass

    def postprocess(
        self,
        results: List[OutputType],
        input_data: List[InputType],
    ) -> List[OutputType]:
        pass

InputType = DomainToIpEnricher.InputType
OutputType = DomainToIpEnricher.OutputType

这段代码可以提炼出 Flowsint 的 enricher 设计哲学：

• 输入输出必须是明确类型，而不是随意的字典
• metadata 不是可选项，而是框架自动发现的一部分
• graph 关系不是副作用，而是 enricher 的正式职责

7.3 参数系统和凭证系统

官方文档还提到 enricher 可以通过 get_params_schema() 暴露参数，并使用 vaultSecret 类型对接凭证存储。

这意味着 Flowsint 不只是“写死逻辑”，而是支持：

• UI 可配置参数
• 加密保存 API key
• passive / active 等不同运行模式

这对真实调查场景非常重要，因为不同目标、不同数据源、不同成本策略，通常都需要不同参数。

八、Tool 原理：为什么还要再抽一层

很多人第一次看 Flowsint，会问一句：“既然有 enricher，为什么还要 Tool？”

答案是：因为工具调用和调查编排不是同一类问题。

8.1 Tool 负责什么

官方 managing-tools 文档指出，Tool 是对外部系统的抽象层，负责：

• 调 Docker 容器
• 调 API
• 调 Python 库
• 返回原始结果

Tool 不关心：

• Pydantic 类型
• Neo4j 图结构
• 业务编排

8.2 DockerTool 的意义

官方文档明确提供了 DockerTool 抽象。它帮开发者统一处理：

• 镜像安装
• 容器执行
• volume 挂载
• environment 注入
• 超时与清理

这意味着像 subfinder、asnmap、dnsx 这一类工具，可以被更稳定地纳入平台，而不必在每个 enricher 里重复写容器细节。

8.3 Tool 和 Enricher 的职责边界

可以用一句话记住：

• Tool：拿原始结果
• Enricher：把原始结果变成调查图

这也是 Flowsint 架构可扩展的关键。

九、内置能力概览：官方 catalog 告诉了我们什么

Flowsint 官方 available-enrichers 文档列出了当前可见的一批 enrichers。这里不生搬硬套“总数”，而是提炼出最值得理解的代表能力。

9.1 域名与网络方向

9.2 身份与组织方向

9.3 网站与内容方向

9.4 社交与泄露方向

9.5 加密资产方向

9.6 从这些条目能看出什么

最值得注意的不是“支持多少项”，而是它背后的统一模式：

• 输入输出都尽量类型化
• 多种数据源都能汇入同一张图
• 同一调查对象可以从不同方向持续 pivot
• 本地 UI、图存储、开发扩展共享同一套模型

十、Flows：从“一个动作”升级到“一个流程”

很多文章讲 Flowsint 时，只讲 enricher，不讲 Flow。其实 Flow 是平台走向“可复用调查流水线”的关键。

10.1 Flow 是什么

官方文档定义很明确：Flow 是多个 enrichers 的链式连接，一个 enricher 的输出作为下一个 enricher 的输入。

例如，你完全可以把这样一条链保存成 Flow：

Domain
→ domain_to_subdomains
→ domain_to_ip
→ ip_to_asn

10.2 Flow 的价值

它解决的是两个现实问题：

• 可重复：换一个目标实体，沿用同一套调查链路
• 可规模化：把个人经验变成团队可共享的标准流程

10.3 官方文档透露的实现细节

Flows 文档提到，每次执行 Flow 都会生成日志文件，保存到 flowsint_core/enricher_logs。日志结构里包含：

• sketch_id
• scan_id
• step 执行顺序
• 每步输入输出
• execution_time_ms
• cache_hit
• 执行汇总信息

这说明 Flow 不只是 UI 上“连一连”，而是一个有明确执行记录和可追踪结果的编排系统。

十一、开发扩展：如何正确地给 Flowsint 加能力

这是本文和很多“项目介绍文”最大的不同：我们不只停在“会用”，还要说清楚“怎么按官方方式扩展”。

11.1 扩展新类型

官方推荐路径可以概括为：

1. 在 flowsint-types/src/flowsint_types/ 下新增类型文件
2. 继承 FlowsintType
3. 用 @flowsint_type 装饰
4. 指定唯一 primary field
5. 实现 compute_label
6. 在 __init__.py 和 __all__ 中导出
7. 把类型加入 API 的分类定义
8. 重新安装或刷新包

其中最容易漏掉的是第 6 步和第 7 步。很多“类型写了但前端不出现”的问题，本质都是注册链没有走完。

11.2 扩展新 Tool

官方建议把 Tool 放在 flowsint-enrichers/src/tools/ 的合适类别下。Tool 至少要定义：

• name()
• category()
• description()
• version()
• launch()

如果是容器型能力，优先继承 DockerTool；如果是纯 API 能力，则可以直接继承基础 Tool。

11.3 扩展新 Enricher

官方文档给出的标准做法是：

1. 在 flowsint-enrichers/src/flowsint_enrichers/<input-type>/ 下新增文件
2. 继承 Enricher
3. 用 @flowsint_enricher 装饰
4. 定义 InputType 和 OutputType
5. 实现 name()、category()、key()
6. 在 scan() 中完成采集与转换
7. 在 postprocess() 中创建图节点与关系
8. 在文件末尾导出 InputType / OutputType

11.4 一个最小扩展路线图

如果你想做一个“真正像 Flowsint 风格”的扩展，建议按下面顺序走：

1. 先决定 实体模型
2. 再决定 底层数据源
3. 把数据源封成 Tool
4. 把调查逻辑写成 Enricher
5. 再考虑 UI 参数、凭证、分类与测试

不要一开始就把所有逻辑堆进一个 enricher 里，否则很快就会失去可维护性。

11.5 测试怎么做

README 写得很直接：每个模块都有各自的测试套件，而且是不完整的。

官方给出的运行方式是：

cd flowsint-core
poetry run pytest

cd ../flowsint-types
poetry run pytest

cd ../flowsint-enrichers
poetry run pytest

cd ../flowsint-api
poetry run pytest

从这个信息你可以得到两个判断：

• 这个项目是鼓励模块级测试的
• 你在贡献新功能时，最好不要只改代码不补测试

十二、使用场景：怎样用 Flowsint 才算“用对了”

为了避免把它想得过重或过轻，可以把 Flowsint 的适用场景分成四类。

12.1 场景一：从单个域名扩展资产图

典型目标是：

• 从一个主域名出发
• 查子域名
• 查 IP
• 查 ASN
• 查网站链接与追踪脚本

这类场景最能发挥 Flowsint 的图式优势，因为每一步扩展都能沉淀为节点和关系，而不是一次性输出。

12.2 场景二：从组织或个人线索追到公开足迹

这类场景更看重：

• 组织 ↔ 域名
• 组织 ↔ ASN
• 个人 ↔ 域名
• 用户名 ↔ 社交账号

它的价值不在“某个结果特别神奇”，而在“不同来源结果被统一挂到一张图里”。

12.3 场景三：网站内容与联系信息提取

如果你已经知道一个站点地址，可以继续用：

• website_to_crawler
• website_to_links
• website_to_text
• website_to_webtrackers

这会把网页层面的信息，转成更适合调查的结构化节点。

12.4 场景四：把经验固化成 Flow

这往往是团队真正开始受益的阶段：

• 个人经验不再依赖口口相传
• 调查步骤可以标准化
• 相同类型目标可以批量复用流程

十三、常见误区与排查思路

13.1 “平台装起来了，但 enrichment 结果很少”

优先排查这几类问题：

• 目标实体本身公开信息少
• 某些 enrichers 依赖额外 API key
• 某些 enrichers 依赖 Docker 工具镜像
• 被查询服务存在限速或数据覆盖差异

也就是说，Flowsint 提供的是一个框架化调查平台，不保证每个外部数据源都永远稳定可用。

13.2 “我写了类型，但 API 或前端里看不到”

优先检查：

• 是否用了 @flowsint_type
• 是否加入 __init__.py 和 __all__
• 是否加入类型分类定义
• 是否重新安装或重启相关服务

13.3 “我写了 enricher，但图里没有关系”

很可能不是 scan() 的问题，而是 postprocess() 没有正确：

• 创建节点
• 创建关系
• 使用正确的对象和关系类型

这也是官方把 scan 和 postprocess 分开的原因：排错时非常清楚。

13.4 “Tool 和 Enricher 我总是分不清”

记住这句就够了：

• Tool 是 能力封装
• Enricher 是 调查流程

13.5 “本地存储就一定完全离线吗”

不一定。README 确实强调“所有内容都存储在你的机器上”，这是数据归属层面的好处；但 enrichers 仍然可能访问外部 API、公开服务或 Docker 工具，因此它不是一个默认完全离线的系统。

十四、伦理、合规与边界控制

Flowsint 在伦理说明上写得非常明确，这一点值得肯定。

14.1 项目明确鼓励的方向

• 合法的安全研究
• 公开信息调查与核验
• 反欺诈与数字风险分析
• 符合授权边界的内部情报工作

14.2 项目明确禁止的方向

README 明确列出不得用于：

• 未经授权的入侵、监视或数据收集
• 骚扰、doxxing 或针对个人的伤害性行为
• 政治操纵、虚假信息传播
• 违反隐私法规的活动

14.3 为什么这部分不是“免责声明装饰品”

因为 Flowsint 天生适合“把碎片信息连成关系图”，而这种能力既可以用于合法调查，也可能被滥用。项目把伦理边界写在最前面，本质上是在提醒你：

• 图能力越强，越要克制使用范围
• 数据越容易串联，越要重视最小必要原则
• 工具越方便，越不能替代授权判断

十五、从入门到精通的建议学习路径

如果你真想把 Flowsint 学透，建议按下面的顺序走。

15.1 第一阶段：会用

目标：

• 完成安装
• 创建 investigation
• 添加实体
• 运行 2-3 个基础 enrichers

建议练习：

• 从一个域名出发跑 domain_to_subdomains
• 对结果继续跑 domain_to_ip
• 再把 IP 跑到 ip_to_asn

15.2 第二阶段：会分析

目标：

• 理解实体如何在图里逐步展开
• 区分“原始线索”和“派生线索”
• 理解不同 pivot 的可信度和覆盖范围

建议练习：

• 对同一个目标比较 DNS、WHOIS、网站爬取三条路径的补充关系
• 观察哪类节点最容易成为调查枢纽

15.3 第三阶段：会编排

目标：

• 把多步 enrichers 组织成 Flow
• 保存和复用调查路径
• 观察执行日志与结果摘要

建议练习：

• 为“域名资产摸底”建立一个标准 Flow
• 为“组织外部公开面梳理”建立一个标准 Flow

15.4 第四阶段：会扩展

目标：

• 新增类型
• 封装 Tool
• 编写 enricher
• 补齐测试与注册链路

建议练习：

• 先模仿官方 domain_to_ip 之类的简单 enricher
• 再尝试封装一个你熟悉的数据源

15.5 学完自测

如果你想确认自己是不是已经真正理解了 Flowsint，可以检查下面 5 个问题：

• 你能否区分 Type、Tool、Enricher、Flow 各自负责什么
• 你能否解释为什么 scan() 和 postprocess() 要分开
• 你能否说清楚 primary field 和 nodeLabel 分别解决什么问题
• 你能否从一个域名出发，设计一条 3 步以上的 Flow
• 你能否说明“数据本地存储”与“默认完全离线”为什么不是一回事

十六、FAQ：读完后最容易继续追问的几个问题

16.1 Flowsint 和单个 OSINT 工具相比，最大价值是什么？

不是“查询能力绝对更强”，而是 把多类查询统一纳入图模型，并支持持续扩展与复用。

16.2 它是不是等于 Neo4j 可视化前端？

不是。Neo4j 很重要，但 Flowsint 的关键还包括：

• 类型系统
• Enricher 编排
• Tool 抽象
• Flow 机制
• 参数与凭证系统

16.3 为什么说它适合开发者深挖？

因为官方文档已经把扩展路径写得相当清楚：

• 如何建类型
• 如何建 Tool
• 如何建 Enricher
• 如何做参数、日志、关系、测试

这意味着它不仅能“拿来用”，也适合“拿来学平台设计”。

十七、总结：如何评价 Flowsint

如果只用一句话总结，我会这样定义 Flowsint：

它不是把 OSINT 能力简单堆进一个前端，而是试图用类型系统、图模型和可扩展编排，把调查过程产品化。

它最有价值的地方，不是某个单独 enricher，而是下面这套组合拳：

• 用类型系统保证输入输出一致
• 用 Tool 抽象隔离底层数据源
• 用 Enricher 承担调查业务逻辑
• 用 Flow 固化可复用的多步路径
• 用图数据库沉淀持续可探索的关系网络

如果你只是想“临时查一个域名”，它可能偏重；但如果你在做需要持续积累、反复验证、多人协作的调查工作，Flowsint 的设计非常值得认真研究。

附录：术语速查

参考资料

• GitHub：https://github.com/reconurge/flowsint
• 官网：https://www.flowsint.io/
• 安装与快速开始：https://www.flowsint.io/docs/getting-started/quickstart
• Enricher 概念：https://www.flowsint.io/docs/getting-started/enrichers
• Flows：https://www.flowsint.io/docs/getting-started/flows
• Enrichers catalog：https://www.flowsint.io/docs/sources/available-enrichers
• Managing types：https://www.flowsint.io/docs/developers/managing-types
• Managing tools：https://www.flowsint.io/docs/developers/managing-tools
• Managing enrichers：https://www.flowsint.io/docs/developers/managing-enrichers