2026年4月

速读

在美团,我们构建了以指标平台为核心的新一代 BI 架构,通过自动语义和增强计算两种核心能力的建设,部分解决了传统 BI 平台在个性化数据集驱动下产生的数据口径混乱、查询性能差等问题。

自动语义能力实现了“定义即研发”。它将业务语言定义的指标自动解析为结构化的逻辑表达,并通过主外键关系将数仓模型自动关联成星型、雪花等模型,从而扩展出复杂指标。该能力贯穿了指标定义、模型关联、指标高亮与路由选表以及查询语义构建的全流程。我们利用自动语义能力,并结合指标仓库的预计算模式,不但使业务能够灵活扩展、查询、分析复杂指标,也满足了在有限时间内完成指标扩展、模型关联等复杂查询前置依赖计算的要求。

增强计算能力则旨在平衡运营监控(要求秒级响应)与灵活分析(处理海量数据)两种场景下的性能与成本挑战。它通过智能查询服务(支持多引擎模型、查询降级策略)和智能物化(自动构建宽表和汇总表)来提升查询稳定性和性能。此外,我们也对增量计算引擎进行探索,利用其存算分离、弹性伸缩、向量化执行等特性,进一步提升了查询性能和系统稳定性。

目前,该平台已支持公司百余业务线,查询量达百万级,查询成功率超过 99.9%,并在新引擎评测和灰度中验证了性能优势。未来,美团将继续在自动语义、增强计算深化演进,为数据分析智能化做好准备。

1 指标平台概述

1.1 指标平台和核心能力

近年,各种组织都在使用 BI/ABI(Busniness Intelligence/Analytics and Business Intelligence)平台,对数据进行建模、分析、可视化,支持有效决策和价值创造。随着技术的进步,BI 已由传统的以报表为核心的 ETL 驱动模式,变为了以数据集为核心的敏捷驱动模式。在后者,数据消费者(数据运营、数据产品、分析师等)可以通过 BI 平台中的无代码 ETL 工具或者 SQL 构建个性化的数据集,进行图表制作、自助分析,无需完全依赖数据研发进行开发和排期,具有一定的灵活性。但也带来了数据质量低(大量数据集导致口径不一致,数据混乱),查询效率低(非研发建立 SQL 数据集性能难以保障,抽取到各种分析引擎中又导致查询资源浪费),可复用性差(指标维度无法跨数据集分享,更难以在不同工具不同系统间使用)等问题。

为了解决上述问题,2021 年由 Airbnb/Minerva 等公司首先提出了指标平台这一概念。指标平台使用唯一的指标层来连接下层数据和上层应用,贯穿指标定义、管理、研发、应用全流程,来解决数据混乱问题。在强调数据治理的同时,也通过指标复用在一定程度上避免了资源浪费,理论上可以达到治理、成本、效率的平衡。近些年来,指标平台逐渐发展和完善,从最开始的仅仅进行指标口径治理的管理平台,过渡到了能够连接下游 BI 应用的管理、应用打通阶段。国内大型云计算供应商和传统 BI 产品厂商,均在分析套件中提供了指标平台产品,国外 Gartner ABI 分析报告在 2023 年将指标仓库(Metrics Store)列为了 BI 关键的 12 项能力之一,并在 2025 年将指标层(Metrics Layer)列为了 BI 常见能力的第一位。

指标平台的核心能力通常分为以下几点:

  • 指标的定义和管理:指标定义描述了业务活动表现的量化标准,需要具有明确唯一、标准易懂、灵活扩展等特征。
  • 逻辑拓扑和模型路由:指标平台可以将用户配置在指标定义中的业务语言进行结构化和逻辑化处理,转化为底层指标、维度、模型间的拓扑关系,自动建立业务语义和研发语义之间的桥梁。
  • 语义查询和分析计算:语义查询允许基于 SQL 查询的方式表达部分指标的消费过程,分析计算负责根据语义查询的结果还原部分指标构建过程,并为跨源等场景的指标表达和统计分析需求提供解决方案。两者共同完成对全体指标的表义、计算、分析。
  • 可视化分析和开放数据服务:指标平台通过集成类型丰富、使用便捷的可视化分析组件,为业务提供数据分析和报表搭建能力。同时也提供统一的接口服务,允许第三方应用通过 API 访问指标数据,体现了指标平台一处定义,多处运行的设计理念。

1.2 指标平台的挑战

指标平台已经在业界有一定规模的实践,但从其驱动特性和具体落地看,比较适合于规模中小,数据需求相对固定的业务模式。面对数据体量大,需求变化迅速的业务(例如互联网、零售、金融等),往往有以下要求和挑战:

(1)更丰富的指标定义能力和表述语义,例如,指标限定指标(e.g. “本月营业时长大于 50 小时的商家平均营业额”)、忽略维度(e.g. “商品类型收入占比”=“收入/收入【忽略商品】”)、二次计算指标(e.g. “日均订单量”)、期初期末指标(e.g.“月初入职人数”)、存留指标。

(2)灵活的分析和扩展能力:业务不仅需要查询指标数据,同时也提出大量的分析需求(同环比、时间窗口、占比合计等),这些分析需求在由数据集驱动的 BI 工具中,往往由业务自助对数据集进行扩展和丰富完成。但在指标平台中,由于强治理诉求(例如:同环比定义的一致性)以及指标数据的具体实现被系统屏蔽,这些分析方法需要由平台能力进行统一的实现和沉淀。此外,业务需要在指标平台之外,灵活的扩展已有指标维度,进行实验性质的分析和探索。

(3)自动化、快速响应的语义层:一方面,要求根据指标定义,从明细层生成原子指标,衍生、计算成上层复合指标,并支持上述的查询、分析、扩展语义。另一方面,面对万级别的模型,指标,维度,迅速构建实际查询 SQL,有限时间内(BI 工具一般要求秒级响应)完成指标维度拓扑,模型选择淘汰,查询、分析语义生成。

(4)计算性能挑战:在定义即研发的模式下,指标取数和分析会转化为面向数仓明细层的海量数据查询,对查询引擎算力要求更高。指标平台一处定义,多处运行的模式意味着对运营监控(Serving)和探索分析(Ad-hoc)场景的兼顾:一方面是传统的面向运营用户看数模式,指标维度数量大,组合和筛选条件相对固定,要求性能响应高于数据规模;另一方面是灵活的分析探查模式,指标维度组合灵活,分析方法不固定,筛选条件和时间周期分散,要求数据规模高于性能响应。这两种矛盾的性能需求模式,对底层计算能力提出了更高挑战。

2 美团 BI 在指标平台上的探索

美团指标平台是美团内部自建的元数据及模型管理平台,面向数据研发、数据产品团队,提供业务全域下数仓规划、指标维度统一管理、标准建模及指标自动生产的产品能力与方法论。美团 BI 平台是公司级一站式数据分析平台,面向数据产运营、研发、分析师、管理者等多种角色,支持多种数据源便捷查询,灵活进行数据可视化分析,快速搭建数据报表和数据监控,提供安全、高效、敏捷的数据分析服务。

在建设初期,技术团队也遇到了业界自助敏捷 BI 的共性难题 :一方面业务创建了百万级别的数据集,造成了口径混乱、数据不一致等问题,对查询性能也难以保障;另外一方面,初版指标平台提供的指标维度丰富程度无法满足业务需求,且仅提供查询语义,不能在 BI 工具上进行高阶数据分析,也无法进行指标维度衍生和扩展。为了解决以上问题,技术团队进行了新一代 BI 平台的开发:新架构以建设指标平台并打通 BI 应用为主要思路,在解决数据消费侧传统问题的同时,也注重数据生产侧的效率提升

新一代指标平台对数据仓库、自动语义、增强计算和分析工具等四个方面都进行了演进:

  • 数据仓库:传统数据仓库需要完成明细层、汇总层和应用层的数仓开发,由于规范难落地、定制化需求和历史包袱等问题,数仓的烟囱化建设越来越严重,形成多个无法流通的数据孤岛,同时也导致库表数量快速上升,加剧存储资源浪费。在指标平台中,数仓研发的精力从承接业务需求转向夯实基础数据,提供标准的明细模型和统一的聚合模型,这些结构稳定、质量良好、可复用高的数仓模型为上层提供了完善且统一的基础指标维度。
  • 自动语义:传统数据工具的指标管理更偏向于表面的口径描述和简单的审核流程管理。在美团指标平台中,元数据管理以自动语义为核心,涵盖了指标定义的配置和使用全流程,实现了指标定义即研发。在配置能力上,指标平台提供了命名规范、标准模板、口径治理、变更校验、智能推荐等功能,保障了指标口径的标准和统一。在使用能力上,指标平台将业务语言解析为结构化和逻辑化的表达,通过多表自动关联成星型模型、雪花模型和星座模型,并结合指标血缘最终扩展出复杂指标。在指标消费场景,通过全局路由和数据集分别表征全局的统一口径和细分场景的特定口径,满足不同阶段不同场景下的数据治理和数据使用诉求。在查询服务上,分析计算服务可以依据指标定义和模型关联,根据实际业务需要灵活选取构建的逻辑宽表,通过执行计划加物理查询的方式实现指标消费。
  • 增强计算:传统的数据工具依赖于数仓对数据的汇总加工,而在指标平台中,通过明细数据即可完成指标的定义,并通过自动语义的能力实现指标的查询。但面对庞大的明细数据量,如何满足业务的查询性能和稳定性成为要解决的关键问题。在查询性能方面,我们研发了智能物化,不再依赖数仓 RD 开发,系统根据指标定义自动完成宽表和汇总表的开发,并能自动完成物化任务周期调度、数据回溯;在稳定性方面,我们有一套完整的指标路由、降级策略,保证查询的稳定性。在此基础上,我们进一步调研并集成了新架构计算引擎,基于其强大计算能力和稳定性设计,在查询性能和可靠性方面有了更有力的保障。
  • 分析工具:传统分析工具中,同环比等分析需求往往由业务自助在数据集中完成,切换分析场景或者分析工具需要重新找表和写 SQL,整体分析流程割裂且不连贯。在美团指标平台中,同环比、时间窗口、占比合计等分析需求都由平台统一进行实现和沉淀,各个分析工具基于平台的统一口径进行指标消费,实现一次定义全局消费。指标平台也支持用户快捷配置各类丰富的自定义指标维度进行实验探索。

以上的各层系统演进,重点在于“自动语义”和“增强计算”两大核心能力的建设,下面我们将分别进行详细阐述。

2.1 自动语义

自动语义将业务语言定义的指标口径解析为结构化的逻辑表达,并通过主外键关系将数仓模型自动关联成星型模型、雪花模型和星座模型,给原子指标提供了更丰富的分析视角,并扩展出衍生、复合指标。在实际执行查询计算时,自动语义根据指标定义和模型拓扑,通过智能路由选表构造逻辑执行计划和物理查询计划,实现定义即研发。

2.1.1 指标定义及加工

指标定义采用业务口径和技术口径定义相连接的设计,业务团队负责描述指标的业务计算口径,数仓团队负责提供指标的原子生产过程,指标平台可以根据注册的业务和技术信息推导非原子指标的生产过程并进行指标表达。美团指标平台具有以下能力:

  • 指标定义及管理:美团指标平台支持丰富种类的指标模板,包括原子指标、四则运算指标、二次计算指标、留存指标、条件判断指标、复合指标等指标类型,也支持指标限定指标、忽略维度,受限维度、强制维度、GroupingSets 维度组、SQL 模型变量、多语言维度等特性,这种配置化和模板化的业务语言不仅有助于业务进行自助灵活的配置,也便于下游推导复杂指标的生产过程。系统还基于标准的词根词库、口径含义检查实现标准易懂、明确唯一的指标口径。
  • 标准化建模:对于不同层次、不同阶段、不同场景的数仓建设诉求,美团指标平台提供丰富的模型类型。对于规范化的数仓模型,可以手动关联多张物理表构建,形成星型或雪花逻辑结构的组件模型。对于下层数仓建设成熟度不够,需要添加较多处理逻辑和变量,可以通过灵活的 SQL 构建组件模型。对已存指标维度,支持快速物化生产主题层、应用层模型,通过圈选指标维度并且智能构建 ETL 的汇总模型。系统也提供指标一致性校验和质量校验,帮助用户发现数据问题并辅助业务数仓的指标治理。
  • 数据消费:对于通用分析并且数仓规范程度较高的场景,可以将指标平台资产发布到 BI 平台的公共池,采用全局路由对下游提供统一的指标维度口径。新业务或者特定业务场景常常需要快速获取特定口径的指标维度以满足业务的敏捷发展,为了避免污染全局统一指标口径,此时可以将指标平台资产发布到 BI 工具的非公共池,并在数据集中圈选对应的模型、指标和维度,对下游提供指标维度口径。全局路由和数据集满足不同阶段、不同场景下的数据治理和数据使用诉求,平衡了口径治理和业务快速发展的矛盾。

基于模板表达完指标定义后,指标平台将其加工为结构化和逻辑化的指标血缘,指标血缘描述了复杂指标依赖哪些底层指标维度,采用树形结构来表达。指标血缘会将复杂指标的限定修饰、忽略维度、留存配置、二次计算配置等信息下推到底层指标维度上,从而等标记出底层指标实际查询时需要考虑的语义。指标血缘还对底层指标的查询语义进行唯一标识,帮助下游复用。如下 3 个计算指标(K1、K2、K3)都依赖了指标 K4,前两个 K4 的限定修饰都是【商家类型 = 大连锁】,可以复用同一个查询语义,而第三个 K4 具有不同的限定修饰【商家城市 = 北京】,需要单独进行查询。

2.1.2 模型关联和指标扩展

指标血缘描述了复杂指标依赖哪些底层指标及下推信息,但是仅仅依靠单个模型无法支持复杂指标的查询,比如上文提到的指标 K4 所在的事实模型可能不支持品类维度。为了扩展出更多的复杂指标,指标平台首先根据主外键对数仓模型进行连结,将多表关联星型模型、雪花模型和星座模型,为事实表上的指标提供更多的分析视角,从而扩展出复杂指标,节省了数仓开发成本。

如下所示是一个雪花模型例子,订单事实表上有商家维表的主键“商家”维度和日期维表的主键“日”维度,事实表就自动关联上商家维表和日期维表。同时商家维表也包含商家品牌维表的主键“商家品牌”维度,和商家蜂窝维表的主键“商家蜂窝”维度,商家维度也关联上商家品牌维表和商家蜂窝维表。如此通过层层关联最后形成如下的雪花模型,最终订单事实表上的指标多了商家的品牌维度、蜂窝维度、城市维度等分析视角,从而能支持“大连锁订单量”之类的复合指标,同时事实表上的指标也可以进行四则计算从而支持“单均价”之类计算指标。

经过自动关联后的雪花模型能提供丰富的维度,任意多个雪花模型都能对齐构建星座模型,如下表所示,星座模型数目 = 任意 2 个雪花模型对齐的星座模型数目+任意 3 个雪花模型对齐的星座模型数目+…+全部 N 个雪花模型对齐的星座模型数目。

可见从雪花模型出发构建星座模型存在模型数目爆炸风险,并且这些星座模型大多数对实际查询是无用的,因此指标平台舍弃构建全量星座模型,而是从指标的定义出发按需构建星座模型。但如果计算指标的成分指标有多个,那么星座模型数目等于各个成分指标雪花模型数目的乘积,也存在模型数目爆炸风险。考虑在后续查询过程中依旧需要对各个成分指标的雪花模型单独进行路由判定,所以指标平台舍弃提前进行组合,仅记录各个成分指标的雪花模型,称之为半成品星座模型。在查询时根据查询条件对雪花模型进行淘汰后再组合,大幅度减少星座模型数目。

自动关联模型后就可以计算指标的扩展方案,不同类型的指标定义具有不同的扩展方式,例如:

  • 维度限定的复合指标需要依赖指标和限定维度能从同一个雪花模型扩展出来;
  • 四则运算指标则要求依赖的成分能各自从某个雪花模型扩展出来;
  • 忽略维度则会减少对模型维度集合的要求;
  • 指标限定指标需要限定指标的模型和主指标的模型在粒度上对齐。

根据指标血缘的树形结构,最终复杂指标的扩展方案数目随着树深度和广度非线性增加,穷举容易导致扩展方案爆炸。在实际路由时指标平台考虑优先选择上层的、成分较少的成分指标来生成扩展方式,设计了带阈值和权重的广度优先搜索策略得到 TopN 的可扩展方式组合,保障了预计算和路由淘汰的计算量不会过大。

由上述细节可以看出,模型关联和指标扩展的计算逻辑存在各种遍历和排列组合,计算复杂度高,并且部分业务场景的请求需要全量的模型关联和指标扩展方案(比如后续介绍的指标高亮),现场请求计算往往无法在秒级内返回结果。技术团队在系统中采用空间换时间的策略,建设了“指标仓库”模块。该模块监听到上游元数据变更自动触发模型关联和指标扩展,将计算结果放在持久存储和缓存中,下游请求时为具体业务逻辑提供预处理的模型关联和指标扩展结果。

2.1.3 指标高亮和路由选表

完成模型关联和指标扩展后,指标平台为下游提供了丰富的指标维度,但是因为部分业务场景之间天然存在隔离,某些指标一定无法在特定视角进行分析,技术团队在产品上采用高亮的方案进行相关信息的展示。指标平台采取点选的形式为用户提供报表配置或灵活分析配置,初始态所有指标维度都处于可选状态,当用户选择某个指标维度后,指标平台计算还有哪些指标维度能参与一起分析,能一起分析的指标维度处于高亮的可选状态,不能一起分析的指标维度处于置灰的可不选状态。高亮的计算逻辑主要分为模型匹配和指标可分析维度两个步骤。

模型匹配 是指根据用户配置和查询条件对所有模型进行匹配判定。不同业务场景有不同的匹配诉求,目前已有如下规则,用户可以根据需求自由选择组合:

  • 数据范围判定:模型的数据范围必须包含用户查询的数据范围,比如特定物理城市、指定日期范围等;
  • 引擎范围判定:部分场景下用户只希望路由到特定类型引擎,例如灵活取数场景下路由到 Spark 引擎;
  • 强制维度判定:模型上的强制维度限定了该模型只能在某些分析视角进行探索;
  • GroupingSets 维度组判定:预聚合模型提供了多个可以分析的维度组,同时基于指标是否可以二次上卷和维度是否支持占位符值对查询条件进行判定;
  • 模型标签或动态范围:根据用户自定义标签或动态模型范围进行匹配判定;
  • 分区策略判定:为了避免扫描全表,用户必须对模型的分区字段进行范围选择,否则禁止使用该模型进行查询;
  • SQL 模型判定:用户需要为 SQL 模型中的变量赋值才能使用对应的 SQL 模型;
  • 多语言环境判定:多语言背景下同一维度支持不同语言维值,模型上绑定和扩展的维度需要和用户的查询语言匹配;
  • 维度集合判定:自动关联形成的星型模型和雪花模型必须提供用户选择的分析维和过滤维。

