包含关键字 typecho 的文章

在全球数字化业务迅速发展的当下,企业普遍将大量资源投入到创建安全的在线门户、开发API接口以及构建云端服务当中,整体运行高度依赖加密技术和信任机制。然而,大部分企业未能正确认识其中潜藏的重大风险,即SSL/TLS证书过期。事实上,证书过期这一隐患并非空穴来风,全球范围内几乎每周都会因数字证书过期而引发一系列损失的运营事故。当保障数据传输安全的“数字护照”突然失效时,造成的负面影响远不止单一的技术问题,而是可能导致一系列动摇企业稳定发展的连锁反应。JoySSL市场部总监指出,SSL证书过期问题由于其“低发频率与高损失”的特点,已成为当今企业数字化运营中普遍存在的风险盲点,这也是为何主动管理证书生命周期已从运营建议,上升为确保业务持续性和维护品牌信誉的核心战略之一。

服务中断引发企业业务连续危机

SSL证书过期带来的首要风险,便是业务直接中断,这种影响既迅速又严重。当下的主流浏览器和操作系统对过期证书采取了严格的“不可接受”政策,用户访问被迫中断,意味着商业交易渠道与在线服务完全关闭。

更为隐秘而影响深远的问题来自后端服务,所有与数字证书关联的前端功能将因证书过期而出现系统性失效。用户可能遭遇无法登录、数据加载失败或交易操作受阻等问题。业务陷入停摆,导致收入减少、用户流失以及处理问题的额外成本增加。

证书过期有损品牌声誉与用户信任

线上服务的稳定性与专业程度,是品牌形象的重要展现。SSL证书过期会对企业形象造成直接伤害,使得企业专业信誉受损,深刻影响B端客户以及合作伙伴对企业的长期信任。

而信任的安全机制可能反向引发问题,过期警告传递公司不安全信号,造成信任缺失。为重新建立受损的信任,企业需要投入远超于证书维护的额外努力。

SSL失效丧失搜索引擎信任与青睐

搜索引擎对网站可用性与用户体验制定了严格的衡量标准,因证书失效导致网站长期无法正常访问,会被视为不良体验,进而对搜索结果的排名进行降序处理。在此期间,网站的自然流量损失难以避免。此外,用户因一次访问错误后,可能会降低对该网站的信任,从而减少后续访问的可能性。

证书自动化方案提供持续安全保障

面对证书过期引发的一系列负面效应,JoySSL技术负责人认为,建立全面化的证书资产监控机制,自动扫描并识别网络资产中所有被使用的SSL证书,统一纳入监控系统。通过全局视角掌握证书资产,消除因“影子证书”导致的管理盲点。智能预警与自动续期功能流水线,确保提醒信息及时传达。自动化续约与部署可从申请、验证、签发到部署自动完成全任务,无需人工操作,完全避免人为疏漏。

数字化安全是一种动态且持续的过程,专业的证书生命周期管理能力已成为评估企业IT治理成熟度及业务韧性的重要指标。通过投资这样的管理体系,可助力企业实现业务稳定在线、品牌可信度持续提升以及稳健发展。

访问链接: https://snapvee.com

SnapVee 由我 100% Vibe Coding 写的生产级 AI 工具,从 UI 设计、需求开发、测试、机器部署 -> 上线,总共代码行数约 4.3w 行,算上配置文件 5.7w 行。

3 天时间是怎么分配的

Day 1 ( 12h )

  • 产品定位 & MVP 功能清单
  • 落地页 + UI 主题定型
  • Auth / 数据库 Schema
  • 基础部署

Day 2 ( 14h )

  • 核心功能(下载 / 解析 / 队列)
  • 存储 & R2 / Redis 接入
  • Stripe 支付
  • SEO / i18n

Day 3 ( 10h )

  • BUG 修复 & 压测
  • 文案、价格、FAQ
  • 域名、合规、上线

模型选择

模型一定要用最好,最贵的模型,能省下很多事情!

Gemini3 Pro

Antigravity 刚出来的时候,就用了,免费额度很多。写一些 demo ,玩具是没有问题的,它在上下文理解和解决 BUG 能力上弱很多,而且还不是中文回复。

GLM4.7 模型

被朋友安利说 openCode 体验还不错。但实际体验过之后,你会发现一坨屎。比 Trea 稍微强上一点吧,执行任务时间长、流程长、会反复报错,反复执行。执行完之后的代码,无法一次运行,有各种 BUG 需要反复改。

Opus4.5

代码模型的神! Plan 模式和 Agent 模式都很舒服。运行速度快,理解能力强,任务规划强。最近又出了 Debug 模式。

能用最贵的代码模型,直接用!这里我用的 Opus4.5 ,成本如图。

UI 设计

我自己没有 UI 设计能力,但业界有很多设计模板网站和组件,这里我选择的是 framerreactbits

都有优秀的 UI 组件和 UI 模板,做出海网站,落地页面的整体架构都是类似的

  • Header (头部)

  • HeroSection (主视觉区)

  • FeatureIntroduction (功能介绍区)

  • PriceSection (价格区)

  • TestimonialsSection (用户评价)

  • FAQSection (答疑)

  • Footer (底部)

我的做法是确定网站的主题,这里选择的是黑紫主题。基于选择主题,再进行填充上面的内容,找到合适的组件。每个组件都可以自行风格话调教,你需要的动画,颜色,展示方式等。

得益于 opus 强大的记忆功能,我在后续的新增功能和 UI 改造,它都能记住网站是黑紫主题。也难怪 Tailwind 要裁员。

技术选型

  • Next.js 全栈型框架

  • UI 库 Shadcn

  • 数据库 Supabase

  • Redis Vercel

  • 邮箱注册 & 谷歌登录 auth.js

  • 邮件发送 resend

  • 存储服务 cloudflare r2

  • 机器 digitalocean

  • 前端部署 Vercel

  • 支付 Stripe

AI 时代下的模型物料训练对 TS 开发人员来说,非常友好!我个人认为 AI 模型能够达到前端资深甚至是专家级别的能力,只要你会使用。

纯 AI 实现一个视频编辑器,都没啥问题。

UI 库用的 Shadcn,不得不说 Shadcn 对 AI 来说简单快速,你要实现自己的一个组件库,很简单。

能用免费的,基本都是免费的,不免费的服务,也有试用额度,基本够用。

AI 模型对话

一句话:你得自己清楚你要实现什么功能,AI 模型才能跟你实现。

比如我这个产品要实现的功能有:

  • 注册登录
  • 落地页
  • 前端部署
  • 后端部署
  • 数据库建表
  • Redis 链接
  • SEO 优化
  • 其他等等

我个人认为,如果你对这些功能没有一个基本的认知。虽然 AI 能够完全帮你实现,但细节上就欠缺。举个例子,Google 登录,AI 帮你生成一份文档,你需要照着文档去操作,如果你不会,那你自然没法操作。

不过,这也让我惊叹于 Opus4.5 强大的编程能力,我让它实现一个 r2 存储服务。它居然可以自动帮我操作浏览器来实现

<video id="video" controls >
<source id="mov" src="https://oss.api-service.net.cn/1%E6%9C%8826%E6%97%A5-1.mov" type="video/mp4">
</video>

实现一个完整的功能,直接使用 Plan 模式,跟它对齐实现方案和要点。

这里我没有去追什么

  • .Claude 文件
  • Skills 文件夹
  • MCP 工具等

完完全全就是和它一起过 Plan 计划,对齐方案,然后 Build ,简简单单,它就能很好的理解,而且每次运行完的代码,是完全能够运行。而不是需要去修复 BUG 啥的。

所以,这里产生了大量的文档,都是跟它过 Plan 计划之后产生的。

我觉得好用的 AI 代码模型就是这样

AI 最容易出问题的 5 个点

  • OAuth / Google 登录(平台配置 ≠ 代码)

  • Stripe Webhook (时序 + 幂等)

  • SEO ( AI 不懂搜索引擎“潜规则”)

  • 边界状态(并发、异常、重试)

  • 成本估算( AI 不心疼钱)

虽然 AI 能写代码,能写文档配置,但不能替你承担线上事故,以及一些细节 AI 是不懂的。

总结:Vibe Coding 的前提,是你脑子里已经有架构。AI 时代下,对于程序员来说,最好是拥有架构的能力,变成一个 AI 架构师。

@playaround 上周这位朋友提到想提取小睡眠 APP 的音频,上周看了一下音频是加密的,基本上需要的数据都能拿到,因为上周没有设备,也没环境,今天装了大半天的环境,记录一下过程。

小睡眠音频有提取方案吗?: 小睡眠音频有提取方案吗?

注:破解软件属于违法行为,有偿服务可触犯刑法,本文仅为学习交流使用,文中涉及网址和核心解密的部分打码了。

过程

安卓 7.0 以上不再信任用户 CA 证书,导致新设备无法抓包,会提示网络错误等,部分 APP 配置了证书信任目录,即使低于安卓 7 仍然不可抓包,解决方案为把用户证书移动到系统证书目录(需 root),这里用的模拟器测试的。
image
反编译获取解密逻辑
通过网络请求获得 secret
此处的 secret 还不能直接用

image
通过加载 libbase.so 文件,调用 getkey 方法转换网络请求得到的 secret

image
抓包获取 secret

image
逆向 libbase.so 文件,获得 Java_com_psyone_brainmusic_utils_Base_GetKey 执行逻辑
image
返回的是 md5(secret+硬编码字符串)

image
验证 getkey 逻辑,完全正确

至此已获得解密所需的 secret 信息,key、iv 转换方法,对文件进行解密即可,后面不再赘述。

第二章 初识ESP32-P4

在本章中,我们将深入探索ESP32-P4这款备受瞩目的微控制器。我们将详细阐述其定义、核心资源、功能应用,以及如何选择适合您项目的ESP32-P4型号。通过本章的学习,您将全面了解ESP32-P4,为您的物联网项目选择合适的硬件平台奠定坚实基础。
本章分为如下几个小节:
2.1 ESP32-P4概述
2.2 ESP32-P4资源概述
2.3 ESP32-P4 命名规则
2.4 ESP32-P4 功能概述
2.5 ESP32-P4 启动流程

2.1 ESP32-P4概述

ESP32-P4是一款高性能MCU,支持超大片上内存,具有强大的图像和语音处理能力。该款MCU包含一个高性能(HP)系统和一个低功耗(LP)系统。其中HP系统由RISC-V双核处理器驱动,包含丰富的外设;LP系统由RISC-V单核处理器驱动,其外设针对低功耗应用进行了优化。下图为ESP32-P4芯片的功能框图。

图2.1.1 ESP32-P4功能框图
这里,笔者结合《ESP32-P4数据手册》中的“Product Overview”章节和上图的内容,简单归纳为5个部分。
1,架构和性能:ESP32-P4采用RISC-V 32位双核处理器(HP系统,400 MHz)和单核处理器(LP系统,40 MHz),具有高效的处理能力和性能。
2,存储:HP系统配备128 KB ROM和768 KB L2MEM,LP系统配备16 KB ROM和32 KB SRAM,支持8 KB的系统紧密耦合内存(TCM)和多个外部存储器接口。
3,外设:提供55个可编程GPIO和多个高级外设接口,包括JPEG解码器、视频编码器和多种数字接口与模拟接口,增强系统的灵活性和扩展性。
4,通信:同时支持多种通信协议,如USB、以太网、SPI、UART等,适用于物联网设备在智能家居和工业自动化等领域的广泛应用。
5,安全机制:具备安全启动、一次性写入安全性(eFuse OTP)和加密硬件加速器,确保数据和系统的安全性。
ESP32-P4是一款功能强大、性能丰富的物联网芯片,适用于各种物联网和音视频等应用场景。以上信息仅供参考,如需了解更多信息,请访问乐鑫公司官网查询相关资料。

2.2 ESP32-P4资源概述

ESP32-P4芯片为开发者提供了丰富的硬件资源和高灵活度的管脚功能,以适应多种物联网应用需求。本章节将介绍芯片的管脚布局以及各个IO管脚的功能,帮助开发者更好地理解如何高效利用这些资源。

2.2.1 管脚布局概览

下图为ESP32-P4管脚分布图。

图2.2.1.1 ESP32-P4管脚布局(俯视图)
上图中,ESP32-P4芯片总共有104个管脚,这些管脚可分为以下几类:
1,IO管脚:上图中的GPIO0~GPIO54,这些IO具有以下预设功能:
1)所有IO管脚均预设了HP IO MUX功能。
2)部分IO管脚预设了LP IO MUX功能。
3)部分IO管脚预设了模拟功能。
关于HP IO MUX、LP IO MUX和模拟功能的详细信息,将在后面的2.4.3小节中进行讲解。
2,专用数字管脚:仅可用于特定外设,如Flash、MIPI DSI、MIPI CSI等。这些管脚在上图中用橙色、红色、黄色和绿色框框标识。
3,特殊模拟管脚:专用于特殊模拟功能。上图78、79、99、100、103号管脚为特殊模拟管脚,这些特殊模拟管脚描述如下表所示。

图2.2.1.1 模拟管脚
上表展示了ESP32-P4芯片提供的一些特殊模拟管脚,用于特定的电源管理和时钟功能。其中,XTAL_N和XTAL_P需要连接一个40MHz晶振,以启动ESP32-P4芯片。CHIP_PU管脚用于芯片的使能控制,必须进行上拉才能启动芯片。EN_DCDC管脚用于控制同步降压DC-DC转换器。FB_DCDC管脚与内部参考电压进行比较,使控制器能够调整EN_DCDC管脚的占空比,以稳定输出电压。下图为DNESP32P4开发板中的同步降压DC-DC转换原理图。

图2.2.1.2 同步降压DC-DC转换
用户可以在其他平台上找到TLV62569 DC-DC电源芯片的数据手册。在手册的第9页中,有一个相关的转换公式,如下图所示。

图2.2.1.3 TLV62569 DC-DC电源芯片转换公式
在上图中,R1和R2分别对应原理图中的R9和R12。根据该公式计算,得出Vout为1.2V,从而为HP系统的内核提供所需电压。
4,电源管脚:为芯片和非电源管脚提供供电,如下表所示。

表2.2.1.2 电源管脚
通过控制VDDPST_1至VDDPST_6管脚,用户可以灵活调整各IO管脚的输出电压,以满足不同外设的电压需求。此外,VFB/VO1至VFB/VO4(图2.2.1.1中用黑色框框标识)管脚可以通过程序调节内部LDO的输出电压。通常情况下,我们将VFB/VO1至VFB/VO4连接到VDDPST_1至VDDPST_6的IO管理电源域,这样可以通过程序控制特定IO管脚的输出电压。为了让读者更好地理解这一功能,我们在DNESP32P4开发板上将VFB/VO3和连接至VDD_MIPI_DPHY以及将VFB/VO4和连接至VDDPST_1,这样便可以通过程序灵活控制MIPI和VDDPST_1电源域中IO的电压了。下图为可调LDO控制电源域原理图。

图2.2.1.4 通过VO3来控制MIPI电源域的IO
有些读者可能会有疑问?为什么需要这个功能呢?。其实很多器件不一定用到3.3V电压启动的,就比如我们正点原子的MIPI显示屏,驱动的IO电平必须是1.8V,所以我们可以通过可调LDO来控制这些不同电压驱动IO器件。

2.2.2 IO管脚功能说明

在上小节中,我们了解到ESP32-P4具有55个可编程IO管脚(GPIO0~GPIO54)。这些IO管脚具有三种预设功能,分别为全部IO管脚的IO MUX功能、部分IO管脚的LP IO MUX功能和部分IO管脚的模拟功能。如下表所示。

表2.2.2.1 部分外设管脚分配
从上表可知,ESP32-P4的IO MUX功能使得所有GPIO管脚能够灵活配置为多种数字信号接口,例如UART、I2S、I2C等,利用ESP32-P4的55个任意IO实现相关通信信号;与此同时,部分IO管脚的LP IO MUX功能专为低功耗应用设计,允许某些管脚在待机状态下保持活跃,以支持LP I2C和LP I2S等通信方式,从而有效节省能耗(如下图为LP系统管理的IO);此外,部分GPIO管脚具备模拟功能(如表中的ADC和TOUCH管脚,其他IO则不具备此功能),能够处理连续信号,直接与传感器和音频设备交互,拓展了ESP32-P4在多样化应用场景中的适用性。

图2.2.2.1 LP系统管理的IO
如果LP系统启动时,我们可以利用上图的IO管脚实现I2C、I2S等多种通信,因为这些信号可以灵活地映射到任意的IO管脚上。这种灵活性使得我们能够根据具体需求驱动相应的器件,从而更好地适应不同的应用场景和设计要求。
值得注意的是,某些外设必须使用特定的管脚实现,例如具有调试功能的JTAG、USB串口/JTAG、全速USB 2.0和EMAC等。如果在开发时未使用这些外设,我们可以利用IO MUX功能对特定通信接口进行映射。然而,这些映射可能会影响传输速率,因此笔者建议开发者首先采用ESP32-P4默认的复用功能IO设计原理图,然后再考虑其他IO映射功能,以确保系统性能的稳定性和可靠性。

2.3 ESP32-P4 命名规则

乐鑫P4系列包含两款芯片:ESP32-P4NRW16和ESP32-P4NRW32,它们之间的唯一差异在于PSRAM容量。以下是这两款芯片的命名规则图示。

图2.3.1 ESP32-P4 系列芯片命名规则
从上图可以看到, H/N表示FLASH温度(H:高温,N:常温);R表示内置PSRAM;W表示仅持1.8v 16-line PSRAM;x表示内置PSRAM大小(MB);。

2.4 ESP32-P4 功能概述

2.4.1 时钟树

ESP32-P4的时钟主要来源于振荡器(oscillator,OSC)、 RC振荡电路和PLL时钟生成电路。上述时钟源产生的时钟经时钟分频器或时钟选择器等时钟模块的处理,使得大部分功能模块可以根据不同功耗和性能需求来获取及选择对应频率的工作时钟。下图为ESP32-P4系统时钟结构。

图2.4.1.1 HP和LP系统时钟树
在上图中,十多路时钟源通过分频器或直接连接的方式供给各个外设。这样,各模块可根据功耗和性能需求,选择和获取相应的工作时钟频率。
接下来,笔者根据HP系统和LP系统的应用不同,划分为两个类型的时钟。
1,高速时钟
1)CPLL_CLK:内部400MHz时钟,CPU主频可由该时钟提供。
2)MPPL_CLK:内部500MHz时钟,PSRAM_CLK可由该时钟提供。
3)SPLL_CLK:内部480MHz时钟,FLASH_CLK/PSRAM_CLK可由该时钟提供。
2,慢速时钟
1)XTAL32K_CLK:外部32KHz石英晶振时钟。
2)RC_SLOW_CLK:内部慢速RC振荡器,频率可调,默认150KHz。
3)RC32K_CLK:内部32KHz RC振荡器。
4)XTAL_CLK:40MHz外部石英晶振时钟。
5)RC_FAST_CLK:内部快速RC振荡器,频率可调,默认20MHz。
6)PLL_LP_CLK:内部PLL时钟,默认为8MHz。
其中,高速时钟用于HP系统及其数字/模拟外设,而慢速时钟则用于LP系统以及某些低功耗模式下的外设。由此可见,我们可以将上图2.4.1.1划分为两个部分:上部分(红色区域)为HP系统所需的时钟,下部分(绿色区域)为LP系统所需的时钟。
前面我们已经了解到,ESP32-P4芯片集成了高性能(HP)系统和低功耗(LP)系统。其中,HP系统的主频最高可达400MHz,而LP系统的主频最高则为40MHz。那么,如何配置这两个系统以达到其最高主频呢?接下来,笔者将结合《ESP32-P4技术参考手册》,详细讲解这两个系统的主频配置方法。
1,HP系统时钟配置
由上图红色区域可知,CPU_CLK是HP系统的主频时钟,由XTAL_CLK、CPLL_CLK和RC_FAST_CLK这三个时钟源提供(LP_CLKRST_HP_CLK_CTRL_REG寄存器中的第0~1位(即LP_CLKRST_LP_CLK_SEL字段)来选择时钟源)。若要将HP系统的主频配置为400MHz,则必须选择CPLL_CLK作为时钟源,并将其频率设置为400MHz。此时,分频器(DIV)不进行分频(即1分频,意味着直接传递原频率),从而确保CPU_CLK的频率为400MHz。
MEM_CLK、SYS_CLK和APB_CLK时钟则是由CPU_CLK时钟经过分频得到的。另外,MPLL_CLK和SPLL_CLK也会经过分频器(DIV)进行分频,以产生不同频率的时钟信号。这些时钟信号被提供给HP系统的各个模块,各模块根据自身的功耗和性能需求来选择相应的时钟频率。下图是派生的HP时钟源。

图2.4.1.2 派生的HP时钟源
上图中,左边“Source Clock”为原始时钟源,右边“Derived Clock”为派生时钟源(由原始时钟源经过分频得到)。下图为HP系统外设时钟源选择。

图2.4.1.2 HP系统外设时钟源选择(部分截图)
关于ESP32-P4的HP系统外设时钟源选择,可以参考《ESP32-P4技术参考手册》中的453页8.2-4和8.2-5表格。
2,LP系统时钟配置
由上图绿色区域可知,在“active”模式下,LP_FAST_CLK是LP系统(低功耗系统)的主频时钟,它由XTAL_CLK、RC_FAST_CLK和PLL_LP_CLK这三个时钟源提供。我们可以通过操作LP_CLKRST_LP_CLK_CONF_REG寄存器中的第0~1位(即LP_CLKRST_LP_CLK_SEL字段)来选择时钟源。若要将LP系统的主频配置为40MHz,则必须选择XTAL_CLK作为时钟源,并将其频率设置为40MHz。
在‘Light-sleep’或‘Deep-sleep’模式下,一般选择LP_SLOW_CLK作为时钟源,该时钟由RC_SLOW_CLK、XTAL32K_CLK、RC32K_CLK和OSC_SLOW_CLK这四个低频时钟源提供。我们可操作LP_CLKRST_LP_CLK_CONF_REG寄存器中的第0~1位(即LP_CLKRST_SLOW_CLK_SEL字段)来选择时钟源。下图是派生的LP时钟源。

图2.4.1.3 派生的LP时钟源
上图中,左边“Source Clock”为原始时钟源,右边“Derived Clock”为派生时钟源(由原始时钟源经过分频得到)。下图为LP系统外设时钟源选择。

图2.4.1.4 LP系统外设时钟源选择
关于ESP32-P4的LP系统外设时钟源选择,可以参考《eESP32-P4技术参考手册》中的455页8.2-7表格。

2.4.2 系统与内存

在ESP32-P4芯片中,系统架构设计和内存布局为高效处理和多任务并发提供了基础。前面讲解过,该芯片集成了高性能(HP)和低功耗(LP)两种RISC-V处理器,配合多级内存结构与丰富的外设支持,适用于各种物联网和嵌入式应用场景。
下图展示了ESP32-P4的系统结构和地址映射。ESP32-P4的指令总线和数据总线共享同一地址空间,这意味着所有非保留的地址都可以通过这两条总线进行访问。这种设计提高了系统在执行指令和访问数据时的灵活性。在分析下图之前,我们需要先了解两个关键概念:总线结构与端序,以及数据访问对齐。
1,总线结构与端序
在ESP32-P4中,HP CPU和LP CPU的指令总线和数据总线均采用小端序(little-endian)。其中,HP CPU的数据总线(DBUS)具有128位的数据宽度,而其他总线的数据宽度为32位。
2,数据访问对齐
1)HP CPU:通过数据总线访问数据时,支持单字节(1字节)、双字节(2字节)和4字节对齐。此外,在执行AI指令时,HP CPU的数据对齐需求最高可达16字节,这为高效的AI计算提供了支持。
2)LP CPU:支持单字节、双字节和4字节对齐的数据访问。
这种对齐方式的设计,尤其是HP CPU的多字节对齐支持,使得ESP32-P4在高性能计算和数据处理任务中能够更有效地利用内存带宽和系统资源。

图2.4.2.1 ESP32-P4 系统结构与地址映射
上图展示了ESP32-P4的系统结构和地址映射。以下是对该图所示系统结构和地址映射的逐步解剖。

1,处理器结构
ESP32-P4芯片包含以下两种处理器:
1)高性能(HP)CPU:32位RISC-V双核处理器,主频高达400 MHz,采用五级流水线结构。HP CPU适用于计算密集型任务,支持对高速缓存和大容量外部存储的快速访问。
2)低功耗(LP)CPU:32位RISC-V单核处理器,主频40 MHz,采用两级流水线结构。LP CPU功耗较低,适合执行低速率、低功耗任务,通常用于待机或低频应用。
这种双处理器架构允许系统在功耗和性能之间灵活切换,为任务分配和资源管理提供了更高的灵活性。

2,内存结构
ESP32-P4的内存结构由多层次的内部存储器和可外扩的存储器组成,允许高效的数据处理和存储访问。
1)HP CPU内存访问:
HP TCM(紧耦合内存):8 KB,地址范围为0x30100000~0x30101FFF,供HP CPU快速访问,适合存储时间敏感的数据或指令。
①:HP ROM(只读存储器):128 KB,分为两种访问方式,一种是缓存访问地址,通过Cache进行缓存访问(0x4FC000000x4FC1FFFF),另一种是直接访问地址(0x8FC000000x8FC1FFFF)。HP ROM存储区是用于系统启动代码和初始化程序。
②:HP L2MEM(二级缓存内存):768 KB,分为两种访问方式,一种是缓存访问地址(0x4FF000000x4FFBFFFF),另一种是直接访问地址(0x8FF000000x8FFBFFFF)。
③:外部存储器:
外部Flash(External flash):最大64 MB,供程序代码和非易失性数据存储,地址范围为:
缓存访问地址:0x40000000~0x43FFFFFF。
直接访问地址:0x80000000~0x83FFFFFF。
外部RAM(External RAM):最大64 MB,适合存储大量数据或临时缓存,地址范围为:
缓存访问地址:0x48000000~0x4BFFFFFF。
直接访问地址:0x88000000~0x8BFFFFFF。
2)LP CPU内存访问:
①:LP ROM:16 KB,地址范围为0x50100000~0x50103FFF,存储启动代码和初始化程序。
②:LP SRAM:32 KB,地址范围为0x50108000~0x5010FFFF,为LP CPU提供的低功耗快速访问存储。
③:共享访问:LP CPU还可以访问HP ROM、HP L2MEM和外部存储器(地址与HP CPU相同),从而增强数据共享和协同处理能力。

3,外设地址映射
ESP32-P4芯片的外设模块具有独立的地址空间,为处理器和外设间的通信提供了便利。
1)HP CPU外设:地址范围为0x3FF00000~0x3FF1FFFF。
2)HP外设:地址范围为0x50000000~0x500FFFFF。
3)LP外设:地址范围为0x50110000~0x5012FFFF。
通过这种独立的地址划分,ESP32-P4的处理器能够高效管理多个外设,减少总线冲突,并优化访问延迟。关于外设地址映射的详细信息,请参考《ESP32-P4技术参考手册》第5章《System and Memory》中的5.3.5小节《Modules/Peripherals Address Mapping》,该小节已详细讲解了各个外设的映射地址。

4,地址配置
ESP32-P4内存的地址空间可以通过不同方式进行访问,其中缓存访问和直接访问的分布设计可以满足不同任务的需求:
1)缓存访问:地址以0x4xxx_xxxx开头的区域可以配置为缓存访问,通过处理器的PMU(性能监控单元)进行管理,以提高访问速度。
2)直接访问:地址以0x8xxx_xxxx开头的区域提供直接访问,通常用于调试或需要低延迟访问的场景。
通过这种灵活的访问配置,ESP32-P4芯片支持在不同存储设备和数据类型之间快速切换,提升了数据的读取和写入效率。
至此,ESP32-P4的系统与内存相关知识讲解完毕。如需深入了解更多系统与内存的细节,请参考《ESP32-P4技术参考手册》中的第5章《System and Memory》。

2.4.3 IO MUX和GPIO交换矩阵

GPIO(通用输入输出)引脚作为芯片与外部设备交互的关键接口,为了支持多种外设和应用需求,GPIO引脚需要灵活地连接到不同的外设信号上。ESP32-P4芯片通过高功率(HP)和低功率(LP)两种GPIO矩阵和IO MUX(输入输出复用器)系统,实现了对GPIO引脚的灵活配置,使其可以与多达数百个外设信号相互连接,并且可以支持信号同步、滤波、直连等多种功能。了解IO MUX和GPIO矩阵的架构和功能,有助于开发者灵活配置ESP32-P4的引脚资源,满足不同应用场景的需求。
本章节将详细介绍ESP32-P4中的HP和LP GPIO矩阵以及对应的IO MUX的工作原理、架构以及信号的路由方式,并对其主要特性进行分析。下图为ESP32-P4的IO MUX和GPIO交换矩阵整体框架。

