GravityAgent（一）：把 IPv6 测绘研究代码变成可运行平台

Sep 5, 2026

Series

IPv6 网络测绘 GravityAgent 架构

本文属于系列

GravityAgent IPv6 测绘平台实战第 1 / 7 篇

把 IPv6 测绘研究代码变成可运行平台

这是「GravityAgent IPv6 测绘平台实战」系列的第一篇。

这个系列不讲某一篇论文的复现，而是讲一件更工程化的事：如何把 IPv6 地址生成、扫描执行、操作系统识别、多用户交互这些能力，串成一个真正能跑起来、能追踪、能落库的闭环系统。

为什么 IPv6 测绘这么难

做 IPv4 测绘时，我们可以直接全网枚举 2³² 个地址，配合 ZMap 之类的工具做无状态扫描。但到了 IPv6，情况完全不同：

地址空间是 2¹²⁸。这个数字大到无法暴力枚举，哪怕只扫一个 /64 子网，也有 2⁶⁴ 个地址。
地址分配稀疏。运营商和企业的 IPv6 地址往往集中在少数子网，且接口标识符（IID）的生成方式五花八门，不能简单按顺序遍历。
研究代码与生产系统脱节。6Graph、6Forest、Entropy/IP、6Sense 这些算法仓库，通常只负责”生成候选地址”，很少解决”如何和真实扫描系统打通、如何追踪批次、如何给多人使用”。

GravityAgent 的定位，就是解决第二、三类问题，并把第一类问题做成可落地的系统。

一句话概括：这是一个 IPv6 目标生成 + 扫描执行 + 结果回收 + 多用户交互 + OS 识别 的统一平台。

它不是一个算法仓库合集

很多人第一次看到这个仓库，会以为它是”若干论文代码的合集”。但实际上，它的核心价值在于工程化封装：

从已有扫描结果中提取组织相关的存活 IPv6 地址，作为种子；
用多种算法做地址模式挖掘和候选生成；
自动把候选地址提交给扫描器；
把扫描结果写回 PostgreSQL 主库与批次级 SQLite 结果库；
通过命令行或 Web 持续查询、导出、复用；
对目标 IP 进行操作系统识别和可信度分析。

五层架构

整个系统可以抽象成五层：

┌─────────────────────────────────────────────────────────────┐
│ 第五层  Web 交互层   agent/web_app.py (Flask)                │
│         用户认证 / 多用户隔离 / 后台任务 / 文件归档          │
├─────────────────────────────────────────────────────────────┤
│ 第四层  Agent 编排层 agent/agent.py (LangGraph ReAct)        │
│         自然语言 → 工具调用 → 结果汇总                       │
├─────────────────────────────────────────────────────────────┤
│ 第三层  算法适配层   sixgraph / sixforest / entropy_ip /     │
│                     sixsense                                 │
│         把研究代码封装成统一 Python 接口                     │
├─────────────────────────────────────────────────────────────┤
│ 第二层  识别与指纹层 os_identify/                            │
│         TCP 原始探测 + nmap 指纹库 + 置信度报告              │
├─────────────────────────────────────────────────────────────┤
│ 第一层  扫描与数据层 gravity-scanner/ (Rust)                 │
│         批次管理 / 任务分发 / 结果落库 / 导出                │
└─────────────────────────────────────────────────────────────┘

第一层：扫描与数据层

由 Rust 编写的 gravity-scanner 提供批次管理、任务分发、扫描结果落库和结果导出接口。它维护两类存储：

PostgreSQL 主库：保存批次摘要、任务状态、lease、结果暂存等元数据；
批次结果库 data/batch_<id>.db：保存每个批次的主机级结果。

第二层：识别与指纹层

os_identify/ 提供 IPv4/IPv6 操作系统识别能力，包括原始 TCP SYN 探测、双引擎指纹匹配、任务状态持久化和可信度分析报告。

第三层：算法适配层

这一层不直接面对用户，而是把不同算法封装成统一的 Python 接口或子进程桥接：

SixGraphMiner
SixForestMiner
EntropyIpMiner
SixSenseRunner

它们负责把”上游研究代码”转换成”当前系统可以稳定调用的工程模块”。

第四层：Agent 编排层

