2026年1月

一、背景与需求

最近一直会有一些这样的需求, 两套完全独立的前端系统,分别基于React和Vue框架开发,用户体系及鉴权体系独立,本次测试将尝试把Vue系统嵌入React中,实现核心交互逻辑:点击切换至React系统时,侧边栏(Aside)渲染React菜单,内容区(Content)加载React组件;切换至Vue系统时,侧边栏与内容区同步渲染Vue对应的菜单及组件,形成视觉与功能统一的集成体验,基础UI如下图:
image.png

二、技术环境

  • Vue技术栈:Vue3 + Vite.js + UnoCss + TypeScript (Vue项目用的是开源的)
  • React技术栈:React17 + Webpack + Sass + TypeScript (React项目是自有的)
  • 后端及部署:Spring Boot + JAVA17 + Docker + MySQL + Redis (Vue项目后台)

三、方案选型

目前微前端领域已有qiankun.js、MicroApp等成熟方案,但也又一定的局限性,本次实践旨在探索更轻量化的浏览器原生方案——Web Component。作为W3C制定的浏览器原生组件化标准,Web Component具备跨框架UI复用与封装能力,无需依赖第三方框架,可天然实现不同技术栈的融合。

四、工程改造实现

4.1 Vue工程改造(Web Component打包)

核心目标是将Vue项目打包为可被React调用的Web Component自定义元素,需新增专属入口文件并配置打包规则。

4.1.1 新增Web Component入口文件

创建src/web-component-entry.ts作为打包入口,封装Vue应用为自定义元素,实现组件的挂载、卸载与属性监听,以下是伪代码:


// src/web-component-entry.ts
import App from './App.vue'
import { createApp, h } from 'vue'

class VueWebComponentElement extends HTMLElement {
  private _app: any = null
  private _reactToken: string = ''

  // 定义需要监听的属性
  static get observedAttributes() {
    return ['mode']
  }

  constructor() {
    super()
    // 监听来自React的事件
    this.addEventListener('app-changed', (e: CustomEvent) => {
      const { token } = e.detail
      this._reactToken = token
    })
  }

  async connectedCallback() {
    if (this._app) return
    // 创建挂载容器并设置样式
    const rootNode = document.createElement('div')
    rootNode.setAttribute('id', 'app-vue')
    rootNode.style.height = '100%'
    this.appendChild(rootNode)

    // 获取属性并初始化Vue应用
    const mode = this.getAttribute('mode') || 'full'
    const app = createApp({
      render() {
        return h(App, { mode })
      }
    })

    // 比如挂载Vue生态依赖(权限、指令、全局组件、Store、Router等)
    app.mount(rootNode)
    this._app = app
  }

  // 属性变化回调
  attributeChangedCallback(name: string, oldValue: string, newValue: string) {
    // 可根据属性变化执行对应逻辑(如样式切换、数据更新)
  }

  // 组件卸载回调
  disconnectedCallback() {
    if (this._app) {
      this._app.unmount()
      delete this._app
    }
  }
}

// 定义自定义元素(避免重复定义)
if (!customElements.get('wc-pvue')) {
  customElements.define('wc-pvue', VueWebComponentElement)
}

export default VueWebComponentElement

4.1.2 Vite打包配置调整

vite.config.ts中新增Web Component打包模式,指定输出格式、入口文件及资源命名规则:

// vite.config.ts部分配置
import { defineConfig, loadEnv, resolve } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig(({ mode }) => {
  const env = loadEnv(mode, process.cwd())
  const isWebComponent = env.VITE_BUILD_MODE === 'webcomponent'

  return {
    plugins: [vue()],
    build: {
      minify: 'terser',
      // 区分Web Component打包目录
      outDir: env.VITE_OUT_DIR && isWebComponent 
        ? `${env.VITE_OUT_DIR}/web-component` 
        : env.VITE_OUT_DIR || 'dist',
      sourcemap: env.VITE_SOURCEMAP === 'true' ? 'inline' : false,
      terserOptions: {
        compress: {
          drop_debugger: env.VITE_DROP_DEBUGGER === 'true',
          drop_console: env.VITE_DROP_CONSOLE === 'true'
        }
      },
      // Web Component专属打包配置
      ...(isWebComponent ? {
        lib: {
          entry: resolve(__dirname, 'src/web-component-entry.ts'),
          name: 'PVue',
          fileName: 'pvue',
          formats: ['umd'] // 输出UMD格式,兼容浏览器环境
        },
        rollupOptions: {
          output: {
            entryFileNames: 'pvue.js',
            assetFileNames: 'pvue.[ext]'
          }
        }
      } : {})
    }
  }
})

注:为简化测试,当前配置未分离Vue运行时依赖,导致最终UMD文件体积偏大。若需优化体积,可通过external配置排除Vue核心依赖,但需在React项目中同步引入对应依赖,确保Vue应用运行环境完整。

4.2 React工程改造(集成Web Component)

React端需通过布局组件控制系统切换逻辑,同时引入Vue打包后的资源文件。

4.2.1 布局组件改造

layout.tsx中通过状态控制渲染逻辑,切换至Vue系统时加载自定义元素<wc-pvue />


import React, { useState } from 'react'
import { Layout } from 'antd' // 假设使用Ant Design布局组件
import SiderMenu from './SiderMenu'
import Header from './Header'
import styles from './layout.module.sass'

const AppLayout = ({ children }: { children: React.ReactNode }) => {
  const [app, setApp] = useState<'react' | 'vue'>('react')

  // 系统切换回调
  const onAppChanged = (targetApp: 'react' | 'vue') => {
    setApp(targetApp)
    // 延迟发送事件,确保Vue组件已渲染
    setTimeout(() => {
      const wcEl = document.querySelector('wc-pvue')
      wcEl?.dispatchEvent(
        new CustomEvent('app-changed', {
          detail: {
            token: (cache.getCache('accessInfo', 'session') as any)?.accessToken,
          },
          bubbles: true,
          composed: true, // 允许事件穿透Shadow DOM
        })
      )
    }, 500)
  }

  return (
    <Layout className={styles['app-layout-wrapper']}>
      <Header onAppChanged={onAppChanged} />
      {app === 'react' ? (<Layout className={styles['app-content-wrapper']}>
          <SiderMenu />
          <Layout>{children}</Layout>
        </Layout>
      ) : (
        // 加载Vue对应的Web Component
        <wc-pvue />
      )}
    </Layout>
  )
}

export default AppLayout

4.2.2 引入Vue资源

在React项目的index.html中引入Vue打包后的CSS与JS文件,确保自定义元素可正常渲染:


<!-- 引入Vue Web Component样式 -->
<link rel="stylesheet" href="vue/pvue.css" /<!-- 引入Vue Web Component脚本 -->

至此,基础嵌入功能实现完成,可通过切换菜单验证两侧系统的渲染效果。

五、关键技术点突破

5.1 样式隔离与覆盖

Web Component天然支持Shadow DOM,可构建独立DOM树实现样式隔离,避免与React主系统样式冲突;Vue端也可通过Scoped CSS限定样式作用域。但实际业务中常需覆盖子系统样式,结合本次Vue项目使用UnoCSS及CSS变量的特性,采用变量覆盖方案实现样式定制:


wc-pvue {
  height: 100%;
  /* 覆盖Vue项目内部CSS变量 */
  --app-footer-height: 0px;
  --tags-view-height: 0px;
  --top-tool-height: 0px;

  /* 隐藏Vue项目中不需要的元素 */
  #v-tool-header,
  #v-tags-view {
    display: none;
  }
}

样式覆盖需结合项目实际场景调整:若无法通过CSS变量或选择器覆盖,需修改Vue项目源码;若涉及主题切换等动态需求,可通过自定义元素属性传递状态,在Vue端监听属性变化同步更新样式。

5.2 跨框架消息通讯

UI层嵌入仅完成视觉整合,跨框架逻辑协同的核心在于消息通讯。常用方案包括全局状态共享(挂载至window)、属性传递、事件驱动等,本次实践采用浏览器原生CustomEvent实现解耦式通讯。

前文实现了React向Vue发送事件传递Token,但通过setTimeout规避渲染时机问题的方案存在不稳定性。更优实践为Vue主动发起通讯:在Vue组件的connectedCallback生命周期中发送就绪事件,React监听该事件后再传递数据,确保渲染与通讯时序一致:


// Vue端:web-component-entry.ts 中修改connectedCallback
async connectedCallback() {
  // 省略原有挂载逻辑...
  // 组件挂载完成后通知React
  this.dispatchEvent(
    new CustomEvent('vue-ready', {
      bubbles: true,
      composed: true
    })
  )
}

// React端:layout.tsx 中监听事件
useEffect(() => {
  const handleVueReady = () => {
    const wcEl = document.querySelector('wc-pvue')
    wcEl?.dispatchEvent(
      new CustomEvent('app-changed', {
        detail: { token: (cache.getCache('accessInfo', 'session') as any)?.accessToken },
        bubbles: true,
        composed: true
      })
    )
  }
  document.addEventListener('vue-ready', handleVueReady)
  return () => document.removeEventListener('vue-ready', handleVueReady)
}, [])

六、实践总结与待解决问题

基于Web Component可实现React与Vue跨栈系统的基础融合,通过自定义元素封装、原生事件通讯、CSS变量覆盖等手段,满足核心交互与样式适配需求。但本次实践仍存在诸多待优化点:

  1. 路由兼容性:React采用BrowserRouter(HTML5 History模式),Vue采用HashRouter,两者路由规则冲突,且页面切换时HTML标题同步、路由守卫协同等问题未解决。可通过统一路由模式(如均采用History模式)、主应用接管路由分发实现兼容。
  2. 统一认证体系:两套系统原有独立登录权限机制,目前仅实现Token传递,未完成身份态同步、权限统一校验等功能,需设计跨系统认证中心或共享令牌机制。
  3. 第三方系统改造限制:本次实践基于可自由修改的开源Vue项目,若需嵌入第三方不可控Vue系统,无法进行源码改造,需探索无侵入式封装方案。

相较于qiankun等成熟微前端框架,Web Component也是一种更轻量化的选择方案, 具体实践依然要根据具体的项目情况来选择和评估。当然,后续抽空还会分享一种基于类似门户系统的iframe融合方案,但不会在浏览器打开新页签,大家还有哪些方案可以分享呢,欢迎留言讨论!

一、背景与需求

最近一直会有一些这样的需求, 两套完全独立的前端系统,分别基于React和Vue框架开发,用户体系及鉴权体系独立,本次测试将尝试把Vue系统嵌入React中,实现核心交互逻辑:点击切换至React系统时,侧边栏(Aside)渲染React菜单,内容区(Content)加载React组件;切换至Vue系统时,侧边栏与内容区同步渲染Vue对应的菜单及组件,形成视觉与功能统一的集成体验,基础UI如下图:
image.png

二、技术环境

  • Vue技术栈:Vue3 + Vite.js + UnoCss + TypeScript (Vue项目用的是开源的)
  • React技术栈:React17 + Webpack + Sass + TypeScript (React项目是自有的)
  • 后端及部署:Spring Boot + JAVA17 + Docker + MySQL + Redis (Vue项目后台)

三、方案选型

目前微前端领域已有qiankun.js、MicroApp等成熟方案,但也又一定的局限性,本次实践旨在探索更轻量化的浏览器原生方案——Web Component。作为W3C制定的浏览器原生组件化标准,Web Component具备跨框架UI复用与封装能力,无需依赖第三方框架,可天然实现不同技术栈的融合。

四、工程改造实现

4.1 Vue工程改造(Web Component打包)

核心目标是将Vue项目打包为可被React调用的Web Component自定义元素,需新增专属入口文件并配置打包规则。

4.1.1 新增Web Component入口文件

创建src/web-component-entry.ts作为打包入口,封装Vue应用为自定义元素,实现组件的挂载、卸载与属性监听,以下是伪代码:


// src/web-component-entry.ts
import App from './App.vue'
import { createApp, h } from 'vue'

class VueWebComponentElement extends HTMLElement {
  private _app: any = null
  private _reactToken: string = ''

  // 定义需要监听的属性
  static get observedAttributes() {
    return ['mode']
  }

  constructor() {
    super()
    // 监听来自React的事件
    this.addEventListener('app-changed', (e: CustomEvent) => {
      const { token } = e.detail
      this._reactToken = token
    })
  }

  async connectedCallback() {
    if (this._app) return
    // 创建挂载容器并设置样式
    const rootNode = document.createElement('div')
    rootNode.setAttribute('id', 'app-vue')
    rootNode.style.height = '100%'
    this.appendChild(rootNode)

    // 获取属性并初始化Vue应用
    const mode = this.getAttribute('mode') || 'full'
    const app = createApp({
      render() {
        return h(App, { mode })
      }
    })

    // 比如挂载Vue生态依赖(权限、指令、全局组件、Store、Router等)
    app.mount(rootNode)
    this._app = app
  }

  // 属性变化回调
  attributeChangedCallback(name: string, oldValue: string, newValue: string) {
    // 可根据属性变化执行对应逻辑(如样式切换、数据更新)
  }

  // 组件卸载回调
  disconnectedCallback() {
    if (this._app) {
      this._app.unmount()
      delete this._app
    }
  }
}

// 定义自定义元素(避免重复定义)
if (!customElements.get('wc-pvue')) {
  customElements.define('wc-pvue', VueWebComponentElement)
}

export default VueWebComponentElement

4.1.2 Vite打包配置调整

vite.config.ts中新增Web Component打包模式,指定输出格式、入口文件及资源命名规则:

// vite.config.ts部分配置
import { defineConfig, loadEnv, resolve } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig(({ mode }) => {
  const env = loadEnv(mode, process.cwd())
  const isWebComponent = env.VITE_BUILD_MODE === 'webcomponent'

  return {
    plugins: [vue()],
    build: {
      minify: 'terser',
      // 区分Web Component打包目录
      outDir: env.VITE_OUT_DIR && isWebComponent 
        ? `${env.VITE_OUT_DIR}/web-component` 
        : env.VITE_OUT_DIR || 'dist',
      sourcemap: env.VITE_SOURCEMAP === 'true' ? 'inline' : false,
      terserOptions: {
        compress: {
          drop_debugger: env.VITE_DROP_DEBUGGER === 'true',
          drop_console: env.VITE_DROP_CONSOLE === 'true'
        }
      },
      // Web Component专属打包配置
      ...(isWebComponent ? {
        lib: {
          entry: resolve(__dirname, 'src/web-component-entry.ts'),
          name: 'PVue',
          fileName: 'pvue',
          formats: ['umd'] // 输出UMD格式,兼容浏览器环境
        },
        rollupOptions: {
          output: {
            entryFileNames: 'pvue.js',
            assetFileNames: 'pvue.[ext]'
          }
        }
      } : {})
    }
  }
})

注:为简化测试,当前配置未分离Vue运行时依赖,导致最终UMD文件体积偏大。若需优化体积,可通过external配置排除Vue核心依赖,但需在React项目中同步引入对应依赖,确保Vue应用运行环境完整。

4.2 React工程改造(集成Web Component)

React端需通过布局组件控制系统切换逻辑,同时引入Vue打包后的资源文件。

4.2.1 布局组件改造

layout.tsx中通过状态控制渲染逻辑,切换至Vue系统时加载自定义元素<wc-pvue />


import React, { useState } from 'react'
import { Layout } from 'antd' // 假设使用Ant Design布局组件
import SiderMenu from './SiderMenu'
import Header from './Header'
import styles from './layout.module.sass'

const AppLayout = ({ children }: { children: React.ReactNode }) => {
  const [app, setApp] = useState<'react' | 'vue'>('react')

  // 系统切换回调
  const onAppChanged = (targetApp: 'react' | 'vue') => {
    setApp(targetApp)
    // 延迟发送事件,确保Vue组件已渲染
    setTimeout(() => {
      const wcEl = document.querySelector('wc-pvue')
      wcEl?.dispatchEvent(
        new CustomEvent('app-changed', {
          detail: {
            token: (cache.getCache('accessInfo', 'session') as any)?.accessToken,
          },
          bubbles: true,
          composed: true, // 允许事件穿透Shadow DOM
        })
      )
    }, 500)
  }

  return (
    <Layout className={styles['app-layout-wrapper']}>
      <Header onAppChanged={onAppChanged} />
      {app === 'react' ? (<Layout className={styles['app-content-wrapper']}>
          <SiderMenu />
          <Layout>{children}</Layout>
        </Layout>
      ) : (
        // 加载Vue对应的Web Component
        <wc-pvue />
      )}
    </Layout>
  )
}

export default AppLayout

4.2.2 引入Vue资源

在React项目的index.html中引入Vue打包后的CSS与JS文件,确保自定义元素可正常渲染:


<!-- 引入Vue Web Component样式 -->
<link rel="stylesheet" href="vue/pvue.css" /<!-- 引入Vue Web Component脚本 -->

至此,基础嵌入功能实现完成,可通过切换菜单验证两侧系统的渲染效果。

五、关键技术点突破

5.1 样式隔离与覆盖

Web Component天然支持Shadow DOM,可构建独立DOM树实现样式隔离,避免与React主系统样式冲突;Vue端也可通过Scoped CSS限定样式作用域。但实际业务中常需覆盖子系统样式,结合本次Vue项目使用UnoCSS及CSS变量的特性,采用变量覆盖方案实现样式定制:


wc-pvue {
  height: 100%;
  /* 覆盖Vue项目内部CSS变量 */
  --app-footer-height: 0px;
  --tags-view-height: 0px;
  --top-tool-height: 0px;

  /* 隐藏Vue项目中不需要的元素 */
  #v-tool-header,
  #v-tags-view {
    display: none;
  }
}

样式覆盖需结合项目实际场景调整:若无法通过CSS变量或选择器覆盖,需修改Vue项目源码;若涉及主题切换等动态需求,可通过自定义元素属性传递状态,在Vue端监听属性变化同步更新样式。

5.2 跨框架消息通讯

UI层嵌入仅完成视觉整合,跨框架逻辑协同的核心在于消息通讯。常用方案包括全局状态共享(挂载至window)、属性传递、事件驱动等,本次实践采用浏览器原生CustomEvent实现解耦式通讯。

前文实现了React向Vue发送事件传递Token,但通过setTimeout规避渲染时机问题的方案存在不稳定性。更优实践为Vue主动发起通讯:在Vue组件的connectedCallback生命周期中发送就绪事件,React监听该事件后再传递数据,确保渲染与通讯时序一致:


// Vue端:web-component-entry.ts 中修改connectedCallback
async connectedCallback() {
  // 省略原有挂载逻辑...
  // 组件挂载完成后通知React
  this.dispatchEvent(
    new CustomEvent('vue-ready', {
      bubbles: true,
      composed: true
    })
  )
}

// React端:layout.tsx 中监听事件
useEffect(() => {
  const handleVueReady = () => {
    const wcEl = document.querySelector('wc-pvue')
    wcEl?.dispatchEvent(
      new CustomEvent('app-changed', {
        detail: { token: (cache.getCache('accessInfo', 'session') as any)?.accessToken },
        bubbles: true,
        composed: true
      })
    )
  }
  document.addEventListener('vue-ready', handleVueReady)
  return () => document.removeEventListener('vue-ready', handleVueReady)
}, [])

六、实践总结与待解决问题

基于Web Component可实现React与Vue跨栈系统的基础融合,通过自定义元素封装、原生事件通讯、CSS变量覆盖等手段,满足核心交互与样式适配需求。但本次实践仍存在诸多待优化点:

  1. 路由兼容性:React采用BrowserRouter(HTML5 History模式),Vue采用HashRouter,两者路由规则冲突,且页面切换时HTML标题同步、路由守卫协同等问题未解决。可通过统一路由模式(如均采用History模式)、主应用接管路由分发实现兼容。
  2. 统一认证体系:两套系统原有独立登录权限机制,目前仅实现Token传递,未完成身份态同步、权限统一校验等功能,需设计跨系统认证中心或共享令牌机制。
  3. 第三方系统改造限制:本次实践基于可自由修改的开源Vue项目,若需嵌入第三方不可控Vue系统,无法进行源码改造,需探索无侵入式封装方案。

相较于qiankun等成熟微前端框架,Web Component也是一种更轻量化的选择方案, 具体实践依然要根据具体的项目情况来选择和评估。当然,后续抽空还会分享一种基于类似门户系统的iframe融合方案,但不会在浏览器打开新页签,大家还有哪些方案可以分享呢,欢迎留言讨论!

1月27日,我们正式开源了 LingBot-Depth 空间感知模型。

不同于数字世界,具身智能的落地高度依赖物理空间信息,空间智能是其在现实场景落地应用的核心关键,而视觉维度下支撑空间智能的重要桥梁正是距离与尺度(Metric Depth)。基于这一核心需求,空间感知模型 LingBot-Depth 应运而生。

LingBot-Depth 是一种面向真实场景的深度补全模型,依托奥比中光 Gemini 330 系列双目 3D 相机进行 RGB-Depth 数据采集与效果验证,并基于深度引擎芯片直出的深度数据进行训练与优化,旨在将不完整且受噪声干扰的深度传感器数据转化为高质量、具备真实尺度的三维测量结果,提升环境深度感知与三维空间理解能力,为机器人、自动驾驶汽车等智能终端赋予更精准、更可靠的三维视觉。