图2.4.3.1 IO MUX和GPIO交换矩阵整体框架
上图是ESP32-P4的HP GPIO矩阵、HP IO MUX、LP GPIO矩阵和LP IO MUX的结构,详细描述了信号从引脚到外设以及从外设到引脚的路由方式。下面我们先了解比较重要的模块相关特性,然后再去了解信号从引脚到外设和外设到引脚的路由方式。
1,HP GPIO Matrix特性
图2.4.3.1中的HP GPIO矩阵是用于将HP外设信号与GPIO引脚连接,它具有以下特点:
1)全交换矩阵:支持HP外设信号与GPIO引脚之间的全交换配置,灵活处理输入输出。
2)HP外设输入:可支持222个HP外设输入信号,灵活路由到任意GPIO引脚。这222个HP外设输入信号可查看《ESP32-P4技术参考手册》中的7.12 HP Peripheral Signal List小节内容,如下图所示。

图2.4.3.2 HP外设信号列表
上图中,左侧为HP系统的外设输入信号,而右侧为HP系统的输出信号,这些外设输入输出可使用任意IO来实现。
3)HP外设输出:支持232个HP外设输出信号,能够路由到任意GPIO引脚(请看上图右侧信号)。
4)信号同步:通过同步处理确保输入信号与HP IO MUX的工作时钟一致,稳定性高。
5)输入信号滤波:配有GPIO滤波器进行二次过滤,有效提升信号抗干扰能力。
6)简单输入输出:提供基础的GPIO输入输出功能,支持常规数字输入输出。

2,HP IO MUX特性
图2.4.3.1中的HP IO MUX是负责HP GPIO引脚的配置与管理,主要功能包括:
1)引脚控制:管理55个GPIO引脚(GPIO0 ~ GPIO54),用于HP外设的连接和控制。
2)配置寄存器:每个GPIO引脚配有配置寄存器(IO_MUX_GPIOn_REG),可控制引脚的输入输出模式、上拉/下拉、电流驱动强度及功能选择。
3)高频信号直连:对于高频信号(如SPI、EMAC),可直接通过HP IO MUX连接外设,优化高频性能。
这两部分功能紧密配合,为ESP32-P4提供了灵活的外设信号处理和GPIO管理能力。

3,LP GPIO Matrix特性
图2.4.3.1中的LP GPIO矩阵是用于LP外设信号提供了灵活的信号路由,适用于低功耗场景,具有以下功能:
1)全交换矩阵:支持LP外设输入输出信号与LP GPIO引脚之间的全交换矩阵配置。
2)LP外设输入:支持14个LP外设输入信号,可以通过LP GPIO矩阵路由到任意LP GPIO引脚,这些外设输入信号请看《ESP32-P4技术参考手册》中的7.13 LP Peripheral Signal List小节内容,如下图所示。

图2.4.3.3 LP系统的外设信号列表
上图中,左侧为LP系统的外设输入信号,而右侧为LP系统的输出信号,这些外设输入输出可使用任意IO来实现。
3)LP外设输出:支持14个LP外设输出信号,可以路由至任意LP GPIO引脚输出(请看上图右侧信号)。
4)输入信号滤波:配备GPIO滤波器,用于对输入信号进行简单的滤波处理,提高信号的稳定性。
5)简单输入输出:支持基本的GPIO输入输出功能,满足低功耗设备的输入输出需求。

4,LP IO MUX特性
图2.4.3.1中的LP IO MUX是负责LP GPIO引脚的配置与管理,它的功能包括:
1)引脚控制:管理16个LP GPIO引脚(GPIO0 ~ GPIO15),用于LP外设的连接和控制。
2)配置寄存器:每个LP GPIO引脚配有配置寄存器(LP_IOMUX_PADn_REG),可用于控制引脚的输入输出模式、上拉/下拉、电流驱动强度、功能选择和IO MUX选择。

5,管脚PAD类型
在图2.4.3.1中,ESP32-P4芯片的PAD管脚类型分为两类电源域:VDDPST1和VDDPST2VDDPST6。VDDPST1电源域负责管理GPIO0GPIO15号管脚的电源,而VDDPST2VDDPST6电源域则负责管理GPIO16GPIO54号管脚的电源。之所以将管脚分为两类电源域,是因为ESP32-P4在不同工作模式下对电源管理有不同的需求。在低功耗(LP)模式下,芯片只能使用由VDDPST1电源域管理的GPIO0GPIO15管脚,以最大限度减少功耗。而在高性能(HP)模式下,芯片可以使用VDDPST1到VDDPST6电源域管理的管脚,即可使用GPIO0GPIO54的全部55个可编程I/O管脚,满足更复杂的I/O需求。这种电源域的划分使得ESP32-P4能够根据不同的工作状态灵活地管理功耗,同时提供丰富的I/O资源来支持多种应用。下面为VDDPST1到VDDPST6电源域管理的管脚范围,如下图所示。

图2.4.3.4 电源域管理的GPIO(部分截图)
上图的列表摘自《ESP32-P4数据手册》中的2.2 Pin Overview小节,表格详细阐述了各个电源域管理的GPIO管脚。通过控制这些电源域的电压,我们可以相应地控制它们所管理的GPIO的输入输出电压。具体来说,VDDPST1电源域管理的GPIO(GPIO0GPIO15)和VDDPST2VDDPST6电源域管理的GPIO(GPIO16~GPIO54)在工作时可根据不同电源域的电压调节来控制相应管脚的电平状态,从而实现精确的电压控制与信号处理。
至此,我们已了解了ESP32-P4的IO MUX和GPIO交换矩阵各个模块的功能与特性,接下来我们将介绍如何配置GPIO管脚为输入或输出,并将其分别与输入信号和输出信号进行绑定。

6,管脚的输入输出配置
从上述内容可以看出,配置ESP32-P4的55个可编程I/O管脚的输入输出模式,需要通过配置IO_MUX_GPIOx_REG和LP_IOMUX_PADx_REG寄存器来实现。其中,IO_MUX_GPIOx_REG寄存器用于配置HP系统中所有55个可编程I/O管脚的电气特性,而LP_IOMUX_PADx_REG寄存器仅能用于配置GPIO0~GPIO15号管脚的I/O功能,适用于低功耗模式下的配置。接下来,笔者将以HP系统为例,介绍如何配置这些管脚。
下图为管脚PAD内部结构,如下图所示。

图2.4.3.4 GPIO0~GPIO54的PAD内部结构
上图展示了PAD焊盘内部结构的输入/输出、上拉/下拉等配置,这些配置可以通过IO_MUX_GPIOx_REG(x:0~54)寄存器来实现。该寄存器用于设置与GPIO相关的电气属性,如输入输出模式、上拉或下拉电阻等。具体的寄存器描述和配置细节如下图所示。

图2.4.3.5 配置GPIO输入配置
上图中,WPD和WPU字段用于配置GPIO的上下拉使能;IE和DRV字段用于配置GPIO的输入使能与驱动能力;SEL和EN字段用于配置GPIO功能和是否启动滤波器。输出配置是由GPIO_ENABLE_REG寄存器配置的,大家可参看《ESP32-P4技术参考手册》中的7.12 HP Peripheral Signal List小节内容。

7,管脚路由至内部外设信号
从图2.4.3.1中可以看出,若GPIO由VDDPST2~VDDPST6电源域管理,则该GPIO的输入信号会流经两个方向:一条是HP IO MUX,另一条是HP GPIO matrix交换矩阵。而若GPIO由VDDPST1电源域管理,则该GPIO的输入信号可流经四个方向:首先是HP IO MUX,其次是HP GPIO matrix交换矩阵,另外在系统处于低功耗模式(即LP系统)时,信号还将流入LP IO MUX和LP GPIO matrix交换矩阵。这些信号流向的方向可参考图2.4.3.1中的红色(③)箭头。
接下来,笔者以VDDPST2~VDDPST6电源域管理的GPIO为例进行说明。
1)若输入信号被选择输入到HP IO MUX,则必须首先选择该GPIO的功能,并将其直接连接至CPU内部外设信号。下图展示了可供选择的GPIO功能,这些功能可以通过配置IO_MUX_GPIOn_REG寄存器来实现。

图2.4.3.6 IO MUX的GPIO选择功能(部分截图)
上图摘自《ESP32-P4数据手册》中的2.3.1 IO MUX Functions小节内容。上图中,若我们把GPIO28号管脚配置为Function3功能,则该GPIO通过IO MUX直接连接至SPI2_CS_PAD内部外设信号(请看图2.4.3.1中的⑥和①)。
2)当输入信号被选择进入高性能(HP)GPIO矩阵时,该信号会依次经过信号滤波和毛刺滤波处理,然后通过GPIO_EXT_GLITCH_FILTER_CHn_REG寄存器配置特定的GPIO输入。此寄存器用于选择对哪个GPIO信号应用毛刺滤波,以去除可能存在的短时噪声信号或毛刺信号,从而提升信号的稳定性和可靠性。经过滤波处理的信号还会进行时钟同步(GPIO SYNC),确保信号与系统时钟保持一致性,减少由于时钟不匹配可能引入的延迟或不稳定因素。同步处理完成后,信号将进入内部信号绑定模块,用于后续的逻辑控制或输出。如下图所示,通过GPIO_EXT_GLITCH_FILTER_CHn_REG(n:0~7)寄存器配置哪个GPIO输入字段描述。

图2.4.3.7 配置哪个GPIO输入信号
3)通过GPIO_FUNCn_IN_SEL配置输入信号时,可参考图2.4.3.1中的步骤②。例如,若要将UART0的RXD输入信号(信号索引为10)连接到GPIO7,请按以下步骤配置。
设置GPIO_FUNC10_IN_SEL_CFG_REG寄存器(n表示图2.4.3.2中的索引号,对应uart0_rxd_pad_in输入信号)中的GPIO_SIG10_IN_SEL位,以通过HP GPIO矩阵启用外设输入。这样可以通过矩阵将信号索引10(即UART0的RXD输入)路由到一个GPIO上。然后在GPIO_FUNC10_IN_SEL_CFG_REG寄存器中,将GPIO_FUNC10_IN_SEL字段设置为7,指定GPIO7作为UART0 RXD信号的输入源,最后配置IO_MUX_GPIO7_REG寄存器中的IO_MUX_GPIO7_FUN_IE位(具体描述见图2.4.3.5中左则的外部信号),以启用GPIO7的引脚输入。此设置允许引脚从HP GPIO矩阵接收输入信号。上述用到的寄存器的字段描述如下所示。

图2.4.3.8 配置GPIO映射到内部输入信号
至此,GPIO路由至内部输入信号的流程已讲解完成。对于LP系统,流程与HP系统类似,只是配置的寄存器不同。

8,内部外设信号路由至管脚
接下来,笔者将以HP系统的内部外设信号输出为例进行说明。如图2.4.3.1所示,HP系统中的232个外设信号可以通过HP GPIO matrix 和HP IO MUX输出。如果选择通过HP GPIO matrix输出外设信号(请看图2.4.3.1中的⑧),则必须配置对应的寄存器,即GPIO_FUNCn_OUT_SEL_CFG_REG寄存器,其中n表示图2.4.3.2右侧列出的外部信号编号,共有232个外部输出信号。以下是GPIO_FUNCn_OUT_SEL_CFG_REG寄存器的字段描述。

图2.4.3.9 内部外设输出信号绑定GPIO
如果选择直接输出外设信号,则信号会通过HP IO MUX的直接映射功能输出。这些映射功能我们已经在图2.4.3.6中进行了详细说明。要实现直接输出的配置,只需设置对应的IO_MUX_GPIOn_REG寄存器,即可完成信号的输出。
至此,内部输出信号路由至GPIO的流程已讲解完成。对于LP系统,流程与HP系统类似,也 是配置的寄存器不同。

2.4.4 芯片Boot控制

芯片在上电或硬件复位时,会通过某些管脚的上下拉(Strapping Pins)和eFuse bits(是一种可编程电子保险丝,是一种用于存储信息和保护芯片的非易失性存储器件)来确定其启动过程和一些功能,无需微处理器的参与。这些设置可以决定以下功能:
1)芯片启动模式:确定芯片以何种模式启动。
2)ROM消息打印的启动和禁用:决定是否在启动时打印ROM中的消息。
3)JTAG信号源:决定JTAG信号的来源。
1,芯片启动模式。
在电源上电或复位过程中,芯片会采集Strapping管脚(GPIO35、GPIO36、GPIO37、GPIO38)的电平状态,存储在锁存器中并保持至断电。下表是芯片启动模式控制。

表2.4.4.1 芯片启动模式控制
ESP32-P4芯片的启动模式由GPIO35至GPIO38的电平决定。默认情况下,若GPIO35为高电平,则芯片进入“SPI Boot”模式;若GPIO35为低电平且GPIO36为高电平,则进入“Joint Download Boot”模式,支持“USB”、“UART”和“SPI Slave”三种下载方式;若GPIO35至GPIO37均为低电平且GPIO38为高电平,则芯片进入“SPI Download Boot”模式;若GPIO35至GPIO38均为低电平,则芯片进入“Invalid Combination”无效模式。下图为Strapping管脚默认电平。

图2.4.4.1 Strapping管脚默认电平
根据上图所示,ESP32-P4芯片的GPIO35管脚在默认情况下内部连接有一个上拉电阻,这种配置使得芯片进入“SPI Boot”模式。若GPIO35管脚未连接或连接到外部高阻抗电路,那么内部的弱上拉电阻将确定该管脚的默认输入电平,进而决定芯片的默认启动模式。下图是芯片启动流程。

图2.4.4.2 ESP32-P4芯片启动流程
注意:上图中的“x1”和“01”表示GPIO35和GPIO36组合值,芯片根据这两个管脚组合值进入不同的启动模式。
小知识:
1)Strapping管脚是芯片每次上电或复位时,都需要一些初始配置参数,如加载芯片的启动模式、flash存储器的电压等。这些参数通过strapping管脚控制。芯片读取Strapping管脚上电时的状态来配置芯片的初始化的参数,复位释放后, strapping管脚和普通IO管脚功能相同。
2)在SPI Boot模式下,ROM引导加载程序通过从SPI flash中读取程序来启动系统。在这个模式下,我们还可以进一步分类如下:
①:Normal flash Boot:ROM引导加载程序通过从SPI Flash加载至L2MEM中启动。
②:Direct Boot:程序从Flash运行。如果要启动此模式,请确保下载的bin文件前两个字为0xaedb041d。
3)在Joint Download Boot模式下,用户可通过USB或UART0接口将二进制文件下载至flash,或者下载至L2MEM中直接运行。
4)在SPI Download Boot模式下,用户可通过SPI接口将二进制文件下载至Flash,或者下载至L2MEM中直接运行。
2,ROM消息打印的启动和禁用
系统启动过程中,ROM代码log可打印至如下控制器。
1)UART0和USB Serial/JTAG控制器(默认)
2)USB Serial/JTAG控制器
3)UART0
EFUSE_UART_PRINT_CONTROL(eFuse 位)和GPIO36控制ROM消息打印到UART0,如下图所示。

图2.4.4.3 UART0 ROM 日志打印控制
EFUSE_DIS_USB_SERIAL_JTAG_ROM_PRINT(eFuse 位)用于控制 ROM 日志是否打印到 USB Serial/JTAG 控制器。当该位为 1 时,禁止将日志打印到 UART Serial/JTAG 控制器。当该位为 0 时,如果通过 EFUSE_DIS_USB_SERIAL_JTAG 启用 USB Serial/JTAG 控制器,则 ROM 消息将打印到 USB 串口/JTAG 控制器。具体情况如下图所示。

图2.4.4.4 USB 串口/JTAG ROM 日志打印控制
默认情况下,EFUSE_UART_PRINT_CONTROL(eFuse 位)和 EFUSE_DIS_USB_SERIAL_JTAG_ROM_PRINT(eFuse 位)均配置为 0,表示启用 UART0 和 USB Serial/JTAG ROM 日志打印功能。请注意,如果 EFUSE_DIS_USB_SERIAL_JTAG_ROM_PRINT 设置为 0 以打印到 USB,但 USB Serial/JTAG 控制器已禁用,则 ROM 消息将不会打印到 USB Serial/JTAG 控制器。
有关 eFuse 控制器的详细信息,请参阅《ESP32-P4 Technical Reference Manual》中的第 292 页“eFuse Controller”章节,该章节提供了关于 eFuse 控制器的技术规格和功能说明。
3,JTAG信号源
在系统启动的早期,GPIO34可用于控制JTAG信号源。该引脚没有内部上下拉电阻,因此strapping的值必须由不处于高阻抗状态的外部电路控制。如下表所示,GPIO34与EFUSE_DIS_PAD_JTAG、EFUSE_DIS_USB_JTAG和EFUSE_JTAG_SEL_ENABLE共同控制JTAG信号源。

图2.4.4.2 JTAG信号源控制
上图中的 eFuse 1、eFuse 2 和 eFuse 3 分别代表 eFuse 位的 EFUSE_DIS_PAD_JTAG、EFUSE_DIS_USB_JTAG 和 EFUSE_JTAG_SEL_ENABLE。这里的 x 代表任意值,可以忽略。

2.4.5 中断矩阵

ESP32-P4 拥有多达 126个外设中断源,需要通过中断矩阵将这些中断信号映射到 32个HP CPU0中断 或 32个HP CPU1中断。若没有中断矩阵,这样大规模的中断源管理将极具复杂性。而通过中断矩阵,不仅能有效地将中断源分配到不同的CPU核,还可以根据应用需求将同一中断源路由至多个CPU中断输入,从而实现灵活的中断处理和多任务并行操作。通过这种结构设计,ESP32-P4的中断矩阵确保了复杂的外设中断管理变得高效、灵活且可扩展,为开发者提供了更多的系统配置选项,优化了系统性能和响应能力。
关于ESP32-P4的这126个外设中断源的详细信息,可以参考 《ESP32-P4技术参考手册》中的593页,其中的表10.4-1 描述了 CPU外设中断源映射/状态寄存器和外设中断源,为开发者提供了详细的中断源配置和映射方式。
1,中断矩阵概述
中断矩阵是一种灵活的硬件机制,用于管理和分配系统中断信号,使得多个外设的中断请求能够灵活地映射到不同的CPU中断输入上。在ESP32-P4芯片中,中断矩阵允许通过软件配置,将不同外设或GPIO引脚的中断源动态连接到特定的CPU中断控制器(Interrupt Controller)。
中断矩阵的主要功能在于其高度灵活性和可配置性,具体包括:
1)动态路由中断源:中断矩阵可以将不同的外设或GPIO中断信号连接到任意CPU核心的中断通道上,支持跨核中断分配。
2)优先级管理:矩阵允许对不同的中断源设置优先级,以确保高优先级中断能够抢占低优先级中断,提高系统的实时性。
3)中断源隔离:它支持通过矩阵的配置隔离不同的中断源,避免多个中断源竞争同一中断通道,从而提升系统的稳定性和鲁棒性。
4)可查询当前外设中断源的中断状态。
5)多个中断源可映射到单个HP CPU0或HP CPU1中断,我们称之为共享中断。
下图为ESP32-P4芯片中断矩阵结构。

图2.4.5.1 中断矩阵结构
上图中的蓝色框表示中断矩阵,它负责接收来自外设的中断信号,包括低功耗外设(LP Peripheral Interrupt Sources)和高性能外设(HP Peripheral Interrupt Sources)。当中断矩阵接收到这些外设中断信号后,用户可以通过配置红色框标识的 Core0 Interrupt Reg 或 Core1 Interrupt Reg 寄存器,来选择将外设中断源路由到 HP CPU0 或 HP CPU1。
红色框中的 Core0 Interrupt Reg 和Core1 Interrupt Reg寄存器具有两个主要功能:
1)上图中的①,通过配置端口(Config Port) 动态地将中断信号路由到特定核心的中断控制器,允许用户灵活配置中断路由。
2)上图中的②,通过状态端口(Status Port) 查询当前外设中断源的状态,帮助用户监控和调试中断的处理情况。
上图中的绿色框标识表示 Core0 Interrupt Ctrl 和Core1 Interrupt Ctrl中断控制器,它负责处理路由到该核心的中断信号。这些控制器可以根据中断优先级、信号来源等条件,决定是否处理中断。最终,当CPU接收到外部中断信号时,会调用与该中断相关联的中断服务程序(上图的橙色框标识),处理完毕后,恢复正常操作。
2,中断矩阵的操作流程
1)中断信号生成:当某个外设或GPIO产生中断事件时,信号传递至中断矩阵。
2)信号路由:中断矩阵根据预设的路由配置,将中断信号映射至目标CPU的中断输入端。
3)CPU中断处理:CPU接收到中断信号后,根据中断优先级判定是否处理该中断。当中断处理完成后,CPU通过清除相应标志位或通过软件控制的中断服务恢复正常执行流程。
下图为中断处理流程图。

图2.4.5.1 中断处理流程
在 ESP32-P4 中,外设模块可以生成多达126个内部中断源,这些中断源对应于不同的外设事件或状态变化,如计时器溢出、串口数据接收完成、GPIO信号变化等。这些中断源首先通过硬件生成 126条中断信号(Interrupt Signals)。
接下来,这些外设中断信号被发送到中断矩阵(Interrupt Matrix),一个用于灵活管理和分配中断信号的硬件结构。中断矩阵将外设的中断信号转化为 中断源(Interrupt Sources),并根据系统配置将其路由到适当的CPU核上的中断控制器。
上图中的中断控制器的任务是根据系统设计和开发者的配置,将这 126个外设中断源路由到 32条CPU中断通道,这些通道分别与ESP32-P4的不同CPU核(CPU0和CPU1)相对应。当中断矩阵将中断源映射到相应的CPU中断信号时,信号最终会进入 HP CPU中断控制器。该控制器负责进一步管理和处理来自中断矩阵的信号,并根据中断的优先级做出处理决策。当中断控制器决定处理某个中断时,CPU会暂停当前任务,执行与中断相关的中断服务例程(ISR)。中断处理完成后,系统将恢复正常任务执行,并清除中断标志,确保系统顺利运行。
下图为中断矩阵管理的CPU外设中断源映射和状态寄存器。

图2.4.5.2 CPU外设中断源映射和状态寄存器(部分截图)
读者可在《ESP32-P4技术参考手册》中的“Interrupt Matrix”章节中,参考表10.4.1,找到关于CPU外设中断源映射和状态寄存器的详细内容。该表格列出了所有可用的中断源及其映射关系,有助于理解中断系统的工作机制和配置方法。

2.5 ESP32-P4 启动流程

本文将会介绍ESP32-P4从上电到运行app_main函数中间所经历的步骤(即启动流程)。从宏观上,该启动流程可分为如下三个步骤。
1)一级引导程序,它被固化在ESP32-P4内部的ROM中,它会从flash的0x2000处地址加载二级引导程序至RAM(IRAM & DRAM)中。
2)二级引导程序从flash中加载分区表和主程序镜像至内存中,主程序中包含了RAM段和通过flash高速缓存映射的只读段。
3)应用程序启动阶段运行,这时第二个CPU和freeRTOS的调度器启动,接着运行main_task任务函数,从而进入app_main函数执行用户代码。
下面作者根据IDF库相关的代码来讲解这三个引导流程,如下:
1,一级引导程序
该部分程序是直接存储在ESP32-P4内部ROM中,所以普通开发者无法直接查看,它主要是做一些前期的准备工作(复位向量代码),然后从flash 0x2000偏移地址中读取二级引导程序文件头中的配置信息,并使用这些信息来加载剩余的二级引导程序。
2,二级引导程序
该程序是可以查看且可被修改,在搭建ESP-IDF环境完成后,可在esp-idf\components\bootloader/subproject/main/路径下找到bootloader_start.c文件,此文件就是二级引导程序启动处。首先我们克隆ESP-IDF库,克隆过程如下所示。

图2.6.1 克隆ESP-IDF库
克隆完成后,使用VSCode打开ESP-IDF库,接着找到bootloader_start.c,如下图所示。

图2.6.2 bootloader_start.c文件路径
在这个文件下,找到call_start_cpu0函数,此函数是bootloader程序,如下是bootloader程序的部分代码。

/*
 ROM引导加载程序完成从闪存加载第二阶段引导加载程序之后到达这里
 */
void __attribute__((noreturn)) call_start_cpu0(void)
{
    if (bootloader_before_init) {
        bootloader_before_init();
    }

/* 1. 硬件初始化:初始化内存、启用超级看门狗自动喂养、配置时钟、清除bss段、开启cache和
复位mmu等操作。
bootloader_support/src/ esp32-p4/bootloader_esp32p4.c */
    if (bootloader_init() != ESP_OK) {
        bootloader_reset();
    }

    if (bootloader_after_init) {
        bootloader_after_init();
    }

    /* 2. 选择启动分区的数量:加载分区表,选择boot分区 */
    bootloader_state_t bs = {0};
    int boot_index = select_partition_number(&bs);
    
    if (boot_index == INVALID_INDEX){
        bootloader_reset();
    }

/* 3. 加载应用程序映像并启动
bootloader_support/src/esp32-p4/bootloader_utility.c */
    bootloader_utility_load_boot_image(&bs, boot_index);
}

ESP-IDF使用二级引导程序可以增加FLASH分区的灵活性(使用分区表),并且方便实现FLASH加密,安全引导和空中升级(OTA)等功能。主要的作用是从flash的0x8000处加载分区表(请看在线ESP-IDF编程指南分区表章节)。根据分区表运行应用程序。
3,三级引导程序
应用程序的入口是在esp-idf/components/esp_system/port/路径下的cpu_star.c文件,在此文件下找到call_start_cpu0函数(端口层初始化函数)。这个函数由二级引导加载程序执行,并且从不返回。因此你看不到是哪个函数调用了它,它是从汇编的最底层直接调用的(components\esp_system\ld\esp32p4\sections.ld.in汇编文件)。
这个函数会初始化基本的C运行环境(“CRT”),并对SOC的内部硬件进行了初始配置。执行call_start_cpu0函数完成之后,在components\esp_system\startup.c文件下调用start_cpu0(在36行中,弱关联start_cpu0_default函数)系统层初始化函数,如下start_cpu0_default函数的部分代码。

static void start_cpu0_default(void)
{
    /* 初始化核心组件和服务 */
    do_core_init();

    /* 执行构造函数 */
    do_global_ctors();

    /* 执行其他组件的init函数 */
do_secondary_init();

#if SOC_CPU_CORES_NUM > 1 && !CONFIG_ESP_SYSTEM_SINGLE_CORE_MODE
    s_system_full_inited = true;
#endif

    /* 开启APP程序 */
    esp_startup_start_app();
    while (1);
}

到了这里,就完成了二级程序引导,并调用esp_startup_start_app函数进入三级引导程序,该函数的源码如下:

/* components/freertos/app_startup.c */
/* 开启APP程序 */
void esp_startup_start_app(void)
{
    /* 省略部分代码 */

    /* 新建main任务函数 */
    BaseType_t res = xTaskCreatePinnedToCore(main_task, "main",
                                             ESP_TASK_MAIN_STACK, NULL,
                                             ESP_TASK_MAIN_PRIO, NULL,
                                             ESP_TASK_MAIN_CORE);
    assert(res == pdTRUE);
    (void)res;

    void __attribute__((weak)) port_start_app_hook(void);
    if (port_start_app_hook != NULL) {
        port_start_app_hook();
    }

    ESP_EARLY_LOGD(APP_START_TAG, "Starting scheduler on CPU0");
    /* 开启FreeRTOS任务调度 */
    vTaskStartScheduler();
}

/* main任务函数 */
static void main_task(void* args)
{   /* 省略部分代码 */
    /* 执行app_main函数 */
    ESP_LOGI(MAIN_TAG, "Calling app_main()");
    extern void app_main(void);
    app_main();
    ESP_LOGI(MAIN_TAG, "Returned from app_main()");
    vTaskDelete(NULL);
}

从上述源码可知,首先在xTaskCreatePinnedToCore函数创建main_task任务,然后开启freeRTOS任务调度器,最后在main_task任务下调用app_main函数(此函数在创建工程时,在main.c下定义的)。

作者:齐海智

一、背景:大促备战中的异常数据

大促备战期间,接到客户反馈我司上传到客户服务器上的文件存在科学计数法表示的情况(下图的4.55058496E7),与约定不符。

在这里插入图片描述



查看转换前的数据是:455058496,转换后(除以10:进行毫米到厘米的转换)就变成了科学计数法形式了。

在这里插入图片描述

问题代码:

<set var="temp.b" expr="${_item.boxLength / 10}" clazz="java.lang.String"/>

说明:

这个是个EL表达式,含义是使用expr的值作为计算逻辑,计算结果赋值给var指向的变量temp.b,类型是java.lang.String。

_item代表当前上下文里的一个对象。

boxLength_item对象所具备的属性。

•该表达式先对boxLength执行除以 10 的运算,再把运算结果转换为字符串(由clazz定义的)。

业务上,boxLength是个长度的概念,单位是毫米,除以10是转换成厘米的含义。为了保证精度,系统(基于JAVA)会先将boxLength先转成java.lang.Double类型,再除以10,最后调用Double.toString()方法转成字符串。

二、问题定位:字符串转换的科学计数法陷阱

