2026年1月

CyberStrikeAI：让安全测试像对话一样简单——智能渗透测试的技术实践

先附上开源工具链接：

https://github.com/Ed1s0nZ/CyberStrikeAI

从工具堆砌到智能调度：渗透测试的演进之路

作为安全工程师，我们都经历过这样的场景：面对一个新的目标系统，我们需要在数十个安全工具之间不断切换，记忆各种复杂的命令行参数，手动分析海量的扫描结果，然后在不同的工具输出中寻找关联性。这种工作方式不仅效率低下，更严重的是，我们往往在工具的使用上花费了太多精力，反而减少了对安全威胁本质的思考时间。

技术人的解决方案：CyberStrikeAI的设计理念

CyberStrikeAI不是要取代安全工程师，而是要成为工程师的智能助手。基于一个朴素但强大的想法：用技术手段解决技术问题，让AI处理重复性工作，让人专注于创造性分析。

效果

对话效果


MCP调用

调用链

核心架构：Golang + MCP协议的工程化实现

// 核心架构简示
Agent Loop (AI决策引擎)
    ↓
MCP Server (工具调度中心)  
    ↓
Security Executor (命令执行层)
    ↓
98+ Security Tools (工具生态)

技术栈选择背后的思考：

  • Golang：并发性能优异，跨平台编译方便，部署简单
  • MCP协议：标准化工具调用，确保扩展性和兼容性
  • SQLite：轻量级数据存储，适合单机部署场景

实际工作流程对比

传统方式：

# 1. 端口扫描
nmap -sS -sV -O 192.168.1.0/24

# 2. Web服务识别
httpx -l targets.txt -title -status-code

# 3. 漏洞扫描  
nuclei -l targets.txt -t /nuclei-templates/

# 4. 手动分析结果，决定下一步...

CyberStrikeAI方式：

"对192.168.1.0/24网段进行全面的安全评估，重点关注Web服务漏洞"

系统自动完成：

  1. 识别网络范围，调用nmap进行主机发现
  2. 对发现的Web服务调用httpx进行指纹识别
  3. 基于服务指纹选择相应的漏洞检测模板
  4. 自动分析结果，对可疑目标进行深度扫描
  5. 生成结构化报告，包括漏洞详情和修复建议

面向安全工程师的技术特性

工具集成：不重复造轮子

我集成了98+个经过社区验证的安全工具，包括：

  • 信息收集：nmap, subfinder, amass, theharvester
  • 漏洞扫描：nuclei, sqlmap, xsser, dalfox
  • Web安全：dirb, gobuster, nikto, wafw00f
  • 专项工具：wpscan, jexboss, ysoserial

每个工具都通过YAML配置文件进行标准化封装：

name: "nmap"
command: "nmap"
args: ["-sT", "-sV", "-sC"]
description: "网络扫描工具，用于发现网络主机、开放端口和服务"

parameters:
  - name: "target"
    type: "string"
    description: "目标IP地址或域名"
    required: true

智能决策：AI作为调度器

AI在系统中的角色不是替代工具，而是智能调度器和结果分析器：

// AI决策流程
1. 理解用户自然语言请求
2. 分析目标特征和测试需求  
3. 选择最适合的工具组合
4. 动态调整参数优化扫描效果
5. 解析工具输出，提取关键信息
6. 基于发现决定后续测试路径

实时监控：掌握测试全过程

系统提供完整的执行监控：

# 查看工具执行状态
GET /api/monitor

# 实时查看漏洞统计
{
  "total": 23,
  "severityCount": {
    "critical": 2,
    "high": 5, 
    "medium": 10,
    "low": 6
  }
}

实际应用场景分析

场景一：红队渗透测试

需求：快速对目标企业进行外围渗透测试
传统方式：手动信息收集 → 工具链执行 → 结果整理 (耗时：4-6小时)
CyberStrikeAI：单次对话描述测试目标 → 自动执行完整流程 (耗时：30-60分钟)

场景二：漏洞复现与验证

需求：批量验证SRC提交的漏洞
传统方式：逐个手动测试，重复性工作量大
CyberStrikeAI：批量导入目标 → 自动匹配检测方案 → 生成验证报告

场景三：安全巡检

需求：定期对资产进行安全巡检
传统方式：编写脚本，定时执行，人工分析
CyberStrikeAI：配置巡检策略 → 自动执行 → 差异对比 → 告警通知

扩展性与二次开发

自定义工具集成

通过标准的YAML配置即可集成新工具：

name: "custom-scanner"
command: "python3"
args: ["/tools/myscanner.py"]
parameters:
  - name: "target"
    type: "string"
    required: true

API集成现有流程

系统提供完整的REST API，可轻松集成到现有安全体系中：

# 集成到自动化漏洞管理平台
def trigger_scan(target, scan_type):
    response = requests.post(
        'http://cyberstrike-ai:8080/api/agent-loop',
        json={'message': f'{scan_type}扫描 {target}'}
    )
    return process_results(response.json())

技术人的实践建议

部署方案

  • 开发测试：本地Docker部署，快速验证
  • 团队使用：服务器部署，共享使用
  • 集成环境：API方式集成到现有安全平台

使用技巧

  1. 渐进式测试：从基础扫描开始，逐步深入
  2. 结果验证：AI发现的关键漏洞建议人工复核
  3. 工具补充：根据实际需求扩展工具库

结语：技术赋能，专注价值

CyberStrikeAI的本质是通过技术手段提升安全工程师的工作效率，让我们从繁琐的工具操作中解放出来，更加专注于威胁分析、漏洞研究和防护策略等更有价值的工作。

在网络安全人才紧缺的今天，提升个体工程师的效率就是提升整个行业的安全水位。我相信，好的工具应该像得力的助手一样，默默处理繁琐工作，让专家专注于专业判断。

项目地址：https://github.com/Ed1s0nZ/CyberStrikeAI

让技术回归本质，让安全测试变得更加高效——这是CyberStrikeAI的技术追求，也是我对安全社区的诚意贡献。

前言

将近三周的时间开发，目标是针对小白都能上手的Windows应急工具，完全基于红队人员攻击思路以及蓝队应急流程开发的Windows应急响应工具，目前V2.0的版本基本上已经ok了没有问题，下面是工具介绍，目前网上基本上没有比这个更好用且更完善的工具，计划是在V3.0计划兼容Winserver2008以下版本，另外加入内存马查杀机制。因为初衷就是想轻量，如果工具过大就违背了这个工具的初衷。

工具授权

目前工具设置需要授权码，计划是三月一次授权。

Cr7crwBXfh2AHVMh/RmH7w==

项目地址

系统支持

  • Windows 10/11 ✅
  • Windows Server 2012/2016/2019/2022 ✅
  • Windows Server 2008 R2 ✅
  • Windows Server 2008 非 R2 ⚠️ 仅支持 Get-EventLog，需升级 PowerShell

工具核心日志处理

// 后门用户迁移4732时间id日志提取
func FetchAndStoreBackdoorUsers(db *sql.DB, startTime, endTime string) error {
	// 动态构建 PowerShell 命令，使用传入的开始和结束时间
	psCmd := fmt.Sprintf(`[Console]::OutputEncoding = [System.Text.Encoding]::UTF8;
$startTime = '%s';
$endTime = '%s';
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4732; StartTime=$startTime; EndTime=$endTime} -MaxEvents 200 |
ForEach-Object {
    $xml = [xml]$_.ToXml()

    $subjectSid = $xml.Event.EventData.Data | Where-Object { $_.Name -eq "SubjectUserSid" } | Select-Object -ExpandProperty '#text'
    $memberSid = $xml.Event.EventData.Data | Where-Object { $_.Name -eq "MemberSid" } | Select-Object -ExpandProperty '#text'
    $groupSid = $xml.Event.EventData.Data | Where-Object { $_.Name -eq "TargetSid" } | Select-Object -ExpandProperty '#text'

    function Get-NameFromSid($sid) {
        try {
            return (New-Object System.Security.Principal.SecurityIdentifier($sid)).Translate([System.Security.Principal.NTAccount]).Value
        } catch {
            return $sid
        }
    }

    $subjectName = Get-NameFromSid $subjectSid
    $memberName = Get-NameFromSid $memberSid
    $groupName = Get-NameFromSid $groupSid

    "$($_.TimeCreated)###$($_.Id)###$subjectName###$memberName###$groupName"
}`, startTime, endTime)

	// 调用 runPowerShellCommand，它会返回一个包含输出行的切片和错误信息
	lines, err := runPowerShellCommand(psCmd)

	// --- 错误处理部分 ---
	// 如果 PowerShell 命令执行失败
	if err != nil {
		// 检查错误信息是否包含“No events were found”
		if strings.Contains(err.Error(), "No events were found") {
			// 如果是这个特定错误，返回自定义的友好错误信息
			return fmt.Errorf("无用户组迁移相关事件id4732")
		}
		// 如果是其他错误，则返回原始错误
		return fmt.Errorf("执行PowerShell命令失败: %w", err)
	}

	// 如果没有错误，但返回的行切片是空的，也视为没有找到事件
	if len(lines) == 0 {
		return fmt.Errorf("无用户组迁移相关事件id4732")
	}
	// --- 错误处理部分结束 ---

	tx, err := db.Begin()
	if err != nil {
		return err
	}
	defer func() {
		if err != nil {
			tx.Rollback()
		}
	}()

	// 清理旧数据
	_, err = tx.Exec(`DELETE FROM backdoor_users`)
	if err != nil {
		return err
	}

	stmt, err := tx.Prepare(`INSERT INTO backdoor_users (time_created, event_id, subject_name, member_name, group_name) VALUES (?, ?, ?, ?, ?)`)
	if err != nil {
		return err
	}
	defer stmt.Close()

	for _, line := range lines {
		if len(strings.TrimSpace(line)) == 0 {
			continue
		}
		parts := strings.SplitN(line, "###", 5)
		if len(parts) < 5 {
			continue
		}

		_, err = stmt.Exec(parts[0], parseInt(parts[1]), parts[2], parts[3], parts[4])
		if err != nil {
			return fmt.Errorf("插入后门用户日志失败: %w", err)
		}
	}

	return tx.Commit()
}

基本上所有的日志模块的处理都是基于powershell来实现的，所以在winserver 2008及以下的版本不安装工具是无法使用的

日志检索效率以及优势

因为该工具是日志文件数据提取保存，会从db文件中读取已经保存的部分数据，在检索速度上效果还是可以的，最大的优势是直接根据事件详情提取需要的字段，避免从Windows自带的检索功能中逐条查看，效率大大提高。

主机信息模块

  • 获取主机信息和网卡信息
  • 获取网络连接状态
  • 网络外联IP定位，目前调用的是公网的ip.net的接口

日志分析模块

  • 提取 Windows 应用日志（Application Log）
  • 提取 Windows 安全日志（Security Log）
  • 支持查看登录成功（4624）、登录失败（4625）、防火墙日志、用户组迁移、用户创建删除等事件
  • 日志保存到 log.db（SQLite 数据库）
  • UI 分页展示、点击查看完整内容
  • 支持模糊查询快速定位IP和用户
  • 根据数据库内容利用AI依据各个表的时间线进行安全分析(建议使用AI分析+人工确认)
  • 一键快速分析功能，可以直接根据数据库生成事件摘要


目前版本为V2.0，因为在实战中1.0的出现部分bug，已经在2，0版本中修复了，防火墙日志图片仅供参考

任务调度

  • 提取定时任务详情，实时刷新

  • 支持任务筛选模糊查询

网站导航模块

  • 云沙箱、IP反查、威胁情报、空间测绘、网站备案、常见编码解码

目前支持一键跳转，本来是计划做一个聚合类的导航栏，奈何go语言实现太麻烦，略微有点儿鸡肋性价比低就实现的跳转。

DeepseekChatAI模块

  • 支持 Deepseek API 调用
  • 上下文聊天、会话创建、清空、删除

在风险主机出网的条件下是支持使用ChatAI模块的，直接在Deepseek购买api量即可，总的来说完全够用。

IP情报查询模块

  • 调用 VirtualTools API 查询IP
  • 请求率: 每分钟4次，每日500次，每月15.5K次
  • 红色标记已打标签IP

目前代码位置固定仅支持每分钟查询4个ip。

截图模块

  • 点击“截图”按钮即可截取全屏
  • 自动保存到当前目录下的 Screenshots 文件夹
  • 支持多显示器同时截图
  • 弹窗提示保存的截图数量和保存路径

使用方法

  1. 启动工具后选择日志类型
  2. 点击按钮执行提取，日志保存到本地数据库
  3. 分页浏览日志，点击查看详情
  4. 可通过筛选或时间选择缩小范围

注意事项

  • 必须以管理员权限运行
  • 默认拉取最近7天日志，可自定义
  • 首次运行会自动创建 log.db，config.json

工具使用效果

目前在本机三层靶场测试效果还可以，基本上受控主机上测试效果还是可以的，基本上可以覆盖溯源攻击路径，不过该工具还是基于windows日志来实现的，前提是日志审核策略需要开启，目前基本上一般业务系统有做过等保和加固的常见的日志审核策略是满足需求的。并且AI的一键分析是基本上能够满足定位分析攻击路径的。

一、概述

在 Windows 系统中，压缩包（如 RAR、ZIP、7z 等）作为常见的文件分发载体，因其便捷性和通用性被广泛使用。然而，攻击者常利用压缩软件的目录穿越漏洞（如 CVE-2025-8088），通过构造恶意压缩包将恶意载荷写入系统关键路径（如启动项、系统目录等），实现持久化驻留或提权执行。此类攻击隐蔽性强、危害大，且传统静态检测难以有效识别。

为应对这一威胁，天穹沙箱正式上线压缩包目录穿越动态检测能力。该能力通过监控压缩软件在沙箱环境中的实际解压行为，实时捕获文件写入路径，精准识别包含 ..\、绝对路径、UNC 路径等高危操作，有效还原攻击者的真实意图。

二、目录穿越攻击常见手法

当前主流压缩包目录穿越攻击主要包括以下几类：

  1. 路径遍历（Path Traversal）压缩包内构造包含 ..\..\..\ 的文件路径，诱导解压程序将文件写入非预期目录。例如：1
    ..\..\..\AppData\Roaming\Microsoft\Windows\StartMenu\Programs\Startup\demo.exe
  2. 绝对路径写入部分压缩格式（如 RAR）支持在压缩时嵌入绝对路径。攻击者可直接指定目标写入路径，绕过用户预期目录限制。
  3. UNC 路径利用通过构造类似 \\?\C:\Windows\Temp\demo.exe 的 UNC 路径，绕过常规路径校验逻辑，实现任意位置写入。

三、样本分析

样本上传

上传样本到天穹沙箱，即可快速准确地检测未知样本恶意行径，操作步骤如下：

  1. 登录天穹沙箱；
  2. 选择分析环境及配置项，如图 1 所示，选择 Windows x64 作为分析系统，配置自动解压开关为 OFF，点击确认选择；
  1. 登录天穹沙箱；
  2. 选择分析环境及配置项，如图 1 所示，选择 Windows x64 作为分析系统，配置自动解压开关为 OFF，点击确认选择；