模型通过判定规则后就进入指标可分析维度的计算,这里的计算逻辑分为雪花模型和星座模型两种情况:

雪花模型

  • 指标 K1 有雪花模型 M1 和雪花模型 M2 支持,那么 K1 的可分析维度 = UNION(Dim(M1), Dim(M2))=(D1,D2,D3,D4)
  • 指标 K2 有雪花模型 M3 和雪花模型 M4 支持,那么 K2 的可分析维度 = UNION(Dim(M3), Dim(M4))=(D1,D3,D5)

星座模型

指标 K3 有依赖成分 K1 和 K2,那么 K3 的可分析维度等于成分指标各个雪花模型组合交集的并集:UNION{INTERSEC(Dim(M1), Dim(M3)), INTERSEC(Dim(M1), Dim(M4)), INTERSEC(Dim(M2), Dim(M3)), INTERSEC(Dim(M2), Dim(M4))}=(D1,D3)

通过高亮点选的形式完成指标维度选择和筛选条件的输入后,用户点击查询就进入路由阶段,此阶段根据用户查询条件为分析目标选择最优模型,从流程上来说分为模型匹配、维度路径选择和模型选择三部分。(1) 模型匹配可复用高亮计算逻辑。(2) 维度路径选择是对于雪花模型中维度选择最优的模型及其关联路径。考虑到各个模型中的维度值存在差异,模型选择策略根据数据完整性优先级递减分为以下五个层次:指标所在事实模型 > 维表模型 && 主键 > 维表模型 && 唯一键 > 非维表模型 && 主键 > 非维表模型 && 唯一键。模型集合确定后,可根据用户推荐、热度、查询性能选择模型,并选择评分最高的路径集合(通常基于贪心算法)覆盖所有查询的维度。针对部分场景对路由选表的确定性要求更高,也设计了非全局计算的稳定选择策略,保障多次规划结果一致。(3)在完成维度路径规划后,需要选择最优模型,此时指标平台通过评分机制进行选择,考虑因素包含引擎类型、推荐度、聚合类型、是否物化、计算方式、时间分区、底表数据量等。

2.1.4 查询语义构建

查询语义服务基于指标仓库构建的逻辑视图和 OLAP 引擎提供的分析计算能力,允许用户描述查询意图(DSL,Domain Specific Language)并从中分析出需要表达的目标指标内容,再用执行计划加物理查询的的方式表达出目标指标的构建过程(SQL),实现指标表义和数据消费。

查询语义服务的能力分为以下四个部分:

灵活多元的指标定义:业务可以基于已有指标、维度扩展定义私有的或一次性指标和维度,兼顾了通用(强治理)和定制化(灵活探索)场景。

  • 自定义指标:允许基于已有的指标、维度,通过定义四则运算、限定关系、同环比、占比、周期平均、累计加和、期初期末等计算过程,定义和表达新的指标口径。
  • 自定义维度:允许基于已有的指标、维度,通过条件分组、数值区间映射、日期分组等方式,定义和表达新的维度表达口径。

查询意图表达:允许用户通过 DSL 表达其在指定分析场景下的查询意图,包含以下内容:

  • 查询上下文:查询提交人业务线、业务场景、语言类型等环境信息,构建方法、缓存策略等行为信息。
  • 数据源和自定义资产元数据:负责圈选可用资产范围,包括业务线公共资产,数据集私有资产,以及服务于特定业务场景的自定义资产。
  • 查询现场:包含分析指标和维度、限定条件、排序和截断、多维查询等信息。
  • 统计分析:允许基于查询现场中的分析维度和指标,衍生定义同环比、占比、合计小计、TopN 及其他计算过程。

执行计划:将用户查询内容经分析转换,表达为任务拓扑,用拓扑节点之间的依赖关系表示指标的构建和表达过程,经过逻辑编排、分组、优化,确定最终的执行计划。

  • 拓扑:单一维度、指标的构建,可以根据其资产定义将其构建过程表达为拓扑结构(AST),一组维度、指标的拓扑又可以合并为一个整体的逻辑拓扑,该逻辑拓扑的数据结构决定了后续执行计划的具体执行过程。
  • 编排:编排主要的职能是判断一个具体的过程指标对应的逻辑构建计划(逻辑拓扑的子拓扑),是否有可能下推到物理查询,基于引擎能力直接表达。编排的过程也是逻辑拓扑剪枝的过程。
  • 分组:将逻辑拓扑中的所有物理查询叶子节点,按数据源、引擎、口径等预设规则进行分组,分组的结果决定了实际需要提交的物理查询。
  • 优化:对上述逻辑拓扑进行结构优化,去除无用计算过程和冗余节点,提升执行计划的执行效率。
  • 执行:依据拓扑排序的结果,顺次执行拓扑节点的动作,当所有节点的动作完成,指标数据的表达亦即完成。

物理查询:物理查询以拓扑任务节点的形式参与执行计划,物理查询节点是执行计划拓扑的叶子节点,一个物理查询节点代表了一个具体的物理查询过程。物理查询 SQL 的内容组织结构,采用自下向上的三层(数据源层、模型层、逻辑层)结构表达:

  • 数据源层:数据源层负责表达模型结构,模型内容来源可以是指标仓库提供的逻辑宽表,也可以是内置了复杂的、非标准化的 SQL 计算逻辑。
  • 模型层:模型层负责根据资产配置元数据,将数据源层提供的数据表或视图表达出来的字段元数据映射为表达原子化的指标和维度的计算过程。
  • 逻辑层:逻辑层负责基于原子指标和已经表达的低阶非原子指标,递归构建高阶非原子指标。

2.2 增强计算

在灵活的指标定义之后,还要保证查询性能和稳定性,在美团指标平台和 BI 分析平台,我们通过智能查询服务和探索最新计算引擎,分别从应用层和引擎层进行优化。

2.2.1 智能查询服务

2.2.1.1 自动降级查询

前文中提到,我们会存在性能响应高于数据规模的面向数据运营用户看数模式(Serving),也有数据规模高于性能响应的灵活分析探查场景(Ad-hoc)。为兼顾这两种查询模式,我们在计算层采用了多种模型和执行降级的策略。

  • 多引擎模型:同一套指标维度可以绑定多种不同引擎类型的模型,比如既可以绑定到 BSP 架构引擎(e.g. Hive 表模型)也可以绑定到 MPP 架构引擎(e.g. OLAP 引擎表模型),以应对不同场景的查询需求。
  • 查询降级策略:如果有多套模型,我们首先会基于查询条件和查询代价选择最优模型进行查询,但如果查询失败或查询未在一定时间内返回,系统会自动降级到次优查询,以应对大数据量耗时久的灵活分析场景,提升查询成功率。降级策略分为以下两大类:

    • 同源降级(模型不变):模型的物理存储不变,切换查询引擎,借助查询引擎的能力进行外表或联邦查询。期间的 SQL 适配和方言改写,由查询服务自动完成。
    • 异构降级(模型改变):平台支持相同指标绑定不同的物理模型,在查询期间,当最优的物理模型未能返回结果,系统可以降级到次优物理模型进行查询。同样,系统将屏蔽不同引擎间的查询细节,自动进行方言改写、函数适配等工作。

2.2.1.2 智能物化

指标平台通过增强指标定义能力,实现了计算逻辑与语义在平台内的统一沉淀。用户可直接基于明细数据进行指标定义,无需依赖数仓复杂加工,但随之而来的是查询海量数据的性能挑战。“智能物化”方案应运而生,该方案充分发挥指标仓库的维度定义与智能路由优势,自动构建应用模型与汇总模型,并完成任务调度与数据回溯。物化后的模型将重新注册至指标仓库,为业务提供高效的指标化消费体验。通过预计算与数据聚合,智能物化大幅提升了查询响应速度。

智能物化主要分为两种实现形式:数据集物化和全局物化,两者的执行时机和目标各有侧重。

(1)数据集物化由用户主动发起,适用于用户定义新数据集并希望加速查询的场景。物化结果直接应用于数仓的应用层,供查询使用。我们提供了两种物化策略:

1.轻度聚合物化:适用于维度指标不固定的灵活分析场景,该模式下我们只物化所选指标依赖的原子指标和维度(包括私有维度),生成轻度聚合模型,物化后的模型保持支持灵活上卷下钻特性。

  • 宽表构建:基于用户选择的指标和维度,扩展物理表生成逻辑宽表。在执行层,通过多表 Join 操作预先固化为宽表,减少查询时的性能消耗。
  • 预聚合:对细粒度数据进行汇总计算,将不同模型的相同维度合并处理,减少数据量,从而满足灵活分析场景的性能需求。
  • 上卷操作:针对常用维度组合,进行预上卷操作,进一步减少数据扫描量,提升查询效率。

2.结果物化:适用于指标维度固定的场景,该模式下我们不再化原子指标,而是直接物化指标的计算结果,减少查询时的计算成本,进一步提升查询效率。

  • 构建 GroupingSets 表:根据用户常用维度组合配置,生成 GroupingSets 的 ETL 代码,通过以空间换时间的方式提升查询性能。

在技术实现上,数据集物化过程主要分为以下几个阶段:

  • 元数据准备:根据用户在数据集中圈选的指标和维度信息,从指标仓库获取指标维度语义及模型路由信息。
  • 智能模型选择:由于指标仓库获取到的是能够支持指标查询的所有模型信息,在这个阶段我们会对每个对模型进行评分,选择最优的查询模型。
  • 变更兼容处理:主要是针对已在线的数据集再次编辑上线的场景,判断在不删除模型的情况下增加新指标维度的物化。
  • 指标智能分组:指标分组是基于一定的规则将指标进行分组的过程,每一个分组在后续会构建一个物化 SQL,生成一个物化模型。
  • SQL 构建:基于每个分组内的指标、维度语义及模型信息,构建 ETL SQL 和物化模型元信息的过程。
  • 执行部署:基于物化 SQL 生成 ETL 任务注册调度,并将模型注册回指标仓库供查询分析使用。

(2)全局物化由系统根据用户查询行为(包括指标、维度、过滤条件等)自动触发。通过指标维度查询热度、关联统计、行为分析(过滤条件、分析方法等)、相似度检测、查询与存储成本分析,系统构建最优数据模型,以最低成本应对可变的查询条件。全局物化的构建结果将自动注册回指标平台,在指标仓库模型选择和查询服务路由中成为候选,和用户绑定模型、数据集物化模型互为补充。 全局物化结果也受数仓管理,物化过程严格遵循数仓规范,可被数仓其它下游复用。

2.2.2 分析引擎探索

2.2.2.1 现状分析

传统的大数据生产服务链路中,由通用引擎(GP)进行数据生产,输出明细和轻度聚合数据;而后导入分析引擎(AP),进行服务层和应用层构建,对接 BI 等各种消费应用。其中,通用引擎和分析引擎,主要区别如下:

  • GP 通常采用 BSP(Bulk Synchronous Parallel)架构进行 Stage/Task 粒度的调度,Stage 结果持久化,数据规模要求高于性能响应,典型的代表是 Spark;
  • AP 通常采用 MPP(Massively Parallel Processing)架构进行 Query 粒度的调度,内存计算/Pipeline 执行,性能响应要求高于数据规模,例如 ClickHouse。

指标平台的计算部分具有以下特性(1)原子指标定义在数仓明细层,上游的复杂指标经过拆解后,查询 SQL 面向海量数据,事实表维表频繁关联(2)查询 SQL 由语义服务自动生成,类似于机器生成代码,逻辑正确但复杂度高、性能差 (3)常用分析语义(同环比、占比等)也由查询服务即时生成,而非传统 BI 中的固化结果,带来了更大的计算量。以上三点对计算引擎的性能和可靠性提出了更高的要求。

通过降级查询和物化策略,我们可以在应用层面部分解决上述问题,将需要快速查询响应的物化在 MPP 引擎上,数据规模大的明细层查询作用在 BSP 引擎上,在保证性能的同时也保留了灵活分析的能力,但依然有以下不足:

  • 系统架构分散,数据链路长,运维成本高、时效差。链路上分为 BSP、MPP 多类型系统,数据需要在多个系统间进行同步,影响成本和时效性,在回刷场景尤其明显。
  • 面对灵活分析场景,仍存在性能瓶颈,并缺乏必要的隔离保护。BSP 架构可以在大查询中限制任务的最大调度单元数量,但受限后往往需要分钟甚至小时级别才能返回结果。MPP 架构虽然可以提供更快的响应时间,但缺乏必要的隔离保护,大查询往往会耗用整个集群的资源,对系统的稳定性造成影响。
  • 资源缺乏弹性机制:业务分析负载具有显著的“潮汐效应”,即查询并发量在日、周、月等不同时间周期内呈现显著的波峰波谷。当前架构(尤其是 MPP),资源必须按照峰值需求进行配置,且业务集群之间相互隔离。上述因素带来了高昂的成本和资源的浪费。

近年来,随着关键技术(Native runtime,向量化执行,Delta Table 格式等)发展和存算分离、湖仓一体等概念的引入,两种引擎都有了飞速的进步。BSP 侧通过 Native runtime 和向量化执行,缓存优化,在小数据量和单点查询上性能大幅提升,直接对接数据消费应用层成为了可能;MPP 侧通过存算分离、CBO 改进,在保证性能的同时,数据规模/查询复杂度支持加强,逐渐向生产侧下移。两种架构的界限变得模糊了许多,在这种趋势下,出现了云原生、存算分离、单一引擎(SingleEngine)的架构路线,其中最典型的是国外的 Snowflake;国内也涌现出一些成熟的供应商,其中我们对云器科技的 Lakehouse 进行了深入的调研和合作。

2.2.2.2 Lakehouse

云器 Lakehouse 是由云器科技自主研发的新一代云湖仓。使用增量计算的数据计算引擎,性能可以提升至传统 BSP、MPP 开源架构的数倍,实现了海量数据的全链路-低成本-实时化处理,也为诸如 AI 创新提供了支持全类型的数据存储、计算平台。云器 LH 通过引入统一计算引擎,扩展弹性支持,存储优化,多重调度模式,向量化执行等几个方面,对传统的计算引擎在性能、成本、可靠性上进行了大幅提升,主要包含:

  • 通用增量计算引擎:云器 LH 通过通用增量计算技术(Generic incremental Computing,GIC),实现了对多种计算形态的统一。计算模式上,GIC 面向通用场景,通过一套增量计算逻辑,统一当前的流、批、交互三种模式。系统架构上,从 Lambda 进化为 Kappa 架构,提供面向数据新鲜度、查询性能和资源成本三方面的多种平衡点。
  • 资源弹性伸缩能力:云器 LH 通过 VirtualCluster 实现横向和纵向双维度弹性。横向扩展根据 QPS 动态调整实例数量,支持 0 到 100+实例的秒级伸缩;纵向扩展根据查询复杂度调整单实例规格,从 2 CORE 到 64 CORE 灵活配置。两者相结合,对前文提到的查询潮汐效应,提供了平衡性能和成本的解决方案。
  • 向量化执行:执行引擎使用 C++开发,并利用 SIMD 指令集进行批量运算,配合列式存储减少 I/O 开销,提升 CPU 利用率。这些优化在处理大规模聚合和多表 JOIN 时效果显著,符合指标平台进行指标多维度查询时的典型特征。
  • 存储层优化:LH 内表存储采用 Parquet 格式配合 ZSTD 压缩,压缩比达 10:1。构建三级缓存(内存、SSD、对象存储)体系,缓存命中率超过 95%。这些优化对于处理时序数据和维表关联特别有效。
  • 双模式执行:系统提供 BSP/DAG 和 MPP/Pipeline 两种执行模式。BSP 模式用于 ETL 和批处理,支持作业级 Failover,吞吐优先;MPP 模式用于交互查询,通过 Pipeline 流式处理降低延迟,支持算子级并行和并行度自动调整。

2.2.2.3 系统集成

美团数据生产消费具有海量数据(PB 级),查询量大(日百万级),实时性强(分钟级),稳定性要求高,安全合规严等高准入门槛,因此在接入云器 LH 作为计算引擎的过程中,既要能够验证生产环境下的性能收益,也要保障不影响线上查询和其他系统稳定性。我们设计了流量回放、线上双跑、灰度放量等多个接入阶段,在保障功能兼容、结果准确、线上稳定的同时,对性能和成本指标进行评估。

当前云器 LH 已经在美团两个数据中心进行了集群的部署。对接现有 BI 生态的系统方案,主要由以下设计考量/取舍:

  • 嵌入式架构:云器 LH 采用引擎嵌入方式部署到美团生产、消费集群,遵循现有存储、计算、服务层已有标准和协议,进行必要的适配
  • 异步查询:指标平台通过异步接口提交到云器 LH,通过提交、状态通知、拉取数据 3 个阶段完成整个异步查询的操作,与当前系统的查询方案一致
  • 语法兼容:通过流量回放识别不兼容语法和函数,对于业务 Spark UDAF/UDF 天然支持无需改造,对于其他 MPP 引擎少量 C++ UDAF/UDF 通过开发进行适配
  • 安全对接:云器遵循美团 Kerberos(KDC 认证)对接,接入数据账号和授权体系,在访问元数据(HMS)及数据(HDFS)对接时均采用授权认证方式。指标平台在 API 层对指标、维度、维值等进行鉴权,与当前系统鉴权方案保持一致。
  • 数据存储:复用既有 HDFS 作为主存储,云器 LH 通过外表方式读写已有数据表,无需数据导入。使用对象存储作为结果存储,与现有 MPP 系统查询结果获取方案一致,提高指标平台拉取结果的性能和稳定性。

3 业务实践

美团指标平台经过几年的建设和应用,当前承接公司百余个业务线,其中模型规模达万量级,指标维度规模达十万量级。对应的 BI 应用,日查询量达百万级别,第三方应用日 API 调用量千万级别。查询成功率超过 99.9%,灵活探索场景查询时长 90 分位控制在分钟级别,运营监控场景查询时长 90 分位达到秒级别。

在云器 LH 的探索和实践上,为了确保线上稳定性和准确性,我们采取线上双跑和线下压测两种方式进行实验和评测。线上双跑,指在生产环境中对任意一次物理查询分别对不同引擎发起一次查询,异步对返回数据进行正确性校对并记录性能数据;线下压测,我们使用生产环境中大流量报表的真实流量进行回放,采用递增 QPS 方式测试系统极限性能并记录各阶梯压力下的性能指标。

在灵活探索(Ad-hoc)场景,我们采用线上双跑方式进行评测,灰度了部分时间内某业务线下的全部指标平台查询流量,涉及 84 张表,1000+TB 数据。对比组采用流行开源引擎 Trino 和云器 Lakehouse。Trino 采用 MPP 部署架构,千核集群;云器 LH 采用同配置(CPU 核数、内存、网络带宽)的 AP 模式,最大 VC 副本量设为 3。云器 LH 比 Trino 集群有 2 倍的性能提升,其中具体的查询百分位数据如下(单位毫秒):