2.1 问题复现

代码:

Double depthInDouble = 455058496d/10;
log.info("depthInDouble={}", depthInDouble);

结果:

在这里插入图片描述



2.2 原因分析

问题就出在了最后一行,日志输出的时候Double会被转成String,调用Double.toString()方法,而对于Double对象的值在一定的范围内,会使用科学计数法表示。

log.info的调用链(为什么会调用到Double.toStirng()):

log.info("depthInDouble={}", depthInDouble);
  ↓
Log4jLogger.info(String format, Object arg)
  ↓
AbstractLogger.logIfEnabled(...)
  ↓
AbstractLogger.logMessage(...)
  ↓
ParameterizedMessageFactory.newMessage(...)
  ↓
ParameterizedMessage 构造函数(参数被暂存为 Object[])
  ↓
// 此时尚未调用 Double.toString()
  ↓
// 当 Appender 执行输出时...
Appender.append(LogEvent)
  ↓
LogEvent.getMessage().getFormattedMessage() // 触发消息格式化
  ↓
ParameterizedMessage.getFormattedMessage()
  ↓
ParameterizedMessage.formatMessage(...)
  ↓
ParameterizedMessage.argToString(Object)
  ↓
Double.toString() // 终于在这里被调用!

查看Double.toString()的源码,可以看到相关解释:

在这里插入图片描述

也就是说对于极小(小于10^-3)或者极大(大于10^7)值的浮点数,转成String的时候会使用科学计数法表示,验证如下。

代码:

public static void main(String args[]) {
       String depth = "455058496"; // 单位:毫米
       Double depthInDouble = Double.parseDouble(depth)/10;
       String doubleInString = String.valueOf(depthInDouble);
       log.info("depthInDouble={}", depthInDouble);
       log.info("doubleInString={}", doubleInString);
       depthInDouble = 1e-3;
       log.info("10^-3 = {}", depthInDouble);
       depthInDouble = 1e7;
       log.info("10^7 = {}", depthInDouble);
       Double aVerySmallNumber = 1e-9;
       depthInDouble = 1e-3 - aVerySmallNumber;
       log.info("10^-3 - delta = {}", depthInDouble);
       depthInDouble = 1e7 - aVerySmallNumber;
       log.info("10^7 - delta = {}", depthInDouble);
   }

运行结果:

在这里插入图片描述



说明,10^-3不会使用科学记计数法,但是小于它就会使用科学计数法,10^7就会使用科学计数法,小于它就会不会,大于它会。

2.3 为什么要使用科学计数法

2.3.1 小数在计算机内是如何表示的

先不急于讨论为什么使用科学计数法,我们先看看小数在计算机内是如何表示的。

从存储角度来看,计算机的存储是有限资源,能存储的数据是有范围的,不是无限大,也就是说有限的硬件资源限制了计算机可以表示的数值的大小。对于一个浮点数,我们可以用10个bit存储,也可以用100个,为了实现跨设备、跨平台的数据统一表示和交换,IEEE 754 规范定义了标准格式,规定了Double类型使用64比特。

在这里插入图片描述

当64个比特确定了,那么它可以表示的数字的范围就确定了,接下来考虑怎么表示小数,可以表示什么范围内的小数,进而再讨论威慑么定义超过10^7或者小于10^-3使用科学计数法,而不用普通的方式(定点数表示法)。

类似整数可以利用除以2取余获得其二级制的表示形式,例如:123(10进制)= 1111011(二进制)

在这里插入图片描述



小数则进行乘2取整,如0.123(10进制)= 0. 0001111101(二进制,位数会一直循环无法精确表示,只能近似,这里取了10位)

在这里插入图片描述

因此最简单的一种设计(不考虑正负)就是将64位中的一部分划分为整数位,一部分划分为小数位,比如32位整数,32位小数(定点数表示法)。

那么这样设计的Double最大数可以表示2^32-1,

如果要以米为单位表示银河系直径,约1光年299792458米/秒1年 = 299792458米/秒365天*86400秒/天 ≈ 9.45 * 10^15 ,而2^32-1≈4.29 * 10^9 (远小于1光年),因此无法使用Double表示银河系直径,无法支撑天文学科的计算了。

在这里插入图片描述



这样设计的Double最小可以表示2^-32=2.3810^-10 ,一个质子的大小是0.84飞米=8.410^-16,因此也无法支持物理学的计算。

所以,矛盾在于增加整数部分的位数,就会压缩小数部分的位数,不同的领域中,既有要求数字很大可表示的(在乎量级,如天文学、金融学),也有要求数值很小能表示的(在乎精度,如物理学、生物学)。

可以看到,上面的很多数字表达,我们也使用了科学计数法的表示形式来简化表达,对于上面这个数字(9.454,254,955,488,000)写起来麻烦还很占地方,而且我们也不需要那么精确,只是看个量级,因此会写成9.45 * 10^15 ,不影响理解。

即表示一个极大或者极小的数可以使用:【数值底数^指数】的形式,对于大数来讲指数就是正的,小数就是负的,计算机使用二进制,因此底数就是2,所以小数可以表示成:【数值2^指数】的形式,这个数值,其实就是尾数。

计算机专家们经过多种研究,最终经过IEEE确定了IEEE 754标准,即不确定整数和小数的位数(固定小数点,即定点数),而使用变化的位数,也就是小数点可以浮动,即浮点数表示法。浮点数表示法定义了小数由符号位+指数位+尾数位三部分组成。

符号位是1bit,0代表整数,1代表负数,指数位决定数值的量级,尾数位决定数值精度。

64位的说明如下:

在这里插入图片描述





其中11和52的设计是在平衡了很多需求后得到的最佳实践。

Double (64位) = 符号位(1位) + 指数位(11位) + 尾数位(52位)

示例:455058496.0 的IEEE 754表示
原始值:455058496.0
二进制科学计数法:1.0101100001110000000000000000000 × 2^28

符号位:0 (正数)
指数位:28 + 1023(偏移量) = 1051 = 10000011011₂
尾数位:0101100001110000000000000000000... (52位)

完整64位表示:
0 10000011011 0101100001110000000000000000000000000000000000000000

2.3.2 数值超过10^7或者小于10^-3会发生什么

其实什么也不会发生,只是基于如下原因综合权衡的结果。

1、认知科学依据

•人类短期记忆的数字处理能力约为7±2位

•超过7位的整数部分难以快速理解

•科学计数法提供更好的可读性

2、精度保持考虑

•10^7 = 10,000,000 (8位数字)

•超过此值,普通格式会显得冗长

•10^-3 = 0.001,更小的数用科学计数法更清晰

3、历史兼容性

•这个标准在多种编程语言中被采用

•保持了与C语言printf的兼容性

•符合IEEE 754标准的建议

这也就是为什么这个这个范围内的数要表示成科学计数法了。

2.3.3 源码探究

1、调用链路

根据源码,可以看到Double.toString()方法的调用链是:

在这里插入图片描述

分流是否使用科学计数法的核心代码toChars的代码如下:

/*
 * Formats the decimal f 10^e.
 */
private int toChars(byte[] str, int index, long f, int e, FormattedFPDecimal fd) {
    /*
     * For details not discussed here see section 10 of [1].
     *
     * Determine len such that
     *     10^(len-1) <= f < 10^len
     */
    int len = flog10pow2(Long.SIZE - numberOfLeadingZeros(f));
    if (f >= pow10(len)) {
        len += 1;
    }
    if (fd != null) {
        fd.set(f, e, len);
        return index;
    }

    /*
     * Let fp and ep be the original f and e, respectively.
     * Transform f and e to ensure
     *     10^(H-1) <= f < 10^H
     *     fp 10^ep = f 10^(e-H) = 0.f 10^e
     */
    f *= pow10(H - len);
    e += len;

    /*
     * The toChars?() methods perform left-to-right digits extraction
     * using ints, provided that the arguments are limited to 8 digits.
     * Therefore, split the H = 17 digits of f into:
     *     h = the most significant digit of f
     *     m = the next 8 most significant digits of f
     *     l = the last 8, least significant digits of f
     *
     * For n = 17, m = 8 the table in section 10 of [1] shows
     *     floor(f / 10^8) = floor(193_428_131_138_340_668 f / 2^84) =
     *     floor(floor(193_428_131_138_340_668 f / 2^64) / 2^20)
     * and for n = 9, m = 8
     *     floor(hm / 10^8) = floor(1_441_151_881 hm / 2^57)
     */
    long hm = multiplyHigh(f, 193_428_131_138_340_668L) >>> 20;
    int l = (int) (f - 100_000_000L * hm);
    int h = (int) (hm * 1_441_151_881L >>> 57);
    int m = (int) (hm - 100_000_000 * h);

    if (0 < e && e <= 7) {
        return toChars1(str, index, h, m, l, e);
    }
    if (-3 < e && e <= 0) {
        return toChars2(str, index, h, m, l, e);
    }
    return toChars3(str, index, h, m, l, e);
}

代码地址: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java

可以看到使用科学计数法处理的核心代码是toChars3,代码如下:

private int toChars3(byte[] str, int index, int h, int m, int l, int e) {
    /* -3 >= e | e > 7: computerized scientific notation */
    index = putDigit(str, index, h);
    index = putChar(str, index, '.');
    index = put8Digits(str, index, m);
    index = lowDigits(str, index, l);
    return exponent(str, index, e - 1);
}
2、toChars3()的参数含义

byte[] str: 输出字符串的字节数组

int index: 当前写入位置的索引

int h: 最高位数字 (0-9)

int m: 中间8位数字 (00000000-99999999)

int l: 低位数字 (用于精度控制)

int e: 调整后的十进制指数值

3、 toChars3()的数据流处理步骤

1.putDigit(str, index, h) → 写入最高位数字

2.putChar(str, index, '.') → 写入小数点

3.put8Digits(str, index, m) → 写入中间8位数字

4.lowDigits(str, index, l) → 写入低位数字(去除尾随零)

5.exponent(str, index, e-1) → 写入指数部分

为什么使用 e-1?

原因:已经放置了一位数字在小数点前
目的:调整指数以保持数值不变
示例:4.55058496E7 表示 4.55058496 × 10^7
4、exponent()分析
标准科学计数法:a.bcd × 10^n
约束条件:1 ≤ a < 10(小数点前只有一位非零数字)

<!---->

private int exponent(byte[] str, int index, int exp) {
    str[index++] = (byte) 'E';  // 写入字符 'E'
    if (exp < 0) {
        str[index++] = (byte) '-';  // 负指数写入 '-'
        exp = -exp;  // 转为正数处理
    }
    if (exp >= 100) {
        str[index++] = (byte) ('0' + exp / 100);  // 百位
        exp %= 100;
    }
    if (exp >= 10) {
        str[index++] = (byte) ('0' + exp / 10);   // 十位
        exp %= 10;
    }
    str[index++] = (byte) ('0' + exp);           // 个位
    return index;
}

输入参数: byte[] str(输出缓冲区)、int index(写入位置)、int exp(指数值)

核心功能: 将指数值格式化为字符串并写入字节数组

处理逻辑: 优化处理1位、2位、3位数的指数

1. 写入 'E'
2. 处理负号(如果 exp < 0)
3. 处理百位(如果 exp >= 100)
4. 处理十位(如果 exp >= 10)
5. 处理个位(必须)

返回值: 更新后的索引位置

例子:

1. 原始数值: 45505849.6
2. 精确指数: 7.658067227112319
3. 调整后指数: 7.658 - 1 = 6.658
4. 四舍五入: 7
5. exponent方法输入: exp = 7
6. 执行步骤:
   - 写入 'E' → index = 1
   - exp = 7 < 10,跳过百位和十位
   - 写入个位 '7' → index = 2
7. 输出: "E7"
8. 完整结果: "4.55058496E7"

根据源代码的逻辑简化了一版如下:

https://coding.jd.com/newJavaEngineerOrientation/Double2Strin...

三、解决方案

3.1 BigDecimal 精准控制

new BigDecimal(doubleValue).setScale(2, RoundingMode.HALF_UP).toPlainString() 

3.2 DecimalFormat 格式化

new DecimalFormat("#0.00").format(doubleValue) // 强制保留两位小数  

四、总结

Double 数值的字符串格式化规则(如 Double.toString())遵循:

•普通格式(Plain):当数值的指数范围在 [-3, 7) 时(即绝对值在 [10^-3, 10^7) 之间),直接显示小数形式(如 0.001 或 123456.0)。

•科学计数法(Scientific):当指数范围超出 [-3, 7)(如 0.000999 或 10000000.0),显示为科学计数法(如 9.99e-4 或 1.0e7)。

作者:高继航

1 前言

2025年,虚拟试衣已成为电商行业不可或缺的核心环节,从技术落地到商业变现,全行业都在加速布局这一赛道。什么是虚拟试衣?其背后的核心技术方案有哪些?国内外电商大厂又有哪些典型实践案例?如何突破技术瓶颈,打造更贴合用户需求的试穿体验?电商平台又该如何构建完整的AIGC能力矩阵?

本文分享将基于京东零售视觉与AIGC部负责人李岩(Jason Li)博士在AICon2025的演讲内容整理呈现,深度拆解虚拟试衣的技术逻辑、行业实践与未来趋势,解锁电商AIGC的全域布局思路。

在这里插入图片描述





内容围绕以下板块展开:首先解析虚拟试穿的定义与分类;其次回顾虚拟试穿的技术发展历程;随后深度拆解行业内主流虚拟试衣产品的核心能力;再介绍京东在虚拟试穿领域的探索及实践沉淀的实践经验;在此基础上,分享京东零售AIGC布局的全景图;最后探讨虚拟试衣及电商AIGC行业的未来发展趋势。

在这里插入图片描述

2 虚拟试穿的定义与分类

在这里插入图片描述

在这里插入图片描述

虚拟试穿的底层逻辑可概括为A+B=AB,其中A指模特的图片或视频,B则是服饰图。通过视觉生成技术将服饰“穿”到模特身上,最终以静态或动态效果呈现给用户,核心要求是保证模特与服饰的关键信息不被破坏、不被篡改。

从不同维度划分,虚拟试穿可分为以下类别:

在这里插入图片描述

首先,从服饰呈现形式来看分类。服饰的素材形态主要有三种:一是平铺的白底服饰图,二是真人模特上身的服饰图,三是假人台模特上身的服饰图。

其次,以服饰数量为划分标准,这一类可以分为单件服饰和多件服饰两类。单件服饰涵盖上装、下装、长款连衣裙以及单件内衣等;多件服饰则是多种单件服饰的组合搭配,这里鞋子、包包、配饰等,也都在虚拟试衣的服务范畴之内。以上就是从服饰的不同维度对虚拟试衣进行的分类。

在这里插入图片描述

接下来,换个角度,从模特的视角来拆解虚拟试衣的分类。

从模特类型来看,可分为全身模特、半身模特、多人模特以及视频模特;

从输出形态来看,则可以分为静态图像模特和动态视频模特两类。

讲到这里大家不难发现,虚拟试衣任务的输入条件其实是相当丰富且复杂的。因此,一个优质的虚拟试穿算法,需要对上述所有的组合矩阵都具备良好的适配能力。而截至目前,要实现这一点,依然存在不小的技术挑战。

2 虚拟试穿的核心价值:三大视角的必要性分析

在这里插入图片描述



虚拟试穿技术的推进源于行业发展、消费者需求与商家痛点三大核心诉求,具体可从三个视角展开:

从行业大环境来看 三年疫情直接推动服饰行业从线下向线上转移。2019年中国服饰线上销售额占整体零售额的25%~30%,2023~2024年这一比例提升至40%,2025年更是突破50%,线上购衣已成为主流消费习惯。

从消费者视角来看 购物的便捷性和私密性需求日益凸显。调研数据显示,65%的女性和54%的男性对传统实体试衣间感到不自在、不方便——狭小空间内的脱衣穿衣操作、冬季厚重衣物的繁琐试穿流程,以及公共区域的疾病交叉感染风险等,均降低了线下试衣体验。而用户天然存在查看服装上身效果的需求,因此AI试穿被视为服饰线上零售在体验上的“最后一公里”。

从商家视角来看 高退货率是服饰电商的核心痛点。这里有一张图,可能经常网购的女生会了解这个梗,现在有不少买家会做“穿完即退”的操作,尤其是礼服类服饰,穿着新衣服拍照打卡、出席活动后,就无理由退货,导致衣服沾染污渍异味,商家根本无法二次销售。为此,商家想出了用“大尺寸+硬质材料”的“巨型吊牌”,来对这种恶意退货进行物理防御。抛开这个梗不谈,普通电商平台的服饰退货率普遍在25%~60%,内容电商直播场景的退货率更高,部分可达80%~90%。商家每处理一件退货,平均需付出15~30元成本,涵盖物流、包装、折旧、仓储及人工处理等环节,跨境电商业务的成本则更高。此外,“穿完即退”等恶意退货行为也加剧了商家损失,因此行业亟需稳定、可靠的线上试穿技术与产品能力解决上述问题。

3 虚拟试穿的行业核心难点:用户预期的三层进阶需求

在这里插入图片描述

虚拟试穿到底好不好做,行业的核心难点又在哪里?聚焦C端场景,虚拟试穿的核心难点集中在用户对技术的三层进阶预期,各层次需求对应的挑战各不相同:

第一层是基础型需求,核心是服装上身效果的精准还原,包括颜色、款式、版型和面料质感。这一层面的难点主要有四:一是用户相册中往往缺乏直接可用的素材,尤其男性用户,难以提供合格的全身或头肩部位肖像;二是试衣算法需保证模特脸部等关键信息不被篡改,尤其是脸部特征,试穿前是什么样子,试穿后核心的面部ID信息必须保持一致,试穿前后核心面部ID信息保持一致;三是真实还原与美学增强的平衡“矛盾体”——算法初期优先追求信息还原,但女性用户对美观度诉求强烈,部分用户可接受轻微肖像修改以提升效果;四是试衣模型多基于扩散模型搭建,试穿效果依赖模型储备的世界知识。

第二层是尺码合身需求,这是大众认知里,虚拟试穿最核心的刚需,也是目前实现难度最高的需求,行业内尚无成熟技术方案。从算法层面看,核心瓶颈是尺码错配训练数据的极度匮乏——电商平台买家秀多为合身尺码展示,缺乏“小体型穿大码”“大体型穿小码”等这类尺码mismatch的完整数据;此外,大量长尾服饰本身存在尺码信息缺失问题,不同品牌、品类的尺码标准不统一,这也是为什么有些店家会建议用户拍大一码或拍小一码。并且,用户对尺码存在个性化偏好,有人偏爱宽松的大码版型,有人则更倾向于合身的小码版型。所以说,尺码合身这个需求,是目前虚拟试穿技术实现中最大的难题,这进一步提升了实现难度。

第三层是突破型需求,即基于用户身材与具体场景的智能穿搭推荐及个性化风格探索。这一层,用户的典型诉求是基于自身身材与具体场景,获得智能穿搭建议,甚至进行个性化的风格探索。比如:用户可以输入自身情况,提出“要参加朋友婚礼该怎么穿搭”“出席孩子家长会适合穿什么”这类场景化需求;也可以针对已有单品提问,比如“我有一件这个颜色的上衣,搭什么下装最合适”“这条裙子配哪种外套更好看”。这些都是用户在穿搭推荐上的典型诉求。这一需求的实现难点在于:一是模型必需精准理解用户的身材特征,避免推荐不符合体型的服饰,比如不能给体型偏胖的用户推荐短款显壮的衣服;二是做好用户历史偏好建模,准确捕捉用户过往的服饰品味,让推荐更贴合其个人喜好,不能给穿衣风格偏保守的用户推荐过多潮流品牌;三是需要获取并理解“时空人”信息,就像现在12月的北京已经入冬,天气寒冷,推荐时就应该优先考虑羽绒服这类御寒衣物。最后,既然要做风格探索,就必须持续投入穿搭知识库的构建,同时积极追踪最新的时尚潮流,这样才能给用户提供前沿且合适的穿搭建议。

4 虚拟试穿的技术发展历程:从学术起源到行业主流

在这里插入图片描述

4.1 学术起源与框架演进

在这里插入图片描述

虚拟试穿的技术发展历程是什么?从虚拟试穿技术的发展看京东零售技术实践和未来发展方向。

通过文献梳理可以发现虚拟试穿(Virtual Try On)的学术概念最早于2001年由日内瓦大学研究人员正式提出,这样早期研究给出了网络环境下基于人体克隆的服装试穿解决方案。采用高度定制化技术,需从特定角度对人体拍照取样,依赖流程化、模块化操作及关键节点定位技术,这就是虚拟试穿技术的学术开端。

在这里插入图片描述

2001年至2025年的二十余年间,虚拟试穿技术在学术界的框架演进可分为三个核心阶段:

第一阶段2001年至2013年,主流方案以3D建模、物理仿真及AR(增强现实)技术为核心;

第二阶段2017年至2022年,技术路径转向基于CNN与生成对抗网络(GAN)的框架;

第三阶段2023年起,扩散模型(Diffusion Model)异军突起,此后绝大多数研究都聚焦于这一技术方向,直到现在扩散模型依然是虚拟试穿领域的最主流技术方案。

在这里插入图片描述

与此同时,虚拟试穿技术在学术界“绕不开”的四类核心研究文献可归纳为四类:第一类是生成对抗网络(GAN)方向,相关研究主要集中在2017到2022年,核心都是基于GAN技术来实现虚拟试穿。第二类是扩散模型方向,正如之前提到的,2023年之后这类研究开始爆发,不同的网络结构和试穿任务场景,都能在这个方向找到具有行业影响力的论文。

在这里插入图片描述

另外两类分别是视频试穿方向和套装试穿方向。随着单件服饰图像试穿技术逐渐成熟,学术界开始朝着不同维度拓展研究边界,一个是从静态图像延伸到动态视频,一个则是从单件服饰试穿升级到多件搭配的套装试穿。



4.2 京东零售虚拟试穿技术的四代演进

在这里插入图片描述



而京东零售自2023年启动虚拟试穿项目研发,至今已有两年多的积累,期间历经了四代大的技术框架迭代,积累了丰富实践经验:

第一代是非常早期的架构,以U-Net作为扩散模型主体,搭配Reference Net来实现参考服饰的信息注入。这个框架大家应该比较熟悉,属于Stable Diffusion时代的产物,它的扩散模型参数规模不算大,对应的图像生成效果也相对有限。

在这里插入图片描述



第二代技术框架将扩散模型主体结构从U-Net升级为DiT,服饰信息特征表示借助ViT与VAE完成,与2024年行业技术趋势同步(Sora的出现推动行业普遍完成U-Net到DiT的切换)。这次升级其实和行业趋势同步,2024年年初Sora横空出世,让大家看到了DiT作为扩散模型框架的先进性,因此大部分行业机构都在2024年上半年完成了从U-Net到DiT的技术切换。基于第二代技术框架的实践,我们也沉淀了三个比较重要的认知分享给大家。第一,基座模型的架构和容量对试穿效果起到决定性作用。这一点也印证了扩散模型的Scaling Law,从最初的1B模型,到3B、10B、20B,再到融入VL框架后升级至30B乃至更大参数规模,模型的生成效果有着肉眼可见的提升。第二,利用VAE对参考图像进行编码,能极大提升生成结果的一致性。ViT的表征更偏语义层面,而VAE的训练以重构残差最小为优化目标,更擅长捕捉图像细节。在实际试穿中,若遇到衣服logo等细节还原不佳的问题,往往就是因为没有正确使用VAE编码器来做服饰特征表征。第三,在这套框架的试穿任务中,无需对参考图进行prompt描述,如强行加入文本描述,反而很可能引发图文冲突与对抗。不过这个结论并非绝对,要结合具体技术框架来看,在当前的DiT+ViT+VAE框架下,我们是可以剥离文本模块的,但后续融入VL模型表征后,文本侧的信息也能发挥相应的价值。


在这里插入图片描述

京东零售的第三代虚拟试穿技术,核心完成了从图像试穿到视频试穿的模态升级。目前行业内的视频生成框架尚未形成统一标准,我们可以分享一套可供参考的技术方案:首先将原始视频解析为带mask的视频帧序列,以及类似OpenPose的“火柴棍”姿态帧序列;再分别对这两类序列进行编码、建模、,最终通过MM-DiT完成去噪,生成服饰上身的视频试穿效果。

在这里插入图片描述

而京东零售最新的第四代虚拟试穿技术,这一代框架最显著的变化,就是完全摒弃了Mask模块,全面拥抱Mask Free的通用技术架构。与此同时,参考图的表征方式也从原来的纯视觉维度,进化为融合文本模态的多模态统一表征,这里我们引入了Vision Language Model 视觉语言模型来专门完成参考图的特征提取。基于第四代框架的实践,我们也沉淀了几个关键认知:第一,Mask Free框架对人物的身份特征、肢体姿态、服饰细节以及配饰元素,都能实现更好的保留效果;第二,该框架彻底摆脱了Mask模块可能带来的误差累积,同时大幅降低了工程研发的复杂度。毕竟从研发角度来说,系统模块越简洁,引入连带问题的概率就越低,而Mask模块本身会因不同应用场景产生各种badcase,容易引发新问题;第三,Mask Free框架可以更好地兼容套装试穿,以及服装与配饰的同步试穿需求。举个简单的例子:在传统Mask方案中,需要先mask掉用户原有的衣物,再叠加新服饰,可如果用户原本还斜挎着小包,这个包包大概率会随旧衣被mask掉,相当于破坏了用户的原始信息,而通过Mask Free的技术框架,就能实现“新衣上身,配饰保留”的效果。

4.3 技术小结与核心观点

在这里插入图片描述



结合虚拟试穿技术发展历程和京东零售的技术实践,给正在做或将要做虚拟试穿的企业或相关产研人员建议,可总结以下核心观点:

一是启动项目前一定要拿到最好的图像生成基座模型,因为模型的世界知识和基础能力,直接决定了整个项目的起跑线。请大家始终相信Scaling Law,至少在30B参数规模以内,这种效应的验证效果是非常清晰的。

二是Mask Free技术框架会成为未来的主流方向,大道至简,越简洁的技术路线越正确,如果现在还有同学在Mask based方案里摸索,建议果断舍弃那些冗余的模块,尽快拥抱Mask Free的通用技术框架。

三是从单件试穿到多件试穿是必然的技术趋势,而且必须要兼顾配饰。在我们看来,“试穿+穿搭”才是更具想象力的产品形态。我们现在聊的更多是“穿”的环节,但从产品层面来说,更关键的其实是“搭”的能力。

四是试穿结果的视频化,是用户的核心诉求,这一点毋庸置疑。毕竟线下试衣时,大家都会对着镜子转身、摆动,动态效果才更贴近真实体验。但这需要我们长期攻克推理效率的难题,目前生成一段10秒的试穿视频,耗时基本还是分钟级,这样的速度对线上用户体验的影响是比较大的。

五是数据的价值,用于试穿的训练数据,会成为各大电商平台的核心资产。极致的试穿效果,主要依赖于企业的in-house数据。我们都知道,数据是大模型的核心,虽然有些从业者为了凸显技术深度,会刻意回避甚至弱化数据的重要性,但事实就是如此。尤其是虚拟试穿这类赛道,每个企业都会建立自己的数据壁垒。同时,随着AIGC能力的提升,模型训练早期可以借助AIGC数据快速收敛到任务需求,后续再用真实数据校正,就能有效规避AIGC生成内容带来的失真。



5 虚拟试穿的行业实践方案:国内外典型案例解析

在这里插入图片描述



而在虚拟试穿的行业实践方案,目前国内外电商大厂已推出多款虚拟试穿产品,覆盖C端购物场景与B端商家服务场景,各产品特点与局限性各有不同:

在这里插入图片描述



首先来看整个行业的发展概况,这里有三组关键数据分享。

第一组数据是200亿美元,2025年全球虚拟试穿平台的市场规模预计将突破200亿美元,这其中涵盖图像生成、增强现实(AR)以及3D虚拟试衣等多个细分技术方向,而中国市场的规模,预计将占到其中的50亿美元左右。

第二组数据是60余个品牌,截至今年12月,国内已有超过60家服装品牌对外宣称具备虚拟试穿能力,覆盖快时尚、运动等多个品类,这些品牌的核心分布区域,也集中在欧美中日韩等时尚消费的核心地带,像Zara、Nike、Gap、H\&M,以及中国的李宁、安踏等,都在其列。

第三组数据是60%,有机构预测,到2026年,全球将有超60%的服装品牌采用不同形式的虚拟试穿解决方案,届时,这项技术将从当前的“可选配置”,正式升级为整个行业的“标配能力”。

上方是目前国内外在虚拟试穿领域具备技术储备的部分机构和企业,供大家参考。

5.1 国内C端购物场景案例分析

逐个拆解虚拟试穿行业里几家互联网大厂的典型实践方案。


在这里插入图片描述

阿里Lookie: 它是一款主打虚拟形象搭配试穿的AI娱乐工具。

这款产品的核心特点有两个:一是玩法丰富、搭配自由度高,而且自带很强的分享属性;二是“电子衣橱”的概念很有新意,精准命中了用户多件服饰试穿搭配的潜在需求。

