Saika

尊敬的平台用户与开发者： **Axon_V2.6-EXP-Checkpoint-260702** 模型将于 **2026年8月15日** 正式从 **BrewTotal 竞技场** 下线。 作为阶段性实验检查点，该模型已圆满完成其历史评估使命。为保障您的评测体验与接入连续性，我们推荐您迁移并接入更新的迭代模型。 --- ### 变更明细 * **下线模型**：`Axon_V2.6-EXP-Checkpoint-260702` * **下线时间**：2026年8月15日 * **影响范围**：BrewTotal 竞技场评测与调用入口 * **推荐替代模型**：`Axon_V2.6-EXP-Checkpoint-260717` ### 迁移建议 推荐选用检查点模型 **`Axon_V2.6-EXP-Checkpoint-260717`**。新模型继承了前版本的检测特性，并在综合效能与稳定性上进行了针对性优化。请相关项目团队及时更新配置，以确保后续测试与调用的顺畅。 感谢您对 Axon 系列引擎及 BrewTotal 竞技场的关注与支持！ **Axon 团队** 2026年8月12日

## 摘要与核心结论 Axon v3-Pre（内部迭代代号 v2.6Exp）完成了对上一代 Axon 2.5Exp 架构的全面重构。系统从传统的“手工特征工程 + LightGBM + 规则路由”树模型体系，演进为“端到端原始字节注意力机制 + 结构化特征融合 + 级联梯度提升纠错网络 + 零依赖 Native C++ 部署”的深度学习混合架构。 ### 核心演进与性能指标 * **架构范式转换**：摒弃 2.5Exp 时代受限于预设特征抽取器的工作流，采用 4096 / 65536 字节原始字节流直接输入注意力网络学习隐式表示，叠加 331 维内容特征级联纠错层（Stage-2 HGB），实现特征捕获与决策矫正解耦。 * **显存与计算优化**：针对 65536 序列长度在传统 Self-Attention 下导致单层注意力矩阵膨胀至约 2 TB（Batch Size 64）的问题，设计自研 MHDSRA2（Multi-Head Dynamic Sparse Recurrent Attention）流式注意力网络，将全序列训练峰值显存降至 **2.24 GB**（Chunk Size = 512, FP32）。 * **基底模型表现**：经过 20 个 Epochs（27.2 小时）训练，在 147,796 个独立测试样本（包含 3,482 个 UPX 加壳白名单文件）上，基底深度模型实现 Test F1 **0.9795**、Accuracy **0.9679**、AUC **0.9921**。 * **Stage-2 纠错提升**：叠加 331 维内容特征与 3-Seed HistGradientBoosting（HGB）纠错层后，Test F1 提升至 **0.99341**，全局分类错误数从 4,742 降至 1,511（**假阳性 FP 下降 75.8%，假阴性 FN 下降 51.9%**）；UPX 加壳白文件误报数由 236 降至 52。 * **原生部署交付**：模型收敛为单一 ONNX 结构（输入包含 `byte_seq[1, 4096]`、`pe[1, 1500]`、`stat[1, 49]`，输出 `logits[1, 2]`），通过无外部依赖的动态链接库 `axon_onnx_predict.dll`（`__cdecl` 接口，18 个导出函数，96 字节 `KvdConfig` 结构体）交付。脱离 Python/PyTorch 运行环境，单文件平均推理延迟 **~355 ms**。 * **现实边界约束**：基于静态特征与含噪标签数据集，绝对零误报与 Recall $> 99\%$ 无法同时达成。评估表明基座模型中包含 221 个置信度 $> 90\%$ 的假阴性（FN）样本，主因为数据源标签噪声，而非模型表征缺陷。 --- ## 1. 架构演进背景与遗留系统（v2.5Exp）局限性 在重构之前，Axon 2.5Exp 采用了“手工特征提取 + LightGBM 树模型 + 静态规则路由”的经典工程架构。随着恶意样本复杂度的提升与对抗技术的演进，该架构逐步显露出若干难以通过局部调优解决的技术瓶颈： ### 1.1 静态特征空间的表征瓶颈 * **特征表达能力受限**：遗留系统的特征抽取过程脱离了下游任务的梯度反馈，高维二进制数据在进入模型前即被大幅度静态压缩（主要依赖轻量级哈希桶与基础 PE 结构字段）。这种缺乏上下文感知的特征设计，造成了深层结构信息的不可逆损失。 * **规则路由的泛化局限**：原有的专家路由机制依赖硬编码的规则阈值（如加壳标志、特定节区比例）。在面对新型加壳变种或缺乏显式特征字符串的对抗样本时，硬编码规则难以自适应动态变化，容易导致路由门控退化。 ### 1.2 树模型对字节特征的拟合瓶颈 在遗留系统的特征重要性评估中，用于刻画原始字节分布的特征字段排名普遍靠后（无一进入前 50）。这表明“人工设计预压缩规则，再由树模型拟合”的传统范式，无法有效捕获二进制文件内部的高频局部字节模式。为此，v3-Pre 决定放弃预判机制，转向**端到端原始字节注意力表示学习**，由神经网络直接从原始字节流中提取高阶特征。 --- ## 2. v3-Pre 模型架构设计 v3-Pre 的深度神经网络采用**三路异构输入 + 特征拼接（Concat）融合**的拓扑结构。 ``` ┌─────────────────────────────────────────────────────┐ 原始字节流 ─► byte_seq(4096/65536) │ ByteEmbedding(256→128) │ │ └─► 正弦位置编码 (max_len=65536) │ │ └─► input_proj(128→128) │ │ └─► [MultiHeadDSRA2 ×2, chunk_pool=last] ──► 128-dim│ PE 结构特征 ─► legacy_dynamic(1500) ┼─► PEFeatureProjector(1500→256→128) ──────► 128-dim│ 字节统计特征 ─► stat(49) └─► stat_projector(49→128) ──────────────► 128-dim│ └───────────────────────────────┬─────────────────────┘ ▼ Concat 融合 ──► 384-dim ▼ LayerNorm(384) ──► Linear(64) ──► GELU ──► Linear(2) ``` ### 2.1 参数量结构分解 根据模型权重文件 `best_model_739k.pt` 的 `state_dict` 实测统计，各模块参数配置如下： | 模块名称 | 参数量 | 结构配置说明 | | --- | --- | --- | | **ByteEmbedding** | 32,768 | 词表大小 256 $\times$ 隐层维度 128 | | **input_proj** | 16,512 | Linear(128 $\to$ 128) + GELU 激活 | | **MultiHeadDSRA2 ($\times 2$)** | 196,876 | 单层 98,438（QKV 投影 49,152 + Out 投影 16,384 + Slot 初始化 16,384 + 门控单元 132） | | **PEFeatureProjector** | 417,664 | Linear(1500 $\to$ 256) + LayerNorm + GELU + Linear(256 $\to$ 128) | | **stat_projector** | 6,656 | Linear(49 $\to$ 128) | | **classifier** | 25,538 | LayerNorm(384) + Linear(384 $\to$ 64) + GELU + Linear(64 $\to$ 2) | | **总计可训练参数** | **696,014** | **约 69.6 万可训练参数** | > **注**：权重文件中的 `numel` 统计值（9,183,060）包含 8,388,608 个**不可训练**的正弦位置编码 Buffer（$65536 \times 128$）及别名引用。模型核心可训练参数仅 69.6 万，具备极高的计算效率与 CPU 运行友好度。 ### 2.2 融合机制选择策略 在系统开发中评估了 `add`、`gated`、`residual_stat_gate` 以及 `cross-attention` 等多种融合拓扑（`model.py:561-584`）。实验表明，在三路输入隐层维度统一对齐至 128 的前提下，直接采用 `concat`（共 384 维）能够以最简单的方式实现信息无损传递，避免了复杂注意力融合带来的额外超参数引入与梯度不稳定风险。 --- ## 3. MHDSRA2 流式注意力网络计算机制 为解决长字节序列在端到端训练时的显存爆炸问题，设计了 MHDSRA2（Multi-Head Dynamic Sparse Recurrent Attention）网络。 ### 3.1 复杂度对比分析 | 维度 | 标准多头自注意力 (MHA) | MHDSRA2 流式注意力 | | --- | --- | --- | | **每层注意力得分计算** | $\mathcal{O}(B \cdot H \cdot T^2)$ | $\mathcal{O}(B \cdot H \cdot C \cdot (K + W + \text{topk}))$，其中 $C=512$ (Chunk Size) | | **每层缓存开销** | $\mathcal{O}(B \cdot H \cdot T \cdot d)$，随序列长度 $T$ 线性膨胀 | $\mathcal{O}(B \cdot H \cdot (K + W) \cdot d)$，固定开销，与 $T$ 解耦 | | **65536 序列 / Batch 64 显存** | 单层 Logits 占用 $\approx 65536^2 \times 64 \times 4 \times 2 \text{ Bytes} \approx \mathbf{2\text{ TB}}$ | 逐 Chunk 分块流式计算，实测峰值仅为 **2.24 GB** | | **跨 Chunk 状态传递** | 无（依赖全全局矩阵） | 依赖 Slot $K/V$ 状态矩阵 $[B, H, 128, d]$、Local Cache ($\le 256$) 及更新门控 | ### 3.2 算法处理流程 设 Chunk 大小为 $C=512$，槽位数量 $K=128$，对于输入的长字节序列，按以下三步分块处理： 1. **Slot Read（槽位读取）**：计算当前 Chunk 的 Query 与全局槽位 Key 的关联性 $Q \cdot K_{\text{slots}}^T \in \mathbb{R}^{B \times H \times 512 \times 128}$，取 `read_topk = 8` 执行稀疏 Softmax 聚合 Slot Value。 2. **Local Attention（局部因果注意力）**：在涵盖 Local Cache（$\le 256$ Token）与当前 Chunk 的滑动窗口内执行因果 SDPA（Scaled Dot-Product Attention）计算。 3. **Slot Write（槽位写更新）**：当前 Chunk 的每 Token 按 `write_topk = 4` 路由至指定 Slot，利用 `scatter_add` 累加，并通过包含 Age/Usage/Confidence 衰减机制的 Gated Forget 单元更新全局槽位状态。 ### 3.3 显存占用与 Chunk Size 关系测试 固定 Batch Size = 64，测试不同 Chunk 配置下的训练峰值显存： | Chunk Size ($C$) | 训练峰值显存 | 运行说明 | | --- | --- | --- | | **512** | **2.24 GB** | 生产与训练标准配置 | | **1024** | 4.23 GB | 显存膨胀约 1.9 倍 | | **2048** | 8.25 GB | 在 8GB 显存设备上触发 OOM 异常 | 其理论显存计算表达式为： $$\text{Memory}_{\text{DSRA}} \approx \mathcal{O}(B \cdot H \cdot C \cdot K \cdot d_{\text{head}}) + \mathcal{O}(2 \cdot B \cdot H \cdot W \cdot d_{\text{head}})$$ 通过用固定大小的 Slot 存储压缩记忆，成功将空间复杂度从 $\mathcal{O}(T^2)$ 压降至 $\mathcal{O}(T)$ 线性级。 ### 3.4 精度约束与 Diversity Loss * **数值稳定性约束**：DSRA 模块在 FP16 混合精度训练下，由于 Chunk 内部与 Slot 状态迭代累加，极易引发前向传播数值溢出（导致 NaN，见 `train_739k_full.py:234`）。实验验证 BF16 虽无 NaN 溢出，但由于 Python 层面的 Chunk 循环调度无法填满 GPU 算力，相比纯 FP32 无明显吞吐提升。因此，训练过程强制采用**全单精度（Pure FP32）**。 * **Slot 坍塌正规化**：为防止 128 个全局 Slot 退化为同质化表示，训练损失中引入了对 Slot Key 矩阵的重叠惩罚： $$\mathcal{L}_{\text{div}} = \lambda \cdot \frac{1}{B \cdot H} \sum_{b,h} \left\Vert{} \text{Gram}\left(K_{\text{slots}}^{(b,h)}\right) - I \right\Vert{}_F^2$$ 其中设置 $\lambda = 0.03$。计算上直接对 Gram 矩阵求逐元素平方和，避免了高代价的 $O(K^3)$ 矩阵求逆运算。 --- ## 4. 结构化特征提取与对齐（legacy_dynamic） 在三路输入中，`legacy_dynamic` 模块负责处理传统的 PE 头与结构化信息（`extractor.py:706-855`）。 ``` [0 : 18] 固定字段：文件头属性与安全标志 [18 : 18+3N] 动态 Section 属性：包含 exec / write / read 标志 (N 为 Section 数量) [18+3N : 47+3N] 聚合计算特征：信息熵、导入/导出表统计、尾部 Overlay 数据、API 类别映射等 [47+3N : 1500] 零值填充（Zero-Padding） ``` 该设计的优势在于，将 Section 维度的访问权限直接转化为动态对齐特征，保留了结构体上下文；缺点是特征索引位置依赖于 $N$ 的变化，导致静态特征名列表与物理偏移不可直接一一映射。此外，审查发现历史代码中的 `idx16`（`has_signature`）依赖未定义的 PE 库属性，导致该特征列恒为 0。在 v3-Pre 的规范化特征映射中，该无用列已被清理。 --- ## 5. 训练策略与平台特定并发优化 ### 5.1 训练超参数超细配置 | 参数项 | 配置值 | | --- | --- | | **损失函数** | Focal Cross-Entropy ($\gamma = 1.0, \alpha = 0.55$) + Label Smoothing ($0.03$) + Diversity Loss ($0.03$) | | **优化器** | AdamW ($\text{lr} = 8 \times 10^{-5}, \text{weight\_decay} = 1 \times 10^{-5}, \beta = (0.9, 0.999)$) | | **学习率调度** | 3 Epochs 线性 Warmup（$1 \times 10^{-6}$） $\to$ Cosine Annealing $\to$ $\text{Min\_LR} = 1.67 \times 10^{-6}$ | | **梯度裁剪** | Gradient Norm Standard $0.75$ | | **数值精度** | **Pure FP32** | | **字节输入截断** | 抽取 65536 字节，训练时截断前 4096 字节 | ### 5.2 截断策略权衡 在前 4096 字节截断配置下，DSRA 迭代步数由 128 降至 8，单步训练时间由 $9.2\text{ s}$ 缩短至 $0.5\text{ s}$（**吞吐提升 18 倍**）。由于 PE 文件头与入口点（Entry Point）上下文通常完整覆盖在前 4KB 空间内，深层字节信息的缺失将由 Stage-2 的全局内容特征进行弥补。 ### 5.3 Windows 并发调度故障修复 在 Windows 平台启用 PyTorch 多进程 DataLoader（8 个 Workers）时，各子进程在初始化 OpenBLAS 运行时会默认尝试锁死所有 CPU 线程（32 线程），导致 Windows 线程栈资源耗尽而产生挂起异常。必须在导入 `numpy` / `torch` 模块**之前**，注入环境变量控制： ```python import os os.environ.setdefault("OMP_NUM_THREADS", "1") os.environ.setdefault("OPENBLAS_NUM_THREADS", "1") ``` ### 5.4 训练收敛收尾记录 训练共执行 20 个 Epochs（耗时 27.23 小时）。基底模型获得 Test F1 **0.9795**、Precision **0.9723**、Recall **0.9867**、AUC **0.9921**（包含 3,217 个假阳性 FP 与 1,525 个假阴性 FN）。整个训练过程中早停机制（Patience = 8）未被触发，模型指标保持稳步上升。 --- ## 6. Stage-2 级联纠错架构（HistGradientBoosting） ### 6.1 纠错逻辑与特征设计 基底深度模型虽然整体校准良好（期望校准误差 ECE = 0.001），但由于训练集中良性样本有 89% 为 DLL 文件，导致模型对大型独立良性 EXE（如安装包、加载器）易产生过自信的误判。Stage-2 引入一个无需重训深度基座的轻量级级联纠错层。 ``` Base Model (739k) ──► p_malicious ──► [p, p², |p-0.5|, log(p), log(1-p), logit(p)] (6 维) │ 原始二进制文件 ──► content_pe_v1 (100 维) │ ──► content_pe_v2 (182 维) ─────────────────────┼─► 331 维特征矩阵 ──► content_string (43 维) │ ▼ 3-Seed HistGradientBoosting (HGB) ▼ 概率均值 ──► 阈值 0.55 决策 ``` * **基底概率衍生特征（6 维）**：提取 Logit 空间与概率空间中的非线性变形特征。 * **content_pe_v1（100 维）**：包含文件头统计、11 个数据目录属性、API 分类占比、导出表及 Overlay 组合特征。 * **content_pe_v2（182 维）**：涵盖 32 个高频 DLL 导入依赖、16 组 API 敏感行为特征、21 项 Section/入口点特征。 * **content_string（43 维）**：针对 ASCII/UTF-16 编码的连续游程、正则匹配（URL/IPv4/注册表/路径）及 14 类敏感语义模式进行提取。 ### 6.2 级联纠错消融实验 在 147,796 个独立测试样本上测试 Stage-2 的性能收益： | 评估配置 | 决策阈值 | Test F1 | 错分样本总数 | 假阳性 (FP) | 假阴性 (FN) | | --- | --- | --- | --- | --- | --- | | **纯 Base Model Logits** | 0.49 | 0.97999 | 4,597 | 3,072 | 1,525 | | **+ content_pe_v1 (100 维)** | 0.55 | 0.99282 | 1,647 | 842 | 805 | | **全量 331 维特征组合** | **0.55** | **0.99341** | **1,511** | **778** | **733** | 在难度极高的 3,482 个 UPX 加壳白名单文件测试子集中，基座模型的误报数由 **236 降低至 52**。剔除加壳白名单干扰后，全局 Test F1 超过 **0.995**。 --- ## 7. Native C++ 部署与端到端集成 ### 7.1 ONNX 导出契约 生产环境模型绑定为单一 ONNX 结构（`dist/axon_739k_onnx_final_20260808`）： | 张量名称 | 维度 (Shape) | 数据类型 (DataType) | 语义说明 | | --- | --- | --- | --- | | `byte_seq` | `[1, 4096]` | `INT64` | 截断的原始前 4KB 字节序列 | | `pe_features` | `[1, 1500]` | `FLOAT32` | `legacy_dynamic` 结构化特征 | | `stat_features` | `[1, 49]` | `FLOAT32` | 字节熵与全量统计特征 | | `logits` | `[1, 2]` | `FLOAT32` | 分类 Logits 输出 | ### 7.2 Native C++ 动态链接库设计 底层推理引擎通过 C++ 实现（`axon_onnx_predict.dll`），完全移除 Python、PyTorch 及 Scikit-Learn 运行时依赖。 * **ABI 与配置定义**：采用 `__cdecl` 调用约定，提供 18 个 C 风格 API 函数。结构体 `KvdConfig` 在 x64 架构下精确定向为 **96 字节**，在 Rust (`size_of::<KvdConfig>() == 96`) 与 Node.js (`koffi.sizeof == 96`) 中进行 ABI 校验。 * **运行时环境隔离**：针对 Windows 环境中 `System32` 下可能存在的旧版本 `onnxruntime.dll`（如 1.17.1）抢占符号问题，DLL 内部使用 `SetDllDirectory` 显式限定加载同级 `bin/` 目录下的 ONNX Runtime 1.24.4 版本。 * **字符集编译修正**：解决 MSVC 编译器在 GBK 编码下解析 UTF-8 中文注释时将续行符 `\` 误判为代码换行，从而导致函数签名损坏的问题。 * **推理耗时预算**：在预热完成后，包含文件读取、特征抽取、ONNX 节点推理的全流程平均耗时为 **~355 ms**（$< 500\text{ ms}$）。 --- ## 8. 综合评估与数据噪声分析 针对评估指标中的基准测试差异进行说明：遗留系统 v2.5Exp 在历史评估中宣称 Acc $0.9938$，但其评估集中恶意样本占比仅约 $60\%$ 且**完全不包含 UPX 加壳白文件**。v3-Pre 测试集包含了大量对抗性强、结构复杂的样本（114,693 个恶意样本与 3,482 个 UPX 加壳良性文件）。 在全局分析中，针对错分的样本进行离线归因发现： * 静态特征表达下不存在能够实现 `FP = 0` 且 `Recall > 99%` 的单点阈值。 * 在 Stage-2 预测的假阴性（FN）样本中，有 221 个样本在基座模型中的预测恶意概率超过 $90\%$。针对这部分样本进行人工逆向复核表明，大部分属于黑产样本在标注库中的**误标白数据（Label Noise）**。在排除误标噪声后，系统真实召回率估计可达 **0.9955**。 --- ## 9. 架构演进中的关键技术洞察 1. **结构化特征虚高问题**：遗留系统宣称的 1500 维特征，在 C++ 提取层实际仅落地 350 维，且关键路由字段存在静默丢失，架构设计需严格以代码实现为准。 2. **流式注意力的数值精度约束**：Chunked 注意力网络由于状态跨 Chunk 累积，FP16 会直接引发数值上溢（Overflow），工业落地必须使用 Pure FP32 或针对性梯度截断。 3. **模型参数量误区**：深度模型中的位置编码矩阵（Positional Embedding Buffer）易被误计入模型可训练参数，需剔除冻结 Buffer 评估真实计算负荷。 4. **特征对齐防线**：C++ 推理端与 Python 训练端特征提取器实现必须逐位（Bit-exact）对齐。本系统中对齐误差降低至 $0.00000$ 级别。 5. **动态拓扑的内存安全性**：在 C++ 中重新实现动态 PE 特征提取时，需防止越界读取及非标准 PE 头导致的内存崩溃。 6. **动态链接库加载防御**：Windows 系统 `System32` 路径下的全局 DLL 易造成依赖劫持，必须在 Native 层显式锁定加载路径。 7. **多进程并发线程竞争**：Windows 平台下 PyTorch 搭配 OpenBLAS 时，必须在导入底层数学库前锁定线程数，防止线程栈耗尽。 8. **分段互补特征设计**：4096 字节截断能够换取 18 倍的训练吞吐收益，深层字节信息的缺失可由非序列化的结构与字符串特征层有效弥补。 9. **级联树模型的部署化**：将 Scikit-Learn 训练的 HistGradientBoosting 决策树参数导出为纯数组 JSON 格式，由 C++ 原生解析运行，可避免引入额外的 C++ 运行时依赖。 10. **验证集与测试集隔离**：Stage-2 的决策阈值（0.55）严格在 Validation Set 上通过网格搜索获取，Test Set 仅执行单次推理评估，确保无测试集数据泄漏。 --- ## 10. 系统演进计划 1. **良性样本扩充重训收尾**：完成目前进行中的良性样本扩充重训任务（测试集包含 813,098 样本，良性样本占比提升至 29.5%），收敛后更新 Stage-2 纠错树。 2. **Stage-2Native 集成**：将导出为 JSON 数组的 Stage-2 HGB 权重接进 `axon_onnx_predict.dll` 的 `stage2_model_json_path` 接口，实现完全端到端交付。 3. **数据集标签去噪**：针对筛选出的 221 个高置信度假阴性（FN）样本建立自动化复核机制，清洗标注噪声。 4. **长上下文检索分支验证**：针对超过 65536 字节的特长文件，评估开启 `PagedExactMemory` 分页检索机制对分类精度的边际收益。