图1 分析配置

上传样本，点击上传区域选择样本上传或将样本拖至上传区域即可上传样本，如图 2 所示，等待沙箱分析结束。

图2 上传样本

检测能力

样本一：7z目录穿越利用（CVE-2025-11001）

报告链接：天穹沙箱分析报告

漏洞原理：CVE-2025-11001 漏洞源于 7-Zip 在处理 ZIP 压缩包中的符号链接（Symbolic Links）时存在安全缺陷。具体来说，当 7-Zip 解压包含符号链接的 ZIP 文件时，未能正确验证符号链接指向的目标路径，导致攻击者可以构造恶意的 ZIP 压缩包，其中包含指向系统关键目录（如系统目录、程序目录等）的符号链接。

经天穹沙箱分析，在 7z 解压过程中捕获到以下行为，如图 3 所示:

  • 7z 工具向自启动目录写入文件 c:\Users\luchao\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\calc.exe；
  • 该路径明显超出沙箱指定的解压目录 C:\Users\luchao\AppData\Roaming\；
  • 沙箱触发“目录穿越”高危告警。
图3 目录穿越检测

借助天穹智能分析平台了解 CVE-2025-11001 漏洞的详细信息，如图 4 所示，智能体总结了漏洞成因、攻击条件、影响版本、PoC代码等信息，并以脑图形式直观展示分析结果之间的关联和层级结构。

图4 天穹智能体解读

样本二：winrar 目录穿越利用（CVE-2025-8088）

报告链接：天穹沙箱分析报告

漏洞原理：WinRAR 在解析压缩文件时存在路径校验逻辑缺陷，未对压缩包内嵌的 NTFS 备用数据流（ADS）及路径跳转符号（如 ..\）进行严格过滤。攻击者可利用此缺陷构造恶意压缩包，通过 ADS 特性隐藏恶意文件，并结合路径遍历技术突破解压目录限制，最终将文件写入系统敏感路径（如启动目录）。

基于天穹沙箱的动态分析链还原漏洞利用攻击路径，如图 5 所示：

  1. 触发解压：用户双击恶意压缩包，系统调用 WinRAR.exe 启动解压流程；
  2. 路径篡改：WinRAR 在解析压缩包时，未正确校验文件路径的合法性。攻击者通过 ADS 流嵌入的路径跳转指令（如 ..\Startup\payload.exe），将目标解压路径动态指向系统启动目录（C:\Users\luchao\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup）；
  3. 越权写入：WinRAR 绕过用户指定的解压目录（如 C:\Downloads），直接将恶意文件写入启动目录，完成持久化驻留。
图5 目录穿越检测

四、IOC

恶意文件（SHA256）

1
2		ad9d91db166e91139b41ae1beae99da78ce0d231b32c43daf50eb0270508d5e9
2a8fafa01f6d3863c87f20905736ebab28d6a5753ab708760c0b6cf3970828c3

报告链接

样本一分析报告：天穹沙箱分析报告

样本二分析报告：天穹沙箱分析报告

技术报告, , ,

近日，国际顶级学术会议 NDSS 2026（Network and Distributed System Security Symposium）公布录用结果，奇安信技术研究院合作完成的5篇论文成功被录用。NDSS 2026将于2026年2月23日至27日在美国圣地亚哥举办。此次多篇论文被录用，充分展现了奇安信技术研究院在网络安全前沿技术研究领域的深厚实力。

1. 大语言模型（LLM）推理服务框架中的缓存安全问题

第一篇论文是由奇安信技术研究院、中国海洋大学和清华大学联合完成的AI安全研究工作，论文题目为《Cache Me, Catch You: Cache Related Security Threats in LLM Serving Frameworks》。这项工作由中国海洋大学和奇安信联合培养的硕士研究生吴祥凡在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和曲海鹏教授（中国海洋大学），其他作者为陈国强（奇安信星图实验室），谷雅聪（清华大学）。这项研究聚焦于大语言模型（LLM）推理服务框架中的安全威胁，深入分析了 KV Cache、多模态缓存及语义缓存 三大核心机制。

这项工作揭示了上述机制中严重的安全隐患：攻击者可利用这些漏洞操纵模型输出，实施数据投毒，甚至绕过现有的安全审核与防御体系。团队在 vLLM、SGLang 和 GPTCache 等主流推理服务框架中定位到了具体的实现缺陷，并提出了针对性的修复方案。目前，相关漏洞已被厂商确认并修复，因此获得了 3 个 CVE 漏洞编号，为提升 LLM 基础设施的安全性做出了实质性贡献。

2. npm 生态漏洞传播影响分析

第二篇论文是由奇安信技术研究院和清华大学合作完成的关于软件供应链安全的工作。论文题目为《From Noise to Signal: Precisely Identify Affected Packages of Known Vulnerabilities in npm Ecosystem》，作者为蒲应元（奇安信星图实验室）、应凌云（奇安信星图实验室）和谷雅聪（清华大学）。这项研究提出了基于函数调用关系的细粒度漏洞传播关系识别方法，结果表明传统的基于包依赖关系识别的漏洞影响结果中约 70% 都是误报。

npm作为全球最大的开源软件生态，其错综复杂的依赖关系使得漏洞极易在供应链中传播，给软件安全带来巨大隐患。现有的包级别软件成分分析（SCA）工具普遍存在严重的误报问题，无法区分漏洞代码是否真实被调用，同时现有的函数级分析工具在面对大规模生态时，往往面临计算成本过高和对JavaScript动态特性支持不足等瓶颈。为解决这些问题，我们设计开发了 VulTracer，一款面向npm生态的高精度、可扩展的函数级漏洞传播分析框架。该工具创新性地提出了“一次分析，多次复用”的模块化分析模式，通过对每一个 npm 包构建不可变的富语义图（RSG）、提取形式化接口以及按需组合合成技术，成功解决了大规模静态分析中的性能与精度挑战。

同时，VulTracer基于全量npm生态（覆盖3400万个npm 包版本，超 9 亿条依赖关系）进行了迄今为止最大规模的函数级漏洞影响实证研究。实验结果表明，该工具在调用图构建上达到了0.905的F1分数（SOTA），相比npm audit降低了94%的误报率；同时研究结果进一步揭示，现有包级别分析工具产生的警报中 68.28% 均为“噪声”（即漏洞代码不可达），且真实的漏洞传播往往随依赖层级加深而迅速衰减。该工作为缓解开发者的警报疲劳提供了切实可行的技术路径，使安全修复工作能聚焦于真实存在的威胁。

3.JavaScript脚本的自动化反混淆

第三篇论文是由奇安信技术研究院和北京邮电大学合作完成的关于JavaScript反混淆的工作。论文题目为《From Obfuscated to Obvious: A Comprehensive JavaScript Deobfuscation Tool for Security Analysis》，这项工作由北京邮电大学和奇安信联合培养的卓越工程师计划博士研究生周董超在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和王东滨教授（北京邮电大学），参与该项工作的还有柴华君（奇安信星图实验室）。这篇论文也是我们继PowerPeeler (CCS 2024)和Invoke-Deobfuscation (DSN 2022)之后的又一项脚本反混淆工作。

JavaScript作为互联网核心脚本语言的广泛应用，使其成为恶意攻击者的重要载体。攻击者利用复杂的代码混淆技术隐藏恶意行为，给安全分析带来严峻挑战。现有反混淆工具普遍存在处理复杂样本能力有限、仅支持特定混淆类型、输出代码难以阅读等关键局限。为解决这些问题，我们设计开发了JSIMPLIFIER，一款集成多阶段处理流程与大语言模型增强的综合性JavaScript反混淆工具。该工具创新性地结合代码预处理、静态AST分析与动态执行监控的双引擎协同，以及基于LLM的智能变量重命名，实现从复杂样本格式化到语义增强的全流程反混淆。JSIMPLIFIER基于44,421个真实混淆样本构建了目前最大规模数据集，实验证明其100%覆盖20种主流混淆技术，达到100%处理成功率和正确率，代码复杂度降低88.2%，可读性提升超过4倍。该工具已成功还原JSFireTruck等复杂恶意样本的混淆行为，相关研究成果、工具及数据集已开源共享。

4. Windows 代码签名滥用分析

第四篇论文是由奇安信技术研究院、清华大学和中关村实验室合作完成的关于代码签名滥用检测的工作。论文题目为《Understanding the Status and Strategies of the Code Signing Abuse Ecosystem》，这项工作由清华大学和奇安信联合培养的卓越工程师计划博士研究生赵汉卿主导完成，导师为段海新教授（清华大学）和应凌云博士（奇安信星图实验室）。其他作者分别为张一铭（清华大学）、张明明（中关村实验室）、刘保君（清华大学）、游子权（清华大学）、张书豪（奇安信星图实验室）。

近年来，软件供应链安全事件频发，为了保护软件真实性与完整性，代码签名机制应运而生。代码签名主要依赖公钥基础设施 PKI 技术，旨在确保软件来自真实来源且软件内容未被篡改。然而，攻击者有时会反过来利用代码签名PKI信任体系中的安全缺陷，帮助恶意软件绕过操作系统和杀毒软件的检查。深入理解代码签名滥用生态系统的演变过程以及滥用者的策略，对于完善相关检测与防御机制至关重要。

在这项工作中，我们利用从真实世界中收集的 3,216,113 个已签名的恶意 PE 文件，对代码签名滥用行为进行了大规模测量。通过细粒度的代码签名滥用检测分类算法，我们检测到了 43,286 张滥用证书，构建了迄今为止最大的滥用标记数据集。分析发现当前代码签名滥用现象普遍存在，影响了 46 家 CA 厂商以及 114 个国家或地区的证书。我们发现了 5 种滥用者的攻击策略，并根据当前代码签名 PKI 存在的安全缺陷提出了若干缓解措施。

5. 4G LTE 飞基站系统性安全评估

第五篇论文是由清华大学、奇安信技术研究院、CableLabs、Carleton University 及泉城实验室合作完成的关于 4G LTE femtocell 安全风险评估的研究工作。论文题目为 《Small Cell, Big Risk: A Security Assessment of 4G LTE Femtocells in the Wild》。该项工作由清华大学和奇安信联合培养的卓越工程师计划博士研究生杨雅儒主导完成，导师为段海新教授（清华大学、泉城实验室）和汤舒俊（奇安信技术研究院）。其他作者分别为张一铭（清华大学）、万涛（CableLabs & Carleton University）、常得量（奇安信技术研究院）、李义申（清华大学）。

近年来，为了提升室内覆盖、降低部署成本并分担宏基站流量，femtocell 作为一种小型、低功耗的运营商基站，被部署于个人家庭等场景。与传统基站不同，femtocell 通常直接接入公共互联网，并在物理与网络层面更容易被攻击者接触。一旦被攻破，femtocell 会以“受信任节点”的身份接入核心网，可能对用户隐私与核心网安全造成严重威胁。

这项工作对真实世界中的 4G LTE femtocell 进行了系统性的安全评估。我们分析了 4 款来自不同厂商的商用 femtocell 设备，从硬件与软件两个层面识别出 5 类可导致本地或远程攻破的共性漏洞。在此基础上，我们在受控实验环境中进一步分析了被攻破 femtocell 对用户侧业务的安全影响，验证了对数据业务、语音通话以及短信服务的威胁，例如用户通信内容的机密性可能在特定场景下面临风险。随后，我们进一步开展了互联网规模测量，基于 IKEv2、TR-069 及管理接口等协议特征，在全球 IPv4 空间中识别出 86,108 个疑似 femtocell 部署实例，其中超过六成为高置信度目标。研究结果表明，femtocell 在真实网络中的暴露程度与安全风险显著，一台被攻破的 femtocell 即可能成为攻击用户与核心网络的重要入口。基于上述发现，我们讨论了其安全影响，并提出了针对设备、部署与标准层面的缓解建议。

=========  我 是 分 割 线  =========

星图实验室隶属于奇安信技术研究院，专注于软件与系统安全的核心技术研究与系统平台研发，对外输出“天穹”软件动态分析沙箱、“天问”软件供应链分析平台、“天象”软件漏洞挖掘系统等核心能力和工具系统。

我们目前正在招聘，工作地点覆盖北京、南京、成都等城市，详情请参见：https://research.qianxin.com/recruitment/

动态资讯, 学术动态, 技术报告

在大模型（LLM）服务极速发展的当下，效率至关重要。为了降低延迟并控制算力成本，主流推理框架广泛引入了先进的缓存机制。然而，这种追求极致速度的设计是否埋下了安全隐患？

本论文是由奇安信技术研究院、中国海洋大学和清华大学联合完成的AI安全研究工作说明了缓存机制如果实现不恰当的话，就会造成安全隐患。论文题目为《Cache Me, Catch You: Cache Related Security Threats in LLM Serving Frameworks》。这项工作由中国海洋大学和奇安信联合培养的硕士研究生吴祥凡在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和曲海鹏教授（中国海洋大学），其他作者为陈国强（奇安信星图实验室），谷雅聪（清华大学）。这项研究聚焦于大语言模型（LLM）推理服务框架中的安全威胁，深入分析了 KV Cache、多模态缓存及语义缓存 三大核心机制。

1. LLM推理加速背后的隐忧

随着模型参数规模的不断膨胀，推理计算的开销急剧上升。为了优化用户体验，vLLM、SGLang、GPTCache等主流服务框架引入了多种缓存策略，包括前缀缓存（Prefix Cache）、语义缓存（Semantic Cache）和多模态缓存（Multimodal Cache）。

虽然这些机制通过存储中间状态极大地减少了重复计算，但我们的研究发现，现有的缓存实现往往“重效率、轻安全”。非加密哈希函数的滥用、有缺陷的对象序列化以及模糊的语义匹配标准，共同构成了一个全新的、尚未被充分探索的攻击面。与以往关注训练阶段的数据投毒不同，这是一类发生在推理阶段的全新安全威胁。

2. Cache Me, Catch You：首个LLM缓存安全系统性研究

为了揭示这一风险，我们对主流LLM服务框架的缓存实现进行了全面的解构与分析，并提出了六种新颖的攻击向量。这些攻击利用了哈希碰撞和语义模糊匹配的特性，能够在不接触模型权重的情况下，通过污染共享缓存来操纵模型输出。

主要发现与攻击向量：

我们将发现的威胁归纳为两大类：一是面向用户的欺诈攻击，即攻击者利用系统渠道向用户传递恶意信息 ，具体手段包括利用哈希碰撞替换合法提示词以劫持对话逻辑的系统提示词碰撞、针对语义缓存构造高相似度恶意查询诱导错误回答的语义模糊投毒 ，以及在检索增强生成场景下利用文档相似性扩大攻击面的RAG语义投毒 ；二是系统完整性攻击，旨在破坏服务功能或绕过安全审查 ，具体涵盖构造与目标完整前缀碰撞以劫持响应的提示词碰撞劫持 、通过精心构造padding token让恶意代码块对LLM“隐形”以绕过审计的分块碰撞劫持 ，以及利用图像处理忽略元数据（如尺寸）缺陷构造哈希碰撞图片以绕过审核的多模态碰撞 。

细节详解：