当然,我们也客观地分析一下它当前存在的局限性。第一,Lookie目前仅支持套装试穿,不支持单件试穿。套装试穿在娱乐场景下确实很有吸引力,但电商平台的用户购买行为更多集中在单件服饰,这就形成了一个明显的场景缺口。第二,它作为淘宝的一款中心化小程序,入口相对较深,导致产品的购物属性偏弱。如何从“好玩”迭代到“好用”,最终实现商业变现,是Lookie团队需要重点回答的问题。第三,从试穿效果来看,生成的形象和用户真实身材仍存在一定差异,大家可以去淘宝小程序里亲自体验感受。第四,Lookie的人物形象建模,在一定程度上依赖于LoRA数字分身技术。熟悉这个技术的人应该知道,早期的妙鸭也是这样,需要用户上传十几张个人照片,付费后等待模型训练,才能生成专属数字分身,后续试穿也都基于这个数字分身来完成。但这种技术方案对训练资源的要求较高,算不上是行业内ROI最优的选择。不过值得一提的是,Lookie目前已经开始尝试支持单张图像建模,在降低用户使用门槛上往前又迈出了一步。

在这里插入图片描述



淘宝AI试穿: 它是一款入口布局激进、功能设计清爽的购物助手。

这款产品的核心特点有两个:第一,它的入口直接设置在搜索双列的商卡上,这个位置的选择相当大胆激进,能最大程度触达购物链路中的用户;第二,它的推理速度较快,试穿效果稳定,产品功能也足够聚焦,整体使用体验十分清爽。

当然,它也存在两处明显的局限性:其一,目前淘宝AI试穿仅支持上传用户相册里的全身正面站立照,这个要求对不少用户来说存在使用门槛,而且产品缺乏虚拟形象定制能力,毕竟从相册里找出完全符合要求的照片,并不是一件容易的事。而虚拟形象定制恰恰是降低使用门槛的有效方式。其二,它现阶段只具备单品试穿能力,没有搭载穿搭推荐功能。我们之前提到过,穿搭是试穿场景中非常重要的延展环节。不难发现,阿里的这两款试穿产品在一定程度上形成了互补:淘宝AI试穿专注于单件试穿场景,深度嵌入核心购物链路;而它所欠缺的穿搭能力,正好可以由Lookie小程序来补齐。



5.2 海外C端购物场景案例分析

介绍完国内电商平台的试穿产品,我们再把目光转向海外,看看海外的虚拟试穿技术能力。


在这里插入图片描述



Google Shopping Try On: 这是一款主打高真实性的购物决策工具。

它的核心特点有三个:第一,具备跨端覆盖的试穿能力,同时支持移动端与桌面端,能满足不同用户的使用习惯;第二,服饰覆盖率极高,几乎涵盖了Google Shopping平台上的全量服饰品类;第三,支持用户上传个人照片或使用AI模特,而且对用户上传素材的包容度很高,要知道,通常模特姿态越简单,试穿效果越容易把控,但Google Shopping Try On即便是面对坐姿、非标准站立等有难度的姿态,也能处理得比较好。

当然,它也存在明显的局限性,这点和淘宝AI试穿有些类似,即仅支持单品试穿,暂未开放穿搭组合的试穿功能。

5.3 C端内容电商服务场景案例分析

介绍完货架电商场景下的典型AI试穿能力,我们再把目光转向内容电商,这里以抖音的AI试穿为例来分析。

在这里插入图片描述



抖音AI试穿: 是一款主打“直播+试穿”的新体验产品。

它的核心特点有三个:第一,与直播场景紧密结合,用户从看到商品到完成试穿的链路快捷又易用;第二,同时支持上传用户真实照片和使用AI模特,在一定程度上降低了用户的使用门槛;第三,除了当前入口的商品,还能支持同店铺内的穿搭推荐,正好契合了我们之前提到的试穿延展需求。

这款产品也存在两处局限性:其一,虽然配备了AI模特,但这些模特的肖像和用户本人没有关联,更像是一张“平均脸”,用户会觉得是陌生人在试穿,而非自己,体验上会有割裂感;其二,它的其中一个试穿入口设置在商品详情页的尺码助手附近,而目前行业内并没有成熟的技术能支持尺码合身效果的试穿,这就容易给用户造成误导,用户本以为点进来能看尺码是否合适,实际却只能看到服饰上身的基础效果,从产品入口设计的角度来看,还有进一步优化的空间。

5.4 B端商家服务场景案例分析

介绍完面向C端的虚拟试穿产品方案,接下来看一个B端的典型案例。

在这里插入图片描述

阿里绘蛙: 这是一个专门服务服饰电商商家的AI内容生成平台。

核心特点有三个:第一,自带海量素材库,涵盖参考图与模特素材,为商家提供了充足的选择空间;第二,同时支持单件与多件服饰上身生成,而且输出素材的分辨率较高,清晰度能满足电商展示、内容种草等多类场景的需求;第三,试穿功能可与平台内其他AI工具无缝联动,比如用试穿能力生成效果图后,能直接在平台内调用图像编辑功能进行二次优化,操作流程十分顺畅。

当然,绘蛙也存在一些局限性:一方面,作为B端生成式服务平台,它目前的生产效率相对偏低,推理耗时基本是分钟级,暂不支持大量素材的批量生成,这对于有规模化生产需求的商家来说是个不小的遗憾;另一方面,受B端的产品定位所限,平台缺少C端用户的使用场景,毕竟普通消费者更习惯在手机购物链路中使用试穿功能,而绘蛙的核心用户群体始终是电商商家,主要用于制作商品相关素材。

5.5 行业分析小结

在这里插入图片描述

结合上述案例,可总结行业实践核心要点,从四方面展开:

第一,B端与C端的定位分化清晰,PC端或Web端聚焦服务B端商家,提供模特生成、AI试穿、素材二次编辑等能力,批量化、低成本生产是商家的核心诉求。如果平台能打通“素材生产—投放—效果验证”的闭环,并将验证结果反馈给模型辅助进化,会成为中小商家的一大福音。而APP端或小程序端则瞄准C端用户,主打简化操作流程,联动购物闭环以适配移动端的碎片化体验;再次强调,对于C端而言,“穿”是刚需,但“搭”才蕴藏着更多产品机会。

第二,入口形态决定产品定位。电商平台的AI试穿入口无非两种:第一种是非中心化入口,将试穿能力嵌入购物全流程,比如直接放在每个商品的商卡上,实现“见品即试穿”,核心目标是强化用户的及时决策;第二种是中心化入口,类似阿里Lookie的小程序单入口,不依附于具体sku,能打造独立场景,延伸穿搭推荐、社交分享等功能,让产品从购物工具升级为内容娱乐的社交载体。

第三,通过多元方案降低用户使用门槛。针对用户相册难以找到合格全身照的痛点,行业内普遍采用多种路径打破传图依赖:一是虚拟捏人;二是非标图像兼容,提升算法能力,支持半身照等非标准素材试穿,比如用半身照试穿上衣;三是“大头照+身材参数”实现数字形象,以此降低C端用户的试穿启动门槛,这些都是值得肯定的产品尝试。

第四,尺码破局需要技术与策略双重保障。单纯依靠算法模型,很难解决尺码合身的试穿问题。行业的可行思路是联动尺码助手、用户试穿报告等策略工具,用“技术生成效果+策略辅助决策”的双重模式降低用户购物决策风险,最终实现退货率的下降。



6 京东的虚拟试穿实践:产品特点与核心经验

在这里插入图片描述

6.1 京东虚拟试穿产品现状

在这里插入图片描述

京东零售虚拟试穿产品目前处于小流量测试阶段,产品主要有四大特点:精准的身材识别、逼真的材质渲染、高效快速的生成、智能的搭配推荐,这也是京东零售虚拟试穿一直持续打磨的产品目标。现阶段产品已覆盖超百万服饰SKU,实验阶段用户量突破100万,覆盖70多个服饰类目,合作头部服饰品牌超500家。

在这里插入图片描述

从具体功能来看,产品设计包括三大核心模块:

一是最左侧图示,商详主图的试穿入口,目前这个入口的设置比较保守,没有像淘宝AI试穿那样直接嵌入搜推双列商卡,我们认为在实验阶段,还是尽量避免影响用户原有的购物体验,后续会根据测试效果考虑提升入口优先级。

二是中间三张图示,我们重点探索的同款不同色服装试穿,用户从某一款颜色的服饰(比如图中的粉色羽绒服)进入试穿页面后,可以一键切换同SPU下的白色、黑色等其他配色,便捷完成多色试穿对比。

三是最右侧图示,我们正在积极推进的上下装搭配试穿,系统会为入口服饰,比如这件羽绒服,匹配同店铺内的裤子、裙子等下装,让用户直观感受不同搭配的视觉效果。当前我们把搭配候选池限定在同店铺内,从消费者视角来看,打破店铺限制可能会更有吸引力。从技术层面来讲,跨店铺搭配的实现难度也并不大,核心在于业务逻辑的梳理,这需要我们与商家做更深入的调研沟通,明确背后的商业价值后,再考虑进一步的功能升级。

6.2 京东虚拟试穿产品实践经验

在这里插入图片描述



京东在虚拟试穿项目实践中沉淀下来的三点核心经验:

一是需全力降低用户使用门槛——我们有一组数据可以佐证这个观点,目前线上使用虚拟试穿的用户中,超过半数无法上传符合要求的试穿照片。即便我们在上传页面做了详细的规则引导,用户从相册里找到合规照片的难度依然很高。为此,我们果断加入了数字人模式,采用“真实照片上传+虚拟数字人形象”的双轨方案,用户如果找不到合适的照片,或者不愿上传个人照片,就可以输入身高、体重等参数打造专属数字人;若能提供肖像照,数字人会更贴近用户本人,没有肖像照也可以使用默认形象,这是降低用户使用门槛非常行之有效的方法。

二是穿搭场景中,“搭”大于“穿”。正如之前提到的,“穿”是用户的基础性刚需,而“搭”属于突破性需求。但在电商场景下,用户对穿搭的期待其实很高,所以我们一直在积极探索为用户提供多样化的搭配可能性,以此挖掘更多产品价值。

三是试穿效果要兼顾“像”与“美”,二者缺一不可。这一点往往被很多项目组忽略。用户对试穿效果的核心要求是“真、像、美”:“真”是衣服和人物的真实感,不能有明显的AI痕迹;“像”是人物ID、服饰细节、环境背景的精准保留;而“美”常常被忽视,但其实至关重要。我们在算法侧也把评测标准,从最开始的“衣服还原不出错”,升级为“可用率+美观度”的多维度评估体系。这里可以举个例子:大家做虚拟试穿,都是希望提升转化率、降低退货率,但如果忽略了“美”的需求,很可能连转化率都会受影响。没有试穿时,用户看商详主图觉得衣服不错就会下单,但AI试穿后发现效果不好看,反而会直接放弃购买。这其实是大模型在落地原生AI场景时会遇到的阵痛,所以我也呼吁行业同仁,面对这类问题要保持长期心态,用户心智的培养和行业的迭代,都需要一个过程

6.3 京东虚拟试穿未来探索方向

在这里插入图片描述



结合行业趋势、实践经验与用户需求我们认为未来值得探索的虚拟试穿产品形态,以下三类产品形态具有较高探索价值:

第一个是万物成套的试穿试戴系统,服饰试穿已经从单件升级到多件,但对于注重OOTD的用户来说,鞋子、配饰、包包甚至手机壳,都是穿搭的重要组成部分。我们希望未来能实现全品类的组合式穿搭,打造真正的“万物穿搭”试穿效果。

第二个是数字人虚拟试穿+AI导购,想象一下,每个用户都有专属的数字人形象,它既可以是你的分身,也可以是你的AI导购助手。你在逛商品流的时候,轻触商卡就能把衣服“穿”到数字人身上,同时还能和这个数字人对话,让它帮你推荐搭配,实现7×24小时的购物陪伴。这其实也是电商2.0时代追求的极致沉浸式个性化体验,我们甚至畅想过一个更极端的场景:用户浏览服饰商卡时,卡面展示的就是自己穿着这件衣服的形象,滑一屏都是专属的上身效果,选款会更直观。不过这种形态需要充分尊重用户意愿,避免造成冒犯,同时也面临着推理资源、生成效率等工程侧的巨大挑战。

第三个是电子衣橱。这个概念虽然已有部分产品提及,但我们认为还有很大的深挖空间。用户可以把已购、收藏的服饰都放进这个虚拟衣橱,系统根据天气、出席场合等场景,为用户提供交互式、陪伴式的试穿搭配建议,真正实现“衣随场景搭”。

7 从虚拟试穿到全域布局:京东电商AIGC能力矩阵

在这里插入图片描述

7.1 京东电商AIGC能力矩阵

从虚拟试衣切入,到更大范畴的电商AIGC。京东零售在电商AIGC领域的能力布局,整体可以分为八大能力板块,全面覆盖商品素材制作、营销推广、用户体验等关键环节。

在这里插入图片描述

第一,商品智能抠图。这是所有电商平台最关键、最基础的技术能力,抠图效果的优劣,直接影响后续整条素材制作链路的最终呈现质量。第二,商品素材生成。我们依托AIGC技术,实现主图、商详图、广告素材的自动化生成。在技术加持下,内容制作周期大幅缩短,素材迭代效率提升了数十倍。第三,视频生成。从2024年开始,视频生成技术的效果已经被大家广泛认可,国内相关技术也实现了大幅跃升。我们主要聚焦主图视频和营销视频两大场景:主图视频时长较短、镜头单一,主打快速展示商品核心卖点;营销视频则篇幅更长、内容更丰富,通常会搭配剧本与口播,用于深度种草和品牌宣传。第四,AI模特。这项能力不仅服务于服饰场景,也覆盖了众多非服饰品类的素材生成需求。传统模式下,头部商家会邀请明星代言,中型商家则需要对接外部服务商拍摄,不仅成本高昂,还会拖慢商品上新节奏。而AI模特能力通过AIGC技术,为商家快速生成适配不同场景、不同风格的模特素材,有效降本增效。

在这里插入图片描述

第五,虚拟试穿。这项能力不过多赘述了,今天的分享主题基本都围绕它展开,核心是通过AIGC技术实现服饰的虚拟上身与搭配,降低用户决策成本。第六,AI设计家。也可以称之为“放我家”功能,主要服务于家具等大件商品场景。用户上传自家房屋照片后,AI就能将目标家具植入到真实家居环境中,直观呈现摆放效果;同时还能针对毛坯房、清水房,按照用户需求设计出对应的装修风格,解决家居选购与装修设计的可视化难题。第七,3D立影。这是京东零售自研的AIGC裸眼3D技术,能让商品从商卡中“跳脱”出来,以3D形态呈现。这项技术能显著提升品牌商品的点击率,以及直播场景下的用户互动率。第八,数字人。相信大家对京东数字人并不陌生,目前已有超2万个品牌在使用这项能力,相关场景的转化率提升了30%。它最直接的价值是实现7×24小时数字人直播卖货,打破传统直播的时间限制,持续为商家创造收益。

7.2 京东电商AIGC实践案例

接下来,选取其中几项能力,展开分享京东零售在业务侧取得的实际成果。

在这里插入图片描述

第一个是商品素材AIGC生成。这里展示的是一款起泡酒的案例,覆盖商品主图、商详图、卖点图和广告图等全类型素材。目前这项能力已经改变了京东超100万商家的内容设计模式,既大幅提升了素材制作效率,又显著降低了制作成本。


在这里插入图片描述



第二个是AI模特。模特图生成技术正逐步在头部品牌中批量落地,我们过去已与Nike、阿迪达斯、海澜之家三大时尚品牌达成深度合作。在批量应用阶段,合作品牌的商品转化率提升29%,商品上架速度提升90%,同时商品素材制作成本大幅下降。大家现在在这些品牌店铺里看到的部分模特图,正是由我们的AIGC技术生成,再结合虚拟试穿能力完成服饰上身的。


在这里插入图片描述



第三个是AIGC裸眼3D技术,立影。这里有SK-II和华为耳机两组合作案例,这项技术能明显带动品牌点击率与销售转化率的提升。目前它主要应用于广告投放、家具搭配、直播互动、互动游戏以及试装试戴等场景。

7.3 京东电商AIGC设计智能体:焕新版京点点Oxygen Vision

在这里插入图片描述



京东零售电商AIGC内容生成平台“京点点”整合了上述大部分能力,目前已支持超过30种业务场景(覆盖商品发品、运营、营销等环节),日能力调用量超1000万次,服务超100万京东商家,助力商家内容生产成本降低90%,生产效率提升95%。

在这里插入图片描述



近期,京点点平台完成系统性升级,焕新版命名为Oxygen Vision平台。新版平台和老版最大的差别,一方面是集成了更多的AIGC能力项,另一方面则是把交互形式从原来的纯GUI交互,升级为Linguistic UI + GUI的混合模式。

具体来说,新版平台具备四大核心特点:第一,对话式人机交互,支持纯自然语言的交互方式,操作更便捷;第二,大模型驱动的任务规划与执行,能够拟人式地分步骤、有序完成各项操作;第三,强一致性且不失多样性的商品素材生成能力,确保生成内容既贴合商品属性,又能满足多样化需求;第四,无缝接入京东AB实验平台的能力。正如我们之前所说,一个合格的B端AIGC内容生成平台,必须打通“素材生产—投放—实验回收—模型迭代”的完整闭环,而这一点,新版京点点平台已经完全具备。

在这里插入图片描述



8 电商AIGC的未来展望:技术纵深与商业价值

在这里插入图片描述



8.1 AIGC应用的三层分类与技术复杂度

在这里插入图片描述

最后未来展望,来看电商AIGC的技术纵深与商业价值,分享个人观点和思考。

首先,从上图来看,AIGC的应用分成了三个层次。最底层的是创意类应用,这类应用的自由度高、约束少,核心是满足用户的个性化表达需求,比如短视频平台的魔法表情特效,运营活动需要的banner海报、插画设计,都属于这个范畴。往上一层是影视类应用。如果大家了解即梦、可灵、海螺这些视频生成工具,应该会有体感,这类应用的核心是通过AIGC实现角色和场景的一致性保持,技术难点也集中在这里。不过说实话,普通消费者对于这类内容的细节一致性,敏感度其实没那么高。而最上层的,就是我们今天一直在聊的电商类AIGC,这个方向,需要解决海量SKU的适配问题,要确保商品信息的准确传递,还要满足实时转化的业务诉求,同时还要应对严格的合规风险。

如果从技术复杂度排序,创意类最简单,影视类次之,电商类堪称地狱级难度。为什么这么说?因为电商AIGC对商品一致性的要求是极致严苛的,哪怕是一个细节的偏差,比如裙子本该没有花边,生成的素材里却加了花边,用户收到货发现“货不对版”,就可能引发客诉,甚至是官司。这和影视类的一致性要求完全不是一个量级,更别说创意类的开放创作模式了。但有意思的是,这三类应用里,电商类AIGC恰恰是距离商业化、距离“钱”最近的。做了这么久的AIGC应用,有一个很直观的体感:有两类应用场景是可以直接实现变现的。第一类,就是影视类AIGC。这个很好理解,举个例子,拍摄《速度与激情》时,要呈现兰博基尼和法拉利相撞的画面,在没有AIGC技术之前,这样一个镜头的成本可能高达上百万;而现在,依托可灵、即梦这类视频生成工具,成本有可能直接降到几百美金。无论是文本生成视频、图像生成视频,还是首尾帧驱动的视频生成技术,都能支撑这类特效镜头的制作。更值得一提的是,现在很多视频生成能力还叠加了音画直出功能,这让电影级别的多媒体内容高效输出,变得越来越有可能。第二类,就是电商与商业化AIGC。这里我们暂时不做细致区分,核心逻辑很简单:我们用AIGC生成的电商素材,是直接供商家用于商品运营和投放的,最终指向的就是GMV的增长,这是最直接的收益。商业化场景也是同理,通过AIGC制作广告素材,直接面向广告主和用户,素材投放后带来的广告消耗,直接对应着平台的营收。所以在我看来,电商与商业化AIGC,是现阶段离“钱”最近的应用方向。这就是个人对整个AIGC行业应用落地的一些理解。

8.2 未来展望

在这里插入图片描述

最后,再分享三个总结性的观点。

第一,从技术角度来看,像虚拟试穿这类垂直业务,未来不会再依赖专属定制模型。一个明确的技术趋势是,越来越多的电商AIGC任务,会统一到通用大模型框架之下,就像nano banana pro这类架构一样,用户只需要在prompt层面定义好业务需求,就能完成相应任务。只不过现在还有不少虚拟试穿方案,还停留在定制化思路上,这个转变需要一个过程。

第二,想和所有AIGC创业者、以及大厂里做AI提效的同学聊一句:不是所有业务都需要升级到LUI(对话式交互)的形式。有些功能用GUI(图形界面)来承载,体验反而会更好。不要觉得套上LUI的壳,就是做了AI native的升级,很多时候这种做法反而属于“故弄玄虚”。这两年大家应该也见过不少“AI小助手”“智能XX工具”,本质上就是把原来的GUI功能强行改成对话式,看似用上了大模型和Agent,实际体验反而不如从前。尤其是编辑类需求,图形化的交互方式往往更直接高效。而新京点点平台之所以选择LUI+GUI的混合模式,核心是看服务对象,我们主要服务的是京东的采销同学。他们每个人负责的SKU数量极多,不可能针对每个商品去定制化制作素材,更需要“一句话指令”就能自动生成内容的傻瓜式操作。这样才能让采销把精力聚焦在拿货、议价、仓储运营这些核心工作上,而不是耗费在素材制作上。

第三,关于电商2.0核心方向,极致的沉浸式与个性化购物体验是核心目标。虚拟试穿是沉浸式体验的重要探索,而个性化购物的底层支撑是“千人千面”的商品素材生成能力。这也是京东在探索大模型时代电商2.0形态的一条核心技术路线。大家对“千人千面”并不陌生,过去京东零售的搜索推荐就是如此,同样搜索一个关键词,不同用户看到的结果页截然不同。但到了商品素材层面,目前商品素材仍处于“千人一面”状态,商家只维护了一套主图、商详图和卖点介绍。而“千人千面”的商品素材生成,就是要打破这种单一性。比如:一款中性款冲锋衣,面对三类不同需求的买家,可以用算法提炼出他们各自关注的核心卖点,定制差异化的素材,既精准吸引用户,又提升购物体验。第一类是户外功能型买家,他们最关心面料科技、防风防水、透气耐磨这些专业指标,AI就在商品图上重点呈现这些性能参数;第二类是外观穿搭型买家,他们不纠结材质,只在意设计风格、版型潮流和穿搭适配,AI就主打OOTD相关的素材生成,突出颜值和搭配感;第三类是价格敏感型买家,他们不关注功能和颜值,只看价格、优惠和赠品,AI就直接在图片贴片上展示最低价标识、优惠券、赠品信息等内容,实现精准引流与体验提升。通过这个案例,大家应该能更直观地理解什么是“千人千面”的商品素材能力。当然这个话题还有很多细节可以展开,可点击查看《从 “千人千面” 的搜索推荐到 “千人千面” 的商品素材技术探索》文章,里面有更详尽的介绍。

原文链接:https://tecdat.cn/?p=44886
原文出处:拓端抖音号@拓端tecdat

封面

全球新能源转型进入“技术决胜”关键期,电池产业作为核心支撑,正迎来技术迭代与市场爆发的双重机遇。固态电池以能量密度突破续航天花板,钠离子电池凭低成本填补细分场景,液流电池扛起长时储能大旗,等静压设备则成为产业化落地的“核心装备”——四大技术路线齐头并进,重塑全球能源格局。

本报告洞察基于《华金证券:固态电池系列报告:锂金属负极》《中关村储能产业技术联盟:集装箱锂电池储能系统自律实践指南(2025版)》《BCG波士顿咨询:2025年全球液流电池产业白皮书》《天风证券:电力设备:固态电池设备的瓶颈-等静压》和文末300+份电池产业行业研究报告及数据,本文完整报告数据图表和文末最新参考报告合集已分享在交流群,阅读原文查看、进群咨询,定制数据、报告和800+行业人士共同交流和成长。

一、核心技术与市场数据图表分析 

图表1:固态电池能量密度比较刻度线图


固态电池能量密度呈现“阶梯式突破”:锂金属负极固态电池能量密度最高达383Wh/kg,远超传统磷酸铁锂电池(160Wh/kg)和硅碳负极电池(3590mAh/g对应的能量密度上限),接近400Wh/kg的产业化目标。这一突破直接破解新能源汽车“续航焦虑”,使超千公里续航成为可能,同时为无人机、低空经济等对能量密度敏感的场景提供技术支撑。
固态电池能量密度比较刻度线图表1数据EXCEL及图表PDF模板已分享到会员群

图表2:全球固态电池出货量预测折线图


全球固态电池出货量将从2025年的19.68GWh飙升至2030年的614.1GWh,年复合增长率高达82%,增速远超传统锂电池。这一爆发式增长背后,是全固态电池技术成熟(2027年小规模量产)、车企装车需求(2026-2027年头部车企陆续落地)、政策支持三重驱动,预计2028年后将进入规模化应用期,成为动力电池高端化的核心选择。
全球固态电池出货量预测折线图表2数据EXCEL及图表PDF模板已分享到会员群


相关文章

专题:2025全球能源转型与电力数字化发展报告|附300+份报告PDF、原数据表汇总下载
相关文章

原文链接:https://tecdat.cn/?p=42778 


图表3:硫化物全固态电池材料成本占比半圆环图


硫化物全固态电池材料成本中,锂金属负极占比约23%,硫化物电解质占比18%,高镍三元正极占比35%,其他材料占比24%。成本结构显示,正极与负极是降本核心——锂金属负极通过蒸镀法工艺优化(成本降至4.3美元/㎡)、硫化物电解质通过规模化量产(2030年成本下降40%),将推动全固态电池成本从2025年的1.5元/Wh降至2030年的1.2元/Wh,逐步接近传统锂电池成本水平。
硫化物全固态电池材料成本占比半圆环图表3数据EXCEL及图表PDF模板已分享到会员群

图表4:中国新型储能累计装机容量面积图


中国新型储能累计装机容量截至2025年上半年突破101.3GW,同比增长110%,其中锂离子电池储能占比92.64%,液流电池、钠离子电池等新型技术占比7.36%。增长趋势显示,电源侧、电网侧长时储能需求(100MWh以上项目)推动液流电池装机快速增长,用户侧、偏远地区储能需求带动钠离子电池渗透,技术多元化格局逐步形成。
中国新型储能累计装机容量面积图表4数据EXCEL及图表PDF模板已分享到会员群

图表5:锂离子与液流电池平准化储能成本比较分组条形图


平准化储能成本(LCOE)对比显示:2025年锂离子电池储能成本约0.46元/Wh,液流电池约132美元/kWh(折合人民币0.95元/Wh);但液流电池循环寿命(10000+次)是锂离子电池(3000次)的3倍以上,全生命周期成本仅为锂离子电池的60%。这一差异使液流电池成为100MWh以上长时储能项目的最优解,而锂离子电池仍主导中短期储能场景。
锂离子与液流电池平准化储能成本比较分组条形图表5数据EXCEL及图表PDF模板已分享到会员群

图表6:全球液流电池累计装机容量堆叠面积图


全球液流电池累计装机容量从2025年的6GWh增长至2030年的50GWh,年复合增长率53%,其中中国占比超60%,成为全球液流电池产业核心市场。增长动力来自电网长时储能需求(新能源消纳、电网调频)和技术突破(电解液循环效率提升至95%),预计2027年后将进入GW级装机爆发期。
全球液流电池累计装机容量堆叠面积图表6数据EXCEL及图表PDF模板已分享到会员群

图表7:钠离子电池性能与经济性优势分组条形图


钠离子电池在性能与经济性上呈现双重优势:能量密度125Wh/kg,虽低于锂离子电池,但成本仅0.3元/Wh(为锂离子电池的65%);低温性能(-20℃容量保持率70%)、安全性(热失控风险低)更优。这使其在低速电动车、家庭储能、偏远地区储能等细分场景具备不可替代性,预计2030年中国钠离子电池出货量将达41.78GWh,年复合增长率75%。
钠离子电池性能与经济性优势分组条形图表7数据EXCEL及图表PDF模板已分享到会员群

图表8:固态电池设备投资结构华夫图


固态电池设备投资结构中,中道设备占比45%,其中等静压设备占中道设备的13%,成为核心增量环节;前段设备(干法电极、蒸镀设备)占35%,后段设备(高压化成、检测设备)占20%。投资结构反映,等静压设备、干法电极设备是固态电池产线建设的“关键投入”,其技术成熟度直接决定产线良率与产能爬坡速度。
固态电池设备投资结构华夫图表8数据EXCEL及图表PDF模板已分享到会员群

图表9:等静压技术参数比较雷达图