## 从 V2.5EXP 到 V2.6EXP：让引擎学会“阅读”文件 如果说 **Axon V2.5EXP** 是一套经验丰富的“结构化体检表 + 树模型判断器”，通过人工设计的表格特征精准识别威胁；那么今天发布的 **Axon V2.6-EXP-Checkpoint-260702**，则像是为引擎配备了一位**能直接阅读文件字节流的分析员**。 > 🔍 *"不再只依赖人工设计的表格特征，Axon V2.6 让模型同时学习‘文件字节长什么样’和‘PE 结构是否异常’，在面对加壳、结构异常等复杂样本时，拥有了更丰富的判断依据。"* --- ## 🔥 核心亮点：三大维度的全面进化 基于 V2.5EXP 的成熟基础，V2.6EXP 在模型架构、部署体验和扫描能力上进行了深度重构： ### 🧠 字节神经网络与多路特征融合 主模型路线从传统的 LightGBM 全面转向由 **DSRA/MHDSRA2 驱动的 AxonMalwareModel**。模型现在同时接收三路输入：`字节序列 + PE 结构特征 + 统计特征`，并在其上叠加内容特征校正。这让引擎能够深入洞察文件前段字节序列的模式。 ### 📦 嵌套包扫描 - **深层穿透：** `scan_nested` 全面支持 ZIP、7z、CAB、MSI 等格式，内层任一 PE 存在风险，外层包即刻预警，对安装包和压缩包投递场景极其友好。 --- ## 📊 实验测试 - 在本次严格的实验漏斗中，**Loop28 内容侧 PE metadata** 展现出了令人振奋的一致性收益。相比上一代Axon v2.5EXP，错误数在各级测试中均显著下降 > ⚠️ *坦诚而言，全量测试中仍有 1900+ 个错误分类，距离我们的终极目标仍有距离。因此，260702 是一个极具试用价值的实验 checkpoint，而非最终的稳定版。* --- ## 📌 版本信息速览 | 项目 | 详情 | |---|---| | **版本号** | Axon V2.6-EXP-Checkpoint-260702 | | **版本定位** | 实验版 checkpoint（非最终稳定版 Axon v3） | | **核心升级** | 字节神经网络 + 稳定 PE 结构 + 二阶段内容特征校正 | | **部署方式** | 支持无 Python 依赖的原生 DLL (ONNX Runtime) | | **兼容性提示** | ⚠️ V2.5 与 V2.6 的模型及特征缓存**不可混用** | --- ## 💬 写在最后：您的反馈，铸就 V3 > *从 V2.5 的结构化深耕，到 V2.6 的字节级探索，Axon 的每一次实验，都是为了在真实对抗中多一分胜算。* **Axon V3** 将把 V2.6 中验证有效的能力彻底产品化，打造一个更可信、更易部署的正式版本。您现在的每一次试用与反馈，都将直接决定 V3 的最终形态。