在运营看数(Serving)场景,我们采用线下压测云器 LH 方式进行评测,回放某大流量业务报表单工作日全部查询流量,涉及 20 张物化加速表,0.79T 数据。压测三轮,QPS 从 40 开始递增至 80 结束(线上实际 QPS 小于 10),每阶段持续 5 分钟,云器 LH 性能指标在各种压力下表现平稳,展现了优秀的弹性和资源隔离能力。具体数据(单位毫秒)如下:

4 未来展望

美团 BI 和指标平台的下一步发展,将继续在自动语义和增强计算两部分演进,并发展智能化能力。

  • 在自动语义层面,我们计划根据业务的实际需求,增强标准数据(指标维度平台)和非标数据(传统 SQL 数据集)的联合查询能力和相互转换能力,并在配置化的基础之上,增加函数表达、开放算子接口等功能,支持更加复杂、个性化的语义配置、路由选表、语义生产能力。
  • 在增强计算层面,放量新版本计算引擎灰度场景,获取更大性能成本收益,在架构上将当前服务层中部分缓存、降级、物化、查询优化能力下沉到引擎层,使查询服务更适配计算引擎的发展趋势。
  • 在智能化层面,指标平台相对于传统 Text2SQL 方式具有天然优势:可以使用已沉淀的指标维度业务和技术信息,避免二义性提高准确率,并能够复用原有鉴权体系,保障数据安全。

美团 BI 工具结合指标平台能力,已经孵化了自然语言数据助手、仪表板分析板助手等智能化产品,下一步将扩大业务场景范围,在数据准备配置、自然语言取数、分析辅助和自动报告生产上进一步提升产品能力,帮助业务持续提升运营效率。

作为观测云用户,在日常使用过程中,当您有长期归档日志、审计数据以满足合规留存要求、需要将观测云数据同步至其他系统进行二次加工分析,或是希望实现指标、链路等实时数据的多系统订阅与联动时,就可以用到观测云的数据转发功能。

在实际使用中,您可以结合观测云数据热存分析与长期存档的核心场景选择数据转发:

  • 日常需对观测云内的热数据(如近期 7 天内的日志、链路数据)进行实时分析、快速查询时,可依托观测云原生存储能力完成热存分析;
  • 当热数据超过分析周期,需要长期存档以满足合规要求,或需留存历史数据用于后续追溯、复盘时,就需要通过数据转发功能将数据同步至对象存储,此时可在观测云默认对象存储与公有云自有对象存储中选择适配方案。

本文结合观测云 SaaS 平台特点,帮您梳理数据转发核心最佳实践,聚焦实用配置与落地步骤,助力您快速落地需求、规避误区。

转发目标选型与适用场景

观测云主要支持多种云平台的对象存储(包括阿里云 OSS,AWS S3,华为云 OBS,火山云 TOS 等)与 Kafka 两种转发目标,二者适配不同业务场景。如果使用观测云 SaaS 平台,观测云平台底座部署在公有云(如阿里云、腾讯云、华为云等),选型时可以优先选择与观测云 SaaS 同厂商、同区域的目标服务,或通过虚拟网络打通连接,最大限度降低网络延迟、减少公网带宽消耗,提升数据传输安全性。

目标类型适用场景观测云适配建议
对象存储(OSS/S3/OBS/TOS)日志、审计、事件的长期归档、低成本冷备,以及需满足合规留存要求的场景优先选择观测云 SaaS 部署所在厂商、同区域资源,或通过VPC打通内网连接
Kafka指标、链路、实时事件的实时流处理、多系统订阅、数据二次加工,以及告警联动场景优先选用观测云 SaaS 所在厂商的托管Kafka,同区域部署,通过虚拟互联网打通内网访问

具体配置可以参考:

规则配置最佳实践

规则配置是数据转发的核心,需遵循“分类配置、精准过滤、适配观测云 SaaS 特性”原则,聚焦观测云侧操作,结合高频场景落地步骤,简化冗余配置,确保高效可控。

一、通用配置规范和考虑点

1、按数据类型拆分规则:登录观测云控制台,进入【管理】-【数据转发】页面,点击【新建规则】,每次仅选择一种数据类型(日志/链路/RUM/事件/审计事件等),单独创建规则,避免数据混杂。

2、精准过滤配置:在“过滤条件”模块,可通过数据所带的标签,例如日志 source、host、service 等标签筛选,仅转发有用数据,从而避免无效的数据增加转发流量和存储成本。

图片

3、需要注意的是,如果需要使用观测云的 Pipeline 解析数据,同时将解析后的字段进行转发,可以使用观测云的中心 Pipeline 脚本:在创建 Pipeline 脚本时,可勾选“启用 Pipeline 处理转发数据”:勾选后,数据先经脚本处理再过滤转存;不勾选则直接转发原始数据。

图片

二、对象存储转发配置

对象存储选型对比(观测云默认对象存储 vs 公有云自有对象存储):

  • 观测云默认对象存储是平台自带的存储资源,无需您额外创建和管理,默认存储时长可配置为 180 天、360 天或 720 天,能满足多数合规留存需求。
  • 您也可以选择您在公有云的自有对象存储(如阿里云 OSS、华为云 OBS 等),从而可以实现数据的自主管控;选择对象存储的时候,可优先选择与观测云 SaaS 同厂商、同区域的公有云自有对象存储,节省流量传输成本。

具体配置方式:

1、新建规则选择对象存储的类型,如果选择了自己云平台的对象存储(如阿里云 OSS),填写云平台和存储桶等相关信息。具体配置方式可以参考在线文档:https://docs.guance.com/management/backup/start-backup/

需要注意的是权限控制:

  • 云平台密钥安全管控,配置对象存储,需输入对应云平台 AK/SK 信息,请严格遵循最小权限原则,仅为观测云分配需要的权限,禁止授予全权限,避免密钥泄露导致的数据篡改、泄露风险,密钥需由专人保管,定期更换
  • 操作权限管控,观测云支持工作空间角色精细化权限分配,在【工作空间】-【权限管理】中,仅为需要操作数据转发的专属人员,分配“数据转发”相关操作权限(如规则创建、编辑、启用/禁用),普通用户仅授予查看权限,杜绝误操作(如误删规则、误改配置)

2、路径与优化:仅需在“存储路径”中输入自定义前缀(如guance-log-backup/),系统自动按“工作空间/数据类型/规则名/年月日时”生成完整路径,方便您在对象存储桶中后续的调用和查看。

3、可以点击“测试连接”进行配置的验证测试

图片

三、Kafka转发配置

1、基础配置:新建规则选择“Kafka 消息队列”

2、输入相关信息:

  • 地址:Host:Port,多个节点使用逗号间隔;
  • 消息主题:即 Topic 名称;
  • 安全协议:在 Kafka 侧,SASL 可以使用 PLAINTEXT 或者 SSL 协议作为传输层,相对应的就是使用 SASL_PLAINTEXT 或者 SASL_SSL 安全协议。如果使用 SASL_SSL 安全协议,必须配置 SSL 证书;

3、点击“测试连接”,若上述信息满足规范,则提示测试连接成功。点击确定即可保存当前规则。

图片

总结

观测云数据转发是“精准选型、精细配置、成本可控、权限安全”,结合其 SaaS 特性,优先选择同厂商同区域转发目标,或打通虚拟互联网连接,按数据类型拆分规则并精准过滤,同时做好权限管控,即可快速落地数据转发、存档和二次分析的需求,发挥数据价值,支撑企业合规留存与业务优化。

引言

物理世界的信息由图像、声音、文字交织而成。今天的大模型,本质上仍然是以语言为中心的建模系统,语言作为人类智慧符号化表述,在”压缩即智能”的范式下表现出强大的能力。但通往真正的物理世界智能,也许语言并不是世界的边界。视觉、语音与文本等多模态信号,实际上是对现实物理对象的不同侧面投影。

这就引出一个根本问题:能否让 AI 像处理语言一样,用同一种方式简洁有效地处理物理世界的多种信息? 如果能,那么物理世界的AI就有了统一的”母语”,Token 不再局限于文本,而是成为描述一切物理信号的原生表示。对这些信号进行统一建模与压缩,可能使模型学到更加本质的表示,并实现更深层的模态内化。

LongCat 团队经过研究发现:在统一的建模框架与优化目标下,可以构造一种语义完备的离散表示。我们将图像、语音与文本统一映射为同源的离散 Token,使模型从学习连续空间的映射,转向学习离散 ID 之间的关系结构,并通过纯粹的下一个 Token 预测(Next Token Prediction, NTP)范式,以一种统一的、优雅的方式建模各种物理信号。

LongCat-Next 是我们在通往物理世界 AI 道路上的一次探索。今天,我们把研究思路的核心——LongCat-Next 模型和它的离散分词器全部开源,希望更多开发者能基于它,构建真正能感知、理解并作用于真实世界的AI。

我们如何构造物理世界的“母语”?

接下来,我们将逐一拆解三项核心技术,看看我们是如何让 AI 真正拥有物理世界的“母语”。

1.1 离散原生自回归架构 DiNA:简洁统一

业界主流的多模态大模型长期受制于“语言基座+外挂视觉/语音模块”的拼凑式架构,非语言模态往往只作为辅助组件存在。这种设计带来很多结构性问题,比如图像理解与生成在结构与优化上长期割裂:前者依赖对齐机制,后者依赖扩散等独立模型,多模态信息始终停留在”被投影”,而非“被内化”。

为此,我们构建了 DiNA(Discrete Native Autoregressive)离散原生自回归架构。其核心非常简单:

将所有模态统一为离散 Token,并用同一个自回归模型进行建模。

它将物理世界广泛存在的多模态信号收敛为同源的离散特征,实现了视觉、语音、文本多模态的底层建模统一。作为整个大语言模型体系的自然扩展,DiNA 彻底打破了模态间的隔阂。它通过极简的下一 Token 预测(NTP)范式,将图像、声音和文字统一转化为同源的离散 Token。在这套原生的统一架构下,视觉的“看”与“画”、听觉的“听”与“说”,不再是拼接的异构模块,而是同一套预测逻辑的自然涌现。

简单而言:我们把文字、图像、语音都变成同一种东西——离散 Token。无论读文字、看图片还是听声音,对AI来说都是同一件事:预测下一个 Token 是什么。

这个设计带来 3 个根本性改变:

  • 架构极简:所有模态共享同一个自回归骨干,这意味着,无论输入的是文字、图像还是音频,模型都用同一套参数、同一个注意力机制、同一个损失函数。这种统一设计,让模型在训练时更稳定,部署时更轻量。我们用 LongCat-Flash-Lite MoE(68.5B 总参数,3B 激活参数)作为基座,在这个框架基础上训练了 LongCat-Next。实验表明,DiNA 的 MoE 路由在训练中逐渐出现模态专精化,激活专家数量相比纯语言设置有所增加,模型正在用更大容量支撑能力扩展。

图1:LongCat-Next 架构概览,该架构基于 DiNA 范式设计

  • 理解与生成对称:LongCat-Next 用同一个自回归模型同时实现了视觉理解和生成,通过这样解决了长期困扰的理解生成架构和优化不一致问题,在统一 Token 空间中,理解与生成被统一为同一数学问题,两者本质上都是条件下的 Token 预测:

图像 → 文本:理解

文本 → 图像:生成

给定图像 Token 预测文字 Token 是“理解”,给定文字 Token 预测图像 Token 是“生成”——数学形式完全一致,从此不再割裂。实验证明,这种对称设计在优化上消弭了冲突:统一模型的理解损失仅比纯理解模型高 0.006,而生成损失比纯生成模型低 0.02。理解没有损害生成,反而表现出协同潜力

图2:DiNA 框架下的视觉理解与生成交互

  • 模态内化:在离散原生训练范式下,不同模态被统一编码为 Token,并以相同方式建模。我们观察到:

    • 不同模态的 Token 表征在表示空间中自然融合(t-SNE 可视化)
    • MoE 专家自发形成模态偏好分化

这表明模型并非在“对齐模态”,而是在内部形成统一的多模态表征结构。

图3:(a) MoE 专家模型在 DiNA 训练下表现出模态分化;(b) LongCat-Next 的表征空间体现出更融合内化的模态间关系

1.2 离散原生分辨率视觉分词器 dNaViT:构造“视觉单词”

如果说 DiNA 解决的是“如何统一建模”,那么 dNaViT 解决的是:

如何让图像本身能够被离散化为可建模的 Token。

LongCat 团队首创的 dNaViT 技术相当于语言模型中的 tokenizer(分词器)——就像把句子拆成单词,它把一张图拆解成一系列有意义的“视觉词汇”。

  • 原生任意分辨率支持(Native Resolution for Understanding and Generation):不做缩放、不裁剪、不填充,每一处细节都完整保留。通过我们精心设计的训练策略,dNaViT 实现了任意分辨率的图像编码与解码——在文档解析(OCR)、复杂图表推理等对细节敏感的任务中具备优势,如在 OmniDocBench、OCRBench 等密集文本场景的测试中均表现优异。

  • 8层残差向量量化(Residual Vector Quantization, RVQ):细节多了怎么办?分层打包。类比于第一层打包轮廓,第二层打包颜色,第三层打包纹理……8层级联递归拟合”残差中的残差”,可以实现高达 28 倍极致像素空间压缩。解码时,DepthTransformer 将多级 Token 合并重建,让压缩与还原高效协同。

  • 解耦的双轨生成解码器(Dual-Path Detokenization):离散 token 还原图像时,先由”结构像素解码器”保住布局,再由”扩散像素细化器”注入纹理细节。解耦设计降低生成方差,确保文本渲染无损清晰。

更妙的是,这套”视觉词汇”实现了 image → token → image 的完整回环——像语言 tokenizer 一样,既用于”看懂”图像,也用于”画出”图像。理解时学到的对应关系,生成时正好反过来用——图像描述和图像生成在同一套 token 序列中闭环流转。

更关键的是,在 LongCat-Next 中:

视觉 Token 完成的是图像到离散 ID 的映射,真正的特征是原生学习的。

真正的视觉表征,是在语言模型内部通过 Embedding 学习得到的。这意味着模型不是”接入视觉能力”,而是在内部学习并形成自己的视觉语言。

这种从“借用模态”到“内生模态”的转变,是原生多模态建模的核心

图4:离散原生分辨率视觉 Transformer(dNaViT)设计概览

图5:LongCat-Next 的理解与生成案例

1.3 语义对齐完备编码器:破解“离散化必然损失信息”的难题

离散建模通常被认为受限于两方面:表征容量与离散化损失。然而,我们进一步分析发现,真正决定上限的关键在于:

离散 Token 本身是否具备语义完备性(Semantic Completeness)。

也就是说,问题不在于”是否离散”,而在于离散后的表示,是否能够同时承载高层语义与细粒度信息(如颜色、纹理与空间结构),从而支撑统一的理解与生成。

基于这一视角,我们提出:实现语义完备离散表示的关键,在于构建合适的表征基础。其中,一类重要的候选范式是 SAE(Semantic-and-Aligned Encoder)。不同于以对比学习为主的模型(如 SigLIP),SAE 通过大规模视觉-语言监督(涵盖图像描述、视觉问答乃至视觉推理等任务),学习高信息密度、多属性的表征。这类表征不仅具备丰富的语义结构,同时我们发现在网络的残差传递机制下,底层视觉细节能够持续向高层传播,从而在抽象语义中保留细粒度信息,为离散 Token 的语义完备性提供基础。

在此之上,离散化过程本身仍需尽可能减少信息损失。为此,我们采用多级残差向量量化(Residual Vector Quantization, RVQ)机制,对表征进行逐级离散建模:通过层级化拟合”残差中的残差”,在有限离散空间内逼近高维连续表示,从而在压缩率与信息保真之间取得平衡。

最终得到的离散视觉 Token,不仅能够支撑细粒度理解任务(例如在密集文本识别中优于连续表征模型),同时也具备高保真的图像重建能力。这表明:

离散表示并非信息的退化形式,而可以成为统一理解与生成的完备表达载体。

图6:dNaViT 的分词器与解分词器训练流程

实证与洞察

LongCat-Next 在视觉理解、图像生成、音频、智能体等多个维度上,以一套离散原生框架展现出与多模专用模型相当甚至领先的性能。

更重要的是,这些成绩验证了三个关键发现:

图7:LongCat-Next 的基准测试性能

发现一:离散视觉没有天花板

行业长期认为,离散模型在细粒度文本识别上必然不如连续模型,这也是一直阻碍业界使用离散建模作为选项的原因。值得一提的是,经过我们 dNaViT 的设计以及 DiNA 的建模框架,LongCat-Next 表现出了非凡的细粒度感知能力和高质量的视觉推理能力。

LongCat-Next 在 OmniDocBench(学术论文、财报、行政表格)上的表现(0.152 / 0.226)挑战了这一刻板印象——不仅超越 Qwen3-Omni,还超过了专用视觉模型 Qwen3-VL。离散化不是细粒度感知的天花板,关键在于如何构建语义完备的离散视觉表征。

发现二:理解与生成可以协同

传统观点认为,一个模型很难同时做好理解和生成。但我们发现:消融实验对比中,LongCat-Next 统一模型的理解损失仅比纯理解模型高 0.006,而生成损失比纯生成模型低 0.02。在图像生成上,LongCat-Next 在 LongText-Bench(英文 93.15);在图像理解上,MathVista(83.1)达到领先水平,成为一个具备工业级潜力的理解生成统一方案。理解没有损害生成,反而表现出协同潜力。

发现三:统一框架不折损语言能力,在智能体与音频交互上形成跨模态协同

在纯文本任务上,LongCat-Next 的 MMLU-Pro(77.02)和 C-Eval(86.80)表现领先,证明原生多模态训练未削弱语言核心能力。在工具调用上,τ²-Bench 零售场景(73.68)大幅领先 Qwen3-Next-80B-A3B-Instruct(57.3);在代码能力上,SWE-Bench(43.0)显著超越同类模型。

在音频领域,这一框架同样展现出良好的通用性。TTS 任务上,SeedTTS 的中文和英文 WER 分别低至 1.90 和 1.89;音频理解上,MMAU(76.40)、TUT2017(43.09)均达到先进水平。更重要的是,模型支持低延迟的并行文本语音生成与可定制的语音克隆,让语音交互更自然、更个性化。

当模型学会用同一种方式理解图像、声音和文字,它在理解世界时变得更聪明了——无论是看懂图表、听懂语音,甚至是调用工具、编写代码

更多样例

Case 1:视觉理解

Analyze this image. Context: Gen = Generation; Und = Understanding. ‘Scaled’ represents a fair 1:1 token comparison. Is there any evidence that Understanding helps Generation?