雷达图显示三类等静压技术的参数差异:冷等静压在“工作压力(100-630MPa)”“量产效率”上领先,温等静压在“界面适配性”“成本平衡”上最优,热等静压在“致密化率(>99.8%)”上突出。固态电池生产中,温等静压因兼顾压力(300MPa)、温度(80-120℃)与成本,成为硫化物、氧化物全固态电池的主流选择,可有效解决固-固界面接触不良问题。
等静压技术参数比较雷达图表9数据EXCEL及图表PDF模板已分享到会员群

图表10:等静压设备市场规模预测折线图


等静压设备市场规模将从2025年的3.25亿元爆发至2030年的66亿元,年复合增长率89%,成为电池设备赛道增速最快的细分领域。增长核心驱动是固态电池产业化(2026-2027年中试线转量产线),其中温等静压设备占比将从2025年的40%提升至2030年的65%,成为市场主流。
等静压设备市场规模预测折线图表10数据EXCEL及图表PDF模板已分享到会员群

图表11:固态电池设备投资结构圆环图


固态电池设备投资结构圆环图显示:中道设备(等静压、叠片机)占比45%,前段设备(干法电极、蒸镀设备)占35%,后段设备(高压化成、检测设备)占20%。与传统锂电池设备相比,固态电池新增干法电极设备、等静压设备两大增量环节,设备投资总额提升30%-50%,但核心设备(如等静压)的技术壁垒更高,头部企业(川西机器、先导智能)将占据主导地位。
固态电池设备投资结构圆环图表11数据EXCEL及图表PDF模板已分享到会员群

图表12:等静压技术参数比较刻度线图


刻度线图清晰呈现等静压技术的核心参数差异:冷等静压工作压力100-630MPa、常温工作,适合规模化量产;温等静压工作压力300MPa、温度80-120℃,适配固态电池固-固界面优化;热等静压工作压力100-200MPa、温度1000-2000℃,用于高端陶瓷电解质制备。参数差异决定了冷等静压主导中试/量产线,温等静压成为全固态电池核心设备,热等静压聚焦高端材料研发。
等静压技术参数比较刻度线图表12数据EXCEL及图表PDF模板已分享到会员群

二、核心数据对比表(不同电池技术关键指标)

电池产业的竞争,本质是“精准适配场景”的较量——就像不同交通工具对应不同出行需求,四大技术路线各有专攻,在能量密度、成本、寿命之间找到最优解:

技术类型能量密度成本水平循环寿命核心应用场景数据来源报告差异原因分析
锂金属负极固态电池383Wh/kg1.5元/Wh(2025E)1000+次新能源汽车、无人机华金证券《固态电池系列报告:锂金属负极》材料体系升级,锂金属负极提效
钠离子电池125Wh/kg0.3元/Wh2000次低速电动车、家庭储能华创证券《钠离子电池:突破关键资源瓶颈》原材料丰富(无钴镍),工艺简化
液流电池80-100Wh/kg132美元/kWh(2025E)10000+次电网长时储能BCG《2025年全球液流电池产业白皮书》电解液可循环,结构设计适配长时
磷酸铁锂电池160Wh/kg0.46元/Wh3000次动力电池、储能华创证券《钠离子电池:突破关键资源瓶颈》技术成熟,规模化降本

3秒解读:固态电池赢在“高能”,适配高端动力场景;钠离子电池胜在“低价”,抢占下沉市场;液流电池强在“长寿”,支撑电网储能;磷酸铁锂电池稳在“成熟”,保障基础需求。
对应人群行动建议:车企优先布局固态电池技术合作,小微企业聚焦钠离子电池细分场景,电网企业重点考察液流电池方案,储能项目开发商可灵活搭配磷酸铁锂电池降低短期成本。

三、可落地行动清单(3件优先级最高的事)

  1. 布局固态电池的企业,优先与赣锋锂业、英联股份等合作验证蒸镀法/压延法工艺,同步锁定川西机器、先导智能等温等静压设备供应商,缩短中试周期6-12个月,规避技术路线试错成本。
  2. 储能项目开发商针对100MWh以上长时项目,2026年前完成液流电池与锂电池的全生命周期成本测算,重点参考德州电网旧电池储能项目的运营数据,聚焦电解液循环成本、设备维护成本,避免短期投资误判。
  3. 钠离子电池企业聚焦电动两轮车、偏远地区储能试点,与上游纯碱企业签订长期供货协议,锁定正极材料(普鲁士白)供应,规避2026-2028年产能不足风险,同时联合热管理企业优化低温适配方案。

四、隐藏风险提示(报告未明确提及的坑)

  1. 固态电池界面阻抗问题可能导致实际循环寿命不及实验室数据,批量生产时需额外投入界面改性成本(占总成本15%左右),建议与材料企业联合研发,优化界面贴合技术。
  2. 钠离子电池低温性能衰减(-20℃容量保持率不足70%),北方地区应用需配套加热装置,推高系统成本10%-15%,可优先布局南方市场或室内储能场景。
  3. 等静压设备依赖进口核心部件(如高压密封件),地缘政治可能导致交货周期延长至12个月以上,建议提前6-12个月备货,同时关注国产替代企业技术进展。

五、核心数据总结表(产业规模预测)

领域2025年规模2030年规模年复合增长率
全球固态电池出货量19.68GWh614.1GWh82%
中国钠离子电池出货量2.73GWh41.78GWh75%
全球液流电池装机容量6GWh50GWh53%
等静压设备市场规模3.25亿元66亿元89%

3秒解读:等静压设备增速最快(89%),是固态电池产业化的“关键受益环节”;固态电池规模最大,2030年突破600GWh;钠离子电池潜力凸显,低基数下实现75%高增长。
对应人群行动建议:投资者可重点布局等静压设备及固态电池材料企业;企业可根据场景选择技术路线,供应商需提前扩产适配爆发式需求。

六、固态电池产业化路径流程图

<pre data-index="0" name="code" style="color: rgb(0, 0, 0); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><img alt="" src="https://i-blog.csdnimg.cn/direct/d085b544372c460fac383ee9bda793e5.png" style="border: 0px; max-width: 650px;">
</pre>

文末图表列表

  1. 固态电池能量密度比较刻度线图表1
  2. 全球固态电池出货量预测折线图表2
  3. 硫化物全固态电池材料成本占比半圆环图表3
  4. 中国新型储能累计装机容量面积图表4
  5. 锂离子与液流电池平准化储能成本比较分组条形图表5
  6. 全球液流电池累计装机容量堆叠面积图表6
  7. 钠离子电池性能与经济性优势分组条形图表7
  8. 固态电池设备投资结构华夫图表8
  9. 等静压技术参数比较雷达图表9
  10. 等静压设备市场规模预测折线图表10
  11. 固态电池设备投资结构圆环图表11
  12. 等静压技术参数比较刻度线图表12

封面

本专题内的参考报告(PDF)目录

  • 中科院128页:全固态电池技术研究进展.pdf
  • 2026-01-25 12:40
  • 兴业证券:固态电池蓄势待发,设备先行关注显性变化环节.pdf
  • 2026-01-25 12:26
  • 江苏省市场监督管理局:2025内外贸一体化认证服务指南-动力电池产业.pdf
  • 2026-01-19 16:51
  • 浙商证券-锂电设备行业系列深度报告三:等静压设备行业深度,固态电池核心增量环节.pdf
  • 2026-01-16 15:16
  • 钠离子电池行业专题报告1:性能适配与经济性共振,有望迎来发展新周期.pdf
  • 2026-01-15 15:32
  • 固态电池专题报告:技术创新与多元应用展望.pdf
  • 2026-01-13 16:07
  • 电力设备与新能源行业固态电池深度研究报告:电池变革重要赛点,材料设备全新颠覆.pdf
  • 2026-01-11 09:25
  • 2025年电力设备行业固态电池系列报告:全球积极布局,固态持续推进.pdf
  • 2026-01-11 09:24
  • TÜV莱茵:2025年动力电池可持续再利用安全管理白皮书.pdf
  • 2026-01-07 10:20
  • 中国蓄电池行业出海国别机会洞察报告.pdf
  • 2026-01-07 10:19
  • 从电池巨头加码高压实铁锂布局看草酸景气向上机遇.pdf
  • 2026-01-06 12:26
  • 固态电池行业深度报告:材料和工艺设备体系革新,固态电池产业化加速.pdf
  • 2026-01-05 15:53
  • 2026年我国新型电池产业发展形势展望.pdf
  • 2026-01-04 16:42
  • 电力设备及新能源行业之光伏电池设备专题报告:暗线潜影织金络,晶硅叠层启玄机.pdf
  • 2025-12-31 15:42
  • 港股储能电池标的梳理.pdf
  • 2025-12-30 14:38
  • 固态电池之等静压设备行业深度:应用领域、技术壁垒、竞争格局及相关公司深度梳理.pdf
  • 2025-12-30 14:38
  • 全固态电池设备投资的五条主线.pdf
  • 2025-12-22 15:10
  • 2025武汉市汽车动力电池行业中小企业数字化转型实践样本.pdf
  • 2025-12-22 15:08
  • 固态电池系列专题:什么是等静压设备?.pdf
  • 2025-12-16 16:11
  • 幸福招商:2025固态电池产业产业化阶段及招商机遇研究报告-简版.pdf
  • 2025-12-15 16:24
  • eVTOL电池篇:固态电池曙光在即,eVTOL有望迎来全新升级.pdf
  • 2025-12-05 16:44
  • 电气设备行业固态电池系列3:全固态电池工程化核心难点在哪?.pdf
  • 2025-12-03 15:42
  • 东莞证券:锂电池产业链2026年上半年投资策略.pdf
  • 2025-12-03 15:42
  • 2025年全球液流电池产业白皮书迈向大规模长时储能之路-BCG.pdf
  • 2025-12-02 17:46
  • 电池:一项技术简介.pdf
  • 2025-12-02 17:42
  • 固态电池系列1:全球政策与各国发展路径全景对比——政策风起,产业破晓.pdf
  • 2025-12-02 17:35
  • 低空航空器动力电池技术路线图(2025 版).pdf
  • 2025-12-01 15:31
  • BCG波士顿咨询:2025年全球液流电池产业白皮书.pdf
  • 2025-11-27 15:45
  • 锂离子电池基础知识培训.pdf
  • 2025-11-25 15:33
  • 固态电池设备行业专题深度系列二:干法成膜——高性能固态电池量产的关键.pdf
  • 2025-11-24 14:59
  • 高效电镀铜栅线异质结晶硅电池量产技术.pdf
  • 2025-11-12 15:26
  • 固态电池设备行业深度报告——固态电池春山可望,工艺设备体系重塑.pdf
  • 2025-11-08 17:40
  • 刘彦龙:2025年我国锂离子电池产业发展形势报告.pdf
  • 2025-11-06 16:36
  • 集装箱锂电池储能系统自律实践指南(2025版)-中关村储能产业技术联盟.pdf
  • 2025-10-27 16:12
  • 固态电池系列报告之三:车端应用加速,产业链有望迎来变革.pdf
  • 2025-10-26 08:49
  • 起点研究院32页PPT:2025中国固态电池行业发展研究报告.pdf
  • 2025-10-21 16:56
  • 陕煤集团:2025年固态电池行业研究报告.pdf
  • 2025-10-17 16:03
  • 2025年中国电池储能盈利模式探索:加州经验的启示.pdf
  • 2025-10-14 15:25
  • 天风证券:电力设备:固态电池设备的瓶颈-等静压.pdf
  • 2025-10-13 09:45
  • 助力电池储能行业走向更安全、更可持续的发展之路.pdf
  • 2025-09-30 16:39
  • 华金证券:固态电池系列报告:锂金属负极.pdf
  • 2025-09-30 16:36
  • UL Solutions:2025年助力电池储能行业的可持续之路白皮书.pdf
  • 2025-09-26 14:22
  • 深企投:2025年固态电池产业链研究报告.pdf
  • 2025-09-14 19:33
  • 固态电池行业深度:固态中试线加速落地,各材料环节全面升级.pdf
  • 2025-09-13 16:31
  • 206页!先进储能电池及集成设备生产项目环境影响报告表.pdf
  • 2025-09-12 16:31
  • 固态电池设备行业专题深度系列一:等静压设备——制约固态电池量产的关键瓶颈.pdf
  • 2025-09-02 17:06
  • 动力电池电芯的电气绝缘:高强度蓝膜与UV涂层的技术对比.pdf
  • 2025-09-01 16:31
  • 固态电池系列之干法电极专题报告:革新技术,方兴未艾.pdf
  • 2025-09-01 16:24
  • 固态电池系列深度一:产业化浪潮将至,设备领域布局正当时.pdf
  • 2025-08-30 16:14
  • 汽车行业数字电池护照:对汽车可持续发展的主要贡献,以及创造价值的机会.pdf
  • 2025-08-27 16:51
  • 五矿证券-电气设备行业专题报告:晶硅电池铜代银方案还有多久产业化?.pdf
  • 2025-08-22 16:25
  • 电力设备与新能源行业研究:固态电池深度二-硫化物:全固态主力路线,产业化进程提速.pdf
  • 2025-08-20 17:02
  • 基础化工行业研究:固态电池:产业趋势逐渐清晰,电解质为核心材料.pdf
  • 2025-08-20 17:01
  • 2025年全球电动汽车固态电池市场市场全景分析报告(英文).pdf
  • 2025-08-19 15:45
  • TaiyangNews:2025年太阳能电池组件技术趋势报告(英文版).pdf
  • 2025-08-16 16:47
  • 固态电池专题-一-:全固态电池:锂电池的下一代解决方案.pdf
  • 2025-08-16 16:40
  • 民生证券-固态电池专题-二-:无负极技术:负极的终局路线.pdf
  • 2025-08-16 16:40
  • 机械设备行业专题研究:锂电设备——从宏工、理奇、尚水招股书看锂电设备复苏、前段设备格局与固态电池布局.pdf
  • 2025-08-05 15:25
  • 驱动视界-北京-技术-新能源商用车电池系统轻量化设计与安全性评价.pdf
  • 2025-08-02 16:08
  • 低空经济专题之固态电池:eVTOL发展提速,助推固态电池商业化进程.pdf
  • 2025-07-31 16:48
  • 电力设备及新能源行业之钒电池专题报告:深峡锁钒成碧玉,裂谷熔钛化金桥.pdf
  • 2025-07-31 16:48
  • 风驰“电车”系列4:储能卡点之电池日历寿命如何突破?.pdf
  • 2025-07-26 20:00
  • 驱动视界-汽车动力电池PACK工艺与制造.pdf
  • 2025-07-22 15:43
  • 氢能与燃料电池行业研究:绿色航运驱动绿氢消纳破局,开启绿醇千万吨级机遇窗口.pdf
  • 2025-07-18 16:32
  • 人保再保险:2025新能源汽车动力电池保险创新白皮书.pdf
  • 2025-07-16 16:12
  • 固态电池系列2:从底层逻辑上看全固态电池难点和产业节奏.pdf
  • 2025-07-15 16:22
  • 固态电池渐行渐近、新技术及工艺持续涌现.pdf
  • 2025-07-11 15:56
  • 固态电池设备行业深度:固态电池0-1快速发展,产业化初期设备商优先受益.pdf
  • 2025-07-02 16:26
  • 印度电动汽车电池回收:引领CHARGE.pdf
  • 2025-07-01 16:51
  • 电池创新 为了可持续的未来.pdf
  • 2025-06-30 15:07
  • 电力设备行业深度报告:固态电池设备关键环节,前中段引领突破.pdf
  • 2025-06-27 16:31
  • 驱动视界-北京-技术-汽车锂离子电池和PACK设计开发.pdf
  • 2025-06-26 16:49
  • 驱动视界-北京-技术-汽车动力电池技术及发展方向.pdf
  • 2025-06-26 16:49
  • 中邮证券-固态电池对上游金属需求梳理.pdf
  • 2025-06-21 17:13
  • 中证鹏元-新质生产力系列_固态电池产业链持续突破.pdf
  • 2025-06-14 16:30
  • 固态电池深度系列三:产业链技术持续突破,固态进入中试关键期.pdf
  • 2025-06-12 15:34
  • 吉图咨询:2025年Q1动力电池行业分析报告.pdf
  • 2025-06-07 16:27
  • 2025年锂离子电池动态阻抗测量及应用报告.pdf
  • 2025-06-05 16:00
  • 电力设备与新能源行业深度报告:AI动力打造固态电池发展新引擎.pdf
  • 2025-05-30 17:01
  • 2025年基于混合驱动与强化学习的氢燃料电池高效电热氢综合能量管理及多堆协同优化控制技术研究报告.pdf
  • 2025-05-29 16:47
  • 电力设备行业深度报告:固态电池:锂电发展新阶段,产业化加速中.pdf
  • 2025-05-29 16:35
  • 2025年绿色保险(十九): 聚焦铅酸蓄电池行业上市公司环责险信息披露的破与立.pdf
  • 2025-05-27 16:08
  • 2025年欧盟《新电池法》下广东动力电池回收产业现状及综合分析报告.pdf
  • 2025-05-22 15:58
  • 香橙会研究院:中国燃料电池汽车产业发展白皮书(2025年).pdf
  • 2025-05-21 15:44
  • 新能源汽车产业链行业深度报告:新技术系列报告-五--固态电池产业化机遇之工艺与设备.pdf
  • 2025-05-21 15:32
  • 2025美韩科技合作报告:电池、生物技术与量子技术(英文).pdf
  • 2025-05-20 17:05
  • 固态电池深度:从技术本征看固态电池产业发展趋势.pdf
  • 2025-04-30 17:13
  • 重申光伏聚焦玻璃、电池、新技术,智驾平权促整车价值重估.pdf
  • 2025-04-30 17:13
  • 2025年背接触(BC)电池技术发展白皮书.pdf
  • 2025-04-29 16:07
  • EVTrend:2024年动力电池十大趋势报告.pdf
  • 2025-04-22 15:50
  • 温室气体 产品碳足迹量化方法与要求 锂离子电池.pdf
  • 2025-04-21 09:57
  • 锂电池硅负极深度:CVD硅碳重塑产业链,迈向动力场景0-1.pdf
  • 2025-04-16 15:23
  • 阳光电源:2025年BM²T电池管理技术白皮书.pdf
  • 2025-04-14 11:09
  • 美国能源部:2024年电池储能系统报告(英文版).pdf
  • 2025-04-12 16:38
  • 2024年欧盟新电池法应对关键和新趋势报告.pdf
  • 2025-04-11 16:28
  • 2024-2025年电池产业监测报告:市场发展概述及价值链的战略选择.pdf
  • 2025-04-09 16:27
  • 电池技术:固态电池的现状如何?.pdf
  • 2025-04-07 11:04
  • 2024年替代燃料降碳潜力评估-氢燃料电池及氢燃料重型货车碳足迹研究报告.pdf
  • 2025-03-22 17:03
  • 固态电池系列报告三:卤化物或为下一代固态电池突破方向.pdf
  • 2025-03-21 15:41
  • 曹玮-国内外电池标准热失控方法比对.pdf
  • 2025-03-19 14:45
  • 姜久春-薄膜压力感测技术在电池状态估计与预警中的应用.pdf
  • 2025-03-19 14:42
  • 清华大学(冯旭宁):2025年电池热失控反应调控技术研究进展报告.pdf
  • 2025-03-19 14:37
  • 魏学哲-电池系统多维感知与智能管控-v7.pdf
  • 2025-03-19 14:37
  • 阳如坤-先进电池制造失效分析与制造安全性0808.pdf
  • 2025-03-19 14:37
  • 谈鹏-硅碳负极锂离子电池应力特性研究.pdf
  • 2025-03-19 14:35
  • 王学远-面向电池寿命和安全管理的电化学阻抗进展.pdf
  • 2025-03-19 14:35
  • 禹习谦-先进成像技术在电池研究中的应用.pdf
  • 2025-03-19 14:34
  • 2025固态电池行业深度报告:变革下的机遇.pdf
  • 2025-03-18 12:41
  • 未来的电池制造厂.pdf
  • 2025-03-17 14:38
  • 中国科学院物理研究所(索鎏敏):2025年锂离子电池辅材报告.pdf
  • 2025-03-15 15:33
  • 动力电池行业深度报告:驱动因素、行业现状、产业链及相关公司深度梳理.pdf
  • 2025-03-15 15:28
  • 固态电池:变革下的机遇.pdf
  • 2025-03-15 15:28
  • 锂电科学社:钠离子基础知识(锂电池宣传和知识普及).pdf
  • 2025-03-12 15:42
  • 固态电池全景图:方兴未艾,技术竞逐.pdf
  • 2025-03-12 15:41
  • 锂电辊压设备国内龙头,布局干法电极和固态电池赛道助力创新突破.pdf
  • 2025-03-06 15:53
  • 中国粉体网:62页PPT了解国内外40家固态电池典型企业技术路线.pdf
  • 2025-03-04 16:04
  • 储能行业剖析:新型储能技术百花齐放,液流电池商业化正在加速.pdf
  • 2025-02-27 14:46
  • 中国消防协会:2025年数据中心锂离子电池消防安全白皮书.pdf
  • 2025-02-26 14:54
  • 产学研协同构建中国全固态电池技术平台-全固态电池材料创新与研发平台升级.pdf
  • 2025-02-22 16:27
  • 2025年锂离子电池回收:面向绿色未来的市场及创新趋势报告(英文版).pdf
  • 2025-02-22 16:21
  • 2025年锂离子电池回收:面向绿色未来的市场及创新趋势报告.pdf
  • 2025-02-21 14:54
  • 全固态电池最新预测——2025年将确定主攻技术路线-欧阳明高.pdf
  • 2025-02-20 14:48
  • 2024-2025年电池产业监测报告:市场发展概述及价值链的战略选择(英文版).pdf
  • 2025-02-19 16:10
  • 致同咨询:2025年致同咨询行业洞察报告:TMT——氢燃料电池.pdf
  • 2025-02-14 16:56
  • 电气设备-固态电池材料行业专题报告:产业方向日益清晰,技术迭代驶入快车道.pdf
  • 2025-02-14 16:49
  • 动力电池新技术展望系列报告十:硫化物全固态电池距离量产还有多远?.pdf
  • 2025-02-14 16:49
  • 2024年行业洞察报告——氢燃料电池行业报告:持续挑战和突破.pdf
  • 2025-02-11 15:46
  • 五矿证券-固态电池深度:从技术本征看固态电池产业发展趋势.pdf
  • 2025-02-09 17:38
  • 五矿证券-固态电池深度:从技术本征看固态电池产业发展趋势.pdf
  • 2025-02-09 17:32
  • 财信证券-新能源电池行业深度:主产业链业绩有望改善,新技术应用加速.pdf
  • 2025-01-24 15:16
  • 2024年中国固态电池报告——提质降本,突破“固”障,电驭未来.pdf
  • 2025-01-17 13:11
  • 电力设备与新能源行业固态电池深度报告Ⅱ_硫化物进展加速设备材料先行.pdf
  • 2025-01-10 16:23
  • 2024年全球与区域电池材料展望报告:实现交通电动化与减少资源开采并行不悖(英文版).pdf
  • 2025-01-09 16:34
  • 基础化工行业深度报告:固态锂电池方兴未艾,高性能材料有望迎新发展机遇.pdf
  • 2025-01-09 16:29
  • 光伏电池片行业:产能逐步出清下盈利拐点已现,龙头优势明显反转可期.pdf
  • 2025-01-08 16:09
  • 固态电池深度报告系列1:必争的技术高地,产业化进程加速-海通国际.pdf
  • 2025-01-06 10:04
  • 2024年电动汽车电池供应链可持续性-生命周期的影响和回收的作用报告(英文版).pdf
  • 2024-12-27 15:01
  • 氢能&燃料电池行业研究:固定式应用场景突破,海外固体氧化物电池迈入商业化.pdf
  • 2024-12-27 14:57
  • 电力设备行业深度报告:固态电池产业化加速,未来市场空间广阔.pdf
  • 2024-12-18 15:48
  • JCIAPS-2024 0006 固定式工商业储能用锂离子电池单体质量分级评价(征求意见稿).pdf
  • 2024-12-14 14:57
  • 固态电池行业专题报告:固态产业化提速,开启新技术变革周期.pdf
  • 2024-12-12 16:25
  • 电池行业:行业底部反转正当时 关注技术变革机会.pdf
  • 2024-12-04 16:18
  • 固态电池行业深度报告:技术优势、发展困境、市场空间、技术路线及相关公司深度梳理.pdf
  • 2024-12-04 16:18
  • 2024年固态锂电池技术发展白皮书.pdf
  • 2024-12-03 15:39
  • 固态电池深度系列二:硫化物未来潜力最大,开启电池发展新纪元.pdf
  • 2024-12-03 15:33
  • 上海知识产权保护中心:2024年太阳能电池片产业海外专利预警分析报告.pdf
  • 2024-11-29 15:37
  • 企业竞争图谱:2024年太阳能电池背膜 头豹词条报告系列.pdf
  • 2024-11-27 16:21
  • 储能电池一体柜用户手册.pdf
  • 2024-11-26 15:49
  • 干法电极设备专题:干法电极技术助力全固态电池加速突围-中邮证券.pdf
  • 2024-11-25 16:11
  • 锂电池行业研究框架专题报告:板块周期底部,创新引领未来-东海证券.pdf
  • 2024-11-22 15:41
  • 欧盟新电池法案及“碳关税”政策对中国动力电池企业影响简析.pdf
  • 2024-11-20 16:32
  • 面向“双碳”战略目标的锂离子电池生命周期评价:框架、方法与进展.pdf
  • 2024-11-18 15:16
  • 2024锂电池健康管理与故障诊断报告.pdf
  • 2024-11-17 21:29
  • 动力电池系统健康评估及超前失效预警研究——哈工大 于全庆.pdf
  • 2024-11-17 21:20
  • 锂离子电池健康评估与故障诊断——重庆大学 胡晓松 邓忠伟.pdf
  • 2024-11-17 21:17
  • 生命周期内蓄电池储能和飞轮储能碳足迹分析.pdf
  • 2024-11-17 21:16
  • 电气设备行业“新技术”系列之一:钠离子电池,别出“芯材”,“钠”样精彩.pdf
  • 2024-11-15 15:22
  • 追风逐光系列三:钙钛矿电池如何引领光伏技术迭代.pdf
  • 2024-11-15 15:21
  • 头豹研究院-企业竞争图谱:2024年消费电子电池 头豹词条报告系列.pdf
  • 2024-11-14 16:22
  • 锂电池产业链2025年上半年投资策略:涅盘重生,景气回归.pdf
  • 2024-11-14 16:19

作者:天彤

云效 Region 版本正式发布,打造企业级研发平台

在数字化转型加速的今天,研发效率与数据安全不再是单选题。对于高合规要求的行业和企业而言,代码、制品、流水线等核心研发资产一旦暴露于公网,就可能带来不可逆的安全风险。如今,这一难题有了全新解法——阿里云云效正式推出「Region 版本」,基于地域部署,实现研发全链路数据“不出域、不通过公网”,在保障极致安全的同时,延续敏捷高效的 DevOps 体验。

为什么安全性是 DevOps 的第一要务?

在现代软件研发中,代码即资产,流水线即生产系统。

对于大多数企业而言,尤其是涉及敏感业务(如金融、交易、会员管理、流程管理)的组织,代码库不仅是开发工具,更是关键基础设施的一部分。

然而,很多 DevOps 工具普遍存在两大安全隐患:

  1. 主流 SaaS 化 DevOps 工具仅支持公网访问: 所有操作(登录、拉取代码、构建、部署)均需通过公网完成,存在被攻击、中间人劫持、数据泄露的风险;
  2. 自建代码仓库看似安全,但配置和维护成本高昂: 企业自建 GitLab、Jenkins 等系统,虽然能控制数据流向,却面临运维复杂、容灾能力弱、版本更新滞后等问题,一旦硬件故障,可能导致代码永久丢失。

如何在“高效协同”与“绝对安全”之间取得平衡?  

云效 Region 版本,给出了答案。

云效 Region 版本:为安全而生的 DevOps 解决方案

从“共享 SaaS”到“独立域控”的跃迁

传统的云效杭州中心版本采用标准 SaaS 模式:

  • 所有企业共用同一域名 devops.aliyun.com
  • 全流程依赖公网通信
  • CI/CD 流程(如克隆代码、推送镜像、部署应用)均通过公网执行

云效 Region 版本完全不同:

  • 每个企业拥有独立的公网域名和 VPC 域名
  • 用户可通过配置,仅允许通过企业内网访问 VPC 域名,实现“数据不出域
  • CI/CD 流程全部在 VPC 内部完成,全程无需经过公网
这不是简单的“私有化”,而是

基于云原生架构的安全增强型 SaaS 服务——既保留了公有云的易用性和灵活性,又满足了企业对安全与合规的严苛要求。

架构揭秘:如何实现“内网访问 + 安全闭环”?

如下图所示,云效 Region 版本通过不同的网络连接策略,构建起一套完整的安全研发闭环体系

image