## 从 V2.1 到 V2.5EXP：进步有目共睹 自**25年12月**正式发布 **Axon V2.1** 以来，我们始终没有停下脚步。经过长达数月的深度测试与持续迭代，**26年3月**推出的 **Axon V2.5EXP** 在与 V2.1 的全面对比中展现出了**显著的性能跃升**——无论是在推理精度、响应速度还是任务泛化能力上，V2.5EXP 都交出了一份令人振奋的答卷。 > 📊 *"经过如此长时间的对比验证，我们可以自信地说：Axon V2.5EXP 是一次真正意义上的代际跨越。"* --- ## 🔥 下一步：Axon V3EXP 正式启航 在 Axon V2.5EXP 坚实基础上，我们即将迎来一次**架构级别的重大革新**。以下是本次升级的核心亮点： ### 🧠 全新模型架构 基于 V2.5EXP 的成功经验，我们对底层模型架构进行了**全面重构**，为下一阶段的能力突破奠定基础。 ### ⚡ 自研 DSRA 注意力架构 本次更新将引入我们**自主研发的 DSRA 注意力架构**。该架构旨在提升模型对关键信息的聚焦能力与长距离依赖的捕获效率，同时有效降低计算开销，实现**性能与效率的双重突破**。 ### 🔬 机器学习类型升级：迈向深度学习 模型的核心学习范式将从原有机器学习方案**全面升级为深度学习**，以更深层的网络结构、更强大的特征提取能力，释放 Axon 系列的全部潜力。 --- ## 📌 版本信息速览 | 项目 | 详情 | |---|---| | **新模型名称** | Axon V3EXP（暂定） | | **基础版本** | Axon V2.5EXP | | **核心升级** | DSRA 自研注意力架构 + 深度学习范式 | | **架构变动** | 模型架构全面重构 | | **状态** | 🔧 开发中，敬请期待 | --- ## 💬 写在最后 > *从 V2.1 的稳扎稳打，到 V2.5EXP 的厚积薄发，再到 V3EXP 的架构革新——Axon 系列的每一步，都在向着更远的未来迈进。* 感谢所有关注与支持 Axon 系列的朋友。**Axon V3EXP，即将到来。** --- *更多技术细节与正式发布时间，请持续关注后续公告。*