以多模态为例，其核心漏洞根源在于当前主流推理框架（如vLLM）在对多模态数据进行序列化时存在严重的逻辑缺陷。具体而言，vLLM默认调用PIL 的 tobytes() 方法来提取图像数据以计算哈希，该方法虽然能获取原始像素字节流，但在vLLM的后续操作中完全忽略了图像宽高等尺寸信息以及调色板等关键元数据。攻击者利用这一特性实施“尺寸伪装”攻击，通过重塑图像维度（例如将 H*W的图像变形为W*H）而不改变像素排列顺序，使得原本违规的图片变成一团毫无意义的噪点，从而生成与原图完全一致的哈希值。此外，攻击者还能利用“调色板模式”漏洞，构造出索引数据相同但颜色定义截然相反的图片对（如黑底白字与白底黑字），由于序列化过程仅读取索引而忽略调色板定义，这两张视觉迥异的图片在系统眼中却拥有相同的“指纹”。

同样的隐患也出现在SGLang框架中，其为了适配张量数值范围将SHA256哈希值进行了取模截断，导致哈希空间被压缩至极易发生碰撞的范围。

下图是我们操纵图片当中的尺寸和PNG当中的P格式的调色盘，实现看上去不同的图片但是hash一致。

3. 实验效果与影响评估

我们在vLLM、SGLang及GPTCache等主流开源框架上进行了实测，证实了这些攻击路径的高可用性与低门槛：攻击者仅需不到1美元的成本即可完成一次投毒 。以针对vLLM的前缀缓存攻击为例，我们在30分钟内便成功搜索到碰撞哈希，实现了100%的缓存命中 。

实验还还原了真实的威胁场景违规图片如何利用多模态缓存缺陷骗过内容审核系统。下图展示一个示意图，成功命中图片之后会复用之前的图片预处理结果，导致生成了错误回复。

4. 防御方案与行业响应

针对发现的漏洞，我们提出了五层防御策略，包括引入随机化哈希（Salting）、采用强加密哈希函数、强制规范化序列化流程、使用更鲁棒的Embedding模型以及增加LLM辅助过滤层。我们的理论分析和实际验证表明，上述的防御方案是可行的、有效的。

我们在第一时间将发现的漏洞通报给了受影响的厂商和社区，包括 vLLM、SGLang、GPTCache、AIBrix、rtp-llm 和 LMDeploy，并分配了 3个 CVE 编号。值得注意的是，vLLM、GPTCache 和 AIBrix 已经采纳了我们提出的缓解措施（如引入随机盐值、规范化图像序列化等）并完成了修复。（在本文发表时，SGLang也反馈采纳了我们的缓解措施。）

5. 讨论与未来展望

我们的研究再次表明，高性能不应成为忽视底层系统安全的理由。本研究证明，即便模型本身无懈可击，外围缓存框架的设计缺陷仍足以瓦解整个系统的信任基石；特别是在云端共享算力场景下，必须实施严格的多租户隔离与键值空间分离以防御跨租户攻击。作为填补推理侧缓存安全空白的先行工作，本研究旨在推动社区正视这一隐蔽威胁，共同构建更稳健的大模型服务基础设施。

更多参考

想了解更多技术细节？欢迎阅读我们的学术论文或访问项目主页：

代码仓库：https://github.com/XingTuLab/Cache_Me_Catch_You

感谢您的阅读，期待能为您的AI安全研究与工程实践带来启发！

学术动态, 技术报告

一、引言：软件供应链安全的”狼来了”困境

想象这样一个场景：你是一名开发者，每天打开 CI/CD 系统，迎接你的是数百条安全警报——”检测到依赖包存在高危漏洞，请立即修复！” 但当你花费大量时间逐一排查后却发现，绝大多数警报都是虚惊一场：那些所谓的”漏洞代码” 根本就没有被你的应用调用。这种”警报疲劳”已成为软件供应链安全领域的痛点，也是众多安全检测工具难以实际落地应用的重要原因。

这正是奇安信技术研究院和清华大学研究团队在 NDSS 2026 会议上发表的论文所要解决的核心问题。论文题目为《From Noise to Signal: Precisely Identify Affected Packages of Known Vulnerabilities in npm Ecosystem》，作者为蒲应元（奇安信星图实验室），应凌云博士（奇安信星图实验室）和谷雅聪博士（清华大学）。这项研究针对全球最大的开源软件生态系统——npm（拥有超过 300 万个包，2024 年处理了约 4.5 万亿次请求），提出了一套基于函数调用关系的细粒度漏洞传播关系识别方法和分析框架。论文分析结果表明，传统工具所产生的漏洞警告中，高达 68.28% 都是”噪声”，即漏洞代码实际上根本无法被触达。

二、问题的本质：为什么传统方法会产生如此高的误报？

npm生态系统的复杂性源于其极度碎片化的包依赖结构。已有研究显示，约四分之一的npm包版本依赖于存在已知漏洞的包。以 pac-resolver为例，这个每周下载量达 300 万次的 npm 包曾曝出高危远程代码执行漏洞，导致 GitHub 上超过 28.5 万个公共仓库可能面临风险。但问题的关键在于：依赖存在漏洞的包，不等于你的应用真的受到影响。当前主流的软件成分分析（SCA）工具，如npm audit、GitHub Dependabot等，都采用包级别的分析方法。它们的逻辑很简单：如果你的依赖树中存在包A的v1.0版本，并且包A的v1.0版本存在漏洞，则发出警报提醒你的应用受到影响。 但这种粗粒度分析忽略了三个关键问题：

  1. 未使用的依赖：你的 package.json 声明了依赖，但代码中从未引入（require/import）该包的任何模块；
  2. 浅层的 API 使用：即使引入了包，可能只使用了其中若干个函数，而漏洞函数根本未被调用；
  3. 传递性衰减：通过多层依赖传递时，每一跳的使用范围都在缩小。

理论上，函数级可达性分析是最佳解决方案——只有当存在从应用入口到漏洞函数的调用路径时，才认为应用真正可能受到影响。但在 npm 生态实施函数级分析面临三大技术挑战：

  • 首先是可扩展性挑战：传统方法需要为每个项目构建完整的调用图（Call Graph），也包含其所有依赖，对于复杂项目，依赖数量可达数百甚至上千个包。每次分析都要从头开始，计算成本呈指数级增长。
  • 其次是 JavaScript 的动态特性带来的程序分析挑战。极其灵活的语法特性为静态分析制造了诸多盲区：代码中广泛存在的动态属性访问（利用变量而非字面量调用函数）、将函数作为参数传递的高阶函数机制（回调），以及允许在运行时动态修改对象原型链的特性，都让静态分析器难以在运行前确定具体的调用目标和完整的控制流，从而极易导致依赖分析链路的断裂或缺失。具体代码示例如下：
// 动态属性访问 
obj[propName]();  // propName是变量，静态分析难以确定调用目标  

// 高阶函数 
function process(callback) {    
    callback();  // 不知道传入的是哪个函数
}  

// 原型链动态修改 ，增加了分析的不确定性
Object.prototype.newMethod = function() { ... };
  • 最后，JavaScript 语言模块系统的复杂性进一步加剧了分析难度：CommonJS (require)和 ESM (import/export) 不同的模块机制、module.exports对象可在运行时修改，以及require()的参数可以是动态表达式 ，这些都进一步加剧了分析难度。

三、VulTracer的核心设计和解决方案

面对这些挑战，我们设计并实现了 VulTracer 这个分析框架。它的核心洞察在于：npm包一旦发布就不可变，因此可以为每个包预计算可复用的分析结果。这开启了”分析一次，复用多次”的新范式。

VulTracer 将传统的整体式分析分解为三个独立阶段，核心设计和架构如上图所示。以下将详细介绍每一个部分的设计逻辑和细节。

3.1 富语义图生成 (RSG Generation)

首先，VulTracer 利用程序静态分析技术，为每一个包构建了一个富语义图（Rich Semantic Graph, RSG）。这张图不仅看清了包内部的函数调用脉络，更关键的是，它显式地刻画了包的“边界”——哪些函数被暴露给了外部，又有哪些地方调用了外部依赖。传统的调用图（Call Graph）只记录”谁调用了谁”，而RSG设计了一个多层次的图结构，完整保留包的边界信息，图中的实体结构和详细定义如 下图 DEF1 所示，包含了三类不同的顶点集合和边集合。

3.2 接口契约提取 (Interface Contract Extraction)

虽然 RSG 保留了包的全部内部细节，但如何让独立分析的包能够正确”对接”？这就涉及到了提取形式化的接口契约。VulTracer 从这张复杂的图中提取出了一份简洁的形式化接口契约（Interface Contract）。这就像是给每个软件模块定义了标准的“插头”和“插座”，契约中清晰地记录了 API 的导出方式（Export Manifold）和导入方式（Import Manifest）。这一步至关重要，它充当了一道“语义防火墙”，屏蔽了复杂的内部实现细节，只保留了交互所需的关键信息。具体的定义如下图DEF2 所示。

3.3 拓扑排序驱动的按需组合式合成 (Compositional Synthesis)

最后，当需要检测某个具体项目时，VulTracer 不再需要深究源代码，而是像拼乐高积木一样，根据依赖关系，将预先计算好的 RSG 和契约进行组合式合成（Compositional Synthesis）形成一个新的生态级调用图 (ECG)。并且该 ECG 可根据任意真实项目的依赖关系按需组装。这种设计使得分析速度和扩展性得到了质的飞跃——在处理复杂的真实依赖图时，VulTracer 的成功率高达 99.41%，而对比的工具Jelly仅为 37.37%。

四、生态级实证研究：揭示漏洞传播的真相

在这项工作中，我们利用 VulTracer 对整个 npm 生态进行了史上最大规模的函数级漏洞传播影响分析。

4.1 数据集构建

首先我们构建了两个核心的数据集：

  • npm 生态数据集： 包含了 3,267,273个唯一npm包 以及其 34,685,976 个不同版本 。同时解析并构建了整个生态中超过9亿条的依赖关系。
  • 漏洞数据集：我们采用双维度选择策略，确保选择的漏洞样本既有代表性又有多样性。一是高影响力漏洞，从 2024 年下载量排行 TOP 10 的软件包 lodash, debug, semver, minimatch 这四个核心库中，找到了影响他们的6个CVE漏洞，每个软件包都有数十万直接依赖包，并且漏洞影响了超过百万的下游软件包。二是多样性维度，对齐 2024 CWE-Top-25 的类型，覆盖注入(CWE-79)、原型污染(CWE-1321)等21个不同类型的 CVE 漏洞，代表不同的攻击向量。最终我们的研究涵盖了27个CVE，涉及9,868,514条潜在传播路径。

4.2 单跳分析：分析衰减的根本原因

我们首先聚焦于d₁ → d₀的单跳关系，这样可以排除多跳传播的复杂因素，精确归因。在我们的研究中建立了三层漏洞传播条件：仅引入模块 (C_mod)、调用任意函数 (C_func)、调用漏洞函数 (C_vuln_func)。定义如下图所示：

只有 C_mod ∧ C_func ∧ C_vuln_func 同时为真，才认为漏洞真正传播。最终单跳的分析结果如下表所示。

我们发现平均 22.80% 的直接依赖包声明了依赖，但从未导入任何模块（C_mod失败）。以 lodash 为例：存在 396,112 个声明依赖的包，但是有 131,933个”僵尸依赖” (33.31%)。这13万多个包背上了”有漏洞”的标签，但实际上完全不受影响。同时我们还发现，npm 第三方库的 API 设计决定传播率。同样的对于 lodash 这样一个综合工具库，拥有242个函数，但漏洞函数 template 只占所有调用的0.30%，排名第49位，详细分析如下图所示。说明这个函数的下游使用率并不高。与之相反的是 debug 库，它功能单一专注于调试，其核心功能函数就是其主函数，导致直接依赖者的受影响比例高达 71.77%。

4.3 多跳分析：揭示传递性衰减规律

单跳分析揭示了初始衰减，但漏洞会通过传递依赖传播多远？我们追踪了完整的传播路径。在分析中，我们追踪了9,868,514条潜在传播路径，涉及1,663,634个包版本。 最终不同漏洞的传播结果如下表所示。

在表格数据中， 以 CVE-2022-3517 (minimatch) 为例，数据揭示了粗粒度分析带来的严重误报问题。包级别分析报告了 497,595 条潜在传播路径，涉及 286,731 个受影响的包版本。然而，经由 VulTracer 的函数级可达性分析，确证受影响的包版本仅为 22,557 个。从全局统计维度来看，函数级分析所识别的受影响库数量平均仅为包级别分析结果的 31.72% 。这一数据统计表明，现有包级别依赖扫描工具产生的警报中，约 68.28% 属于漏洞代码不可达的误报（False Positives）。

最后，在上图也更进一步可视化了漏洞传播随依赖链路深度的衰减过程，分别从两个不同的视角来进行呈现。图（a）展示了每一跳（Hop）中新增受影响包数量的分布情况。对比显示，函数级别（红色曲线）的传播在 3 跳之后呈现出急剧的衰减趋势，与包级别（蓝色曲线）的长尾分布形成显著差异。这证实了真实的漏洞影响范围会随着依赖深度的增加而迅速减弱。而图 （b） 展示了传播过程中的累积概率分布情况进一步佐证了这一“浅层效应”：函数级传播曲线迅速收敛并达到平台期，数据显示 96.59% 的真实受影响包均收敛在 4 跳 的范围内。这意味着，尽管依赖图谱可能具有较深的层级结构，但具有实际威胁的漏洞传播主要局限于浅层依赖网络中。

五、结论：从噪声中提取信号

面对日益复杂的开源生态，我们的研究证明，传统的“版本比对”模式已经难以为继。由现有包级别工具识别出的潜在风险中，高达 68.28% 的漏洞代码实际上从未被调用 。换言之，近七成的“受影响”项目其实是安全的，并不需要火急火燎地去修复。这种高误报率不仅制造了巨大的“噪声”，更导致了严重的警报疲劳，反而掩盖了真正的威胁。因此，转向更细粒度的函数级可达性分析已是行业必经之路。通过 VulTracer，我们可以从噪声中提取出那 30% 的真实信号。这不仅能让开发者从无效的运维工作中解脱出来，更能让安全团队聚焦于真正具有可利用性的威胁。这才是让供应链安全治理走出困境、迈向精准防御的未来方向 。

学术动态, 技术报告,

一、当恶意代码穿上”隐身衣”：JavaScript混淆的现实威胁

打开一个可疑的JavaScript文件，你可能会看到这样的代码：

这不是乱码，而是攻击者精心设计的”隐身衣”——JavaScript代码混淆。这段看似天书般的代码，实际上可能隐藏着窃取用户数据、植入后门或发起网络攻击的恶意逻辑。

JavaScript作为互联网前端和客户端脚本的核心语言，在网页及各类网络应用中被广泛使用，这也使其成为了攻击者的首选目标。攻击者频繁利用JavaScript的动态特性，通过多层、多样化的混淆技术隐藏恶意代码，极大增加了安全分析的难度。