1. 身份认证:统一身份源,安全登录

  • 支持与多种外部身份源集成:钉钉、飞书、企业微信(即将上线)、Azure AD、OKTA 等
  • 通过 SSO 账号同步实现单点登录,用户无需重复注册
  • 企业内部身份源可直接对接,确保只有在企业内网登录才能访问云效,进一步提升安全性

image

2. 访问控制:公网 + VPC 双域名策略

  • 公网域名: 供用户远程访问
  • VPC 域名: 仅限企业内网访问,可通过企业专线与 VPC 对等连接接入
  • 用户可设置“IP 白名单”的方式,仅允许 VPC 内访问,彻底关闭公网入口

3. 数据传输:专线连接,稳定可靠

  • 云效 VPC 与用户 VPC 之间通过 Private Link 实现安全互联
  • 企业 IDC 与用户 VPC 之间可以通过专线连接,保障低延迟、高带宽
  • 支持与企业自建代码库、私有构建机互通,实现混合环境下的无缝协作

4. 构建任务:内网访问,弹性伸缩

  • 云效构建集群通过用户 VPC 来拉取云效代码库或者企业自建的代码库
  • 支持弹性伸缩,每个构建任务都是独立的容器资源,高并发时仍然保证构建速度
  • 直接访问用户 VPC 内的 ACK、ACR、OSS 等阿里云资源,安全可靠

全球布局,灵活扩展:Region 版本打破地域限制

在企业全球化高速发展的今天,研发团队早已遍布世界各地。然而,传统的云效中心站(杭州中心)采用集中式 SaaS 架构,仅在单一地域提供服务。这不仅限制了平台的横向扩展能力,更导致境外用户频繁遭遇高延迟、连接超时、Git 操作失败等跨境网络问题,严重影响跨国协作效率。

而云效 Region 版本从设计之初就面向全球,支持在任意阿里云 Region 独立部署站点,实现“本地部署、就近接入”。云效已正式在上海站、新加坡站开服,覆盖中国华东与东南亚核心区域,深圳站、北京站已在规划中,未来将全面支持全国重点经济圈。

免费策略:持续支持开发者成长

尽管面向高安全场景,云效始终秉持对个人开发者和初创团队的支持:

  • 免费用户许可: 5 个免费账号
  • 免费存储空间: 20GB Git 存储 + 20GB 大文件存储 + 10GB 制品存储
  • 免费构建资源: 3000 核分/月流水线构建核分

即使是中小企业研发团队,也能以极低成本开启高效、安全的研发之旅。

即刻行动,开启研发新模式

云效 Region 版本现已在中国站上海 region 和国际站新加坡 region 正式发布,深圳站/北京站正在规划中,即将上线。详情请点击https://help.aliyun.com/doc-detail/3000758.html

结语

安全,不应成为效率的代价;效率,也不应牺牲安全。

云效 Region 版本,正是为了打破这一困局而生。

它让企业在享受云原生带来的便捷与弹性的同时,真正实现“研发数据不出域,安全合规全闭环”。

让每一次提交,都安心;让每一次发布,都可靠。云效 Region 版本——为研发安全而生。

聚焦中文核心能力!LLaMA-Factory驱动CT-LLM微调全流程实践

在大模型领域,我们经常面临一个尴尬:很多号称全能的模型,内核依然是英文思维,中文输出总带着一股挥之不去的“翻译味儿”。难道参数量只有 2B 的小模型,注定只能在中文语境下做配角吗?

答案是否定的。

本次,我们把目光投向了以中文为核心的 Chinese Tiny LLM (CT-LLM)-2B。通过自主整理的高质量中英文语料,结合目前业内极其高效的微调利器 —— LLaMA-Factory,进行了一场深度炼丹实践。

我们尝试了不同的中英文数据集配比方案,从数据品质过滤到指令微调,全流程模拟主流开源模型的构建路径。实测证明,在 LLaMA-Factory 的加持下,这个 2B 的小模型不仅能听懂复杂的中文指令,更在生成质量上实现了质的飞跃,同时兼顾一定的英文和编程能力。

数据集介绍

为了喂饱这个 2B 的“小胃王”,我们选择了以下三类数据集,涵盖了从地道中文表达、海量通用知识到逻辑编程能力的方方面面:

  • COIG-CQIA (中文高质量指令集):主打“地道”与“高质量”。它深度挖掘了中文互联网的优质内容(如小红书、知乎、豆瓣等),让模型告别生硬的翻译腔,学习真正的中文思维。
  • OL-CC (中文通用语料):提供了海量的中文常识与语言素材。通过对该语料的清洗过滤,我们为模型构建了扎实的中文底蕴和流畅的叙事能力。
  • OpenHermesPreferences (英文偏好数据集):精选英文指令集。引入它的目的是通过“跨语言迁移”,保留模型在复杂逻辑推理、数学应用及编程代码上的核心竞争力。

我们设计了三组对照实验:

微调后效果一览

原生模型效果:

中英文语料比例为2:1微调后模型效果:

可见,原模型回答主题并不明确,微调后回答更具准确性,围绕”制作巧克力面包“展开。

项目实战

Step 1 数据处理

新建实例JupyterLab或VSCode,由于数据处理后期需要使用Qwen模型计算困惑度,建议选择1卡GPU,使用代码下载数据,共三个数据集。它们的原始数据形态差异较大:

下载完成后,先做数据清洗与格式统一,让不同来源的数据都符合 LLaMA-Factory 的数据规范(为 ShareGPT 或 Alpaca)。本文选择统一处理成 Alpaca 格式,即每条样本固定为:

  • instruction:任务指令/问题
  • input:可选上下文(没有就留空字符串)
  • output:目标答案/回复

完成格式统一后,引入一个关键环节:用困惑度评估文本自然度。困惑度是自然语言处理领域常用的语言模型评估指标。它用于衡量模型对文本的预测能力,数值越低表示模型对数据的拟合越好,生成的文本越自然。
本文选用 Qwen2.5-7B 作为评估模型,思路直接:

  • 文本越“顺”、越符合模型语言分布 → PPL 越低
  • 文本越“怪”、噪声越多(断句混乱、模板化、乱码、拼接错误等)→ PPL 越高
    为了避免只看均值带来的误判,这里统计了每个数据集 PPL 的分位点,用于观察整体质量分布:

    可以直观看到:OpenHermes 的整体 PPL 显著更低,说明文本更自然、更“模型友好”;而 COIG 与 OL-CC 在高分位(90%/95%)区间 PPL 拉升明显,往往对应更重的噪声与非自然片段。
    由于三类数据源的“天然噪声水平”不同,采用差异化阈值进行去噪过滤:统一选择 75% 分位点作为过滤门槛。保留 PPL ≤ 阈值的样本,剔除更“离谱”的高困惑度文本,这样既能显著降低噪声占比,也不会过度清洗导致数据规模骤减。

    处理完成后的数据为:

    清洗后的数据导出为 Alpaca JSON 文件后,最后一步是把数据注册到 llamafactory/data/dataset_info.json 中,并在训练配置里按预设比例进行混合采样。

    Step 2 模型微调

    完成数据处理后,进入微调阶段。这里新建实例并打开 LLaMA-Factory Web UI,建议直接使用 2 卡 GPU 启动训练。
    在「模型路径」处填入:/shared-only/models/m-a-p/CT-LLM-Base。
    需要说明的是:LLaMA-Factory 官方当前尚未对 CT-LLM-Base 做完整适配。因此虽然平台已内置该模型,但在 Web UI 的「模型名称」下拉框中可能不会显示它的名字。这种情况下,「模型名称」可以 不设置/任意,训练时会默认使用你在「模型路径」中指定的 CT-LLM-Base。
    Train页面中,为了保证实验可比性,本次三组微调实验使用完全一致的训练参数,只更换数据集组合以验证不同中英配比的影响。下图中未展示的参数均使用默认。


实验中设置三种数据配比方案(全中文 / 中英 2:1 / 中英 4:1),在 Web UI 中对应的数据集选择,参数配置完成后,点击开始启动任务。
全中文语料实验中,选择"coig_caia_train_ppl_filtered"、"olcc_train_ppl_filtered"两个数据集“,可以查看微调过程中的日志及loss曲线:

在中英语料比例为4:1实验中,选择 "coig_caia_train_ppl_filtered"、"olcc_train_ppl_filtered"、"open_hermes_train_ppl_filtered_2"三个数据集,可以查看微调过程中的日志及loss曲线:

注意:因为实验较多,注意区分不同实验的输出目录,后续在模型对话和模型微调时,需要在检查点路径处使用该目录。

Step 3 模型对话

微调完成后,切换到 “Chat” 页面进行定性验证。评测原模型时,先清空 “检查点路径”,再点击 “加载模型”,确保对话调用的是基础模型本体;随后在输入框中填写同一个测试问题,点击提交并观察模型回答。
评测微调模型(SFT)时,在 “检查点路径” 中选择对应实验输出目录下的 checkpoint,其余流程保持一致,同样输入相同问题进行对话。依次加载并验证三组实验 checkpoint:全中文 / 中英 2:1 / 中英 4:1。

全中文微调后模型效果:

中英语料比例为2:1时模型效果:

中英预料比例为4:1时模型效果:


从定性对话效果看,微调整体显著提升了指令跟随与回答相关性;其中 中英 2:1 的回答结构更完整、表达更自然。

Step 4 模型评估

完成三组微调训练后,进入 LLaMA-Factory 的 “Evaluate & Predict” 页面进行模型评估。
评测原模型时,需要先清空“检查点路径”,以确保评估对象为基础模型本体而非某个训练 checkpoint。随后在测试集处选择三个数据集对应的 test 子集,并将截断长度设为 2048、批处理大小设为 25、Top-p 设为 0.95、温度系数设为 0.01,最后点击开始
评测微调后的模型(SFT)时,在“检查点路径(Checkpoint Path)”处选择对应实验输出目录下的 checkpoint,其余评测参数与测试集保持与原模型一致。

按照相同流程分别运行三组实验(全中文 / 中英 2:1 / 中英 4:1),即可得到可对比的评估结果:

可以得出:

  • 微调显著提升生成质量指标:相比原模型,三组微调模型在 BLEU-4 与 ROUGE(1/2/L)上均有明显增益,说明 SFT 对目标数据分布的适配效果明显。
  • 综合最优出现在“中英 2:1”:中英 2:1 在 BLEU-4、ROUGE-1/2/L 上均为最高,整体表现最佳。
  • 4:1 未继续带来提升:相比 2:1,4:1 的质量指标略有回落,同时推理速度也略下降(samples/s 下降、runtime 增加),说明英语占比过低可能削弱了部分泛化与表达能力。
  • 推理开销整体稳定:除 4:1 的 runtime 略高外,三组微调模型的 steps/s 基本一致,模型准备时间几乎不变,评测成本整体可控。

    给新手的秘密武器

如果你还没接触过LLaMA Factory这个明星微调框架,快来看看《从零开始玩转 LLaMA Factory 大模型微调》这门课程!
随着多模态的应用场景越来越丰富,为了顺应大模型的发展需求,以及响应LLaMA Factory粉丝的呼声。我们在《从零开始玩转 LLaMA Factory 大模型微调》课程基础上做了重磅升级,新增多模态实战内容,但是加量不加价

课程亮点

作者亲授:LLaMA-Factory 开源作者亲自教学,拒绝二手解读、拒绝搬运教程
新增多模态实战内容:紧跟大模型发展趋势,课程全面升级!
早鸟价仅450元,包含:
⭐价值 300 元的配套算力资源(开箱即用)
⭐官方完课证书
⭐独家《大模型微调实战手册》
⭐课程期间专家答疑支持 立即抢购,锁定席位
立即抢购,锁定席位!

该项目来自LLaMA-Factory Online

关注“大模型实验室Lab4AI”,第一时间获取前沿AI技术解析!

还在为大模型应用开发的高门槛发愁?想快速搭建属于自己的AIAgent却被复杂配置劝退?

1月15日,商汤大装置事业群算法工程师陈家豪带来 「LazyLLMAgentic应用开发快速上手从一行代码说起」 直播,用一行代码解锁大模型应用开发新姿势,现在就为大家梳理这场 直播的核心亮点,错过直播的同学速码收藏吧~


一、直播核心内容速览

本次直播围绕四大核心模块展开,从技术演进到实操落地,层层递进带大家玩转LazyLLM:

No.1 大模型技术时间线

回顾2022年底ChatGPT引爆AI浪潮后,大模型从千亿参数跃迁、多模态融合,到2024年MOE架构兴起、2025年Agentic能力成为主战场的完整演进路径,解析黄仁勋"五层蛋糕理论"下AI应用的核心价值。

No.2 LazyLLM框架揭秘

作为商汤大装置推出的一站式多Agent应用开发工具,LazyLLM主打 “低代码、低成本、高灵活” ,破解AI应用开发中的选型难、调试难、优化难等痛点,支持从原型搭建、数据回流到迭代优化的全流程。

No.3 实操演示

一行代码搞定大模型应用:从环境安装、API密钥申请,到模型调用、RAG系统搭建、Agent创建,全程代码演示,手把手教大家快速落地AI应用。

No.4 高阶用法速览

涵盖本地模型部署、多数据库适配、MCP协议接入、生产级部署等进阶技能,助力开发者从Demo走向实际生产。


二、LazyLLM核心亮点速递

No.1 All-in-One选型自由,切换零成本

不用再为模型、数据库选型纠结!LazyLLM内部整合了主流模型厂商(商汤科技、火山引擎、阿里百炼、硅基流动等)、在线/本地数据库服务。

通过统一的OnlineModule,一行代码即可调用文本生成、视觉模型、Embedding向量、文生图等各类模型,切换厂商或模型类型无需修改核心逻辑,极大降低试错成本。

No.2 Flow组件:像搭乐高一样编排应用

复杂应用不用逐行堆砌代码!Flow组件提供pipeline(流水线)和parallel(并行处理)两种核心能力,支持业务逻辑的可视化编排。

以RAG系统为例,仅需十余行代码,即可完成文档解析、切片入库、多路检索、结果重排、模型生成的全流程搭建,结构清晰且可灵活调整。

No.3 低代码构建Agent,工具调用超简单

Agent开发三步搞定:定义工具→创建Agent→运行!

通过FunctionCallRegister可快速将普通函数转化为大模型可用工具,配合MCP(模型上下文协议),能无缝接入外部工具和数据源,实现浏览器浏览、文件操作等复杂功能。无论是简单的任务执行,还是多工具协同的复杂场景,都能以极简代码实现。

No.4 全流程支持:从Demo到生产级落地

LazyLLM不止于快速搭建原型,更提供完整的生产级支持:

  • 数据回流与badcase分析,助力应用持续优化;
  • 兼容LlamaFactory等微调框架,支持模型迭代;
  • 轻量化网关+launcher组件,适配裸金属、K8s、公有云等多部署环境;
  • 支持PDF/Excel等多格式文档解析,提供高性能切分策略与数据库适配。

三、高频问题答疑汇总

Q1 安装配置复杂吗?

不复杂!支持Windows/MacOS/Linux系统,Python3.10-3.12版本均可,通过pipinstalllazyllm==0.7.2或gitclone即可快速安装,一行代码完成基础配置。

Q2 与LangChain、LlamaIndex的区别?

核心能力相近,但LazyLLM在性能、服务部署、逻辑编排上更具优势,主打生产级友好,并沉淀了更多RAG/Agent落地场景的算法经验,避免仅停留在Demo阶段。

Q3 搭建RAG应用需要多少代码?

基础版仅需十余行代码!实际落地时可通过内部模块自定义编排,满足个性化需求。

Q4 支持多模态向量化吗?

支持!选择多模态Embedding模型(如千问v2.5vrembedding),可直接处理文本、图片甚至视频的混合输入,也可通过视觉模型描述图片后再进行向量化入库。

Q5 能否调用私有化部署模型?

完全兼容!只要模型支持OpenAI-like接口,指定source为openai并配置baseurl,即可直接调用,无需自定义格式。


四、资源福利get!

  • 项目地址

    https://github.com/LazyAGI/LazyLLM

    GitCode搜索「LazyLLM」

  • 官方文档:docs.lazyllm.ai(含入门教程、高阶用法、避坑指南)
  • 学习手册:免费开源20节课程,从零到一掌握生产级RAG应用落地
  • 技术交流:欢迎加入下方技术交流群,研发同学与maintainer在线答疑

本次直播的PPT演示代码可在技术交流群内获取,感兴趣的同学请扫描下方二维码加入~

无论您是AI新手还是资深开发者,都能通过LazyLLM降低大模型应用开发门槛

后续我们还会带来更多实操教程和版本更新解读,请持续关注!如果在使用过程中有任何问题,欢迎在交流群中与我们互动~


欢迎升级体验 LazyLLM v0.7.1,请大家去github上点一个免费的star,支持一下~

仓库链接🔗:


更多技术内容,欢迎移步 "LazyLLM" 讨论!

最近糟心新闻有点多, 还是来看看 AI 笑话放松一下吧(以下均为使用 Antigravity 过程中模型生成的内容):

  1. 货不对板

    货不对板

  2. 着急下班

    着急下班

  3. 人为疏忽

    人为疏忽

  4. 完全忘记

    完全忘记

  5. 头昏眼花

    头昏眼花

  6. 绝对吊打

    绝对吊打

  7. 恰到好处的 emoji

    非常极其准确

资深程序员都知道,开发效率的瓶颈往往不在于手速,而在于环境配置、接口调试、查阅文档以及寻找市场定位这些琐碎环节的损耗。市面上主流的 IDE 虽然功能全面,但在处理特定任务时,往往不如一些垂直领域的小工具来得顺手。

这里挑选了 7 款能够实质性改善开发体验的工具,它们不一定是最热门的,但都在各自的领域解决了具体的痛点。

Fx — 终端里的可视化 JSON 浏览器

image.png

在终端处理 API 返回数据或日志时,面对一大坨没有格式化的 JSON 文本是常态。虽然 jq 是处理这类数据的标杆工具,但它的语法对记忆力有一定要求,且交互性较弱,往往需要反复试错才能提取到想要的数据。

那 Fx 就可以将终端输出的 JSON 数据转化为可交互的视图,支持鼠标点击展开或折叠节点,就像在浏览器控制台里查看对象一样清晰。而且它保留了命令行的灵活性,支持使用 JavaScript 函数(如 map、filter、reduce)直接对数据进行实时筛选和转换。对于后端开发人员而言,就不再需要把日志复制到在线格式化网站,直接在命令行里就能完成从查看、清洗到分析的全过程,既保证了数据安全,又维持了工作流的连贯性。

ServBay — 本地化 AI 与全栈环境集成平台

image.png

有没有谁被环境配置坑过,请举手!Docker 虽然隔离性好,但对于简单的本地开发调试,编写 Dockerfile、配置挂载卷和端口映射依然耗时。

ServBay 就是一个开箱即用的工具箱,具备一套完整的 GUI 本地开发环境,最佳的 Docker 替代品。它内置了 PHP、Node.js、Python、Go、Rust 等主流编程语言,并且做好了版本隔离。开发者可以在不同项目间通过图形界面一键切换语言版本,无需手动修改环境变量。

在数据库方面,MySQL、PostgreSQL、Redis 和 MongoDB 也已预置妥当。值得一提的是,它整合了本地 AI 部署能力,支持一键运行常见的 AI 模型。省下来的时间都够打一局王者了。

HTTPie — 符合直觉的命令行 HTTP 客户端

image.png

Curl 是行业标准,但它的设计初衷是传输数据,而非供人阅读。使用 Curl 调试接口时,就要手动添加一长串参数来设置 Header,且返回的 JSON 默认没有格式化和高亮,阅读体验较差。

HTTPie 是一个给人用的 CLI 工具。它的语法极其简洁,例如 http POST url name=value 就能自动构造 JSON 请求体,无需繁琐的参数指定。它默认开启语法高亮,自动格式化返回的 JSON 数据,并且只在非管道输出时显示 Header 信息,保持输出界面的清爽。对于日常的 API 冒烟测试或快速调试,HTTPie 提供的交互体验远优于 Curl,同时又比启动 Postman 这种重型 GUI 软件要快得多,是终端爱好者的首选。

TLDR Pages — 只有干货的命令行手册

image.png

当忘记某个命令的用法时,运行 man 查看手册不是不可以,但是看的眼都花了也找不到答案。其实,开发者不需要了解参数背后的系统调用原理,只想快速知道“怎么解压这个 tar.gz 文件”或者“怎么更新 git 子模块”。