Yes, there is evidence that "Understanding" (Unified) helps "Generation" (Pure-Gen.), particularly in the context of token efficiency and image loss reduction.
Let's break this down:
1. Main Graph: Image Loss vs. TokensThe x-axis is Tokens (from 0B to 100B), and the y-axis is Image Loss (lower is better).Three curves are shown:Pure-Gen. (blue): Pure generation model.Unified (orange): Unified model (combines understanding and generation).Unified (unscaled) (light orange): Same as Unified, but scaled for fair token comparison.Key Observations:At low token counts (e.g., 0–20B tokens), all models start with high image loss, but Unified (orange) starts slightly lower than Pure-Gen. (blue), suggesting a small advantage.As tokens increase, Unified (orange) consistently achieves lower image loss than Pure-Gen. (blue), especially after ~40B tokens.The Unified (unscaled) curve (light orange) is very close to the Unified curve, indicating that scaling doesn’t change the relative performance — it’s just a fair comparison.✅ Conclusion: The Unified model (which includes understanding) performs better than Pure-Gen. across most token ranges, meaning understanding helps generation.
2. Inset Graph: Zoomed-in View (40B–50B Tokens)This shows a close-up of the region where the curves diverge slightly.The difference (Δ = 0.0213) is explicitly marked between Pure-Gen. and Unified at ~48B tokens.The Unified curve is below Pure-Gen., meaning lower image loss — better performance.✅ This quantifies the benefit: Understanding provides a measurable improvement in image quality (lower loss) at higher token counts.
3. Interpretation: What Does "Understanding" Mean Here?The term "Unified" likely refers to a model that jointly learns understanding (e.g., semantic or structural comprehension) and generation. In contrast, "Pure-Gen." is a model trained only on generation tasks.
So, when the Unified model outperforms Pure-Gen., it suggests that incorporating understanding during training leads to better generative performance — possibly by enabling more informed, context-aware generation.
✅ Final Answer:Yes, there is clear evidence that Understanding helps Generation.The Unified model (which includes understanding) consistently achieves lower image loss than the Pure-Gen. model across token counts, with a quantified improvement of Δ = 0.0213 in the inset graph. This indicates that integrating understanding into the model improves its generative performance, especially as token count increases.

Case 2:视觉生成

Case 3:音频问答与语音合成

请查阅原文

LongCat-Next 现已开源

作为一个初步的尝试,我们展示了一个有意义的视角:物理世界的信息可以被离散化、统一化、像语言一样被建模,让 AI 第一次能够像处理文字一样原生地理解物理世界的多模态信号。

今天,我们把这个探索研究的过程及产物——LongCat-Next 模型和 dNaViT 分词器全部开源。

🚀 开源平台链接

💻 更多体验前往:

结语

我们也期待,有一天 AI 能真正看懂真实世界的每一个角落、听懂顾客的每一句话、理解物理世界的每一条规律。

而我们今天开源的 LongCat-Next,以小尺寸验证了原生离散架构的潜力,是这条路上的一块重要的基石。我们也知道,还有非常多重要的方向尚未被充分探索——但这恰恰是未来研究的机遇。我们诚挚欢迎社区同仁的深入讨论与合作,一同推动原生多模态智能走向更远

智能体AI浪潮奔涌,全球算力集群正加速向AI云原生时代跃迁,升级算力底座成为行业破局关键。开源作为创新协同的重要范式,汇聚产业智慧、缩短研发周期、催化更多创新成果落地。

openFuyao首个LTS版本凝聚了社区全体成员单位与开发者共建的核心技术成果,面向AI推理等高并发、高负载场景,打造高性能、高安全、高可靠的企业级AI云原生平台,促进有效算力的极致释放。

此次直播,邀请两位社区大咖技术委员会主席胡昊&架构师姚晓忠带你快速了解openFuyao,解读LTS版本核心能力及技术特性的关键价值。

接下来,openFuyao将在官方视频号持续进行版本解读、关键特性深度解析、社区技术Panel、商业化落地案例分享等直播,欢迎大家关注社区动态,不错过每一期技术干货。

开发者朋友们大家好:

这里是 「RTE 开发者日报」,每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE(Real-Time Engagement) 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」,但内容仅代表编辑的个人观点,欢迎大家留言、跟帖、讨论。

本期编辑:@koki、@鲍勃

01 有话题的技术

1、Hand2World:基于 3D 手部结构与射线嵌入,实现首个闭环交互式第一人称世界模型

南洋理工大学(NTU)MMLab 团队发布 Hand2World,这是首个支持自由手势驱动的第一人称交互世界模型。该模型允许用户通过空中手势实时操控虚拟场景并生成连续视频,解决了传统世界模型在主动物理交互及相机运动解耦方面的技术瓶颈

  • 3D 手部结构化控制信号:放弃传统的 2D Mask 方案,采用 3D 手部 mesh(MANO 模型)渲染的「填充轮廓 + 线框叠层」复合信号。该设计实现了遮挡无关的条件输入,解决了推理时完整手势与训练时残缺手部(受物体遮挡)之间的分布错配。
  • Plücker 射线嵌入解耦相机运动:引入逐像素的 Plücker 射线(Plücker Ray Embedding)显式编码相机运动,通过轻量级 adapter 注入扩散模型。该技术将手部关节运动与头部自运动(ego-motion)彻底解耦,使 FVD 指标从 815 优化至 218,有效抑制背景漂移。
  • 因果自回归蒸馏实现 8.9 FPS 交互:将双向扩散教师模型蒸馏为支持 KV cache 的因果自回归生成器。在 A100 平台上可实现 8.9 FPS 的流式输出,支持用户边看边调的闭环持续交互。
  • 全自动单目标注流水线:开发了一套无需多目相机或人工干预的自动化标注系统,可直接从普通单目视频中提取 3D 手部位姿与相机轨迹。相比 PlayerOne 等依赖同步采集的方案,显著提升了具身智能训练数据的可扩展性。
  • 多项 SOTA 性能指标:在 ARCTIC、HOT3D、HOI4D 三个标准数据集上均取得最优结果。在 ARCTIC 测试中,相机轨迹误差降低 42%,深度一致性(Depth-ERR)从 22.51 降至 16.14。

(@新智元)

2、Snap 联合高通研发新款 Spectacles:搭载 Snapdragon XR 平台,支持端侧 AI 交互

Snap 旗下 AR 硬件子公司 Specs 与高通(Qualcomm)达成多年战略合作伙伴关系,确定下一代 Spectacles 智能眼镜将采用 Snapdragon XR 芯片平台。此次合作旨在通过底层算力升级,在今年年内推出具备端侧 AI 处理能力的消费级可穿戴设备

  • Snapdragon XR 平台架构集成:新款 Spectacles 将搭载高通专为 AR/VR 设备设计的 Snapdragon XR 系列片上系统(SoC),用于处理高复杂的空间计算与图形渲染任务。
  • 端侧 AI(On-device AI)处理能力:双方合作重点在于实现人工智能在硬件本体的实时运行,以降低交互延迟,并增强在离线状态下的多模态感知与语义理解能力
  • 高级多人数字体验支持:利用高通的通信与计算协同技术,开发支持多名用户在同一物理空间内实时交互的增强现实应用。
  • 从开发者生态向消费端过渡:自 2024 年转向「仅限开发者」策略后,Specs 计划通过此次硬件升级,将积攒的开发者插件与应用库正式推向消费市场

( @TechCrunch)

02 有亮点的产品

1、Mizzen Insight 完成近千万美元天使轮+融资,4 个月从 0 到 300+客户

AI 用户研究平台 Mizzen Insight 已完成天使+轮融资,融资金额近千万美元,由红杉中国种子基金领投,达晨创投、嘉程资本跟投,种子轮老股东 Creekstone 继续加码。本轮融资将主要用于模型能力优化、产品迭代及市场拓展。

  • 全链路 Agent 自动化闭环:系统支持从输入调研目标开始,自动生成访谈提纲、筛选受访者、实时主持访谈并输出可视化结构化报告,实现调研全流程脱离人工干预。
  • 语义级实时动态追问:访谈模型具备深度语义理解能力,能基于受访者的实时回答进行动态逻辑追问,而非执行固定脚本,模拟专业研究员的深访交互。
  • 大规模定性研究吞吐量:上线 4 个月累计完成访谈逾 1 万小时,参与人数近 2 万人,验证了 AI 在高频、大规模并发访谈场景下的可扩展性。
  • 基于人类偏好建模的技术栈:创始人孙克强博士背景涵盖清华及港中文 MMLab,专注人机交互与人类偏好建模,相关技术 Benchmark 此前已被 Google、DeepMind 等机构采纳。

( @Z Potentials)

2、AI 潮玩品牌 MOMOTOY 获数千万元融资:自研五大 AI 技术体系,支持端云协同与本地化数据处理

AI 潮玩品牌 MOMOTOY 完成数千万元融资(投后估值 2.5 亿元),由翼朴基金投资。该公司将 AI 技术与高奢材质(如 999 足金)引入潮玩硬件,试图通过自研情感计算模型实现从静态摆件向具身智能终端的转型。

  • 五大 AI 核心技术体系: 构建以记忆分级、动态情绪、心理分析、端云协同、深度情感理解为核心的技术栈。支持双向对话、多语种实时交流及声音克隆,能够根据用户交互历史实现渐进式记忆增长。
  • 端云协同与隐私安全架构: 建立个人数据空间,支持信息分级管理。关键交互数据直连本地智能体(agent),无需强制上传云端,通过端侧加密保护用户隐私。
  • 全场景智能联动能力: 软件接口已打通车载系统与智能家居系统,实现「人-车-家」全生态场景的智能体接入,使潮玩具备跨终端的交互连续性。

(@36 氪未来消费)

03 Real-Time AI Demo

1、Vibe Ring 实现 Switch 健身环语音输入:挤压健身环 = 长按 Fn

来自 X 上的开发者 @wong2_ _:

沉迷 Vibe Coding 却疏于锻炼?快来试试 Vibe Ring!

把落灰的 Switch 健身环和 Mac 按键映射:

  1. 挤压健身环 = 长按 Fn 语音输入
  2. 向外拉健身环 = 回车发送

GitHub 链接:

https://github.com/wong2/vibe-ring/blob/main/README_CN.md

04 有态度的观点

1、别只敲键盘了!吴恩达最新研判:语音 AI 正引爆下一场交互革命

近日,人工智能先驱吴恩达(Andrew Ng)撰文指出,大众严重低估了语音用户界面(Voice UI)即将带来的颠覆性影响。他预言,语音交互将成为继「鼠标点击」和「屏幕触控」之后的下一次重大 UI 变革。

回顾科技史,每一次交互方式的跃迁都会催生出庞大的全新应用生态。吴恩达强调,读写是需要系统学习的技能,而「听和说」则是人类与生俱来的本能。由于开发者群体普遍具备较高的读写能力,人们很容易忽视「打字操作」对许多普通用户而言仍是一种摩擦力。随着语音识别准确率的飙升,语音 UI 将彻底打破这一门槛,让科幻电影中「对着计算机直接下达指令」的愿景成为现实。

过去,语音 AI 常常面临一个死结:要低延迟(反应快)就容易显得「智商低」,要高智能(经过大模型深思熟虑)就必然带来高延迟。对此,吴恩达分享了目前行业前沿的解法——「双智能体自定义架构」。即通过前台智能体(Foreground Agent)与用户保持低延迟的实时语音拉扯,同时让后台智能体(Background Agent)默默处理复杂的逻辑推理、工具调用和安全护栏。这种协同作战,完美兼顾了沟通的流畅度与 AI 的聪明才智。

吴恩达明确表示,语音并不会消灭键盘和鼠标,而是最强力的补充。纯语音交互存在局限,但「视觉+语音」的多模态结合将带来颠覆性体验。系统可以在听取用户指令的同时,实时动态更新屏幕上的画面和动画,形成视觉与听觉的双重闭环。

如今,构建语音 UI 的门槛已大幅降低。吴恩达透露,借助 AI 编程工具,他仅用不到一小时就为一款普通的数学应用加上了语音交互层。在全球范围内,真正下场开发语音应用的开发者仍是凤毛麟角。

正如吴恩达在信末的呼吁:这片蕴含着巨大创新的处女地已经敞开。在这个 AI 爆发的时代,是时候给你的应用装上「声带」,让它和世界真正对话了!

(@Deeplearning AI)

阅读更多 Voice Agent 学习笔记:了解最懂 AI 语音的头脑都在思考什么

写在最后:

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创,感兴趣的朋友请通过开发者社区或公众号留言联系,记得报暗号「共创」。

对于任何反馈(包括但不限于内容上、形式上)我们不胜感激、并有小惊喜回馈,例如你希望从日报中看到哪些内容;自己推荐的信源、项目、话题、活动等;或者列举几个你喜欢看、平时常看的内容渠道;内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点,仅供参考

引言

现如今的大语言模型已经能流畅地写文章、写代码,甚至执行复杂的 Agent 工作流,然而,它们在面对严谨的数学定理证明时,却往往显得力不从心。

在常规的数学解题中,模型只需要“答对最终数值”即可,但数学定理证明不同,它要求极度严苛的逻辑链条,任何一句自然语言的模棱两可,都可能导致整个证明的崩塌。那么,如何让 AI 从“猜答案”走向“严谨证明”,成为复杂推理具有挑战的课题。

为了解答这个问题,我们开源了专门用于数学形式化与定理证明的模型 —— LongCat-Flash-Prover

LongCat-Flash-Prover 在解决定理证明和形式化任务时,将形式化推理拆解为自动形式化(Auto-Formalization)、草稿生成(Sketching)和证明生成(Proving)三大原子能力。在结合工具集成推理(Tool-Integrated Reasoning,TIR)策略下,仅用 72 次推理预算,MiniF2F-Test 通过率就达到 97.1%,在已知开源 Prover 模型中刷新 SOTA;在超难竞赛级任务上,MathOlympiad-Bench 达 46.7%(180 次预算),PutnamBench 达 41.5%(118 次预算),同样超越现有开源模型。

目前 LongCat-Flash-Prover 已全面开源,欢迎使用:

让我们感到惊喜的是,模型在开源后几日内,不仅受到了 AI 和大模型研究者们的关注,更引起了数学界的关注。发布当日,我们便收到了国内顶尖高校的合作邀请,共同探讨基于该模型开发形式化证明 Agent 的可能性。我们期望借此将现有的数学教材和前沿论文”翻译”成形式化语言,进一步充实形式化数学的知识底座,为整个数学研究领域的范式创新提供助力。这让我们深刻意识到:AI 在定理证明上的突破,不再仅仅是算法跑分,而是真正开始成为基础科学研究的“基础设施”

为什么要用形式化语言来完成定理证明?

自然语言天生带有模糊性,很难进行步骤级的严谨性验证,为了解决这个问题,数学家和计算机科学家们引入了形式化语言(如 Lean4)

你可以把 Lean4 理解为一种“数学编程语言”。就像 Python 代码可以通过编译器执行一样,用 Lean4 写出的数学证明,可以通过编译原理进行逐行校验。只要模型能写出语法正确、逻辑严谨且能通过 Lean4 编译器验证的代码,就意味着这个数学定理被 100% 严谨地证明了。

我们是如何教 AI 证明定理的?

教 AI 证明定理,就像教一个数学系新生,不能指望它一眼看穿答案,而是要教它拆解步骤。我们将 AI 的证明过程拆解为三个基础的形式化推理原子能力:

1. 自动形式化(Auto-Formalization)——“翻译题目”:先将自然语言描述的数学问题,精准翻译成 Lean4 计算机能看懂的形式化描述。

2. 草稿生成(Sketching)——“写解题大纲”:面对复杂定理,不急于一步写完。模型会先写一个草稿,把大问题拆解成几个需要证明的小引理(Lemma),理清逻辑主线。

3. 证明生成(Proving)——“补全细节”:沿着草稿的思路,一步步补全剩余的证明过程,完成逻辑推演。

为了让模型熟练掌握这三项技能,我们设计了一套结合“工具集成推理”(TIR)的“混合专家迭代”框架。简单来说,就是组合不同具备这些原子能力的专家模型,以单轮和多轮形式进行不断试错、自我纠正,从简单的完整证明,逐步过渡到复杂的“引理式草稿证明”。

一、技术亮点

1.1 混合专家迭代

在这个框架中,我们旨在结合不同的专家不断合成基于 Auto-Formalization、Sketching 和 Proving 这三个原子能力以及相互组合下的推理轨迹,并挑选高质量的数据来进一步提升相应专家模型的性能。

专家迭代主要包含两个阶段:

Cold-Start 阶段:我们首先利用团队在早期探索的基于 TIR 和 DPO 训练的 Auto-Formalizer 专有模型 ATF-32B 用于合成 Formal Statement。基于这些 Statement,我们利用 LongCat-Flash-Thinking-2601 生成高质量的带有多个 Lean4 相关验证工具反馈的轨迹。基于这些合成数据,我们通过执行去污、去重和基于难度和多样性的采样,构建了一个高质量的冷启动数据集。由于不同的专家模型来自不同的模型族,我们应用领域混合 SFT 来整合这些功能,并得到最终的冷启动模型。

Iteration 阶段:在迭代阶段,我们选择冷启动阶段得到的模型作为新的专家模型。每个形式推理任务的轨迹都是基于这个新专家模型合成的。此外,我们还整合了大量通用数据,以确保模型具备非形式推理能力。每一轮迭代中,我们会进行 SFT 和 RL 训练,多次迭代之后则可以得到 LongCat-Flash-Prover 模型。

1.2 课程学习模式下的 TIR 轨迹合成

在数据合成过程中,如何组织这些专家进行协同是一个挑战。我们设计了如下图所示的工作流。

每个专家模型都能同时生成单轮轨迹(不调用工具)和多轮轨迹(TIR 模式),从而确保合成数据的多样性。

为了使模型能够根据每个问题的难度动态选择合适的工具和证明策略,我们采用了一种课程学习方法:1)从单轮合成开始,然后是多轮调用工具合成;2)从生成完整证明逐步过渡到引理式草稿证明。

基本合成过程如下:

  1. 首先给定一个 Informal Statement(即一个自然语言问题),先用 Auto-Formalization 专家在单轮无工具条件下生成 N 个 Formal Statement。我们使用 Lean4 Server 和语义一致性打分模型来对每个结果进行打分。当且仅当生成的 Formal Statement 没有语法错误且语义与 Informal Statement 保持一致的则被认定为正确;

  2. 如果这 N 个 Formal Statement 包含正确的结果,则直接获取这些正确的 Statement 即可;如果全部错误,则激活 TIR 模式,通过结合 Lean4 Server 和语义一致性打分模型两个工具来不断修改,直到能生成正确的为止;

  3. 基于生成好的 Formal Statement,我们接下来使用 Prover 模型尝试生成证明。我们先使用 Whole-Proof 模式来一次性给出完整的证明过程,同样我们生成 N 个结果,并使用 Lean4 Server 和 Theorem 一致性来判断模型生成的证明是否通过。其中,Theorem 一致性是为了避免模型伪造或修改原始证明目标从而导致 Hacking 问题;

  4. 如果生成的 N 个 Whole-Proof 没有正确的,那么我们激活 Whole-Proof 的 TIR 模式,借助 Lean4 Server 和 Theorem 一致性打分工具的反馈信息帮助模型修改 Proof;

  5. 如果 Whole-Proof 模式下不论使用单轮还是 TIR 都无法被证明(通常是一些复杂的问题,或者需要超过 1000 行证明过程的问题),我们则开启 Sketch-Proof 的策略;

  6. Sketching 中,给定一个 Formal Statement,Sketcher 专家模型先生成 N 个 Sketch,每个 Sketch 包含多个待证明的 Lemma,以及一个 Main Body,我们同样采用 TIR 模式来帮助模型生成语法和 Theorem 一致的 Sketch;

  7. 对于每个 Sketch,我们再次使用 Prover 专家模型对每个 Lemma 进行 Whole-Proof 模式的证明,整个证明过程均使用 TIR 模式。