面对这一日益严峻的安全威胁，奇安信技术研究院星图实验室与北京邮电大学联合研究团队在NDSS 2026会议上发表了论文《From Obfuscated to Obvious: A Comprehensive JavaScript Deobfuscation Tool for Security Analysis》。该论文由北京邮电大学和奇安信联合培养的卓越工程师计划博士研究生周董超在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和王东滨教授（北京邮电大学），参与该项工作的还有柴华君（奇安信星图实验室）。这篇论文也是我们继PowerPeeler (CCS 2024)和Invoke-Deobfuscation (DSN 2022)之后的又一项脚本反混淆工作。

通过系统性文献调研和样本分析，研究团队将JavaScript混淆技术归纳为四大类共20种技术：词法级混淆（变量重命名、间接属性访问等5种）、语法级混淆（表达式转函数、特殊编码等6种）、语义级混淆（字符串数组、控制流平坦化等7种）和多层混淆（OB混淆、AI辅助混淆2种）。针对这些复杂化的混淆趋势，研究开发的综合性反混淆工具JSIMPLIFIER能够自动破解各种混淆技术，将晦涩的恶意代码还原为安全分析师能够快速理解的清晰形式。

二、现有反混淆工具的三重困境

当前的JavaScript反混淆工具面临着三个核心挑战，这些挑战严重限制了它们在实际安全分析中的应用效果。

输入处理的脆弱性： 现有工具在遇到不同语法、混合编码、打包器包装等”不规范”输入时经常直接崩溃。真实世界的恶意代码往往包含这些问题，导致工具连分析机会都没有。
分析策略的单一性： 静态分析工具无法处理运行时依赖的混淆（如动态代码生成），动态分析工具又难以应对大规模样本和安全风险。更关键的是，现有工具通常只针对特定混淆模式，缺乏对多层混淆的综合支持。以JSFireTruck恶意软件为例，这个一个月内感染26.9万网页的攻击使用了复杂的多层混淆，现有工具要么无法处理，要么只能部分解码。
输出可读性的缺失： 即使成功反混淆，输出代码仍充斥着_0x4f2a、_0x1b3c等这样的无意义标识符，安全分析师需要花费大量时间才能理解代码逻辑，严重影响威胁响应效率。

三、JSIMPLIFIER的创新设计

针对以上挑战，我们提出了JSIMPLIFIER，一款集代码预处理、静态抽象语法树分析、动态执行跟踪和大语言模型（LLM）智能变量重命名与代码美化于一体的综合性反混淆工具。JSIMPLIFIER采用三阶段流水线架构，每个阶段专门解决一类核心问题，形成了从”输入修复”到”逻辑还原”再到”可读性提升”的完整处理链条。

预处理器：让”坏代码”变”好代码”（Preprocessor）

预处理器是整个系统的基石，负责将各种”问题代码”标准化为可分析的格式。它首先进行代码有效性检查，使用容错性强的Meriyah解析器，即使面对不同灵活语法或不完整的代码也能生成完整的抽象语法树（AST）。接着进行词法清理，系统性地处理字符编码冲突，比如将过时的八进制转义序列（如\302）转换为标准的十六进制格式（如\xC2），并重建被分割的多字节UTF-8字符。在语义兼容化阶段，系统将遗留的JavaScript构造替换为跨平台等价物，确保在现代JavaScript环境中的兼容性。最后通过结构优化，利用AST作用域链遍历解决声明冲突，将代码重构为严格模式兼容的形式。

反混淆器：静态与动态的完美协作（Deobfuscator）

反混淆器采用混合分析设计，巧妙结合静态AST分析和受控动态执行。

增强的静态AST分析 方面，JSIMPLIFIER配备强化表达式求值引擎，专门处理混淆代码中的复杂构造：对于LogicalExpressions，实现正确的短路求值处理嵌套的&&和||链（如False && anything直接返回False）；对于ES6解构赋值如[a, b, c] = [getValue(), obj.prop, func.call(this)]，JSIMPLIFIER扩展AssignmentExpression处理，解析左侧模式结构并递归遍历嵌套数组模式，将每个元素位置映射到对应的右侧值；对于UnaryExpressions中的环境检测代码如typeof window !== 'undefined'，JSIMPLIFIER维护excludedNames白名单（包含window、document、navigator等关键全局变量），避免静态求值破坏环境特定的代码路径。

受控动态执行监控 方面，JSIMPLIFIER首先进行预执行风险评估，扫描危险关键字组合（push、shift、eval、await）识别可能导致无限循环或递归死锁的代码模式，并通过函数依赖映射追踪混淆函数间的调用关系。然后使用Node.js的vm.runInNewContext创建隔离执行环境，每个混淆代码段在独立的沙箱VM实例中运行，无法访问文件系统、网络或全局对象，仅暴露必要的内置对象。JSIMPLIFIER实现了全面的安全机制，包括执行超时防止进程挂起、递归深度限制防止无限循环、内存监控防止资源耗尽攻击。

混合分析协调技术 通过双向信息流实现两种分析方法的有机融合。在静态到动态的移交中，当静态分析遇到无法安全求值的CallExpression时（如函数调用者通过变量查找确定、涉及运行时代码生成的调用、依赖运行时状态的调用），JSIMPLIFIER的canbetransformed标记机制识别这些表达式并打包上下文信息传递给动态执行监控。在动态到静态的反馈整合中，动态执行结果经过类型感知处理后重新整合到静态AST：简单数据类型直接转换为字面量AST节点，函数结果解析为FunctionExpression节点，复杂对象通过JSON序列化确保安全表示，同时更新作用域链中的变量绑定并触发依赖代码段的重新分析。

人性化器：从机器码到人类语言（Humanizer）

虽然反混淆器成功恢复了程序逻辑，但结果往往仍然难以阅读。人性化器通过LLM技术将机械正确但晦涩的代码转化为专业、可读的形式。在智能标识符重命名方面，JSIMPLIFIER可以利用多种LLM模型（GPT、Gemini、本地模型等）进行上下文感知的变量和函数重命名，将无意义的混淆标识符替换为语义明确的名称。同时通过专业代码美化，集成Prettier格式化工具，确保输出符合行业标准的代码规范，包括一致的缩进、标准化的括号放置和规范的引号使用，最终生成既功能正确又易于理解的高质量代码。

四、最大规模验证与突破性成果

全面的数据集构建

为公正全面地评估工具性能，我们构建了业界最大的真实JavaScript混淆数据集进行验证。MalJS数据集包含23,212个野生恶意样本（平均391.78KB），这些样本来自超过1000万个真实恶意代码中的精选，覆盖所有已知的20种混淆技术。BenignJS数据集包含21,209个良性样本（平均41.40KB），来源于GitHub热门项目和合法网站。这两个数据集提供了真实世界中多样化和多层混淆技术的样本，远超现有数据集仅包含人工生成样本的局限。

全面的技术覆盖突破

实验评估采用了多个互补维度进行综合测评。在反混淆能力评估中（表II），JSimplifier实现了对全部20种混淆技术的100%处理能力和100%正确率，远超现有工具。与13种现有方法（包括10种传统工具和3种基于LLM的方案）的对比表明，传统工具在面对复杂语义级混淆时表现不足，而即便是先进的LLM方案也难以处理最复杂的混淆方法。

显著的代码简化效果

在代码简化评估中，JSimplifier在多个维度上展现了卓越的性能。首先，工具在CombiBench基准测试上达到了0.8820的Halstead长度减少分数——这一指标衡量代码中操作符和操作数的数量变化，分数越高说明代码复杂度降低更多。JSimplifier实现的88.2%复杂度降低意味着反混淆后的代码比原始混淆代码简单了近9成，显著超越了现有工具。

此外，研究团队还采用熵值分析来量化代码的随机性和混乱程度。熵值越低，代码的结构越清晰、可读性越强。大规模评估显示，JSimplifier在全部44,421个样本上实现了显著的熵值降低（如图2）——无论是AST结构熵（衡量代码语法树的复杂度）还是代码文本熵（衡量文本层面的混乱度）均达到最低中位值，充分证明了工具在真实场景中的有效性。

质的可读性飞跃

为验证代码可读性提升，研究团队采用了多个先进LLM模型（Claude 3.7 Sonnet、Gemini 2.5 Pro、DeepSeek-R1、GPT-o3）进行独立评估。这些模型对代码可读性进行0-10分的打分，其中0分代表完全不可读，10分代表极易理解。评估结果如下表所示，JSimplifier实现了平均466.94%的可读性提升，将难以理解的混淆代码（评分1.02-1.81，接近完全不可读）转化为适合安全分析的清晰代码（评分6.21-7.83，达到良好可读性水平）。

此外，研究团队还进行了用户研究，邀请9名不同专业水平的参与者（新手、中级、专家各3名）分析混淆样本。结果表明JSimplifier显著提升了分析准确率（新手提升12.7%）并大幅减少了分析时间（中级用户减少47.7%），主观评分在可读性、清晰度和逻辑性方面均显著提高。用户研究显示，工具显著提升了分析准确率（新手提升12.7%）并大幅减少了分析时间（中级用户减少47.7%）。一位中级参与者评价道：”变量重命名让我能够快速跟踪逻辑流程，我可以在几分钟内识别出可疑的网络调用，而不是在整个分析过程中大海捞针。”

实战验证：破解JSFireTruck的”密码”

JSFireTruck恶意软件活动是JSIMPLIFIER实战能力的最佳证明。这个复杂的攻击活动仅使用六个ASCII字符!+就构建了极其复杂的混淆代码，传统工具几乎束手无策。

原始混淆代码（部分）：

JSIMPLIFIER反混淆结果：

通过JSIMPLIFIER，安全分析师可以清晰地看到攻击逻辑：检测搜索引擎来源、注入恶意iframe、重定向到攻击域名。这种从”天书”到”明文”的转换，极大提升了威胁分析和响应的效率，展现了工具在真实安全分析场景中的实用价值。

五、结论：从”混乱”到”清晰”的技术突破

JSIMPLIFIER的成功体现了针对JavaScript混淆这一具体安全问题的有效解决方案。通过将静态分析、动态执行和LLM技术相结合，该工具在处理复杂混淆代码方面取得了显著进展。

技术贡献的实际价值主要体现在三个方面：三阶段流水线架构有效解决了输入多样性、分析复杂性和输出可读性的问题；静态与动态分析的协调机制克服了单一方法的局限性；LLM技术的合理应用显著改善了代码的人机交互体验。这些技术改进为反混淆工具的发展提供了新的参考方向。

实验验证的充分性通过大规模真实数据集得到了有力支撑。在44,421个样本上的测试结果——100%的技术覆盖率、88.2%的复杂度降低、466.94%的可读性提升——证明了该方法的有效性。JSFireTruck等真实案例的成功处理进一步验证了工具在实际安全分析场景中的实用价值。

当然，JavaScript混淆技术仍在不断发展，新的挑战也会持续出现。JSIMPLIFIER的模块化设计为应对这些变化提供了一定的灵活性。我们期待通过持续的技术改进和社区合作，进一步提升JavaScript安全分析的效率和准确性。

目前，JSimplifier及对应数据集已开源发布，面向安全研究和防护社区共享。未来工作将继续优化工具性能，扩展对更多混淆技术的支持，为脚本安全分析提供更好的技术工具。

项目开源地址：https://github.com/XingTuLab/JSIMPLIFIER

论文链接：https://arxiv.org/abs/2512.14070

学术动态, 技术报告, , ,

  1. 肯定是 AI 写绝大部分代码，人只是起到审阅者作用，最多手动改几行代码，因此可以对手动编程不友好，但是一定对手动改动友好，只需要最小改动就能改正错误，例如尽量配置化。
  2. 语法应该尽量通俗化，小白上手快，一看就能看懂，例如多吸取语文，数学上的符号，表示，而不是像 C++，rust 那样晦涩难懂。
  3. 不会因为一个括号，一个分号的漏写就导致崩溃，应该是对 AI 友好的，多一些字符或少一些字符不会导致编译失败，例如定义函数是：
======= function myFunction =======

这里定义 === 只要大于 3 个就行，多了也不会报错，这样对 AI 改动就友好许多，同时也对人阅读友好。再举一个完整的例子：

======== 函数：计算面积 ==========
输入：长, 宽
输出：长 × 宽
================================

关键字支持自然语言同义词：如“输入”也可写作“参数”、“入参”、“arguments”，甚至可以做 i18n 国际化。

例如调用函数这么写：

[任务：发送邮件]
  收件人 = [email protected]
  主题   = "欢迎加入"
  内容   = 从模板"welcome.txt"加载
  条件   = 用户状态 == "已注册"

代码语句尽量通俗化：

如果 点击 支付按钮
那么 跳转 支付页
否则 弹出 提示 “请完成支付”

首先是在 b 站刷到了这个 OpenAI 员工翁家翌的访谈视频：
翁家翌：OpenAI ，GPT ，强化学习，Infra ，后训练，天授，tuixue ，开源，CMU ，清华｜ WhynotTV Podcast #4

访谈视频中翁家翌提到他是 OpenAI 的 infra （ LLM 基础设施）建设的，在他的观点看来，哪家 ai 公司更有能力看的并不是谁家的模型又上了 Benchmark 排行榜第一名，而是公司内部的 infra 的对于 llm 的迭代速度。

视频中他提到，OpenAI 内部用于训练 ChatGPT 的 infra 已经是三年前搭建的了，而他们仍然还在准备新一代的 infra ，这是 OpenAI 面对 DeepSeek, Gemini, Claude 时较为乏力的原因，这些后来者的 infra 比 OpenAI 的更加先进，这意味着他们可以更快地对 LLM 进行迭代。

随后又刷到了美国战争部长去 SpaceX 向 Elon Musk 取经的视频：
美国防部长走访马斯克星舰基地！要把第一性原理搬到五角大楼！

Musk 的 SpaceX 或者说 Tesla 的成功原因，一个是他的“第一性原理”，另一个就是他的“快速迭代理论”。

快速迭代理论说的是：并不是从一开始就做一个完美的产品，而是先做一个差不多的产品，然后用最快速度去逼近完美。

而 Musk 的星舰基地，就是一个快速迭代的平台，这个星舰基地有充足的资源让他可以不断试错不断发射失败，发射失败的速度越快，他距离成功的速度也就越快。

同理，回到 LLM 的迭代中，各家 AI 公司其实真正需要的不是一个牛逼的算法或者架构，而是可以最短时间内验证一个 idea 的能力，任何人有 idea 或者算法都可以在最短时间内集成到产品中去，从而判断是否可以加强产品能力。

这也是 DeepSeek 在 2025 年初能够释放重磅炸弹的原因，幻方量化有足够的 infra ，才能实现他们各种颠覆性的 ideas 。

LLM 的 infra 是 AI 公司的算力基建和训练管道，而对于普通程序员或者独立开发者来说，其实 idea 并不重要，因为这个世界上有太多的 idea 了，在 idea 落地之前，没人知道这个 idea 能否成功，重要的是实现 idea 的 infra ，也就是现在的 coding agent 。

因此，作为开发者，在 2026 年，一个 idea 落地的效率大大提高，因此没有必要再去问值不值得做，而是先 vibe coding 一个最简单的核心出来，然后看市场反馈，如果反馈好那么使用快速迭代理论来疯狂地接近成功。