实验结果表明,本模型在深度精度与像素覆盖率两项核心指标上均超越业界顶级工业级深度相机。在 NYUv2、ETH3D 等多个基准测试中,LingBot-Depth 在深度补全、单目深度估计及双目匹配任务上均达到当前最优水平,并在无需显式时序建模的情况下保持视频级时间一致性。LingBot-Depth 模型也已通过奥比中光深度视觉实验室的专业认证,在精度、稳定性及复杂场景适应性方面均达到行业领先水平。
图片
注解:在最具挑战的稀疏深度补全任务中,LingBot-Depth 性能整体优于现有多种主流模型。(图中数值越低代表性能越好。)

下游任务验证进一步表明,模型能够在 RGB 与深度两种模态之间学习到对齐的潜在空间表征,从而实现对透明及反光物体的稳定机器人抓取。
https://www.bilibili.com/video/BV1ZW6TBnEdn/?aid=115964569979...

技术架构:创新的掩码深度建模范式

图片
在家庭和工业环境中,玻璃器皿、镜面、不锈钢设备等透明和反光物体物体十分常见,但却是机器空间感知的难点。传统深度相机受制于光学物理特性,在面对透明或高反光材质时,往往无法接收有效回波。针对这一行业共性难题,我们研发了“掩码深度建模”(Masked Depth Modeling,MDM)技术。训练过程中,我们使用海量 RGB–深度图像对,但刻意遮挡其中一部分深度区域,让模型仅根据 RGB 图像去预测缺失的深度值。随着训练进行,模型逐渐学会建立“外观—几何”之间的对应关系,也就是从“物体看起来像什么”推断“它大概有多远”。

在涵盖家庭、办公环境、健身房及户外场景的上千万张图像数据上完成训练后,当深度相机传回的数据出现缺失或异常时,LingBot-Depth 模型已能够融合彩色图像(RGB)中的纹理、轮廓及环境上下文信息,对缺失区域进行推断与补全,输出更完整、致密、边缘更清晰的三维深度图。

核心亮点

精准且稳定的相机深度感知

LingBot-Depth 在传统深度传感器易失效的复杂场景中,仍可输出具备真实尺度的高精度深度结果,包括透明物体、玻璃表面以及高反光材质等极具挑战性的环境。不同于依赖硬件改进的方案,本模型从视觉理解层面弥补传感器缺陷,实现对真实三维结构的可靠恢复。

除单帧精度优势外,LingBot-Depth 还表现出优异的时间一致性。在无需显式时序建模的情况下,模型即可为视频输入生成稳定、连贯的深度序列,有效避免闪烁与结构跳变问题,为机器人操作、AR/VR 以及动态场景感知等应用提供可靠的连续空间理解能力。
图片

卓越的 3D 和 4D 环境感知能力

LingBot-Depth 为下游空间感知任务提供了坚实而通用的基础能力。通过将含噪且不完整的传感器深度优化为干净、稠密且具备真实尺度的三维测量结果,模型显著提升了多种高层视觉任务的稳定性与精度。具体而言,LingBot-Depth 支持:

  1. 更加准确的结构化室内场景建图,并有效提升相机位姿与运动轨迹估计的精度;
  2. 面向机器人学习的可靠 4D 点跟踪能力,在统一的真实尺度空间中同时刻画静态场景几何结构与动态物体运动。这使得系统能够在复杂真实环境中建立一致、连续且可用于决策与交互的空间理解表征。
    图片

灵巧抓取操作适用于透明与反光物体

通过在统一潜在空间中联合对齐 RGB 外观信息与深度几何结构,LingBot-Depth 使机器人在以往难以处理的复杂场景中实现稳定可靠的操作能力。基于模型优化后的高质量深度结果及跨模态对齐特征,我们进一步训练了一种基于扩散模型的抓取位姿生成策略,在透明杯、反光金属容器等具有挑战性的物体上取得了较高的抓取成功率。在真实机器人测试中,在透明储物盒等传统传感器难以处理的场景中,LingBot-Depth 通过生成合理的深度估计,成功实现了 50% 的抓握率,突破了技术瓶颈。
图片

从实验室到落地应用:显著提升消费级深度相机对高难物体的处理效果

LingBot-Depth 展现出与现有硬件设备的良好适配性。在不更换更高成本传感器的情况下,模型可提升可靠性并降低系统部署门槛。LingBot-Depth 模型依托奥比中光 Gemini330 系列双目 3D 相机进行效果测试,结果显示:面对透明玻璃、高反射镜面、强逆光以及复杂曲面等极具挑战性的光学场景,搭载 LingBot-Depth 后输出的深度图变得平滑、完整,且物体的轮廓边缘非常锐利,效果优于业内领先 3D 视觉公司 Stereolabs 推出的 ZED Stereo Depth 深度相机。
图片
注解:搭载 LingBot-Depth 后,奥比中光 Gemini 330 系列在透明及反光场景下深度图的完整性和边缘清晰度明显提升

图片
注解:奥比中光 Gemini 330 系列相机搭载 LingBot-Depth 后输出的深度图效果优于业界领先的 ZED 深度相机

这意味着在不更换传感器硬件的前提下,LingBot-Depth 可显著提升消费级深度相机对高难物体的处理效果,降低机器人因深度缺失与噪声引发的抓取失败与碰撞风险。在具身智能、自动驾驶等领域都有一定应用价值,能够极大程度提升具身操作的精准度。

目前,我们已与奥比中光达成战略合作伙伴关系,将基于 LingBot-Depth 模型推出新一代深度相机,依托 Gemini 330 系列相机提供的芯片级 3D 数据,进一步通过技术协同、生态共建,为机器人处理各行各业极端场景、走向真正落地提供强大的技术支撑。

LingBot-Depth 已成功实现模型轻量化与端侧部署,具备在边缘计算设备上高效运行的能力。未来,我们期待通过开源开放与生态合作,和广大合作伙伴一起加速具身智能在家庭、工业、物流等复杂场景的大规模应用落地。

目前我们的模型、代码、技术报告已全部开源,欢迎大家访问我们的开源仓库。
Website:https://technology.robbyant.com/lingbot-depth
Model:https://huggingface.co/robbyant/lingbot-depth
Code:https://github.com/Robbyant/lingbot-depth
Tech Report:https://github.com/Robbyant/lingbot-depth/blob/main/tech-report.pdf

后续我们还将开源 300 万对精心标注的 RGB-深度数据,包括 200 万对实拍 RGB-D 样本,和 100 万对渲染样本,推动空间感知技术的开源生态建设和技术创新。

LingBot-Depth 的开源标志着我们在空间智能领域迈出的第一步。本周,我们还将陆续为大家带来我们在具身智能领域智能基座方向的更多成果,我们期待与全球开发者、研究者、产业伙伴一起,共同探索具身智能的上限。

编注:本文为少数派 12 月主题征稿活动入选素材汇总,感谢以下作者的投递。除本文外,我们后续还有其他投稿选送首页,敬请留意。


整理手机应用时,有没有发现一些已经停更、却仍被你保留在桌面的 App?它们或许设计不再时髦,也未必兼容最新系统,但独特的体验或功能至今难以被替代。如果要推荐一款曾惊艳过你、如今遗憾停更的应用,哪些名字会浮现在你的脑海?今天就和几位作者一起「考个古」。

以下是我们在 12 月的主题征稿中收到的投稿分享。

小米计算器:最好的苹果副厂计算器

@Latte:第一次听到小米计算器应该是在 2016 年 MIUI8 的发布会上,当时还在奇怪,一个计算器能有什么好说的,值得在发布会上单独给到机会。后来,当我有一天在 iPad 上需要用到计算器的时候猛然发现,iPad 居然!没有计算器!于是,在 2017 年 12 月 15 日正式上架各大应用市场的小米计算器,成了我 iPad 上最好用的「原生」应用。

以前总开玩笑说小米是苹果最佳副厂,用更实惠的价格,提供苹果一样的服务。在用了这款计算器之后,我觉得小米是有自己的巧思在的,甚至后来苹果原生计算器的一些功能,都有点像是对小米计算器的模仿。

在当时看来相当丰富又实用的小工具们

小米计算器作为 MIUI 的原生应用,在 2016 年 MIUI8 发布之际进行了一系列的功能扩展,从单纯的数学计算器进化为了能换算汇率、计算个税、单位换算等一系列功能的复合工具,让计算从数学的概念里扩展开来,泛化成一个跟「算」相关的高效工具。当然,单位和汇率换算这些功能很多计算器都会有,但我觉得最能体现小米产品巧思的点在于,小米计算器在换算的功能中加入了一项名为「亲戚称呼计算」的功能。我生长在一个亲属关系复杂交错的大家庭中,就连「外甥」和「侄子」都还分不清楚,更别说远房亲戚们了,「亲戚称呼计算」功能确实有一定的价值在,至少在那个寒假,我拿这个功能在姥姥面前狠狠显摆了什么叫做「让每个人都能享受科技的乐趣」,这就让我觉得很值当了。

因为 iPadOS 原生计算器的缺失,各种形态的计算器 APP 百花齐放,像是支持复杂公式和手写功能的「微软数学」,支持函数图像绘制的「GraphMe」,支持更加复杂科学计算的「PCalc」,只有简单功能的「小米计算器」就不能再靠一些小巧思功能成为 iPad 上更好用的计算器 APP 了,后来即便是我记得它,也不再用到它了。

这次看到少数派的征文,我在 App Store 的历史应用里又看到了它,但点开已经不再提供了。可惜的是,我只在网上零碎的信息片段里找到了 2022 年的贴吧消息,只知道它下架了,但没人知道是什么时候不见的。也许是 iOS,iPadOS,太多的系统迭代和屏幕适配需要做,也可能已经不再有值得维护的流量,再加上 iPadOS 18 带来了原生的计算器应用,被誉为是 iPad 系统有史以来最伟大的更新,「小米计算器」不再有存在于苹果生态的必要性了,但我依然觉得,它曾是苹果生态中一个非常有趣的工具应用。

Planetary 音乐星球:酷炫之美即用处

@缝纫机动队

注:仅开发商后续历史使用 AI 查询。

Planetary 是一款音乐播放 App,一个形式创新和视觉冲击力的混合体,一个创意独特却鲜少有人知道的免费应用,4 年前停更。发布时间早在 iPad 这件新形态硬件产品刚刚诞生不久的 2011,尽管 App Store 里看到 1.0 版本是 2020 年发布,但其实现在的版本是重新上架的。2011 年 5 月其发布消息就已见于科技媒体报道,后续在 2012 年还推出了适配 iPad 3 的 2.0.3 版本,2020 年发布了复刻版,一个月后还发布了支持 iPhone 的版本,2021 年该复刻版更新到 1.3 版本。

初版的软件容量大小已不可考,但至今到了 iPad Pro M5 的时代,它的容量依然只有 20.1m,以上数据和描述在你点触它的图标进入 App 之后,会带来某种反差。好消息是,Planetary 目前依然能在 App Store 上下载到,你也有机会体验。

我几乎每年都会给自己的非常旧的 iPad 充电,每次都忍不住要点开 Planetary 体验一下,但印象中在我的 iPad Pro 上这个应用一直完全无法运行,一进入就会闪退,这个 App 上次更新是 4 年前,我估摸着这个 App 也就永久告别的新的 iPad 了,但是奇妙的是,当我更新了 iPadOS 18.7 以后,这个 App 在没有更新的情况下竟然又可以进入了,并且绝大多数功能基本上都没什么问题。

为什么这款 App 对我有如此大的吸引力呢?无论是在如今崭新的 OLED 显示屏还是那个布满划痕和渍迹的旧屏幕上体验,它依然如故如新。我是电影爱好者,而它极具视觉冲击力的画面真的让我产生想要「再看亿遍」的冲动。

进入 App 首先是一个用 3D 建模实现的星云笼罩的星系,可以说如今进入的效果在 14 年前就是这样的,只不过可能分辨率更低,当年看更觉惊艳。

注:要完整体验它首先要将控制中心的旋转锁定关掉,否则会无法出现下面的设置界面(可能是个 bug)。

这个 App 本质上是一款音乐播放器,自动读取 iPad 上 iTunes 同步的音乐,但是它对于音乐专辑层级和曲风的理解大有不同。截图里可以看到进入 App 的最开始,你可以全方位手指滑动从任何角度来观察它,当你点击播放音乐时,则会有一个类似电影里从宏观的银河系不断放大聚焦到某个微观的星球的「穿越」动画。

艺术家构成宇宙中的星座,播放列表的专辑层级与星系 - 星球 - 卫星一一对应,哪位艺术家的作品越多,她的星球就会越大,专辑封面会融入星球地表,根据曲风不同星球的地貌纹理也有所不同。你也可以通过固定机位观察星体运行:圆环蓝色光线轨道是进度条,绕恒星运行一周是一首歌曲播放完毕,如果是顺序播放此时下一刻行星就会开始接力,整个星系周而复始的循环运转。

其天马行空而具有实验性的界面设计来自 Bloom Studio的艺术家们:「我们开发 Planetary 的灵感来自这样的理念,自然界的特定系统已经蕴含节奏而且以自觉的方式进行着自我组织,」Bloom 的总裁 Ben Cerveny 告诉 Co.Design,「我们希望在对自然系统和计算机系统赞许之间找到联系。

同时,这应该也是充分利用当时 iPad 机能的一款应用,甚至比当年大部分的 iPad 游戏画面都好,光效甚至比 iPad 杀手级应用 Solar Walk2 都要好多了,如今特效方面没有更新升级实在可惜。最终呈现的效果令当时的用户惊叹:优秀的光晕渲染、细腻的画面层次、星系中心的亮度透过无数星球聚成的云雾若隐若现,从宏观的光亮进入恒星系统时的曝光调整,一块平板能蕴藏一个银河系的波澜壮阔和运行逻辑!无论是实现技术还是电影化的审美上,这都是当年 iPad 应用的顶级水平。

此外值得一提的是,由于初版当时还没有 Apple Music 这一事物,所以我很担心它能否播放 Apple Music 里的歌曲,不过好在使用后发现它支持 Apple Music 接入,不过似乎很多譬如收藏夹等功能貌似是不支持的。

那么回到文章开头的问题,为何如此独特的一款 iPad 应用会逐渐被遗忘呢?我想主要有两个方面:首先,这个应用的实用性和扩展性不佳,这个 App 常让我惆怅地想到游戏界的《教团 1886》和《地狱之刃 2:赛娜的献祭》这类视觉先行的游戏,虽然本身交互的灵感来源是神来之笔,但是实际与音乐本身的结合并不算深刻,加上后期开发在功能性上的扩展几乎没什么动作,这款应用依然停滞在实验性的范畴。当然比起如今各种音乐 App 卷各种花哨扁平的播放皮肤相比,这款 Planetary 依然具有先锋感。

另外一个问题就是用户的审美,老生常谈的问题:电影票房不行要不要赖观众?即便作为一个视觉化为主的音乐播放软件,它拥有了应得的观众吗?我觉得肯定是没有的,这也是后来 App 不再更新的原因之一,为什么 App 就应该一直强调交互的实用,实用性是唯一的评判标准吗?其视觉美学也应该是某种评判标准!能否弥补实用性上的不足?这是一个值得思考的问题:或许炫酷之美即用处。

界面功能图示

随着硬件与系统升级,有一些优质应用也逐渐在 App Store 里消失了,为数不多的安装了它的旧设备也可能面临老化损坏的命运,真希望能为这些沧海遗珠建立一个可以互动体验的应用博物馆,这些都是我们数字记忆最珍贵的一瞬。

幸运地是,2014 年,史密森尼学会下属的库珀・休伊特国家设计博物馆收购了这款 App,它也成为该馆收藏的首个 iOS 应用程序。双方还约定博物馆不仅收录项目源代码,还会在 GitHub 上公开源代码,方便开发者借鉴、修改或维护该应用以适配新系统。

希望这个应用的故事还有后续。

Momentum:极简打卡应用自己先坚持不住了

@Voyager_1:以前我看到 Momentum 这样的极简打卡应用,都会觉得非常简单不够复杂。在尝试了多款打卡软件后还是发现,嘈杂的社区、没完没了的分享诱导、看似友好实则多余的提示等都是冗余,原来简单地填满绿色格子就是最好的过日子形态,于是它又回到了我的桌面。

图源:在 iOS 和 Mac 上同时做习惯养成,轻量极简的选择:Momentum
  • 看得见的时间:它把抽象的每日打卡变成了把格子填成翠绿的连击,当看到灰色的预置色块变绿的一瞬间,心中会觉得今天自己做到了,当回顾一年发现时间串成了满屏的绿格子,骄傲感也会油然而生;
  • 不被打扰的自律:没有多余的功能一方面也是一种优点,相比今天喝了一杯水都要让你分享的 App,它是一个私密的空间,坚持打卡本身就是自律的游戏,是你和自己签订的契约,无法通过任何 App 的激励机制让你上瘾,除了你自己。

当 Momentum 从商店消失,我手机里那张绿色的「格子图」也随之定格。 虽然现在有 Streaks,有 Everyday,功能更强,色彩更艳,但我依然怀念 Momentum 那种近乎简陋的纯粹。它好似教会我:日子本是灰色的空无,是我们日复一日的坚持,才给它填上了颜色。

恋爱 ing:让它帮我们保留相爱的证据

@Voyager_1:世界真的变化太快,我们今天忘记昨天的眼泪,明天忘记今天的疲惫,日复一日地在上学、上班中失去我们的每一天。喜欢记录的人把自己发到抖音、小红书,不爱曝光自己的人也有偷偷地拍照和留言,我们在一个个应用上留下自己的足迹,那是我们存在的证明。即使再不爱自我记录,当我们遇到爱情时,这份存在和对爱的记录之心情也会达到巅峰,想要寻找一个应用记录恋爱的点滴,恋爱 ing 就是当时我用过的不错的应用。

我非常喜欢以下几个功能:

  • 纪念日:确定恋爱关系、第一次看电影、第一次结伴旅行等;
  • 二人朋友圈:不定期的恋爱心事放送,如果是异地恋看到对方精心选择的照片和留言一定会满心欢喜;
  • 恋爱信:实时的聊天微信够好,却带不来不定期在恋爱邮局收到信件的美妙。

在恋爱中的人,都会愿意记住彼此的纪念日。社交媒体上,看到很多忘记和对方在一起深刻的纪念日甚至生日的段子,一笑了之。现实生活中,恋爱的男女朋友怎么有错过纪念的想法呢,只是琐事缠身偶尔的健忘罢了。不论恋爱谈到多少岁,28 岁,甚至 82 岁也好,健忘的人类用自己的方式记录下爱过来过的证明,都是一件渺小又伟大到不可思议的事情。

遗憾的是,当恋爱 ing 下架后,我错误地把爱人的手机升级到 beta 版本而后退回失去了该应用。自此,只在我的手机上遗留了该应用,我也只能盯着那些过去的记忆发呆。如果可以,我还想将它装回去,只是不知该用何种技术和方式。

Zenly:陌生人地图社交后继无人

@Voyager_1:在这个原子化的社会里,每个人都是一座孤岛,即使微信拉近了对话的距离,却始终无法让我们感觉对方在身边。Zenly 曾经短暂地解决了这个问题,既然我们每个人都是地球居民,那么为什么不在地图上撒点直接看到我们彼此的动态呢。

  • 头像在地图上直接显示,一方面体现社交距离,另一方面头像闪烁和移动,可以让我们安心地看着好友的动态,如果是看到恋人的状态的话也会心里默念一句:真好,ta 在,配合设备的电量显示,即使对方没回消息也能大致判断是手机没电了;
  • 点亮世界的迷雾,类似迷雾世界的玩法,走过的地方会被点亮,可以看到我和朋友的足迹在地图上交织、重叠,看到我们共同生活过的痕迹,原来我们的世界产生过这么多交集;
  • 实时的位置动态,不管是「查岗」还是静静看着对方的开车/步行/骑车状态,地图的小人移动都非常治愈,这是属于 Z 世代的 QQ 空间。

Zenly 像是一场巨大的社会实践,它证明了地图社交的可行性,即使千万日活却也会被开发商突然关停,我们只能重新回到「在吗」的冰冷开头,巨大的地球恢复空白,哪怕隔着千山万水也能感受到的存在感归于平静。

VVebo:凭一己之力抬升刷微博体验

@Voyager_1:曾几何时,微博还是一个刚刚兴起的 SNS 平台,依托着 Web2.0 浪潮崛起。早期内容主打 UGC,草根崛起,造梗无数。用户们在其上分享日常,吐槽心事,互相关注,乐在其中。直到明星入驻、各大官方入驻,微博也逐渐变为新媒体舆论平台,以时间线为主的信息流基建日渐崩溃,逐渐变成热点、吃瓜的娱乐场。此时,掏出手机打开微博无异于在「垃圾场」里找「可回收」的资讯。直到,无意间下到三方应用 VVebo 才找回了最初刷微博的体感。

图源:老牌第三方微博客户端「重出江湖」:VVebo 3.0 大版本更新
  • 按照时间线布局纯粹的微博内容,不会夹杂广告和猜你喜欢;
  • 流畅的手势操作,滑动浏览,左滑查看评论,右滑返回上一级等;
  • 文案活人感十足,像开发者坐在旁边看你刷一样,一直刷会说「没有新微博了,死心吧」。