TLDR(Too Long; Didn't Read)Pages 解决了这个问题。它是由社区维护的简化版文档,只列出该命令最常用的 5-10 个实际使用案例。比如查询 tar,它会直接给出压缩和解压的常用命令组合,而不是列出几百个参数选项。它不是要替代官方文档,而是作为一种快速参考,在开发者卡壳的那一瞬间提供最直接的帮助,大幅节省查阅资料的时间。

Asciinema — 轻量级终端会话录制工具

image.png

在编写技术文档、教程或汇报 Bug 时,截图就没办法完整展示动态过程,而录制视频不仅文件体积大,画面容易模糊,观众也没办法复制视频中的代码,交互体验较差。

Asciinema 就不同了,它录制的不是视频像素,而是终端的文本字符流。生成的播放文件体积极小,在网页上播放时看起来像视频,但本质上是文本。那观众就可以随时暂停,直接选中并复制演示过程中的命令行代码。对于开源项目的 README 编写者或技术博客作者,用 Asciinema 展示安装和配置过程,专业又实用,极大提升了文档的可读性和互动性。

Exploding Topics — 技术趋势风向标

image.png

很多开发者容易陷入闭门造车的困境,用顶尖的技术解决一个不存在的需求。Exploding Topics 不直接参与代码编写,但对产品选型和方向判断极具参考价值。

该工具通过算法分析搜索数据和互联网讨论热度,识别那些处于早期增长阶段但尚未被主流大众熟知的话题。对于寻找副业方向或独立开发灵感的程序员,它能帮助过滤掉单纯的媒体炒作,发现真正具有增长潜力的利基市场。在技术栈选型或产品功能定义阶段,利用客观数据验证需求,比单纯依靠直觉要靠谱得多,能有效降低方向性错误的风险。

Carbon — 代码截图的颜值标准

image.png

在技术传播和个人品牌建设中,代码的卖相也挺重要的。很多开发者习惯直接截取 IDE 屏幕,截图的IDE屏幕都不怎么好看,就像分辨率模糊还有配色不统一,严重影响阅读体验。Carbon 就是那个让很多推特大V和技术博主的秘密武器。

这款工具将代码分享提升到了设计美学的层面。不需要打开 Photoshop,只要粘贴代码,Carbon 就能自动套用优雅的语法高亮主题、添加窗口阴影和背景填充,瞬间生成一张海报级的高清图片。对于撰写技术文档、准备演示文稿(PPT)或是在 LinkedIn 与 Twitter 上分享技术见解的程序员来说,它不仅提升了信息的可读性,更在细节处展示了你对作品质量的极致追求,是打造专业开发者形象的必备利器。

总结

优秀的开发者不仅会写代码,更懂得利用工具来优化自己的工作流。

从 Fx 和 HTTPie 对终端体验的改良,到 ServBay 对本地环境的整合,再到 Exploding Topics 对市场方向的指引,这些工具涵盖了从“想做什么”到“怎么开发”的各个环节。它们的存在证明了,在主流的庞大生态之外,依然有许多精致的工具在专注于解决具体而微小的问题。尝试将它们纳入工具箱,或许能为日常开发带来意想不到的流畅感。

作者:残风、栀七

更多接入与使用方式,可查看文末微信与钉钉群,与官方维护团队取得联系。

📖 简介

Assistant Agent 是一个基于 Spring AI Alibaba 构建的企业级智能助手框架,采用代码即行动(Code-as-Action)范式,通过生成和执行代码来编排工具、完成任务。它是一个能理解、能行动、能学习的智能助手解决方案,可帮助企业快速构建智能答疑客服、系统诊断、运维助手、业务助理、AIOps 等智能体。

仓库地址:https://github.com/spring-ai-alibaba/AssistantAgent

技术特性

  • 🚀代码即行动(Code-as-Action) :Agent 通过生成并执行代码来完成任务,而非仅仅调用预定义工具,可以在代码中灵活编排、组合多个工具,实现复杂流程
  • 🔒安全沙箱:AI 生成的代码在 GraalVM 多语言沙箱中安全运行,具备资源隔离能力
  • 📊多维评估:通过评估图(Graph)进行多层次意图识别,精准指导 Agent 行为
  • 🔄Prompt 动态组装:根据场景及前置评估结果动态注入上下文(经验、知识等)到 Prompt 中,灵活处理不同任务
  • 🧠经验学习:自动积累成功经验,持续提升后续任务的表现
  • 快速响应:熟悉场景下,跳过 LLM 推理过程,基于经验快速响应

Assistant Agent 能帮你做什么?

Assistant Agent 是一个功能完整的智能助手,具备以下核心能力:

  • 🔍智能问答:支持多数据源统一检索架构(通过 SPI 可扩展知识库、Web 等数据源),提供准确、可溯源的答案
  • 🛠️工具调用:支持 MCP、HTTP API(OpenAPI)等协议,灵活接入海量工具,可组合调用实现复杂业务流程
  • 主动服务:支持定时任务、延迟执行、事件回调,让助手主动为你服务
  • 📬多渠道触达:内置 IDE 回复,允许通过 SPI 可扩展钉钉、飞书、企微、Webhook 等渠道

为什么选择 Assistant Agent?

image

适用场景

  • 智能客服:接入企业知识库,智能解答用户咨询
  • 运维助手:对接监控、工单系统,自动处理告警、查询状态、执行操作
  • 业务助理:连接 CRM、ERP 等业务系统,辅助员工完成日常工作

💡 以上仅为典型场景示例。通过配置知识库和接入工具,Assistant Agent 可适配更多业务场景,欢迎探索。

image

image

整体工作原理

以下是 Assistant Agent 处理一个完整请求的端到端流程示例:

image

项目结构

assistant-agent/
├── assistant-agent-common          # 通用工具、枚举、常量
├── assistant-agent-core            # 核心引擎:GraalVM 执行器、工具注册表
├── assistant-agent-extensions      # 扩展模块:
│   ├── dynamic/               #   - 动态工具(MCP、HTTP API)
│   ├── experience/            #   - 经验管理与快速意图配置
│   ├── learning/              #   - 学习提取与存储
│   ├── search/                #   - 统一搜索能力
│   ├── reply/                 #   - 多渠道回复
│   ├── trigger/               #   - 触发器机制
│   └── evaluation/            #   - 评估集成
├── assistant-agent-prompt-builder  # Prompt 动态组装
├── assistant-agent-evaluation      # 评估引擎
├── assistant-agent-autoconfigure   # Spring Boot 自动配置
└── assistant-agent-start           # 启动模块

🚀 快速启动

前置要求

  • Java 17+
  • Maven 3.8+
  • DashScope API Key

1. 克隆并构建

git clone https://github.com/spring-ai-alibaba/AssistantAgent.git
cd assistant-agent
mvn clean install -DskipTests

2. 配置 API Key

export DASHSCOPE_API_KEY=your-api-key-here

3. 最小配置

项目已内置默认配置,只需确保 API Key 正确即可。如需自定义,可编辑 assistant-agent-start/src/main/resources/application.yml

spring:
  ai:
    dashscope:
      api-key: ${DASHSCOPE_API_KEY}
      chat:
        options:
          model: qwen-max

4. 启动应用

cd assistant-agent-start
mvn spring-boot:run

所有扩展模块默认开启并采用合理的配置,无需额外配置即可快速启动。

5. 配置知识库(接入业务知识)

💡 框架默认提供 Mock 知识库实现用于演示测试。生产环境需要接入真实知识源(如向量数据库、Elasticsearch、企业知识库 API 等),以便 Agent 能够检索并回答业务相关问题。

方式一:快速体验(使用内置 Mock 实现)

默认配置已启用知识库搜索,可直接体验:

spring:
  ai:
    alibaba:
      codeact:
        extension:
          search:
            enabled: true
            knowledge-search-enabled: true  # 默认开启

方式二:接入真实知识库(推荐)

实现 SearchProvider 接口,接入你的业务知识源:

package com.example.knowledge;
import com.alibaba.assistant.agent.extension.search.spi.SearchProvider;
import com.alibaba.assistant.agent.extension.search.model.*;
import org.springframework.stereotype.Component;
import java.util.*;
@Component  // 添加此注解,Provider 会自动注册
public class MyKnowledgeSearchProvider implements SearchProvider {
    @Override
    public boolean supports(SearchSourceType type) {
        return SearchSourceType.KNOWLEDGE == type;
    }
    @Override
    public List<SearchResultItem> search(SearchRequest request) {
        List<SearchResultItem> results = new ArrayList<>();
        // 1. 从你的知识源查询(向量数据库、ES、API 等)
        // 示例:List<Doc> docs = vectorStore.similaritySearch(request.getQuery());
        // 2. 转换为 SearchResultItem
        // for (Doc doc : docs) {
        //     SearchResultItem item = new SearchResultItem();
        //     item.setId(doc.getId());
        //     item.setSourceType(SearchSourceType.KNOWLEDGE);
        //     item.setTitle(doc.getTitle());
        //     item.setSnippet(doc.getSummary());
        //     item.setContent(doc.getContent());
        //     item.setScore(doc.getScore());
        //     results.add(item);
        // }
        return results;
    }
    @Override
    public String getName() {
        return "MyKnowledgeSearchProvider";
    }
}

常见知识源接入示例

image

🧩 核心模块介绍

评估模块(Evaluation)

作用:多维度意图识别框架,通过评估图(Graph)对信息进行多层次特质识别。

┌──────────────────────────────────────────────────────────────────┐
│                    评估图 (Evaluation Graph) 示例                  │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  用户输入: "查询今日订单"                                           │
│          │                                                       │
│          ▼                                                       │
│  ┌─────────────────────────────────────────────────────────┐     │
│  │ Layer 1 (并行执行)                                      │     │
│  │   ┌────────────┐         ┌────────────┐                 │     │
│  │   │ 是否模糊?   │         │ 输入改写     │                 │     │
│  │   │ 清晰/模糊   │         │(增强)      │                 │     │
│  │   └─────┬──────┘         └─────┬──────┘                 │     │
│  └─────────┼──────────────────────┼────────────────────────┘     │
│            │                      │                              │
│            └──────────┬───────────┘                              │
│                       ▼                                          │
│  ┌─────────────────────────────────────────────────────────┐     │
│  │ Layer 2 (基于改写内容,并行执行)                            │     │
│  │   ┌──────────┐   ┌──────────┐   ┌──────────┐            │     │
│  │   │ 检索经验  │   │ 匹配工具  │   │ 搜索知识  │             │     │
│  │   │ 有/无    │   │ 有/无     │   │ 有/无    │             │     │
│  │   └──────────┘   └──────────┘   └──────────┘            │     │
│  └─────────────────────────────────────────────────────────┘     │
│                       │                                          │
│                       ▼                                          │
│            ┌────────────────────┐                                │
│            │ 整合不同维度评估结果  │                                │
│            │ → 传递给后续模块     │                                │
│            └────────────────────┘                                │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

核心能力

  • 双评估引擎:

    • LLM 评估: 通过大模型进行复杂语义判断,用户可完全自定义评估 Prompt(customPrompt),也可使用默认 Prompt 组装(支持 description、workingMechanism、fewShots 等配置)
    • Rule-based 评估: 通过 Java 函数实现规则逻辑,用户自定义 Function<CriterionExecutionContext, CriterionResult> 执行任意规则判断,适合阈值检测、格式校验、精确匹配等场景
  • 依赖关系自定义: 评估项可通过 dependsOn 声明前置依赖,系统自动构建评估图按拓扑执行,无依赖项并行、有依赖项顺序执行,后续评估项可访问前置评估项的结果
  • 评估结果: 支持 BOOLEANENUMSCOREJSONTEXT 等类型,传递给 Prompt Builder 驱动动态组装

Prompt Builder 模块

作用:根据评估结果和运行时上下文,动态组装发送给模型的 Prompt。示例:

┌─────────────────────────────────────────────────────────────────────────┐
│                   Prompt Builder - 条件化动态生成                         │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  评估结果输入:                                                            │
│  ┌────────────────────────────────────────────────────────┐             │
│  │ 模糊: 是  │ 经验: 有  │ 工具: 有  │ 知识: 无               │             │
│  └────────────────────────────────────────────────────────┘             │
│                    │                                                    │
│                    ▼                                                    │
│  ┌────────────────────────────────────────────────────────────────┐     │
│  │              自定义 PromptBuilder 条件匹配                       │     │
│  │                                                                │     │
│  │   模糊=是 ──────▶ 注入 [澄清引导 Prompt]                          │     │
│  │   模糊=否 ──────▶ 注入 [直接执行 Prompt]                          │     │
│  │                                                                │     │
│  │   经验=有 ──────▶ 注入 [历史经验参考]                              │     │
│  │   工具=有 ──────▶ 注入 [工具使用说明]                              │     │
│  │   知识=有 ──────▶ 注入 [相关知识片段]                              │     │
│  │                                                                │     │
│  │   组合示例1: 模糊+无工具+无知识 ──▶ [追问用户 Prompt]               │     │
│  │   组合示例2: 清晰+有工具+有经验 ──▶ [快速执行 Prompt]               │     │
│  └────────────────────────────────────────────────────────────────┘     │
│                    │                                                    │
│                    ▼                                                    │
│  ┌────────────────────────────────────────────────────────────────┐     │
│  │ 最终动态 Prompt:                                                │     │
│  │ [系统提示] + [澄清引导] + [历史经验] + [工具说明] + [用户问题]        │     │
│  └────────────────────────────────────────────────────────────────┘     │
│                    │                                                    │
│                    ▼                                                    │
│              ┌──────────┐                                               │
│              │   模型    │                                               │
│              └──────────┘                                               │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

核心能力

  • 多个 PromptBuilder 按优先级顺序执行
  • 每个 Builder 根据评估结果决定是否贡献、贡献什么内容
  • 支持自定义 Builder,根据业务需求定制 Prompt 逻辑
  • 非侵入式,在模型调用层拦截

对比传统方案

image

学习模块(Learning)

作用:从 Agent 执行历史中自动提取并保存有价值的经验。

┌─────────────────────────────────────────────────────────────────────────┐
│                         学习模块工作流程                                   │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  ┌────────────────────────────────────────────────────────────────────┐ │
│  │                        Agent 执行过程                               │ │
│  │                                                                    │ │
│  │  输入 ──▶ 推理 ──▶ 代码生成 ──▶ 执行 ──▶ 输出                          │ │
│  │   │        │          │         │        │                         │ │
│  │   └────────┴──────────┴─────────┴────────┘                         │ │
│  │                        │                                           │ │
│  └────────────────────────┼───────────────────────────────────────────┘ │
│                           ▼                                             │
│              ┌────────────────────────┐                                 │
│              │      学习上下文捕获      │                                 │
│              │  - 用户输入             │                                 │
│              │  - 中间推理步骤          │                                │
│              │  - 生成的代码           │                                 │
│              │  - 执行结果             │                                │
│              └───────────┬────────────┘                                │
│                          │                                             │
│                          ▼                                             │
│   ┌──────────────────────────────────────────────────────────────┐     │
│   │                    学习提取器分析                              │     │
│   │  ┌────────────┐  ┌────────────┐  ┌────────────┐              │     │
│   │  │ 经验提取器  │  │ 模式提取器   │  │ 错误提取器   │              │     │
│   │  │ 成功模式    │  │ 通用模式    │  │ 失败教训     │              │     │
│   │  └─────┬──────┘  └─────┬──────┘  └─────┬──────┘              │     │
│   └────────┼───────────────┼───────────────┼─────────────────────┘     │
│            │               │               │                           │
│            └───────────────┼───────────────┘                           │
│                            ▼                                           │
│                   ┌────────────────┐                                   │
│                   │   持久化存储    │ ──▶ 供后续任务参考使用                │
│                   └────────────────┘                                   │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

核心能力

  • After-Agent 学习: 每次 Agent 运行完成后提取经验
  • After-Model 学习: 每次模型调用后提取经验
  • Tool Interceptor: 从工具调用中提取经验
  • 离线学习: 批量分析历史数据提取模式
  • 学习过程: 捕获执行上下文 → 提取器分析识别 → 生成经验记录 → 持久化存储供后续复用

经验模块(Experience)

作用:积累和复用历史成功执行经验。

┌─────────────────────────────────────────────────────────────────────────┐
│                         经验模块工作示意                                   │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  【场景1: 经验积累】                                                       │
│                                                                         │
│   用户: "查询订单状态"  ──▶  Agent 成功执行  ──▶     ┌────────────────┐     │
│                                                  │ 保存经验:       │     │
│                                                  │ - React决策经验 │     │
│                                                  │ - Code经验     │     │
│                                                  │ - 常识经验      │     │
│                                                  └────────────────┘     │
│                                                           │             │
│                                                           ▼             │
│                                                  ┌────────────────┐     │
│                                                  │   经验库        │     │
│                                                  └────────────────┘     │
│                                                                         │
│  【场景2: 经验复用】                                       |              │
│                                                          │              │
│   用户: "查询我的订单状态"  ◀────  匹配相似经验  ◀────────────┘              │
│            │                                                            │
│            ▼                                                            │
│   ┌─────────────────────────────────────────────────┐                   │
│   │ Agent 参考历史经验,更快决策+生成正确代码             │                   │
│   └─────────────────────────────────────────────────┘                   │
│                                                                         │
│  【场景3: 快速意图响应】                                                   │
│                                                                         │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │ 经验库                                                           │   │
│   │   ┌─────────────────────┐       ┌────────────────────────────┐  │   │
│   │   │ 经验A (普通)         │       │ 经验B (✓ 已配置快速意图)      │  │   │
│   │   │ 无快速意图配置        │       │   条件: 前缀匹配"查看*销量"   │  │   │
│   │   │ → 注入prompt供llm参考│       │   动作: 调用销量查询API       │  │   │
│   │   └─────────────────────┘       └───────────┬────────────────┘  │   │
│   └─────────────────────────────────────────────┼───────────────────┘   │
│                                                 │ 条件命中               │
│                                                 ▼                       │
│   用户: "查看今日销量"  ──▶  匹配经验B快速意图  ──▶  跳过LLM,直接执行          │
│                                                                         │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

核心能力

  • 多类型经验: 代码生成经验、ReAct 决策经验、常识经验,为类似任务提供历史参考
  • 灵活复用: 经验可注入 Prompt 或用于快速意图匹配
  • 生命周期管理: 支持经验的创建、更新、删除
  • 快速意图响应:

    • 经验需显式配置 fastIntentConfig 才能启用
    • 匹配已配置条件时,跳过 LLM 完整推理,直接执行预记录的工具调用或代码
    • 支持多条件匹配:消息前缀、正则、元数据、状态等

触发器模块(Trigger)

作用:创建和管理定时任务或事件触发的 Agent 执行。

┌─────────────────────────────────────────────────────────────────────────┐
│                         触发器模块能力示意                                 │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  【定时触发】                                                             │
│                                                                         │
│   用户: "每天早上9点给我发送销售日报"                                        │
│            │                                                            │
│            ▼                                                            │
│   ┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐   │
│   │  Agent 创建      │     │   调度器         │     │  自动执行        │   │
│   │  Cron 触发器     │────▶│  0 9 * * *      │────▶│  生成日报        │   │
│   │  (自我调度)      │     │                 │     │  发送通知        │    │
│   └─────────────────┘     └─────────────────┘     └─────────────────┘   │
│                                                                         │
│  【延迟触发】                                                             │
│                                                                         │
│   用户: "30分钟后提醒我开会"                                               │
│            │                                                            │
│            ▼                                                            │
│   ┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐   │
│   │  Agent 创建      │     │   30分钟后      │     │  发送提醒         │   │
│   │  一次性触发器     │────▶│   触发          │────▶│  "该开会了"       │   │
│   └─────────────────┘     └─────────────────┘     └─────────────────┘   │
│                                                                         │
│  【回调触发】                                                             │
│                                                                         │
│   用户: "满足xx条件时帮我xx"                                               │
│                                                                         │
│   外部系统: 发送事件到 Webhook                                             │
│            │                                                            │
│            ▼                                                            │
│   ┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐   │
│   │  接收回调        │     │   触发 Agent     │     │  处理事件        │   │
│   │  Webhook 事件   │────▶│   执行任务        │────▶│  返回响应        │   │
│   └─────────────────┘     └─────────────────┘     └─────────────────┘   │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

核心能力

  • TIME_CRON 触发器:支持 Cron 表达式定时触发任务
  • TIME_ONCE 触发器:支持一次性延迟触发
  • CALLBACK 触发器:支持回调事件触发
  • Agent 可通过工具自主创建触发器,实现“自我调度”

回复渠道模块(Reply Channel)

作用:提供灵活的消息回复能力,支持多种输出渠道。

┌─────────────────────────────────────────────────────────────────────────┐
│                       回复渠道模块能力示意                                 │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   Agent 需要向用户回复消息                                                 │
│            │                                                            │
│            ▼                                                            │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │                    回复渠道路由                                   │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│            │                                                            │
│            ├──────────────┬──────────────┬──────────────┐               │
│            ▼              ▼              ▼              ▼               │
│   ┌────────────┐  ┌────────────┐  ┌────────────┐  ┌────────────┐        │
│   │  DEFAULT   │  │  IDE_CARD  │  │ IM_NOTIFY  │  │  WEBHOOK   │        │
│   │  文本回复   │  │  卡片展示   │   │  消息推送   │  │  JSON推送   │        │
│   └─────┬──────┘  └─────┬──────┘  └─────┬──────┘  └─────┬──────┘        │
│         │               │               │               │               │
│         ▼               ▼               ▼               ▼               │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐          │
│   │ 控制台    │    │   IDE    │    │   IM     │    │ 第三方    │          │
│   │ 终端回复  │    │ 富文本卡片 │     │ (可扩展) │    │  系统     │          │
│   └──────────┘    └──────────┘    └──────────┘    └──────────┘          │
│                                                                         │
│  【使用示例】                                                             │
│                                                                         │
│   用户: "分析完成后发送结果"                                                │
│            │                                                            │
│            ▼                                                            │
│   Agent: send_message(text="分析结果...")                                │
│            │                                                            │
│            ▼                                                            │
│   用户收到消息: "📊 分析结果: ..."                                         │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

核心能力

  • 多渠道路由: Agent 可根据场景选择不同渠道回复
  • 配置驱动: 动态生成回复工具,无需编码
  • 同步异步支持: 支持同步和异步回复模式
  • 统一接口: 屏蔽底层实现差异
  • 内置示例渠道: IDE_TEXT(演示用)
  • 可扩展渠道(通过实现 ReplyChannelDefinition SPI): 如 IDE_CARDIM_NOTIFICATION(钉钉/飞书/企微)、WEBHOOK_JSON 等,需用户自行实现

工具扩展模块(Dynamic Tools)

作用:提供高度可扩展的工具体系,让 Agent 能够调用各类外部工具完成任务。

┌─────────────────────────────────────────────────────────────────────────┐
│                        工具扩展架构                                       │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   Agent 需要执行操作                                                      │
│            │                                                            │
│            ▼                                                            │
│   ┌──────────────────────────────────────────────────────────────────┐  │
│   │                   CodeactTool 工具体系                            │  │
│   └─────────────────────────────────────────────────────────────────┘   │
│            │                                                            │
│            ├─────────────┬─────────────┬─────────────┬──────────────┐   │
│            ▼             ▼             ▼             ▼              ▼   │
│   ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌───────┐ │
│   │   MCP      │ │   HTTP     │ │  Search    │ │  Trigger   │ │ 自定义 │ │
│   │   Tools    │ │   API      │ │  Tools     │ │  Tools     │ │ Tools │ │
│   │            │ │   Tools    │ │            │ │            │ │       │ │
│   └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ └───┬───┘ │
│         │              │              │              │            │     │
│         ▼              ▼              ▼              ▼            ▼     │
│   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐  ┌──────┐   │
│   │ 任意 MCP │   │ REST API │   │ 知识检索   │   │ 定时任务  │  │ ...  │   │
│   │ Server   │   │ OpenAPI  │   │ 项目搜索  │   │ 事件回调  │  │      │    │
│   └──────────┘   └──────────┘   └──────────┘   └──────────┘  └──────┘   │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

核心能力

  • MCP 工具支持: 一键接入任意 MCP Server,复用 MCP 工具生态
  • HTTP API 支持: 通过 OpenAPI 规范接入 REST API,调用企业现有接口
  • 内置工具类型: 搜索(Search)、回复(Reply)、触发器(Trigger)、学习(Learning)等
  • 自定义工具 SPI: 实现 CodeactTool 接口,轻松扩展新工具

知识检索模块(Knowledge Search)

作用:多数据源统一检索引擎,为 Agent 的问答和决策提供知识支撑。

┌─────────────────────────────────────────────────────────────────────────┐
│                       多数据源检索架构                                     │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  用户问题: "如何配置数据库连接池?"                                          │
│            │                                                            │
│            ▼                                                            │
│  ┌─────────────────────────────────────────────────────────────────┐    │
│  │                      统一检索接口                                 │    │
│  └─────────────────────────────────────────────────────────────────┘    │
│            │                                                            │
│            ├────────────────┬────────────────┬────────────────┐         │
│            ▼                ▼                ▼                ▼         │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌─────────┐     │
│   │    知识库     │  │    项目       │  │     Web      │  │  自定义  │    │
│   │   Provider   │  │   Provider   │  │   Provider   │  │Provider │    │
│   │   (主要)      │  │   (可选)     │  │   (可选)      │  │  (SPI)  │    │
│   └──────┬───────┘  └──────┬───────┘  └──────┬───────┘  └───┬─────┘    │
│          │                 │                 │              │          │
│          ▼                 ▼                 ▼              ▼          │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌────────┐      │
│   │ FAQ / 文档    │  │ 源代码       │  │ 网络文章       │  │  ...   │      │
│   │ 历史问答      │  │ 配置文件      │  │ 技术论坛       │  │        │      │
│   │ 团队笔记      │  │ 日志         │  │               │  │        │      │
│   └──────────────┘  └─────────────┘  └───────────────┘  └────────┘      │
│          │                 │                 │              │          │
│          └─────────────────┴─────────────────┴──────────────┘          │
│                            │                                           │
│                            ▼                                           │
│               ┌────────────────────────┐                               │
│               │ 聚合排序                │                               │
│               │ → 注入 Prompt          │                                │
│               └────────────────────────┘                               │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

核心能力

  • 统一检索接口: SearchProvider SPI,支持可插拔数据源
  • 演示 Provider: 内置知识库、项目、Web 的 Mock 实现(仅供演示和测试)
  • 自定义扩展: 通过实现 SearchProvider 接口,接入任意数据源(数据库、向量库、API)
  • 结果聚合: 支持可配置的排序策略
  • 业务价值: 接入企业知识库提供准确答案、支持答案溯源、降低人工客服压力

配置示例

spring:
  ai:
    alibaba:
      codeact:
        extension:
          search:
            enabled: true
            knowledge-search-enabled: true   # 知识库(默认 Mock 实现)
            project-search-enabled: false    # 项目代码(默认 Mock 实现)
            web-search-enabled: false        # Web 搜索(默认 Mock 实现)
            default-top-k: 5
            search-timeout-ms: 5000

💡 以上搜索功能默认提供 Mock 实现供演示测试。生产环境需实现 SearchProvider SPI 接入实际数据源。

🙏 致谢:

联系方式:

  • 搜索加入钉钉群:130240015687

在运营拼团软件的过程中,我们常常面临着如何根据不同地区的用户需求,提供个性化和定制化服务的问题。根据技术和经验的累计,IP地址定位成为了一种高效的解决方案。今天,我想分享我如何利用IP归属地定位功能,提高平台的本地化和精准营销。

一、IP地址定位的作用

IP地址定位技术可以帮助平台通过用户的IP地址快速识别其地理位置。这样,平台就能根据用户所在的城市或地区,动态展示最相关的内容和服务。比如,我的平台可以根据用户的IP地址自动推送本地化的拼团活动、当地商家信息以及地区特定的优惠。

举例:

  • 本地化内容展示: 用户登录平台时,系统识别其IP地址后,自动展示该地区的热门拼团商品或商家信息。
  • 个性化营销: 基于用户的地理位置,推送本地特有的优惠券、促销活动,提升转化率。

这大大减轻了我在广告投放上的精力和经费,让我能更专注地投入到选品和平台的维护上,为使用我平台的用户提供更多的福利和促销。

二、如何使用IP地址定位进行差异化服务

市面上有很多专业的非专业的IP归属地查询工具(为了我们的数据安全和操作便捷当然是要选择专业的平台),经过我的对比和筛选,各大主流IP服务平台的功能都大差不差,最后的决定因素当然就是价格,最终通过我“考验”的就是IP数据云,精准度相同的情况下性价比真的一绝!具体不再赘述,有需要的小伙伴可以去试用一下。

有了工具,接下来就是怎么通过使用查询工具,实现内容个性化和精准推送。

步骤一:通过后台/其他方式获取用户登录IP(要符合隐私规则,向用户提前告知哦)

步骤二:然后向API发送IP地址查询的请求

示例代码(Node.js后端):

const axios = require('axios');
 
// 用户的IP地址(假设你已经通过其他方式获得)

const userIp = '8.8.8.8';  // 替换为实际IP

const apiKey = 'your_api_key';  // 替换为你的API密钥
 
axios.get(`https://api.ipdatacloud.com/v2/query?ip=需要查询的ip&key=您申请的key`)
  .then(response => {
    console.log(response.data);  // 输出IP的详细信息
  })
  .catch(error => {
    console.error(error);
  });

步骤三:数据返回

步骤四:根据IP定位调整平台内容

三、如何提升营销效果

有了这些数据,我们就可以为用户提供更人性化的服务:

1.显示本地化内容

根据城市、地区或国家信息,展示与用户位置相关的内容。例如:

  • 显示当地的拼团活动。
  • 推荐附近的商家或品牌。
  • 提供本地语言支持(如果你是多语言的平台)。

2.优化广告投放

  • 跨区域营销:如果我们知道某个地区的用户对某类商品感兴趣,就可以根据数据定向投放广告,提高转化率。
  • 精准广告推送:通过IP定位推送适合的广告、优惠券或产品。
例如:对用户推送附近商家的拼团活动,或推送当地特有的商品。

3.防止欺诈行为

如果有反欺诈需求,IP数据云的IP风险画像和IP代理识别API的风险评分和代理识别功能,可以帮你检测是否为可疑IP,避免诈骗或恶意行为。

例如:若检测到是代理IP或VPN,平台可通过验证措施二次确认用户身份,降低欺诈风险。

以上就是我在使用了IP地址定位后的成果,它帮助我为我的用户提供更加精准和本地化的服务,提升了用户转化和忠诚度。当然工具的选择很重要,好的工具可以让我们事半功倍!

从Kafka到AutoMQ:爱奇艺实时流数据架构演进

概述

本文详细介绍了爱奇艺在处理大规模实时流数据时,从传统Kafka架构向AutoMQ演进的技术历程。为了解决私有云环境下集群扩缩容难、资源利用率低以及运维成本高等挑战,爱奇艺开发了Stream平台与Stream-SDK,实现了业务与底层存储的彻底解耦。随后,公司引入公有云服务并最终切换至基于存算分离架构的AutoMQ,利用其单副本存储和秒级弹性的特性,显著提升了系统的灵活性。这一系列的架构升级不仅优化了数据治理体系,还成功将运营成本降低了70%以上。目前,爱奇艺正持续扩大AutoMQ的应用规模,以进一步实现降本增效的长期目标。

背景

Kafka因其高吞吐、低延时、可扩展的特性,在出现之后迅速成为流数据存储的标准组件,广泛应用于实时大数据场景。爱奇艺的流数据服务也主要基于Kafka构建,随着实时大数据应用越来越广泛,Kafka集群数量、规模越来越大,面临扩缩容繁琐、成本高、难治理等诸多问题与挑战。为解决这些问题,我们进行了Kafka服务化、上云、迁移AutoMQ等一系列探索。

本文将介绍爱奇艺Kafka从私有云迈向公有云、从Kafka到AutoMQ的探索与实践。

流数据在爱奇艺的应用

图1 数据通路

在爱奇艺,流数据的存储组件使用的是Kafka,计算组件主要使用的是Flink,流数据相关的典型数据通路如图1所示,主要包括如下环节:

  • 数据集成:Pingback(端上投递日志)、后端日志、数据库binlog、指标等持续产生的流数据,实时写入数据总线Kafka。
  • 数据仓库:由Flink程序将数据引入到实时(流式)、离线(批式)数仓。在实时数仓中,数据仍然以流数据形态存储在Kafka中,并通过Flink构建实时数仓各层数据。在离线数仓中,流数据将会聚集成批数据存储在Iceberg中,再由 Flink增量消费Iceberg构建离线数仓各层数据。实时数仓具备秒级延时,离线数仓具备分钟级以上延时。
  • 数据开发:数仓的数据通过数据开发平台应用到各业务场景。在实时计算中Kafka也会作为中间流数据的存储用于任务之间的解耦。
  • 数据应用:数据广泛应用到爱奇艺的推荐、搜索、广告、报表等等场景中。数据的价值随着延时增大快速衰减,为了数据价值最大化,近几年主要应用场景都已切换到流数据。

Kafka作为流数据的存储承担数据集成到大数据体系的数据总线、实时数仓存储、实时任务之间解耦等角色。

流数据存储服务:从管集群到管数据

爱奇艺的流数据服务最初以Kafka集群为核心构建,提供集群生命周期管理、Topic管理、消费监控等基础能力。随着业务规模扩大、集群数量和数据量持续增长,逐渐暴露出以下问题:

  1. 业务与集群强耦合:业务代码直接依赖Kafka地址访问集群,一旦需要迁移或调整集群,必须修改业务代码并重新上线,不灵活。同时也无法从平台侧统一识别和监控各业务的读写行为。
  2. 缺乏统一的数据与schema管理:平台没有管理数据描述、schema、数据归属等元数据信息,无法提供数据查找功能,不利于跨团队的数据理解、复用与治理。
  3. 主备数据管理缺失:对重要数据,业务侧通常配置主备链路,但平台侧缺乏对主备关系的统一管理,难以做到一致性保障与故障切换治理。

为了解决上述问题,我们将流数据存储服务升级到了如图2所示的架构,由Stream平台、Stream-SDK、存储组件三部分构成。

图2 流数据服务架构

先介绍下Stream平台,Stream-SDK和存储组件后面介绍。Stream平台由“集群管理”和“数据管理”两大模块组成。集群管理负责集群生命周期与底层资源的统一管理,侧重运维侧能力。数据管理是平台的核心,以“数据为中心”构建,面向数据开发人员提供统一的数据视图和管理能力,核心功能如下:

  1. 逻辑队列:原先“集群+Topic”定位数据的方式,升级为基于“项目+队列(Topic)”的逻辑命名方式,集群仅作为队列的一个属性,消除业务对具体集群的依赖。逻辑队列还支持同时绑定主备两个集群,结合Stream-SDK可实现主备链路的一键切换。
  2. Schema管理:支持为队列配置schema,并自动同步至大数据元数据中心,使队列能够在数据开发平台中自动映射为逻辑表,使用SQL直接处理流数据。
  3. 数据地图:提供队列的多维度查询与检索能力,支持在线申请和授权使用队列,简化跨团队的数据查找和复用流程。
  4. 数据血缘:基于Stream-SDK自动上报的读写端信息,构建应用级的读写血缘链路,帮助快速定位上下游数据关系及影响范围。

Stream-SDK:统一的流数据读写客户端

Stream-SDK是平台提供的统一数据访问客户端,封装了底层原生客户端,兼容Kafka协议和RocketMQ。业务仅需配置“项目+队列”,即可完成数据读写,无需关注具体集群地址或认证方式,从而实现业务代码与底层集群的彻底解耦。

图 3 Stream SDK 读写数据过程

Stream-SDK的数据读写流程如图3所示,主要包括两个阶段:

  1. 配置获取与上报

基于业务提供的项目、队列和Token(用于鉴权),SDK调用Stream平台的配置API,获取队列对应的集群信息、Topic、认证参数等配置,并使用原生客户端执行读写。同时,SDK会通过该API上报客户端IP、消费组、应用名称等信息,平台据此实时构建读写血缘。

  1. 集群变更感知与自动切换

在运行期间,SDK每分钟与Stream平台进行心跳交互,实时感知队列关联的集群是否发生变更。一旦检测到变化,SDK会自动将读写流量切换至新集群,实现无感迁移。

借助Stream-SDK,集群的迁移成本大幅降低,也为后续从私有云迈向公有云、从Kafka切换到AutoMQ的架构演变做好了准备。

Kafka混合多云建设

早期爱奇艺Kafka集群部署在私有云IDC,受制于IDC资源供给模式及Kafka架构固有特性,资源利用率难以保持在合理区间。自2023年起,平台逐步引入多家公有云Kafka,形成混合云架构,在资源弹性、运维效率和成本优化方面取得了显著成效。下文将介绍下上云过程。

私有云Kafka

![
图4 Kafka 架构](https://image.automq.com/20260126bot/atub35.png)

Kafka架构如图4所示,是经典的多副本容错分布式架构,由Broker和Zookeeper两类角色组成:Broker负责数据存储与客户端读写,Zookeeper负责管理集群的元数据与协作状态。在私有云中,Kafka部署在爱奇艺各IDC,其中Zookeeper通常以虚机部署,Broker则根据场景选择虚机或物理机。

私有云模式支撑了公司流数据规模的快速增长,但随着业务体量持续扩大,也逐渐暴露出以下问题:

  1. 集群弹性差:Kafka的Shared Nothing架构虽然简单可靠,但每个Broker上都存储大量数据,导致扩容或缩容时必须在Broker间进行大规模数据迁移。迁移过程耗时长且会影响业务任务的读写性能,使得集群难以实现平滑弹性伸缩。
  2. 资源弹性不足:私有云的物理资源从采购到报废周期较长,难以随业务流量动态变化而快速调整,导致集群资源利用率长期处于“过高或过低”的状态。同时,对于寒暑假、重点直播等短时流量高峰,也难以做到按需扩缩,影响系统整体资源效率与成本优化。

从私有云Kafka到公有云Kafka

为实现降本增效并提升流数据存储的灵活性,我们引入并上线了公有云Kafka产品。

公有云Kafka产品遵循Kafka协议,通过在Stream平台与Stream-SDK中进行统一适配,为业务侧提供一致、无差异的使用体验,实现了私有云与公有云之间统一接入和平滑切换。

借助公有云庞大的资源池和按需创建集群的能力,解决了私有云环境下资源弹性不足的问题,取得20%以上的降本效果。

从Kafka到AutoMQ

公有云Kafka虽然解决了资源弹性不足的问题,但是依然有集群弹性差的问题。新出现的AutoMQ支持秒级弹性吸引了我们的注意。

图 5 AutoMQ 架构

AutoMQ采用存算分离架构,如图所示,具备如下特性:

  1. 共享存储:数据统一存储在对象存储中,Broker不再持有本地数据。为解决对象存储延迟高、IOPS较低的问题AutoMQ引入块存储作为WAL(Write-Ahead Log),数据先写入WAL再进行批量落盘到对象存储。
  2. 单副本存储:云端的块存储和对象存储本身具备多副本特性,已在存储层保证了高可用,因此AutoMQ内部的Topic均采用单副本策略,避免传统Kafka中Broker之间的副本同步开销,大幅降低成本与数据复制压力。
  3. 兼容Kafka协议:AutoMQ基于开源Kafka改造,保留计算层逻辑,替换底层存储实现,完全兼容Kafka协议。
  4. 快速弹性:由于Broker不再存储数据,节点可快速启动或销毁,实现分钟级弹性;同时对象存储按量计费,使资源规模能够与业务流量保持高度匹配,避免资源浪费。

在完成相关性能与稳定性验证后,我们在公有云环境部署了AutoMQ,并将其纳入流数据服务存储体系。通过Stream平台逐步将私有云Kafka、公有云Kafka迁移至AutoMQ,成本进一步降低70%以上。

总结及规划

流数据因其低延时特性,已成为爱奇艺的重要数据通路。随着规模增长,传统私有云Kafka在弹性、成本与治理上逐渐遇到瓶颈,因此,流数据存储架构从“管集群”转向“管数据”,并通过Stream平台与Stream-SDK实现解耦与统一治理。随后引入公有云Kafka和AutoMQ,使系统在弹性、运维效率和成本上都实现了显著提升。

爱奇艺目前约40%的流量已迁移到公有云Kafka或AutoMQ,其中一半是AutoMQ,下一步将继续扩大AutoMQ的使用规模,并探索AutoMQ的自适应自动弹性机制,持续降本。

本文作者:OceanBase 资深技术专家 张易

摘要:
在 AI 时代,OceanBase 以混合搜索为核心的多模能力,从 AI Agent 的视角出发,为大模型提供高质量的上下文信息,在提升 AI 应用效果的同时显著降低运行成本,真正实现了技术与业务价值的统一。

在 AI 与数字化转型驱动的时代,企业正面临数据形态、处理速度与复杂性的剧增。近日,全球知名咨询机构 Forrester 在其最新报告《Multi-Model Data Platforms Landscape, Q4 2025》中指出,多模数据平台(MMDP)已成为应对现代应用复杂数据需求的关键趋势。报告将 MMDP 定义为“在一个数据库管理系统中支持多种数据模型”的统一平台,其核心价值在于简化技术栈、降低数据冗余并加速开发周期。

OceanBase作为“Notable Vendor”出现在该报告中,这不仅是对 OceanBase 多模一体化产品的认可,更预示着化繁为简、现代架构的数据时代即将来临。

在报告中,OceanBase 被认为是聚焦以下扩展用例的代表性厂商:

Agentic AI
Forrester 认为 MMDP 是 Agentic AI 的大脑与记忆。AI Agent 需要推理,它需要知道事实、拥有记忆并理解逻辑关系。MMDP 提供了向量检索(找相似)、图谱(找逻辑)、结构化数据(找事实)的统一平台,防止 AI 幻觉。

多模数据统一检索
Forrester 认为 MMDP 能为开发者提供一键“原子操作”。比如,用户修改资料,既要改结构化数据里的名字,又要改全文搜索里的索引,还要改图数据里的节点,过去这需要写很复杂的分布式事务代码,而 MMDP 允许用统一查询语言在一个步骤内完成跨模态的增删改查,保证数据一致性,极大简化开发。

推荐引擎
Forrester 认为 MMDP 能够提供比“猜你喜欢”更懂你的推荐。传统的推荐只看买了什么,现在的推荐要看用户的实时点击流(行为)、朋友买了什么(关系)、用户搜索的关键词(文本语义),结合了图计算(社交推荐)和多模态搜索(语义推荐),提供更精准的上下文感知推荐。

本文将深度解读 OceanBase 多模一体化能力,探讨其如何以原生一体化的架构,帮助企业架构师与 IT 决策者厘清正在面临的“架构之问”:是继续采用“烟囱式”的数据库组合,还是转向真正的一体化平台?

从“多”到“一”:终结架构碎片化,多模是 AI 时代的必然选择

长期以来,业界普遍采用“为专业场景选择专业工具”的理念,构建了所谓的“多语言持久化”(Polyglot Persistence)架构,即为不同数据模型部署独立的数据库系统。然而,这种模式在业务复杂性指数级增长的今天,其弊端日益凸显,逐渐演变为创新的沉重枷锁。

这种“数据库联邦”模式的困境,在许多积极拥抱 AI 的企业中表现得尤为突出。它们为了实现语义搜索、精确匹配与关系查询,被迫引入由关系数据库、搜索引擎与多种向量数据库构成的复杂技术栈。这不仅导致架构臃肿、运维成本高昂,更在稳定性、数据一致性与开发效率上带来了巨大挑战,形成了沉重的技术债务。

货拉拉在转型过程中的早期探索,便是一个深刻的例证,其面临的动态 Schema 变更、混合检索与多系统运维难题,正是这种碎片化架构的典型缩影。

这些痛点深刻揭示了“烟囱式”架构的本质缺陷——它将数据管理的复杂性转嫁给了应用和运维团队。正如 Forrester 报告所指出的,MMDP 的核心价值正是通过在一个数据库内部实现统一的数据存储、事务处理和治理,从根本上解决数据孤岛问题,降低总拥有成本(TCO)并提升业务敏捷性。


Forrester: MMDPs Enable Simpler Cross-Model Querying

解构 OceanBase:为 AI Agent 打造的混合搜索“大脑”

在 AI Agent 与大语言模型(LLM)引领技术浪潮的今天,数据库的角色正在被重新定义。它不再仅仅是数据的存储仓库,更是决定 AI 应用智能水平与运行成本的“上下文引擎”(Context Engine)。

正如 OceanBase CTO 杨传辉所言,“向量搜索只是 AI 数据库的初级阶段,最终所有向量搜索都会演进为混合搜索——能否支持混合搜索,正是衡量 AI 数据库核心实力的关键分水岭”。


OceanBase 的多模一体化实现混合搜索

OceanBase 的多模能力并非简单的“功能叠加”,而是根植于其原生一体化的分布式架构。这种架构将关系、向量、全文、JSON 等多种数据模型统一在单一引擎下,共享同一套存储、事务和查询优化器。其核心价值主张,正是从 AI Agent 的视角出发,通过强大的混合搜索能力,为大模型提供更高质量、更精准的上下文信息,从而在提升 AI 应用效果的同时,显著降低因 Token 消耗而产生的计算成本。

混合搜索:AI 时代的“上下文工程”基石

AI 应用,尤其是 RAG(检索增强生成)应用,其效果的优劣极大程度上依赖于提供给大模型的上下文质量。大模型虽然具备强大的计算能力,但缺乏长期记忆,这就需要数据库为其存储并管理上下文信息,同时精准输出大模型所需的上下文——这一过程被称为“上下文工程”(Context Engineering)。

一个典型的复杂查询,如“推荐附近 500 米内,人均消费低于 25 元,评价超过 4.5 分,且环境安静的咖啡厅”,单纯的向量或文本搜索都难以胜任。这需要一个能同时理解并处理多种数据维度的“大脑”。

OceanBase 的混合搜索能力,正是为解决这类多维度信息综合检索的难题而生。它将四种关键的搜索能力无缝融合在一个查询引擎中:

这种“多路召回,统一排序”的模式,让 OceanBase 能够先通过关系、标量数据进行高效过滤,大幅缩小检索范围,再在小范围内进行精准的向量或全文搜索。每一路检索都会产出部分结果,最终将各路结果融合,并经过全局重排序(Rerank),才能为大模型输出其真正需要的精准结果。


OceanBase 混合搜索机制

这种机制不仅极大地提升了查询的准确性(Recall)和精确率(Precision),更重要的是,它将最相关、最精炼的信息作为上下文喂给大模型,有效避免了无关信息对模型推理的干扰,并从根本上减少了昂贵的Token消耗,直接降低了AI应用的运行成本。

技术利器一:高性能向量搜索是混合搜索的基础

高性能且功能完备的向量搜索,是混合搜索的核心基础。目前,OceanBase 向量搜索性能已达到业界开源向量数据库的先进水平——无论是稠密向量还是稀疏向量,在向量数据库领域主流 Benchmark 测试中均表现突出。

在 VectorDBBench 的测试中,OceanBase 在不同过滤率下的性能全面占优。同时,OceanBase 的磁盘向量索引,在构建时间与存储占用两方面,也实现了业界领先。


OceanBase 向量性能测评

更重要的是,OceanBase 实现了向量搜索与全文搜索的深度融合,通过多路搜索显著提升召回效果。测试数据清晰呈现了不同搜索方式的召回表现:仅采用单一搜索路径(无论全文搜索、稠密向量还是稀疏向量),都难以达到最优召回效果;唯有将稀疏向量、稠密向量与全文搜索相结合,才能实现更优的召回表现,达成 1+1 > 2的协同效应。


OceanBase 多路召回评测

值得一提的是,这两大能力均构建于 OceanBase 数据库原生架构之上,天然继承了分布式架构的弹性扩展特性与对象存储的高效适配能力。

技术利器二:半结构化数据的高效处理(JSON)

在 AI 场景中,企业在处理海量 JSON 数据(如用户行为日志、订单轨迹、动态特征字段)时,普遍面临 Schema 重复存储导致空间浪费、按行存储导致压缩率低、查询性能低下等痛点。

OceanBase 针对性地设计了创新的存储方案。它采用 JSON 二进制存储,并创造性地实现了“列化拆分”。通过智能识别“高频列(Frequent Col)”与“稀疏列(Spare Col)”,将频繁访问的字段独立成列存储,稀疏字段则聚合存储。


OceanBase JSON 列化拆分机制

这种设计带来了显著的技术收益。首先是极致的压缩效率,拆分后的独立列可利用 OceanBase 成熟的列存编码能力进行高效压缩。在 TPCH-10G 数据集上的测试显示,其压缩比是传统文档数据库的 3 倍,直接降低了存储成本。

其次是查询性能的加速,查询特定字段时,只需读取对应列,极大减少了 I/O 开销。此外,用 JSON 格式动态扩展特征字段,还可帮助企业减少 30%-50% 的数据清洗成本。这一能力对于 AI 应用中频繁变化的特征工程尤为重要,使得企业无需频繁修改 Schema 即可灵活应对业务需求。

技术利器三:HTAP 能力支撑 AI 场景的元数据管理

在 AI 场景中,除了要开展多路搜索,还需妥善管理 AI 场景下的元数据。要做好 AI 数据库的元数据管理,不仅需要支持元数据的实时写入与事务一致性,还需实现元数据检索结果与多路搜索结果的 SQL 级联动。

在这方面,支持 HTAP 的关系型数据库是更优选择。通过将关系模型与向量、全文、JSON 能力深度融合,OceanBase 最终形成了全面的混合搜索能力。


OceanBase 如何解决 AI 场景元数据管理问题

例如,在知识库场景中,需要管理用户权限、文档分类、访问日志等大量元数据,同时还要进行文档的语义检索。传统方案需要在应用层协调关系数据库与向量数据库的查询结果,而 OceanBase 则可以通过一条 SQL 完成“先通过关系过滤确定用户可访问的文档范围,再在该范围内进行向量语义搜索”的复杂操作,极大地简化了开发逻辑并提升了查询效率。

一体化架构:从“数据库联邦”到“统一数据底座”

过去,企业为了实现类似的多模态处理能力,不得不拼凑一个由关系数据库、向量数据库、全文搜索引擎等多种产品组成的“数据库联邦”。这种“烟囱式”架构不仅运维复杂、成本高昂,更在数据一致性、开发效率和系统稳定性上带来了巨大挑战。

OceanBase 的一体化架构则试图改变这一局面,为企业 AI 应用提供坚实的统一数据底座。多个客户的成功实践,生动地诠释了这一价值。

蚂蚁集团“百宝箱”的智能体在线搜索就是一个典型案例。其复杂的地理位置、用户评分、消费水平和语义偏好混合查询需求,在 OceanBase 中通过一条 SQL 即可实现,完美替代了原先 Milvus + Zsearch + OceanBase 的复杂组合。这种将多路检索逻辑从业务层下沉到数据库内核的做法,极大地简化了业务实现,实现了在线高性能混合搜索。


蚂蚁集团百宝箱 Agent 在线搜索示例

货拉拉则基于 OceanBase 的混合搜索能力,构建了一站式的企业 AI 数据底座,支撑起包括知识库平台、AI Coding、Agent 平台、ChatBI、智能客服等多种 AI 应用。这不仅用单一技术栈取代了原有的 vsearch + Weaviate + Milvus 等多个开源组件,解决了系统的稳定性难题,还复用了 OceanBase 成熟的高可用能力,实现了 RPO=0、RTO<8 秒的金融级标准。

在具体应用中,货拉拉通过“资损代码识别”场景,利用历史案例向量化与实时代码相似度检索,有效规避了潜在的财务风险;在“数仓AI答疑助手”项目中,更是融合了向量、标量、全文关键字等多种检索方案,并结合重排序模型,显著降低了内部数据查询门槛和人力成本,提升了数据开发人员的效率。


货拉拉 AI 应用架构

中国联通利用 OceanBase 构建了拥有 10 亿级向量规模的公司级统一知识库平台。原先采用“关系数据库+Elasticsearch”的架构,在切换到 OceanBase 后,查询执行效率提升到原 Elasticsearch 方案的 2 倍,同时解决了复杂的用户-文档权限管理问题。通过融合关系查找与多路搜索,联通成功实现了知识库的精细化权限管控及灵活的用户间权限共享需求,支持公共文档与私有文档的统一管理。


中国联通 AI 应用架构图

飞猪也通过 OceanBase 统一了其智能体数据平台的后端,用一套系统替代了原先的分布式 KV + 分布式 Table + 搜索 + 向量的复杂架构。这不仅统一了技术栈,还实现了对知识库、Memory 等多种数据的统一支持,SQL 的简单易用性与稳定低延迟的特性,让开发团队能够更专注于业务创新。


飞猪 AI Agent 架构

这些案例共同证明,OceanBase 的一体化架构并非简单的功能聚合,而是通过在内核层面实现多模数据的统一管理与查询,从根本上解决了数据孤岛问题,降低了技术栈的复杂性,最终加速了AI应用的创新与落地。

从技术到业务:OceanBase 多模一体化的实践价值

技术的先进性最终需要通过业务价值来体现。从上述案例中,我们可以清晰地看到 OceanBase 多模一体化架构在 AI 时代所带来的三大核心价值:

第一,显著降低 AI 应用的运行成本。 通过混合搜索提供的精准过滤与排序机制,OceanBase 能够为大模型提供更高质量、更相关的上下文信息,从而大幅减少无效 Token 的消耗。在当前大模型推理成本居高不下的背景下,这种成本优化对企业而言具有直接的经济价值。

第二,简化技术栈,提升开发与运维效率。 一体化架构让企业无需在应用层协调多个异构数据库系统,开发者可以用熟悉的 SQL 语言完成复杂的多模查询,极大地降低了学习成本与开发复杂度。同时,统一的运维管理也减轻了 DBA 团队的负担,提升了系统的整体稳定性。

第三,加速 AI 应用的创新周期。 当数据基础设施变得简单、高效且可靠时,业务团队可以将更多精力投入到 AI 应用本身的创新上,而非陷入复杂的数据管道搭建与维护中。这种“基础设施即服务”的理念,正是 OceanBase 一体化架构的核心价值所在。

选择下一代数据基石,拥抱智能未来

Forrester 的报告揭示了多模一体化不仅是技术趋势,更是企业在 AI 时代保持竞争力的战略选择。面对日益复杂的数据环境,传统“烟囱式”的架构已难以为继。

OceanBase 提供的不仅是一个功能丰富的数据库,更是一个稳定、高效、面向未来的一体化数据基石。它通过在存储、查询、事务等层面的原生一体化设计,让企业能够更从容地应对数据融合的挑战,将宝贵的精力聚焦于业务创新本身。

特别是在 AI 时代,OceanBase 以混合搜索为核心的多模能力,从 AI Agent 的视角出发,为大模型提供高质量的上下文信息,在提升 AI 应用效果的同时显著降低运行成本,真正实现了技术与业务价值的统一。

对于正在寻求下一代数据架构的架构师和 IT 掌舵者而言,可以重新审视自身的技术栈,考虑 Forrester 倡导的多模数据处理平台,为企业的下一个十年发展奠定坚实基础。

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

管理数千集群、数万 Redis 节点的规模化场景下,传统人工调度模式的效率瓶颈与稳定性风险日益凸显。信也科技通过构建Redis 实例自动化调度体系,以系统自动执行替代人工重复操作,实现资源精准管控与效率跃升,打造支撑业务缓存体系的核心技术基石。

一、演进起点:传统人工调度的痛点困局

信也科技Redis管理平台已承载上千集群、数万Redis-server节点、百台宿主机,内存使用率与分配率稳居业内第一梯队。但随着业务高速增长,传统手动调度模式的弊端逐渐暴露,成为运维效率与集群稳定性的制约因素:

  • 人力成本居高不下: 过保机器替换、资源打散迁移等重复性工作,每周需投入 2 人天专项人力,机械操作占比高,核心运维精力被严重分散;
  • 稳定性风险难以规避: 人工批量操作易出现漏操作、重复操作、误操作等问题,直接威胁集群可用性,引发业务故障隐患;
  • 响应速度滞后业务需求: 依赖 DBA 实时监控资源水位,无法快速响应突发内存使用率飙升场景,易引发性能瓶颈,影响业务体验。

针对上述痛点,我们内部负责 Redis 技术体系建设与运维的核心团队 —— 基石 Redis 团队,正式启动自动化实例迁移能力建设。核心目标是通过调度全流程自动化,实现 “高效精准、安全可靠、资源最优” 的集群管控效果,破解传统运维模式的困境。

二、方案设计:自动化调度的核心流程闭环

自动化调度以“系统自动执行+人工轻量管控”为核心,整体流程形成闭环,兼顾效率与可控性,分为4步:

  1. 筛选迁移对象: 系统基于预设阈值(如内存使用率、机器服役周期)自动识别待迁移节点/宿主机,也支持运维手动筛选;
  2. 创建迁移工单: 运维在平台发起工单,系统自动通知集群负责人及相关成员,确认后触发调度流程;
  3. 生成迁移任务: 系统根据资源分布、部署规则自动规划迁移路径、目标机器,无需人工干预;
  4. 自动化执行迁移: 系统全程自动完成“添加从节点→数据同步校验→主从切换→节点下线”,运维仅需监控进度。

image.png
Redis过保替换流程图

三、核心技术:自动化调度的高可用保障机制

自动化调度的核心挑战是迁移过程中“业务无感知”,因此我们为每一步调度环节都设计了自动化校验与容错机制,从技术层面筑牢迁移安全防线。

1. 添加从节点:规则化自动选址,筑牢基础

系统自动为待迁移节点创建替代从节点,严格遵循5大部署规则,平衡可用性与资源利用率:

  • 新节点与原节点同机房部署,降低网络延迟对同步的影响;
  • 规格、Redis版本与原节点完全一致,规避兼容性问题;
  • 同一集群节点分散部署在不同宿主机,避免单点故障牵连集群;
  • 宿主机内存分配上限设为90%,预留10%缓冲应对业务突发增长;
  • 优先选择剩余可用内存多的宿主机,提升整体资源利用率。

注:整个节点部署流程完全自动化,涵盖机器筛选、端口分配、槽位配置及主从关系建立等全环节,无需运维逐节点手动操作,大幅减少重复工作量。

2. 数据同步校验:自动化双重核查,确保一致

添加从节点后,系统自动调用info replication命令(Redis查看主从复制状态的核心命令)完成双重校验,仅通过校验方可进入下一步:

  • 主节点视角:新增从节点接入正常,同步状态state=onlineoffset≠0
  • 从节点视角:角色为slave,同步主节点数据与其一致,master_link_status:upmaster_repl_offset≠0
  • 二次校验:首次校验通过后,系统延迟30秒自动复核,规避redis主从节点瞬时同步异常的风险。

3. 主从切换:自动化按需触发,平稳过渡

  • 若原节点为从节点,则系统无需进行切换动作,直接执行后续下线流程;
  • 若原节点为主节点, 系统自动对新从节点执行cluster failover命令(Redis集群手动故障转移命令,此处由系统自动化调用),将其选举为新主节点,确保业务无感知。

4. 结果校验与异常回滚:自动化兜底

主从切换完成后,系统并不会直接进入原节点下线流程,而是先自动开展全节点穿透式核查,确保集群整体状态稳定后再推进后续操作:

  • 新主节点:角色为master,从节点数量≥1,同步状态均正常;
  • 所有从节点:同步目标为新主节点,无同步中断情况。

下线原节点前,系统还会自动校验业务连接是否完全迁移,确保无流量残留。同时支持一键回滚,若任一环节异常,系统可自动(或运维手动触发)回滚至迁移前状态,降低故障风险。

5. 自动化消息通知:全程透明可控

  • 工单创建、调度启动、完成/失败等关键节点,系统自动通知集群负责人及运维;
  • 调度失败(如宿主机资源不足、同步超时)时,实时推送告警并附异常日志,助力快速排查。

image.png
整体功能展示图

四、可视化管控:自动化调度的全生命周期监控

为保障自动化调度的可控性,平台配套了可视化任务管理界面,支撑运维对调度全流程进行轻量管控,实现“自动化执行+可视化监控”的双重保障:

  • 待执行任务:支持取消、修改执行时间、手动触发执行;
  • 执行中任务:实时展示迁移进度、各环节状态及校验日志,异常节点自动标红;
  • 历史任务:完整留存调度记录,支持按集群、时间检索,便于问题复盘与合规审计。

这套覆盖调度全生命周期的可视化管控能力,为 Redis 实例自动化调度方案的稳定落地、风险可控提供了关键支撑。经过多场景实际落地验证,该方案已充分适配业务需求,以下是经验总结与未来规划。

五、落地效果与经验总结

1. 核心落地效果

  • 资源利用率优化: 通过自动化调度动态平衡资源,宿主机内存使用率稳定控制在阈值内,兼顾高利用率与冗余缓冲;
  • 稳定性提升: 调度全流程自动化校验,彻底杜绝人工误操作,迁移零业务中断;
  • 效率激增: 自动化替代90%+人工调度工作,每周2人天的重复操作被解放,运维可聚焦核心优化工作;
  • 集群韧性增强: 调度规则强制实现节点分散部署,机器故障对集群的影响范围大幅缩小。

2. 可复用实战经验

  • 自动化优先保障数据一致性: 多维度自动化校验、二次复核是避免迁移故障的核心,比人工判断更精准高效;
  • 资源分配需“留有余地”: 90%内存分配阈值+同机房部署规则,平衡利用率与业务稳定性,该阈值可根据集群负载特性动态调整;
  • 自动化≠失控: 配套可视化监控、异常告警与回滚机制,才能让自动化调度更安全,降低运维心理负担;
  • 调度规则需贴合业务场景: 节点分散、版本一致等规则,需结合自身Redis集群架构(如主从、哨兵、集群模式)设计,避免通用规则适配偏差。

3. 技术展望

基于现有自动化能力,我们计划从“智能升级、链路完善、架构适配”三个方向持续迭代,让Redis实例调度更贴合复杂业务场景:

  • 全链路自动化: 完善集群自动部署、节点垂直扩缩容的自动化能力,形成Redis全生命周期管控闭环;
  • 智能化策略升级: 引入机器学习算法,基于历史资源使用数据预测集群负载趋势,实现调度任务的主动触发与最优路径规划;
  • 多架构兼容适配: 拓展对Redis Cluster、Redis Sentinel等主流架构的全面支持,覆盖更多业务场景的调度需求。

作者介绍

图片

图片

36ecf4845e41c9282eecdb5b690cc65b_6390495865593148019638243.png

在金融科技(FinTech)进入 2026 年的今天,数字化转型已步入“无人区”。随着生成式 AI 与大模型在金融业务场景的广泛落地,金融软件系统的架构正经历从“云原生”向“AI 原生”的范式跃迁。然而,架构越先进,质量保障(QA)的压力就越大。传统的测试手段在面对微服务交织、逻辑动态变幻的金融交易系统时,日益显现出“力不从心”的疲态。

1月19日,这一局面迎来重要里程碑。由中国信通院、中国人工智能产业发展联盟(AIIA)牵头,联合 Testin云测、中国工商银行、国泰君安证券、海通证券等头部金融与技术机构共同编制的《面向软件工程的智能体技术和应用要求 第3部分:测试智能体》(以下简称《规范》)正式发布。这不仅是一份技术文件,更是金融行业在 AI 时代守住安全红线的“数字化白皮书”。

行业深蹲:金融软件质控的三大“效能黑洞”

长期以来,金融机构的研发效能被三个核心痛点紧紧拽住。

首先是高频迭代与回归压力的矛盾。在互联网金融产品竞争白热化的当下,某股份制银行的 App 每周更新频率甚至达到“一周三版”。传统的自动化测试依赖人工维护脚本,往往新功能还没测完,UI 布局又改了,导致脚本大面积报废。

其次是业务逻辑的深度耦合。金融交易链路长、涉及私有协议多,AI 辅助工具若不理解“贷款审批”或“清算对账”的领域上下文,生成的测试案例往往流于表面,无法触达深层逻辑漏洞。

最后是合规与容错率的极低门槛。金融系统一旦在生产环境出现 Bug,面临的是公关危机、监管处罚乃至经济损失。

技术破局:Testin云测如何重塑“智测大脑”?

作为本次《规范》的核心参编单位,Testin云测凭借连续多年深耕 AI 测试的经验,其技术实力在最新公布的“2025 AI 测试服务商”榜单中荣登榜首。其核心产品 Testin XAgent 成为金融企业破局的关键。

  1. 深度语义理解与 RAG 知识注入 传统的 AI 工具容易产生“幻觉”,这对追求绝对精确的金融业是致命的。Testin XAgent 引入了 RAG(检索增强生成)技术,将银行内部沉淀的 PRD 文档、接口规范、历史缺陷报告等私有知识进行向量化。这意味着,当测试人员输入“测试大额存单申购流程”时,AI 能够自动联想相关的限额逻辑、风控规则,生成的测试案例采纳率高达 60% 以上,实现了真正的“懂行测试”。
  2. 视觉自愈引擎攻克 UI 频繁变更 针对 UI 自动化的“脚本易碎”问题,Testin XAgent 率先将视觉大模型(VLM)与 OCR 技术融合。它赋予了智能体像人眼一样的感知力,不再机械地识别控件 ID。在实际应用中,即使 App 界面改版,智能体也能通过逻辑关联自动“认路”,将脚本稳定性拉升至 95% 以上。
  3. 跨平台的高精度闭环 金融 App 必须兼容上千款移动终端。Testin云测通过云端真机实验实验室,配合 AI 智能诊断功能,将原本需要人工排查 30 分钟的错误缩短至 5 分钟。在某大型股份制银行的实践中,回归测试周期从数周缩短至数天,业务场景覆盖率提升了 300%。

趋势洞察:从“成本中心”向“价值中心”的跃迁

《规范》明确了测试智能体需具备感知、记忆、规划、执行四大核心能力。这标志着测试工作正从人力密集型向机器智能驱动转变。

Testin云测 CEO 徐琨曾指出:“软件质量已成为数字经济时代的关键生产力。”对于金融机构而言,测试智能体不仅是省钱的工具,更是构建“数字免疫系统”的核心。通过 AI 的闭环反馈,企业能提前预判风险,将“事后发现”转变为“事前预防”。

随着标准化与智能化的同频共振,以 Testin云测为代表的领军厂商,正在 AI4SE 的新纪元中,助力金融科技夯实数字基石,催生出更具韧性、更敏捷的未来。