另外再举一些生活中的例子，比如你想开一家咖啡馆，而你本身并没有开咖啡馆的经验，你要做的不是花几十万重金盘下一个店面装修再购买数万元的设备，而是使用最低成本：买二手设备，租便宜店面，先简单装修等等压缩成本的方式开一家咖啡馆，然后看自己能不能开好这家咖啡馆，如果营业不下去了就倒闭，然后总结经验，继续开始下一次试错。

到目前为止想的就这么多，本想用 AI 优化一下排版，但是不希望 AI 代理我的语言输出，大家将就看吧。

训练单个 RL 智能体的过程非常简单，那么我们现在换一个场景，同时训练五个智能体，而且每个都有自己的目标、只能看到部分信息，还能互相帮忙。

这就是多智能体强化学习（Multi-Agent Reinforcement Learning，MARL），但是这样会很快变得混乱。

什么是多智能体强化学习

MARL 是多个决策者（智能体）在同一环境中交互的强化学习。

环境类型可以很不一样。竞争性的，比如国际象棋，一方赢一方输。合作性的，比如团队运动，大家共享目标。还有混合型的，更像现实生活——现在是队友，过会儿可能是对手，有时候两者同时存在。

但是这里与一个关键的问题：从任何一个智能体的视角看世界变成了非平稳的，因为其他智能体也在学习、在改变行为。也就是说在学规则的时候，规则本身也在变。

MARL 在现实中的位置

单智能体 RL 适合系统只有一个"大脑"的情况，而MARL 则出现在世界有多个"大脑"的时候。

现实世界中有很多这样的案例，比如交通信号控制：每个路口是一个智能体，一个信号灯"贪婪"了，下游路口就会卡死；仓库机器人：每个机器人自己选路径，碰撞和拥堵天然是多智能体问题；广告竞价和市场：智能体用不断变化的策略争夺有限资源；网络安全：攻击者和防御者是相互适应的智能体对；在线游戏和模拟：协调、欺骗、配合、自我对弈——这些都是MARL 的经典试验场。

核心概念

大多数真实场景中，智能体只能看到状态的一部分。所以 MARL 里的策略通常基于局部观测，而不是完整的全局状态。

单智能体 RL 里环境动态是稳定的，而MARL 不一样"环境"包括其他智能体。它们在学习，你的转移动态也就跟着变了。

这正是经典的 Qlearn在多智能体环境里容易震荡、甚至崩溃的原因。

合作任务中团队拿到奖励，但功劳该算谁的？团队成功了，是智能体 2 的动作起了作用，还是智能体 5 在 10 步之前的作用？这就是信用分配问题，这是MARL 里最头疼的实际难题之一。

集中式与分布式

集中训练、分布式执行（CTDE）

这是目前最常见的模式。训练时智能体可以用额外信息，比如全局状态或其他智能体的动作。执行时每个智能体只根据自己的局部观测行动。

这样的好处是，既有集中学习的稳定性，又不需要在运行时获取不现实的全局信息。

完全分布式学习

智能体只从局部经验学习。这个听起来是对的，而且简单任务也能用。但实际中往往不够稳定，合作任务尤其如此。

算法总览

合作性基于价值的方法：Independent Q-Learning（IQL）是最简单的基线，容易实现但通常不稳定；VDN 和 QMIX 通过混合各智能体的价值来学全局团队价值，合作处理得更好。

策略梯度和 Actor-Critic 方法：MADDPG 用集中式 Critic 配分布式 Actor，概念上是很好的切入点；MAPPO 在很多合作任务里是靠谱的默认选择。

自我对弈（Self-play）：和自己不同版本对打来建立泛化的策略。思路简单粗暴效果也很好。

用 Python 从零搭一个小 MARL 环境

来做个玩具游戏：两个智能体必须协调。经典设定——两者选同一个动作才有奖励。每个智能体选 0 或 1，动作一致拿 +1，不一致拿 0。

我们这里刻意设计得简单，这样方便我们聚焦在 MARL 机制本身。

 import random  
from collections import defaultdict  

class CoordinationGame:  
    def step(self, a0, a1):  
        reward = 1 if a0 == a1 else 0  
        done = True  # single-step episode  
         return reward, done

接下来是最小化的 Independent Q-Learning 设置，每个智能体学自己的 Q 表。这里没有状态，Q 只取决于动作。

 def epsilon_greedy(Q, eps=0.1):  
    if random.random() < eps:  
        return random.choice([0, 1])  
    return 0 if Q[0] >= Q[1] else 1  

Q0 = defaultdict(float)  # Q0[action]  
Q1 = defaultdict(float)  # Q1[action]  

alpha = 0.1  
eps = 0.2  
env = CoordinationGame()  

for episode in range(5000):  
    a0 = epsilon_greedy(Q0, eps)  
    a1 = epsilon_greedy(Q1, eps)  

    r, done = env.step(a0, a1)  

    # One-step update (no next-state)  
    Q0[a0] += alpha * (r - Q0[a0])  
    Q1[a1] += alpha * (r - Q1[a1])  

# Inspect learned preferences  
print("Agent0 Q:", dict(Q0))  
 print("Agent1 Q:", dict(Q1))

多数运行会收敛到两种"惯例"之一：两者都学会总是选 0，或者都学会总是选 1。

这就是协调从学习中涌现出来的样子。虽然小但和大型合作 MARL 系统里依赖的模式是同一类东西。

这个玩具例子太友好了。难一点的任务里，IQL 常常变得不稳定，因为每个智能体都在追一个移动靶。

让例子更"MARL"一点

常见技巧是加共享团队奖励，同时保证足够长的探索期来发现协调，下面是一个带衰减 epsilon 的训练循环：

 Q0 = defaultdict(float)  
Q1 = defaultdict(float)  

alpha = 0.1  
eps = 0.9  
eps_decay = 0.999  
eps_min = 0.05  

env = CoordinationGame()  

for episode in range(20000):  
    a0 = epsilon_greedy(Q0, eps)  
    a1 = epsilon_greedy(Q1, eps)  

    r, _ = env.step(a0, a1)  

    Q0[a0] += alpha * (r - Q0[a0])  
    Q1[a1] += alpha * (r - Q1[a1])  

    eps = max(eps_min, eps * eps_decay)  

print("Agent0 Q:", dict(Q0))  
 print("Agent1 Q:", dict(Q1))

这当然不会解决 MARL，但它演示了一个真实原则：早期探索帮助智能体"找到"一个稳定的协调惯例。

总结

一旦解决了单步协调问题，还会有三个问题会反复出现：

虚假学习信号：智能体可能觉得"是自己动作导致了奖励"，实际上是另一个智能体的动作起了作用。

糟糕的均衡陷阱：在竞争性游戏里，智能体可能卡在稳定但不强的弱策略上。

规模爆炸：多智能体的状态和动作空间膨胀很快，需要更好的函数逼近（神经网络）、更好的训练方案（CTDE），通常还需要更讲究的环境设计。

应对这些问题没有万能解法，但有一些经过验证的思路。针对虚假学习信号，可以用 CTDE 架构让 Critic 看到全局信息，帮助每个智能体更准确地评估自己动作的贡献。均衡陷阱的问题，自我对弈加上一定的探索机制能帮智能体跳出局部最优。规模问题则需要参数共享、注意力机制等技术来降低复杂度。

实际项目中，建议先在概念上理解集中式 Critic 的工作原理，不用急着写完整的深度 RL 代码。这一步会改变你思考可观测性和稳定性的方式，后面上手具体算法会顺畅很多。

作者：Syntal

当半导体一级市场回归理性，资本不再为单纯的“算力堆叠”买单，而是开始寻找真正能“落地”的技术。1 月 15 日，硅谷通用神经网络处理器（GPNPU）IP 厂商 Quadric 正式宣布完成 3000 万美元（约合人民币 2.17 亿元） 的 C 轮融资。本轮融资由 BEENEXT 管理的 ACCELERATE 基金领投，老股东 Uncork Capital、Pear VC 持续加注，新投资方阵容则颇具产业背景，包括 万向美国（Wanxiang America）、NSITEXE（丰田 / 电装生态圈）、MegaChips（日本大型无厂半导体公司）以及 Gentree 和 Volta 等。

在端侧大模型（Edge LLM） 加速渗透的今天，Quadric 试图用一套“软件优先”的 GPNPU 架构，打破传统 NPU“不仅难用，还没法改”的僵局。

1. 营收翻倍，不仅是“讲故事”

芯片圈现在的融资环境大家有目共睹，光靠 PPT 已经很难从 VC 口袋里掏出钱了。Quadric 这轮融资之所以能成，核心在于其商业化进程的 “实锤”。根据官方通稿披露的数据，Quadric 在过去一年交出了一份相当硬核的成绩单：2025 年的 IP 许可与特许权使用费（Royalty）营收较 2024 年实现了三倍增长。截至目前，其累计融资总额已超过 7200 万美元。Quadric CEO Veerbhan Kheterpal 在谈及此次融资时底气十足地表示：“在这个充满挑战的融资环境中，能够超额认购完成 C 轮，直接证明了市场对我们‘代码优先’（Code-First）推理架构的认可。”

2. 拿下关键 Design Wins：Tier IV 与亚洲大厂

除了营收数据，Quadric 此次还披露了两个极具含金量的 Design Wins（设计中标），直接验证了其技术在高端市场的落地能力：日本自动驾驶软件巨头 Tier IV作为开源自动驾驶软件 Autoware 的维护者，Tier IV 将在其下一代 AD / ADAS 计算平台中集成 Quadric 的 Chimera GPNPU 核心。这对实时性要求极高的车规级市场来说，是一个重要的风向标。一家亚洲顶级芯片供应商（Top-Tier Asian Silicon Vendor）虽然官方未点名，但这大概率指向了本轮的战略投资方之一（如 MegaChips 等）。该厂商将在其边缘 SoC 中集成 Quadric IP，专门用于运行端侧大语言模型（Edge LLMs）。这标志着 Quadric 已经杀入了最火热的 AI PC / AI Phone 或边缘服务器赛道。

3. 为什么要“革 NPU 的命”？

目前市面上的边缘 SoC 设计，普遍还在用“CPU + DSP + NPU”的异构堆叠模式。看着分工明确，实则痛点不少：数据要在不同核心的内存间搬来搬去，功耗白白浪费；而且 NPU 往往是“黑盒”，开发门槛高，一旦算法变了（比如从 CNN 切到 Transformer），硬件可能就废了。

Quadric 搞的这个 Chimera™ GPNPU，核心逻辑就是做 减法与融合。软件定义的硬件：Quadric 强调 “C++ driven”，开发者不需要学习晦涩的专用语言，直接用 C++ 就能控制硬件。混合流水线：它在一个处理器里同时处理矩阵计算（AI 推理）和控制逻辑（C++ 代码）。这意味着，你不需要把数据在 CPU 和 NPU 之间来回倒腾，直接在 GPNPU 内部“一条龙”处理完。抗老化能力：对于汽车这种生命周期长达 10 年的产品，算法年年变。GPNPU 的可编程性，意味着车厂可以通过软件更新来支持未来的新模型，而不用更换硬件。

4. 行业观察：资本向“应用侧”转移

边缘计算社区观察到，本轮投资方的构成非常耐人寻味。除了财务投资人，NSITEXE（电装关联企业）、MegaChips 和万向美国 的入局，清晰地表明了产业链上下游的态度：汽车电子和工业自动化领域，急需一种更灵活、更高效的计算架构。随着 Transformer 架构日新月异，端侧大模型层出不穷，专用加速器（ASIC）“上市即落伍”的风险越来越大。Quadric 这种“通用性 + 高性能”的中间路线，或许正是解决当前边缘 AI 碎片化难题的一剂良药。据悉，这笔 3000 万美元 将重点用于扩大全球工程团队，并进一步打磨其软件开发工具链（SDK），毕竟对于 IP 厂商来说，生态好不好用，直接决定了客户愿不愿意用。

参考材料
Quadric Press Release: Quadric Raises $30M Series C Funding to Accelerate On-Device AIhttps://quadric.ai/press-release/quadric-raises-30m-series-c-...

Pulse 2.0: Quadric: $30 Million Series C Closed As Design Wins Acceleratehttps://pulse2.com/quadric-30-million-series-c/

Design & Reuse: Quadric Raises $30M Series C Financing for GPNPU Architecturehttps://www.design-reuse.com/news/56829/quadric-series-c-fina...

基于 YOLOv8 的桥梁病害（八类缺陷、病害高精度）自动检测 [目标检测完整源码]

一、背景与问题：桥梁检测为什么需要 AI？

桥梁作为城市与交通网络中的关键基础设施，其服役周期长、受力复杂、环境影响显著。随着时间推移，桥梁结构不可避免地会出现裂缝扩展、混凝土退化、钢筋腐蚀、潮湿渗水等病害问题。若不能及时发现并处理，轻则影响通行安全，重则引发结构性风险。

传统桥梁检测主要依赖人工目测或人工+仪器结合的方式，普遍存在以下痛点：

  • 检测效率低，难以覆盖大规模桥梁资产
  • 对检测人员经验依赖强，结果主观性高
  • 数据难以结构化，不利于长期健康评估

在此背景下，基于计算机视觉的自动化桥梁病害检测逐渐成为智能运维的重要发展方向。
在这里插入图片描述

源码下载与效果演示

哔哩哔哩视频下方观看：

https://www.bilibili.com/video/BV1m8g8z6Ejp/

在这里插入图片描述
包含：

📦完整项目源码

📦 预训练模型权重

🗂️ 数据集地址（含标注脚本

二、整体解决方案概述

本文介绍的一套桥梁病害检测系统，采用 YOLOv8 目标检测模型 作为核心算法，并结合 PyQt5 桌面端可视化工具，构建了一条从模型训练到工程应用的完整技术链路。

系统核心能力概览

  • 支持 8 类典型桥梁缺陷与病害识别
  • 覆盖 图片、批量图片、视频、摄像头 等多种输入形式
  • 提供 图形化操作界面，降低使用门槛
  • 支持模型再训练与工程级部署

该系统既可作为科研与教学案例，也可直接用于工程检测与巡检辅助。

在这里插入图片描述
在这里插入图片描述

三、检测目标设计：让模型“看懂”桥梁问题

在桥梁结构表面，病害往往呈现出尺度小、纹理细、形态多样的特点。针对工程实践需求，系统定义了以下八类检测目标：

  1. 裂缝
  2. 收缩裂缝
  3. 底层收缩裂缝
  4. 混凝土退化
  5. 混凝土空洞
  6. 腐蚀
  7. 潮湿
  8. 路面劣化

这些类别基本覆盖了常见桥梁表观病害类型，为后续健康评估与维修决策提供了结构化输入。

在这里插入图片描述

四、为什么选择 YOLOv8？

YOLOv8 是 Ultralytics 推出的新一代实时目标检测模型，在工程实践中表现出明显优势：

  • Anchor-Free 架构
    对细长裂缝、小尺度缺陷更友好，减少人为先验约束。
  • 推理速度快
    能够满足视频流与实时检测场景需求。
  • 训练与部署流程成熟
    模型配置灵活，支持快速复现与迁移学习。
  • 多任务扩展能力强
    为后续引入分割、姿态或多模态任务奠定基础。