有bug都可以反馈到本帖中来，本帖会记录并跟踪所有bug情况

作为一款注重用户隐私的社区平台，MyndBBS 在安全设计上投入了大量精力。本文将介绍本论坛的技术安全细节，帮助您了解我们如何保护您的账号和数据安全。 --- ## 一、端到端加密（E2EE） 私信功能是本论坛的核心特性之一。我们采用 **端到端加密** 确保您的私人通信只有对话双方可以阅读，即使是服务器管理员也无法解密。 ### 加密架构 | 层级 | 技术方案 | 说明 | |------|---------|------| | 密钥交换 | P-521 ECDH | 椭圆曲线 Diffie-Hellman，提供 521 位安全级别 | | 后量子加密 | ML-KEM-1024 | 抗量子计算的密钥封装机制（X-Wing 混合方案） | | 密钥派生 | HKDF-SHA256 | 从共享密钥派生最终的 AES 加密密钥 | | 消息加密 | AES-256-GCM | 带认证标签的对称加密，防篡改 | ### 工作流程 1. 发送消息时，使用您的私钥与对方的公钥通过 ECDH 派生共享密钥 2. 结合 ML-KEM-1024 的共享密钥形成混合密钥材料 3. 通过 HKDF 导出 AES-256-GCM 会话密钥 4. 加密后的消息以 Base64 格式传输 ### 私钥保护 您的私钥本身使用独立的 AES-256-GCM 密钥加密存储。每次登录时，您需要输入密码解锁私钥。我们不会在服务器端存储您的明文私钥或密码。 --- ## 二、认证与授权体系 ### JWT 双 Token 机制 | Token 类型 | 有效期 | 存储方式 | |-----------|--------|---------| | Access Token | 15 分钟 | HttpOnly Cookie | | Refresh Token | 较长有效期 | HttpOnly Cookie | - Access Token 过期前会自动刷新，无需频繁登录 - Token 签名使用 HS256 算法，密钥由环境变量 `JWT_SECRET` 提供 - 生产环境下强制使用 HTTPS 传输（Secure Cookie） ### CASL 细粒度权限控制 我们采用 **CASL** 权限引擎实现基于角色的访问控制（RBAC）： | 角色 | 权限范围 | |------|---------| | SUPER_ADMIN | 完全控制权（manage all） | | ADMIN | 完全控制权（manage all） | | MODERATOR | 读取所有 + 管理面板访问权 | | 版主 | 仅限管辖分类内的管理权限 | | 普通用户 | 读写自己创建的内容 | | 游客 | 仅读取公开且无等级限制的内容 | 权限规则支持数据库驱动，允许管理员在不修改代码的情况下调整权限配置。 ### 会话管理 - 会话状态缓存在 Redis 中，加速验证 - 支持会话撤销（强制登出） - 被封禁用户无法通过缓存的 Token 继续访问 --- ## 三、无密码认证（Passkeys） 我们支持基于 WebAuthn 标准的 **Passkeys** 无密码登录。 ### 技术特性 - **平台认证器**：支持 macOS Keychain、Windows Hello、手机指纹等 - **Resident Key**：登录时无需输入用户名 - **用户验证**：优先要求生物特征验证（指纹、面容、PIN） ### 安全性优势 - 不存在密码泄露风险 - 无法被钓鱼攻击骗取 - 私钥永远不离设备 首次设置 Passkey 后，您可以在安全设置中管理已注册的认证器。 --- ## 四、两步验证（TOTP） 为账号安全提供额外保护层。 ### 加密存储 您的 TOTP 密钥（Base32 格式）不会明文存储在数据库中。我们使用： - **AES-256-GCM** 加密算法 - **HKDF-SHA256** 从 `JWT_SECRET` 派生加密密钥 - **认证标签（Auth Tag）** 检测密文篡改 - **`v1:` 前缀** 区分加密数据与遗留明文数据 ### 敏感操作二次认证 以下高风险操作需要进入 **Sudo 模式**（重新验证身份后执行）： - 删除已注册的 Passkey - 修改或禁用 TOTP 两步验证 - 修改安全相关的账号设置 --- ## 五、速率限制 为防止暴力破解、灌水和滥用，我们部署了多层级限流： | 场景 | 限制规则 | |------|---------| | 发帖/评论 | 5 分钟内最多 10 次 | | 文件上传 | 10 分钟内最多 5 次 | | 好友请求 | 1 小时内最多 20 次 | | 公开读取 | 1 分钟内最多 30 次 | 限流基于客户端 IP（经代理识别后的真实 IP）计算。 --- ## 六、HTTP 安全头部 后端使用 **Helmet.js** 设置安全相关的 HTTP 头部，包括但不限于： - `X-Content-Type-Options: nosniff` — 防止 MIME 类型嗅探 - `Content-Security-Policy` — 限制资源加载来源 - CORS 白名单 — 仅允许配置的域名跨域请求 ### CSRF 防护 针对非安全 HTTP 方法（POST/PUT/DELETE），我们验证： 1. `Origin` 请求头必须在允许的域名列表中 2. `X-Requested-With` 头必须为 `XMLHttpRequest` ### 文件下载安全 访问上传文件时： - 头像文件：以内联方式展示，设置 `Content-Disposition: inline` - 其他文件：强制下载，设置 `Content-Disposition: attachment` - 点文件（`.gitignore` 等）一律拒绝访问 --- ## 七、Cookie 安全配置 | 属性 | 值 | 作用 | |------|-----|------| | HttpOnly | true | 禁止 JavaScript 读取 | | Secure | production 环境为 true | 仅通过 HTTPS 传输 | | SameSite | lax | 限制跨站请求携带 | | Path | /api | 仅在 API 路径下生效 | --- ## 八、代码层面安全 ### 输入限制 - 请求体大小限制：**100KB** - URL 编码数据大小限制：**100KB** ### 安全默认值 - 隐藏 `X-Powered-By` 响应头 - 禁用调试模式 - 生产环境校验 `JWT_SECRET` 和 `JWT_REFRESH_SECRET` 必须不同 ### 审计日志 后端集成审计中间件，记录关键操作的元数据。 --- ## 九、隐私保护 - 私信内容采用端到端加密，服务器无法解密 - 数据库中不存储明文敏感信息 - 符合 GDPR 和《个人信息保护法》（PIPL）要求 --- ## 十、安全建议 作为用户，您也可以采取措施提升账号安全： 1. **启用 Passkeys**：使用生物特征登录，无密码泄露风险 2. **开启两步验证**：即使密码泄露，攻击者也无法登录 3. **使用强密码**：如果使用密码登录，确保密码足够复杂且唯一 4. **警惕钓鱼**：我们不会通过私信索要您的密码或验证码 5. **及时举报**：发现可疑行为或收到违规私信，请使用举报功能 --- MyndBBS 致力于为用户提供安全、可靠的社区环境。我们将持续关注安全领域的新技术，不断优化平台安全能力。 如您对安全有任何疑问或建议，欢迎通过站内渠道反馈。