基于这些合成轨迹,我们进行了一些数据处理、多样性采样和难度控制,从而可以获得 SFT 模型。

1.3 形式化智能体工具

我们的专家迭代框架和 RL 训练框架中,共享相同的一套智能体工具:

1. Lean4 Server:我们部署了 Lean4 Server 并作为验证生成的 Formal Statement、Sketch 和 Proof 的语法是否准确。相比于之前工作直接将 Lean4 Server 的 JSON 格式作为反馈信息,我们对其进行了处理:通过将完整的 Proof 中插入锚点,即直接告诉模型错误代码片段,而非简单的行列坐标,这样可以避免模型错误判断错误代码的位置,提高纠错的准确性。

2. 语义一致性:只靠 Lean4 Server 可能会存在 Hack 问题,例如模型为了生成语法正确的代码而修改原始问题。为此,我们通过 LLM-as-a-Judger 的手段,验证模型生成的 Formal Statement 与原始问题是否语义一致。

3. Theorem 一致性:在模型生成 Sketch 或 Proof 时,需要确保模型的 Theorem 证明目标不能被篡改,一些微小的符号变化可能会导致整个证明问题发生改变。我们采用基于规则的方法来约束模型不能修改原始证明目标。

4. Legality 验证:我们观察到大约 9 种存在作弊的 Proof 行为,这些证明过程通常尝试修改 Formal Statement、插入提前终止符 #exit、插入不存在的公理或无法证明的假设、通过添加 macro、elab、syntax、notation 尝试绕过编译错误等手段企图达到 Lean4 Server 给出证明通过的反馈。通过引入 Legality 验证,可以极大地避免模型出现 Hack 问题。

1.4 HisPO 算法

Prover 在 RL 阶段训练使用 TIR 模式,我们基于 LongCat-Flash-Thinking 所使用的 DORA 训练框架进行。

在训练过程中,我们观察到 MoE 两个影响模型稳定性的因素:训推一致性问题以及 Staleness。对于训推 Diff,我们通过评估新旧策略模型在训练引擎与推理引擎上关于重要性采样比(Important Sampling Ratio,IS Ratio)的估计来衡量训推一致性。相比 GRPO 而言,我们除了将 Sequence-Mean-Token-Mean 调整为 Token-Mean 以外,我们主要引入分层的 Masking 策略来直接消除不稳定 Token 的梯度贡献:

序列层面 Masking:我们首先通过计算所有 Token 的 IS Ratio 的几何平均值来估计序列级的训练-推理 Diff。对于整个序列,如果 Diff 超过一定范围,则认为其对训练稳定性有显著影响,并将移除该序列的梯度贡献。该策略旨在仅考虑序列级的训练-推理一致性度量,避免过度忽略有价值的标记。

Token 层面 Masking:对于剩余的序列,我们将移除具有显著训推不一致性的 Token,以确保剩余标记不会因训练拉取不一致性而影响稳定性。

Token 层面 Staleness 控制:对于经过序列和 Token 层面的 Masking 处理后所保留的 Token,我们再考虑标准的 Clipping 操作,用于控制 Staleness,以确保更新幅度限制在一定范围内,从而保证训练稳定性。

1.5 有趣的发现:AI 也会在证明中“作弊”

在训练过程中,我们观察到了一个非常有意思的现象:AI 为了得到高分,学会了“作弊”。