在桥梁病害这类“复杂背景 + 小目标”的场景中，YOLOv8 在精度与速度之间取得了良好平衡。

在这里插入图片描述

五、数据集构建与训练流程

1. 数据组织方式

系统采用标准 YOLO 数据格式，清晰划分训练集与验证集，便于模型迭代：

dataset/
├── images/
│   ├── train/
│   └── val/
├── labels/
│   ├── train/
│   └── val/

每张图像均配有对应标注文件，记录目标类别及归一化边界框信息。

2. 训练与评估策略

模型训练过程中，重点关注以下指标：

  • box_loss：定位精度
  • cls_loss：类别区分能力
  • mAP@0.5：整体检测性能

当模型在验证集上达到稳定收敛并取得较高 mAP 后，即可进入部署与应用阶段。

在这里插入图片描述

六、推理与可视化系统实现

1. 模型推理逻辑

系统基于 PyTorch 推理接口加载训练完成的 YOLOv8 模型，对输入图像或视频逐帧执行检测，输出包括：

  • 缺陷类别
  • 置信度
  • 边界框坐标

这些信息可进一步用于统计分析或风险评估。

2. PyQt5 图形化界面优势

通过 PyQt5 封装推理流程，系统实现了：

  • 图像/视频/摄像头一键加载
  • 检测结果实时展示
  • 自动保存检测图片与日志
  • 无需命令行操作的工程化体验

这使得系统不仅面向算法工程师，也适用于检测人员与工程管理人员使用。

在这里插入图片描述

七、典型应用场景

该系统在多个实际场景中具备应用潜力：

  • 桥梁日常巡检与快速筛查
  • 历史病害数据对比与趋势分析
  • 科研机构桥梁健康监测研究
  • 高校土木与智能建造课程教学

通过持续积累检测结果，还可进一步构建桥梁全生命周期健康管理体系。

八、未来扩展方向

在当前系统基础上，可进一步拓展以下能力：

  • 引入 图像分割模型，实现裂缝精细化测量
  • 融合 红外或多光谱数据，增强隐蔽病害识别
  • 部署至 边缘计算设备或无人机平台
  • 结合时序数据，分析病害演化趋势

在这里插入图片描述

结语

本文介绍了一套面向实际工程应用的 桥梁病害智能检测系统，通过 YOLOv8 高性能目标检测模型与 PyQt5 可视化工具的结合，实现了从数据、模型到应用的完整闭环。

该方案在提升检测效率、降低人工成本、增强结果一致性方面具有显著优势，为桥梁智能巡检与结构健康监测提供了一条可落地、可扩展的技术路径，也为工业视觉在基础设施领域的应用提供了有价值的实践参考。

本文从实际工程应用角度出发，系统梳理了一套基于深度学习目标检测模型的智能识别解决方案，完整覆盖了数据准备、模型训练、推理验证以及应用系统集成等关键环节。通过将算法能力与可视化应用相结合，实现了从模型效果验证到业务可用系统落地的转化，体现了人工智能技术在真实场景中的工程价值。整体方案结构清晰、技术路线成熟，既具备较强的复用性与扩展性，也为相关领域的智能化升级提供了可参考、可落地的实现范式。

基于 YOLOv8 的多车型交通车辆实时检测识别项目 [目标检测完整源码]

一、背景与问题引入

在智慧交通体系中，“看得清、分得准、跑得快”始终是视觉感知系统的核心诉求。传统基于规则或特征工程的方法，在复杂道路环境、密集车流、多车型混行的场景下，往往存在鲁棒性不足、维护成本高的问题。

随着深度学习目标检测模型的成熟，YOLO 系列逐渐成为交通视觉领域的主流方案。其中，YOLOv8 以其 Anchor-Free 架构、更优的速度–精度平衡以及完善的工程生态，非常适合用于实时车辆检测与系统级落地。

本文将从工程实践角度，完整介绍一个 支持 12 类常见交通车辆、具备图形化界面、可直接部署运行 的实时检测系统设计与实现思路。
在这里插入图片描述

源码下载与效果演示

哔哩哔哩视频下方观看：

https://www.bilibili.com/video/BV1dwg5zCEkL/

在这里插入图片描述

包含：

📦完整项目源码

📦 预训练模型权重

🗂️ 数据集地址（含标注脚本

二、系统整体架构设计

该系统并非仅停留在“模型推理”层面，而是以完整应用系统为目标进行设计，整体架构可划分为四个核心模块：

┌────────────┐
│  数据输入层 │  ← 图片 / 视频 / 摄像头 / 文件夹
└─────┬──────┘
      │
┌─────▼──────┐
│  检测引擎层 │  ← YOLOv8 Detection Model
└─────┬──────┘
      │
┌─────▼──────┐
│  结果处理层 │  ← NMS / 置信度过滤 / 可视化
└─────┬──────┘
      │
┌─────▼──────┐
│  UI 交互层  │  ← PyQt5 图形界面
└────────────┘

这种分层结构具备以下优势：

  • 算法与界面解耦，便于模型升级
  • 输入方式可扩展（无人机、RTSP流等）
  • 易于二次开发与功能叠加

在这里插入图片描述
在这里插入图片描述

三、核心功能能力解析

3.1 多源输入的统一检测流程

系统支持多种数据源接入，并统一走同一套检测逻辑：

  • 单张图片检测：适合离线分析与测试
  • 文件夹批量检测：用于数据清洗与标注校验
  • 视频文件检测：适配道路监控录像
  • 实时摄像头检测：满足在线监控需求

在底层实现上，通过对输入源进行抽象封装，确保模型推理逻辑保持一致，避免重复代码。

3.2 多车型精细化识别

本项目针对真实交通场景，定义了 12 类常见车辆类型，涵盖：

  • 轿车、SUV、面包车
  • 公交车、卡车、工程车辆
  • 特殊用途车辆等

YOLOv8 的 Anchor-Free 机制在多尺度目标（远距离小车 / 近景大车）检测中表现稳定，有效降低漏检与误检率。

3.3 PyQt5 图形化交互系统

为了降低系统使用门槛，引入 PyQt5 构建桌面级应用界面，核心设计原则是：

  • 无需编程经验即可使用
  • 操作路径清晰
  • 结果可视、可保存

主要功能包括：

  • 输入源选择与切换
  • 检测启动 / 停止控制
  • 实时画面显示（带检测框）
  • 检测结果自动保存

这使得模型能力真正转化为“可使用的软件”，而不仅是脚本级 Demo。

在这里插入图片描述

四、YOLOv8 模型训练与评估实践

4.1 数据集组织规范

项目采用标准 YOLO 数据格式，便于复用与迁移：

dataset/
├── images/
│   ├── train
│   └── val
└── labels/
    ├── train
    └── val

标签文件采用归一化坐标，兼容 Ultralytics 官方训练接口。

4.2 模型训练策略

训练阶段基于 YOLOv8 预训练权重进行微调，核心关注点包括：

  • box_loss：定位精度
  • cls_loss：车辆类别区分能力
  • dfl_loss：边框质量优化

在实际项目中，当 mAP@0.5 稳定超过 90%，即可满足工程部署需求。

4.3 推理与部署方式

模型推理通过 Ultralytics 官方 API 完成，具备如下特点：

  • 接口简洁，代码量少
  • 支持 CPU / GPU 自适应
  • 可导出 ONNX / TensorRT

结合 UI 层，可直接形成“即点即检”的完整工作流。

在这里插入图片描述

五、工程化落地与可扩展性

与单纯算法实验不同，该项目在工程层面具备以下实用特性：

  • 完整源码与权重打包
  • 一行命令启动系统
  • 训练 / 推理 / UI 全流程覆盖

在此基础上，可进一步拓展：

  • 车辆轨迹跟踪（DeepSORT / ByteTrack）
  • 车流量统计与时间序列分析
  • 多路摄像头并行检测
  • 智慧交通平台对接

在这里插入图片描述
在这里插入图片描述

六、总结与展望

本文从系统视角出发，完整介绍了一套 基于 YOLOv8 的多车型交通车辆实时检测平台 的设计与实现思路。通过将高性能目标检测模型与 PyQt5 图形界面深度融合，实现了从算法能力到实际可用系统的有效转化。

该项目不仅适用于智慧交通与城市监控场景，也非常适合作为：

  • 计算机视觉工程实战案例
  • AI 教学与科研实验平台
  • 工业级视觉系统原型

随着模型与算力的持续演进，交通视觉系统将不再只是“看见车辆”，而是逐步走向 理解交通、预测交通、优化交通。这一项目，正是迈向该目标的一个扎实起点。

在这里插入图片描述

本文从工程化与系统化的角度，介绍了一套基于 YOLOv8 的多车型交通车辆实时检测系统，完整覆盖了数据输入、模型训练、推理部署以及 PyQt5 图形化交互等关键环节。通过将高精度目标检测模型与易用的桌面端界面相结合，系统实现了对多种交通场景下车辆目标的稳定识别与实时展示，显著降低了深度学习技术在智慧交通领域的使用门槛。整体方案结构清晰、可扩展性强，不仅具备直接落地应用的工程价值，也为后续在车流统计、行为分析和交通智能决策等方向上的功能扩展提供了良好的技术基础。

作者：张红霞，青岛雨诺网络信息股份有限公司新零售产品部总监

综述

当前，医药零售企业已不再满足于“卖药”，而是致力于成为“健康管理伙伴”。通过构建以 CRM 会员系统为核心、线上与线下深度融合的全渠道服务架构，企业实现了服务时间与空间的无限延展、会员数据的集中管理与智能应用、营销活动的精准触达与高效转化。

作为医药零售的头部企业，重庆医药（集团）股份有限公司（简称“重药集团”）前身是成立于1950年的中国医药公司西南区公司，服务于医药全产业链，同时从事医药研发（MAH）、医疗器械生产，并投资参与医药工业。重药集团拥有全级次分、子公司200余家，正在从传统的配送商业企业向“互联网+医药”融合型现代医药企业转型。

随着CRM会员系统的使用时间拉长，其底层的传统数据库逐渐难以满足复杂数据的高效处理需求。面对海量交易和多维度行为数据的汇聚，重药集团CRM会员系统亟需采用具备高可用、强一致、可扩展特性的数据库。经过对比三款国产分布式数据库，重药集团选择OceanBase，最终实现系统稳定运行、复杂场景实时分析、查询效率提升25倍、存储空间节约60%。

此次重药集团CRM系统的数据库升级不仅提升了用户体验与品牌忠诚度，也为后续集团构建高性能、高可用的“集团级数字化运营中枢”提供了明确的业务需求与数据基础，构建可扩展、可复制、可监管的集团化运营体系。

医药零售商业模式变革，CRM系统实现全渠道协同

随着消费者行为的数字化转型和健康需求的持续升级，医药零售行业正经历深刻的商业模式变革。传统药店“有啥卖啥”的经营逻辑，逐步向“顾客需要什么”的逻辑转变，除了提供到店服务外，还支持线上服务，比如通过企业微信、公众号等渠道建立长期沟通机制。微商城代客下单、在线解答疑问等。

为构建以专业化服务为基础的顾客信任体系，医药企业建立了完整的会员服务体系——CRM 会员系统，以实现绑定多重会员信息、建立精准的会员标签画像，为会员提供更多的服务和营销。通过数据驱动决策的专业化服务能力提升来提高企业在行业内的竞争力，实现增收。

如图1 所示，CRM 会员系统可以实现线上、线下全渠道协同，支持会员档案统一、标签体系完善、自动触发机制、店员触达赋能、社群营销等关键功能。完成顾客到店/线上购药 → 完成交易 → 数据沉淀至 CRM → 触发服务与营销 → 二次消费 → 再次触达，实现“交易—服务—再交易”的正向循环。

图1 CRM会员系统实现线上、线下全渠道协同

为实现一体化管理需求，构建CRM会员系统

重药集团CRM会员系统的搭建背景，源自于其各子公司会员管理分散，系统缺乏统一规划，导致数据难沉淀、服务差异大、运营难复制，且缺乏实时监控，难以支撑决策。

为实现一体化管理，重药集团CRM会员系统分阶段建设。第一阶段完成会员营销平台的底座建设，打造集团化、标准化、数据化运营基础，核心目标如下。

  • 搭建集团化会员运营平台。现集团—子公司—门店的一体化管理，打通组织架构与业务链路，确保会员在不同层级和渠道中都能获得一致的服务体验。
  • 统一的会员运营服务体系。构建覆盖会员管理、营销活动、服务交付的标准化流程，减少分散运作带来的效率损耗，提升整体运营协同能力。
  • 可快速复制标准化服务能力。形成可落地的服务模板和运营机制，帮助新业务和子公司快速复制成熟经验，缩短建设周期，提升推广效率。
  • 实现经营数据统一分析。沉淀完整的数据资产，打破信息孤岛，实现对会员、门店、区域的多维度统一分析，为企业战略决策与合规审计提供有力支撑。

在上述目标指导下，我们做了三个核心举措：

  • 联合集团会员中心，推进一体化进程。覆盖集团全品牌及线上会员，实现线上和线下会员统一运营和全域价值管理（见图2）。
  • 构建多层级组织架构视角报表。支持集团、品牌、门店的权限管理，权限灵活配置，便于集团总部进行跨品牌的数据报表分析。
  • 集团统一下达任务。集团可向各品牌下发销售任务、患者教育活动任务及拉新任务，实现集团任务统一管理与执行监督。

图2 集团会员同意运营架构

我们计划以集团内个别区域公司为试点，试行以上举措，若成功，则进行全面推广。推广成功后，重药集团会员运营平台将实现从“单一业务系统”向“集团级数字化运营中枢”演进。依托统一的技术底座与标准化流程，平台不仅实现对多家子公司、多个品牌的全面接入，更构建起可扩展、可复制、可监管的集团化运营体系。

此外，为实现全渠道会员统一运营，平台通过整合分散在各系统中的数据，构建统一、动态、多维度的会员标签画像体系（见图3），支撑精细化运营决策。

图3 多维度会员标签画像体系

通过会员系统精准化的服务来反哺我们的线上和线下的会员营销和服务，实现线上精准营销、个性化推荐、好物推送、会员关怀，线下关联用药建议、慢病管理提醒、店员主动触达等，提升营销转化率，增强客户粘性，实现“数据驱动服务”的闭环。

精细化会员服务，带来海量数据的查询、存储难题

然而，随着集团化会员运营平台的推进，精细化服务模式持续深化，导致用户数据规模呈指数级增长，显著提升了系统的查询与存储复杂性。

  • 会员量：突破千万级，覆盖多个品牌及区域公司。
  • 交易数据量：达到亿级，涵盖线上线下购药、用券、复购等行为。
  • 用户行为类数据：包括商品浏览、搜索、加购等，总量亦达千万级以上。

这些数据来源于线上商城、私域平台、公众号等多个渠道，经标签体系整合后，用于构建立体化的会员画像，支撑精准营销与双向引流。