各位用户： 为维护 MyndBBS 社区的健康氛围，保障所有用户的合法权益，我们依据《服务条款》第四条，特制定以下发帖行为规范。请您在发布内容前仔细阅读并严格遵守。 --- ## 一、基本原则 MyndBBS 是一个开放、包容、互助的社区平台。我们鼓励用户分享知识、交流观点、结交朋友。同时，每一位用户都有义务维护社区秩序，对自己的言行负责。 --- ## 二、禁止发布的内容 以下内容 **严禁** 在 MyndBBS 发布，一经发现，将根据违规程度给予删除、警告、临时封禁或永久封禁等处理： ### 1. 违法内容 - 任何违反中华人民共和国法律法规、国际法或您所在地区法律的内容 - 包括但不限于：传播淫秽色情信息、赌博、毒品相关内容、暴力犯罪等 ### 2. 侵犯性内容 - 诽谤、污蔑、侮辱、骚扰、威胁他人的文字、图片或视频 - 基于种族、民族、性别、宗教、性取向、年龄、残疾等的歧视性内容 - 任何形式的网络霸凌 ### 3. 侵权内容 - 未经授权发布他人的原创作品（文章、图片、音乐、视频等） - 侵犯他人商标、专利、商业秘密的内容 - 未经本人同意发布其个人信息（姓名、照片、联系方式等），即侵犯隐私权 ### 4. 垃圾信息与恶意内容 - 重复发布相同或相似内容（灌水） - 无关推广（广告、推销未经授权的商业内容） - 恶意软件、病毒、木马、钓鱼链接 - 任何试图破坏系统稳定或数据安全的行为 ### 5. 虚假信息 - 故意散布未经证实的谣言 - 伪造官方通知、系统消息或他人身份 - 误导性或欺诈性内容 --- ## 三、内容发布建议 为提升帖子质量，我们建议您： | 建议 | 说明 | |------|------| | 言之有物 | 发帖前请先搜索是否已有相关话题，避免重复 | | 分类明确 | 选择恰当的板块发布对应主题的帖子 | | 态度友善 | 即使观点不同，也请保持理性讨论 | | 尊重原创 | 引用他人内容请注明来源 | | 语言规范 | 使用清晰、准确的语言表达 | --- ## 四、年龄与账号责任 - **年龄要求**：您必须年满 16 周岁方可使用本服务。未满 16 周岁的用户需在父母或监护人同意并参与下方可使用。 - **账号安全**：请妥善保管您的账号凭证（包括密码和通行密钥），对您账号下发布的所有内容负责。如发现账号被盗用，请立即联系我们。 --- ## 五、违规处理 | 违规等级 | 行为示例 | 处理方式 | |---------|---------|---------| | 轻微 | 重复发帖、偏离主题 | 内容删除 + 警告 | | 中度 | 发布广告、轻微骚扰 | 临时封禁（1-30天） | | 严重 | 违法内容、严重侵权、多次违规 | 永久封禁 | 我们保留对违规行为进行独立判断的权利，并可在不事先通知的情况下执行处理。 --- ## 六、免责声明 您发布的内容代表您的个人立场，与 MyndBBS 无关。您应对自己发布的所有内容承担全部责任。因违规发布导致的一切后果，由发布者自行负责。 --- ## 七、结语 社区环境靠大家共同维护。我们希望通过这份规范，帮助每一位用户更好地参与社区讨论，同时保护大家的合法权益。 如您发现违规内容，欢迎通过站内举报功能反馈，我们将及时处理。 感谢您的理解与支持！