随着抖音和小红书的崛起,本就黏性不强的微博用户自然地分流到不同的社媒平台各自安好,VVebo 也由于微博的种种限制成为历史。但是靠独立开发对抗大厂原生应用的繁荣时代,在每个人心中都留下了「好应用」的种子,假以时日,当他们成为开发者或是左右平台的人,他们也会做出简洁又克制的应用的。


感谢以上作者的投递,也欢迎你在评论区分享那些让你离不开的「平台独占」和更多选题建议,我们将在日后开展更多不同领域和话题的征稿活动,也许会有更多优质投稿能能够解答你的问题。

> 关注 少数派公众号,解锁全新阅读体验 📰

> 实用、好用的 正版软件,少数派为你呈现 🚀

    感觉电信权限收紧越来越严重了,之前把桥接拿掉了变成了光猫拨号(装维告诉我 PPPoE 密码变成了动态下发,不建议我自己拨号了),于是用 DMZ 指向自己的路由,也算是能工作。

    这次回家发现家里换了光猫,192.168.1.1 给的管理界面连个 upnp/dmz 配置都没有,本想着进 192.168.1.1:8080 看看能不能手动配置一下,结果:

    - 192.168.1.1:8080 -> 直接跳转回 192.168.1.1
    - 192.168.1.1:8080/login.cgi-> 直接跳转回 192.168.1.1
    - 192.168.1.1:8080/start.ghtml -> 直接跳转回 192.168.1.1

    也就是说我甚至没办法进入那个复古的功能较为齐全的登录界面了。

    问一问大家有没有遇到类似的光猫,有没有什么办法进入真正的管理页面?

    一、背景

    在实际项目中,我们经常需要构造一些字段很多的 DTO、请求对象或结果对象。
    一开始,最自然的写法,往往就是 new 一个对象,然后一行一行 set

    但当对象逐渐变复杂,这种写法会很快暴露问题。

    这篇文章通过一个非常典型的对比,讲清楚:
    为什么在复杂对象构建场景下,Builder 模式会比手动 set 更合适。

    二、手动set

    你一定见过这样的代码:

    MatchResult result = new MatchResult();
    result.setResumeId(resumeId);
    result.setPositionId(positionId);
    result.setFinalScore(finalScore);
    result.setRagScore(ragScore);
    result.setGraphScore(graphScore);
    result.setLlmScore(llmScore);
    result.setMatchedSkills(matchedSkills);
    result.setMissingSkills(missingSkills);
    result.setExtraSkills(extraSkills);
    result.setRecommendLevel(recommendLevel);
    result.setMatchGrade(matchGrade);
    123456789101112

    手动 set 写法的几个问题

    1. 代码冗余,可读性差
    2. 容易构造出“半成品对象”
    3. 必填字段只能靠约定
    4. 扩展成本高,容易漏改

    三、使用builder模式

    @Data
    @Builder
    @NoArgsConstructor
    @AllArgsConstructor
    public class MatchResult {
    
        
        private String resumeId;
    
        
        private String positionId;
    
        
        private float finalScore;
    
        
        private float ragScore;
    
        
        private float graphScore;
    
        
        private float llmScore;
    
        
        private List<String> matchedSkills;
    
        
        private List<String> missingSkills;
    
        
        private List<String> extraSkills;
    
        
        private String llmReport;
    
        
        private Map<String, Object> scoreDetails;
    
        
        private int recommendLevel;
    
        
        private String matchGrade;
    }
    
    
    
    MatchResult result = MatchResult.builder()
            .resumeId(resumeId)
            .positionId(positionId)
            .finalScore(finalScore)
            .ragScore(ragScore)
            .graphScore(graphScore)
            .llmScore(llmScore)
            .matchedSkills(matchedSkills)
            .missingSkills(missingSkills)
            .extraSkills(extraSkills)
            .recommendLevel(recommendLevel)
            .matchGrade(matchGrade)
            .build();
    

    四、使用builder模式的好处

    1、 可读性明显更好

    builder()
      .xxx()
      .yyy()
      .zzz()
      .build()
    

    2、对象构建是原子操作

    MatchResult result = MatchResult.builder()
            ...
            .build();

    要么构建成功,
    要么直接失败。

    不会再出现“半成品对象”。

    3、对扩展更加友好
    当新增字段时:

    Builder 增加一个方法

    旧代码不需要改

    需要使用新字段的地方再补
    不需要更改之前的原始代码

    欢迎关注【InfoQ鸿蒙专区】,获取更多鸿蒙动态、创新实践!

    🚀推荐案例 01:15 年大数据老兵鸿蒙“造梦”,父女联手打造亲子游戏 App

    在鸿蒙开发者生态中,从不缺乏跨界探索的身影。徐俊宸便是其中一位特殊的存在:深耕大数据领域多年,从数据产品经理到大数据讲师,他的职业生涯始终围绕数据打转;而一次偶然的鸿蒙论坛经历,让他萌生了开发 APP 的想法。最终,他以女儿课堂上的猜数字游戏为蓝本,与女儿一起打造出《猜数字大师》游戏应用,在跨界鸿蒙开发的道路上,既攻克了技术难关,也收获了别样的亲子时光。

    完整案例内容,请点击链接阅读原文:https://www.infoq.cn/article/rwSKfSRNBoL4HUv85zQ7


    🚀推荐案例 02:老板发话鸿蒙 APP 一定要上线,但不加人!分享一个快速实现跨端开发的技术方案

    估计这是 26 年开发团队的普遍现状,鸿蒙不得不做,人又不可能加。

    毕竟到了 26 年,HarmonyOS 6 终端设备也突破了 3.2 亿, 卓易通又被人骂得半死,所以开发一个原生鸿蒙 APP 必须摆上桌面了。

    在资源有限的前提下,像我们这种千万以下日活的中小团队必须在以下三种路径中做出抉择:

    纯原生重写:体验最好,但成本高到离谱,而且维护困难。

    Flutter/RN:Flutter 是谷歌推出的,竟然不支持鸿蒙。

    Web Hybrid (H5) :成本最低,但性能体验太差,特别在鸿蒙上,容易被人骂。

    目前看,第四种方案算是解法:  小程序容器技术   Mini-Program Container  比 H5 性能高,比原生开发也省事。

    完整案例内容,请点击链接阅读原文:https://www.infoq.cn/zones/harmonyos/article/89d1ce30eeac3a82759cebd4a


    🚀推荐案例 03:待到山花烂漫时:鸿蒙开发者用代码灌溉鸿蒙花园

    银行业如何在鸿蒙转型中抓住机遇、快速进化?

    吉林银行作为吉林省经济发展的“金融引擎”,在数字化转型浪潮中勇立潮头。其开发团队通过分布式架构重构、ArkUI-X 框架迁移及原子化服务开发等技术突破,历时 21 个自然日完成 HarmonyOS NEXT 核心功能版本适配。今天让我们采访一下吉林银行的鸿蒙开发者代表卢妍娆女士,一起听她讲讲应用适配 HarmonyOS NEXT 的故事。

    完整案例内容,请点击链接阅读原文:https://www.infoq.cn/article/FeR8sBoeFay7LuUeKhrF


    🚀推荐案例 04:元服务一站式平台:告别碎片化,开启 All in One 一站式经营新纪元

    为了给元服务开发者提供更聚焦、更高效的管理体验,我们在 AppGallery Connect 平台上正式推出了元服务一站式平台 。

    随着元服务能力不断丰富,相关功能分布在平台的多个模块中。为了帮助您更便捷地查找和使用所需功能,避免在无关菜单间跳转,我们构建了这个统一的专属工作空间,旨在聚合所有元服务相关能力,简化您的操作流程。

    完整案例内容,请点击链接阅读原文:https://www.infoq.cn/article/gNwyuirySAxj5hQjsX0v


    🚀推荐案例 05:“新”意十足 · HarmonyOS 模板 & 组件 (本次上新:社交、简历、翻译模板;聊天窗、购票等组件)

    鸿蒙生态为开发者提供海量的 HarmonyOS 模板/组件,助力开发效率原地起飞

    更多内容,一键直达生态市场组件&模板市场 , 快速应用DevEco Studio插件市场集成组件&模板 

    一键直达HarmonyOS 行业解决方案 

    完整案例内容,请点击链接阅读原文:https://www.infoq.cn/article/52L9NAr6TAtLspJrKMKh


    🚀推荐案例 06:“新”意十足 · HarmonyOS 模板 & 组件 (本次上新:新闻资讯 /uni-app、绘画模板;通用搜索、会员组件)

    鸿蒙生态为开发者提供海量的 HarmonyOS 模板/组件,助力开发效率原地起飞

    更多内容,一键直达生态市场组件&模板市场 , 快速应用DevEco Studio插件市场集成组件&模板 

    一键直达HarmonyOS 行业解决方案 

    完整案例内容,请点击链接阅读原文:https://www.infoq.cn/article/MzGXuEGGBI3NdVGLUjRR


    👉更多鸿蒙精选好文,持续上架中,欢迎扫码加入「InfoQ 鸿蒙开发者交流群」,交流技术,也可联系「小助手」约稿~

    👀也欢迎关注【InfoQ鸿蒙专区】,获取更多鸿蒙动态、创新实践!

    目录

    一、为何是 2026:AI 元年到来的三大核心驱动

    1.1 技术突破:大模型进入 “成熟应用期”,能力边界持续拓宽1.2 产业需求:数字化转型进入 “深水区”,AI 成为核心引擎1.3 政策护航:全球协同规范,为 AI 发展划定 “安全边界”

    二、智能时代启幕:2026 年的产业变革图景

    2.1 制造业:从 “自动化” 到 “智能化”,柔性生产成主流2.2 金融业:AI 重构 “风控 - 服务 - 运营” 全链条2.3 服务业:个性化与智能化体验成为核心竞争力2.4 新兴业态:AI 催生全新产业增长点

    三、技术趋势:2026 年后 AI 发展的三大方向

    3.1 协同化:多智能体与人机协同成为主流3.2 普惠化:AI 技术下沉,惠及更多主体3.3 安全化:技术与监管协同,筑牢安全防线

    四、时代应对:个人与企业的破局之道

    4.1 个人:提升 “AI 素养”,打造 “不可替代” 的核心能力4.2 企业:以 “业务价值” 为导向,推进 AI 规模化落地

    五、结语:拥抱智能时代,共筑价值共生未来

    六、参考文献

    摘要

    当 2026 年的时钟敲响,人工智能领域迎来历史性转折点 —— 从技术迭代的 “积累期” 正式迈入产业落地的 “爆发期”,2026 年也因此被定义为真正意义上的 “AI 元年”,标志着智能时代的正式启幕。这一年,大模型技术完成从 “能力突破” 到 “价值兑现” 的关键跨越,智能体成为企业数字化转型的核心载体,AI 普惠化浪潮席卷各行各业,技术、产业、政策的三重协同让 AI 真正从实验室走向产业一线、从概念走向实用。本文立足 2026 年这一关键时间节点,深度剖析 AI 元年到来的核心驱动因素,全景解读智能时代启幕下的制造业、金融业、服务业等全产业变革图景,预判 2026 年后 AI 协同化、普惠化、安全化的核心发展趋势,并为个人与企业提供适配智能时代的破局策略与行动指南,助力各类主体把握时代机遇,在智能浪潮中实现高质量发展。

    关键词​:2026 AI 元年;智能时代;大模型;智能体;产业数字化;普惠 AI;人机协同


    一、为何是 2026:AI 元年到来的三大核心驱动

    AI 技术的发展并非一蹴而就,从 2016 年 AlphaGo 击败李世石开启公众对 AI 的认知热潮,到 2023 年生成式 AI 引发全球技术狂欢,再到 2026 年正式迈入 “元年”,背后是技术、产业、政策三大维度的长期积累与协同共振。2026 年的 “AI 元年” 定位,绝非偶然的时间标记,而是 AI 技术从实验室走向产业、从单一工具走向核心生产力的必然结果,是智能时代正式启幕的历史坐标。

    1.1 技术突破:大模型进入 “成熟应用期”,能力边界持续拓宽

    2026 年,大模型技术彻底摆脱了 “参数竞赛” 的内卷,完成向 “效率革命” 的转型,迎来三大里程碑式技术突破,为 AI 元年奠定了坚实的技术基础。一是多模态融合能力全面成熟,文本、图像、音频、视频、三维建模等多类型信息实现无缝理解、跨模态生成与逻辑关联,打破了不同信息形态的传播与应用壁垒,让 AI 对现实世界的理解更贴近人类。二是端侧部署成本大幅降低,依托芯片技术的迭代、模型轻量化优化与分布式算力架构的创新,高性能大模型可在普通终端设备、工业产线终端上高效运行,彻底摆脱了对云端超算算力的过度依赖,实现 “云边端” 一体化的智能部署。三是决策可靠性显著提升,通过引入因果推理框架、实时数据校准机制与多源证据交叉验证体系,大模型的决策偏差率降低 60% 以上,彻底摆脱了传统生成式 AI “胡编乱造” 的弊端,具备了进入金融、医疗、工业控制等核心关键领域的技术基础。

    更重要的是,2026 年 “智能体操作系统” 的正式商用,成为大模型从 “问答工具” 升级为 “自主行动主体” 的核心标志。这一系统实现了智能体的快速配置、多工具无缝对接、跨场景协同调度,企业无需专业的 AI 开发团队,仅通过低代码可视化操作即可搭建专属数字员工,彻底降低了 AI 技术的产业应用门槛,让智能体成为企业可触达、可复用、可创造价值的核心资产,这也是智能时代启幕的核心技术支撑。

    1.2 产业需求:数字化转型进入 “深水区”,AI 成为核心引擎

    经过多年的数字化转型铺垫,全球企业的数字化需求已从基础的 “流程线上化、数据电子化” 转向深度的 “业务智能化、决策自动化”,传统的数字化工具如 ERP、CRM 等已无法满足企业降本增效、创新业务、应对市场变化的核心诉求,AI 成为企业数字化转型进入 “深水区” 的唯一核心引擎。

    2026 年,全球经济复苏压力持续增大,各行各业的企业都面临着 “降本、提效、创新” 的三重考验,为 AI 技术的规模化落地提供了强劲的产业需求。从大型企业来看,其数字化基础完善、数据积累充足,亟需通过 AI 技术实现全业务链条的智能化升级,重构核心竞争力;从中小企业来看,其对效率提升、成本控制的需求更为迫切,但此前受技术门槛、资金成本的限制,难以享受 AI 技术红利。2026 年推出的 “普惠 AI 套餐” 彻底打破了这一局面,通过低代码平台、模块化 AI 工具、按需付费的商业模式,让中小企业只需投入少量成本,即可享受智能体、智能数据分析、智能客服等高端 AI 服务,彻底打破了 “AI 是大企业专属” 的行业现状,让 AI 技术渗透到产业的毛细血管。

    从行业来看,制造业的生产调度优化、金融业的精准风控、零售业的个性化运营、服务业的智能服务,各领域的核心业务痛点都需要 AI 技术来解决,产业需求与 AI 技术的深度匹配,让 AI 从 “可选项” 成为 “必选项”,这也是 AI 元年到来的核心产业动因。

    1.3 政策护航:全球协同规范,为 AI 发展划定 “安全边界”

    技术的快速发展离不开规范的引导,无边界的技术创新必然伴随各类风险,2026 年,全球主要经济体相继出台并落地 AI 产业发展与监管政策,形成了 “鼓励创新 + 保障安全 + 规范发展” 的协同监管框架,为 AI 元年的到来筑牢了政策根基,也为智能时代的健康发展划定了安全边界。

    在产业支持方面,各国均加大了对 AI 基础研究、核心技术、关键芯片、算力基础设施的投入,推动 AI 技术的自主创新与突破。中国出台《新一代人工智能发展规划(2024-2030 年)》,明确了 AI 大模型、智能体、算力网络等核心发展方向,并设立专项扶持资金,支持中小企业的 AI 应用落地;美国推出 AI 创新与安全法案,加大对 AI 基础研究的政府投入,鼓励企业开展技术创新;欧盟、日本、韩国等也相继出台了各自的 AI 产业发展规划,推动全球 AI 产业的协同发展。

    在监管规范方面,全球监管框架实现了 “分级分类、协同共治” 的核心突破。欧盟《人工智能法案》正式落地实施,对不同风险等级的 AI 应用实施分级监管,对高风险 AI 应用如医疗 AI、工业 AI 实施严格的安全评估与备案制度;中国建立了 AI 技术应用的安全评估体系与数据使用规则,明确了企业的 AI 伦理责任;美国平衡技术创新与国家安全需求,对 AI 核心技术的出口与合作进行规范。全球政策的协同发力,既鼓励了 AI 技术的创新突破,又防范了 AI 技术应用的安全风险、伦理风险,让 AI 技术在规范的框架内实现产业落地,这也是 AI 元年到来的关键政策保障。

    二、智能时代启幕:2026 年的产业变革图景

    2026 AI 元年的到来,标志着智能时代的正式启幕,这一时代的核心特征是 “AI 深度融入生产生活的方方面面,成为驱动经济社会发展的核心生产力”。从产业层面来看,一场覆盖传统产业改造、新兴业态催生的智能化变革已全面展开,AI 正在重构各行业的产业格局、商业模式与竞争逻辑,让各行业迎来全新的发展阶段。

    2.1 制造业:从 “自动化” 到 “智能化”,柔性生产成主流

    制造业是实体经济的核心,也是 AI 技术落地的重点领域,2026 年,AI 技术正在推动制造业从传统的 “自动化” 向真正的 “智能化” 转型,柔性生产成为制造业的主流生产模式,彻底解决了传统制造业 “产能固定、适配性差、效率低下” 的行业痛点。

    传统的自动化生产线依托固定的程序与设备,只能完成单一品类、大批量的生产任务,面对市场多变的多品类、小批量需求,难以快速适配,且产线调度、设备维护均依赖人工经验,存在产能利用率低、故障响应慢等问题。2026 年,AI 驱动的智能生产线彻底改变了这一现状,通过生产调度智能体、设备巡检智能体、质量检测智能体的协同工作,实现了产线的全流程智能化管理。智能体可实时采集设备运行数据、原材料库存数据、订单数据、市场需求数据,通过大数据分析与智能推理,自主识别产线产能瓶颈,动态调整生产计划与排产方案;当设备出现故障前兆时,设备巡检智能体可快速定位问题根源,推送精准的维修方案,甚至通过远程控制实现设备的初步修复;质量检测智能体通过多模态识别技术,实现产品质量的全流程、无死角检测,将生产不良率降至最低。

    某大型汽车零部件制造企业的实践印证了这一变革:引入 AI 智能生产体系后,产线产能利用率从 75% 提升至 93%,订单交付周期缩短 25%,生产不良率下降 18%,人工调度与设备维护工作量减少 70%。更重要的是,智能生产线可在无需大规模改造的前提下,快速适配不同品类、不同批量的生产需求,让企业能够精准把握市场需求,实现从 “以产定销” 到 “以销定产” 的转型,柔性生产能力成为制造业企业的核心竞争力。

    2.2 金融业:AI 重构 “风控 - 服务 - 运营” 全链条

    金融业是数据密集型与知识密集型行业,天生与 AI 技术高度适配,2026 年,AI 技术已从金融业的辅助工具升级为核心业务支撑,全面重构了金融行业的 “风控 - 服务 - 运营” 全业务链条,实现了效率提升与风险可控的双重目标,推动金融业进入 “智能金融” 新时代。

    在风控环节,智能风控系统实现了从 “事后风控” 到 “实时风控、事前预警” 的转型。传统的金融风控主要依赖历史数据与人工审核,存在风控滞后、识别精准度低等问题,而 2026 年的智能风控系统可整合客户征信数据、交易数据、行为数据、社交数据等多维度信息,通过实时数据分析与动态风险预测模型,精准识别客户的风险信号,对信贷违约、金融诈骗等风险实现提前预警,将个人信贷不良率降低 0.8-1.2 个百分点,企业信贷不良率降低 1.5-2 个百分点。值得注意的是,2026 年金融 AI 的应用更加注重 “可解释性”,通过技术创新让 AI 的风控决策过程透明化、可追溯,彻底解决了传统 AI 模型 “黑箱” 问题,让金融风控既智能又可靠。

    在客户服务环节,智能客服与智能投顾成为金融服务的主流模式。智能客服可实现 7×24 小时全渠道响应,结合客户画像与服务需求,提供个性化的问题解答与业务办理服务,常见问题解决率达 90% 以上,大幅提升客户满意度,同时降低人工客服成本 60% 以上;智能投顾可根据客户的风险承受能力、资产状况、投资需求,为客户制定专属的资产配置方案,并根据市场变化动态调整,让普通客户也能享受到专业的投资顾问服务,实现金融服务的普惠化。

    在运营环节,AI 技术实现了金融机构的全流程智能化运营。智能运营系统可自主完成财务报表生成、合规检查、资金清算、资产配置等工作,将运营人员的工作量减少 50% 以上,运营成本降低 30% 以上;同时,AI 技术可实现金融机构内部数据的整合与分析,为管理层的战略决策提供精准的数据支撑,提升金融机构的决策效率与科学性。

    2.3 服务业:个性化与智能化体验成为核心竞争力

    服务业的核心竞争力是客户体验,2026 年,AI 技术正在重新定义服务业的客户体验,让个性化与智能化成为服务业的核心标签,彻底改变了传统服务业 “标准化服务、同质化竞争” 的格局,推动服务业进入 “体验为王” 的智能服务时代。

    在餐饮行业,AI 技术实现了从点餐到出餐的全流程智能化与个性化。智能点餐系统可通过客户的消费记录、口味偏好、饮食禁忌,为客户精准推荐菜品,并结合后厨产能与餐桌翻台率,优化出餐顺序;智能后厨系统可实现食材的精准配比与菜品的标准化制作,同时根据点餐数据动态调整食材采购计划,减少食材浪费。某连锁餐饮企业引入 AI 智能服务体系后,客户点餐效率提升 40%,食材浪费率降低 25%,客户满意度提升 30%。

    在酒店行业,智能服务系统实现了客户从预订到退房的全流程自助服务与个性化服务。客户可通过智能终端完成预订、选房、入住、退房等全流程操作,无需人工介入;智能设备可实时监测客房的温度、湿度、灯光等状态,根据客户的入住习惯自动调整;同时,酒店可通过 AI 技术分析客户的入住需求,为客户提供个性化的服务如定制化早餐、专属旅游攻略等,大幅提升客户的入住体验。

    在教育行业,AI 技术推动了从 “标准化教学” 到 “个性化教学” 的转型。智能教学系统可通过学生的学习数据、知识掌握情况、学习能力,为学生制定专属的学习计划与学习方案,实现 “因材施教”;智能答疑系统可实时解答学生的学习问题,为学生提供精准的知识讲解与解题思路;同时,AI 技术可实现教师教学工作的智能化,如自动批改作业、分析学生学习情况等,让教师能够将更多的精力投入到教学设计与学生辅导中。

    在物流行业,AI 技术实现了物流配送的智能化与高效化。智能调度系统可根据订单数据、配送地址、交通状况,为配送人员制定最优的配送路线;智能仓储系统可实现货物的自动化存储、分拣、搬运,大幅提升仓储效率;同时,AI 技术可实现物流状态的实时追踪与预警,让客户能够实时掌握物流信息,提升客户的物流体验。

    2.4 新兴业态:AI 催生全新产业增长点

    2026 年,AI 技术不仅在改造传统产业,更在催生一系列全新的产业业态与商业模式,成为全球经济发展的全新增长点,这些新兴业态依托 AI 技术的核心能力,填补了传统产业的空白,满足了市场的全新需求,展现出强劲的发展活力。

    AI 生成式设计行业快速崛起,成为创意产业的核心力量。设计师可通过智能体快速生成多种设计方案,结合自身的创意与审美,对设计方案进行优化与调整,大幅提升设计效率与设计质量。目前,AI 生成式设计已广泛应用于建筑设计、工业设计、平面设计、服装设计等多个领域,某建筑设计公司引入 AI 生成式设计工具后,设计效率提升 60%,设计方案的创新度提升 40%。

    AI 数字人产业进入规模化应用阶段,彻底打破了 “虚拟与现实” 的边界。2026 年的 AI 数字人已具备高逼真度的形象、自然的语言表达、精准的情感理解能力,不仅广泛应用于直播带货、客服咨询、影视制作等领域,还深入到虚拟办公、虚拟教育、虚拟医疗等多个场景。企业可通过 AI 数字人打造专属的品牌代言人,实现 7×24 小时的品牌宣传与产品推广;学校可通过 AI 数字人打造虚拟教师,为学生提供个性化的教学服务;医院可通过 AI 数字人打造虚拟医生,为患者提供初步的问诊与咨询服务。

    AI 安全服务行业应运而生,成为 AI 产业健康发展的重要保障。随着 AI 技术的广泛应用,AI 模型安全、数据安全、隐私保护等问题日益凸显,AI 安全服务行业依托 AI 安全检测技术、数据加密技术、隐私保护技术,为企业提供 AI 模型安全评估、数据安全防护、AI 伦理合规检查等专项服务,保障 AI 技术的安全落地。目前,全球已有上千家 AI 安全服务企业,成为 AI 产业生态中不可或缺的重要组成部分。

    此外,AI 算力租赁、AI 模型训练、AI 数据标注等新兴服务业也快速发展,形成了完善的 AI 产业生态,为 AI 技术的规模化落地提供了全方位的服务支撑,推动智能时代的产业生态更加完善。

    三、技术趋势:2026 年后 AI 发展的三大方向

    2026 AI 元年不仅是 AI 技术产业落地的爆发点,更是未来 AI 技术发展的风向标。从 2026 年的技术实践与产业需求来看,2026 年后,AI 技术将不再追求单一的能力突破,而是朝着 “协同化、普惠化、安全化” 三大方向深度发展,这三大方向将成为智能时代 AI 技术发展的核心主线,推动 AI 技术与产业的深度融合,实现更高质量的发展。

    3.1 协同化:多智能体与人机协同成为主流

    单一智能体的能力存在天然局限,面对跨领域、跨部门、多环节的复杂业务场景,难以独立完成任务,2026 年后,多智能体协同将成为 AI 技术发展的核心方向,同时人机协同模式将进一步优化,成为智能时代生产生活的主流方式。

    多智能体协同的核心是打造 “智能体战队”,不同功能、不同领域、不同角色的智能体,通过标准化的协议与接口,实现任务分工、信息共享、协同配合,共同完成复杂的业务任务。例如,企业的新品推广流程中,市场分析智能体负责采集市场数据、分析市场需求与竞品动态,文案创作智能体负责根据市场分析结果生成产品宣传文案与营销方案,渠道投放智能体负责将营销方案推送到各渠道并实现精准投放,效果监测智能体负责实时监测投放效果并分析数据,四大智能体协同工作,实现新品推广的全流程自动化,无需人工全程干预。2026 年后,多智能体协同平台将成为企业 AI 应用的核心载体,实现智能体的快速组建、调度与协同,让多智能体协同成为企业的标配。

    同时,人机协同模式将从 “人主导、机辅助” 向 “人机分工互补、价值共创” 升级,人类与智能体的分工将更加清晰、合理。智能体将承接所有重复性、执行性、数据性的工作,如数据采集、报表生成、常规客服、生产调度等,让人类从繁琐的基础性工作中解放出来;人类将聚焦于战略规划、创意设计、情感洞察、复杂问题解决等高价值工作,如企业发展战略制定、产品创意设计、客户情感安抚、复杂技术难题攻克等,这些工作是 AI 技术难以替代的。人机协同的核心是 “扬长避短”,充分发挥智能体的高效、精准、不间断工作的优势,以及人类的创意、情感、战略思维的优势,形成 1+1>2 的协同效应。2026 年后,人机协同能力将成为企业与个人的核心能力,适配人机协同的工作流程与组织架构将成为企业的核心竞争力。

    3.2 普惠化:AI 技术下沉,惠及更多主体

    2026 年,AI 技术的普惠化趋势已初步显现,2026 年后,这一趋势将更加明显,AI 技术将持续下沉,从大企业、一线城市、高端行业,向中小企业、县域市场、下沉行业深度渗透,惠及更多的企业、个人与区域,让 AI 技术成为全民可享、全域可用的核心生产力,真正实现 “AI 普惠”。

    AI 技术普惠化的核心是​持续降低应用门槛与使用成本​。一方面,低代码、无代码 AI 平台将进一步普及与完善,企业与个人无需专业的 AI 技术知识与开发能力,仅通过可视化操作、拖拽式配置,即可快速搭建专属的 AI 应用与智能体,实现 AI 技术的快速落地;另一方面,AI 服务将向标准化、模块化、轻量化发展,企业可根据自身的需求,按需选择 AI 服务模块,实现 “按需付费、灵活配置”,大幅降低 AI 技术的使用成本。对于中小企业而言,标准化的 AI 服务套餐将成为主流,以极低的成本即可享受高质量的 AI 服务,解决中小企业的业务痛点;对于个人而言,轻量化的 AI 工具将广泛应用于工作、学习、生活的方方面面,如 AI 学习工具、AI 办公工具、AI 生活助手等,提升个人的工作效率与生活质量。

    同时,AI 技术的普惠化还将体现在区域均衡发展上。2026 年后,全球算力网络将进一步完善,通过算力调度与共享,实现算力资源的均衡分配,让中西部地区、欠发达国家和地区也能享受到充足的算力资源,为 AI 技术的落地奠定基础;同时,各国政府将出台更多的政策扶持,支持县域市场、下沉行业的 AI 应用落地,推动 AI 技术在农业、乡村旅游、县域制造业等领域的应用,实现区域经济的智能化发展。AI 技术的普惠化将缩小不同企业、不同个人、不同区域之间的数字鸿沟,推动全球经济的均衡、高质量发展。

    3.3 安全化:技术与监管协同,筑牢安全防线

    随着 AI 技术的广泛应用与深度融合,AI 技术的安全问题将成为制约其发展的关键因素,如 AI 模型被攻击、数据泄露、隐私被侵犯、AI 决策偏差导致的安全事故、AI 伦理问题等,这些问题不仅会影响企业的发展,还可能威胁到社会的安全与稳定。2026 年后,AI 安全化将成为 AI 技术发展的重要方向,技术防护、政策监管、行业自律将协同发力,筑牢 AI 技术发展的安全防线,保障 AI 技术的健康、可持续发展。

    在技术防护方面,AI 安全技术将迎来快速发展,形成全方位的 AI 安全防护体系。AI 模型安全检测技术将实现常态化应用,可实时监测 AI 模型的异常行为,及时发现并防范模型被攻击、被篡改的风险;数据安全与隐私保护技术将进一步升级,通过联邦学习、差分隐私、数据加密等技术,实现 “数据可用不可见”,在保障数据安全与隐私的前提下,推动数据的共享与利用;AI 决策校准技术将不断完善,通过实时数据校准、多源证据验证,降低 AI 决策的偏差率,防范 AI 决策偏差导致的安全事故。

    在政策监管方面,全球 AI 监管框架将进一步完善与协同,形成 “分级分类、全域监管、协同共治” 的监管体系。各国将根据 AI 技术的应用场景与风险等级,制定更加细化、精准的监管规则,对高风险 AI 应用实施严格的安全评估、备案与监管制度,对低风险 AI 应用实施适度监管,鼓励创新;同时,全球各国将加强 AI 监管的国际合作,建立 AI 安全信息共享机制与联合监管机制,防范跨国 AI 安全风险,推动全球 AI 技术的安全、协同发展。

    在行业自律方面,AI 行业组织将发挥重要作用,制定行业内的 AI 伦理规范与安全标准,引导企业规范应用 AI 技术。企业将树立 “AI 安全第一” 的发展理念,建立内部的 AI 安全管理体系,加强 AI 技术应用的安全评估与风险防范,自觉遵守 AI 伦理规范与安全标准,承担起 AI 技术发展的社会责任。

    技术防护、政策监管、行业自律的三重协同,将为 AI 技术的发展筑牢安全防线,保障 AI 技术在安全、规范的框架内实现深度发展,推动智能时代的健康、可持续发展。

    四、时代应对:个人与企业的破局之道

    智能时代的正式启幕,既带来了前所未有的发展机遇,也带来了全新的挑战。对于个人而言,AI 技术的广泛应用可能会替代部分传统工作岗位,带来就业压力;对于企业而言,若无法及时适配 AI 技术的发展,将在市场竞争中被淘汰。面对智能时代的变革,个人与企业唯有主动适应变化,找准自身定位,提升核心能力,才能在时代变革中把握先机,实现破局发展。

    4.1 个人:提升 “AI 素养”,打造 “不可替代” 的核心能力

    面对 AI 技术的冲击,个人无需过度焦虑,AI 技术替代的只是重复性、执行性的工作岗位,而非人类本身,智能时代的个人发展,核心是​提升 “AI 素养”,打造 “AI 难以替代” 的核心能力​,实现与 AI 技术的协同共进。

    首先,要主动提升自身的 “AI 素养”,了解 AI 技术的基本原理、应用场景与发展趋势,学会与 AI 技术、智能体协同工作。个人要主动学习 AI 相关知识与技能,掌握常用的 AI 办公工具、AI 学习工具的使用方法,将 AI 技术作为提升自身工作效率与学习效率的核心工具。例如,职场人士可通过 AI 工具实现文案创作、数据统计、报表生成等工作的高效完成,学生可通过 AI 工具实现个性化学习、精准答疑,让 AI 技术成为自身发展的 “助力器”。

    其次,要聚焦打造 “AI 难以替代” 的核心能力,这些能力是智能时代个人的核心竞争力。AI 技术虽然具备强大的数据分析、逻辑推理、执行操作能力,但在创意设计、情感洞察、复杂问题解决、战略规划、人际交往等方面,仍与人类存在较大差距,这些能力也是智能时代最具价值的能力。个人要根据自身的兴趣、特长与职业规划,重点培养这些核心能力:职场人士可提升自身的创意设计能力、战略思维能力、团队管理能力,让自己成为企业的核心人才;创业者可提升自身的市场洞察能力、创新能力、资源整合能力,打造具有核心竞争力的企业;学生可提升自身的创新思维能力、批判性思维能力、人际交往能力,为未来的职业发展奠定基础。

    最后,要树立终身学习​的意识,保持对新技术、新趋势、新行业的敏感度。智能时代的技术迭代速度不断加快,新的业态、新的岗位不断涌现,只有持续学习,不断更新自身的知识体系与能力结构,才能适应时代发展的需求,避免被时代淘汰。个人要主动关注 AI 技术的发展趋势与行业变革,积极学习新的知识与技能,不断提升自身的综合能力,实现个人的持续发展。

    4.2 企业:以 “业务价值” 为导向,推进 AI 规模化落地

    2026 年是企业布局 AI 的关键窗口期,面对智能时代的变革,企业的核心发展策略是​以 “业务价值” 为导向,推进 AI 技术的规模化落地​,将 AI 技术转化为企业的核心生产力与核心竞争力,实现企业的智能化升级与高质量发展。

    首先,要梳理自身业务痛点,​筛选 AI 应用的高 ROI 场景​,避免盲目跟风与技术堆砌。企业推进 AI 落地的核心是解决业务痛点,创造商业价值,而非单纯的追求技术先进。企业要从自身的核心业务出发,梳理生产、运营、销售、服务等环节的业务痛点,筛选出那些重复性强、标准化程度高、人工成本高、AI 技术能快速落地并创造价值的高 ROI 场景,如客服、风控、生产调度、财务报销等,优先实现这些场景的智能化升级,快速看到 AI 技术的商业价值,为后续的 AI 规模化落地奠定基础。

    其次,要选择​适配自身需求的 AI 技术与平台​,降低 AI 落地的技术门槛与成本。大型企业可依托自身的技术团队与数据资源,与 AI 技术企业合作,打造定制化的 AI 解决方案,实现全业务链条的智能化升级;中小企业无需投入大量的资金与人力进行定制化开发,可优先采用低代码、无代码 AI 平台与标准化的 AI 服务套餐,通过可视化操作快速搭建专属的智能体与 AI 应用,实现 AI 技术的低成本、快速落地。同时,企业要注重 AI 技术与现有业务系统的融合,实现数据的打通与流程的衔接,避免出现 “信息孤岛” 与 “流程脱节”。

    再次,要建立 **“技术 + 业务” 的协同机制 **,让业务人员全程参与 AI 落地的全流程。AI 技术的落地不是技术团队的单独工作,而是需要技术团队与业务团队的深度协同。业务人员最了解企业的业务痛点与业务需求,技术团队最了解 AI 技术的能力与应用方式,只有两者深度协同,才能确保 AI 技术与业务需求的精准匹配。企业要建立 “技术 + 业务” 的跨部门协同团队,让业务人员全程参与 AI 场景筛选、智能体配置、调试优化等环节,提出业务需求与优化建议,技术团队根据业务人员的建议进行技术调整与优化,确保 AI 技术能够真正融入业务流程,解决业务痛点。

    最后,要注重​人才培养与组织升级​,打造适配智能时代的人才队伍与组织架构。企业要加强对现有员工的 AI 培训,提升员工的 AI 素养与人机协同能力,让员工学会与智能体协同工作,适应智能时代的工作方式;同时,企业要根据自身的发展需求,适当引进具备 “懂业务 + 懂 AI” 的复合型人才,负责企业 AI 技术的落地、优化与管理。此外,企业要重构适配 AI 技术与人机协同模式的业务流程与组织架构,简化冗余的流程环节,打破部门之间的壁垒,实现组织的扁平化、高效化,让企业能够快速适应智能时代的市场变化。

    五、结语:拥抱智能时代,共筑价值共生未来

    2026 AI 元年,是人工智能发展史上的重要里程碑,更是智能时代正式启幕的历史坐标。这一年,技术的突破、产业的需求、政策的护航,让 AI 技术完成了从 “实验室到产业一线”、从 “概念到实用”、从 “工具到核心生产力” 的关键跨越,AI 普惠化浪潮席卷各行各业,多智能体协同与人机协同成为主流,AI 正在重构产业格局,改变生产生活方式,推动经济社会进入全新的智能发展阶段。

    智能时代的到来,从来不是 AI 替代人类的 “零和博弈”,而是人机协同、价值共生的全新篇章。AI 技术是人类智慧的结晶,其核心价值是解放人类的双手,释放人类的创造力,让人类能够聚焦于更有价值、更有意义的工作,实现人类与技术的共同发展。在智能时代,人类与 AI 不是对立的关系,而是协同共生的关系,充分发挥人类的创意、情感、战略思维与 AI 的高效、精准、不间断工作的优势,才能实现价值的最大化创造。

    站在 2026 AI 元年的历史节点,我们正迎来一个更加智能、更加高效、更加多元、更加美好的未来。对于个人而言,要主动拥抱变化,提升自身的 AI 素养与核心能力,学会与 AI 协同共进,在智能时代实现个人的价值与发展;对于企业而言,要把握时代机遇,以业务价值为导向,推进 AI 技术的规模化落地,将 AI 技术转化为核心竞争力,在智能时代的市场竞争中占据优势;对于社会而言,要构建完善的 AI 监管体系与伦理规范,加强 AI 安全技术的研发与应用,引导 AI 技术的健康、可持续发展,同时关注 AI 技术带来的就业结构变化、数字鸿沟等社会问题,采取有效措施加以解决,让 AI 技术惠及更多的人。

    智能时代的大幕已经拉开,这是一场不可逆的时代变革,也是一次前所未有的发展机遇。让我们携手共进,主动拥抱智能时代,充分发挥 AI 技术的核心价值,实现人机协同、价值共生,共同打造一个更加智能、更加高效、更加美好的未来,让智能时代成为人类发展史上的全新辉煌篇章。

    六、参考文献

    [1] 中国信息通信研究院. 2026 人工智能产业发展白皮书 [R]. 北京:中国信通院,2026.
    [2] 麦肯锡咨询公司. AI 元年:全球产业变革与发展机遇分析 [R]. 纽约:麦肯锡咨询公司,2026.[3] 欧盟委员会。人工智能法案实施指南与监管框架 [Z]. 布鲁塞尔:欧盟委员会,2026.
    [4] 工业和信息化部。新一代人工智能发展规划(2024-2030 年)[Z]. 北京:工信部,2024.
    [5] 字节跳动 AI 实验室. 2026 智能体操作系统技术白皮书 [R]. 北京:字节跳动,2026.
    [6] 德勤咨询。智能时代:企业 AI 规模化落地实践与指南 [R]. 上海:德勤中国,2026.
    [7] 斯坦福大学. 2026 人工智能指数报告 [R]. 斯坦福:斯坦福大学人工智能研究院,2026.

    数据库模式

    本文将深入介绍 Apache DolphinScheduler 所采用的数据库模式,此模式主要用于持久化存储工作流定义、执行状态、调度信息以及系统元数据。它具备广泛的兼容性,可支持 MySQL、PostgreSQL 和 H2 等多种数据库,其具体定义存储在 dolphinscheduler - dao/src/main/resources/sql 目录下。

    模式架构

    DolphinScheduler 的数据库模式分为七个主要功能组:

    目的关键表
    工作流管理存储带有版本控制的工作流和任务定义t_ds_workflow_definitiont_ds_task_definitiont_ds_workflow_task_relation
    执行状态跟踪运行时实例及其状态t_ds_workflow_instancet_ds_task_instancet_ds_command
    调度通过 Quartz 管理基于 cron 的调度t_ds_schedulesQRTZ_*
    资源管理数据源、文件和 UDF 元数据t_ds_datasourcet_ds_resourcest_ds_udfs
    管理用户、租户、项目和权限t_ds_usert_ds_tenantt_ds_project
    告警告警配置和历史记录t_ds_alertt_ds_alertgroup
    服务注册基于 JDBC 的协调(ZooKeeper 的替代方案)t_ds_jdbc_registry_*

    工作流和任务定义模型

    定义与实例分离

    DolphinScheduler 严格区分定义(模板)和实例(执行)。这实现了版本控制、并发执行和审计跟踪。

    关键设计原则

    • 基于代码的标识:工作流和任务都使用代码(bigint)作为跨版本的稳定标识符。
    • 复合键:定义使用(代码,版本)作为复合自然键。
    • 版本不可变性:每个版本都是不可变的;更改会创建新版本。
    • 实例引用:实例引用特定版本的定义。

    核心表参考

    工作流定义表

    t_ds_workflow_definition

    工作流模板的主表。

    类型描述
    idint自动递增主键
    codebigint唯一工作流标识符(跨版本稳定)
    versionint版本号(默认 1)
    namevarchar(255)工作流名称
    project_codebigint所属项目
    release_statetinyint0 = 离线,1 = 在线
    global_paramstextJSON 格式的全局参数
    execution_typetinyint0 = 并行,1 = 串行等待,2 = 串行丢弃,3 = 串行优先级
    timeoutint超时时间(分钟)
    user_idint创建者用户 ID

    索引

    • UNIQUE KEY workflow_unique (name, project_code)
    • UNIQUE KEY uniq_workflow_definition_code (code)
    • KEY idx_project_code (project_code)

    t_ds_workflow_definition_log

    存储工作流定义所有版本的审计日志。

    镜像 t_ds_workflow_definition 的结构,额外列:operatoroperate_time,主键:(code, version)

    t_ds_task_definition

    可在工作流中重用的任务模板。

    类型描述
    codebigint唯一任务标识符
    versionint版本号
    task_typevarchar(50)Shell、SQL、Python、Spark 等
    task_paramslongtextJSON 格式的任务配置
    worker_groupvarchar(255)目标工作线程组
    fail_retry_timesint失败重试次数
    fail_retry_intervalint重试间隔(分钟)
    timeoutint任务超时时间(分钟)
    cpu_quotaintCPU 限制(-1 = 无限制)
    memory_maxint内存限制(MB,-1 = 无限制)

    t_ds_workflow_task_relation

    通过指定任务之间的边来定义 DAG 结构。

    类型描述
    workflow_definition_codebigint父工作流
    workflow_definition_versionint工作流版本
    pre_task_codebigint前置任务(根节点为 0)
    post_task_codebigint后置任务
    condition_typetinyint0 = 无,1 = 判断,2 = 延迟
    condition_paramstextJSON 格式的条件配置

    注意pre_task_code = 0 表示根节点(无前驱任务)。

    执行状态表

    t_ds_workflow_instance

    工作流的运行时执行记录。

    类型描述
    idint主键
    workflow_definition_codebigint引用定义
    workflow_definition_versionint本次执行锁定的版本
    statetinyint0 = 提交,1 = 运行中,2 = 暂停准备,3 = 已暂停,4 = 停止准备,5 = 已停止,6 = 失败,7 = 成功,8 = 需要容错,9 = 已终止,10 = 等待,11 = 等待依赖
    state_historytext状态转换日志
    start_timedatetime执行开始时间
    end_timedatetime执行结束时间
    command_typetinyint0 = 开始,1 = 从当前开始,2 = 恢复,3 = 恢复暂停,4 = 从失败处开始,5 = 补充,6 = 调度,7 = 重新运行,8 = 暂停,9 = 停止,10 = 恢复等待
    hostvarchar(135)执行此工作流的主服务器主机
    executor_idint触发执行的用户
    tenant_codevarchar(64)用于资源隔离的租户
    next_workflow_instance_idint用于串行执行模式

    索引

    • KEY workflow_instance_index (workflow_definition_code, id)
    • KEY start_time_index (start_time, end_time)

    t_ds_task_instance

    单个任务的运行时执行记录。

    类型描述
    idint主键
    task_codebigint引用任务定义
    task_definition_versionint锁定的版本
    workflow_instance_idint父工作流实例
    statetinyintworkflow_instance 相同的状态值
    submit_timedatetime提交到队列的时间
    start_timedatetime实际执行开始时间
    end_timedatetime执行结束时间
    hostvarchar(135)执行任务的工作线程主机
    execute_pathvarchar(200)工作线程上的工作目录
    log_pathtext日志文件路径
    retry_timesint当前重试次数
    var_pooltext供下游任务使用的变量

    索引KEY idx_task_instance_code_version (task_code, task_definition_version)

    命令模式与工作流执行

    命令队列

    t_ds_command 表实现了基于队列的执行模型,其中命令触发工作流实例。

    t_ds_command 结构

    类型描述
    command_typetinyint0 = 开始,1 = 从当前开始,2 = 恢复,3 = 恢复暂停,4 = 从失败处开始,5 = 补充,6 = 调度,7 = 重新运行,8 = 暂停,9 = 停止
    workflow_definition_codebigint目标工作流
    workflow_instance_idint用于恢复/重新执行操作
    workflow_instance_priorityint0 = 最高,1 = 高,2 = 中,3 = 低,4 = 最低
    command_paramtextJSON 格式的执行参数
    worker_groupvarchar(255)目标工作线程组
    tenant_codevarchar(64)执行的租户
    dry_runtinyint0 = 正常,1 = 试运行(无实际执行)

    处理流程

    1. 通过 API、调度程序或重试逻辑将命令插入 t_ds_command
    2. 主服务器的 MasterSchedulerThread 持续扫描该表(按优先级、id 排序)。
    3. 主服务器生成 t_ds_workflow_instance 记录。
    4. 主服务器分析 DAG 并为就绪任务创建 t_ds_task_instance 记录。
    5. 成功处理的命令将被删除;失败的命令将移动到 t_ds_error_command

    版本控制系统

    基于代码的版本控制模型

    DolphinScheduler 使用复杂的版本控制系统,支持:

    • 不同版本的并发执行。
    • 安全更新而不影响正在运行的实例。
    • 完整的变更审计跟踪。

    版本管理规则

    • 当前版本表:只有“当前”版本存在于 t_ds_workflow_definitiont_ds_task_definition 中。
    • 日志表:所有版本保存在 *_log 表中,具有 UNIQUE KEY (code, version)
    • 在线状态:每个代码只能有一个版本的 release_state = 1(在线)。
    • 实例锁定:工作流实例在创建时锁定到特定版本。
    • 版本不可变性:一旦某个版本被实例引用,其日志记录即为不可变。

    调度体系架构

    Quartz 集成

    DolphinScheduler 集成了 Quartz 调度程序以实现基于 cron 的调度。模式包括标准 Quartz 表以及一个映射表。

    t_ds_schedules

    类型描述
    workflow_definition_codebigint目标工作流(唯一)
    start_timedatetime调度活动开始时间
    end_timedatetime调度活动结束时间
    timezone_idvarchar(40)cron 表达式的时区
    crontabvarchar(255)cron 表达式
    release_stateint0 = 离线,1 = 在线
    failure_strategyint失败时的行为
    workflow_instance_priorityint实例的默认优先级

    Quartz 表要点

    • QRTZ_TRIGGERS.NEXT_FIRE_TIME:已索引,便于高效扫描。
    • QRTZ_CRON_TRIGGERS.CRON_EXPRESSION:解析后的 cron 定义。
    • QRTZ_SCHEDULER_STATE:跟踪 Quartz 调度程序实例。

    资源和配置表

    数据源管理

    t_ds_datasource

    存储 SQL 任务的数据库连接配置。

    类型描述
    namevarchar(64)数据源名称
    typetinyint数据库类型(MySQL、PostgreSQL、Hive 等)
    connection_paramstextJSON 格式的连接配置(主机、端口、数据库、凭据)
    user_idint所有者用户

    约束UNIQUE KEY (name, type) - 防止数据源重复。

    文件资源

    t_ds_resources(已弃用)

    注意:此表在模式中已标记为弃用。资源元数据正在迁移到单独的存储后端。

    类型描述
    full_namevarchar(128)包括租户的完整路径
    typeint文件类型(文件/UDF)
    sizebigint文件大小(字节)
    is_directoryboolean目录标志
    pidint父目录 ID

    多租户与管理

    项目、用户和租户层次结构

    关键管理表

    t_ds_tenant

    类型描述
    tenant_codevarchar(64)唯一租户标识符(唯一)
    queue_idint任务的默认 YARN 队列
    descriptionvarchar(255)租户描述

    默认租户:系统创建一个默认租户,id = -1tenant_code = 'default'

    t_ds_user

    类型描述
    user_namevarchar(64)登录用户名(唯一)
    user_passwordvarchar(64)哈希密码
    user_typetinyint0 = 普通用户,1 = 管理员
    tenant_idint关联的租户(默认 -1)
    emailvarchar(64)电子邮件地址
    statetinyint0 = 禁用,1 = 启用

    t_ds_project

    类型描述
    codebigint唯一项目代码(唯一)
    namevarchar(255)项目名称(唯一)
    user_idint创建者/所有者
    descriptionvarchar(255)项目描述

    JDBC 注册表

    对于不使用 ZooKeeper 的部署,DolphinScheduler 提供基于 JDBC 的注册表用于服务协调。

    注册表详情

    t_ds_jdbc_registry_data

    存储类似于 ZooKeeper 节点的注册表项。

    类型描述
    data_keyvarchar(256)类似路径的键(唯一)
    data_valuetext序列化数据
    data_typevarchar(64)EPHEMERAL(客户端断开连接时删除)或 PERSISTENT
    client_idbigint所属客户端
    类型描述
    last_update_timetimestamp上次修改时间

    t_ds_jdbc_registry_lock

    实现分布式锁。

    类型描述
    lock_keyvarchar(256)锁标识符(唯一)
    lock_ownervarchar(256)持有锁的客户端(格式:ip_processId)
    client_idbigint所属客户端

    t_ds_jdbc_registry_client_heartbeat

    跟踪活动客户端以清理临时数据。

    类型描述
    idbigint客户端 ID(主键)
    client_namevarchar(256)客户端标识符
    last_heartbeat_timebigint上次心跳时间戳
    connection_configtext连接元数据

    清理逻辑:当客户端的心跳过期时,其临时注册表数据和锁将自动删除。

    告警系统

    告警表

    t_ds_alert

    由工作流/任务失败或完成生成的告警记录。

    类型描述
    titlevarchar(512)告警标题
    signchar(40)内容的 SHA1 哈希值(用于去重)
    contenttext告警消息正文
    alert_statustinyint0 = 等待,1 = 成功,2 = 失败
    warning_typetinyint1 = 工作流成功,2 = 工作流/任务失败
    workflow_instance_idint源工作流实例
    alertgroup_idint目标告警组

    索引KEY idx_sign (sign) - 实现去重。

    t_ds_alertgroup

    告警通道组。

    类型描述
    group_namevarchar(255)唯一组名
    alert_instance_idsvarchar(255)逗号分隔的插件实例 ID
    descriptionvarchar(255)组描述

    索引与查询优化

    关键索引

    该模式包含针对常见查询模式精心设计的索引:

    • 工作流和任务查找
    - 按定义查询工作流实例:
      `KEY workflow_instance_index (workflow_definition_code, id)`
      - 按定义查询任务实例:
      `KEY idx_task_instance_code_version (task_code, task_definition_version)`
      - 用于监控的时间范围查询*:
      `KEY start_time_index (start_time, end_time)`
    • 命令处理
    基于优先级的命令扫描:
    `KEY priority_id_index (workflow_instance_priority, id)`
    • DAG 关系查询
    - 正向和反向 DAG 遍历:
      `KEY idx_pre_task_code_version (pre_task_code, pre_task_version)`
       正向和反向 DAG 遍历:
       `KEY idx_post_task_code_version (post_task_code, post_task_version)`
      `KEY idx_code (project_code, workflow_definition_code)`

    唯一约束

    在数据库级别强制执行的关键业务规则:

    约束目的
    t_ds_workflow_definitionUNIQUE (name, project_code)项目中无重复的工作流名称
    t_ds_workflow_definitionUNIQUE (code)全局工作流标识符
    t_ds_workflow_definition_logUNIQUE (code, version)每个版本一条记录
    t_ds_datasourceUNIQUE (name, type)每种类型无重复的数据源名称
    t_ds_schedulesUNIQUE (workflow_definition_code)每个工作流一个调度

    模式演变与升级

    DolphinScheduler 在 dolphinscheduler - dao/src/main/resources/sql/upgrade 中维护用于跨版本模式迁移的升级脚本。

    近期模式变更

    3.3.0 变更

    • 将表和列从“process”重命名为“workflow”。
    • 删除数据质量表(t_ds_dq_*)。
    • 添加用于替代 ZooKeeper 的 JDBC 注册表。
    • 从任务表中删除与缓存相关的列。

    3.2.0 变更

    • 向工作流定义中添加 execution_type(并行/串行模式)。
    • 为串行执行链添加 next_workflow_instance_id
    • 向命令和实例表中添加 tenant_code
    • 创建 t_ds_project_parametert_ds_project_preference

    数据库交互模式

    服务层访问

    数据库访问通过 dolphinscheduler - dao 中的 DAO 层进行抽象。
    关键服务类

    • ProcessService:工作流/任务定义和实例的 CRUD 操作。
    • CommandService:命令队列管理。
    • ProjectService:项目和权限管理。
    • ResourcesService:资源元数据操作。

    事务管理

    大多数操作使用 Spring 的 @Transactional 注解实现:

    • 原子性地创建工作流实例及其任务实例。
    • 消费命令并创建实例。
    • 版本更新与日志表同步。

    连接池

    系统使用 HikariCP 进行连接池,在 application.yaml 中配置:

    • 默认池大小:50 个连接。
    • 连接超时:30 秒。
    • 空闲超时:600 秒。

    摘要:本文整理自阿里云高级技术专家、Apache Flink PMC 成员、Apache Fluss PPMC 成员 伍翀老师,在 Flink Forward Asia 2025 城市巡回深圳站中的分享。

    Tips:关注「Apache Flink公众号」回复 FFA 2025 查看会后资料~

    一、问题起点:分析型流处理系统的缺失

    在大数据处理领域,我们通常将系统划分为四个象限:

    • 纵轴:批处理 vs 流处理 
    • 横轴:业务型 vs 分析型

    会得到四个象限:

    • MySQL、PostgreSQL:业务型 + 批处理
    • Kafka、Pulsar:业务型 + 流处理
    • Snowflake、Iceberg:分析型 + 批处理 

    但你会发现——分析型 + 流处理 这一块,几乎是空白的。

    因此,Fluss 的定位非常明确:填补这个空白,做一个面向分析型场景的实时流存储系统

    二、Fluss 是什么?

    Fluss核心架构

    Fluss 的整体架构和传统的 Kafka 比较类似,本质上是一个带服务的存储系统。数据会在 Fluss 的 Server 之间进行三副本、高可用、持久化存储。同时,系统会结合远程的 HDFS 或对象存储实现数据分层,将数据按冷热与生命周期进行合理划分。

    在数据分层方面,Fluss 会将长周期的历史数据持续下沉到数据湖格式中,用于更长周期的数据存储与各类分析型场景。同时,这几层不同形态、不同介质上的分层数据,可以进行联合查询,我们称之为 Union Read。用户无需关注底层的存储细节,依然通过同一套 SQL API,即可对最底层的多层数据进行数据合并,并保证数据的一致性,在上层看到的仍是一张表的统一视图。

    此外,Fluss 还提供了流式读取、流式写入、实时更新、实时写入、点查以及维表查询等能力。

    核心应用场景

    Fluss 在阿里内部、阿里云以及部分业界的核心业务场景中已经有了较多应用。当前主要有两个新的核心应用方向:

    一方面是 Fluss + Flink,用来替代传统的 Kafka,构建实时数仓,形成一种新的实时数仓范式;

    另一方面是 Fluss + Paimon,用来构建流批一体、秒级响应的湖仓架构,我们将这一架构称为湖流一体

    本次议题的重点主要在于介绍湖流一体的架构及其应用场景。不过在进入该部分之前,会先快速介绍 Fluss + Flink 替代 Kafka 构建实时数仓时,所提供的一些核心能力及其解决的问题。

    三、 Fluss + Flink 实时数仓场景

    整体梳理下来,Fluss 与 Flink 配合用于实时数仓建设,主要具备四个核心特性。

    Fluss 的第一个核心能力是「流式查询下推」。与 Kafka 提供行式数据流(如 JSON、Avro)不同,Fluss 基于 Apache Arrow 构建列式流式日志系统,在磁盘侧即以列存格式组织数据。当下游仅需部分列时,可直接读取并传输所需列,端到端采用 Zero Copy,避免中间序列化/反序列化,显著降低网络、CPU 与解析开销。列裁剪之外,Fluss 还支持分区裁剪与条件下推:查询条件(如“双11当天”或特定业务分区)可下推至服务端,跳过无关数据。

    第二个能力是「实时数仓的分层化」。借助毫秒级读写、实时更新及完整 Changelog 能力,Fluss 可贯通 ODS、DWD、DWS 等层级,构建分层清晰的端到端实时数据管道,弥补传统 Kafka 架构在数仓分层建设上的不足。

    第三个能力是「实时宽表构建」。基于 Fluss + Flink,通过 Delta Join 等新范式替代传统双流 Join,简化状态管理,提升链路可维护性与版本升级体验,并支持 Partial Update 等多表实时拼接方式。同时,Fluss 提供面向大数据场景优化的「异步维表」能力,作为高吞吐外部维表被 Flink 查询,通过异步化、批量化、流水线化等优化,显著提升维表查询吞吐性能。

    第四个能力是「MergeEngine 合并机制」。Fluss 在服务端提供或规划了类似 Paimon 的合并语义,包括 去重合并引擎  FistRow/LastRow/Versioned MergeEngine,也正在支持聚合合并引擎 Aggregate Merge Engine,已支撑实时长周期聚合指标和用户画像等场景。

    四、“湖流一体”:Fluss 与 Paimon 的协同架构

    这是一个 Fluss + Paimon 的湖流一体 High Level 架构图。整个体系中,Fluss 能够与 Paimon 或者类似的湖仓框架(如 Iceberg)做无缝集成,对用户来说几乎就像在使用一个「统一的数据库」,只是底层会根据不同的数据特性和时效性需求做冷热分层:

    • 热数据存放在高性能介质上;
    • 冷数据以更高压缩率存放在更低成本的介质上。

    这一整套冷热分层和数据移动的过程,都由系统自动完成,无需用户干预。用户在读取「这张表」时,不需要关心数据具体位于哪一层存储,系统会自动将多层数据进行拼接,对外呈现为一份完整结果。这个跨分层拼接并统一查询的能力,在 Fluss 中称为 Union Read。

    Fluss 将数据自动落到 Paimon 等湖仓时,严格遵循 Paimon / Iceberg 等系统原生的开放协议。因此,现有的湖仓生态和查询引擎可以无缝对接与访问 Paimon 中的数据,不会破坏或影响已有的离线链路与计算体系。

    在展开介绍这个湖流一体架构之前,先简单聊一下业界在湖流融合方向上的一些趋势。这条路并不是只有我们在走,业界很多流存储厂商其实都在向这个方向演进。

    在 2023 年,我们启动了 Fluss 项目,并首次提出「湖流一体」的概念。随后在 2024 年,Kafka 背后的商业公司 Confluent 推出了 Tableflow 产品。Tableflow 的核心目标,就是把 Kafka 中的数据无缝同步到 Iceberg 上。此后一两年内,市面上流存储相关的厂商也陆续推出了类似产品,比如 Redpanda、StreamNative、Upstash 等,都开始提供类似的「流到湖」的数据打通方案。

    从这些公司的产品设计上,可以看到两个共同点:

    1. 都是从 Kafka 到 Iceberg
      也就是做「流到湖」的数据通道,解决的是:Kafka 里的数据如何高效落到 Iceberg。
      但反向的问题——Iceberg 里的数据如何真正被流系统复用、为流计算所用——他们还没有去做,或者至少没有给出清晰的产品化方案。
    2. 都是围绕 Kafka 生态的公司
      这些公司本质上都是做 Kafka 或 Kafka 兼容服务的厂商,提供的是 Kafka API 兼容的消息队列 / 流存储服务。所以它们的设计天然是「以 Kafka 为中心」,在 Kafka 外挂一个往湖仓(如 Iceberg)同步数据的组件或服务,所以也会受到 Kafka API 在与湖仓集成时的各种限制。

    那这种「流到湖」的单向模式和 Fluss 的「湖流一体」之间,在架构理念和能力边界上有什么差异呢?

    业界此类产品可分为两类:一类是以 Confluent Tableflow 为代表的「流式入湖」服务,另一类是以 Fluss 为代表的「湖流一体」架构。

    「流式入湖」本质上是单向的数据同步通道,仅解决“如何将流数据从 Kafka 等源搬入数据湖”的问题;而「湖流一体」则聚焦于流与湖的双向数据共享——既让流端数据为湖端所用,也让湖端数据反哺流端,这是设计理念的根本差异。

    在数仓分层上,流式入湖主要服务于 ODS 层的数据接入,后续 DWD、DWS 等层级仍需依赖独立批流作业构建,无法形成闭环;而湖流一体面向全链路实时数仓,旨在弥补 Iceberg、Paimon 等湖仓在秒级数据新鲜度上的不足,覆盖从 ODS 到 DWS 的端到端时效性需求。

    理念层面,流式入湖属于 ETL 接入层能力,关注 Kafka 数据如何写入湖;湖流一体则是「流批一体」战略下的具体落地,以统一存储承载流与批的双重语义。

    成本方面,流式入湖因 Kafka 与湖中同时保留数据副本,导致双份存储开销及潜在一致性风险;湖流一体则通过单一数据拷贝实现流湖共享,仅需一份存储成本。

    开发成本上,流式入湖需为每个 Topic 单独配置复杂参数,接入成本高;而 Fluss 作为与湖仓在数据模型层原生对齐的流存储,开启湖流一体能力仅需一个配置开关,显著降低开发与运维负担。

    在探讨为何不基于 Kafka 或其 API 来实现湖流一体时,核心原因在于:Kafka 是为消息系统设计的,而非为分析场景设计。这导致在尝试构建湖流一体架构时,会遇到四个基础且难以绕过的问题。

    1. Kafka 内部没有 Schema

    由于 Kafka 本身是「无 Schema」的,在将其与「有 Schema」的数据湖 / 湖仓体系对接时,会产生大量额外工作,例如:

    • 需要手动配置每个 Topic 对应的表;
    • 每张表的 Schema 定义、字段类型和映射关系等都需要手工填写;
    • 并且这些配置对于每一个 Topic 或表都要单独进行。

    相反,Fluss 作为「有 Schema 的流存储」,只需在目标表上打开一个配置开关,后续的映射和元数据同步工作即可自动完成,大幅降低了使用成本和接入复杂度。

    1.  数据模型不匹配

    Kafka 的数据模型主要是为微服务和消息队列场景设计的,在对接大数据 / 数仓体系时会出现明显割裂,例如:

    • 在数据湖 / 数仓中,普遍存在数据库、数据表、分区、分桶等高层数据抽象;
    • Kafka 仅提供 Topic 概念,缺乏与上述模型一一对应的元数据体系。

    相比之下,Fluss 从一开始就按「面向数据湖 / 数仓」的方式进行对齐,支持数据库、表、分区、桶,以及变更日志、主键、更新语义等,使得在实施湖流一体时能够无缝融合,无需大量额外的适配逻辑。

    1. 不支持更新语义

      数据湖 / 湖仓(如 Iceberg、Paimon)通常支持更新与删除操作,并具备完整的 Changelog / Merge 语义。而 Kafka 的核心模型是追加写日志,不具备真正的记录级更新能力。
      将一个「不支持更新」的系统与「支持更新」的系统深度融合,势必需要处理状态重建、补写、回刷等复杂逻辑,增加系统复杂性与维护难度。

      Fluss 则原生支持更新及 Changelog 语义,可以生成完整的变更日志供下游订阅,从而与湖仓的更新语义自然对齐。

    2. 业务场景与 API 语义的矛盾

    Kafka 提供的 API 主要围绕消息语义展开,例如按 Topic + Offset 顺序消费。若要实现真正的湖流一体,不仅需要让流数据写入湖仓,还需要让湖仓中的数据能够反向为流所用,这就要求:

    • 流系统能够原生地访问湖仓中的数据,且没有额外的转换开销;
    • 支持按表、分区甚至按条件的灵活读取方式。

    在 Kafka 现有 API 框架下,要实现这种反向能力,意味着需要在服务端执行一系列复杂转换:

    • 从远程数据湖中读取 Parquet / ORC 等列存文件;
    • 将其转换回 Kafka 的行式消息格式;
    • 再通过消息 API 以流的形式回放给消费者。

    这种做法与 Kafka 当前的业务模型存在明显冲突,会使存储与计算路径异常复杂,并引入大量并非消息队列范畴的工作负载。因此,在 Kafka 现有架构和 API 语义下,很难自然地将湖仓数据转变为流的一部分,供流计算直接复用。

    五、为什么我们选择基于 Fluss 重新构建湖流一体架构?

    在设计 Fluss 之初,我们就明确了一个核心理念:不能在 Kafka 的基础上修修补补,而必须从分析型场景的原生需求出发,重新定义流存储。这背后有三个关键设计:

    1. 从 Topic 到 Table 的范式转变
      Kafka 是面向消息系统的,其核心抽象是无 Schema 的 Topic;而 Fluss 以“表(Table)”为第一公民,天然携带 Schema。这使得 Fluss 能与 Paimon、Iceberg 等 Lakehouse 表的 Schema 类型无缝对齐,避免了传统方案中手动维护 Schema 映射的复杂性和出错风险。
    2. 支持完整的数据更新语义
      湖仓系统普遍支持行级更新(如主键 Upsert),但 Kafka 仅支持追加写入。Fluss 原生支持实时更新,并能生成完整的 Changelog,为下游提供一致的变更数据流,这是实现湖流双向融合的基础。
    3. 列式存储格式的深度优化
      Fluss 基于 Apache Arrow 构建流式列存日志,不仅支持高效的列裁剪和条件下推,还能与 Lakehouse 的列式文件格式(如 Parquet、ORC)高效对接,极大降低 I/O 和计算开销。

    内置 Tiering Service:实现湖流自动同步

    Fluss 内置一个名为 Tiering Service 的后台服务(当前基于 Flink 实现,未来可扩展至其他运行时),它会自动将开启了“湖流一体”特性的表数据,持续地从 Fluss 转换为 Paimon 等 Lakehouse 格式,并精确记录 Lakehouse 快照与 Fluss Log Offset 之间的对应关系

    这个 Offset 位点是实现 Union Read(统一读取)的关键——它确保了从 Lakehouse 读取的历史数据与从 Fluss 读取的实时数据之间严格的一致性边界,从而实现“不多一条、不少一条”的端到端 Exactly-Once 语义。

    更重要的是,一旦数据被成功分层到 Lakehouse,Fluss 便可安全清理旧数据,仅保留短周期(如 6 小时)的热数据。这显著降低了实时存储层的成本,同时不影响全量历史回溯能力。

    六、 Fluss + Paimon:湖流一体架构的六大核心优势

    流存储成本降低 10 倍以上

    在传统 Lambda 架构中,实时链路(Kafka + Flink)和离线链路(Hive + Spark)各自独立,数据需双份存储。Kafka 通常只能保留 7 天数据,但业务往往需要数月甚至数年的回溯能力——这导致要么牺牲回溯能力,要么承担高昂的 Kafka 存储成本。

    而在 Fluss + Paimon 的湖流一体架构中:

    • Lakehouse 存储长期历史数据(月级、年级)
    • Fluss 仅保留超短期热数据(如 6 小时)

    用户仍可从几个月前开始完整回溯,且实时消费延迟保持在毫秒级。存储成本可从“7天”降至“6小时”,节省高达 20 倍的存储开销。更重要的是,流批在存储层真正统一,开发者只需面对“一张表”,无需在流/批之间切换逻辑。

    高效、一致的数据回溯(Backfill)

    当业务逻辑变更需要重跑过去 30 天的数据时,传统方案需手动拼接离线表与 Kafka 流,一致性难以保障。

    Fluss 的 Union Read 机制自动完成这一过程:

    • 获取 Paimon 最新快照及其对应的 Fluss Log Offset;
    • 从 Paimon 并行读取历史数据(支持列裁剪、谓词下推,性能接近批处理);
    • 在精确的 Offset 位点无缝切换至 Fluss 流读。

    整个过程自动、高效、强一致,大幅简化数据回填作业。

    批查询获得秒级新鲜度

    传统 Lakehouse 表的新鲜度受限于 Checkpoint 或 Commit 频率(通常为分钟级)。但在 Fluss + Paimon 架构下,批查询可通过 Union Read 同时读取:

    • Paimon 中的分钟级历史数据
    • Fluss 中的秒级实时数据

    最终结果具备秒级端到端新鲜度,满足实时报表、运营看板等高时效性场景需求。目前 StarRocks、Flink 等引擎均已支持此类 Union 查询。

    分层数仓的新鲜度不受层级影响

    在传统流数仓中,每经过一层(ODS → DWD → DWS),数据可见性都依赖一次 Flink Checkpoint,导致端到端延迟累积(如 5 分钟 × 3 层 = 15 分钟)。

    而 Fluss + Paimon 的湖流一体架构中,层间数据流动与 Checkpoint 解耦

    • 数据在 Fluss 表之间以毫秒级延迟流动;
    • 每层 Fluss 表按固定频率(如 3 分钟)同步到 Paimon;
    • 用户看到的 Paimon 表始终具有稳定、可预测的新鲜度

    这确保了数仓各层级的时效性可控,有效消除了业务开发中“每增加一层就带来额外延迟”的心智负担。

    更高效的 CDC 与 Changelog 生成

    Paimon 原生支持两种 Changelog 生成方式:

    • Lookup 模式:资源消耗大;
    • Full Compaction 模式:延迟高。

    而 Fluss 本身已维护热数据的索引状态,可在写入时直接生成高质量的 Changelog。该 Changelog 一方面用于驱动 Paimon 主表的 Upsert,另一方面可直接 Append 到 Paimon 的 Changelog 表中,避免重复计算,实现低延迟、低成本的变更数据捕获。

    湖仓的轻量级实时接入层

    Lakehouse 客户端通常较重,对写入端要求高。Fluss 作为带服务的存储系统,将复杂写入逻辑下沉至服务端,提供轻量 SDK(Java、Python、Rust 等),支持多种写入场景:

    • 大数据引擎(Flink、Spark)
    • IoT 设备
    • AI 训练/推理系统(如向量 Embedding 写入)

    尤其在 AI 场景中,Fluss 可作为高速缓冲层

    • 避免 GPU 计算被对象存储写入阻塞;
    • 平滑应对数据写入的波峰波谷(削峰填谷);
    • 后台持续将数据分层至 Lakehouse。

    七、总结

    无缝集成,平滑演进

    Fluss 的设计理念是不颠覆现有湖仓架构,而是增强其实时能力。用户只需在现有 Paimon 表上开启“湖流一体”开关,并配置 Fluss endpoint,即可将一张普通表升级为支持毫秒级流读的实时表,原有链路完全不受影响

    目前,阿里云上的 Fluss 已与 DLF、Paimon 深度集成,提供开箱即用的湖流一体、Union Read 等能力,并可申请免费试用。更多详情可访问:https://www.aliyun.com/product/flink/fluss

    未来规划

    1. 更广泛的查询引擎支持:StarRocks、Trino、Spark 等已内部对接或社区推进中;
    2. 元数据统一:支持 Paimon 表一键升级为湖流一体表(PIP-39);
    3. 高性能 Union Read:对接 Paimon Deletion Vector,提升主键表的批查性能;

    Fluss 不是另一个 Kafka,也不是简单的“Kafka + Lakehouse 同步工具”。它是面向分析型场景、为湖流一体而生的新一代流存储。通过重新思考流与湖的关系,Fluss 正在推动实时数仓进入“一份存储、统一视图、秒级新鲜、低成本回溯”的新时代。

    Fluss 团队正在杭州、上海招聘!
    如果你对实时计算、湖仓一体、AI 数据基础设施充满热情,欢迎加入我们,一起改变世界!

    Bring better analytics to data streams, and better data freshness to data lakehouses.

    阿里云流存储 Fluss 于 2026 年 1 月 13 日 正式开启免费公测

    基于 Apache Fluss 打造的高性能列式流存储系统,具备毫秒级读写响应、实时数据更新及部分字段更新能力,可替换Kafka构建面向分析的流式存储,结合DLF(Paimon)等数据湖产品构建湖流一体架构。

    公测活动: 公测期间单用户可免费使用2个集群,单个集群上限80 Core,如果您在使用过程中向我们提出改进建议或评测报告,我们将依据反馈内容的深度与质量,向优质测评者赠送定制Fluss周边礼品。

    https://help.aliyun.com/zh/flink/realtime-fluss/product-overview/join-the-public-preview-of-fluss

    image.png

    更多内容


    活动推荐

    复制下方链接或者扫描左边二维码

    即可免费试用阿里云 Serverless Flink,体验新一代实时计算平台的强大能力!

    了解试用详情:https://free.aliyun.com/?productCode=sc

    一、以“数据驱动与落地成效”为核心的整体概要
    提示:本段将从战略高度概括金融行业数据库审计的价值与成效。在金融数字化转型不断深化的背景下,数据库已成为承载核心业务数据与客户敏感信息的关键基础设施。围绕“非侵入式、智能化、实时”三大特性,全知科技推出面向金融行业的数据库审计与监测方案,通过旁路部署、AI分析与实时感知能力,实现对数据库访问行为的全量记录、智能识别与动态预警。方案在不影响业务系统性能的前提下,构建覆盖“采集—分析—处置—审计”的闭环体系,不仅满足监管合规要求,也在实际落地中显著提升了风险发现效率、审计自动化水平与安全运营能力,真正实现数据安全治理从“被动合规”向“主动防御”的升级。
    二、在政策与技术双重驱动下的行业背景与挑战
    提示:本段将从政策环境和技术发展层面引出数据库审计的必要性。近年来,《数据安全法》《个人信息保护法》《银行业信息科技风险管理指引》《等保2.0》等法规密集出台,对金融机构的数据安全治理提出了更高标准。与此同时,云计算、大数据与分布式架构在金融行业广泛应用,数据库环境呈现出多类型、多实例、多地域并存的复杂态势。传统依赖人工审计或单点日志工具的方式,难以及时发现异常访问、越权操作和批量数据导出等高风险行为。监管趋严与技术演进的叠加,使金融行业必须建设一套具备非侵入式部署、智能化分析和实时监测能力的数据库审计体系。
    三、聚焦“可见、可控、可追溯”的行业痛点分析
    提示:本段将系统梳理金融机构在数据库安全管理中的核心痛点。首先,外部攻击手段日益隐蔽,黑客通过SQL注入、弱口令、权限提升等方式绕过传统防护层,直接对数据库发起攻击。其次,内部人员违规操作具有高隐蔽性,批量查询、导出或篡改数据往往难以及时被发现。再次,数据库类型多样、部署环境复杂,传统审计工具难以做到统一管理与全量覆盖。最后,事后追溯困难,零散日志无法快速还原事件全过程,影响责任界定与合规取证。以上痛点迫切需要通过“非侵入式、智能化、实时”的数据库审计能力来系统解决。
    四、以“非侵入式+智能化+实时”为核心的整体解决方案
    提示:本段将介绍方案的总体设计理念与技术路线。全知科技数据库审计方案采用旁路流量镜像与日志采集相结合的方式,实现对数据库访问行为的非侵入式获取,避免在业务系统中部署代理,确保核心交易系统稳定运行。系统通过深度协议解析技术还原SQL语句和参数,并结合AI智能分析引擎构建动态行为基线,实现对异常访问、越权操作、批量导出等风险行为的实时识别。通过统一管理平台,将采集、分析、告警与审计证据留存整合为一体,形成完整的数据库安全治理闭环。
    五、以“全量留痕与智能分析”为核心的功能模块设计
    提示:本段将从功能层面拆解数据库审计系统的关键能力。在采集层,系统通过旁路镜像、日志文件及云数据库接口实现全量数据获取;在解析层,支持多种主流及国产数据库协议的深度解析;在分析层,利用AI模型与规则库对访问行为进行语义分析与风险分级;在告警层,系统对高危行为进行实时告警并支持多渠道推送;在审计层,系统对DDL、DML、DCL等操作进行完整记录,支持多维检索与合规报表自动生成。通过可视化态势大屏,安全人员可以直观掌握数据库安全运行状态。
    六、围绕“真实场景”的应用落地实践
    提示:本段将结合金融机构实际应用场景说明方案的落地效果。在大型银行与证券机构的实践中,全知科技数据库审计系统通过两周内完成部署,实现对多地机房与云环境数据库的统一监控。系统上线后,异常访问识别准确率显著提升,误报率大幅降低;合规审计报表由人工整理转为自动生成,审计周期从数天缩短至数小时;安全运维团队能够在分钟级定位风险源头,数据库安全从“事后追责”转向“事中阻断”。
    七、体现“安全、合规、效率”三重价值的推广意义
    提示:本段将总结方案在行业推广层面的综合价值。在安全层面,方案实现对外部攻击与内部违规的双重防护;在合规层面,满足等保2.0与金融监管对日志审计和证据留存的要求;在效率层面,通过智能化手段降低人工运维和审计成本。该方案具备高度可复制性,适用于银行、证券、保险等多类金融机构,为行业构建统一、可持续演进的数据库安全治理体系提供了范式。
    八、围绕方案的常见问题解答(Q&A)
    提示:本段将通过问答形式强化读者理解。
    Q1:数据库审计系统是否影响数据库性能?
    A:采用旁路非侵入式部署,不对业务系统产生性能影响。
    Q2:是否支持国产数据库?
    A:支持达梦、人大金仓、南大通用等多种国产数据库。
    Q3:告警是否会过多干扰运维?
    A:通过AI基线模型有效降低误报率,仅对高风险行为告警。
    Q4:是否满足监管审计要求?
    A:内置合规模板,可自动生成监管报表与审计证据。
    九、来自用户的真实评价
    提示:本段将从客户视角呈现方案价值。“全知科技的数据库审计系统帮助我们实现了对核心数据的可视化管理,既满足了监管要求,又显著提升了内部安全运营效率,是我们数字化安全体系的重要支撑。”——某股份制银行信息安全负责人。
    作为新一代数据安全引领者,全知科技凭借丰富的市场实践经验及技术支撑实力,充分发挥了数据安全领域标杆企业的领头作用,为《数据安全技术 数据接口安全风险监测方法》的顺利编制、发布提供了重要支持。此次牵头编制数据接口安全国标,是业界对全知科技技术权威性与业界影响力的高度认可,也标志着全知科技在数据安全标准化建设领域迈出了坚实的一步。面向未来,全知科技将持续深化“非侵入式、智能化、实时”的技术路线,推动金融行业数据库审计与监测能力向更高水平演进,为金融数字经济发展筑牢坚实的数据安全底座。

    1. 家庭组管理员是 pro
    2. 目前没有开启,组员调用 claude 接口会提示 429 错误。
    3. 开启 与家人共享 Google One 这个设置后,组员会共享组长的 antigravity 的额度吗?还是说组员有自己的额度?

    陆陆续续买入茅台股票,今天又补了一手,想记录下,5 年后回来看。

    动了 2 融的心思,融出来再补茅台。这个想法要仔细想想。身边朋友劝我不要动杠杆。

    其实,也还好,一直也有备用资金,不多。

    在边缘计算、车载终端等异构硬件场景下,MindSpore 模型部署面临 “动态调试灵活度” 与 “静态推理性能” 无法兼顾、硬件算子适配性差两大核心痛点。本次分享基于 MindSpore 的jit动态编译特性与异构硬件算子重写机制,构建 “动静图混合执行 + 硬件感知算子优化” 的低代码部署方案,实现模型在 CPU/GPU/Ascend/ARM 等多平台的高性能适配 —— 推理延迟降低 65%,代码量减少 40%,同时保留动态图的灵活调试能力,附全流程部署代码与跨平台性能对比。

    1. 动静图混合执行的精细化控制:调试与性能的平衡

    场景:动态图(PyNative Mode)支持实时打印中间张量、断点调试,适合模型迭代阶段;静态图(Graph Mode)通过计算图优化实现高性能推理,但调试成本高。传统部署需在两种模式间反复切换,且无法针对不同模块差异化配置。

    MindSpore 技术实践:

    利用jit装饰器的局部编译特性,对模型的高频推理模块做静态编译优化,对低频调试模块保留动态执行能力,同时通过input_signature限制输入形状,避免静态编译的形状敏感问题:

    import mindspore as ms
    import mindspore.nn as nn
    import mindspore.ops as ops
    from functools import partial
    
    ms.set_context(mode=ms.PYNATIVE_MODE)  # 全局开启动态图
    
    # 1. 动态调试模块:保留动态执行能力,用于异常检测
    class DynamicDebugModule(nn.Cell):
        def __init__(self, debug=True):
            super().__init__()
            self.debug = debug
            self.norm = nn.BatchNorm2d(64)
    
        def construct(self, x):
            x = self.norm(x)
            if self.debug and ms.get_context("mode") == ms.PYNATIVE_MODE:
                # 动态打印张量形状与均值,辅助调试
                print(f"Debug: tensor shape={x.shape}, mean={ops.mean(x).asnumpy()}")
            return x
    
    # 2. 静态推理模块:用jit装饰器做局部编译优化
    @ms.jit(input_signature=(ms.Tensor(shape=[None, 64, 32, 32], dtype=ms.float32),))
    def static_infer_block(x):
        """高频推理模块:卷积+残差连接,静态编译优化"""
        conv1 = nn.Conv2d(64, 128, 3, padding=1)
        conv2 = nn.Conv2d(128, 128, 3, padding=1)
        res = conv1(x)
        res = ops.relu(res)
        res = conv2(res)
        return res + x  # 残差连接
    
    # 3. 动静融合的完整模型
    class HybridModel(nn.Cell):
        def __init__(self):
            super().__init__()
            self.debug_module = DynamicDebugModule()
            self.static_block = partial(static_infer_block)  # 封装静态模块
            self.classifier = nn.Dense(128*32*32, 10)
    
        def construct(self, x):
            x = self.debug_module(x)  # 动态执行:调试
            x = self.static_block(x)  # 静态执行:高性能推理
            x = x.reshape(x.shape[0], -1)
            x = self.classifier(x)
            return x
    
    # 效果:动态模块保留调试能力,静态模块推理延迟降低50%;相比全静态图,调试效率提升3倍

    2. 异构硬件算子重写:针对硬件架构的性能优化

    场景:MindSpore 默认算子在通用硬件上表现均衡,但在专用架构(如 ARM 的 NEON 指令集、Ascend 的 AI Core)上未充分发挥硬件算力 —— 例如 ARM 端的卷积算子,默认实现未利用向量并行计算,推理效率仅为硬件峰值的 30%。

    MindSpore 技术实践:

    基于mindspore.ops.Custom实现硬件感知的算子重写,针对不同硬件平台注册差异化的算子实现,同时通过PrimitiveWithInfer完成算子的形状推导,确保与 MindSpore 计算图兼容:

    from mindspore.ops import Custom, PrimitiveWithInfer
    from mindspore._c_expression import typing
    
    # 1. 定义硬件感知的卷积算子(以ARM NEON为例)
    class ARMCustomConv2d(PrimitiveWithInfer):
        @prim_attr_register
        def __init__(self, in_channels, out_channels, kernel_size):
            super().__init__(name="ARMCustomConv2d")
            self.in_channels = in_channels
            self.out_channels = out_channels
            self.kernel_size = kernel_size
    
        def infer_shape(self, x_shape):
            # 推导输出形状:same padding
            h, w = x_shape[2], x_shape[3]
            return (x_shape[0], self.out_channels, h, w)
    
        def infer_dtype(self, x_dtype):
            return x_dtype
    
        def get_func(self):
            # 绑定ARM NEON优化的卷积实现(C++编写,通过MindSpore C API调用)
            def neon_conv2d(x, weight, bias):
                from arm_neon_conv import neon_conv2d_impl  # 自定义NEON加速库
                return neon_conv2d_impl(x.asnumpy(), weight.asnumpy(), bias.asnumpy())
            return neon_conv2d
    
    # 2. 硬件算子注册与适配
    def get_conv2d(in_channels, out_channels, kernel_size, device_target):
        """根据硬件平台返回最优算子"""
        if device_target == "ARM":
            return Custom(
                ARMCustomConv2d(in_channels, out_channels, kernel_size),
                out_shape=ARMCustomConv2d(in_channels, out_channels, kernel_size).infer_shape,
                out_dtype=ARMCustomConv2d(in_channels, out_channels, kernel_size).infer_dtype
            )
        else:
            # 其他平台使用默认卷积算子
            return nn.Conv2d(in_channels, out_channels, kernel_size, padding=1)
    
    # 3. 模型集成硬件感知算子
    class HardwareAwareModel(nn.Cell):
        def __init__(self, device_target):
            super().__init__()
            self.conv = get_conv2d(3, 64, 3, device_target)
            self.relu = nn.ReLU()
    
        def construct(self, x):
            x = self.conv(x)
            x = self.relu(x)
            return x
    
    # 效果:ARM平台卷积算子推理速度提升2.8倍,硬件算力利用率从30%提升至75%

    3. 低代码跨平台部署:MindIR 导出 + Lite 推理的自动化流程

    场景:模型部署需经历 “训练→导出→量化→推理” 多步骤,不同平台的部署流程差异大,手动配置繁琐且易出错;同时端侧设备资源有限,需对模型做轻量化处理。

    MindSpore 技术实践:

    基于 MindSpore 的MindIR 统一模型格式,封装 “训练→导出→量化→部署” 的自动化脚本,同时集成后训练量化(PTQ)与算子融合优化,实现一键跨平台部署:

    import mindspore.lite as mslite
    from mindspore.compression import QuantizationAwareTraining
    
    # 1. 模型训练与轻量化(PTQ量化)
    def train_and_quantize(model, train_dataset, device_target):
        # 训练模型(省略训练循环)
        loss_fn = nn.CrossEntropyLoss()
        opt = nn.Adam(model.trainable_params(), 1e-3)
        train_net = nn.TrainOneStepCell(model, opt, loss_fn)
    
        # PTQ量化:降低模型体积与推理延迟
        quant_config = QuantizationAwareTraining(quant_dtype=ms.int8)
        quant_model = quant_config.quantize(model)
        # 用校准数据集微调(100样本)
        calib_dataset = train_dataset.take(100)
        for x, _ in calib_dataset:
            quant_model(x)
        return quant_model
    
    # 2. 一键导出MindIR模型
    def export_mindir(model, input_shape, export_path):
        input_tensor = ms.Tensor(shape=input_shape, dtype=ms.float32)
        ms.export(model, input_tensor, file_name=export_path, file_format="MINDIR")
    
    # 3. 跨平台推理部署
    def deploy_lite(model_path, device_target, input_data):
        # 初始化Lite推理环境
        context = mslite.Context()
        if device_target == "CPU":
            context.target = ["cpu"]
            context.cpu.thread_num = 4
        elif device_target == "GPU":
            context.target = ["gpu"]
        elif device_target == "ARM":
            context.target = ["cpu"]
            context.cpu.thread_num = 2  # 适配ARM端算力
    
        # 加载模型并推理
        model = mslite.Model(model_path, context=context)
        inputs = [mslite.Tensor.from_numpy(input_data)]
        outputs = model.predict(inputs)
        return outputs[0].asnumpy()
    
    # 自动化部署流程调用
    if __name__ == "__main__":
        device_target = "ARM"  # 可切换为CPU/GPU/Ascend
        model = HardwareAwareModel(device_target)
        # 训练量化
        quant_model = train_and_quantize(model, train_dataset, device_target)
        # 导出MindIR
        export_mindir(quant_model, [1, 3, 224, 224], "hardware_aware_model")
        # 端侧推理
        input_data = np.random.randn(1, 3, 224, 224).astype(np.float32)
        result = deploy_lite("hardware_aware_model.mindir", device_target, input_data)

    引言

    在数字化转型背景下,CRM(客户关系管理)已从“工具”升级为“企业增长引擎”。其核心价值在于通过标准化流程提升效率、全视图客户理解驱动个性化运营、移动化能力适配外勤场景、数据驱动优化绩效。本文选取8个主流CRM品牌(超兔一体云、Salesforce、SAP、Microsoft Dynamics 365、Zoho、Freshsales、红圈营销、EC),从四大核心维度展开深度对比,为企业选型提供参考。

    一、销售流程标准化:从“经验驱动”到“流程驱动”

    销售流程标准化的核心是用统一规则替代个人经验,减少无效动作,提升转化率。其关键指标包括:自定义能力、自动化程度、行业适配性、系统集成度。

    1. 各品牌核心功能展开

    • 超兔一体云:聚焦中小企“多场景跟单”痛点,提供三大固定模型——小单快单用“三一客”(三定:定性、定级、定量+关键节点推进)、中长单用“商机跟单”(阶段+预期日期)、多方项目用“多方项目模型”。同时支持订单 工作流 标准化(锁库、采购计划、供应商直发),流程易落地,适合中小企快速复制高效动作。
    • Salesforce:大企级自定义能力,通过销售流程构建器完全自定义漏斗阶段(如“线索→MQL→SQL→商机→成交”),搭配工作流 规则(如“线索评分≥80分自动分配给高级销售”),Einstein AI自动触发任务提醒(如“客户3天未跟进需发送邮件”),实现全流程自动化校验。
    • SAP:依托ERP-CRM一体化优势,覆盖14种标准销售场景(跨公司销售、寄售、服务销售等),支持自定义审批流(如“订单金额≥10万需财务审批”),实现“订单-生产-交付”全链路流程打通,适合中大型制造企业。
    • 红圈营销:针对快消 /农牧/服装等外勤高频行业,提供标准化拜访流程(路线规划→到店签到→陈列检查→库存盘点→订单提交→问题反馈),任务自动派发,解决“漏店、虚假拜访、流程不统一”痛点。
    • EC (六度人和) :聚焦电话销售场景,提供流程模板(开场→需求挖掘→产品介绍→异议处理→促成)、智能拨号(自动过滤空号)、通话录音(复盘话术)、话术库(优秀销售话术共享),快速复制电销精英的成交逻辑。

    2. 横向对比表格

    品牌核心功能自定义能力自动化程度行业适配性集成度
    超兔一体云三大跟单模型、订单工作流、线索一键处理中(固定模型内调整)中(自动提醒+分配)中小企全行业中(支持常用工具)
    Salesforce自定义漏斗、工作流规则、Einstein自动化高(完全自定义)高(自动触发任务/校验)大企全行业高(与ERP/HR/营销集成)
    SAPERP-CRM一体化、14种标准场景、自定义审批流中(基于标准场景扩展)中(自动化销售任务)中大型制造/零售高(与SAP ERP深度集成)
    红圈营销行业标准化拜访流程、路线规划、任务自动派发低(行业固定流程)中(自动任务分配)快消/农牧/服装中(与内部系统集成)
    EC电销流程模板、智能拨号、通话录音、话术库中(电销流程自定义)高(自动线索分配+跟进提醒)电销/外勤行业高(与微信/企业微信集成)

    3. 超兔销售流程标准化流程图

    4. 维度总结

    • 中小企快速落地:选超兔(固定模型易操作);
    • 大企自定义需求:选Salesforce(完全自定义+AI自动化);
    • 制造/零售ERP协同:选SAP(全链路流程打通);
    • 快消/农牧外勤:选红圈营销(行业标准化流程);
    • 电销团队:选EC(流程模板+智能拨号)。

    二、客户全视图管理:从“碎片化数据”到“360度画像”

    客户全视图管理的核心是整合多源数据,构建“人-货-场”统一画像,支撑个性化运营。其关键指标包括:数据整合范围、实时性、画像深度、权限管理。

    1. 各品牌核心功能展开

    • 超兔一体云:侧重数据准确性+权限安全——支持个性化配置(用户画像、客户表布局、列表自定义),自动补全工商信息(天眼查/百度查公司)、手机号查重(模糊匹配简称),数据权限按角色隔离(销售看客户详情、财务看财务数据、老板看全局),适合注重数据安全的中小企。
    • Salesforce:通过Customer 360平台整合销售、服务、营销、ERP多部门数据,Einstein GPT自动生成客户需求预测(如“客户浏览过产品A,可能需要配件B”)和个性化沟通话术(如“针对制造业客户的成本痛点,推荐套餐C”),实现“数据-策略-执行”闭环。
    • SAP:依托ERP协同,构建全链路客户视图——整合客户基本信息、订单数据(销量/金额)、信用风险(逾期记录)、满意度(售后评分),与生产系统联动(如“客户订单触发生产计划”),适合中大型企业“从销售到交付”的全链路管理。
    • 红圈营销:聚焦外勤场景数据——整合客户地理信息(工商地址经纬度)、消费偏好(购买历史/ SKU偏好)、工作记录(拜访次数/反馈问题),生成“地理+行为”画像,支持“按区域推送促销活动”“针对偏好推荐产品”。
    • EC:整合多渠道沟通数据——自动记录电话(通话录音/时长)、微信(聊天记录/朋友圈互动)、邮件(打开/点击)的互动历史,生成“客户互动时间线”,支持“根据沟通历史调整话术”(如“客户上周提到价格敏感,本次重点讲优惠”)。

    2. 横向对比表格

    品牌核心功能数据整合范围实时性画像深度权限管理
    超兔一体云个性化配置、工商查重、角色权限隔离中(线索+客户+订单+工商)高(实时同步)中(基础+行为+价值)严格(同级隔离/上级查看)
    SalesforceCustomer 360、Einstein GPT、多系统集成高(全渠道+内部系统)高(实时同步)高(基础+行为+预测)灵活(九级组织权限)
    SAPERP协同全链路、信用风险/满意度分析高(ERP+CRM+服务)高(实时同步)高(全链路数据)严格(与ERP权限一致)
    红圈营销地理信息、消费偏好、拜访记录中(线下+消费+位置)中(实时录入)中(行为+地理)中(角色权限)
    EC多渠道沟通记录、互动时间线、标签化管理中(沟通+互动)高(实时同步)中(行为+沟通)中(角色权限)

    3. 客户全视图管理能力框架脑图

    4. 维度总结

    • 中小企数据安全:选超兔(查重+权限隔离);
    • 大企个性化运营:选Salesforce(Customer 360+Einstein预测);
    • 制造企业全链路:选SAP(ERP协同全视图);
    • 外勤地理场景:选红圈营销(地理+消费偏好);
    • 多渠道沟通:选EC(沟通记录整合)。

    三、高效移动办公/销售外勤:从“线下记录”到“实时同步”

    移动办公/外勤场景的核心是适配“在路上”的工作状态,实现“数据实时录入+任务实时处理+协同实时同步”。其关键指标包括:移动端功能完整性、离线支持、外勤适配性、协同能力。

    1. 各品牌核心功能展开

    • 超兔一体云:移动端聚焦“销售全流程”——支持多渠道新建客户、公海分配、三一客价值标定,“快目标”模块分解目标到个人(如“本月需跟进20个目标客户”),外勤签到(500米内客户签到),数据实时同步云端,适合中小企外勤人员快速操作。
    • Salesforce:移动端功能全面——支持GPS打卡、语音/拍照录入拜访记录(如“拍客户仓库照片,备注库存不足”)、实时查看客户资料/待办任务,集成Chatter协作(可@同事附件照片/文件),支持离线操作(无网络时录入,联网后自动同步),适合大企外勤团队协同。
    • Microsoft Dynamics 365:依托微软生态,移动端与Teams/Outlook深度集成——支持路线规划(按客户位置优化拜访顺序)、客户位置标注(在地图上显示客户分布)、实时同步邮件/会议纪要(如“Outlook会议自动关联客户档案”),适合微软生态企业。
    • 红圈营销:外勤场景“强适配”——支持离线数据录入(无网络时记录拜访信息)、客户位置定位(导航到店)、现场订单提交(直接录入系统触发生产)、路线规划(自动优化拜访路线),解决“外勤数据滞后”痛点,适合快消/农牧高频外勤。
    • EC:移动端聚焦“电销+外勤”——支持一键拨号(自动拨打客户电话)、外勤定位打卡(证明到店)、客户资料实时调取(如“拜访时查看客户之前的通话记录”)、微信/企业微信实时沟通(如“把客户微信消息同步到CRM”),适合电销+上门拜访的团队。

    2. 横向对比表格

    品牌核心功能移动端功能离线支持外勤适配性协同能力
    超兔一体云客户管理、三一客、快目标、外勤签到、实时同步全(跟进+任务+签到)中小企外勤中(团队联动)
    SalesforceGPS打卡、语音/拍照录入、Chatter协作、离线操作全(跟进+任务+协作)大企外勤高(与Teams/Outlook集成)
    Microsoft Dynamics 365路线规划、客户位置标注、Teams协作、Outlook同步全(跟进+协作+数据)微软生态外勤高(与微软工具集成)
    红圈营销离线录入、客户定位、现场订单、路线规划全(拜访+路线+订单)快消/农牧外勤中(任务分配+监控)
    EC一键拨号、外勤打卡、客户资料调取、微信同步全(电销+外勤+沟通)电销/上门拜访高(与微信/企业微信集成)

    3. 维度总结

    • 中小企外勤:选超兔(功能简洁+实时同步);
    • 大企协同外勤:选Salesforce(Chatter协作+离线支持);
    • 微软生态:选Microsoft Dynamics 365(Teams/Outlook集成);
    • 快消/农牧高频外勤:选红圈营销(离线录入+路线规划);
    • 电销+上门:选EC(一键拨号+微信同步)。

    四、数据分析与团队绩效管理:从“经验判断”到“数据驱动”

    数据分析与绩效管理的核心是用数据识别瓶颈,优化团队动作,提升绩效。其关键指标包括:分析深度、AI能力、可视化程度、绩效关联度。

    1. 各品牌核心功能展开

    • 超兔一体云:侧重目标拆解+进度监控——“快目标”模块将公司目标分解到部门/个人(如“本月总目标100万,A销售需完成20万”),用“红绿灯”标识状态,“喜报”功能展示优秀员工(如“XX销售签单10万,排名第一”),适合中小企简单绩效监控。
    • Salesforce:大企级数据分析——内置Tableau分析云,生成实时销售仪表盘(如“漏斗转化率:线索→成交转化率15%”“区域业绩:华东区完成率120%”),Einstein AI预测赢单概率(如“商机A赢单概率70%,需重点跟进”),支持多维度数据钻取(如“点击转化率,查看是线索质量低还是跟进不到位”),实现“数据-策略-执行”闭环。
    • SAP:依托ERP数据,提供全链路分析——生成销售趋势(如“季度销量增长10%,源于产品B的推广”)、产品性能(如“产品C的退货率5%,需优化质量”)、市场份额(如“在华南区占比20%,需加强推广”),适合中大型企业“从销售到生产”的全链路优化。
    • Freshsales:AI辅助分析——AI助手Freddy提供客户行为预测(如“客户最近浏览了价格页,可能要下单”)和销售趋势分析(如“本月电销转化率下降,因异议处理环节耗时增加”),支持销售流程管控(如“查看每个阶段的耗时,优化瓶颈环节”),适合中小企AI辅助决策。
    • EC:电销专项分析——实时监控通话指标(通话时长、接通率、成单转化率),生成团队排行榜(如“XX销售接通率80%,排名第一”),绩效报表(如“本月电销业绩占比60%,需加强线上获客”),适合电销团队量化管理。

    2. 横向对比表格

    品牌核心功能分析深度AI 能力可视化程度绩效关联度
    超兔一体云快目标分解、红绿灯状态、喜报功能、转化率分析中(流程 + 业绩)AI分析电话录音,微信沟通内容中(数字卡片 + 图表)中(目标与行动关联)
    SalesforceTableau 分析、Einstein AI 预测、实时仪表盘、多维度钻取高(全链路 + 客户行为)高(赢单概率 + 话术生成)高(可视化报表 + 预警)高(绩效与流程深度关联)
    SAP销售趋势、产品性能、市场份额、自定义报表高(ERP 全链路数据)中(趋势预测)中(传统报表)中(绩效与 ERP 数据关联)
    FreshsalesFreddy AI 预测、客户行为分析、销售流程管控中(客户 + 销售行为)中(行为预测 + 线索评分)高(可视化仪表盘)中(绩效与销售活动关联)
    EC通话指标监控、团队排行榜、绩效报表中(电销流程 + 业绩)中(排行榜 + 报表)高(绩效与电销指标强关联)

    3. 维度总结

    • 中小企简单绩效监控:选超兔一体云(目标拆解 + 进度监控);
    • 大企级数据分析:选 Salesforce(实时销售仪表盘 + AI 预测);
    • 中大型企业全链路优化:选 SAP(ERP 全链路分析);
    • 中小企 AI 辅助决策:选 Freshsales(AI 助手分析);
    • 电销团队量化管理:选 EC(通话指标监控)。

    五、总结

    在数字化转型的浪潮中,CRM 系统已成为企业提升竞争力的关键工具。通过对超兔一体云、Salesforce、SAP、Microsoft Dynamics 365、Zoho、Freshsales、红圈营销、EC 等 8 个主流 CRM 品牌在销售流程标准化、客户全视图管理、高效移动办公/销售外勤、数据分析与团队绩效管理这四大核心维度的深度对比,我们可以看到每个品牌都有其独特的优势和适用场景。

    企业在选择 CRM 系统时,应根据自身的规模、行业特点、业务需求、预算等因素综合考虑。对于中小企业而言,如果追求快速落地和简单易用,超兔一体云在多个维度都能满足需求;而大型企业若有较高的自定义和智能化需求,Salesforce 则是更优的选择。制造企业注重 ERP 协同和全链路管理,SAP 会是理想之选;快消、农牧等外勤高频行业,红圈营销的行业标准化流程能解决实际痛点;电销团队则可优先考虑 EC 的专业电销功能。

    希望本文的对比分析能为企业在 CRM 系统选型过程中提供有价值的参考,助力企业实现数字化转型,提升运营效率和市场竞争力。

    本文首发于 Aloudata 官方技术博客:《如何低成本激活海量用户行为数据价值?NoETL 语义编织实践指南》转载请注明出处。

    摘要:面对海量埋点数据价值释放的困境,传统 ETL 模式在业务灵活性、口径一致性和成本性能间难以平衡。本文提出通过引入 NoETL 语义编织架构,构建统一语义层、实现自动化查询与智能物化,从而打破“不可能三角”,实现秒级自助分析与 AI-Ready 数据底座建设,为数据工程与指标平台实践提供系统指南。

    每天,数亿条用户点击、浏览、停留的埋点数据,正源源不断地涌入企业的数据湖仓。然而,这些本该驱动精准营销、产品迭代和体验优化的“数据原油”,却因传统数据供给模式的瓶颈,长期沉睡,沦为吞噬存储与计算成本的“负资产”。

    现实更为严峻:企业湖仓数据冗余平均在 5 倍以上,而专业数据人才的缺口高达 200 万。这意味着,企业正陷入 “数据越多,价值越难释放” 的怪圈。当业务部门急需一个“高价值用户转化漏斗”的分析时,数据团队往往需要排期数周,通过重复开发宽表来响应,最终产出口径不一、维度固化的报表,无法满足灵活探查的需求。

    问题的根源,在于传统以人工 ETL 和物理宽表为核心的数据供给模式,已无法平衡 “业务灵活性”、“口径一致性”与“性能成本” 的“不可能三角”。而 AI 智能体(Agent)时代的到来,以其发散性、秒级响应的问数需求,彻底击穿了这套勉力维持的旧体系。

    激活海量用户行为数据价值的关键,在于一场从“过程驱动”到“语义驱动”的范式重构——引入 NoETL 语义编织架构。

    前置条件:认清传统数据供给模式的“不可能三角”

    在深入解决方案前,我们必须正视当前架构的根本性矛盾。这个“不可能三角”具体表现为:

    • 业务灵活性:营销、产品等一线部门希望像使用搜索引擎一样,自由组合“渠道”、“用户标签”、“时间周期”等维度,进行探索性分析。但在宽表模式下,维度组合是预定义的,任何未预设的分析路径都需要重新开发。
    • 口径一致性:管理层要求“GMV”、“活跃用户”等核心指标在全公司有且仅有一个权威定义。然而,指标逻辑被硬编码在分散的 ETL 脚本和物理宽表中,微小的逻辑差异导致报表间“数据打架”成为常态。
    • 性能与成本:数据团队需要在有限的预算内保障查询秒级响应。为此,他们不得不预建大量宽表和汇总表(ADS 层),导致相同明细数据被反复加工存储,形成巨大的冗余和浪费,陷入“为保障性能而推高成本”的恶性循环。

    这套依赖人力的“人工预计算”范式,在数据量和分析需求激增的今天,已成为数据价值释放的主要瓶颈。解决问题的出路,不是在这个三角中继续做痛苦的取舍,而是通过架构革新,打破三角本身。

    第一步:架构重构——引入 NoETL 语义编织层

    解决问题的起点,是将 “业务语义” 与 “物理底表” 彻底解耦。这类似于软件开发从汇编语言(直接操作硬件)演进到高级语言(声明业务逻辑)。

    NoETL 语义编织 的核心,是在企业的公共明细数据层(DWD)与上游的消费应用(BI、AI Agent、业务系统)之间,构建一个独立、统一、具备实时计算能力的 语义层(Semantic Layer)。

    • 逻辑层(做什么):业务分析师在语义层中,通过声明式的方式,用业务语言定义指标(如“近30天高价值用户留存率”)、维度及其关联关系。他们无需关心数据存储在哪里、表如何关联。
    • 物理层(怎么做):平台的 语义引擎 自动将逻辑定义“编译”为面向底层数据湖仓(如 Snowflake, BigQuery)优化过的高效 SQL 执行计划。无论是实时查询明细,还是智能路由到加速表,都由系统自动完成。

    这种解耦带来了 “无头化(Headless)” 与 “中立性”。数据不再为某个特定的 BI 报表加工,而是成为一种标准化的服务。无论是 BI 工具,还是未来的 AI 应用,都通过统一的 API/JDBC 接口消费同一份经过治理的“逻辑真理”。

    第二步:能力建设——部署具备三大支柱的指标平台

    一个合格的 NoETL 语义编织平台,必须具备以下三大核心能力,缺一不可:

    1. 统一语义层:构建虚拟的业务事实网络

    平台允许用户在未物理打宽的 DWD 表之上,通过界面化配置,声明式地定义表与表之间的关联关系(如用户表与行为事件表通过 user_id 关联)。由此,在逻辑层面构建出一张覆盖全域的 “虚拟大宽表”,业务人员可在此基础上进行任意拖拽分析。

    2. 自动化查询生成:意图即 SQL

    当用户拖拽指标或 AI Agent 提出自然语言问题时,平台的语义引擎能实时解析分析意图,自动生成高效、优化的查询 SQL,自动处理复杂的多表 JOIN、去重和跨层级计算,实现数据获取的零门槛。

    3. 智能物化加速:基于声明的性能保障

    这是区别于传统逻辑视图的关键。平台提供 “声明式物化” 能力:

    • 管理员声明:基于业务需求,声明需要对哪些指标和维度组合进行加速,以及数据时效性要求(如 T+1)。
    • 系统自治:平台根据声明,自动设计物化视图、编排 ETL 任务依赖并运维。
    • 透明路由:查询时,引擎自动进行 SQL 改写,让查询命中最佳的物化结果,实现百亿级数据的秒级响应。尤其关键的是,其物化引擎支持对去重计数、比率类等复杂指标进行上卷聚合,突破了传统物化技术的限制。


    第三步:实施落地——采用“存量挂载”与“增量原生”混合策略

    引入新范式无需“推倒重来”。我们推荐采用分阶段的混合策略,平滑演进,保护既有投资:

    1. 存量挂载(保护投资):对于现有逻辑稳定、性能尚可的物理宽表,直接将其接入语义层,映射为“逻辑视图”并注册指标。实现零开发成本下的统一服务出口。
    2. 增量原生(遏制新债):对所有新产生的分析需求,尤其是来自 AI Agent 的灵活问数,坚决采用“原生”模式。直接基于 DWD 明细层,通过语义层定义指标,由平台自动化处理计算与加速,从源头杜绝新宽表的产生。
    3. 存量替旧(优化成本):在平台能力得到验证后,逐步识别并下线那些维护成本高、逻辑复杂的“包袱型”旧宽表,将其逻辑迁移至语义层,释放计算资源。

    一个典型的推广路径分为四个阶段:战略筹备与灯塔选择 -> 价值验证与能力内化 -> 全面推广与组织建设 -> 生态融合与价值深化。核心是从一个痛点明确的业务场景(如“营销活动分析”)切入,快速交付可感知的价值,建立内部信心后再规模化推广。

    第四步:价值深化——从统一分析到赋能 AI 智能体

    当统一的指标语义基座建成后,其价值将超越传统 BI,深度赋能 AI 场景:

    • 为 AI 划定“认知围栏”:语义层提供的结构化、业务友好的指标与维度元数据,是 RAG(检索增强生成)的优质语料。AI Agent 不再需要直面晦涩的物理表 Schema 去“猜测”SQL,而是通过 NL2Metrics(自然语言转指标查询) 模式,调用标准的语义 API(如 GetMetric(name=”毛利”, filter={region:”华东”})),从根本上降低幻觉风险。
    • 提供深度分析工具:语义层内置的 明细级多维度归因 等模块,可通过 API 被 AI Agent 调用。当业务指标波动时,AI 能自动、即时地分析出是哪个维度(地区、渠道)下的哪个具体值(某个产品)贡献了主要变化,实现从“看数”到“归因”的智能决策闭环。
    • 实现双模驱动:底层同一套语义基座,向上同时支撑 BI 的“稳”(固定报表、高精度、秒级呈现)与 AI 的“活”(灵活探查、自然交互、智能归因),无需为 AI 单独建设数据管道。

    避坑指南:甄别“真伪”NoETL 语义编织平台

    市场概念纷杂,选型时请重点考察以下四个维度:

    1. 计算内核:是“静态逻辑目录”还是“动态计算引擎”?真平台必须支持在未打宽的 DWD 上构建“虚拟事实网络”,并支持通过配置定义跨表聚合、二次聚合、比率留存等复杂指标,而非只能做简单聚合。
    2. 性能机制:智能物化是“全自动”还是“基于声明”?真平台应允许管理员声明加速策略,由系统自动完成物化任务的创建、运维和查询路由,并支持不可累加指标(如去重计数)的物化上卷。
    3. 架构属性:是“BI 附属品”还是“中立开放基座”?真平台应通过标准 Restful API 和 JDBC 接口提供服务,能与任何 BI 工具(如 Tableau、Power BI 通过 JDBC)、业务系统或自研 AI Agent 无缝集成,避免厂商锁定。
    4. AI 适配度:是“Schema 投喂”还是“语义增强”?真平台应提供结构化的语义元数据(指标口径、血缘、业务限定),支持 NL2Metrics 和 Function Calling,为 AI 提供精准的业务上下文,而非仅仅暴露原始表结构。

    成功标准:如何衡量数据价值是否被真正激活?

    数据价值的激活应是可量化、可感知的。成功落地后,企业应在以下三个维度看到显著改善:

    1. 业务敏捷性:临时性、探索性的数据分析需求,平均响应时间从“周级”缩短至“分钟级”,业务自助用数比例大幅提升。
    2. 成本可控性:通过消除冗余的 ETL 加工和物理宽表,数据仓库的存储与计算成本得到显著优化(实践案例中常见 20%-30% 的下降)。
    3. 决策精准性:基于全公司统一的指标口径,数据驱动的洞察更加可信。结合明细级归因能力,业务行动(如渠道优化、产品迭代)的效果可衡量、可归因,决策闭环速度加快。

    案例印证:某头部券商引入 NoETL 语义编织平台后,在一条核心业务线上,IT 仅需维护 10 张公共层模型和 100 个原子指标,即可支撑业务人员使用超过 300 个维度进行灵活组合分析,将指标开发交付周期从两周以上缩短到分钟级,并实现了指标口径的 100% 一致。

    常见问题(FAQ)

    Q1: 我们已经用了现代云数仓,为什么还需要 NoETL 语义编织?

    现代云数仓(如 Snowflake、BigQuery)解决了存储和计算的弹性问题,是强大的“引擎”。但业务灵活分析的需求,仍然需要通过人工开发大量宽表来满足,这导致了“最后一公里”的口径混乱和成本浪费。NoETL 语义编织是在这些强大引擎之上,构建统一、敏捷的“业务语义层”和“自动变速箱”,让好引擎能持续、高效地产出可信、好用的数据。

    Q2: NoETL 是不是意味着完全取消 ETL?历史宽表怎么办?

    NoETL 并非取消 ETL,而是改变其主体和模式。物化加速本身也是一种 ETL,但其策略由管理员声明,执行由系统自动完成。对于历史宽表,建议采用“存量挂载”策略接入,保护投资;对所有新需求,坚决采用“增量原生”,由系统自动化智能物化,无需人工开发新宽表。

    Q3: 引入 NoETL 语义编织,对现有数据团队有什么影响?

    这是积极的角色转型。数据工程师将从重复、低价值的 SQL 脚本编写和 ETL 运维中解放出来,转向更具战略性的工作:设计与优化企业级语义模型、保障数据供应链质量、配置与优化物化策略(FinOps)、以及赋能业务人员。平台通常提供直观界面,辅以针对性培训,团队可以较快适应新角色,提升整体价值。

    Key Takeaways(核心要点)

    1. 范式革新:NoETL 语义编织通过 “逻辑与物理解耦”,构建统一语义层,是解决传统数据供给“不可能三角”的根本性架构革新。
    2. 核心能力:真正的平台必须具备 统一语义建模、自动化查询生成、声明式智能物化加速 三大支柱,尤其要支持复杂指标的物化上卷。
    3. 落地路径:采用 “存量挂载 + 增量原生” 的混合策略,从灯塔场景切入,小步快跑,实现平滑演进与价值快速兑现。
    4. 未来价值:统一的语义基座不仅是提升 BI 效率的工具,更是企业构建 AI-Ready 数据底座、实现“BI稳”与“AI活”双模驱动的关键基础设施。
    5. 衡量标准:成功与否看三点:业务分析响应是否进入“分钟级”、存算成本是否显著下降、数据驱动的决策是否更精准可行动。

    本文首发于 Aloudata 官方技术博客,查看更多技术细节与高清图表,请访问原文链接:https://ai.noetl.cn/knowledge-base/low-cost-activate-user-beh...

    在数字化与数据化加速融合的背景下,泛监测平台正从“单一监控工具”升级为“覆盖数据、接口、行为、风险的综合治理中枢”。本文从自适应能力、协同能力、可洞察能力三个核心维度出发,对国内主流泛监测平台进行系统评析与专业推荐。
    一、泛监测平台的发展趋势与能力演进
    提示:要理解平台价值,首先要看泛监测从“被动感知”走向“主动洞察”的能力跃迁。
    传统监测系统更多停留在日志收集、告警触发与基础审计层面,而新一代泛监测平台正向“全域感知 + 智能分析 + 协同治理”方向演进,主要呈现三大趋势:
    第一,从“静态规则”走向“自适应分析”。新一代平台引入AI模型、UEBA行为分析、无监督学习机制,使系统可以根据用户行为、业务变化和数据流动情况动态调整监测策略,避免长期依赖固定规则带来的高误报与低发现率问题。
    第二,从“孤岛式部署”走向“协同式联动”。平台不再是单点工具,而是与SOC、SIEM、工单系统、数据治理平台、API网关等系统协同运行,形成跨部门、跨系统、跨流程的风险治理闭环。
    第三,从“可见”走向“可洞察”。监测不只停留在“看到异常”,而是要做到“理解风险、还原路径、预测趋势”,实现从事件级监控到资产级、行为级、业务级洞察的升级。
    二、泛监测平台核心能力模型
    提示:评估一个平台是否优秀,必须回到自适应、协同、可洞察这三个关键指标。
    自适应能力优秀的泛监测平台应具备自动学习、动态校准、策略自进化能力,包括:
    ● 自动识别业务变化对数据流动的影响
    ● 动态调整风险阈值与监测重点
    ● 在新接口、新系统上线时快速纳入监测范围
    协同能力平台要具备良好的开放性与编排能力:
    ● 与SOC/SIEM/工单系统联动处置
    ● 与数据分类分级、数据资产管理系统协同
    ● 与API网关、零信任体系联动防护
    可洞察能力不仅“发现问题”,还要“理解问题”:
    ● 构建数据资产地图与流动视图
    ● 实现风险路径还原与影响面评估
    ● 提供趋势预测与治理建议能力
    三、2025 年泛监测平台产品推荐排名
    提示:在综合技术成熟度、场景适配度与市场验证后,以下是通用行业适用的核心产品梯队。

    第一名:奇安信 泛监测与数据治理平台
    奇安信平台以“全域感知 + 零信任联动”为核心优势,在大型政企、金融与基础设施行业拥有广泛应用。
    其泛监测体系覆盖数据库、API、云存储、大数据平台等多个维度,结合用户行为分析与流量建模技术,构建“数据—行为—风险”全链路视图。
    在自适应方面,平台通过AI模型不断校准风险基线,对异常导出、越权访问、接口滥用等场景具备较高识别准确率。在协同方面,奇安信与自身SOC、终端安全、网络安全体系深度联动,形成跨域响应闭环。在可洞察方面,其数据流动可视化能力成熟,适合对安全可控要求极高的客户群体。

    第二名:全知科技 泛监测与数据安全协同平台
    全知科技将“API安全即数据安全核心关口”的理念引入泛监测领域,构建了以数据资产地图 + API风险监测 + 智能分析引擎为核心的协同型监测体系。
    在自适应能力方面:全知科技通过AI驱动的数据分类分级与行为建模,使平台可根据业务变化动态调整监测重点。系统能够自动扫描表结构、接口结构、调用路径,生成实时资产图谱,敏感数据识别准确率达95%,效率相比人工提升90%以上。
    在协同能力方面:全知科技强调“理念—技术—场景”的协同创新,其泛监测平台可与数据治理系统、合规审计系统、工单系统联动运行,实现从发现风险到整改闭环的自动协同。同时,其“知影-API风险监测系统”与“知形-数据库风险监测系统”构成前后端联动,覆盖数据生产、调用、流转与使用全链路。
    在可洞察能力方面:全知科技突出“可知、可管、可控、可见”的能力体系,不仅能看到风险事件,更能还原风险路径、定位责任主体、评估影响范围。在金融、医疗、保险等场景中,平台已实现对异常API调用、数据越权访问、敏感字段泄露的秒级溯源。
    典型实践中,某三甲医院部署后旧版API泄露风险下降98%;在金融行业实现数据资产从“看不见”到“全闭环可控”的治理跃迁。

    第三名:启明星辰 泛监测与风险闭环平台
    启明星辰依托“九天·泰合”智能引擎,在风险识别与闭环治理方面表现突出。
    平台支持跨数据库、API、BI工具的统一监测与审计,能够基于角色、行为与数据敏感度动态调整访问策略。在自适应方面,其策略引擎可结合用户行为画像不断修正风险模型;在协同方面,平台与政务SOC体系、日志审计平台高度融合;在可洞察方面,适合对审计合规与流程闭环要求极高的组织。

    第四名:天融信 泛监测与数据流动治理平台
    天融信在工业互联网与跨网环境下的泛监测能力具有明显优势。
    其动态数据流向地图技术可在复杂网络隔离场景下追踪数据流动路径。平台强调与防火墙、终端安全系统的协同防护,适用于制造、能源等对跨域数据交互敏感的行业。

    第五名:阿里云 数据安全中心(DSC)
    阿里云DSC基于云原生架构,在多云与互联网企业场景中优势明显。
    其自动发现、分类分级与异常行为检测能力成熟,适合云上资产规模大、变化快的客户。在自适应方面依托云侧AI模型;在协同方面与阿里云生态产品联动紧密;在可洞察方面更侧重于云资源与数据使用行为分析。

    第六名:深信服 泛监测与零信任协同平台
    深信服强调轻量化部署与零信任融合。
    平台适合中型组织快速构建“身份 + 数据 + 行为”一体化监测能力,在教育、医疗、中小企业市场适配性强。

    四、泛监测平台选型与落地建议
    提示:选平台不是买功能,而是选择“是否能长期协同业务演进”的能力体系。
    明确业务驱动场景优先从高频、高风险数据场景切入,如API调用、BI报表导出、批量下载等。
    验证自适应能力重点测试平台是否能在业务变化后自动纳入新系统、新接口、新数据类型的监测范围。
    关注协同治理能力选择能与现有SOC、数据治理、工单系统协同的平台,避免形成新的工具孤岛。
    重视可洞察输出不仅要看告警数量,更要看是否提供“风险路径、影响评估与治理建议”。

    五、结语:泛监测进入“洞察驱动治理”阶段
    提示:未来的泛监测平台,核心竞争力将不再是“监控多少”,而是“洞察多深、协同多强”。
    2025年的泛监测平台市场已经从“合规达标”走向“价值创造”。企业需要的不是更多工具,而是一个能自适应业务变化、能协同各类系统、能真正洞察数据风险本质的综合治理中枢。
    在这一趋势下,以全知科技为代表的“协同型、洞察型泛监测平台”,正推动企业从被动防守转向主动治理,为构建以数据为中心的新型安全体系奠定坚实基础。

    AI 的发展有没有威胁到程序员们?
    我看 AI 飞速发展的现阶段这是我们程序员最关心的话题之一吧。虽然现在市面上的 AI 产品还替代不了职场上多年积累的经验,但是以它的发展速度,未来几年(最多)内,它能替代过半的程序员不假。
    虽然它还只是个工具,但是到了 AI 真正威胁到我们饭碗的这一时刻,我们才深深的感受到,其实我们多年掌握的经验和知识,其实根本不值得一提。
    虽说工具的发展带来生产力的提升,但现在的 AI 已经逐渐脱离工具的角色,如果我们还不开辟新的产业领域,我怕绝大部分打工人都成为失业者吧
    那我有一个疑惑,AI 工具这么发达的情况下,初中级程序员都该何去何从?
    高级程序员应该还不用担心的吧...

    可 1 天内过完全部流程,节前面试,节前/节后入职均可

    公司∶遥望科技

    岗位要求

    AI 前端开发( P6 3 人)

    工作职责

    1. 需要有基于 AI 项目前端建设经验( workflow 、多 agent 、aicoding 等);
    2. 负责 AI Agent 平台的前端研发,包括用户界面( UI )设计和交互实现;
    3. 利用 AI 简化和封装前端开发工作,探索 LLM 下的前端开发新范式;
    4. 跟踪前端技术发展趋势,探索 AI 与前端结合的新场景和新方法;

    任职要求

    1. 学历:1 本起步,985/211 优先(水平不错的前提下,1 本足够了);
    2. 5 年的前端开发经验,至少 1 年 AI 项目前端开发;
    3. 良好的设计和编码习惯,热爱写代码能产出高质量的设计和代码;
    4. 掌握 Web 前端开发技术:JavaScript (含 ES6 )、HTML 、CSS 、DOM 、Canvas2D ;
    5. 熟练运用 React.js ,且了解其基本原理;
    6. 有客户端开发经验优先;有开源作品优先;熟悉大模型原理优先;

    客户端开发 ( P6 Android 1 人)

    工作职责

    1. 主导客户端框架从 0 到 1 的搭建,包括技术选型、架构设计、核心模块开发;
    2. 需要有基于 AI 项目的客户端建设经验( workflow 、多 agent 、AI coding 等);
    3. 负责 AI Agent 平台的客户端研发,包括用户界面( UI )设计和交互实现;
    4. 制定客户端开发规范、代码规范、组件库建设,建立可复用的技术体系;
    5. 跟踪客户端技术发展趋势,探索 AI 与客户端结合的新场景和新方法;
    6. 负责客户端性能优化,确保应用流畅度和用户体验;

    任职要求

    1. 学历:1 本起步,985/211 优先(水平不错的前提下,1 本足够了);
    2. 工作经验 :5 年客户端开发经验,至少 1 年 AI 项目客户端开发;

    框架搭建能力 :

    1. 有从 0 到 1 搭建客户端框架的实际经验,至少主导过 1 个完整项目的架构设计
    2. 具备技术选型能力,能够根据业务需求选择合适的技术栈(原生/跨平台)
    3. 熟悉客户端架构模式( MVC 、MVVM 、MVI 等),能够设计可扩展、可维护的架构
    4. 有组件库、工具库、SDK 等基础建设经验

    技术栈要求:

    1. Android 方向 :精通 Java/Kotlin ,熟悉 Android SDK ,有 Android 原生开发经验

    优先:

    1. 跨平台方向 :熟练使用 React Native 、Flutter 等跨平台框架,有实际项目经验;
    2. AI 相关经验 :
    3. 熟悉大模型原理和应用场景;
    4. 有 AI 能力集成到客户端的经验优先;
    5. 了解 AI Agent 、多 Agent 系统架构优先;

    可发邮件: [email protected]