但数据体量大、类型多样、实时性要求高，对数据库的高并发读写能力、存储扩展性与查询性能提出严峻考验。面对千万级会员、亿级交易和多维度行为数据的汇聚，传统数据库难以满足高效处理需求，亟需采用具备高可用、强一致、可扩展特性的分布式数据库系统进行支撑。

CRM会员系统数据库升级，应对千万级数据处理难题

传统数据库的技术瓶颈制约业务发展

重药集团会员服务平台的规模化发展，使系统数据总量迅速增长至千万级、数十 TB 存储规模，传统关系型数据库在支撑精细化会员运营场景时，暴露出四大核心挑战。

  • 性能：百万大表 InnoDB 在高并发读写及复杂查询场景下，性能显著下降，无法满足业务需求，且有事务访问，无法通过拆分提升性能。同时，业务强依赖事务一致性，无法通过拆分提升性能。
  • 效率：核心归档由于业务需求，需要保留大量数据（数十 TB），会造成 DDL 周期长，延迟业务上线时间。
  • 成本：随着企业数量增多、历年数据累积，存储成本将越来越高。
  • 及时性：在各种场景下，对应数据处理的及时性需求越来越强。

上述技术挑战不乏真实业务案例。

例 1：某大型连锁店，以满足信创要求为前提进行性能保障

如今国家对信息技术应用创新（简称“信创”）的要求日益严格，特别是在国有企业中，系统必须符合相关标准才能上线。为了响应这一趋势，我们严格按照信创目录选择数据库产品，并对其进行了全面的业务场景适配与性能验证。

  • 数据准备：会员卡 9950万+、订单 1 亿 9980万+。
  • 验证数据库：OceanBase 数据库、某数据库1、某数据库2。
  • 验证功能：报表 14 项内容、高级筛选 8 项内容。
  • 参考标准：报表查询小于 20s、静态化数据小于 60s、高级筛选小于 15s。

测试结果如图4所示。OceanBase 在所有测试项中均显著优于其他两个国产数据库，在报表查询、高级筛选、静态化数据三个场景的性能表现都远超预期：

  • 报表查询小于 7s，平均提速 78 倍以上。
  • 高级筛选响应高级筛选小于 1s，速度提升 200–700 倍。
  • 静态化数据静态化数据小于 46s，效率提升 6.7 倍以上。

图4 OceanBase 数据库、某数据库1、某数据库2的测试结果

在严格遵循国家信创要求的前提下，OceanBase 不仅完全满足合规性准入条件，更在百亿级数据规模下的复杂查询与批量处理场景中展现出卓越性能，远超同类国产数据库产品。基于此，我们总结了三个数据库的性能数据，向客户提交了一份详细的分析报告。

例 2：连锁会员、订单交易数据量增长迅速，实时性查询瓶颈

除了信创需求外，客户对业务的实时性、及时性要求也越来越高。过去，企业主要依赖 BI 工具进行周期性报表生成，可容忍数小时甚至数天的数据延迟。然而，随着营销策略向精准触达和即时响应演进，业务人员需要在高价值客户识别、复购提醒触发、定向营销投放、健康知识推荐等场景中获取近实时数据支持。为实现精准服务，运营人员经常需要基于会员信息、会员属性、历史消费、会员标签、商品集合等多个维度进行多维组合筛选，由于关联维度过多，可能会出现查询失败、查询时间过长、范围跨度受限、复杂查询无法支持等问题，显然，这些问题是我们服务的客户无法接受的。

例 3：海量业务数据，系统可用性与存储成本难平衡

连锁医药企业会员体系的不断扩展和数字化运营的深入，必然会带来业务数据量的指数级增长，海量数据带来的高存储成本成为制约系统可持续发展的关键瓶颈之一。

  • 用户数据：累计会员数量突破千万级（>1000万）。
  • 交易流水：日均订单量达百万级，历史累计超过亿级（>1亿条）。
  • 用户行为数据：包括浏览、搜索、加购、收藏等行为记录，总量亦达千万级以上。

单个业务数据库实例空间占用已达到 N 个 TB 级别，且随时间推移呈线性增长。随着客户数量增加和业务持续扩张，业务数据库实例的空间占用迅速攀升至数十TB甚至上百TB级别，这些数据不仅用于支撑日常业务运行，还需长期保留以满足合规审计、精准营销、客户画像构建等需求。企业面临保障性能与可用性的前提下降低存储成本的难题。

因此，引入具备高效数据压缩、自动冷热分层、弹性扩展能力的新一代分布式数据库，是实现“数据价值最大化、存储成本最小化”的必然选择。

数据库技术引入，支撑海量交易数据的高效处理

综合业务需求与传统数据库的技术瓶颈考虑，我们需要替换传统数据库，升级为高性能、稳定性强、成本低、 HTAP 一体化的分布式数据库。

自 2023 年起，我们开始系统性地评估并引入 OceanBase，历经技术认知、多轮测试、工具链验证、SaaS 级试点上线等关键阶段（见图5），最终成功应用于重药集团会员管理平台。

图5 上线OceanBase的关键阶段

1.技术引入与评估阶段（2023年）

测试重点包括三部分。

其一，日常抖动测试。在对 OceanBase 初期测试时，我们首先进行了业务压力测试。低峰期业务配合100%模拟线上流量直接发压，高达4轮的压力测试，每次持续 3 小时以上。

其二，扩容/缩容测试。在业务流量低时进行相关操作验证。为了验证是否存在小概率事件，进行了为期一周的脚本自动扩、缩容操作以观察其稳定性。

其三，Add Index 测试。与扩容、缩容相仿，基于业务流量对1T大表进行多达几十次的add index操作，观察延迟情况。

2.SaaS 产品试点上线（2023 年 12 月）

在完成全面技术验证后，我司将 OceanBase 应用于内部 SaaS 类产品中，作为首个生产级试点场景。该阶段实现了：

  • 数据库稳定运行于真实业务环境中。
  • 验证了迁移、运维、监控等全生命周期管理能力。
  • 积累了宝贵的实战经验，为后续客户项目打下坚实基础。

3.重药集团项目正式上线（2025 年 4 月）

基于前期充分验证与试点成果，我们于 2025 年 4 月正式启动重药集团会员管理平台项目，OceanBase 正式投入生产使用，支撑海量交易数据的高效处理。

会员服务平台“新面貌”：稳定、高性能、低成本

构建标准化数据链路，稳定、高效处理海量数据

目前，OceanBase 主要支撑重药集团会员服务平台的分析型业务场景，支撑高并发、多维度的会员数据查询、标签计算、报表生成及精准营销决策。其核心价值体现在：高效处理海量历史数据、支持复杂实时分析、保障查询性能与系统稳定性。

整个数据链路遵循“源系统 → CRM 中转清洗 → OceanBase 分析库”的三层架构，如图6所示。

图6 会员服务平台的数据分析链路

数据来源（源系统）包括POS 订单数据、各渠道会员信息、组织人员数据、会员标签数据、档案测量数据、全部商品主数据。

  • 中转与清洗层（CRM 系统）：所有原始数据通过定时抽取或实时接入方式进入 CRM 系统，进行统一的数据清洗、去重、合并与标准化处理。关键处理策略包括历史数据清洗、订单数据合并、积分逻辑处理、会员标签动态更新、消费行为计算、活跃度模型计算。
  • 目标存储与分析层（OceanBase 分析库）：清洗后的数据通过同步机制实时或定时写入 OceanBase 分析库；并分为原始数据表、静态化处理表、日表/月表、报表中间表。

通过构建“源数据 → CRM 清洗 → OceanBase 分析库”的标准化数据链路，实现了多源异构数据的统一整合、复杂分析场景的高性能响应、业务数据的长期留存与高效利用。

会员精准筛选复杂场景，查询效率提升 25.7 倍

在重药集团会员服务平台的实际运营中，多维度组合筛选（见图7）是支撑精细化营销与客户管理的核心功能。对于数据库而言，该功能是典型的复杂查询场景，用户需同时基于多个维度进行精确匹配，查询通常涉及多表关联、大量过滤条件和聚合计算，非常考验数据库的执行效率。我们通过开启 OceanBase 的列存模式（Columnar Storage），将原本传统数据库MySQL 的响应时间从 18 秒缩短至 0.7 秒，性能提升达 25.7 倍，满足业务对“实时圈选、即时触达”的严苛需求，显著提升了系统整体吞吐量与用户体验。

图7 会员服务平台多维度组合筛选

数据存储空间省 60%，有效降低存储成本压力

OceanBase 将全量数据划分为两个部分进行管理：一是增量数据（Memtable），即实时写入内存中的热数据，支持快速读写；二是基线数据（静态数据），即经过合并与持久化后的冷数据，存储于磁盘。

对于静态数据，OceanBase 采用高效的压缩算法，对列式存储的数据进行深度压缩，显著减少磁盘 I/O 和存储开销。例如，当原始数据总量为 4TB 时，MySQL 需要完整保留所有数据，存储空间占用为 4TB；而 OceanBase 通过对静态数据进行高压缩处理，仅需 1.5TB 即可承载相同规模的数据。

在重药集团会员服务平台的实际部署中，OceanBase 通过其先进的列式存储引擎与高效压缩算法，显著降低了数据存储空间占用，在同等业务数据规模下实现了 60% 以上的存储空间节约，有效缓解了海量数据带来的存储成本压力。

面向未来，持续推进 OceanBase 的深度集成与价值释放

随着 OceanBase 在重药集团会员服务平台的成功落地，我们对其在更广泛业务领域和客户群体中的应用充满信心。面向 2026 年及未来，我们将围绕场景拓展、客户推广、技术融合与产品适配四大方向，持续推进 OceanBase 的深度集成与价值释放。

应用于更多业务场景与产品

当前，OceanBase 已稳定支撑重药集团会员管理平台的复杂分析型业务（如精准筛选、标签计算、报表生成）。订单处理中心和运营诊断产品也在生产环境开始使用OceanBase，下一步，我们将推动其全面融入日常运营服务场景，包括：实时会员服务、营销活动执行、AI 智能推荐等业务场景。

另外，我们将逐步将 OceanBase 适配至更多内部产品，包括商品主数据管理、患者健康管理平台、智能补货与供应链协同系统，构建以 OceanBase 为核心的统一、弹性、智能的企业级数据基础设施。

向业内客户推荐

在国家信创政策与企业降本增效双重驱动下，我们已将 OceanBase 作为高并发、大数据量、强一致性要求场景下的首选数据库，并向行业客户积极推广。截至目前，已在以下大型医药企业成功落地：扬子江药业集团、鹭燕医学、重药集团、上海医药、国大药房。未来，我们将继续优先推荐 OceanBase 作为会员服务、订单中心等关键系统的数据库底座，助力更多企业完成安全、高效、低成本的国产化替代。

交流开发，沉淀运维经验

为持续提升团队与客户的 OceanBase 应用能力，我们计划定期组织专题培训、参与社区技术沙龙、共建问题解决机制、定期组织数据库培训及实战分享会议，探讨并解决遇到的问题，争取打造一支“懂业务、精技术、能落地”的复合型数据库应用团队。

未来，我们将携手更多合作伙伴，共同探索“数据库 + AI + 行业场景”的创新路径，为医药健康行业的高质量发展注入新动能。

使用 springboot 集成 micrometer 实现自定义 prometheus 指标。
假如在多实例的商城系统中存在一个用于统计商品查看次数的指标，名为 item_view_count ，label：item_id 、instance_id 。
当服务重启时，按照 micrometer 的默认行为，这个指标会被置为 0 。

对于这个行为我想到了两种方案。

  1. 将这个值持久化，并且在第一次创建指标时加载。
  2. 服务重启后使用新的 instance_id ，这样在做 sum 统计时不会被重置影响

各位都是如何处理这个问题呢？

最近做了个小项目：Pocket Shell ，一个移动端友好的 Web 终端。
说实话，它和手机上的 SSH 客户端功能上差不多，并没有什么“颠覆性”。

而且体验比起 Termius 还是差很多

可能适合的人：

  • 不想装客户端、临时在手机浏览器里连一下服务器
  • 想要一个“轻量、可自部署”的网页版终端

主要特性：

  • 移动端优化 UI,输入等
  • 虚拟键盘（ Ctrl/Alt/Tab/方向键）
  • 长按方向键手势输入
  • 单二进制部署（前端内嵌）
  • 会话状态恢复

Pocket Shell

项目地址：
https://github.com/zzjcool/pocket-shell

议题分享： When ASUS IoT Devices Play Hide-and-Seek with Security


Writeup

, ,

…

前言

这个议题于2025年5月8日在新加坡举办的Off-By-One Conference上分享。

大致的议题介绍：

Asus, as a leading consumer electronics manufacturer, offers a wide range of IoT devices, but its router products have historically faced significant challenges in security, including critical vulnerabilities such as the cfgserver issue in the Tianfu Cup and the httpd authentication bypass vulnerability. These incidents reveal potential shortcomings in the security design of ASUS router products.

This presentation will provide a systematic attack surface analysis of ASUS router devices, focusing on a review of some key historical vulnerabilities and a deep dive into the lighttpd component within the aicloud service to identify potential security risks. Our analysis will cover multiple vulnerabilities and their associated remote code execution (RCE) vulnerability chains, assess their impact scope and potential consequences, and offer recommendations for future improvements.

……

公开 slide

这里公开 slide ， 感兴趣的同学可以自行阅读

CVE-2025-36463 Sudo_chroot Elevation of Privilege 漏洞分析


漏洞分析

,

CVE-2025-32023 Redis 漏洞分析


漏洞分析

智能体对话正在告别“纯文本时代”！近日，腾讯云智能体开发平台（ADP）重磅上线国内首个“AI 原生 Widget”，面向企业客户提供“富交互任务交付”能力，只需自然语言描述，就能实时生成表单、按钮等交互组件。该能力还同步在腾讯元器（一站式 AI 智能体创作与分发平台）生态侧落地，支持创作者一键生成交互卡片。

 

值得一提的是，这一功能还兼容 OpenAI 生态的 Widget 接入规范，外部 Widget 可依据标准协议直接导入复用，进一步拓展智能体能力边界与生态扩展空间。

 

“AI 原生 Widget”是一种面向智能体任务交付的“富交互组件形态”，模型输出结构化描述（JSON Schema)，平台自动渲染为可操作的表单、按钮，并将用户交互结果回传智能体，实现任务闭环执行。

自然语言秒级生成智能体交互组件

在传统的大模型对话中，文本输出是主要形式。海量的文字堆砌，不仅抬高理解成本，而且完成单一任务需要多轮来回沟通，效率低且体验不佳。Widget 作为可嵌入式的自定义展示组件，能在智能体对话流中，灵活融入图表、表单、按钮等“富交互”模块，将对话界面升级为沉浸式任务平台，引导用户按步骤操作，大幅提升信息传递与任务执行效率。

 

当前国内的智能体平台构建 Widget 时，普遍采用传统“拖拉拽式低代码+手动配置字段/数据源映射关系”的方式，流程繁琐、耗时久、稳定性一般，难以适配高效开发的需求。针对这一痛点，腾讯云 ADP 推出的 AI 原生 Widget，提供了模版创建、代码创建、自然语言生成等多种方式，降低开发门槛。即使非专业前端开发者，只需用语言描述需求，或调用现成 Widget 模板，一分钟内就能够生成对应组件，真正实现“所想即所得”。