欢迎使用 MyndBBS！为确保社区健康有序，营造安全、尊重、高效的交流环境，我们依据《服务条款》制定本细则。请您在使用本论坛的私信功能时严格遵守。 --- ## 一、私信功能的安全使用红线 本论坛的"安全私信"功能是为注册用户提供的端到端加密通讯服务，旨在最大限度保障您的隐私安全。但加密不代表监管豁免，严禁利用该功能从事任何违法或破坏社区生态的行为。 ### 1. 严禁传播违法与违规信息 用户不得利用私信功能发送任何违反中华人民共和国法律、行政法规以及国际相关法律（如欧盟《通用数据保护条例》(GDPR)、中国《个人信息保护法》(PIPL)）的内容。这包括但不限于： - 涉及政治敏感话题、色情低俗、暴力恐怖、赌博诈骗的信息 - 宣扬仇恨、歧视（种族、宗教、性别等）的言论 - 任何侵犯他人名誉权、荣誉权的诽谤或辱骂性文字 ### 2. 严禁骚扰、威胁与欺凌 用户应尊重他人的人格尊严。禁止利用私信进行以下行为： - 持续发送无关信息，对他人进行恶意骚扰或"轰炸" - 发送恐吓、威胁性言论，或进行人身攻击 - 冒充他人、冒充论坛管理人员或冒充官方机构进行欺诈 ### 3. 严禁侵犯隐私与数据滥用 鉴于私信的私密性，用户更应恪守法律底线： - 禁止通过私信索取、收集、买卖或泄露他人的个人敏感信息（如身份证号、联系方式、家庭住址、生物识别信息等），严格遵守《个人信息保护法》关于未成年人保护的规定 - 禁止利用私信诱导用户点击恶意链接、下载含有病毒或木马的文件，或进行网络钓鱼（Phishing）攻击 - 禁止利用私信功能进行未经授权的商业广告推广、传销或垃圾信息群发 --- ## 二、用户义务与合规承诺 根据《服务条款》第2条（资格与年龄要求）与第4条（用户行为），您在使用私信功能时需履行以下义务： - **年龄要求**：若您未满 16 周岁（或您所在地区法律规定的相应年龄），您必须在父母或监护人的指导和同意下使用本服务，且监护人需对您的私信行为负责。 - **账号安全**：您有责任保管好您的账号凭据（Passkeys/密码）。如发现账号被盗用或未经授权使用，请立即通知管理员，以防止私信功能被用于非法目的。 - **自我承担**：鉴于私信数据采用端到端加密技术，平台服务器无法获取解密密钥，因此无法查看或留存私信明文内容。用户需自行承担私信内容的法律后果。 --- ## 三、违规处理与法律追责 依据《服务条款》第6条（终止与封禁），对于违反上述规范的用户，我们将采取严厉措施： | 处理措施 | 具体说明 | |---------|---------| | 技术处置 | 依据技术日志（发送行为、频率、账号关联等）进行风险评估，暂时或永久封禁私信发送功能 | | 账号封禁 | 严重违规行为（发送恶意软件、诈骗诱导等）将依据《服务条款》永久封禁账号并列入黑名单 | | 法律追责 | 依法配合司法机关调查，提供账号注册信息、登录日志等数据，追究法律责任 | 由于私信内容加密特性，平台无法主动监测具体内容。如您收到违规私信，请务必通过"举报"功能提交相关证据（如截图、上下文记录等），我们将依据举报材料进行核实并处理。 --- ## 四、争议解决与免责说明 鉴于私信功能的加密特性，若因用户自身发送违规内容导致的法律纠纷或账号封禁，平台不承担内容审查责任，但保留依据《服务条款》对违规账号进行处置的权利。用户应妥善保管自己的私信记录，若发生争议，需自行承担举证责任。 --- ## 五、温馨提示 > 网络并非法外之地。私信虽"私"，但法律监管无"盲区"。请各位用户珍惜账号信誉，文明沟通，共同维护 MyndBBS 的安全与清朗。