如果仅仅依赖 Lean4 编译器作为裁判,模型有时会通过修改原始题目、插入提前终止符(如 #exit)、甚至凭空捏造不存在的公理,来骗过编译器,获得“证明通过”的反馈。

为了纠正这种“耍小聪明”的行为,我们不仅引入了 LLM 作为裁判来检验“语义一致性”,还专门开发了一个轻量级的 Lean4 词法和语法分析器。它能将代码转化为抽象语法树(AST),严格排查大约 9 种作弊手段。

二、实验结论

  • Auto-Formalization 任务:在 Auto-Formalization 任务上,LongCat-Flash-Prover 在所有自动形式化基准测试中均取得了新的最佳结果;尤其是在 MiniF2F-Test 和 ProofNet 测试中,我们获得了 100% 的得分。基于 TIR 的改进带来了高达 14% 的性能提升,凸显了工具反馈在帮助模型解决先前无法解决的任务方面的有效性。

  • 极高的样本效率(低预算、高通过率):过去,模型往往需要尝试上千次才能碰巧证明一个难题。而 LongCat-Flash-Prover 在结合工具集成推理(TIR)后,仅需 72 次尝试,就在 MiniF2F-Test 数据集上达到了 97.1% 的通过率,刷新了已知开源模型的 SOTA。

  • “打草稿”真的很管用:实验证明,在相同的计算预算下,采用”草稿生成(Sketching)”将问题拆解为引理,能让证明准确率平均再提升大约 10%。

  • 攻克超难竞赛级任务:在难度极高的 MathOlympiad-Bench、ProofNet、ProverBench 和 PutnamBench 测试中,模型分别达到了 46.7%、52.2%、70.8% 和 41.5% 的准确率,同样超越了现有的开源模型。

三、结语

从”答案看起来对”到”每一步都能被验证”,LongCat-Flash-Prover 不再满足于输出一个数值,而是像一位严谨的数学研究员,从公理出发,用计算机可验证的语言完成证明的闭环。

我们相信,当 AI 真正学会”证明”而不仅仅是”猜答案”时,它便有可能成为数学研究者、教育者与学习者的得力伙伴——不仅能帮助翻译文献、验证思路,更能启发新的证明路径,甚至参与前沿数学问题的探索。

目前,LongCat-Flash-Prover 已经全面开源。我们期待与学术界和开源社区一起,让严谨推理的能力走得更远,让每一次数学探索都有迹可循。

四、开源

🚀 欢迎体验与探讨:

| 本文系美团技术团队出品,著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容,敬请注明“内容转载自美团技术团队”。本文未经许可,不得进行商业性转载或者使用。任何商用行为,请发送邮件至 tech@meituan.com 申请授权。

还在为 Memory Agentic 操作框架反复重造轮子?也许,这正是这个方向迟迟没有爆发的根本原因。

AI Agent 领域有一个越来越清晰的共识正在形成:

真正决定 Agent 能不能从"会聊天的工具"进化成"长期持续工作的系统"的,不只是模型推理能力,也不只是工具调用能力,而是记忆能力。

没有记忆的 Agent,本质上仍然是一个"单轮应答器"

过去一年多,Memory-R1、MemAgent、RMM 三篇工作几乎前后脚放出来,社区里讨论"用强化学习训 Agent 记忆"的帖子开始刷屏。

大家发现一件事:每篇论文的代码都是各写各的——训练流程不一样,数据格式不一样,模块之间不能互换。想复现一个、对比一下,工程量就已经不小了。

问题就在这里——它们彼此之间太难复用,太难拼接,也太难公平比较。很多时候,真正拖慢 Agent Memory 研究的,不是想法不够多,而是重复造轮子的工程成本太高。

这正是 MemFactory 的出发点。

一句话说清楚:它是第一个专门给记忆增强 Agent 设计的统一训练 + 推理框架,思路上对标 LLaMA-Factory 做 LLM 微调的方法论——把记忆的生命周期拆成标准化的原子模块,像搭乐高一样组装,然后用 GRPO 做强化学习训练。

本次发布要点:

640 (2).png

[MemFactory 整体架构图:Module Layer / Agent Layer / Environment Layer / Trainer Layer 四层结构及数据流向]

一、为什么需要 MemFactory

Agent Memory 领域最不缺的就是新想法:Memory-R1 用 CRUD 操作显式管理记忆条目,MemAgent 用循环压缩把整段对话浓缩成记忆状态,RMM 则在检索阶段引入反思式重排序。三篇工作各有亮点,社区讨论热度也很高。

但真正上手复现的人都知道,难的不是理解算法,而是把它跑起来,再换一个跑跑看。

🌰 举个栗子

你基于 Memory-R1 搭好了一套 CRUD 式记忆管理 pipeline,Extractor 负责从对话中抽取记忆条目,Updater 负责执行增删改操作,训练跑通了,效果还不错。但你还想试一下 MemAgent 的循环压缩策略,试试效果哪个好。

按现在的开源现状,这两套代码的数据格式不一样,训练框架不一样,奖励函数不一样——换一个模块基本等于重新搭一次项目。

光是把数据转成对方的格式、重写训练循环、调通奖励计算,工程量就够折腾一两周了。这就是 Agent Memory 研究当前最大的瓶颈,每个团队都在重复解决相同的工程问题——数据格式转换、训练循环搭建、模块间接口适配——真正花在算法创新上的时间反而被大幅压缩。

MemFactory 目标很明确:成为 Agent Memory 领域的「LLaMA-Factory」,把记忆管理流程标准化,让不同的记忆策略能在同一套框架里即插即用。

二、四层架构:从原子操作到端到端训练

MemFactory 的整体设计分四层,每层职责清晰:

2.1 Module Layer(模块层)——记忆操作的最小单元。

把记忆流程拆成三种原子操作:

·Extractor(记忆抽取器):从原始对话中提取结构化记忆条目

·Updater(记忆更新器):对比新旧记忆,执行 ADD / DEL / UPDATE / NONE 四种操作

·Retriever(记忆检索器):从记忆库中找到与当前对话最相关的记忆条目,支持语义检索 + LRM 重排序

另外还有一个 Agent Module(智能体模块),专门给 MemAgent 这种"不拆抽取和更新、端到端直接生成新记忆状态"的策略用。

说白了,这一层做的事情就像把厨房里的"切菜""炒菜""调味"分成了标准工位。每个工位可以换不同的师傅(不同的实现),但工位之间的交接方式是固定的。

640(3).jpeg

[Module Layer 原子模块示意图:Extractor → Updater → Retriever 的数据流,以及 Agent Module 的端到端路径]

2.2 Agent Layer(智能体层)——把模块组装成完整的 Agent。

光有模块还不够,得有人把它们组织起来。MemFactory用"乐高式"组合不同模块的实现,构建出不同的记忆 Agent。框架内置了三个现成的 Agent 配置:

·MemoryR1Agent:基于 Memory-R1 的 CRUD 记忆管理;

·MemoryAgent:基于 MemAgent 的循环记忆压缩;

·MemoryRMMAgent:基于 RMM 的反思式检索优化;

每个模块统一暴露 generaterolloutinference 三个接口。训练时用前两个(会产生梯度),纯推理时用 inference(支持 vLLM 和 OpenAI 风格 API)。

你只需要指定用哪些模块、怎么组合,剩下的工程复杂度框架帮你消化。

2.3 Environment Layer(环境层)——数据加载 + 奖励计算。

Environment 层是 Agent 与任务之间的桥梁,兼具数据加载器和奖励管理器的双重角色。

它把不同数据集统一成标准格式,按记忆类型分两种环境:

·MemoryBankEnv:长期记忆场景,维护一个可更新的外部记忆库

·LongcontextEnv:短期记忆场景,直接处理长对话上下文

奖励信号支持格式奖励(Format Reward)和 LLM-as-Judge 两种方式。

2.4 Trainer Layer(训练层)——基于 GRPO 的策略优化。

GRPO 的好处是不需要额外训练一个 Critic 模型(PPO 的老问题了——Critic 占的显存跟 Policy 一样大),对于本来就要处理长上下文的记忆 Agent,这一点可以大大节省训练资源。

MemFactory 不是把强化学习"贴"在 Agent Memory 上,而是把"记忆策略是可以被训练出来的"这件事,正式做成了工程现实。

三、实验:单卡 A800 跑出来的提升

MemFactory 用 MemAgent 的公开训练集和评测集做了验证,基座模型分别是 Qwen3-1.7B 和 Qwen3-4B-Instruct。

训练数据做了简化处理——把上下文长度压缩到原来的 1/3 左右(每个样本 50-80 篇文档),整个训练 + 评测流程在单张 A800 80GB GPU 上就能跑完。

微信图片_2026-04-15_165335_487.png

两个值得一提的结论:

第一,1.7B 小模型在主任务上提升明显(eval\_50 从 0.47 跳到 0.57),平均提升 14.8%,不过在 OOD 评测上有所下降——小模型的泛化能力确实有限。

第二,4B 模型则更稳:三个评测集上全面提升,平均提升 7.3%,OOD 上也有正向增益。说明更大的模型确实能把学到的循环记忆策略迁移到没见过的场景里。

训练只需要 250 个有效步数,每个问题跑 4 次取平均(avg@4)。单卡就能做到这个效果,对大多数研究者来说门槛不算高。

四、开箱即用:三种 SOTA 范式一键跑通

MemFactory 目前内置支持三种最新的 Memory-RL 范式,不需要从头搭:

4.1 Memory-R1 路线

思路是把记忆管理拆成显式的 CRUD 操作——一个 Memory Manager 负责决定"加/删/改/不动",一个 Answer Agent 负责用记忆回答问题。MemFactory 里对应 NaiveExtractor + NaiveUpdater 的模块组合。

4.2 MemAgent 路线

不拆抽取和更新,直接把"上一轮记忆状态 + 最新上下文"丢给模型,让它生成新的记忆状态。相当于把记忆当成一个循环变量,每轮对话更新一次。MemFactory 里对应 RecurrentMemoryModule

4.3 RMM 路线

专攻检索环节——先用语义检索拉回候选记忆,再用大推理模型(LRM)做重排序。训练信号来自"模型到底有没有引用这条检索到的记忆",用 REINFORCE 更新重排器。MemFactory 里对应 RerankRetriever

三种路线覆盖了记忆生命周期的不同阶段(抽取/更新、端到端压缩、检索优化),研究者可以在同一套框架里做对比实验,也可以把不同路线的模块混搭着用。

快速上手

git clone https://github.com/MemTensor/MemFactory.git

cd MemFactory

MemFactory 想做的事情很简单——Memory-RL 这个方向已经证明了可行性,但基础设施还没跟上。每个团队都在重复造轮子,精力都花在工程适配上而不是算法创新上。有了统一框架之后,研究者可以把时间花在"这个记忆策略到底好不好"上,而不是"怎么把两套代码跑在一起"上。

这不就是当年 LLaMA-Factory 对 LLM 微调做的事情嘛,不是吗 ~

📎 相关链接

·GitHub:

https://github.com/MemTensor/MemFactory

·论文:

https://arxiv.org/abs/2603.29493

·MemOS 主仓库:

https://github.com/MemTensor/MemOS


关于 MemOS

MemOS 为 AI 应用构建统一的记忆管理平台,让智能系统如大脑般拥有灵活、可迁移、可共享的长期记忆和即时记忆。

作为记忆张量首次提出“记忆调度”架构的 AI 记忆操作系统,我们希望通过 MemOS 全面重构模型记忆资源的生命周期管理,为智能系统提供高效且灵活的记忆管理能力。

可以想象未来如果开发能力全部集中到这些 llm 厂商手中.
中低阶码农能力大幅退化。

虽然大企业可能仍然养得起一堆高素质开发者。

但是中小企业梭哈 llm 云员工之后,那岂不是任人家拿捏,你的业务进度,你的紧急 bug ,都在人家手里攥着。

就跟把睾丸放在人家手里一样,牵着你走。

刚刚接到一个电话,让我点击短信链接,购买医疗保险。我一看,并没有收到短信,然后是在骚扰拦截里找到的。这时候我就起疑心了,感觉像诈骗。短信内容如下:

[保通保险代理] 亲爱的 XXX ,您挑选的国任保障,点击 https://zlbao.com/xxxxxxx 完善保障,立享最高 600 万保险保障,合同约定范围内看病住院可报销!拒收请回复 R

我点进链接一看,上面直接写着我的名字、身份证和电话。当时我就奇怪了,为什么可以有我的身份信息?甚至还是直接预填在上面的?

打开短链以后,完整链接很长。我精简了一下,还能正常打开,并且不显示我的身份信息了。链接是 https://mkt-h5.zhelibao.com/v2/short?wareId=399&packId=707&pageVersion=insure

我查了一下域名 zhelibao.com ,看起来好像是正经保险公司,但是这事很像诈骗。还有 V 站的关联贴 https://www.v2ex.com/t/1059369

各位有没有遇到过?这到底是正经保险公司,还是诈骗?如果是公司,能不能举报泄露个人信息?如果是诈骗,能不能搞它一手?


PS:我还想着写个脚本爆破网站,污染它的数据库。于是从网上找了公开泄露的身份信息,填进去以后,居然要手机号验证码?给我的短信链接,可以是点进去就可以直接支付了,没有任何验证步骤。

最近想把视频号的一些直播存下来,搜了一圈发现这事居然这么麻烦 —— 要么挂代理抓包装证书,要么上逆向 Hook 微信进程,总之没一个省心的。

后来突然想到一个事:微信投屏到电视不是用的 DLNA 吗?那电视能拿到直播流地址,我电脑装个假电视不就行了?

试了一下,还真可以。SSDP 组播宣告自己是 MediaRenderer ,微信就会在投屏列表里显示出来。选中之后微信会通过 SOAP 把 m3u8 地址 POST 过来,直接截获就完事了。

整个过程不需要动微信客户端,不需要证书,不需要代理,因为这就是标准的 DLNA 协议流程 —— 微信没法区分真电视和假电视。

用纯 Python 标准库写的,零依赖,500 来行代码:

```bash
pip install wechat-finder-dlna
wechat-finder-dlna
# 手机投屏过来就能拿到直播流地址
```

拿到地址之后 ffmpeg 录制、VLC 播放都行。也支持 `--record` 直接录。

B 站、爱奇艺那些支持 DLNA 投屏的 App 也都能用,不只是微信。

项目在这: https://github.com/gtoxlili/wechat-finder-dlna

有想法欢迎提 issue 交流。

营业厅客服说没有什么其他费用,就是第一年免费,需要收个 100 元安装费,第二年一个月 10 元。

300M 的宽带,不知道会不会跟移动一样,晚上大概七八九点的时候,网络下降非常严重。

目前移动宽带 500M 的,这个月底到期,现在考虑要不要换联通的这个,觉得挺便宜的。

就是想问一下大家,有没有办理过这个宽带的,有没有坑?
晚上网络高峰期的时候降速严不严重?

由于您当前绑定的号码长期未进行身份验证,已被列为风险帐号,部分功能已受限。为避免被清除,请点击下方按钮进行验证。

点击它提供的机器人进去,就索要手机号码(察觉不对,没有给),查了下类似案例,下一步就是要验证码,骗子无疑

近日,有"行业风向标"之称的第十四届储能国际峰会暨展览会(ESIE2026)在北京召开。KaiwuDB 高级技术专家唐仲 受邀出席"储能 + AIDC 协同发展论坛",发表《从海量数据到智能运维,构筑能源 Data+AI 新基座》主题演讲,分享了 KaiwuDB 在新型储能数据底座建设与 AI 融合的创新实践。

KaiwuDB 唐仲发表主题分享

当前,在"双碳"目标与新型电力系统建设双重驱动下,我国新型储能产业迎来爆发式增长。同时,国家在政策层面将新型储能列入"新兴支柱产业"并进一步提出"着力构建新型电力系统"、"大力发展新型储能" 等重大部署,储能产业正从规模化增长迈向高质量发展新阶段。

会上唐仲表示:"随着新型储能产业的爆发式增长,海量、高频、多源的储能运行数据成为核心生产要素,也对底层数据基座提出了严苛要求。储能电站百万级测点每秒会产生数十万条时序数据,涵盖设备状态、能量流转、环境监测等多维度信息,传统数据库已难以应对高并发写入、实时分析、多模数据融合及 PB 级历史数据长期存储的核心需求。KaiwuDB 作为一款分布式多模数据库,我们构建"时序+多模+AI"的一体化技术底座,刚好可以解决产业快速发展带来的数据管理痛点。"

高性能时序数据处理:

KaiwuDB 时序引擎可实现千万记录/秒稳定写入、毫秒级查询,至高 30 倍数据无损压缩,可用于替换 InfluxDB 等主流传统时序数据库,高效支撑海量时序数据全生命周期管理。

一库多模,化繁为简:

KaiwuDB 以一套库代替时序 + 关系两套数据库,**简化架构、降低部署及运维成本,打破储能场景异构数据割裂的难题,为综合能源管理、调度优化提供统一数据支撑。

AI-Ready,智能运维:

库内 AI 模型算子化内嵌,支持 SQL 直接调用异常检测、寿命预测、容量预估等推理能力;同时结合了 LLM for DB 技术,覆盖数据库部署、查询优化、自治运维、数据分析全流程,大幅降低运维成本、提升运行效率。

截至目前,基于 Powered by KaiwuDB 的能源解决方案已在储能、风电领域规模化落地:支撑国网某省分布式储能聚合管理平台百万级测点毫秒级采集、PB 级数据高效存储,实现了光伏 100% 消纳供电可靠性达 99.999% ;支撑某大型风电企业新一代SCADA系统,应对日均 1 亿 + 条风机数据爆发式增长,查询性能提升 20 倍以上运维成本降低 30%,显著提升风电场发电效率。

未来,KaiwuDB 将持续深耕能源与新型储能领域,以分布式多模架构与原生 AI 能力为核心,不断优化适配储能场景的技术与解决方案,打造更具竞争力的 Data+AI 技术基座,助力产业突破数据管理瓶颈,加速智能运维与数据价值挖掘。

Anthropic 正在给 Claude 加上真实证件验证,目前主要针对新注册账号。新号门槛大幅提高,老号价值跟着涨了。🤡

Anthropic 官方帮助中心上线了"Claude 上的身份验证"页面。核心流程:提交护照、驾照或国家身份证,配合摄像头拍实时自拍,大概 5 分钟。不接受复印件、截图、数字证件。

目前是灰度推出,主要针对新注册账号和触发风控的场景。Anthropic 的原话是"当您访问某些功能时"才会看到验证提示。已经在正常使用的老账号,目前没有大规模推送验证的迹象。

接码平台批量注册的路子,成本和难度都在飙升。而且中国护照验证等于主动暴露内地身份,可能直接触发风控。这是一个两难,不验证功能受限,验证了身份暴露。

反过来,已经稳定运行的老账号价值在提升。有使用历史、有订阅记录、没触发过风控,这些在新规则下都是隐性资产。手里有老号的,好好养着。✌️

AI 平台收紧账号管理是大趋势。OpenAI 去年就开始对部分功能要求身份验证,Anthropic 现在跟上了。模型越强,平台越需要知道谁在用。

我们也不必恐慌。老账号正常使用就好,别折腾,别频繁换 IP ,别共享账号。长期来看,AI 工具的使用门槛只会越来越高。现在多准备一条后路,总比到时候被动好。

这件事换个视角看,其实利好谷歌,大家左手 Claude ,右手 Gemini ,还是一条好汉。

被封了几个号后,发现问题出在很容易忘记切换 全局代理。更换设备这些操作导致 ip 漂移;
于是突发奇想,如果把 claude code cli 所有操作行为锁死在一台 vps ; 就弄了个云端 web terminal 这小工具;

自己用了 2 天,写了 1 个 小项目,感觉还不错,意外收获是可以用手机直接打开网页,也可以躺在床上 编程了
但是手机输入不方便,于是就加了个 语音转 文字输入功能;

说来搞笑,我这个工具全程都使用 claude code 开发出来,用魔法打败魔法啊。我问他这个方案有没有违法 claude code 规则,他说 没有使用第三方工具使用订阅 token ,还是使用原生的 claude code cli ;在允许范围之内;看起来这条路目前比较安全。

有同样需求的同学可以试用一下,不过前提是你需要一台海外 vps 。我用的腾讯云 轻量 vps 99 元一年那种;之前用它来搭梯子。

https://github.com/mageg-x/ccwt

摘要:瓴岳科技原数据平台基于 Hive 与 StarRocks、Spark 多引擎协同架构,随着数据规模增长,在性能与易用性上逐渐面临瓶颈。通过引入阿里云 SelectDB,构建湖仓一体化探索分析平台,在无需迁移数据的前提下实现对 Hive 数据湖的透明加速,显著提升查询性能并简化架构,完成从多引擎协同向统一分析平台的升级。

瓴岳科技是一家以大数据与人工智能为核心的数字科技集团,旗下拥有国内产品洋钱罐与印尼市场产品 Easy Cash,致力于为全球用户提供卓越的金融科技服务。截至 2025 年,公司已服务全球超 114 家金融机构,拥有逾 1.81 亿注册用户,累计交易额突破 5400 亿元。

原数据平台采用 Hive 数据湖与多计算引擎(StarRocks / Spark)协同模式,其中 StarRocks 在部分场景中承担查询加速的能力。随着业务全球化与数据规模的迅猛增长,对查询体验及查询性能提出更高要求,原有架构在易用性、查询性能和扩展性方面逐渐暴露出瓶颈。

  • 平台接入复杂:原有架构在 Hive 之上提供 StarRocks、Spark 等多套计算引擎供业务方按需选用,但不同引擎间 SQL 方言不统一、最佳实践差异大,且查询结果一致性难以保障,导致用户接入使用过程复杂。
  • 查询性能受限:尽管平台已经将跨计算引擎兼容的查询自动路由至 StarRocks 进行加速,但核心探索分析场景下,复杂查询的 P95 响应时间仍高达 300 秒,严重制约数据探索效率与业务决策速度。
  • 数据处理链路维护难:数据导入导出过程依赖独立的物理机资源,需通过额外的数据 ETL 工具,对大量数据进行多轮加工处理,整体链路维护复杂且存在单点故障风险。
    原有架构.PNG
    因此,团队目前亟需构建一个能够兼容现有 Hive 生态的统一查询入口(即屏蔽底层多引擎差异,统一以 Hive SQL 作为访问方式),又能提供较 StarRocks 更优的极速查询体验,以支持洋钱罐团队从数据探索到可视化分析的全球一体化探索分析平台演进

为什么选择阿里云 SelectDB?

2025 年 3 月,在评估多个技术方案后,瓴岳科技团队最终将SelectDB 全新湖仓一体架构确定为核心破局方案。其不仅在查询加速能力上更胜于 StarRocks,更从架构层面实现统一查询入口与数据湖能力的全面释放,提供了面向数据湖的统一分析能力。其核心能力主要体现在:

  • Hive 透明加速能力:SelectDB 通过 Hive Catalog 直接对接 Hive 数据湖,无需任何数据迁移;同时高度兼容 Hive SQL 方言,查询结果与原引擎保持一致。使平台在不改变数据存储形态的前提下实现统一查询入口与业务无感切换,从而实现数据不动、查询升级。
  • 极致查询性能:基于对 Hive 的高度兼容性,更多业务查询可无缝路由至高性能的 SelectDB 计算引擎。在无需额外数据导入的前提下,相较原有 StarRocks 架构进一步释放查询性能,支撑高频交互式分析场景,平台整体查询效率可实现大幅提升。
  • 湖仓一体与存算分离:云原生存算分离架构与湖仓数据互通能力,使数据持续沉淀于 Hive,而计算统一收敛至 SelectDB,形成统一的湖仓分析架构,既能灵活应对业务峰谷,也显著降低数据链路复杂度与运维成本。

基于以上优势,团队正式立项引入 SelectDB。在落地过程中,为确保平滑过渡,我们构建了完整的线上 SQL 回放与结果一致性验证体系,并与 SelectDB 技术团队紧密协作,针对 Hive Catalog 的查询性能与兼容性进行了深度优化。历经两个月开发与两周灰度测试,新平台已在国内和印尼两地全面上线。

阿里云数据库 SelectDB 植根于开源 Apache Doris 的坚实基础,深度融合云随需而用的特性,依托阿里云基础设施,构建起云原生存算分离的全新架构,面向企业海量数据的实时分析需求,提供极速实时、湖仓融合统一、简单易用的云上数仓服务。扫码免费体验:
阿里云通用banner.PNG

基于 SelectDB 全新探索分析平台

新平台的核心是基于 SelectDB 云服务搭建的存算分离架构。计算层由 SelectDB 替换原有 StarRocks,作为统一的高性能查询引擎,存储层则继续沿用 Hive。通过 SelectDB 的 Hive Catalog 功能,实现了对 Hive 数据的“所见即所得”查询,无需复杂的数据同步。

基于 SelectDB 全新探索分析平台.PNG
新平台架构清晰覆盖数据全生命周期,具体可分为以下三层:

  • 数据导入:优化 CSV 导入流程,从依赖物理机与 Hive 命令的复杂链路,转变为数据直传对象存储(OSS),由 SelectDB 通过 INSERT INTO SELECT 方式高效写入 Hive,实现服务与物理机解耦,并支持 K8s 弹性伸缩
  • 数据查询:统一查询语言为 Hive SQL,并构建智能自动路由策略。路由基于函数兼容性判断、集群负载情况及表扫描量(超过 5TB 则保护性回退)三个核心策略,使查询路由比例从 60%提升至 95%,是探索分析整体性能提升的关键
  • 数据导出:利用 SelectDB 的 OUTFILE 功能,将原先需要创建临时表、手动拆分文件、补全文件头等多步复杂操作,简化为一步到位的导出指令,导出 P95 时间从 300 秒优化至 20 秒

总而言之,该架构下无需数据迁移即实现资源的弹性伸缩,且数据只在 Hive 中存储一份,省掉耗时且冗余的数据同步过程,极大简化了数据流转链路。目前,SelectDB 集群计算资源超 1000 Core,缓存数据量超 100 TB,日均查询量超 500 万次,P95 响应时间相比之前的 StarRocks 降低 90%+ 至 20 秒

该方案提供了一种面向 Hive 数据湖的统一分析平台升级路径,可为具备类似数据架构的企业提供参考借鉴。尤其适用于已构建 Hive 数据湖、存在多引擎协同且平台复杂度较高,并面临数据规模持续增长的数据团队,具备良好的通用性与可复制性

核心实践及优化经验

01 Hive 方言兼容:实现平滑迁移与高效查询

为确保用户无需改变查询习惯,平滑无感迁移至 SelectDB,我们在 Hive 方言兼容性上实施了一套完整方案。

关键措施

在 Hive 方言兼容性方面,我们采取了多项措施,实现了 98% 的 Hive 方言兼容性,为业务无感迁移奠定了基础。

  • 函数回测:建立了包含 100+ 个核心用例的回测框架,可在 5 分钟内完成全量运行。该框架确保了开发流程的质量:任何对 SelectDB 修改都需通过修改前后的回测对比,保证每次迭代都正向演进。
  • Hive UDF 验证:针对数十个关键业务 UDF,进行了集中的注册兼容性测试与结果验证。结果表明,绝大多数 UDF 可无缝迁移,仅少数涉及 Bitmap 函数或动态参数等高级特性的 UDF 尚待支持。
  • 线上 SQL 回放:建立了自动化流程,每天回放前一天的线上 SQL,对比 SelectDB 与 Hive 的执行结果。任何不一致案例都会与 SelectDB 技术团队协同分析解决,提前化解潜在的数据差异风险。
  • 标准数据集性能验证:基于线上数千条 SQL 的统计,构建了包含 20 个标准数据集,通过多轮性能验证。最终结果显示,其中约 12 个数据集的性能超越了 StarRocks,并符合上线标准。

底层实现逻辑

SelectDB 通过sql_dialectserde_dialect核心参数控制方言转换。流程如下:

  1. SQL 语句通过SQL dialect发送到sqloglot(一款开源 SQL 转换器)进行方言改写。
  2. 改写后的 SQL 会被传送至 SelectDB 的 nereids 进行语法解析。
  3. 解析器生成逻辑计划,经优化器转化为物理执行计划,分发至各后端节点(BE)执行。
  4. 最终,serde_dialect参数控制结果集的展示格式(如小数位数、布尔值形式等),确保输出符合预期。

通过这两个参数,SelectDB 实现了完整的方案转换逻辑,确保了查询的兼容性和执行效率。

底层实现逻辑.png

02 智能查询路由:兼顾性能与稳定

  1. 在统一入口下,我们设计了三层智能路由策略,在提升性能的同时保障集群稳定:
  2. 兼容性判断:优先判断 SQL 中使用的函数或语法是否被 SelectDB 支持。得益于 98%的兼容率,绝大多数查询可直达 SelectDB。不兼容时将进行回退至 Hive on Spark。
  3. 资源监控:实时感知 SelectDB 集群负载。在集群繁忙时,将查询自动回退,避免过载。
  4. 过载保护:当单表扫描量预估超过 5TB 时,查询将被回退,以保障 SelectDB 集群资源稳定运行。

这些回退策略将在查询日志中明确记录,用户可据此判断当前的集群资源状态或识别不兼容的函数,并进行相应的修改。

通过以上策略的实施,自动路由的上线使我们的路由比例从原先的 60% 提升至 95%

02  智能查询路由:兼顾性能与稳定.png

03 Hive 数据加速,查询性能数量级提升

在 SelectDB on Hive 架构下,我们通过多层缓存机制实现了查询性能的数量级提升,核心场景查询从分钟级缩短至秒级

缓存机制与配置

目前,集群缓存总容量超过 100TB,命中率长期保持在 90% 以上,这意味着大多数场景都能有效利用缓存资源。而关键配置在于 Hive Catalog 的精细化缓存控制:通过设置不同的 TTL,我们平衡了数据新鲜度与缓存效率。用户也可通过REFRESH命令主动刷新缓存。

CREATE CATALOG hive_catalog PROPERTIES (
    "type" = "hms",
    "schema.cache.ttl-second" = "60",
    "partition.cache.ttl-second" = "0",
    "hive.metastore.uris" = "thrift://127.0.0.1:9083",
    "get_schema_from_table" = "true",
    "file.meta.cache.ttl-second" = "0"
);

以 LDFI 数据为例,我们首先将 Parquet 文件拆分为多个块(Block)。查询时,系统首先在本地磁盘的 LRU 缓存中寻找这些数据块。若命中,则直接返回;若未命中,则从 HDFS 读取,并在查询完成后异步缓存至本地 LRU,供后续使用。
03 Hive 数据加速,查询性能数量级提升.png

04 全链路优化提速

除此之外,SelectDB 的引入使文件上传、数据导出、DQC 等方面的性能都得到巨大的性能提升,具体来看:

  • 在数据导入方面:SelectDB 通过 INSERT INTO hive_table SELECT * FROM OSS_FILE 命令,可将 CSV 经 OSS 直接高效写入 Hive 表,导入 P95 时间从 200 秒优化至 30 秒
  • 在数据导出方面,利用 SelectDB 原生的OUTFILE功能,将此前繁琐的导出流程(涉及创建临时表、手动拆分文件、补全表头等)简化为一步指令,使导出P95 时间从 300 秒降至 20 秒
  • 在数据质量检查上(DQC)上,SelectDB on Hive 通过任务分组与并发控制,高效调度大量校验任务,使 DQC 任务执行 P95 时间从原来的 2600 秒(约 43 分钟)骤降至 25 秒,提升超百倍。同时,为避免超大校验任务挤占集群资源,设计了降级方案,可自动切换至 Spark 引擎。

结束语

通过引入阿里云 SelectDB 构建新一代探索分析平台,不仅实现了性能的显著提升,更完成了从“多引擎协同 + 查询加速”到“湖仓一体 + 统一分析平台”的关键演进。成功构建了一个兼容现有生态、查询极速、体验流畅的全球一体化探索分析平台。未来,瓴岳科技将会进一步探索 SelectDB 的能力:

  • 应用异步物化视图:

    • 面向报表与看板场景,提供开箱即用的数据集加速能力,极大提升查询性能。
    • 依托 SelectDB 内置智能调度引擎,实现增量数据的自动化、定时化更新,保障数据时效性。
    • 支持自动查询路由,用户查询无需改写即可命中最优物化视图,实现透明加速。
  • 推行 Serverless:

    • 通过 Serverless 产品形态,实时应对业务流量潮汐,实现资源秒级按需分配,显著降低成本。
    • 面向高优先级批处理任务,通过自动资源扩容,保障大数据量作业稳定高效完成,提升平台 SLA。
  • 探索 AI 应用:

    • 在 ChatBI 场景探索向量混合检索,增强自然语言交互的数据探索能力与智能水平。
    • 在 Data Agent 领域集成 SelectDB MCP,打造基于统一数据服务的智能体生态,赋能自动化分析与决策。

随着全球数字化建设的不断推动,数字政务建设逐渐深入人心,政务服务网站成为群众办事、信息发布和数据共享的主要窗口。但也正因如此,政务网站承载着大量公民个人隐私信息,企业法人信息以及政务部门内部敏感文件等。一旦网站出现安全纰漏,导致大量数据被窃取或者丢失,引发的后果将不可想象。因此多年来,全国多地的政务服务网站因安全配置不当,防护能力不足而遭到通报,甚至出现网站被网络黑客成功入侵的安全事故。因此,政务服务网站的建设配置标准一路提升,安全问题首当其冲,SSL证书已经成为政务网站的安全标配。

政务网站选取SSL证书的严格标准

实现组织级身份验证:政务网站具有权威性,需明确向用户表明为真实政务机构,而非仿冒网站。因此,至少需要OV级证书,理想情况下使用EV证书,在浏览器地址栏突出政务单位全称,提升公信力与权威性。
满足国产密码合规要求:根据《密码法》安全评估要求,政务网站需优先采用国密算法(SM2)证书。仅支持RSA算法的证书将被判断不符合。证书支持国密算法或采用国密+国际双算法方案,才满足合规需求。
兼容各类终端与浏览器:政务网站访问者包含大量老旧系统的用户,证书只有具备优秀的兼容性,才能在各种系统、终端和浏览器上正常运行。
CA具备快速响应能力:当证书到期或私钥泄露,政务服务网站将面临服务中断危机,影响极大。证书服务商需支持7x24小时的技术服务,及时完成证书吊销、部署和续签等工作,保障政务网站稳定运行。

不适合政务服务网站的SSL证书类型

仅支持RSA算法证书:不支持国密算法,无法满足国密合规要求,无法通过密评。
无本土化服务证书:部分国际证书仅支持邮件工单,响应慢,影响政务部门的业务连续性。
免费证书:有效期90天过短,需频繁续期;且免费证书无组织验证,无法建立政务部门的身份信任。

国内外主流SSL证书品牌对比剖析

Certum:波兰最大的CA,欧盟信任列表成员,提供EV证书,价格亲民。但针对国内政务网站支持较弱,老旧系统的根证书预置缺失,且无中文售后服务。

沃通:国内较早支持国密的SSL证书厂商,支持国密算法,OV/EV证书支持政务网站密评改造。但由于曾经被浏览器信任库移除,导致政务单位接受度产生影响。

JoySSL:国密+国际双证书方案既满足兼容需求,又满足合规需求。支持7x24小时技术服务,可快速响应,处理紧急故障,符合政务服务网站安全需要。

灵活选型 保障政务数据安全流转

政务服务网站的SSL证书选型,绝非简单的安装部署即可,而需综合考虑身份验证强度、是否合规、终端兼容表现以及应急服务能力等多种因素。无论是国际品牌还是国外品牌,都存在各自的优势与缺陷。综合来看,政务部门的证书选型更偏向于国内,毕竟合规是绕不开的前提。在此条件下,综合品牌信誉与证书价值进行选择,方能有效保障政务数据在安全通道中流转。

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

关于分析师

Dawei Zhou
麦吉尔大学计算机科学与统计专业。熟练使用Python、R、SQL、C、stata、Wind数据分析软件,专注于金融、数理统计领域。擅长从复杂数据中提炼产业链投资逻辑,曾参与多家物流科技企业的商业化路径设计。
    • *

引言:无人物流车真的来了,而且比你想的要快

如果你在中山火炬开发区看到一辆没有驾驶舱、贴着“顺丰”标志的白色小车平稳驶过,不必惊讶——那是中山市首批功能型无人物流车正式上路了。3月18日,4条示范线路、22.4公里总里程,白犀牛、九识、新石器三家L4级企业携手顺丰、邮政,让“快递由无人车送到驿站”成为现实。

这不是遥远的概念,而是正在发生的成本革命。2025年中国快递业务量预计突破1900亿件,末端配送成本却依然占整个物流费用的50%以上。当一辆裸车价不到2万元的无人车,能把单票配送成本从0.21元打到0.08元,降幅超60%——这意味着什么?意味着一个快递网点老板,一年就能省下一辆奥迪A6的钱。

信息图表:无人物流_开场主题锚定_信息图表1

无人物流_开场主题锚定_信息图表1数据EXCEL及图表PDF模板已分享到会员群

分析:这张图用闭环箭头揭示了无人物流车爆发的三大驱动力——政策路权开放(200+城市)、L4技术成熟(事故率1.5次/万公里)、整车成本下降(裸车1.98万元)。三要素形成正向循环:路权让企业敢投入,技术降低了事故风险,成本让网点算得过账。角落“成本高昂、短期难商业化”的误区被三个箭头同时否定——行业已跨过示范试点,进入规模化前夜。

本文洞察基于东吴证券《无人物流专题:万事具备,爆发元年》长江证券《物流行业迎来无人技术的“DeepSeek时刻”》以及文末180+份物流与无人驾驶行业研究报告及数据,本文完整研究报告数据图表和文末180+份最新参考报告合集已分享在交流群,阅读原文查看、进群咨询,定制数据、报告和900+行业人士共同交流和成长。

    • *

核心结论:三个数据看懂无人物流“为什么是现在”

  1. 成本奇点已至:无人物流车单票配送成本从0.21元降至0.08元,降幅超60%,比人工便宜一半以上。
  2. 政策全面松绑:全国超200个城市开放路权,杭州、北京等地率先立法,无人车上路不再“偷偷摸摸”。
  3. 技术成熟度跃升:L4级自动驾驶在限定ODD(设计运行域)和低速场景下事故率低至1.5次/万公里,远程人车比可达1:120。

无人物流已从“示范试点”跨入“规模化商用”前夜,整车销售+软件订阅的双轮驱动模式将在未来3年催生千亿级市场。

信息图表:无人物流_焦虑破局认知反转_信息图表2

无人物流_焦虑破局认知反转_信息图表2数据EXCEL及图表PDF模板已分享到会员群

分析:这张图直接回答物流人最焦虑的问题——“无人驾驶到底能不能真降本?”左侧:单件配送成本0.21元→0.08元,降幅超60%;右侧:无人叉车渗透率1.66%→3.17%,三年翻倍。中间红叉否定“无人车不如人工划算”的错误认知。底部左右分栏用具体场景数据(支线物流2025销量超3万辆、末端配送月运营成本2130元 vs 司机月薪6500元)证明经济性。核心信息:成本拐点已到,不需要再观望。

    • *

一、政策红利全解读:路权从“奢侈品”变成“日用品”

2021年5月,北京高级别 自动驾驶 **示范区为京东、美团、新石器颁发国内首批无人配送车编码,这是中国无人配送车第一次获得合法路权。此后,政策开放速度远超行业预期。截至2025年6月,已有103个城市开放无人物流车路权试点,覆盖超过80%的主要物流节点城市。

解读:路权不再是稀缺资源,而是地方争夺“智慧物流示范城市”名片的筹码。
对应人群行动建议

  • 中小企业主:优先选择已开放路权的城市进行试点,节省3-6个月的牌照申请周期。
  • 品牌方:可联合无人车企业向当地政府申报“绿色配送示范项目”,争取补贴与路权优先。

值得注意的是,杭州在2024年5月率先为低速无人车立法,开放全市八城区3474平方公里测试区域。这种“区域示范→全国推广”的路径,让无人车企业能够像连锁店一样快速复制运营网络。新石器目前已获得超过250个地市公开道路路权,九识智能则在29个省份常态化运营。

    • *

二、行业景气度基本面:销量、渗透率、成本三线共振

2.1 无人物流车:从百台试用到万台交付

国泰海通证券预测,2024年中国无人物流车销量仅0.6万辆,2025年将飙升至3.26万辆,2030年达到60万辆。这个增长曲线的陡峭程度,与十年前智能手机普及率爆发如出一辙。

无人物流_销量预测_折线图表1

无人物流_销量预测_折线图表1数据EXCEL及图表PDF模板已分享到会员群

九识智能2024年交付2500台,2025年Q1订单同比增长4倍;新石器2024年交付1030台,2025年目标1.5万台。支撑这种量级跃迁的,是整车成本的断崖式下降——九识E6裸车价仅1.98万元,新石器X3包含5年FSD服务费也仅14.5万元。

本文节选自拓端发布的《专题:2025无人物流报告:爆发元年、降本增效与产业链机遇》,如需获取全文内容,可进入拓端官网搜索查看。

无人物流_市场规模_横向条形图表2

无人物流_市场规模_横向条形图表2数据EXCEL及图表PDF模板已分享到会员群

长江证券测算,以可替代的存量商用车1200万辆为基数,假设渗透率分别为10%、30%、50%,对应整车销售规模188亿、565亿、941亿元。解读:这不是“远期愿景”,而是未来3-5年可见的确定性增量。品牌方:可提前与无人车企业签订年度框架协议,锁定低价产能。

    • *

相关文章

2026AI医疗行业专题报告:智能医疗器械、手术机器人、脑机接口、可穿戴设备|附240+份报告PDF、数据、可视化模板汇总下载

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

    • *
2.2 无人叉车:制造业的“隐形降本利器”

天风证券数据显示,中国无人叉车出货量从2019年的2700台增至2023年的1.95万台,渗透率从0.44%提升至1.66%,预计2025年将达3.9万台,渗透率3.17%。

无人物流_无人叉车销量渗透率_双轴图表3

无人物流_无人叉车销量渗透率_双轴图表3数据EXCEL及图表PDF模板已分享到会员群

背后的推动力是价格腰斩。2018年一台无人叉车均价60万元,2023年降至20万元,2027年有望跌破18万元。解读:对中小制造企业而言,1.3年即可收回投资(替换2-3名叉车司机,年省人力20万元)。创业者:可考虑提供“无人叉车租赁+按吨计费”的轻资产服务,切入中小工厂市场。

无人物流_无人叉车均价_折线图表4

无人物流_无人叉车均价_折线图表4数据EXCEL及图表PDF模板已分享到会员群

技术路线上,SLAM自然导航已成为绝对主流,2023年占无人叉车销量的75%,彻底淘汰了需要预埋磁钉或反射板的旧方案。这意味着无人叉车部署周期从数周缩短到数小时,柔性生产成为可能。

无人物流_SLAM导航占比_圆环图表5

无人物流_SLAM导航占比_圆环图表5数据EXCEL及图表PDF模板已分享到会员群

信息图表:无人物流_概念拆解价值分层_信息图表3

无人物流_概念拆解价值分层_信息图表3数据EXCEL及图表PDF模板已分享到会员群

分析:这张图聚焦“如何选对技术路线”。左上角红框标注核心概念“SLAM自然导航技术”,中心问题是“我的企业如何获益?”左右分栏给出答案:左侧高风险区——传统人工叉车、高精地图依赖方案、低价低质AGV;右侧高价值区——无人叉车AMR、轻地图+多传感器融合、硬件低价+软件订阅。底部箭头指明方向:从重资产购买转向订阅制。中小企业主别再买需要预埋磁钉的旧款AGV,直接选择支持“轻地图+订阅制”的AMR供应商。

    • *

三、产业链投资图谱:从“大脑”到“手脚”的价值分配

我们把无人物流产业链拆解为三个核心环节,并按投资优先级排序:

环节代表企业壁垒国产替代空间核心催化
控制器/软件(大脑)仙工智能、驭势科技算法+数据闭环,毛利率超80%高,2024年独立控制器销量3.1万台,复合增速84.4%具身智能大模型上车
整车制造(躯体)新石器、九识、杭叉集团规模化生产+路权牌照,毛利率约15%-25%中,但国内企业已主导中低端市场年交付量突破1万台
运营服务(血液)顺丰、京东、菜鸟场景理解+运力网络,盈利靠订阅费低,巨头自建车队单城日均订单超5000单

A股选股核心逻辑

  • 杭叉集团(603298) :传统叉车龙头转型智能物流,2024年智能物流营收增长近80%,收购国自机器人补齐AMR技术。
  • 安徽合力(600761) :与华为、顺丰、京东深度合作,智能物流业务2025H1同比+59%,布局具身智能。
  • 中力股份(603194) :电动仓储叉车市占率第一,投资睿芯行、科钛等核心技术公司,6月将发布带机械手的具身物流机器人。

预期差:市场普遍认为无人车企业短期难以盈利,但东吴证券测算当累计销量达到4万辆时,单车利润即可转正;达到10万辆时净利率达29%。九识智能2025年目标交付1万辆,新石器冲刺1.5万辆,头部企业正在快速逼近盈亏平衡点。

    • *

四、细分赛道 深度 **拆解:快递末端 vs 工厂内部物流

4.1 快递末端配送:顺丰+新石器验证“人机协同”

传统模式:网点→快递员→驿站,单票成本0.21元。
无人车模式:转运中心→无人车→驿站,单票成本0.10元,降幅52.4%。

无人物流_单票成本对比_灰底条形图表6

无人物流_单票成本对比_灰底条形图表6数据EXCEL及图表PDF模板已分享到会员群

顺丰已在湖南、郑州等地规模化部署新石器X3,单车每月节省人力及燃油成本约1000元,效率提升30%以上,且支持夜间作业。解读:加盟制快递网点老板应重新算账——一台5万元的无人车,一年省下的司机工资就能回本。行动建议:加盟商可联合几家网点共用一台无人车,分摊成本。

信息图表:无人物流_案例验证流程拆解_信息图表4

无人物流_案例验证流程拆解_信息图表4数据EXCEL及图表PDF模板已分享到会员群

分析:左右对比结构验证“人机协同”模式。左侧传统思维——“无人车投入大、维护复杂,不如多雇司机”,结果人力成本上涨、效率瓶颈。右侧核心新思维——“人机协同:无人车干线接驳,快递员专注上门服务”,以顺丰+新石器X3拆解4步流程:转运中心装货→L4自动驾驶至驿站→驿站人员卸货→自动返程充电。底部量化结果:单票成本0.21元→0.10元,降幅52.4%,单车每月节省约1000元。这不是空谈理论,而是已被头部企业验证的可复制流程和真实收益。

4.2 工厂内部物流:无人叉车从“可选项”变“必选项”

以汽车制造、3C电子为例,一条产线原本需要3-4名叉车司机三班倒,年人力成本超过30万元。部署一台无人叉车(20万元)后,1.3年即可收回投资,后续每年净省15-20万元。加上无人叉车可以24小时作业,综合流转效率提升30%-50%。

    • *

五、预期差挖掘:市场低估了“软件订阅”的利润弹性

很多人把无人物流车看作“硬件生意”,但头部企业的真实盈利模型是“硬件贴成本卖,靠软件订阅赚钱”。九识智能E6裸车1.98万元,但FSD(完全自动驾驶)服务费1800元/月;新石器X6打包5年FSD售价15.5万元,平均每年3.1万元。

东吴证券测算:当销量达到5万辆时,单车利润可达4.3万元,净利率40%+。解读:这已经不是卖车,而是卖“运力即服务”(TaaS)。对应人群:产业资本应关注具备数据闭环能力的软件平台,而非单纯制造企业。

另一个预期差:市场认为无人车只能在快递末端使用,但实际已拓展到商超补货、社区团购、医药冷链等场景。新石器订单中超过50%来自非快递场景,预计2026年该比例将提升至70%-80%。

    • *

六、风险提示与应对方案

风险1:路权政策反复或地方保护主义

具体应对方案:优先选择已立法(如杭州、北京)或拥有国家级示范区的城市部署;与当地邮政管理局共建示范线路,绑定政府KPI。
社群支持:交流群内每周更新全国路权开放地图,并提供地方对接资源。

风险2:无人车事故导致舆论收紧

具体应对方案:购买不低于300万元的第三方责任险;采用“远程安全员+车端冗余”双保险;初期在封闭园区或低风险路段运营。
社群支持:可咨询定制化的保险方案与安全标准文档。

风险3:技术路线突变(如纯视觉替代激光雷达)

具体应对方案:选择支持“轻地图、多传感器融合”方案的供应商(如九识、新石器均已在2025H2切换至轻图模式);硬件采购保留可升级接口。
社群支持:交流群内分享主流厂商技术路线图更新。

    • *

七、可落地的3件事(行动清单)

  1. 下周可做:盘点公司半径20公里内的转运中心与驿站,计算日均包裹量,若超过2000件/天,立即联系无人车企业申请3个月免费试运营。
  2. 下月可做:参加至少一场无人物流路演(如新石器、九识的招商会),重点关注“城市运营商”加盟政策,抢占本地独家代理。
  3. 下季度可做:联合本地3-5家快递网点,共同采购5-10台无人车,成立区域运力共享平台,摊薄运维成本,争取政府新能源物流补贴。

信息图表:无人物流_行动指南建议清单_信息图表5

无人物流_行动指南建议清单_信息图表5数据EXCEL及图表PDF模板已分享到会员群

分析:这张图将全文分析浓缩为三条可立即执行的行动建议。每条遵循“否定错误做法→明确正确方向→核心结论”结构。建议一:不要盲目购买高价无人车,先租赁/订阅试点,3-6个月验证ROI,单票成本0.10元。建议二:不要再依赖人工叉车+高精地图,部署SLAM无人叉车+订阅,投资回收期1-1.5年,人力成本降70%。建议三:不要单打独斗自研无人驾驶,与新石器/九识合作,共享路权与数据,快速规模化。适合截图保存,作为企业引入无人物流的第一步检查清单。

    • *

八、数据汇总表与参考报告目录

获取文末所有报告数据,进交流群,加小助手微信号:tecdat_cn

核心数据表格(基于报告提取)

指标2024A2025E2026E2030E来源
无人物流车销量(万辆)0.513.2610.0260.0东吴证券
无人物流车渗透率0.2%1.2%3.4%18.3%东吴证券
无人叉车出货量(万台)2.453.364.94-天风证券
无人叉车渗透率1.91%2.5%3.5%-天风证券
无人叉车均价(万元/台)21201918东海证券
SLAM自然导航占比75%---招商证券

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

通渠有道:2024年园区物流无人驾驶行业研究报告.pdf

军工&交运行业:需求、技术、政策共振,无人化物流发展正当时.pdf

无人叉车行业深度: AI 驱动无人叉车技术持续发展,智慧物流有望迎来快速发展期.pdf

2025物流无人车商业落地现状、应用场景、市场规模及重点企业分析报告.pdf

东吴证券:无人驾驶深度之一:无人物流专题:万事具备,爆发元年.pdf

低速无人行业系列研究报告之二:无人物流行业兴起,无人叉车企业或充分受益.pdf

无人系列专题报告(一):智慧物流东风起,无人叉车晓将至.pdf

长江证券-物流行业迎来无人技术的“ DeepSeek 时刻”.pdf

天风证券:机械设备:无人叉车:智造升级引擎,物流变革新支点.pdf

具身智能产业深度研究(六):物流无人车从快递起步,迈向城市配送星辰大海.pdf

无人叉车进入加速渗透期,厂商积极布局智能物流.pdf

市场洞察:从“最后一公里”到“城市级运力”,无人物流车迎来产业化窗口期.pdf

智能物流行业专题报告:AI赋能物流新变革,无人叉车引领智能升级.pdf

印度的新时代物流革命:无人机配送,冷链,和超本地化解决方案.pdf

南疆喀什自营仓整合营销方案【仓储物流】.pdf

2025货主企业绿色物流CATI指数评价报告.pdf

国家发改委:2025社会物流统计调查制度.pdf

交通运输行业:地缘冲突下的能源变局与煤炭物流机遇.pdf

交通运输行业:地缘冲突下的能源变局与煤炭物流机遇.pdf
2026-04-09 16:10
印度的新时代物流革命:无人机配送,冷链,和超本地化解决方案.pdf
2026-03-26 16:44
2025中国跨境电商物流行业研究-灼识咨询.pdf
2026-03-21 17:12
中物联医药物流与供应链分会:2026医疗机构中药制剂市场分析报告.pdf
2026-03-20 15:41
DHL:2026年全球物流报告(英文版).pdf
2026-03-20 15:38
印度的新时代物流革命.pdf
2026-03-20 15:35
罗戈网:2026LOG中国供应链物流创新科技报告.pdf
2026-03-13 15:47
市场洞察:从“最后一公里”到“城市级运力”,无人物流车迎来产业化窗口期.pdf
2026-03-12 16:04
网经社:2025年度中国物流科技投诉数据与典型案例报告.pdf
2026-03-10 16:23
南疆喀什自营仓整合营销方案【仓储物流】.pdf
2026-03-03 14:53
顺丰控股公司深度研究:厚积薄发,综合物流龙头开启新成长-国海证券.pdf
2026-03-02 16:08
零排放货运行动:全球物流排放理事会物流排放核算与报告框架V3.2中文版.pdf
2026-03-01 10:10
2024年全球物流排放理事会:物流排放核算与报告框架V3.2.pdf
2026-02-04 16:36
安徽交控迅捷物流园区招商手册.pdf
2026-02-04 16:31
国防军工行业空天系列:星舰量产驱动学习曲线重现,降本规模有望重新定义全球物流.pdf
2026-02-04 16:27
国家发改委:2025社会物流统计调查制度.pdf
2026-01-30 16:02
2025年未来航空货运设施愿景:通过技术和创新重塑物流.pdf
2026-01-25 12:34
新兴市场的绿色物流创新:驱动竞争力与共享价值.pdf
2026-01-22 19:40
2026年冷链物流服务模式升级技术驱动、需求拉动与政策赋能的多维分析报告-先见AI.pdf
2026-01-22 12:05
2025货主企业绿色物流CATI指数评价报告.pdf
2026-01-13 17:25
为什么选择波兰-2025波兰工业和物流房地产市场投资指南.pdf
2026-01-11 09:32
2025年物流品牌25强.pdf
2026-01-09 17:01
中国数联:2025中国物流数据发展白皮书.pdf
2026-01-06 16:00
戴德梁行:2025第三季度大中华区物流地产市场回顾报告.pdf
2026-01-06 08:43
2025年美国零售与消费者物流满意度报告.pdf
2025-12-18 14:46
新兴市场的绿色物流创新:驱动竞争力与共享价值洞察报告.pdf
2025-12-17 16:19
2025年中国第三方物流行业市场研究报告.pdf
2025-12-14 08:27
2025年中国跨境物流行业市场研究报告.pdf
2025-12-12 17:01
即时配送行业:万物皆可即时达,配送物流迎机遇.pdf
2025-12-10 16:54
中国AOPA:2025中国低空物流产业链名录.pdf
2025-12-05 16:47
企业竞争图谱:2025年智能物流车 头豹词条报告系列.pdf
2025-12-02 17:39
具身智能产业深度研究(六):物流无人车从快递起步,迈向城市配送星辰大海.pdf
2025-11-30 09:11
2025年智慧物流的目标、主要内容和场景研究报告.pdf
2025-11-19 15:26
弘人网络:2025年智能制造行业物流与供应链数字化转型白皮书.pdf
2025-11-15 15:12
2025年第三季度全国物流地产市场报告-物联云仓.pdf
2025-10-27 16:15
探迹科技:2025年跨境物流行业发展趋势报告.pdf
2025-10-23 16:25
2025年冷链物流行业研究报告-硕远咨询.pdf
2025-10-20 15:04
戴德梁行:2025年第二季度大中华区物流地产市场回顾报告.pdf
2025-10-09 08:10
2025年信息、零售和物流杂志:用人工智能塑造未来报告(英文版).pdf
2025-09-19 16:50
天风证券:机械设备:无人叉车:智造升级引擎,物流变革新支点.pdf
2025-09-18 16:27
低速无人行业系列研究报告之二:无人物流行业兴起,无人叉车企业或充分受益.pdf
2025-09-12 16:29
荣续ESG智库:2025年零碳物流园区发展白皮书.pdf
2025-09-10 15:32
无人叉车进入加速渗透期,厂商积极布局智能物流.pdf
2025-09-03 16:44
2025年华中区域物流地产市场报告-物联云仓.pdf
2025-09-01 16:35
_印孚瑟斯Infosys:2025年全球物流行业展望报告(英文版).pdf
2025-08-26 16:59
中国高标仓物流市场报告2025年上半年.pdf
2025-08-25 16:29
港口物流园区解决方案(58页).pdf
2025-08-23 17:13
智慧物流园区项目建设方案(65页).pdf
2025-08-23 17:11
机械设备-机械设备专题研究:机器人重构万亿物流仓储产业链-华泰证券.pdf
2025-08-22 16:25
中国物流与采购联合会:2025年货车司机从业状况调查报告.pdf
2025-08-08 16:09
2025年低碳供应商(物流)评价报告v1.0.pdf
2025-08-05 15:29
智能物流仓储:智算驱动下的物流革命,仓储系统进入跃迁期 头豹词条报告系列.pdf
2025-08-05 15:27
2025年郑州市物流地产市场报告-物联云仓.pdf
2025-08-04 14:54
2024年从货架到消费者:无缝物流的实践艺术研究报告(英文版).pdf
2025-07-31 16:49
上海冷链协会:2025年新质冷链物流发展白皮书.pdf
2025-07-29 17:09
2025年第二季度全国物流地产市场报告.pdf
2025-07-28 16:20
2025年中国仓储物流市场年中回顾与展望.pdf
2025-07-28 16:20
交通运输行业深度研究报告:交运低空60系列研究(二十一),低空+物流,新质生产力的经济账怎么算?.pdf
2025-07-25 15:42
无人系列专题报告(二):无人城配物流,L4级自动驾驶率先落地场景.pdf
2025-07-23 16:22
世邦魏理仕CBRE:2025年欧洲物流租户调查报告(英文版).pdf
2025-07-22 15:43
长江证券-物流行业迎来无人技术的“DeepSeek时刻”.pdf
2025-07-18 16:33
无人系列专题报告(一):智慧物流东风起,无人叉车晓将至.pdf
2025-07-18 16:32
人力更新報告運輸及物流業 2025.pdf
2025-07-14 16:16
人力更新报告2025-运输及物流业(繁体版).pdf
2025-07-11 15:59
无人叉车行业深度:AI驱动无人叉车技术持续发展,智慧物流有望迎来快速发展期.pdf
2025-07-10 16:30
交通物流降本提质增效典型案例(首批).pdf
2025-07-08 16:52
香港运输及物流局:2025物流业ESG发展路线图(繁体版).pdf
2025-07-08 16:52
低空经济专题报告:盘点江浙沪皖低空经济建设,重点关注低空物流领域.pdf
2025-07-08 16:49
低空经济专题系列报告四:无人机与低空物流:拥抱无人物流时代.pdf
2025-07-06 08:29
戴德梁行:2025第一季度大中华区物流地产市场回顾报告.pdf
2025-07-04 16:26
2025年一季度中国非保税高标物流地产市场概览-仲量联行.pdf
2025-06-30 15:10
2025年第一季度长三角城市群非保税高标物流地产市场概览.pdf
2025-06-30 15:03
2025年第一季度京津冀城市群非保税高标物流地产市场概览.pdf
2025-06-30 15:03
2025年第一季度珠三角城市群非保税高标物流地产市场概览.pdf
2025-06-30 15:03
2025年第一季度珠三角城市群非保税高标物流地产市场概览报告.pdf
2025-06-27 16:40
智能物流行业专题报告:AI赋能物流新变革,无人叉车引领智能升级.pdf
2025-06-27 16:30
交通运输行业2025中期策略报告:供给加速出行反转,科技重塑物流格局.pdf
2025-06-26 16:45
2025物流无人车商业落地现状、应用场景、市场规模及重点企业分析报告.pdf
2025-06-25 16:33
罗戈研究:2025中国低碳供应链&物流创新发展报告.pdf
2025-06-24 15:09
2025年西南区域物流地产市场报告.pdf
2025-06-23 15:42
车路云50人:2025自动驾驶干线物流商用报告.pdf
2025-06-18 15:29
华源证券-无人车行业深度:物流无人车浪潮起,产业变革新机遇.pdf
2025-06-14 16:31
中物联:2025中国电子产业物流发展现状及未来趋势报告.pdf
2025-06-12 15:36
2024年量子计算在交通运输与物流领域的应用研究报告(英文版).pdf
2025-06-12 15:35
东吴证券:无人驾驶深度之一:无人物流专题:万事具备,爆发元年.pdf
2025-06-12 15:33
马士基(Maersk):2025年全球物流趋势图谱:十大物流趋势(英文版).pdf
2025-06-11 16:34
2025年全球电子商务趋势报告:购物行为、物流偏好与市场动态(英文版).pdf
2025-06-09 13:36
戴德梁行:2025年全球物流与工业地产市场动态报告(英文版).pdf
2025-06-09 13:33
物联云仓:2025年华东区域物流地产市场报告.pdf
2025-05-23 16:20
安能ane:安能物流2024年度ESG报告.pdf
2025-05-15 16:10
2025年中国电子产业物流发展报告.pdf
2025-05-14 16:36
2025年低碳物流解决方案——碳排放计算汇报研究报告.pdf
2025-05-08 16:04
从人工搬运到智能搬运托盘识别技术引领高效物流.迈尔微视.pdf
2025-05-08 16:00
物联云仓:大数据驱动的数智化仓储物流服务平台.pdf
2025-04-29 16:04
脱碳物流:推动更绿色、更具盈利能力的供应链的技术与策略-GEP.pdf
2025-04-29 16:04
南方顺丰仓储物流REIT价值分析:仓配一体化龙头的REIT首亮相.pdf
2025-04-25 16:01
网经社:2024年度中国物流科技市场数据报告.pdf
2025-04-24 15:48
跨境电商物流行业报告:从干线运输到末端配送,解码跨境电商物流市场战略机遇.pdf
2025-04-23 15:57
2024年粤港澳大湾区物流市场-第一太平戴维斯.pdf
2025-04-14 11:02
军工&交运行业:需求、技术、政策共振,无人化物流发展正当时.pdf
2025-04-11 16:24
第一太平戴维斯:2025年中国物流地产回顾与展望报告.pdf
2025-04-10 16:16
罗戈研究_2025年中国供应链物流科技创新发展报告.pdf
2025-04-08 15:49
智慧多维交运物流行业产业链跟踪研究(一):AI与大模型时代,智慧交运物流赛道研究框架.pdf
2025-04-04 17:56
2025中国物流与供应链领域AI应用研究报告.pdf
2025-04-03 15:53
机器人行业跟踪报告之五:物流机器人市场空间广阔-光大证券.pdf
2025-03-28 16:26
物联云仓:2024年全国物流地产市场报告.pdf
2025-03-27 14:57
中国物流信息中心:2025年全国物流预警预测报告.pdf
2025-03-25 16:03
智慧物流赋能制造业数字化转型 (30页).pdf
2025-03-25 15:50
2025年Q1物流仓储行业薪酬报告.pdf
2025-03-24 14:37
“AI+”如何为ToB供应链物流赋能.pdf
2025-03-20 14:48
2024年跨境物流市场回顾与趋势研判报告.pdf
2025-03-18 12:42
2025年Q1物流运输业行业薪酬报告.pdf
2025-03-17 14:50
2025年公路干线物流自动驾驶行业研究报告.pdf
2025-03-11 16:30
2024年物流行业中的数据与AI白皮书:战略性地引入人工智能技术(英文版).pdf
2025-03-11 16:29
慈溪市综合物流园区概念性规划方案(62页).pdf
2025-03-05 15:27
红桥物流园区现代化信息建设技术方案(123页).pdf
2025-03-05 15:24
2024Q4长三角城市群物流报告-JLL.pdf
2025-03-03 14:48
2024Q4珠三角城市群物流报告-JLL.pdf
2025-03-03 14:47
2024年度中国物流科技投诉数据与典型案例报告.pdf
2025-02-21 14:47
华源证券-2025年物流行业投资策略:经济修复,物流先行.pdf
2025-02-08 15:05
2024年第四季度物流地产报告.pdf
2025-01-21 15:29
2023年粤港澳大湾区供应链领域标准规则衔接研究报告——以供应链物流为例.pdf
2025-01-14 16:15
高力国际-2023Plus版全球物流仓储库租金报价地图.pdf
2025-01-10 16:32
华税:2025年物流运输行业税务合规报告.pdf
2025-01-04 17:26
城市物流转型.pdf
2025-01-02 14:21
中国餐饮供应链指南2024(冷链物流及设计咨询篇).pdf
2025-01-01 20:16
2024年新能源与新交通融合赋能物流行业高质量发展报告.pdf
2025-01-01 20:15
2024第三季度大中华区物流地产市场回顾报告.pdf
2025-01-01 20:14
跨境电商平台出海目的地-中东市场-:行业呈现三足鼎立态势,物流和支付是竞争关键.pdf
2024-12-28 16:48
2024新能源城配物流车总使用成本TCU白皮书.pdf
2024-12-25 15:55
交通运输行业专题报告:中国仓储物流园区REITS:迈向智能化升级,发展潜力较大.pdf
2024-12-25 15:44
交银国际证券-物流房地产:电商时代的中流砥柱.pdf
2024-12-25 15:44
中国城市物流竞争力报告(2024)-同济大学.pdf
2024-12-21 17:20
2024中大件跨境物流供应链洞察报告.pdf
2024-12-20 16:21
亿邦智库&西邮物流:2024年中大件跨境物流供应链洞察报告.pdf
2024-12-10 15:57
粤港澳大湾区供应链领域标准规则衔接研究-以供应链物流为例.pdf
2024-12-10 15:53
探迹科技:2024年跨境物流行业发展趋势报告.pdf
2024-12-07 17:18
2024年物流及航运物流行业ESG白皮书.pdf
2024-12-06 16:58
智慧物流装备:智慧物流装备趋于智能化、高效化,成为推动物流行业发展的重要力量.pdf
2024-12-03 15:33
2024物流仓储暨基础设施投资发展报告.pdf
2024-11-30 20:22
2024年全球物流排放理事会:物流排放核算与报告框架V3.1(英文版).pdf
2024-11-28 16:58
2024年马士基亚太区独家趋势与洞察蓝皮书-锚定2024年亚太区物流的挑战和制胜之道.pdf
2024-11-26 15:56
2024年跨境电商竞争力研究报告-物流企业.pdf
2024-11-26 15:56
通渠有道:2024年园区物流无人驾驶行业研究报告.pdf
2024-11-23 17:15
民生证券-嘉友国际-603871-深度报告:矿产物流出海,还看今朝.pdf
2024-11-23 17:00
2024航空物流行业ESG白皮书.pdf
2024-11-21 15:42
2024年第三季度:京津冀城市群非保税高标物流地产市场概览.pdf
2024-11-20 16:30
2024年第三季度:珠三角城市群非保税高标物流地产市场概览.pdf
2024-11-20 16:30
2024年第三季度中国物流地产市场报告.pdf
2024-11-20 16:30
2024年第三季度中国非保税高标物流地产市场概览-JLL.pdf
2024-11-18 15:18
2024年欧洲电子商务物流市场报告(英文版).pdf
2024-11-07 16:56
2024从人工搬运到智能搬运_托盘识别技术引领高效物流白皮书.pdf
2024-11-06 15:37
京东物流:5G助力物流数字化转型升级.pdf
2024-11-05 15:54
物联云仓:2024年第三季度物流地产市场报告.pdf
2024-10-18 17:02
2024年物流行业橙皮书-高质量增长:连接型CRM驱动新质生产力.pdf
2024-10-17 15:55
中物联冷链委:2024年冷链物流政策发展演变与趋势研判报告.pdf
2024-10-17 15:41
京津冀物流地产市场的新融合.pdf
2024-10-14 15:41
物流云:构建全球化供应链的数字引擎 头豹词条报告系列.pdf
2024-10-13 15:41
2024中国自动驾驶物流货运产业洞察研究报告.pdf
2024-10-12 15:11
阿里巴巴国际站:半托管物流介绍.pdf
2024-10-11 15:25
天风证券-计算机行业深度研究:数据要素重大变化:助力出海与统一大市场,供应链与物流数据场景有望率先跑通.pdf
2024-10-10 15:09
引航咨询&运满满:2024年长三角光伏产业供应链物流洞察白皮书.pdf
2024-09-28 16:04
中国移动:车联网-物流-活鲜运输物联网解决方案.pdf
2024-09-27 15:54
2024年物流品牌25强.pdf
2024-09-07 16:28
智慧物流园区解决方案-菜鸟.pdf
2024-09-06 16:21
2024年日本仓储物流租户调研报告 -世邦魏理仕.pdf
2024-09-03 16:55
2024第二季度京津城市群物流报告 -仲量联行.pdf
2024-09-03 16:54
东方证券-达达集团首次覆盖报告:“物流+零售”双管齐下,高速成长,扭亏为盈曙光显现.pdf
2024-09-03 16:47
“四港”联动“一网智联”赋能物流降本 增效.pdf
2024-09-02 16:49
中国银河-交通运输行业中企出海专题研究:拥抱物流出海大时代,布局全球供应链体系.pdf
2024-08-30 17:46
华创证券-申通快递-002468-深度研究报告:大物流时代系列-25--量在“利”先的循环已经启动,“反内卷”下更有助于业绩弹性释放.pdf
2024-08-30 17:45
海伯高斯:2024工业机器人方向行业研究报告-物流机器人篇.pdf
2024-08-28 16:50
极智嘉&UPS:2024机器人技术赋能的第三方物流_零售履约的未来研究报告.pdf
2024-08-27 16:30
机器人技术赋能的第三方物流:零售履约的未来.pdf
2024-08-27 16:25
零排放货运行动(ZEFI):2024全球物流排放理事会物流排放核算与报告框架V3.0.pdf
2024-08-24 16:43
普华永道:2024年上半年中国物流行业并购活动回顾及趋势展望报告.pdf
2024-08-23 15:53
Cargowise:2024开创未来:拥抱物流业数字化转型报告.pdf
2024-08-18 17:26
2024跨境电商物流方兴未艾:布局海外仓需要注意的一些问题-物联云仓.pdf
2024-08-11 19:38
AIoT星图研究院:2024中国RFID无源物联网生态报告之快递物流应用市场分析报告.pdf
2024-08-10 17:03
物联云仓:2024跨境电商物流报告:百舸争流千帆竟,长风破浪正.pdf
2024-08-09 17:33

    • *

如需定制本赛道专属品牌洞察报告/商业决策尽职调查/赛道进入可行性研究/全渠道自媒体分发服务,加小助手微信号:tecdat_cn。