支持多种 Widget 开发模式

比如用户想要搭建一个“健身小助理”智能体，通过 AI 原生 Widget，输入提示词后，一键就能生成对应卡片。当用户询问“我要跑步”时，系统会弹出预设卡片，引导用户点选运动频率、强度等习惯信息，再根据用户的选择，快速生成“跑步训练周计划”卡片，包含每周运动安排、单次运动内容、时长和强度建议等核心信息。

从纯文本对话到富交互任务执行

虽然我并不认同“IDE 会在 2026 年消亡”这种绝对说法，但 Steve Yegge 和 Gene Kim 在分享中抛出的判断，依然值得认真对待：在他们的推演里，从 2026 年 1 月 1 日起，继续依赖传统 IDE 的工程师，会被更快拉开差距。

他们认为这不是“工具升级”，而是“生产方式换代”：工程师的竞争力，越来越取决于你能否用好新一代 AI 开发方式，以及你愿不愿意为它付出真实成本——例如把每天的 token 开销重新定价到“接近日薪”的量级。

更刺耳的是，他们转述了 OpenAI 的 Andrew Glover 的一项观察：是否使用 Codex，可能会让同级别工程师之间的生产力差距被拉到 10 倍，这让管理层“非常惊慌”，“因为他们甚至可能不得不裁掉 50% 的工程师”。

其核心观点如下：

  • 现在的模型本质上是派一个潜水员下去，让它在代码库里四处探索，即使给它更大的氧气瓶，比如一百万 token，它仍会耗尽。正确做法应该是派多个角色，而不是寄希望于一个超大的单一潜水员。

  • 如果你在 2026 年 1 月 1 日后还在使用 IDE，那你就是一个“不好的工程师”。

  • 作为工程师，我每天花在 Token 上的费用应该与我的日薪相当，也就是每天 500 到 1000 美元。

  • Claude Code 走错了方向，他们造出一只巨大、耗能、高成本的“肌肉蚂蚁”。

 

Steve Yegge：今天的时间会过得很快，我将讨论明年(2026 年）开发工具的样貌。

 

现在所有人都迷恋 Claude Code，市面上大概有四十个竞争者，但 Claude Code 并不是答案，代码补全也不是。

 

虽然我每天使用它十四个小时，但开发者并未真正采纳。核心问题是这些工具使用难度过高，认知负担重，而且常常“撒谎、作弊、偷懒”。因此大多数开发者并不喜欢这样的工具。

 

我逐渐认识到，Claude Code 很像电钻或电锯。对于没有受过训练的人，它既能帮上忙，也能造成巨大损伤。未受训练的工程师使用 Claude Code，与一个新手拿着电锯差不多：既可能“切到脚”，也可能在熟练后完成极其精细的工作。然而软件世界无限广阔，而我们的野心也同样无限。

 

因此我想用一个类比说明：明年将是从“手持电锯、电钻”转向“数控机床（CNC）”的一年。CNC 在给定坐标后能自动执行极其精确的操作，这项技术我们已经使用了数百年，也不会在今年停止。

 

有人说“模型已经触顶了”，你的工程师们可能也这么说。即使如此，我们仍然等同于刚发现蒸汽和电力，还需要时间去驾驭它。现在的问题已经主要是工程问题。一年到一年半内，所有代码都将由大型自动化“磨床”式系统生成，工程师不再直接查看代码。这将是一个全新的世界，而我们正走向那里。

 

Gene 和我曾与 OpenAI 的 Andrew Glover 交流过，他说公司内部出现了明显的分化：部分工程师使用 Codex，而更多人没有用（拒绝使用工具的人主要是资深与 Staff 级工程师），产能差距巨大，导致绩效评估出现警报。两个同级别的工程师，其生产力可能相差十倍，这让管理层非常惊慌，因为他们甚至可能不得不裁掉 50% 的工程师。

 

这种情况类似瑞士机械表产业的衰落：经历数百年的辉煌，却被石英表在短短几年内颠覆，当时的工匠与今天坚持传统方式的资深工程师反应如出一辙。

 

未来需要的是一种全新的 UI，不是传统 IDE，而是新的 IDE。事实上，Replit 已经走得最前，他们的方向非常值得称赞。我们不该再继续追着旧形态、构建各种命令行界面。

 

更重要的是，Claude Code 及其竞争者都走错了方向——它们像在打造“世界上最大的蚂蚁”。

 

我的朋友、澳大利亚联邦银行的 Brendan Hopper 说得很好：自然界靠蚁群协作，而 Claude Code 却造出一只巨大、耗能、高成本的“肌肉蚂蚁”。无论是要分析整个代码库，还是只是问“我的 git ignore 还在吗”，它都调用最昂贵的模型。

于是我想到了“潜水员隐喻”：上下文窗口就像氧气瓶。现在的模型本质上是派一个潜水员下去，让它在代码库里四处探索，即使给它更大的氧气瓶，比如一百万 token，它仍会耗尽。正确做法应该是派多个角色：产品经理潜水员、开发潜水员、代码审查潜水员、测试潜水员、合并潜水员等，而不是寄希望于一个超大的单一潜水员。可没人这么做，大家都在造“大潜水员”。

 

未来的构建方式将是工程师熟悉的：任务分解、逐步细化、组件化、黑盒化，并依赖大量协作的智能体，而不是单一智能体。

但在此之前，我的建议还是：学习 Claude Code 来适应新方式，并放弃你的 IDE。如果你在明年 1 月 1 日后还在使用 IDE，那你就是一个“不好的工程师”。

Gene Kim：我研究高绩效技术组织已有 26 年，这段旅程始于我作为 Tripwire 的技术创始人。我们致力于研究那些表现卓越的技术组织——它们在项目交付、运维稳定性、安全合规方面都处于领先。我们想理解这些组织如何实现“从优秀到卓越”的转变，以及其他组织如何复制这些成果。

 

在这 26 年中我经历了许多意外，其中最大的意外之一，是这项研究最终将我带到了 DevOps 运动的中心。DevOps 改变了测试、运维、信息安全等角色的协作方式。我曾以为这会是我职业生涯中最激动人心的经历，直到我在今年 6 月首次与 Steve Yegge 见面。

 

我和 Steve 有许多共同点，其中之一就是对人工智能的热爱，以及都认为 AI 将从底层重塑软件开发的方式。我们相信，AI 对技术组织的影响，可能比十年前敏捷、云计算、CI/CD 和移动化所带来的变革大上百倍。而这些技术突破不仅会改变组织，也会重塑整个经济，让经济结构围绕更先进的生产方式重新排列。

 

过去一年半，我们观察了许多案例，让我们提前看到未来技术组织的雏形。有人可能熟悉 Adrian Cockcroft，他曾是 Netflix 的云架构师，主导了 2009 年将 Netflix 整个基础设施从自建机房迁移到云端。他在几个月前写道，2011 年有人提出“无运维（NoOps）”时，引发了基础设施和运维团队的强烈反对，但现在类似的事情再次发生，只不过这次可能叫“无开发（NoDev）”。如今看来，这似乎不再好笑。

 

我们从 Zapier 的分享中看到，支持团队能发版，设计师能发版，UX 设计也能直接发版。过去被开发者告知“排队、等一个季度、等一年、甚至永远等不到”的人，现在突然能够自己把功能“对话式地”写进生产环境。这不仅改变技术组织，也可能改变整个经济。

 

Steve 和我很幸运能看到部署方式的改变带来什么影响。十年前，我写了《The Phoenix Project（凤凰项目）》，讲述灾难性的部署流程。当时许多组织一年只发布一次版本，难以想象。后来我参与了 DevOps 状况研究，这项跨行业研究在 2013–2019 年间覆盖了 36,000 名受访者。我们发现，高绩效团队每天能多次部署，并能在一小时内完成一次发布。

 

在 2009 年，多次每日部署被视为鲁莽、不负责任甚至“不道德”，但如今却是常态。若想保持高可靠性、缩短平均修复时间，就必须更频繁地进行更小规模的部署。现在我们看到的案例表明，不再手写代码，而是运用新的方式进行开发，可能是一种价值更优的路径。

 

我们在《Vibe coding》一书中提出的定义是：只要不是靠双手在 IDE 里敲代码的方式，都可以称作“Vibe coding”。有些人还像在暗房里冲洗照片一样，依旧习惯在昏暗环境里手动输入代码。但 Anthropic 联合创始人兼 CEO Dario Amodei 给了我们更好的定义：Vibe coding 是由反复对话推动的、由 AI 生成代码的过程。他说这个词很美，能表达一种全新的开发方式，但也略带戏谑。不过对他们而言，这已经是“唯一的方式”。

 

这是编程语言领域的重要人物 Erik Meijer 博士，他参与过 Visual Basic、C#、Haskell，也在 Meta 推出了 Hack 编程语言，在一年内迁移了数百万行 PHP 代码，引入静态类型检查。他说，我们可能是最后一代手写代码的开发者，所以应该享受这一段最后的旅程。

 

还有一件事是这样的：去年 11 月开始，我一直在观察 Steve，他每天在编码代理上花掉几百美元。这在当时看起来非常奇怪。他不仅把各种月度订阅都用到了上限，实际上还远远超出了这些额度。

但现在我们听到的一种说法是：作为一名工程师，我的工作本身就应该要求我每天在 token 上的花费，和我的日薪大致相当。也就是说，大概每天 500 到 1000 美元。因为这些工具带来的，是一种机械优势和认知优势。作为工程师，我会挑战自己，去榨取这种投入所能带来的最大价值，把成果交付给真正重要的人。

在书中，我们把人们为何愿意这样做总结成一个缩写：FAAFO。

第一个 F 是 Faster（更快），但这是最表层的理由。

 

更重要的是 A-Ambitious（雄心），AI 让我们得以完成过去无法实现的雄心项目，把不可能的事情变得可能。在另一端，琐碎麻烦的小任务也几乎变成了零成本。我非常喜欢 Claude Code 团队中的一段采访，Katherine 说，以前客户问题会被放进 Jira 的待办项，在梳理会议中争论，一拖数周；而现在我们直接在当下修复，并在 30 分钟内发布。记录依然会做，但协调成本几乎完全消失了。也就是说，不可能的事情变得可能，麻烦的小事变得免费。

 

第二个 A 是 Able（能力），代表“更独立”，更能单独完成工作。这里有两类协调成本正被 AI 消除。第一类协调成本来自“等待”。如果你需要开发者或一个团队帮你做事，你必须沟通、协调、同步、排优先级、游说、升级……总之必须让他们“和你一样在乎这个问题”。而现在，依靠这些近乎奇迹般的新工具，你可以自己完成许多工作。第二类协调成本来自“理解”。即使别人愿意像你一样重视某件事，他们也无法读你的心。但我们发现，LLM 是惊人的“协作中介”。仅通过一个 LLM，你就能以 Markdown 文档的形式与不同职能顺畅协同。这当然不是最终形态，但它让高带宽的理解成为可能。因为要想实现共同的成果，就必须先有共同的目标与共同的理解。

 

第二个 F，是 Fun（好玩）。正如 Steve 所说，Vibe coding 具有成瘾性。我们见过两个人原本以为“写代码的黄金时代已经过去了”，结果却意外发现现实恰恰相反。我现在常常玩得太投入，不逼自己去睡就会写到凌晨两三点。它不是只有好的一面，但肯定比无聊、枯燥甚至痛苦要好得多。

 

O 是 Optionality（可选项）。我们非常重视“创造期权价值”。模块化之所以强大，也因为它能创造更高的期权价值。Vibe coding 能让你同时进行更多实验、更多尝试，因此它是极具经济价值的工具。Steve Yegge 说，对于已经经历“顿悟时刻”的人来说，本能反应往往是：如何让团队中所有人都获得与你现在同等的生产力？

 

下面我分享一些让我们看到未来形态的案例。

 

例如，Travelopia 的产品与技术负责人 Sree Balakrishna 的分享。Travelopia 是一家年营收 15 亿美元的旅行企业。他们曾用一个小团队，在 6 周内替换一套传统系统。按过去的方式，需要 8 人（6 个开发、1 个 UX、1 个产品负责人）；而现在，也许只需要一个开发与一个领域专家，正如 Kent Beck 所说，“一个有问题的人加一个能解决问题的人”。这种团队规模的变化会深刻影响组织未来的运作方式。

 

我最兴奋的案例来自 Dr. Tapabrata Pal。他在 Capital One 推动过 DevOps，如今在 Fidelity 负责一个关键应用，用来查询公司 2.5 万个应用中哪些受 Log4j 影响。过去他的团队总说重新做这个工具需要 5 个月，并需招聘前端工程师。

 

最终他自己花 5 天 Vibe coding 出了一个版本，并上线生产。他只是想证明：事情完全能做，而且可以更快完成。后续更戏剧的是：他为应用找维护者，资深工程师们都不愿接手，最后是团队中最年轻的工程师成为维护者，并正在快速成长。

 

与此同时，这个应用的内部用户数量增长了 10 倍，他也因此获得更多人手。这些变化是任何人都没预料到的。

 

再分享一个例子，我重返 Google Cloud 团队做的 Dora 研究，其中一项未进入正式报告的发现是关于“AI 信任度”。我们采用的信任定义是：你能多大程度预测对方（AI）的行为？越信任，就能给更大请求，用更少词语，减少反馈需求。结果显示：使用 AI 的时间越长，信任越高。那些说“我试了一下，它写代码很差”的人，多半只用了 1 小时。显然，AI 的掌握是可训练的技能，需要实践，而不是一次性体验。

 

因此，我们的责任之一，是帮助他人获得“顿悟时刻”，并协助他们不断练习，从而真正掌握这些强大的工具。

 

六周前，Steve 和我为领导者们做了一次 Vibe coding 工作坊。三小时内，完成率 100%，每个人都做出了成果。还有一位，他说自己 15 年没写代码了，却在短时间内做出一个自动帮自己抢 Southwest 登机位的工具（直到被反机器人系统封掉），你从他脸上的表情就能看到那种久违的创造力被重新点燃。

所以，当支持团队、领导者能编码并上线时，技术组织必然会重塑。

 

一个技术领导者说，当他告诉团队他写了一个应用，其中 6 万行代码都是 AI 写的，而他自己一行没看时，团队看他的眼神仿佛“希望他不存在”。

 

另一个例子，一些存在十年的遗留系统问题，团队集合资深工程师，用 AI 生成修复方案并提交 Pull Request。这次被接受了，而不像过去那样被污名为“AI 生成的低质量内容（AI slop）”。还有团队说，他们现在的代码提交速度如此之快，以至于每个代码仓库只能容纳一个工程师，否则合并冲突会让协作成本爆炸。

 

参考链接：

https://www.youtube.com/watch?v=cMSprbJ95jg&t=4206s

 

  1. 1
  2. ...
  3. 161
  4. 162
  5. 163
  6. 164
  7. 165
  8. 166
  9. 167
  10. ...
  11. 239