亲爱的社区朋友们： 大家好！ 首先，衷心感谢大家一直以来对我们社区的关注与支持。近期，我们正式上线了全新的论坛平台，采用我团队自主研发的后端系统，旨在为大家带来更流畅、更现代、更个性化的交流体验。 然而，不少热心用户已注意到：原Discuz论坛的历史数据（如旧帖、回复、积分记录等）并未在新平台中呈现。更有用户关心这些数据的去向。在此，我们郑重说明未进行数据迁移的原因，并就数据处理情况作出明确声明。 #### 数据因隐私保护已彻底删除 首先，我们确认：原论坛的所有数据——包括线上数据库及所有备份——均已因隐私保护原因被彻底、安全地删除。 原Discuz系统运行多年，数据结构复杂，且包含大量用户敏感信息（如密码哈希、邮箱、私信记录等）。在无法确保完全安全迁移的前提下，为杜绝任何潜在的隐私泄露风险，我们决定在新旧系统切换前，对原数据执行不可逆的清除操作。这一决策优先保障了每一位用户的数字安全，是我们对“用户隐私高于数据延续”原则的坚定践行。 #### 技术架构的根本性差异 原论坛基于Discuz这一成熟但架构陈旧的PHP+MySQL系统，其数据结构高度耦合，表设计复杂。而新论坛完全由我团队从零开发，采用现代化技术栈，数据模型、权限体系、内容存储方式均与Discuz完全不同。强行映射不仅工程量巨大，更可能引发数据错乱、关联断裂等问题。为避免“迁移成功但无法使用”的局面，我们选择不进行技术上不可控的迁移。 #### 产品理念的重塑 新论坛并非原平台的“升级版”，而是一次全新的出发。我们希望用户在新环境中以清晰的身份、干净的起点参与社区建设，而非被旧系统的等级、积分、标签所束缚。我们相信，真正的社区价值在于当下的互动与未来的内容共创。 #### 我们的承诺与新起点 虽然历史数据无法保留，但我们珍视每一位用户的存在与贡献： - **历史存档已不可恢复**：因数据已彻底删除，无法提供旧内容查阅或导出服务，敬请谅解。 - **新平台将更快迭代**：我们将把资源集中于新功能开发，打造更优质的社区环境。 - **鼓励新内容共创**：我们欢迎您将重要观点、经验或创作在新平台重新发布，共同构建属于当下的社区记忆。 我们深知，一次“清零式”的切换可能让您感到遗憾。但请相信，这一决定是基于对用户隐私安全的最高承诺与对社区长远发展的审慎考量。 感谢您的理解与同行。让我们在新起点，共同书写新的篇章。 KoloBBS 管理团队 2026/5/19