agent/agent.py 基于 LangChain + LangGraph 的 ReAct agent 构建，通过工具调用完成查询、导出、挖掘、预测和识别。它负责：

从扫描系统获取种子地址；
根据用户意图选择查询、预测或 OS 识别工具；
调用算法生成模式或候选地址；
调用 os_identify 执行 OS 识别；
将结果保存到统一路径；
自动将候选地址提交回扫描系统；
将批次号、文件路径和结果摘要返回给用户。

第五层：Web 交互层

agent/web_app.py 实现用户认证、多用户配置隔离、附件上传下载、聊天历史、后台任务调度和文件归档。

完整闭环长什么样

把上面五层串起来，就形成了一个从”历史数据”到”新扫描结果”的闭环：

历史扫描结果 (PostgreSQL / SQLite)
        │
        ▼
   提取存活 IPv6 种子
        │
        ▼
  6Graph / 6Forest / Entropy/IP / 6Sense
        │  模式挖掘 + 候选生成
        ▼
   候选地址文件 (download/<uid>/candidates/)
        │
        ▼
   自动提交 gravity-scanner
        │
        ▼
   新批次扫描 (data/batch_<id>.db)
        │
        ├──► 结果导出 / 复用为下一轮种子
        │
        └──► os_identify 操作系统识别

这个闭环意味着：系统对”地址预测”的定义不是离线研究实验，而是生产式闭环——生成、提交、追踪、导出全部连通。

仓库结构

gravity/
├── README.md
├── docs/
│   ├── technical_report.md        # 技术报告
│   ├── presentation_report.md      # 汇报报告
│   └── code_walkthrough.md         # 关键代码走读
├── agent/
│   ├── agent.py                    # 命令行 Agent（约 3300 行）
│   ├── web_app.py                  # Flask Web 平台
│   ├── runtime_paths.py            # 运行期路径规范
│   ├── sixgraph.py                 # 6Graph 适配层
│   ├── sixforest.py                # 6Forest 适配层
│   ├── entropy_ip.py               # Entropy/IP 适配层
│   ├── sixsense.py                 # 6Sense 总控包装
│   ├── sixsense_train.py           # 6Sense 训练桥接
│   ├── sixsense_bridge.py          # 6Sense 生成桥接
│   └── org_ipv6_mapping.json       # 组织 → ASN/前缀映射
├── os_identify/
│   ├── pipeline.py                 # 核心识别流程（约 1300 行）
│   ├── nmap_fingerprints.py        # 指纹库解析与匹配（约 790 行）
│   ├── nmap-os-db                  # nmap OS 指纹库（5652 条）
│   └── os_identify.db              # SQLite 结果库
├── gravity-scanner/                # Rust 扫描系统
│   └── src/{main,api,db,engine,state,models,org_lookup}.rs
├── dbui/                           # 独立只读数据可视化 WebUI
├── 6Graph/ 6Forest/ entropy-ip/ 6SENSE/   # 上游算法代码
├── data/                           # 每个批次的结果库
├── runs/                           # 统一运行期产物
├── upload/ download/               # Web 上传 / 用户隔离下载
└── dns_server_find/                # DNS 服务器发现子系统

技术栈一览

层次	技术
扫描引擎	Rust 2021、Tokio、Axum、pnet、sqlx
算法适配	Python 3.9+、NumPy、NetworkX、scikit-learn
Agent 编排	LangChain、LangGraph、ChatOpenAI
Web 平台	Flask、SQLite（用户/会话）
数据存储	PostgreSQL（主库）、SQLite（批次结果）
OS 识别	原始套接字、nmap OS 指纹库

本系列会讲什么

接下来几篇会按”自底向上”的顺序展开：

算法适配层：6Graph / 6Forest / Entropy/IP / 6Sense 是怎么被统一封装的；
扫描执行引擎：Rust 写的 gravity-scanner 如何做无状态探测与任务调度；
操作系统识别：双引擎识别与置信度报告；
Agent 编排：自然语言到工具调用，以及候选自动提交闭环；
多用户 Web 平台：用户隔离、后台任务、文件归档与防幻觉；
工程化踩坑复盘：模块冲突、除零 bug、WAL 落库、参数错位等真实问题。

下一篇，我们从最底层的算法适配层开始，看看研究代码是怎么被”驯服”成工程模块的。