在实际办公和开发场景中，我们经常会遇到这样的需求：Word 文档中包含大量结构化表格数据，而最终需要将这些数据统一整理到 Excel 中进行统计、分析或二次处理。手动复制粘贴不仅效率低，而且在遇到复杂表格（如单元格内多段文本、多表格文档）时，格式也很容易被破坏。

借助 Python 脚本我们可以自动化提取 Word 文档中的所有表格，并将每个表格完整写入 Excel 的独立工作表中，在保证数据结构清晰的同时，大幅提升处理效率。

本文将详细介绍一种完整、可复用的实现方案，并对关键代码逻辑进行说明，适用于批量表格转换与自动化办公场景。

本文所使用的方法需要用到 Free Spire.Doc for Python 和 Free Spire.XLS for Python，分别用于提取 Word 表格数据和写入 Excel 文件。可通过 pip 安装：pip install spire.doc.free spire.xls.free。

一、实现思路概览

整个转换流程可以拆分为两个清晰的阶段：

1. 从 Word 文档中提取表格数据

   • 遍历文档中的所有节（Section）
   • 遍历每个节中的所有表格（Table）
   • 逐行、逐单元格读取文本内容
   • 保留单元格内的原有段落结构

2. 将提取的数据写入 Excel 文件

   • 为每个 Word 表格创建一个新的工作表
   • 按行列顺序写入单元格内容
   • 自动调整列宽，提升可读性

这种“先抽象为数据结构，再写入目标文件”的方式，逻辑清晰，也便于后续扩展（例如 CSV、数据库等）。

二、使用 Python 提取 Word 中的表格数据

下面的函数负责从 Word 文档中提取所有表格，并以嵌套列表的形式返回数据。

from spire.doc import *

def extract_tables_from_word(word_file_path):
    """
    从 Word 文档中提取所有表格数据。
    返回一个列表，其中：
    - 每个元素代表一个表格
    - 表格内部是“行”的列表
    - 每一行是“单元格内容”的列表
    """
    document = Document()
    document.LoadFromFile(word_file_path)

    all_tables_data = []

    # 遍历文档中的所有节
    for sec_index in range(document.Sections.Count):
        section = document.Sections.get_Item(sec_index)

        # 遍历节中的所有表格
        for table_index in range(section.Tables.Count):
            table = section.Tables.get_Item(table_index)
            current_table_data = []

            # 遍历表格中的所有行
            for row_index in range(table.Rows.Count):
                table_row = table.Rows.get_Item(row_index)
                current_row_data = []

                # 遍历行中的所有单元格
                for cell_index in range(table_row.Cells.Count):
                    table_cell = table_row.Cells.get_Item(cell_index)

                    # 提取单元格中的所有段落文本，保留换行结构
                    paras = [
                        table_cell.Paragraphs.get_Item(i).Text.rstrip('\r\n')
                        for i in range(table_cell.Paragraphs.Count)
                        if table_cell.Paragraphs.get_Item(i).Text.strip()
                    ]
                    current_cell_data = "\n".join(paras)
                    current_row_data.append(current_cell_data)

                current_table_data.append(current_row_data)

            all_tables_data.append(current_table_data)

    document.Close()
    return all_tables_data

关键说明

• Section → Table → Row → Cell 的层级结构，符合 Word 文档的真实组织方式

• 使用 Paragraphs 而不是直接读取 Text，可以：

  • 避免丢失单元格内的多段内容
  • 保留原有换行结构，写入 Excel 后依然清晰
• 最终返回的数据是一个三层嵌套列表，非常适合后续写入表格类文件

三、将提取的数据写入 Excel 文件

在拿到结构化表格数据后，接下来使用 Spire.XLS for Python 将其写入 Excel。

from spire.xls import *

def write_data_to_excel(extracted_data, excel_file_path):
    """
    将提取的 Word 表格数据写入 Excel 文件。
    每个 Word 表格对应 Excel 中的一个工作表。
    """
    workbook = Workbook()
    # 清除默认工作表
    workbook.Worksheets.Clear()

    if not extracted_data:
        print("没有从 Word 文档中提取到任何表格数据。")
        return

    # 遍历所有表格数据
    for i, table_data in enumerate(extracted_data):
        sheet = workbook.Worksheets.Add(f"Table_{i + 1}")

        # 写入行列数据
        for r_idx, row_data in enumerate(table_data):
            for c_idx, cell_value in enumerate(row_data):
                # Excel 行列索引从 1 开始
                sheet.Range[r_idx + 1, c_idx + 1].Value = cell_value

        # 自动调整列宽
        sheet.AllocatedRange.AutoFitColumns()

    workbook.SaveToFile(excel_file_path, ExcelVersion.Version2016)
    workbook.Dispose()
    print(f"数据已成功写入到 {excel_file_path}")

实现要点

• 每个 Word 表格 → 一个 Excel 工作表

  • 结构直观，避免数据混杂
• Excel 行列索引从 1 开始，需要注意与 Python 索引的差异
• AutoFitColumns() 可显著提升导出后的可读性

四、完整调用示例

word_file = "input.docx"
excel_file = "output.xlsx"

extracted_data = extract_tables_from_word(word_file)
write_data_to_excel(extracted_data, excel_file)

运行后，Word 文档中的所有表格将被完整转换，并按顺序写入 Excel 文件。以下是运行结果示例：

五、适用场景与扩展建议

适用场景：

• 将报告型 Word 文档中的数据统一汇总到 Excel
• 自动化处理批量合同、清单、配置表
• 作为数据清洗或分析流程的前置步骤

扩展方向：

1. 批量处理多个 Word 文件
2. 根据表格内容自动命名工作表
3. 对 Excel 输出添加边框、样式或冻结首行
4. 将中间数据结构复用于 CSV 或数据库写入

总结

通过结合 Spire.Doc for Python 与 Spire.XLS for Python，我们可以用一套清晰、稳定的 Python 方案，实现 Word 表格到 Excel 表格的自动化转换。这种方式不仅避免了手动复制的低效和错误，也为后续的数据处理和分析提供了良好的基础。

对于需要频繁处理文档表格数据的开发者和办公场景来说，这是一种非常实用、可维护性也很高的解决方案。

一、风冷：算力中心的“传统空调”，可靠但遇瓶颈

风冷，顾名思义，就是用空气作为散热介质，靠“吹风”带走服务器的热量，原理和我们家用空调、电风扇几乎一致，是目前应用最广泛、最成熟的散热技术，遍布各类中小型算力中心。

1. 核心原理：

风冷系统主要由两部分组成：服务器内部的散热风扇，以及机房整体的精密空调或列间空调。服务器运行时，CPU、GPU等核心部件会快速发热，内部风扇会加速转动，将冷空气吸入机箱，冷空气穿过散热片（吸收芯片热量）后，变成热空气被排出机箱；机房的精密空调则负责制造冷风、控制机房温度和湿度，将热空气冷却后循环利用，形成完整的散热闭环。

简单说，风冷就像给发烧的人吹电风扇，靠空气流动带走体表热量，技术逻辑简单，不需要复杂的管路设计。

2. 主流类型

风冷分为两种常见形式，适配不同场景：

• 被动风冷：完全依靠自然对流和散热片散热，没有风扇，静音、无能耗，但散热效率极低，仅适用于发热量极小的低端服务器，现在已基本淘汰。
• 主动风冷：就是我们现在最常见的形式，服务器内置风扇、机柜搭配散热风机，机房配备精密空调，可通过调节风扇转速、空调温度，适配不同的发热场景，散热效率比被动风冷高5-10倍，能应对单机柜功率密度≤10kW的传统算力需求。

3. 优劣势：成熟可靠，但扛不住高密度算力

风冷能沿用多年，核心优势在于“简单实用”：

• 成本低：设备采购、安装和维护都很简单，初期投入少，运维人员上手快；
• 可靠性高：没有复杂的管路和液体介质，不存在漏液风险，故障率极低；
• 兼容性强：适配所有类型的服务器，改造难度小，存量算力中心升级成本低。

但随着AI大模型、云计算的爆发，算力密度大幅提升（部分智算中心单机柜功率突破50kW），风冷的短板也越来越明显，逐渐触及物理极限：

• 散热效率低：空气的导热系数仅为0.026W/(m·K)，导热能力极差，当机柜功率超过15kW时，多台空调叠加运行也难以降温，甚至会限制服务器性能，被动降频，导致计算效率下降30%；
• 能耗极高：制冷系统（精密空调、风扇）的能耗占算力中心总能耗的30%-40%，是名副其实的“能耗黑洞”，导致PUE（能源利用效率）居高不下，南方地区夏季风冷PUE普遍突破1.6，难以满足国家新建数据中心PUE≤1.3的要求；
• 噪音大：服务器风扇和机房空调持续运转，噪音可达80分贝，相当于站在马路边，对机房环境要求较高。

二、液冷

液体的导热效率是空气的20倍以上，比热容是空气的4倍。现在，液冷已成为高端智算中心、AI训练集群的“首选方案”，能实现PUE低至1.04，较风冷节能40%-50%。

1. 核心原理

液冷的核心的是用液体介质（水、矿物油、氟化液等）替代空气，直接或间接接触服务器发热部件，通过液体对流和相变吸热，将热量快速带走，再通过冷却系统将热水（或热液体）降温，循环利用。

与风冷相比，液冷的核心突破的是取消了高功耗的空调压缩机，改用低功率的闭式冷却塔和冷量分配单元（CDU），制冷系统能耗降低90%以上，从根源上实现节能。

2. 主流类型：三种技术，适配不同算力场景

根据液体与服务器部件的接触方式，液冷主要分为三种，各自有明确的适配场景，目前冷板式和浸没式应用最广泛：

（1）冷板式液冷：给核心部件“敷冷毛巾”

这是目前最主流、最易落地的液冷技术，相当于给CPU、GPU等核心发热部件，贴了一块“可循环制冷的冷毛巾”。

原理是将铜或铝制的冷板，紧密贴合在芯片等发热部件表面，冷板内部有密闭流道，乙二醇溶液（防结冰、防腐蚀）在流道内循环，直接吸收芯片热量，再通过管路将热液体输送到冷却模块，降温后循环使用。

优势是改造无需改变服务器结构，支持“液冷+风冷”混合模式，适配10-30kW/机柜的场景，PUE可降至1.15-1.25，改造周期仅2个月。机柜密度可以提高20kW以上。

（2）浸没式液冷：

让服务器泡冷水澡，相当于把整个服务器，放进一个装满特殊冷却液的“浴缸”里，全程浸泡散热。

所用的冷却液（矿物油、氟化液）是绝缘、无毒、不导电的，不会对服务器部件造成损坏。服务器完全浸没在冷却液中，运行时产生的所有热量，都会被冷却液直接吸收，冷却液吸热后会自然对流，将热量传递到容器壁，再通过外部冷却系统降温，部分还能利用冷却液的相变（液体变气体），实现高效吸热。

这种方式的散热效率是冷板式的2-3倍，适配30-100kW/机柜的高密度智算场景，PUE可低至1.05-1.15，几乎没有风扇噪音（可低至45分贝），还能大幅节省机房空间。中兴通讯怀来项目部署48kW机柜，年节电超110万度，CO₂减排900吨；华为全液冷方案在50kW机柜上，年省50万度电，减排237.5吨。

（3）两相液冷：

这是更先进的液冷技术，基于航天级相变原理，利用液体气化时的潜热换热，散热效率是风冷的1000倍以上，能应对100kW以上的极端算力场景。

原理是让冷却液在发热部件表面沸腾，从液体变成气体，这个过程会吸收大量热量，气体上升后遇到冷却管，再凝结成液体，循环往复。塔能科技泵驱两相系统实现PUE≤1.12，某南方电信机房改造后PUE从1.8降至1.196，制冷负载系数（CLF）仅0.036。

3. 优劣势：高效节能，但门槛较高

液冷的核心优势，完美解决了风冷的痛点，适配算力爆发的需求：

• 散热效率极高：液体导热能力远超空气，能轻松应对高密度算力的发热需求，避免服务器因过热宕机；
• 能耗极低：制冷系统能耗大幅降低，能实现PUE≤1.1，部分项目可达1.04，符合国家“双碳”和节能政策；
• 噪音小、稳定性强：减少或取消风扇，机房噪音大幅降低；同时液体温度波动小，能将芯片温度控制在55℃以下，较风冷低15℃，芯片故障率下降30%，服务器寿命延长2-3年；
• 可回收余热：液冷系统回收的高温冷却液，可用于机房供暖、热水供应等场景，实现能源二次利用，北方某智算中心通过余热回收，额外实现年节能15%。

但液冷也有明显的短板，限制了其快速普及：

• 初期成本高：设备采购、管路铺设、机房改造的投入，比风冷高10%-30%，冷却液（尤其是氟化液）价格较高；
• 运维难度大：需要专业的运维人员，负责监测管路漏液、冷却液更换和补充，漏液若未及时发现，可能损坏服务器；
• 兼容性有限：浸没式液冷需要专用服务器，无法直接适配传统风冷服务器，改造存量机房的成本较高。

三、风冷vs液冷：

很多人会觉得，液冷崛起后，风冷就会被淘汰，但实际上，两者并不是“非此即彼”的关系，而是根据算力需求，形成互补共生的格局。简单来说：低算力、低成本需求，风冷依然是最优选择，比如中小型企业的算力节点、传统办公用的服务器机房，风冷的可靠性和低成本足以满足需求；高密度、高节能需求，液冷是必然趋势，比如AI大模型训练中心、大型云厂商的算力集群，液冷能破解散热和能耗困局，长期来看能节省大量电费，2年左右即可回收初期额外投入。

四、未来趋势：液冷普及加速，风冷持续优化

随着“东数西算”工程推进，以及国家对数据中心PUE的严苛要求（2025年新建数据中心PUE≤1.3），液冷技术的普及速度会越来越快。行业趋势显示，液冷在算力中心的占比，将从2025年的15%升至2030年的50%，标准化也会加速，未来会出台液冷系统设计、测试的统一规范。

同时，液冷技术也在不断升级：漏液检测技术越来越精准（可实现秒级响应），冷却液成本持续下降（规模化采购可降低40%），国产化替代加速，华为、塔能等企业已实现冷板、工质、控制算法全链条自主可控，打破国外技术垄断。

而风冷也不会被淘汰，而是会持续优化——比如优化风扇转速调节、改进散热片设计、采用间接蒸发冷却技术，提升散热效率、降低能耗，适配中低端算力需求，与液冷形成“高低搭配”，共同支撑算力时代的发展。

一、风冷：算力中心的“传统空调”，可靠但遇瓶颈

风冷，顾名思义，就是用空气作为散热介质，靠“吹风”带走服务器的热量，原理和我们家用空调、电风扇几乎一致，是目前应用最广泛、最成熟的散热技术，遍布各类中小型算力中心。

1. 核心原理：

风冷系统主要由两部分组成：服务器内部的散热风扇，以及机房整体的精密空调或列间空调。服务器运行时，CPU、GPU等核心部件会快速发热，内部风扇会加速转动，将冷空气吸入机箱，冷空气穿过散热片（吸收芯片热量）后，变成热空气被排出机箱；机房的精密空调则负责制造冷风、控制机房温度和湿度，将热空气冷却后循环利用，形成完整的散热闭环。

简单说，风冷就像给发烧的人吹电风扇，靠空气流动带走体表热量，技术逻辑简单，不需要复杂的管路设计。

2. 主流类型

风冷分为两种常见形式，适配不同场景：

• 被动风冷：完全依靠自然对流和散热片散热，没有风扇，静音、无能耗，但散热效率极低，仅适用于发热量极小的低端服务器，现在已基本淘汰。
• 主动风冷：就是我们现在最常见的形式，服务器内置风扇、机柜搭配散热风机，机房配备精密空调，可通过调节风扇转速、空调温度，适配不同的发热场景，散热效率比被动风冷高5-10倍，能应对单机柜功率密度≤10kW的传统算力需求。

3. 优劣势：成熟可靠，但扛不住高密度算力

风冷能沿用多年，核心优势在于“简单实用”：

• 成本低：设备采购、安装和维护都很简单，初期投入少，运维人员上手快；
• 可靠性高：没有复杂的管路和液体介质，不存在漏液风险，故障率极低；
• 兼容性强：适配所有类型的服务器，改造难度小，存量算力中心升级成本低。

但随着AI大模型、云计算的爆发，算力密度大幅提升（部分智算中心单机柜功率突破50kW），风冷的短板也越来越明显，逐渐触及物理极限：

• 散热效率低：空气的导热系数仅为0.026W/(m·K)，导热能力极差，当机柜功率超过15kW时，多台空调叠加运行也难以降温，甚至会限制服务器性能，被动降频，导致计算效率下降30%；
• 能耗极高：制冷系统（精密空调、风扇）的能耗占算力中心总能耗的30%-40%，是名副其实的“能耗黑洞”，导致PUE（能源利用效率）居高不下，南方地区夏季风冷PUE普遍突破1.6，难以满足国家新建数据中心PUE≤1.3的要求；
• 噪音大：服务器风扇和机房空调持续运转，噪音可达80分贝，相当于站在马路边，对机房环境要求较高。

二、液冷

液体的导热效率是空气的20倍以上，比热容是空气的4倍。现在，液冷已成为高端智算中心、AI训练集群的“首选方案”，能实现PUE低至1.04，较风冷节能40%-50%。

1. 核心原理

液冷的核心的是用液体介质（水、矿物油、氟化液等）替代空气，直接或间接接触服务器发热部件，通过液体对流和相变吸热，将热量快速带走，再通过冷却系统将热水（或热液体）降温，循环利用。

与风冷相比，液冷的核心突破的是取消了高功耗的空调压缩机，改用低功率的闭式冷却塔和冷量分配单元（CDU），制冷系统能耗降低90%以上，从根源上实现节能。

2. 主流类型：三种技术，适配不同算力场景

根据液体与服务器部件的接触方式，液冷主要分为三种，各自有明确的适配场景，目前冷板式和浸没式应用最广泛：

（1）冷板式液冷：给核心部件“敷冷毛巾”

这是目前最主流、最易落地的液冷技术，相当于给CPU、GPU等核心发热部件，贴了一块“可循环制冷的冷毛巾”。

原理是将铜或铝制的冷板，紧密贴合在芯片等发热部件表面，冷板内部有密闭流道，乙二醇溶液（防结冰、防腐蚀）在流道内循环，直接吸收芯片热量，再通过管路将热液体输送到冷却模块，降温后循环使用。

优势是改造无需改变服务器结构，支持“液冷+风冷”混合模式，适配10-30kW/机柜的场景，PUE可降至1.15-1.25，改造周期仅2个月。机柜密度可以提高20kW以上。

（2）浸没式液冷：

让服务器泡冷水澡，相当于把整个服务器，放进一个装满特殊冷却液的“浴缸”里，全程浸泡散热。

所用的冷却液（矿物油、氟化液）是绝缘、无毒、不导电的，不会对服务器部件造成损坏。服务器完全浸没在冷却液中，运行时产生的所有热量，都会被冷却液直接吸收，冷却液吸热后会自然对流，将热量传递到容器壁，再通过外部冷却系统降温，部分还能利用冷却液的相变（液体变气体），实现高效吸热。

这种方式的散热效率是冷板式的2-3倍，适配30-100kW/机柜的高密度智算场景，PUE可低至1.05-1.15，几乎没有风扇噪音（可低至45分贝），还能大幅节省机房空间。中兴通讯怀来项目部署48kW机柜，年节电超110万度，CO₂减排900吨；华为全液冷方案在50kW机柜上，年省50万度电，减排237.5吨。

（3）两相液冷：

这是更先进的液冷技术，基于航天级相变原理，利用液体气化时的潜热换热，散热效率是风冷的1000倍以上，能应对100kW以上的极端算力场景。

原理是让冷却液在发热部件表面沸腾，从液体变成气体，这个过程会吸收大量热量，气体上升后遇到冷却管，再凝结成液体，循环往复。塔能科技泵驱两相系统实现PUE≤1.12，某南方电信机房改造后PUE从1.8降至1.196，制冷负载系数（CLF）仅0.036。

3. 优劣势：高效节能，但门槛较高

液冷的核心优势，完美解决了风冷的痛点，适配算力爆发的需求：

• 散热效率极高：液体导热能力远超空气，能轻松应对高密度算力的发热需求，避免服务器因过热宕机；
• 能耗极低：制冷系统能耗大幅降低，能实现PUE≤1.1，部分项目可达1.04，符合国家“双碳”和节能政策；
• 噪音小、稳定性强：减少或取消风扇，机房噪音大幅降低；同时液体温度波动小，能将芯片温度控制在55℃以下，较风冷低15℃，芯片故障率下降30%，服务器寿命延长2-3年；
• 可回收余热：液冷系统回收的高温冷却液，可用于机房供暖、热水供应等场景，实现能源二次利用，北方某智算中心通过余热回收，额外实现年节能15%。

但液冷也有明显的短板，限制了其快速普及：

• 初期成本高：设备采购、管路铺设、机房改造的投入，比风冷高10%-30%，冷却液（尤其是氟化液）价格较高；
• 运维难度大：需要专业的运维人员，负责监测管路漏液、冷却液更换和补充，漏液若未及时发现，可能损坏服务器；
• 兼容性有限：浸没式液冷需要专用服务器，无法直接适配传统风冷服务器，改造存量机房的成本较高。

三、风冷vs液冷：

很多人会觉得，液冷崛起后，风冷就会被淘汰，但实际上，两者并不是“非此即彼”的关系，而是根据算力需求，形成互补共生的格局。简单来说：低算力、低成本需求，风冷依然是最优选择，比如中小型企业的算力节点、传统办公用的服务器机房，风冷的可靠性和低成本足以满足需求；高密度、高节能需求，液冷是必然趋势，比如AI大模型训练中心、大型云厂商的算力集群，液冷能破解散热和能耗困局，长期来看能节省大量电费，2年左右即可回收初期额外投入。

四、未来趋势：液冷普及加速，风冷持续优化

随着“东数西算”工程推进，以及国家对数据中心PUE的严苛要求（2025年新建数据中心PUE≤1.3），液冷技术的普及速度会越来越快。行业趋势显示，液冷在算力中心的占比，将从2025年的15%升至2030年的50%，标准化也会加速，未来会出台液冷系统设计、测试的统一规范。

同时，液冷技术也在不断升级：漏液检测技术越来越精准（可实现秒级响应），冷却液成本持续下降（规模化采购可降低40%），国产化替代加速，华为、塔能等企业已实现冷板、工质、控制算法全链条自主可控，打破国外技术垄断。

而风冷也不会被淘汰，而是会持续优化——比如优化风扇转速调节、改进散热片设计、采用间接蒸发冷却技术，提升散热效率、降低能耗，适配中低端算力需求，与液冷形成“高低搭配”，共同支撑算力时代的发展。

近期，金融监管部门公布了多起银行因数据管理、数据安全相关问题被处罚的案例。其中，浙江绍兴某农商银行因违反数据安全与网络安全管理规定等多项要求，被处以较大金额罚款；邮储银行某分行也因“数据管理不审慎”等问题受到行政处罚。这些事件再次表明，在金融业务高度数字化、系统高度互联的背景下，数据已经不仅是资产，更是必须被严格管理与持续审计的核心对象。

从监管逻辑看，当前对金融机构的要求，已经从“有没有制度”转向“有没有能力”，从“事后追责”转向“事前防控”。尤其是在接口化、平台化、生态化的金融IT架构中，数据的流动越来越依赖API接口完成，数据接口是否可控、可审计、可溯源，正成为金融数据安全治理的新焦点。在实际业务运行中，金融机构的数据流转大多通过各类API接口完成：核心系统与业务中台、渠道系统、外部平台之间，持续进行高频的数据交互。数据接口越多、调用越频繁，系统运行效率越高，但同时，风险也越隐蔽。很多机构面临的现实情况是：数据在不停地“跑”，但数据接口调用的行为是否合理、是否越权、是否存在异常模式，却难以及时、全面地掌握。传统安全体系更多关注网络边界、主机、数据库本身，对“数据接口层面的行为风险”缺乏持续、智能的监测手段，容易形成监管与实际运行之间的“能力断层”。当数据接口成为数据流动的主要通道时，如果缺乏系统化、可视化的风险感知能力，就很难真正做到数据使用的可控与合规。

知影-API风险监测系统——让数据接口安全真正“看得见、管得住”

正是基于金融行业对数据接口安全的现实需求，全知科技推出了「知影-API风险监测系统」。该系统面向金融机构API接口场景，构建以“行为感知 + 风险识别 + 可视治理”为核心的新一代API安全监测平台，帮助机构实现从“被动防护”向“主动风控”的转变。

1、核心功能：基于智能算法的多维风险监测

「知影-API风险监测」模块是系统的核心能力，融合了多维检测模型、动态基线分析和自适应防护策略三大技术体系，实现从“识别”到“处置”的全流程防护。
API识别与梳理：摸清资产“家底”
支持RESTful、SOAP等主流格式，API识别准确率超98%；实时洞察敏感信息，覆盖多领域数据标签并动态更新暴露面；通过独创算法完成API四级分类分级，聚焦高风险资产；自动跟踪API全生命周期状态，确保资产清单同步。
弱点检测：提前堵住漏洞
集成OWASP API Top10，内置50+项弱点规则；精准识别逻辑异常、硬编码密钥等风险，结合数据泄露行为分析影响面；提供弱点测试与修复建议，实现闭环整改。
风险防护：动态拦截威胁
基于API画像实时监测异常行为；依托自研引擎构建三大维度风险规则，秒级识别适配多行业；自动建立并调整智能基线降低误报，支持自定义指标，可对恶意IP阻断、限流。
审计溯源：实现责任
可追结构化提取关键信息，平衡存储效率与溯源需求；提供线索、主体双模式溯源，1小时内定位责任方。
多节点管理：适配复杂部署
支持多城市、多机房跨地域部署及流量本地化处理；节点数据汇聚中心节点，实现资产、风险统一管理与配置下发，降低运维成本。2、产品优势：轻量高效、智能联动的防护体系

AI驱动更智能：融合大模型技术，实现资产识别、风险降噪、策略调整自动化，响应时间从小时级缩至秒级。
覆盖场景更全面：适配互联网、生产网、办公网等多元环境，支持金融、运营商等多行业需求。
合规适配更精准：满足《数据安全法》《个人信息保护法》及行业规范，日志留存、审计溯源符合合规要求。
联动能力更强：可与全知自有产品（数据资产地图、数据脱敏系统）及第三方安全工具联动，形成全域防护网。

随着金融业务不断向平台化、生态化发展，数据安全治理正在从单点技术建设，走向体系化能力构建。数据接口不只是连接系统的“管道”，而是数据合规与风险控制的核心节点。只有把API风险监测纳入整体数据安全治理框架，与数据分类分级、数据库审计、日志审计、合规管理等能力协同联动，金融机构才能真正构建起“看得见流动、控得住使用、管得住风险”的数据安全底座。而「知影-API风险监测系统」，正是这一治理体系中不可或缺的“感知层”和“前哨站”。

面向金融行业数据要素流通与风险治理不断深化的新阶段，全知科技将持续围绕核心场景需求，深化数据接口安全技术与AI能力的融合应用，在“看得见风险”的基础上进一步实现“预判风险、降低风险、治理风险”。值得一提的是，由全知科技牵头，公安部第三研究所、中国电子技术标准化研究院 、国家信息中心 、中国信息通信研究院等制定的 《数据安全技术 数据接口安全风险监测方法》国家标准已正式发布，将多年技术积累与一线场景经验转化为行业通用的方法论与规范框架。未来，在标准与AI双轮驱动下，全知科技将不断夯实金融行业数据接口安全与数据治理的技术底座，助力金融机构在数字化与合规要求持续升级的环境中，实现真正可控、可视、可持续的数据安全治理。

作者：

徐榜江(雪尽) ，阿里云Flink数据通团队负责人，Flink PMC 成员，Flink CDC 开源项目负责人

李昊哲(米灵)，阿里云Flink高级产品经理，负责阿里云 Flink 稳定性、可观测性、数据摄入等企业级产品特性

内容概要

本文主要介绍阿里云基于开源 Flink CDC 打造的企业级日志实时入湖入流的技术解决方案，涵盖产品功能介绍、日志场景挑战与解决方案、最佳实践案例以及联合解决方案等内容。

一、阿里云企业级Flink CDC数据摄入功能介绍

1、Flink CDC开源项目概述

开源 Flink CDC 是一款用于处理数据变更捕获（Change Data Capture）、支持增量数据的分布式数据集成工具。该项目早期主要聚焦于数据库入库入仓场景，在数据库增量数据同步领域积累了丰富的实践经验。

从 3.0 版本开始，Flink CDC 支持通过 YAML 格式描述数据传递过程以及 ETL 转换逻辑，极大简化了用户的数据集成与同步工作。Flink CDC 的核心价值在于结合数据库的变更捕获技术（Data Capture），打造全增量一体化的集成框架，有效降低用户的使用成本，同时满足数据时效性与一致性方面的需求。

Flink CDC 最主要的应用场景是在数仓分层架构中作为数据入湖入仓的第一步。增量快照算法是其核心能力之一，支持读取历史数据、全增量一体化同步以及整库同步等功能。此外，Schema 信息管理功能在后续版本迭代中持续增强，进一步提升了用户对社区的信任度与粘性。YAML ETL 将复杂的高级功能平民化，使更多 BI 领域的用户能够通过 YAML 脚本完成复杂的作业配置。Flink CDC 在社区的主要应用场景集中在数据库的实时入湖入仓领域。

在传统数据同步方案中，用户通常需要分别处理全量数据与增量数据，使用不同的链路与业务系统，最终通过定时合并完成数据同步。这种 Lambda 架构存在以下问题：链路组件较多，数据合并的时效性较差，且合并过程中存在位点无法强对齐的情况，容易导致数据一致性问题。对于研发人员而言，技术栈过于复杂，普通用户难以驾驭。

Flink CDC 将上述复杂流程整合到一个 YAML 作业中，实现全增量一体化，Flink 作业可支持亚秒级延迟。框架层面从原理上保证数据不丢不重，同时提供端到端的作业管理体验。用户仅需编写一个 YAML 文本即可启动作业，这是 Flink CDC 在社区中最核心的应用场景。

2、阿里云企业版Flink CDC对比开源Flink CDC

阿里云企业版 FlinkCDC-数据摄入在开源基础上对企业版进行了多项增强，主要包括以下几个方面：

引擎层面优化：阿里云企业版引擎内部称为 VVR，在作业自动调优、数据摄入（即 Flink 作业的热更新能力）、State Backend、SQL 算子等方面均进行了企业级优化。资源分配方面支持弹性力度的动态调整。

管控平台支持：阿里云提供 VVP 平台负责 Flink 作业的开发与运行。相比开源版本仅支持数据库入湖入仓，VVP平台扩展支持了日志入湖入仓，具备更丰富的企业级上下游生态。

阿里云产品之间相互打通，整体用户体验更佳。平台支持资源动态扩缩容、全链路监控、告警机制等功能，同时支持 YAML 作业的全生命周期管理，包括作业版本管理、日志查询、资源配置、依赖管理等。

阿里云企业级 Flink CDC 的定位是在开源内核的基础上，通过插件化开发提供更多增值服务，提升易用性并降低开发运维门槛。

阿里云企业版Flink CDC-数据摄入产品优势

阿里云 Flink CDC 数据摄入的产品优势可从功能特性与性能成本两个维度进行阐述。

功能优势：提供更多企业级功能特性，包括引擎侧有更强大的表结构变更自动同步（无需作业重启）和 DB 入湖场景的数据限流功能，以及日志入湖场景的 Schema Inference 能力、全链路脏数据收集功能等。得益于阿里云 Flink 产品底座的长期建设，CDC YAML 作业也能复用诸多企业级能力，比如弹性扩缩容、Hot-Update 资源调优、监控和告警等能力，同时具备丰富的数据源支持，涵盖大数据存储、关系数据库、湖仓、流存储等上下游生态。

性能优势：阿里云 Flink CDC 数据摄入在读取和写入上均做过深度的性能优化，在读取 MySQL 和 MongoDB 场景，支持了多线程解析和高效下推过滤等优化，对比社区有数倍性能优势。在写入 Paimon 和 Fluss 时均支持 Dynamic Shuffle 优化，能够根据每个并发的实时数据量自适应调整写入流量分布，作业运行更加智能和平稳。此外，CDC YAML 作业默认支持整库同步或多表入湖，单 Sink 节点可写多表的拓扑模式，避免拓扑节点过多导致资源消耗过大、部分表数据量少造成资源浪费等问题。

最佳用户体验体现在端到端 Pipeline 的便捷性上：用户仅需关注 YAML 文本，作业提交与部署均由平台自动完成。阿里云还提供丰富的场景与最佳实践方案文档，用户可根据实时数仓、数据库或结合 Fluss 等不同业务场景参考相应的最佳实践，直接复制粘贴 YAML 文本即可。另外，作为云产品，SLA 保障、运维监控体验更佳。

当前最新版本已迭代至 VVR 11.5，该版本功能最全、稳定性最佳，建议用户使用最新的稳定版本以获得更好的用户体验。

二、日志场景实时入湖入流的趋势与挑战

随着 AI 技术、Agent 以及 AGI 等技术的兴起，AI 应用日益普及，用户对非结构化数据、日志数据乃至多模态数据的需求持续增长，Flink CDC 需要具备更强的数据接入能力。

日志实时入湖入流可为数据分析与 AI 两大赛道解锁更加新鲜的数据，帮助业务运营人员、决策人员乃至 Agent 完成更快的业务决策。数据新鲜度越高，基于数据的判断就越准确，这在风控反欺诈、广告投放等时间敏感的业务场景中尤为关键。

1、日志场景的业务痛点

日志入湖入流领域存在以下三个主要痛点：

数据定义多样化：与数据库数据不同，日志数据定义极为多样化。不同应用甚至同一应用的不同终端（如手机、iPad）采集的日志数据格式可能不同，语义也可能不一致，缺乏统一标准。数据库表字段通常固定且有明确类型约束，而日志数据可能存在 Integer、Bigint、Big Decimal 等不同类型表示同一语义的情况。因此，该场景需要具备数据规范化处理能力。

日志加工时效性要求高：日志数据规模通常较大，需要实时采集处理。这不仅是对日志入湖工具系统的要求，更是端到端的要求。海量实时批量数据对数据湖引擎（如 Flink、Starrocks 等）的分析能力提出了更高要求，各子系统均需满足端到端的高性能需求。

表结构变更频繁：日志数据定义多样化、终端不确定性及多版本迭代导致表结构变更频繁。数据库表变更通常需 DBA 审核，遵循加字段而非删字段的最佳实践。而日志场景灵活性高，终端采集字段的增删变化是常态。这要求端到端日志处理链路具备 Schema 推断与演进能力，支持从无 Schema 的裸 JSON 数据推断 Schema，并在下游 ODS 表自动新增字段，对技术能力提出更高要求。

2、基于阿里云企业级Flink CDC日志实时入湖入流解决方案

阿里云 Flink CDC 提供一键实时入湖功能，用户仅需编写 YAML 文本即可完成日志的实时入湖入流。入湖支持 DLF 的 Paimon Sink 服务格式，入流支持 Fluss 等流存储。

传统日志入湖入流方案通常将日志数据采集到消息队列（如 Kafka、SLS），然后通过编写 Java 代码（如 Flink DataStream 作业）进行解析处理，每个字段需手动判断处理，拓扑需根据下游表数量配置。这种方案门槛较高，要求用户熟练掌握 Java 与 Flink 核心概念，需手动处理表结构推导，且作业是黑盒不可见，开发、迭代与资源调优均较困难。

阿里云通过 YAML 方式支持 Kafka、SLS 等数据源，可自动对 Topic 内数据进行 Schema 推断与推导，并通过路由写入下游不同表。用户仅需编写 YAML 文本即可实现零代码开发，Schema 自动推导，业务复制修改即可复用。开发调优体验类似 SQL 开发，修改配置参数或动态加表均可在平台上直接编辑。

3、基于阿里云企业级Flink CDC日志实时入湖入流客户案例

某用户业务场景中，数据已采集至 Kafka，包含 DB 字段与 Table 字段，需将一个 Topic 的数据分发至下游八千多张表，要求一个作业完成。用户期望根据 DB 与 Table 字段自动建表并同步数据，新增列时 ODS 表自动加列。

该场景通过一个 YAML 文本即可解决，支持下游自动建表、分库分表、Schema 自动推导。UserId 自动推断为 String 类型，EventTime 推断为 Timestamp 类型。支持数据清洗（如 Projection 只选特定字段）、Where 过滤、UDF 过滤、表名转换等功能。

用户数据进入 DLF（Paimon、Iceberg）后，可基于 Flink 加 DLF 方案，结合 Starrocks 构建实时数仓完整解决方案，数据入湖过程高效便捷。

三、基于阿里云企业级Flink CDC日志入湖入流最佳实践

1、作业配置示例

以下是一个线上的真实作业示例，API 与社区 Amazon API 一致。配置包含 Source（数据源，如 Kafka）与Sink（目标端，如 Paimon）。Transform 为可选数据转换配置，可指定所有列或通过Projection选择特定字段。可通过组件配置指定主键字段，如用 ID 作为主键。Route 可进行表名映射，如将 user 表映射为 origin\_user 或 ODS\_user 表。简单的 YAML 文本即可在阿里云 Flink 完成数据摄入作业开发。

YAML 文本提交后将自动生成线上Flink作业，支持部署配置、Metric 监控、告警配置等功能。作业日志查询、Metric 查询、配置告警等体验与全托管Flink作业一致。

2、核心特性说明

数据过滤与计算：支持 MySQL 语法风格的数据过滤与计算，对用户友好。例如可对表内age字段进行过滤（如 age 大于100的数据），或统计字段长度。提供内置函数与内存函数，支持 UDF 调用及 SQL 表达式调用，实现数据过滤与清洗。在数据过滤时，斜杠星（/*）表示匹配原数据所有字段，且支持 Schema Evolution。假设原数据有 ID、name、age 三个字段，新增address字段后，作业会自动在下游添加该字段，计算列与filter规则继续生效。

组件与分区键重定义：支持重新定义主键与分区键。例如 MySQL 表主键为 ID，但希望 DLF 数据湖表将主键换成其他字段或增加分区键（因多个数据库实例数据写入同一张表）。YAML 中可指定 PK 与分区键。

Pre Transform 与 Post Transform 执行逻辑不同。Pre Transform 侧重原数据修改，包括修改表主键、分区键、加列等操作。Post Transform 侧重数据处理，包括 Filter 与 Projection。两个算子通常嵌入为一个 Transform，既支持 Schema 裁剪与重定义，也支持数据过滤与处理。

3、日志入湖-DLF（Paimon）快速入门

阿里云 DLF 提供全托管 Paimon，可以参考阿里云的帮助文档，文档采用 Step By Step 方式，从配置白名单、准备测试数据到编写作业，用户可按步骤完成快速入门。文档中提供完整可运行的作业样例，用户只需替换 Kafka 地址与 Topic，可选配置已加上注释说明。此外，文档包含脏数据处理能力配置、Deletion Vector 优化配置等内容，用户参照文档即可将 Kafka 日志数据通过 Flink CDC 一键写入阿里云 DLF（Paimon）。

4、日志入流-流存储Fluss版快速入门

阿里云提供全托管 Fluss，当前已经开启公测。Fluss 作为流存储，相比原生 Kafka，在列裁剪、Schema 化、湖流一体化等方面优势明显。将原始采集数据同步至 Fluss 后，可构建流式数仓，对 Paimon 数据进行加工处理。Fluss 场景支持类似配置，将 Source 换为 Kafka，Sink 换为 Fluss，提交 YAML 文档后作业即可运行。即使 Kafka 内数据为无 Schema 的 JSON，也会自动推导 Schema。

5、日志入湖入流最佳实践

自动推导表结构

Flink CDC 数据摄入支持丰富的推导表结构策略，默认策略为自动推导表结构，该策略默认配置适用于大多数业务场景。比如通过配置预读取 Kafka 记录数为100，从指定新位点消费累计100条数据，对100条数据的 Schema 进行推导，获取推导的最宽表结构作为初始表结构。例如前面50条推导出10个字段，后面50条推导出12个字段，最终合并为最宽的15-16个字段作为下游 Paimon 表结构，自动建表并写入数据，缺失字段填 Null。

灵活指定表结构

Flink CDC 数据摄入也支撑用户手动指定初始表结构，如下图所示用户可通过 DDL 语句声明作业初始化表结构，您可以直接粘贴下游已有表的 DDL，比如通过 Flink Catalog 执行 show create table 命令快速获取您期待的初始表结构。语法与 Flink SQL 对齐，指定初始表结构后按该结构继续演进。适用于 Kafka Topic 数据太少或尚未开始采集的场景，可先编写数据摄入作业，数据到达后自动拉起。

部分字段指定类型，自动推导可能存在误差，用户可指定部分字段为固定类型。如指定 ID 为 bigint 或 string，name 为 varchar 等。对于不符合规则的数据，可通过脏数据收集器处理。灵活指定表结构以满足特定业务需求。

脏数据处理

日志场景与数据库不同，弱结构化数据不可避免存在脏数据。阿里云提供脏数据容忍与收集配置：用户可设置脏数据容忍条数，脏数据支持收集。业务运行时不查看脏数据，过后可据此调整下游 Schema 或反馈给上游业务方，确保 Pipeline 稳定运行。

常见问题排查

阿里云积累了大量常见问题与排查手段，相关链接已整理。包括 Flink CDC 数据摄入的常见问题与解决方案，涵盖数据库入湖、日志入湖等场景。日志场景最多涉及 Kafka 与 SLS 两类，问题总结包括配置方法、网络联通性、嵌套 JSON 格式解析等，用户可参照文档快速排查。

四、阿里云企业级Flink CDC联合解决方案

1、湖流一体解决方案：阿里云企业级Flink CDC+Fluss+Flink+Paimon

基于 Fluss 加 Flink 加 Paimon 的湖流一体解决方案中，Flink CDC 作为数据接入层，可接入数据库数据、日志数据、OSS 数据（OSS 支持开发中），摄入至 Fluss 与 Paimon。

对时效性不敏感的业务可直接写入 Paimon，对时效性要求更高的业务先写入 Fluss，通过 Fluss 的湖流一体能力自动将热数据写入 Paimon。Flink CDC 支持直接写入 Fluss 或直接写入 Paimon。用户可基于此方案，结合 OLAP 查询引擎（如 Starrocks、SelectDB 等）完成报表、Dashboard、数据探查、数据分析等应用。

根据业务场景选择方案：中级时效需求通过数据摄入直接写 Paimon；秒级时效需求先写 Fluss 加速再写 Paimon。端到端实时数仓可达到秒级时效。

2、金融入湖入仓解决方案：阿里云企业级Flink CDC+ EMR StarRocks +EMR Spark

阿里云某金融行业客户案例具有一定代表性。客户原数据架构包含数据采集、数据库、数据应用及离线调度。阿里云基于 Flink CDC 数据摄入对原有方案升级为实时数仓架构，替代自建 Kafka 集群，大幅降低自建 Kafka 集群的管理运维成本。Flink 作业直接采集至 Kafka 后，可通过 Flink SQL 进行实时 ETL、聚合等复杂分析，也可通过 Flink CDC 日志入湖能力将 Kafka 内的 JSON 等日志类型数据直接写入数据湖，再进行后续的计算和分析。

该方案在客户环境稳定运行一年多。开源方案在企业级场景存在性能瓶颈与运维管理困难，阿里云方案开箱即用，资源弹性几分钟内即可扩展。Flink CDC 采集能力提升 50% 以上，实时计算性能相比开源内核提升 2-3 倍，在大型性能要求极致场景中得到客户认可。

3、智驾实时数据湖解决方案：阿里云企业级Flink CDC+DLF(Paimon)

汽车行业尤其是新能源汽车快速发展，阿里云 Flink CDC 与某行业头部客户在自动驾驶场景展开合作。车端数据量巨大，采集后通过 Flink CDC 写入数据库，基于数据库进行模型训练、搜索等自动驾驶业务场景。

Flink CDC 处于业务链路前端，快速接入端侧数据，后续链路处理能获取更新鲜的数据，业务效果更佳。支持端侧日志数据入湖，数据库数据（关系型 DB、NoSQL DB 如 MongoDB）摄入。开源版本已具备初步能力，企业版进一步优化性能，帮助头部客户快速完成自动驾驶场景数据湖方案建设。

五、总结

阿里云 Flink CDC 数据摄入旨在快速高效智能化地将用户数据写入数据湖与流存储，主要包含两类场景：数据库与日志。

数据库场景核心能力：Schema Evolution、表级入湖、整库同步、内置函数与 UDF 处理、数据限流（避免打挂核心业务库）。

日志场景核心能力：Schema Inference（从杂乱无章原数据推出表结构和结构化数据）、主键与分区键灵活指定、脏数据处理（日志场景脏数据较为常见）、多表拆分入湖（Kafka Topic 较贵，单 Topic 可能存储数百上千张表数据）、JSON 智能解析（筛选特定字段、字段合并规则、版本号字段映射等）。

阿里云 Flink CDC 针对数据库与日志场景分别打造企业级核心能力与最佳实践，适用于阿里云 Flink 产品用户或开源用户，均可获得启发与参考。这些最佳实践是云产品孵化过程中踩坑沉淀的结晶，云上用户可获得更多底座能力支持，与兄弟团队云产品 DLF、Fluss、Hologres、Maxcompute、Starrocks 深度融合，打通用户体验，开箱即用。

阿里云企业级 Flink CDC 在 Serverless Flink 中可以直接使用，入湖场景支持多种湖格式，已支持 DLF Paimon、DLF Iceberg 和 Fluss 等，对 Paimon 与 Fluss 的支持走在业界前沿。

实时湖仓场景中，Flink CDC 核心功能为入湖入仓，支持写入 DLF、EMR-Starrocks、Hologres、Maxcompute。湖流一体方案中，Flink CDC 将数据库业务库数据与日志业务日志高效写入 Fluss 流存储，再通过 Fluss 自动同步至 Paimon，形成湖流一体解决方案，在实时湖仓基础上为核心业务提供更高实时性。

经典实时数仓解决方案中，Flink 与 Hologres 团队合作推出的 Flink CDC 直接写入 Hologres 方案较为经典。Flink CDC 也支持写入 EMR Starrocks，用户可根据偏好选择商业产品或开源产品。无论是实时数仓、湖仓还是湖流一体方案，Flink CDC 数据摄入均能完成方案第一步。

欢迎大家免费开通 Serverless Flink 来使用企业级 Flink CDC，如需更多交流，可加入阿里云实时计算 Flink 版交流群，开源 Flink CDC 问题可在 Flink CDC 社区群讨论。

当前，我们正处在一个AI技术飞速发展的时代。企业运维的演进脉络清晰可见：从信息时代的效率提升与自动化，到数字时代的数据驱动与智能运维（AIOps）崛起，如今正大步迈向多智能体协作（Multi-Agent System, MAS）的新阶段。在这一新阶段，多智能体通过任务分解、知识共享与协同决策所形成的“群体智慧”，将推动运维从被动响应走向全面自主，成为企业驾驭复杂系统、保障业务连续性的关键。Bonree《智能体协同矩阵重塑自主运维新范式》白皮书点击下方海报或扫描二维码即刻免费下载👇

博睿数据重磅发布《智能体协同矩阵重塑自主运维新范式》白皮书。该书立足国内运维行业发展趋势，深度融合博睿数据在多智能体协作领域的实践经验与技术洞察，详解多智能体协作在运维体系化演进中的核心原理、架构设计、技术实现、落地路径与未来趋势，兼顾行业共性需求与企业个性化应用场景，为各行业布局智能运维、提升智能体协作下的运维效能提供全方位的理论支撑与技术指引。白皮书剖析了当前运维领域面临的共性难题，指出单点智能的局限性，并提出以多智能体协同为核心的解决方案框架。此外，白皮书重点阐述了博睿数据BonreeONE“三位一体”的智能体协作体系——通过基于Workflow的故障诊断Agent、基于知识驱动的故障诊断Agent、基于自主决策的故障诊断Agent三种不同类型的故障诊断Agent互补共存，以应对不同确定性的运维场景； 针对多智能体协作的特有需求，博睿数据创新性提出构建包含语义、认知、协作、成本、安全五大核心层面的立体化治理架构，全面覆盖多智能体协作全流程，保障协作的高质量、高效率与高可信度。多智能体协作正持续拓宽运维价值维度，推动运维体系向智能协同的新阶段演进，重塑智能运维生态格局，成为企业数字化韧性构建的核心支柱。博睿数据将依托多智能体协作这一“群体智慧”，助力企业构建高效、全域的智能可观测能力，迈向全面自主运维新征程。

关于博睿数据北京博睿宏远数据科技股份有限公司（简称博睿数据）(股票号688229）是AI驱动的全球智能可观测性领导者，蝉联中国应用性能管理及可观测性APMO市场份额第一，已获得1000+头部客户的选择和信赖。专注于构建以用户为中心的简捷，高效，智能的新型IT运维，有效提升云资源利用效率，驱动业务创新增长，助力企业提升核心竞争力，抢占数字经济先机。17年以来，博睿数据以深厚的技术积累不断打磨产品和服务能力，已在IT系统可观测领域形成了自身的独特优势，并将智能可观测解决方案落地到各种客户生产环境之中，为银行，证券，保险，高端制造等行业的数字化、智能化转型持续赋能，已经获得中国银行、中国工商银行、中国建设银行、国泰海通、国信证券、泰康保险、新华保险、华为、中国南方航空等1000+头部客户的选择和信赖。2026年4月17-18日，智能体驱动的 GOPS 全球运维大会将于深圳举行，博睿数据产品中心总监贺安辉将带来《智能体协同矩阵：重塑下一代故障智能诊断范式》的精彩演讲，敬请期待。

Bonree关于 GOPS 全球运维大会

当前，智能体（Agent）技术正以前所未有的深度重塑IT领域的生产范式。从运维自动化的闭环决策到开发环节的智能协同，从测试流程的自主验证到基础设施的AI驱动，智能体正成为推动研发运维体系向自治化、智能化演进的核心引擎。在这一关键发展窗口，第28届智能体驱动的GOPS全球运维大会2026 · 深圳站将于2026年4月17日-18日隆重启幕。大会由高效运维社区（GreatOPS）与BizDevOps软件工厂联合主办，DAOPS基金会、开放运维联盟（OOPSA）指导，作为业内IT技术的高端行业盛会，GOPS大会自2015年发起以来已成功举办27届，覆盖国内外城市包括北京、上海、深圳、美国硅谷、新加坡举办，主要面向IT行业的中高端技术人员，累计吸引超9万人次参会，覆盖金融、通信、制造、互联网等各行业一线技术决策者与实践者。本届大会为期2天，侧重运维智能体、开发智能体、测试智能体、AI Infra、AI+DevOps、SRE、AIOps、AI+可观测性等热门技术领域。与行业一线专家共同探讨智能体驱动下的技术变革。

随着数字化进程加快，各行各业的运营方式、服务模式以及核心资源正快速向数字领域迁移。这一重大变革改变了风险的布局，网络攻击不再是随机分布，而是如精准制导武器般，集中瞄准那些拥有高数据价值、业务中断影响大的行业领域，或是安全防御较为薄弱的目标。识别这些重点目标的特征及其弱点，不仅是理解风险的关键，更是一种基础性的威胁应对策略。JoySSL 有关专家指出，通过全面的行业分析可以得出结论，网络攻击的针对性让安全防护的基础设施重要性再次凸显。而数字证书的作用，早已超越了为网站提供加密保障的单一功能。在应对针对性极强的网络威胁时，能够凭借先进的加密技术与身份验证系统，有效抵御网络攻击，逐渐成为各行业在数字架构中构建“基础通信安全免疫”的必备工具，同时也随着数字威胁的升级，发挥着日益重要的作用，在现阶段不可或缺。

SSL证书应对网络攻击的行业偏好

金融领域是数字经济的“金库”，极易遭受黑客网络攻击，包括勒索软件、供应链攻击、API数据泄露等。SSL证书保护通信安全，确保数据在传输时不被非法截取。医疗领域则是存储个人健康信息的“保险库”，数据在黑市价格极高。数字证书保障医疗数据的绝对安全，避免因钓鱼攻击导致泄露。

电子商务是海量交易与消费者数据的关键平台，业务高度数字化，是不法分子的高度关注对象。SSL证书通过加密通信保护用户登录和支付环节的隐私安全，增强支付页面的信誉，平衡安全性与业务增长需求。

教育领域则被称为开放网络中的“知识存储库”，拥有海量的学生及教师个人信息，包含创新性研究成果和知识产权数据。数字证书保护网络教学平台及科研数据资源的访问安全，为开放式学术环境建立传输通信的安全基准，维护知识产权及个人隐私。

数字证书共通价值直击行业痛点

即使各行各业面临的安全威胁各不相同，SSL证书的技术解决路径却能精准解决共同的基础安全难题。无论是金融、医疗、电商还是教育领域，均以“加密传输”和“身份溯源”为核心基础，满足多项法律法规的要求，为数字化合法经营提供技术保障。

JoySSL技术专家解释道，借助SSL证书的强加密技术及服务器身份验证功能，可在通信阶段设置防护屏障，确保数据安全传输，提升钓鱼攻击难度。凭借安全类标识，建立品牌信任资产，提升企业竞争优势。

建立可信基础抵御不确定网络威胁

在数字化发展的过程中，安全问题既存在又分布不均。应对风险的关键，在于为所有数字交互构建基础且广泛的信任基石。虽然无法针对特定威胁，但却是行业稳定运作不可或缺的基本条件。

标题1：当时序数据成为工业底层能力：麦斯时代为何选择 TDengine

标题2：专访麦斯时代刘剑锋：钻石级合作背后，是一次长期路线判断

标题3：钻石分销合作背后：麦斯时代为什么选择 TDengine

在工业数字化进入深水区之后，越来越多企业开始意识到一个问题：真正限制系统上限的，往往不是应用功能，而是底层对时序数据的处理能力。

设备、工艺、能耗、安全、环保——这些最核心的数据形态，几乎全部以高频、连续、长期积累的方式存在。它们不是“报表型数据”，而是贯穿生产全过程的运行数据。一旦规模上来，传统数据库方案很容易在性能、成本或稳定性上同时失效。

正是在这样的背景下，麦斯时代与涛思数据达成了 TDengine 钻石级分销商合作。围绕这次选择背后的判断逻辑，我们与麦斯时代总经理刘剑锋（Jeff）进行了一次深入交流。

不只是技术选型，而是长期路线判断

在刘剑锋看来，当前时序数据市场的变化，并不是简单的“技术风口”，而是工业系统结构性变化的结果。

“在工业现场，几乎所有关键决策，都越来越依赖对运行数据的持续分析。但很多系统在设计之初，并没有为这种规模和频率的数据做好准备。”

在他过往参与的大型工业互联网项目中，这种矛盾反复出现：一方面，设备数量和采集频率不断上升；另一方面，数据系统却难以支撑长期、稳定、低成本运行，最终影响的是业务系统本身。

这也是麦斯时代判断时序数据库将成为工业数字化底层公共能力的核心原因。

在国内外众多时序数据库厂商都在布局渠道合作的背景下，麦斯时代最终选择 TDengine，并直接以最高级别钻石合作切入，这也并非偶然。

刘剑锋将核心原因归结为三个关键词：性能、成本与生态匹配度。“我们服务的工业场景，对读写性能和长期存储成本都极其敏感。TDengine 在这两点上的优势非常突出，而且不是通过复杂架构堆出来的，这对实际交付非常重要。”

但技术也并不是唯一因素。“对我们来说，生态合作的确定性同样重要。”刘剑锋表示，“TDengine 的合作伙伴体系不是停留在口头层面，而是把转售、市场、客户拓展等关键环节的权益与支持方式都提前明确下来。尤其是在钻石级别的合作机制下，无论是市场资源协同、客户拓展支持，还是长期能力共建的空间，都具备清晰预期，这让我们敢于在方案、团队和市场上做长期投入。”

这一合作背后，其实是一次对长期路线稳定性的判断。

先打穿一个行业，再谈规模复制

在落地策略上，麦斯时代并没有选择多行业同时推进。刘剑锋坦言，不同行业对时序数据的关注重点，本身就决定了落地路径不可能“一刀切”。

在矿山和冶炼行业，设备连续运行时间长、工况复杂，对设备可靠性和运行稳定性的要求极高；化工行业更关注安全与环保指标的持续监测；而汽车制造场景中，工艺一致性和质量追溯能力往往是核心诉求。关注点不同，也意味着数据模型、采集频率和分析方式存在明显差异。“如果没有对行业运行逻辑的长期理解，很容易只是在‘换一个数据库’，却解决不了真正的问题。”刘剑锋表示。

基于这一判断，麦斯时代选择优先在矿山和冶炼行业推动 TDengine 落地。这些行业不仅是麦斯时代积累最深、客户痛点最集中的领域，也更容易在真实生产环境中验证方案的稳定性和可复制性。

在具体实践中，这类场景往往同时面临高并发数据写入、海量历史数据长期存储，以及对实时分析响应的刚性需求。“我们会把 TDengine 作为核心数据底座，嵌入到现有的生产管理、能源管理、设备健康管理解决方案中，替代传统数据库模块。这不仅能极大缓解客户的数据存储压力，还能提升实时分析效率，为客户的精细化分析和 AI 技术落地提供优秀的数据底座。”

谈及合作首年的规划，麦斯时代并没有给出激进的扩张目标。“第一年最重要的不是铺量，而是把样板工程跑通。”刘剑锋强调。

按照规划，麦斯时代希望在 3–5 个重点行业中落地标杆项目，覆盖 20 家以上新客户，并在此基础上形成标准化、可复制的“TDengine + 麦斯时代”解决方案模型。“只要样板工程成立，后续的行业复制是自然发生的。”

不止是分销商，而是能力延伸者

作为一家深耕工业数字化 16 年的解决方案提供商，麦斯时代并不把自己简单定位为产品代理方。在刘剑锋看来，工业数字化项目的成败，往往不取决于某一项单点技术，而取决于技术是否真正融入业务流程，能否在长期运行中稳定发挥作用。

“我们不是把 TDengine 简单当作一个‘卖点’，而是要把它真正嵌入到客户的业务闭环里。”

这意味着，TDengine 在麦斯时代的解决方案中，并不是一个独立存在的数据库组件，而是与生产管理、能源管理、设备运维等业务系统一起，被纳入整体架构设计和交付体系之中。

在这种模式下，麦斯时代的优势也不再体现在某一项单点技术能力上，而是来自三方面的协同：对行业运行逻辑的长期理解、完整的解决方案交付能力，以及服务头部工业客户过程中积累的工程经验。只有同时具备这三点，数据库能力才能在真实工业场景中被“用起来”，而不是停留在技术选型层面。

也正因如此，刘剑锋将“钻石分销商”视为一种责任导向的角色，而不仅是权益层面的合作级别。“钻石分销商对我们来说，既是一种权益保障，更是一份责任承诺，我们要成为 TDengine 在工业领域的技术延伸和价值传递者，帮客户把能力用起来、跑稳定。”

从更长周期看，他将这次合作理解为一次工业应用生态与时序数据库能力的深度融合实践。“未来，我们希望与 TDengine 在行业数据模型、联合解决方案等层面展开更深入的协同，逐步沉淀出适合特定行业的通用方法和实践路径，甚至参与相关行业标准的探索与共建。”

他也对 TDengine 的后续演进提出了期待：“如果能在工业场景中提供更多开箱即用的适配能力，以及更贴近端侧的新产品形态，将显著提升整体交付效率。此外，我们也希望未来 TDengine 能开放更多联合方案推广与培训资源，助力生态伙伴提升交付能力。”

结语

在工业数字化的真实世界里，技术并不缺，缺的是能长期跑、敢规模用的底层能力。对麦斯时代而言，与 TDengine 的合作，并不是一次简单的渠道合作，而是一次围绕“工业时序数据底座”的长期选择。

正如刘剑锋最后总结的那样：“麦斯时代携手 TDengine，希望让工业数据不只是被采集，而是真正成为企业持续进化的基础能力。”

关于麦斯时代

北京麦斯时代信息技术有限公司深耕工业物联网、低代码平台与数据管理解决方案，构建了“1平台 + N应用 + M模型”的全栈数字化服务体系，服务于有色金属、汽车制造、能源化工等多个行业的头部客户，具备千万级智能工厂项目的实施经验与深厚行业积累。

关于采访人

刘剑锋（Jeff），麦斯时代 COO，拥有二十余年工业数字化领域经验，曾任职于施耐德电气、西门子和第四范式等头部企业。他主导过多项大型工业互联网项目落地，擅长技术与业务的融合推进，致力于通过生态合作与技术创新，推动工业企业的数字化转型与价值提升。

1. KAT 背景介绍

在 AI 技术飞速发展的当下，"让数据库更智能、更易用"成为行业核心探索方向，尤其国产数据库使用过程中，普遍存在学习成本高、运维流程复杂、特色功能上手难度大等痛点，各类手册文本繁杂，不利于用户快速落地使用。

针对这一现状，KaiwuDB 在 AI 与数据库融合领域持续深耕，形成了DB for AI 与 AI for DB 两大核心布局，既打造了适配多场景的预测分析引擎，又推出了 KAT - KaiwuDB 数据库智能体工具，构建起完整的数据库 AI 赋能体系，其中 KAT 作为 AI for DB 领域的核心成果，重点解决用户操作、运维、研发中的各类痛点。

本期直播核心围绕数据库智能体工具 KAT 展开，全面拆解其背景价值、架构功能及实操效果，为 DBA、研发工程师、数据科学家等技术从业者，提供 AI 与数据库融合的全新解决方案，助力降低数据库使用门槛、提升全流程工作效率。

2. KAT 架构和功能

2.1 KAT 核心架构

KAT 采用先进的 Multi-Agent（多智能体）架构，规避单 Agent 系统处理复杂任务时的效率低、准确性不足等短板，通过"分工协同、各司其职"的设计，实现复杂任务的高效拆解与落地。

• Main Agent（主智能体）：作为核心调度中枢，负责接收用户请求、识别核心需求、拆解复杂任务，并分配给对应 Subagent，同时监控任务执行进度、整合最终结果。

• Subagent（子智能体）：具备独立决策与执行能力，聚焦特定任务类型，包括 NL2SQL 转换、性能分析、数据分析、安装部署、知识库管理、故障诊断等，通过多轮迭代完成复杂需求。

• 核心组件：包含 Agent UI、Agent Server、Task Manager 三大组件，Agent UI 提供图形化交互与配置能力，Agent Server 以 RESTful API 形式提供 Agent 功能，Task Manager 支持定时任务与 Webhook 通知。

KAT 架构图

2.2 KAT 核心功能特性

KAT 具备五大核心功能特性，全面覆盖数据库操作、运维、分析全流程，大幅提升工作效率：

•自然语言交互：用户可通过对话完成各类数据库相关任务，无需掌握复杂操作指令。

• 智能问题诊断：快速定位 KaiwuDB 使用过程中的问题，提供精准解决方案。

• 性能调优：依托 KaiwuDB 专家知识，针对性优化数据库性能，提升运行稳定性。

• 自动化任务：支持定时巡检、备份、报表生成等运维任务，简化日常工作。

• 数据管理与分析：支持自然语言查询、趋势预测及可视化展示，让分析结果更直观。

KAT 功能特性

2.3 KAT 针对不同角色的赋能

• DBA：提供故障预防、巡检自动化、智能告警、部署自动化等能力，解放重复劳动，聚焦高价值工作。

• 研发工程师：支持自然语言生成 SQL、辅助业务设计、快速熟悉业务逻辑，大幅提升研发效率。

• 数据科学家：提供智能数据预处理、分析预测、结果可视化等支撑，助力高效挖掘数据价值。

3. KAT 相关演示

视频演示详见：全景解析 KaiwuDB 数据库智能体工具

如果说前几年，工业企业谈数据，更多是在解决“能不能采、能不能存”；那这两年，越来越多客户开始问的是另一类问题：

• 数据规模上来之后，系统还能不能稳？
• 复杂分析越来越多，查询是不是一定会慢？
• 业务想用数据，但每次都要找技术同事，能不能更“自动”一点？
• AI 说了这么多年，真正想落到工业场景里的，到底应该怎么做？

这些问题，其实正是 TDengine 在规划 2026 年产品路线时反复讨论的出发点。

最近，我们正式对外发布了 TDengine TSDB & TDengine IDMP 的 2026 年年度路线图。相比“多加几个功能”，这份路线图更想解决的是一件事：在真实、长期、复杂的工业数据场景里，系统如何继续向前演进。

TDengine TSDB｜2026 年路线图

从规划可以看到，TDengine TSDB 在 2026 年的重点，并不只是“更快”，而是让复杂场景变得可控。

一方面，查询能力持续向真实工业分析靠拢：关联查询、子查询、自然周期窗口、累计窗口、窗口函数……这些能力背后，都是越来越复杂的分析逻辑需求。

另一方面，虚拟表与流计算被反复强化，意味着计算正在前移：不再只是“数据进库 → 再算”，而是让系统本身承担更多实时与持续计算的职责。

而在更底层，引擎、缓存、多副本、资源管控的优化，则是在为长期稳定运行打基础。

TDengine IDMP｜2026 年路线图

TDengine IDMP 于 2025 年 7 月正式发布。从一开始，它就不是一个“补充型工具”，而是围绕工业数据长期使用所设计的平台级产品。

在过去半年多的迭代中，IDMP 始终保持着“快迭代、小步快跑”的节奏：依托 TDengine TSDB 的高性能时序数据底座，持续强化工业数据的标准化管理与情景化分析，并在此基础上进一步拓展 AI 原生能力，让数据从“可管理”走向“可决策”。

这些更新更多聚焦在语义一致性、分析可复用性、视图沉淀与 AI 使用门槛等方面，为后续复杂场景与规模化落地打下稳定基础。

2026 年，IDMP 的演进重点开始从“能力补齐”转向“体系化建设”：

• 在延续既有 AI 能力的基础上，引入更完整的事件体系与根因分析能力；
• 强化面板、仪表板与分析之间的组合、继承与钻取关系；
• 同时在平台层面补充可观测性、权限与数据治理能力，使分析与 AI 能力能够长期、稳定地运行在真实工业环境中。

从 2025 到 2026，TDengine IDMP 正在从“能力集合”走向“可长期演进的工业数据平台”。

写在最后

工业数据的下一阶段不是“有没有数据”，而是系统能不能承载更复杂的分析、更长周期的运行，以及更高层次的智能应用。2026 年，TDengine 正在为这一阶段提前铺路。

如果你正在使用 TDengine，或正在评估下一代工业数据平台，这份路线图，或许能帮你更早看清接下来一年的演进方向。同时，我们也欢迎你基于真实场景和实际需求反馈建议，一起把这份 Roadmap 打磨得更加“落地”。

一、物联网设备分布分析，真的“必须”精准地理信息吗？

在讨论物联网设备分布之前，很多团队第一步就会接触到类似 IP数据云IP地址查询——通过设备日志里的 IP，还原设备大致所在的行政区域，但物联网场景，真的需要“越精细越好”的地理信息吗？

物联网和互联网业务最大的不同

普通 Web/App：

• 用户是“人”
• 地理信息更多用于画像、推荐或内容分发

物联网（IoT）：

• 对象是“设备”

• 地理信息直接影响：

  • 运维
  • 网络调度
  • 合规判断
  • 成本控制

因此，对IoT来说是基础数据层的一部分。

常见物联网场景，对地理精度的真实需求

IoT并不追求“街道级定位” ，而是稳定、可批量、可解释的行政区级定位。
这也是为什么在真实项目中，很多团队会优先选择基于 IP 的地理解析方案，而不是复杂的设备侧定位能力。

二、为什么物联网更适合用「IP离线库」，而不是在线接口？

这是很多IoT团队在早期容易低估的一点。
即便你已经验证过某些在线 IP 地址查询接口（比如在测试环境用过 IP数据云IP地址查询）。

物联网的三个现实约束

① 数据量极大

• 设备数：几十万/几百万
• 日志规模：每天TB级
• 实时接口调用成本极高

② 网络环境复杂

• 专网/内网
• 边缘节点
• 海外或弱网环境

③ 稳定性和可控性优先

• 运维分析≠实时用户交互
• 离线可复现，比“快几毫秒”更重要
  这种背景下IP离线库几乎是IoT场景的解法

离线库在IoT场景的优势

• 批量解析（百万级IP无压力）
• 本地运行（无外部依赖）
• 结果可追溯（版本固定）
• 成本可控（一次部署，多次使用）
  适合：
• 日志回放
• 周/月度设备分布报告
• 异常区域复盘

三、IPv4/IPv6双栈是刚需

为什么 IoT 里 IPv6 占比越来越高？

• 设备数量爆炸，IPv4不够用
• 运营商网络天然支持IPv6
• NB-IoT、5G、蜂窝网络大量走IPv6
• 海外部署（尤其亚太、欧洲）IPv6更常见

现实很多IoT平台中，IPv6设备占比已经达到30%～50%。

双栈支持在离线库中的技术含义

一个合格的IP离线库，至少需要做到：

• 同时支持IPv4/IPv6
• 统一输出结构（国家/省/市/ASN 等）
• 支持批量解析

• 不需要维护两套SDK、两套逻辑
  否则，在IoT场景中维护成本会变高。
  

  四、在真实物联网系统中，IP地理数据通常怎么用？

  典型流程示例

• 设备上报日志（包含IP）
• 日志落库/对象存储
• 离线任务（Spark/Flink/MapReduce）
• 调用IP离线库做 批量解析

• 生成：

  • 设备区域分布
  • 国家/省级设备数量
  • 区域异常告警
  • 合规统计报表

五、唠叨（给技术/产品都能用）

• 物联网设备分布分析需要地理信息，但不是“GPS 级”，而是稳定、可批量的行政区级精度
• IP离线库天然适合IoT大规模、离线、可复现的数据分析
• IPv4/IPv6双栈批量解析，已经是物联网分析的基础能力，而不是可选项
• IP数据云IP地址查询是IoT数据体系中的基础功能

在实际生产环境中，时序数据库面临的挑战早已不只是“能不能存数据”，而是如何在复杂查询、高并发计算、多源接入和安全合规要求不断提高的情况下，依然保持稳定、高效和可控。

近日，TDengine TSDB 发布新版本 3.4.0.0，围绕查询性能、流计算能力、安全体系与数据接入生态进行了系统性增强。本次更新在虚拟表查询、状态窗口计算、流计算性能等核心场景下带来了显著优化，同时补齐了多项安全能力，并进一步扩展了数据订阅、授权服务及主流数据源接入能力。

本文将为你梳理该版本的主要更新亮点，帮助你快速了解哪些改进能在实际场景中带来更直接的性能提升、更稳定的运行体验，以及更灵活的系统集成方式。

重要更新亮点

安全功能全面提升（企业版）

通过对身份鉴别、权限控制、审计、传输与存储等关键环节的系统性安全加固，新版本整体安全能力得到显著提升，为安全可靠性测评及等保三级、四级要求提供有力支撑。

身份鉴别

新版本在身份鉴别与访问控制方面进行了增强，支持强口令策略及密码生命周期管理，引入多因素认证与 TOKEN 认证机制，并完善用户锁定与会话控制能力。同时，系统支持基于 IP 与时间段的访问限制，口令在存储与传输过程中均采用加密保护，进一步提升整体安全性。

访问控制

新版本完善了基于 RBAC 的权限管理体系，引入系统级与对象级权限划分，内置互斥的 SYSDBA、SYSSEC、SYSAUDIT 系统角色，实现权限制衡与职责分离。同时支持权限与角色的创建、删除、授予与回收，提供标准 GRANT/REVOKE 语法，并支持对象所有者权限转移。在访问控制层面，支持库、表、列等多层级权限控制。

安全审计

新版本完善了分级审计能力，按粒度分为系统级、集群级、数据库级、子表级、数据级五级审计，支持查询、删除、写入等数据操作审计。审计操作与业务访问相互隔离，强制启用加密存储并设置不少于 5 年的保留策略，相关安全属性不可修改。同时强化审计链路安全与防篡改能力，保障审计数据的完整性与可信性。

传输安全

新版本完善了传输安全与连接管控机制，采用 TLS 传输加密与 SASL 身份认证的分层架构，保障通信安全。在连接层面，支持按用户配置并发会话数、会话时长及空闲超时等参数，并增强黑白名单访问控制能力。同时引入通信失败监测与异常告警机制，可在异常场景下自动触发告警并临时锁定相关用户/IP。TLS 私钥采用加密存储并支持安全轮换，相关安全操作均可审计，在保障安全性的同时总体性能下降不超过 10%。

存储安全

新版本完善了存储安全能力，采用分级密钥体系，对配置文件、元数据及时序数据实现透明加密，密钥生成、变更、到期及恢复等过程统一由系统管理，用户方面无感知。核心密钥通过加密通信机制安全传输，并支持国密算法适配，敏感操作需管理员权限并全程留存审计。同时提供加密状态与范围的可观测能力，支持密钥到期告警配置。

加密算法

新版本增强了加密算法管理能力，新增系统表用于集中查看和管理可用加密算法，覆盖对称加密、非对称加密与散列算法等类型。系统内置国密与国标算法，适配数据加密、密钥交换与完整性校验等多种场景，并支持通过动态链接库方式扩展自定义加密算法，满足不同环境下的算法适配需求。

安全函数

新版本补充了安全相关内置函数能力，提供数据加密、脱敏、哈希及编码转换等函数，支持国密与国际算法，满足数据存储、传输及查询过程中的安全处理需求。

流计算事件窗口新增「子事件窗口」触发机制

本次版本在流计算中引入事件窗口的子窗口触发机制，支持为同一事件定义多个开始条件。不同开始条件满足时，可依次触发对应的子事件窗口，系统自动维护父事件窗口的开启与关闭关系；父窗口及各子窗口均可独立触发计算与通知。该能力特别适用于分级告警、状态升级、阈值递进等复杂场景，使事件驱动的流计算逻辑更加贴近真实业务变化过程，而无需通过多条规则或多条流任务进行拆分实现。

EVENT_WINDOW(START WITH (start_cond_1, start_cond_2 [,...]) [END WITH end_cond])

流计算的资源消耗和计算延迟显著降低

新版本在 Nevados 实际业务场景下对流计算引擎进行了针对性优化，显著降低了资源消耗并改善了计算延迟表现。优化后，CPU 平均使用率由 321.7% 降至 30.3%，降幅约 90.6%；内存平均占用由 8.65 GB 降至 1.49 GB，减少约 82.8%。同时，流计算的平均处理延迟由原来的约 1 小时缩短至 5 分钟以内，整体响应速度提升约 92%。

虚拟表的查询性能优化

投影查询性能优化（虚拟超级表 / 子表）

新版本针对虚拟超级表及虚拟子表的投影查询场景，系统对查询路径进行了针对性优化，覆盖包含 tbname、tag 条件、时间过滤以及全量扫描等多种常见查询模式。在包含 tbname 或 tag 条件的查询场景下，查询性能提升最高可达千倍量级，显著改善了典型业务查询的响应速度；在全量扫描或单表查询场景中，性能提升相对有限，但仍体现了底层执行与数据访问优化带来的整体收益。

聚合与选择函数查询性能优化（虚拟超级表）

新版本针对虚拟超级表在聚合函数与选择函数场景下的查询性能进行了系统性优化，覆盖是否使用 partition by、函数参数是否包含 tag 等多种常见用法。优化后，虚拟超级表在上述典型查询用例中的执行时间由原来的 68–86 秒 显著缩短至 0.088–0.640 秒，整体性能提升约 119×–796×，大幅改善了统计分析与状态类查询的响应效率。

状态窗口查询性能优化（虚拟超级表 / 子表）

针对虚拟超级表及子表在状态窗口计算场景下的性能问题，新版本对窗口判定与计算流程进行了优化，特别用于解决稀疏数据与密集数据混合计算时的效率瓶颈。新机制下，系统可在窗口触发前先提取窗口边界信息，再按策略激活后续计算，并支持按批次或单窗口两种优化策略。在数据分布密集场景下推荐使用批处理策略，在数据分布相对均匀且窗口数量较少的场景下，可选择单窗口策略，其余情况沿用默认策略。

查询性能优化及语法增强

新增非相关标量子查询

在查询能力方面，新增对非相关标量子查询的支持，子查询可返回单行单列结果并作为常量参与主查询计算与条件判断。

状态窗口零状态支持

新增状态窗口零状态（zeroth state）能力，可在状态窗口计算完成后，将状态值等于指定零状态的窗口整体排除，不参与后续计算。该机制与通过 WHERE 条件过滤数据不同：零状态是在完整状态窗口判定之后进行过滤，而 WHERE 条件是在数据进入窗口计算之前生效，可用于更精确地区分“无效状态窗口”与“有效状态但需排除的数据”。

STATE_WINDOW(col[, extend][, zeroth_state]) [TRUE_FOR(true_for_duration)]

多类典型查询与能力边界优化

新版本针对多种高频查询场景进行了集中优化，包括 last_row + tags 查询、系统表统计子表数量以及窗口查询能力扩展。优化后，last_row + tags 查询平均耗时由 25.9 秒 降至 0.385 秒，性能提升约 68 倍；基于系统表统计子表数量的查询平均耗时由 3.824 秒 降至 0.003 秒，同样提升约 68 倍。同时，窗口查询不再强制要求包含聚合函数，可仅使用窗口伪列（\_wstart、tbname 等）参与查询；虚拟表支持的最大列数提升至 32767 列，且不影响写入与查询性能。

XNODE 高可用与负载均衡支持

在新版本中，taosX 正式成为 TSDB 的一个内部组件：XNODE，由 MNODE 统一管理并通过 xnoded 调度器进行调度，支持高可用与负载均衡能力。

OAuth 2.0 / OIDC 单点登录（SSO）支持

新版本新增对 OAuth 2.0 与 OIDC 的单点登录支持，兼容 OAuth 2.0 与 OIDC 1.0 标准 API，并支持基于 OIDC 的端点自动发现。同时提供可配置的自定义 OAuth 2.0 API 接入能力，并支持对 SSO 用户的基础管理功能（部分能力已实现）。

KingHistorian 数据源支持

新版本新增对 KingHistorian 数据源的支持。KingHistorian 是 Wellintech 于 2006 年推出的工业实时数据库，已在现场运行近 20 年，支持单机最高 200 万标签规模，广泛应用于大规模设备数据采集与实时计算场景。

Pulsar 数据源支持

新版本新增对 Apache Pulsar 数据源的支持。Apache Pulsar 是一款分布式发布订阅消息平台，支持灵活的消息模型与流式消费方式，可用于消息队列及流处理场景。在使用体验上，Pulsar 数据源的 UI 界面与 Kafka 保持一致，降低多数据源场景下的使用与运维成本。

taosgen 发布到 Kafka

taosgen 新增对 Apache Kafka 的数据发布能力，支持将生成的数据直接写入 Kafka 主题。Apache Kafka 是一款开源的分布式流处理平台，常用于构建实时数据管道与流式应用，该能力可用于数据生成、测试与流处理场景的联动验证。

taosAdapter 功能增强（JSON 写入与查询管控）

taosAdapter 新增对 HTTP POST JSON 写入的支持，可接收任意格式的 JSON 数据，并通过 JSONata 进行数据转换，同时支持时间字段解析；同时引入 SQL 查询请求管控能力，支持对 SQL 请求进行拦截，并按用户维度设置并发限制，提升接口访问的可控性与稳定性。

C WebSocket（WS）支持 TLS

C WebSocket 连接器新增 TLS 支持，实现通信过程的端到端加密，提升数据传输的安全性。

OpenTSDB 支持自定义列名、子表名

OpenTSDB 接入新增对自定义字段与子表命名的支持，可灵活配置时间戳字段、数值字段以及子表名，提升不同 OpenTSDB 数据模型下的接入适配能力。

其他优化

1. TDgpt 的数据补全算法支持任意采样间隔，支持 dtw、dtw\_path、tlcc 等相关性分析函数
2. 新增 maxSQLLength 设置 SQL 语句的最大长度，最大可为 64M
3. 虚拟表支持的最大列数提升至 32767 列
4. STMT2 对虚拟表查询的支持
5. Compact 命令支持 force 选项
6. Show connections 命令新增客户端版本号字段
7. Show vgroups 命令新增 is\_ready 列
8. 优化 event\_window 按 tbname 分组查询的效率
9. 优化子查询做主键过滤条件时的性能

除此之外，每个版本都会做很多其他的工作，比如 bug 修复、功能优化等等。如果想要了解新版本（时序数据库功能更新）更加详细的发布信息，可以移步至 https://github.com/taosdata/TDengine/releases/tag/ver-3.4.0.0 查看发布说明。

欢迎大家下载使用，也欢迎在评论区提出建议和意见，如有任何问题请及时联系我们获得支持。

看这一行长长的代码：

while(1)r.bgcolor("black").pensize(5).speed(0).color(r.heading()).circle(100,90).left(90).circle(100,90).left(90).right(20);

主要就是这一行代码，画了一幅美妙的莲花图案。下面是完整的，C++精灵库画莲花的代码：

#include "sprites.h"  //包含C++精灵库 
Sprite r;      //建立角色叫r
 
int main(){        //主功能块 
 
  while(1)r.bgcolor("black").pensize(5)
          .speed(0).color(r.heading())
          .circle(100,90).left(90)
          .circle(100,90).left(90).right(20);
 
   return 0;    //返回0
}

神仙对话泄天机

哪吒（手持乾坤圈）：“俺是哪吒三太子，刚刚听闻有位小魔法师用几行代码画出了一朵美轮美奂的莲花。那莲花的花瓣颜色还会随他的笔转向而不断变换，真是神奇！你可知道他是如何做到的？”

太上老君（手持拂尘）：“此乃C++精灵库的妙用也。那小魔法师创建了一个名为r的角色，就像我身边的童子一样，然后在main函数里用了一个永不停歇的while循环，让r不停地舞动乾坤。”

哪吒：“你这葫芦里卖的什么药？快讲讲r是怎么画莲花的？”

太上老君：“那小魔法师在循环里让r做了好多动作。他先把r的背景色设为黑色，就像天庭的黑夜一样深邃。接着把笔画粗细调粗到5个单位，笔速设为0，意味着笔走如飞，一点都不拖沓。”

哪吒：“嘿嘿，俺这乾坤圈也重达千斤，画笔画粗些倒也般配。那他还做了什么？”

太上老君：“他把画笔的颜色设置为r.heading()，也就是根据r当前的方向来取颜色。这就好比r在不停地旋转，每转一个角度，颜色就变一变，仿佛r的心情在变，颜色也跟着变。”

哪吒：“这颜色还会变？那r是怎么转的呢？”

太上老君：“r画了两个半径100的圆弧，每次转90度。具体来说，先画了一个90度的圆弧，然后左转90度，再画另一个90度的圆弧，又左转90度，然后右转20度。如此循环往复，就像你在打旋子一样，一圈一圈地转。”

哪吒：“这不是和我用乾坤圈画圈一样吗？那最后r会不会停下来？”

太上老君：“那小魔法师在循环里没有停下来的意思，while(1)就是无限循环。”

哪吒：“原来如此！这C++精灵库真像一位多才多艺的画匠，寥寥数笔就能画出五彩斑斓的莲花。而且它的命令和Python的turtle库差不多，对于喜欢Python的孩子来说，学这个C++库就像换了个平台继续玩耍，真是一举两得！”

太上老君：“哈哈，哪吒你说得对！C++精灵库让孩子们在学习编程时，既可以延续熟悉的图形命令，又能领略C++的强大功能，确实是非常值得学习的库。”

哪吒：“俺这就回去告诉师傅，让他也教教我C++精灵库，说不定俺也能画出更漂亮的莲花呢！”

太上老君：“好啊，希望你早日成为C++小能手，画出属于你自己的绚丽莲花！”

代码解析学咒语

下面的逐行解释了main函数中while循环内的代码，并说明其作用：

代码行 作用
r.bgcolor("black") 设置画笔背景色为黑色。
.pensize(5) 设置画笔粗细为5个像素单位。
.speed(0) 设置画笔移动速度为0（最快速度）。
.color(r.heading()) 根据画笔当前方向heading()获取颜色值，并设置画笔颜色。方向值会被转换为色相，从而实现颜色随方向变化。
.circle(100, 90) 以当前位置为圆心，半径100逆时针绘制一个90度的圆弧。
.left(90) 画笔向左旋转90度。
.circle(100, 90) 再次向左绘制一个90度的圆弧。
.left(90) 画笔再次向左旋转90度。
.right(20) 画笔向右旋转20度（调整方向，使下次循环继续）。
上述代码通过链式调用的方式组合了一系列绘图命令，在无限循环中不断重复执行。每次循环中，画笔都会以黑色背景、粗线条、动态颜色绘制两个圆弧，然后旋转方向，如此往复，形成了莲花形状的图案。

始作俑者详剖析

C++精灵库（Sprite库）是一个基于SDL2库的少儿C++编程教学库，提供了类似Python turtle库的简洁命令，通过绘制图形和制作动画或小游戏创意C++作品来让少年儿童学习C++。它具有以下几个特点和优势：

简单易学： 库中的命令与Python turtle的命令非常相似，用法绝大多数一模一样。这使得熟悉Python绘图的用户可以快速上手C++编程。对于少年儿童来说，使用熟悉的命令可以降低学习门槛，激发他们对编程的兴趣。
功能强大： 虽然命令简单，但C++精灵库基于SDL2库，同时具备C++的强大性能和灵活性。用户可以利用C++的高级特性，如对象、函数和循环，实现更复杂的图形和动画效果。
丰富的图形效果： 库支持设置画笔颜色、粗细、速度，以及绘制各种图形（直线、圆圈、圆点、圆弧、椭圆等）并且增强了对画笔颜色的一些更精细的控制。比如让颜色渐变的coloradd命令。实际是逐步增加颜色的色相。比如设定颜色的饱和度命令(pensat)，还有设定颜色的明度命令(penvalue) 及洪水填充命令fill等。用户通过组合这些命令，用户可以创造出丰富多彩的图形和动画效果。例如，本示例中通过动态改变画笔颜色，实现了颜色随方向变化的绚丽图案。
拓展与互动性强： C++精灵库的底痤基于SDL2库，可以完美融入SDL2库的命令，从而方便地响应用户输入（如鼠标点击、键盘按键等）。这使得用该库开发的程序具有更强的交互性，也可以用于游戏和教育应用的开发制作。

综上所述，C++精灵库是一个非常适合少年儿童学习编程的工具。它将Python turtle的易用性与C++的强大功能相结合，使孩子们在享受编程乐趣的同时，也能逐步掌握C++语言的基本概念和编程技巧。对于培养少年儿童的逻辑思维和创造力，C++精灵库无疑是一个“一箭双雕”的选择。

在云原生数据仓库的演进过程中，如何在保障作业SLA与优化资源成本之间取得平衡，始终是用户关注的核心问题。传统静态资源配置模式难以应对现代数据作业中普遍存在的突发性、非周期性、不可预测性负载特征。

MaxCompute 全新推出 自动弹性（Autoscale）功能——基于实时负载感知的秒级弹性扩缩容机制，结合按量计费模型，实现计算资源供给与业务需求的动态对齐。

一、背景：从静态预留到智能弹性

过去，MaxCompute 用户主要依赖 包年包月预留资源：稳定可靠，但缺乏灵活性；面对突发需求，只能提前大量采购，造成大量闲置。

后来，基于推出的弹性预留 模式：用户可自定义时间计划和扩缩规则，适用于有明显周期性波动的场景（如每天凌晨跑批）。但这也要求用户具备较强的运维能力，且难以应对突发或不规则的负载变化。

现在，MaxCompute 全新推出 自动弹性（Autoscale）功能 —— 通过系统的负载感知与调度策略，实现“无感扩缩”，填补了非稳态、高动态场景下的资源管理空白，真正做到“用多少，付多少”。

三者可组合使用：以包年包月为基础保障，弹性预留应对可预测高峰，自动弹性兜底突发流量，构建MaxCompute Serverless 弹性资源体系。

二、自动弹性核心优势

1. 开箱即用，低运维负担

• 用户只需设置 AutoscaleLimitCU（自动弹性上限），系统自动完成扩缩决策；
• 支持一级/二级 Quota 粒度配置，二级 Quota 共享一级自动弹性CU资源池，自动分配。

2. 按需供给，按量计费

• 仅对实际使用的自动弹性CU（AutoscaleUsedCU）用量按秒计量，按小时统计出账；
• 单价：0.36元 / (CU·时)，无需预付，无最低消费。

3. 秒级响应，保障作业SLA

• 相比小时级调度窗口，自动弹性支持秒级资源调整，有效应对突发作业排队；
• 后端基于历史负载与预测模型优化库存保障和资源调度，提升弹性资源可用性。

⚠️ 注意：自动弹性依赖实时资源库存，无法100%保证极端突发场景下的资源可达性。对于强SLA要求场景（如大促），建议同步配置弹性预留作为资源兜底。

三、真实场景案例

场景一：突发业务高峰下的作业SLA保障

某电商平台客户，日常使用 50 CU 包年包月Quota，足以支撑日常数据加工分析任务。但每逢大促，作业量激增3倍，原有资源严重不足，作业排队超2小时，严重影响数据产出时效。

客户曾评估扩容包年包月Quota至150 CU，但大促仅占全年不到20%的时间，全年多花约18万元，长期持有高配资源性价比极低。

启用 Autoscale 后：

• 设置 自动弹性上限 AutoscaleLimit 为 100 CU（即最多可额外使用100 CU自动弹性CU）
• 系统在检测到作业队列积压后，秒级自动扩容， 动态将可用CU提升至140CU（50 CU包年包月 + 90CU自动弹性），作业完成时间恢复至30分钟内，满足业务SLA要求；

“以前不敢做大促实时分析，现在敢了，而且花得更少！” —— 客户反馈

场景二：替代分时弹性，实现降本增效

某金融客户每日需执行大量 T+1 批处理任务，用于全量交易对账、监管报送数据聚合等，长期采用 分时弹性预留策略：每日22:00–6:00 时段将 Quota 从 包月预留 50 CU 扩容至 100 CU。

但时常因业务活动、节假日调休、系统割接活上游产出延迟等，常出现“资源空转”或“容量不足”并存的问题，运维团队需频繁调整弹性计划，但人工干预滞后性强，且易出错。

切换至 Autoscale 后：

• 设置自动弹性上限 AutoscaleLimitCU 为 60 CU ，允许系统在 50 – 110 CU 范围内动态扩缩；
• 系统根据实际作业队列动态调整弹性CU，夜间平均仅使用 30 CU 自动弹性资源；
• 月度弹性费用从分时弹性CU 3780元 （50CU *0.315元/CU*8小时*30天）降至 2592元（30CU *0.36元/CU*小时*8小时*30天），降本32%，且作业完成时间更稳定。

“不用再熬夜调配置了，系统自己会‘看饭下菜’！” —— 运维工程师点赞

四、快速启用

概念说明

自动弹性上限CU（AutoscalelimitCU）：指用户为Quota设置的弹性CU资源总上限。当该值 > 0 时，则为启用自动弹性功能，系统可在此上限范围内按实际负载自动扩缩容。自动弹性使用CU（AutoscaleUsedCU）：指在启用自动弹性后，Quota中实际消耗的自动弹性CU资源使用量。系统将根据作业负载自动调整CU用量，并按此实际CU使用量计费。

使用须知

前提条件：必须已购买包年包月计算资源Quota；计费单位：CU·时，按秒采样、按小时聚合；自动弹性CU价格：0.36元 /(CU*时)；计费公式：每小时的费用 = 该小时自动弹性CU用量（单位：CU*时）× 自动弹性CU价格。

谁适合用自动弹性？

✅ 业务负载波动频繁、难以预测（如营销活动、临时分析）
✅ 希望保障作业性能，同时避免资源浪费
✅ 已有包年包月Quota，想进一步补充/优化弹性资源

登录 MaxCompute 控制台 → Quota管理 → 编辑基础配置 → 设置 AutoscaleLimitCU

即可开启智能弹性之旅！

更多说明文档请参考 https://help.aliyun.com/zh/maxcompute/use-cases/auto-elastic-usage-best-practices?spm=a2c4g.11174283.help-menu-search-27797.d\_0

五、总结

自动弹性不是简单的“资源扩容”，而是 MaxCompute 在智能调度、成本治理、SLA保障三位一体方向上的重要演进。它让资源管理从“静态规划”走向“动态协同”，真正实现“用多少，付多少；要多少，给多少”。

欢迎您的试用并反馈您的生产实践。我们将持续优化弹性调度算法与资源保障能力，助力企业构建更高效、更经济的云原生数据基础设施。

近日，赣南师范大学代表团莅临百度，双方正式签署校企合作战略协议。这不仅是一场强强联手的签约，更是前沿AI技术与深厚学术积淀的一次“握手”。当“AI for Science”遇上“产教融合”，百度与赣南师大正联手开启智能时代复合型人才培养的新篇章。

在座谈环节，双方达成高度共识：在智能时代，AI素养已不再是人才的“加分项”，而是“必选项”，产教融合势在必行。百度一见产品部总经理朱名发详细分享了一见在多模态大模型领域的战略布局，以及在能源、制造、连锁、运输等行业的产业实践。“要把最前沿的技术，转化为课堂上的生产力。” 在热烈的氛围中，赣南师范大学党委常委、副校长罗序中与百度代表双方签署协议。

随后，校方代表团走进百度展厅，近距离感受百度文心大模型赋能千行百业的实战场景。从实验室的算法到产业实践里的深度应用，双方对“AI+教育”的未来达成了高度共识。朱名发总经理强调：“大模型时代，具备AI素养、能熟练运用AI工具提升效率的复合型人才，已成为企业的首选。我们希望通过合作，让学生在校期间就掌握‘AI生产力’，赋能在就业市场具备核心竞争优势。”

罗序中副校长对此深表认可。他表示，作为江西省“双一流”建设高校，赣南师大拥有扎实的AI学科基础，百度一见在视觉管理领域的深厚积淀，将为学校科研创新注入强劲动力。双方将通过产教融合，加速成果转化，联合培养懂产业、精技术的实战型人才。拒绝纸上谈兵，直击地方痛点。 依托国家脐橙工程技术研究中心等国家级平台，双方明确将“赣州脐橙智能化种植”与“赣州电子制造”作为首批科研攻关方向。通过百度一见的多模态专业视觉技术赋能，双方将合力打造具有全国影响力的应用标杆，真正将产教融合的实践“写”在赣南大地的田间地头与工厂车间。

签约只是起点，赋能才是目标。未来，百度一见将持续以技术创新为核心，深度融入赣南师大的教学与科研土壤。从实验室的创新火花，到产业界的落地成果，双方将共同探索AI赋能实体经济的新路径。当“AI新范式”扎根老区沃土，一场关于人才、科研与产业的化学反应，正在发生！

过去两年，能源矿产行业，正在从一个“以规模和资源驱动”为主的行业，进入一个以复杂运行与系统治理为核心约束的新阶段。一方面，全球能源博弈加剧、关键矿产战略属性抬升，安全、稳定与可控成为底线要求；另一方面，绿色低碳、双碳约束、成本透明化，正在把过去“被吸收”的不确定性，逐步转化为显性经营压力。与此同时，AI 对算力与能源的需求反向放大了能源系统的战略地位，使能源矿产不再只是“上游产业”，而是全球产业体系中的基础能力提供者。

这三股力量叠加，带来的并不是简单的业务增长或下行，而是一种更根本的变化：企业运行本身，正在变得前所未有地复杂。复杂性不再来自“业务更多”，而来自“变量更多、耦合更强”。

正是在这一判断之下，这本《能源矿产行业 Data+AI 数智化转型白皮书》试图回到一个更基础的问题：能源矿产企业，究竟需要怎样一套面向未来十年的数智化体系？

产业链拆解：矿山、冶炼、加工、集团企业，各有各的“卡点”从产业链整体看，能源矿产行业正同时承受来自安全、成本、效率与治理复杂度的多重压力，但不同环节的问题形态并不相同。矿山企业长期处在高风险、高耦合的运行环境中，生产、安全与成本高度依赖现场经验进行平衡判断，虽然系统与数据不断增加，但信息分散在采掘、通风、运输、安全监测等多个专业系统中，难以形成连续、稳定的运行态势认知，一旦出现异常，管理动作往往发生在结果之后，风险演化过程缺乏提前感知能力。

进入冶炼环节，问题逐步从“能不能稳住生产”转向“利润结构是否可被解释”，能耗、原料、工艺路线、排产节奏相互影响，加工费、能源价格与碳成本波动频繁，财务结果可以核算清楚，但利润变化背后的驱动因素难以被拆解，生产侧与经营侧之间长期缺乏贯通分析视角。

加工企业表面上资产更轻、流程更灵活，但项目数量多、订单碎片化、区域分散，使成本、进度、交付与质量高度交织，管理层往往只能看到阶段性结果，对项目运行节奏与关键偏差缺乏整体把控能力。

到了集团层面，上述问题进一步叠加放大，数据持续上行但语义口径不统一，指标体系不断扩充却难以横向对比、纵向追溯，分析结果更多停留在展示层面，难以真正嵌入资源配置、考核机制与管理动作之中。这种状态下，企业对外部不确定性的感知能力持续增强，对内部运行复杂性的掌控能力却并未同步提升，成为当前能源矿产行业普遍面临的系统性挑战。

统一底层逻辑：一体两翼架构如何支撑能源矿产企业数智化转型在具体展开矿山、冶炼、加工与集团四类企业实践之前，有必要先回答一个更基础的问题：这些看似差异巨大的场景，是否存在一套可复用的数智化底层逻辑？

从大量项目实践来看，答案是肯定的。能源矿产行业面临的问题虽然分布在不同环节，但在数据形态、管理诉求与运行机制上，呈现出高度一致的结构特征——数据来源复杂、业务耦合度高、风险容忍度低、管理链条长。这决定了数智化建设需要一套能够长期运行、持续演进的通用架构作为基础。

一体两翼方案架构基于这一认识，白皮书提出了“一体两翼”的整体方案框架。“一体”指向统一的数据底座，核心目标是解决数据在跨系统、跨层级、跨业务域流动过程中的可解释性问题。通过多模态数据智能中台与治理体系建设，将组织、资产、项目、装置、人员、合同、物料等关键对象纳入统一的数据模型与语义体系，明确主数据口径、指标计算逻辑与责任归属，使不同系统产生的数据能够在同一语境下被理解、被对比、被追溯。这一层解决的是“数据能不能支撑管理”的问题，是所有后续分析与应用的前提。

在统一数据底座之上，“两翼”分别对应数据智能能力与空间智能能力。数据智能侧重于把治理后的数据转化为可用的分析与判断能力，包括主题域分析、指标体系运行、异常识别、趋势判断以及智能问数与辅助分析等能力形态，其价值在于降低分析门槛、提升判断效率，使管理层能够从数据中快速获得“发生了什么、为什么发生、接下来可能会怎样”的连续认知。

空间智能则承担另一类关键任务——将复杂业务运行状态放入空间语境中表达，通过数字孪生把生产现场、工程项目、管网资产、园区设施等实体对象转化为可感知、可联动、可推演的运行载体，让风险、进度、资源与规则以更直观的方式支撑监管、指挥与协同。

图：车辆及驾驶员精准定位及状态监控

“一体两翼”框架并不追求一次性覆盖所有场景，而是为不同类型企业提供了一套可按需展开的通用底盘。矿山企业更多把能力落在空间智能与实时监管上，解决高风险场景下的运行感知与风险前移；冶炼企业重点强化数据治理与主题域分析，打通生产、能耗与经营之间的分析链路；加工与工程型企业围绕项目主线展开数据中台与经营分析，提升对经营节奏与风险暴露的掌控能力；集团企业则在统一底座之上，通过经营分析、统管机制与空间化承载，实现对子公司的可比、可控与可调度管理。差异体现在应用重点，而非底层逻辑本身。

也正因为有这样一套通用方案作为支撑，后续不同企业类型的实践，才能在保持行业差异的同时，呈现出清晰一致的建设路径与演进逻辑。

矿山、冶炼、加工、集团企业的不同落地路径：一体两翼走向行业实践要把矿山、冶炼、加工与集团统管这四类问题真正解决到位，方案需要同时回答三件事：数据怎么汇、口径怎么统一、场景怎么持续运行。

矿山环节优先建设“矿山实景数字孪生实时监管平台”，它的关键在于把巷道/采场/硐室等空间对象变成可承载业务规则的“运行容器”。在平台底座上，矿山空间模型持续随采掘推进更新，人员定位、车辆轨迹、作业票证、岗位资质、环境越限、重点风险源等数据按空间对象绑定与联动，形成“谁在何处、在做什么、是否具备资质、环境是否越限、风险是否可控”的连续态势。

监管能力通过两类机制落地：一类是空间化的风险分级与联动处置，例如越界、越限、禁入、临边与关键设备区的规则触发，自动生成预警清单与处置闭环；另一类是面向应急的路径推演与指挥协同，将人员分布、撤离路线、应急物资点位、救援力量调度纳入同一空间语境，支持从“态势掌握”进入“指挥动作”。这类平台真正解决的是深部开采条件下的“运行可见性”和“风险前移”，让安全管理从事后统计转向过程监管。

图：采矿车辆空间运行状态监控概览

进入冶炼环节，解决方案落点是建设“智慧运行平台”，建设重点围绕数据中台、治理体系与主题域分析同步展开。冶炼业务天然具有强耦合特征：原料结构、工艺参数、能耗水平、产量节奏与质量指标相互牵引，财务结果虽能核算，利润变化的形成过程长期缺少可解释链路。智慧运行平台首先把 DCS/MES/ERP、计量、能源与质量等系统数据纳入统一治理框架，建立主数据（组织、装置、物料、工序、计量点、能源介质等）与指标口径映射关系，确保“同一指标在不同装置、不同基地、不同时间粒度下可对比、可追溯”。在此基础上，以既定的主题域框架沉淀分析体系，将经营、财务、合同、人资、采购、合规等管理视角与生产过程数据打通，形成从“工艺—能耗—成本—利润”的贯通分析路径，使管理动作能够落在可解释的数据链路上：哪里波动、为什么波动、影响到哪个利润环节、该由哪个责任单元承接改进。冶炼方案的价值锚点在于把“算得出结果”升级为“看得见机制”，为排产优化、能效对标、成本拆解与风险预警提供稳定底盘。

图：冶炼行业多模态数据智能中台架构

加工型企业的方案，以全厂级实景建模为基础，构建覆盖厂区、车间与关键装置的数字空间底座，将设备、工艺、人员与环境等要素统一承载，为现场管理与分析提供稳定语境。在此之上，通过人员定位与风险感知能力建设，形成覆盖全厂的实时态势感知，使作业行为、风险区域与异常状态能够被持续识别与管控。围绕运行保障与生产组织，数字孪生进一步用于支撑应急演练、处置推演与跨车间态势协同，帮助管理层在同一视角下理解不同工序与车间的运行关系。随着现场数据持续沉淀，经营分析能力逐步与生产过程耦合，通过将产量、能耗、设备状态与成本、收率等指标关联，管理层能够在空间化视角下理解经营结果的形成路径，实现从结果统计向过程解释的转变，并在指挥大厅与接待场景中形成可操作、可表达的整体能力。

图：企业作战驾驶舱现场实景

集团层面的方案要回答“怎么统管子公司、怎么横向对比、怎么把分析转成抓手”。集团数据中台承担统一标准、统一口径、统一组织维度的工作，把成员企业数据上行与集团管理下行打通；经营分析体系则围绕集团既定主题域框架运行，将财务经营、人力资源、工程运营、客户服务等关键场景沉淀为集团级可对比的管理视图，支撑跨区域、跨业态的态势判断与资源配置。数据门户体系负责把集团分析、预警与任务清单组织成统一入口，形成“会前看态势、会中抓异常、会后盯整改”的运行机制。空间化能力在集团中更多承担“资产与运行态势的承载方式”，将管网、场站、工程项目与重点风险点的空间分布与经营分析结果关联呈现，降低跨层级沟通成本，让集团层的统管动作更容易落到区域与项目公司。

主题域规划

运营平台（原型测试数据）

四类企业的真实落地：一体两翼架构在复杂场景中的实践验证在地下矿山场景中，十五冶的实践验证了数字孪生作为运行级基础能力的价值。通过构建地下矿山实景数字孪生实时监管平台，企业将人员、设备、环境与作业活动统一纳入空间化运行视角，矿山管理从分系统监控转向整体态势感知。安全管理由事后复盘逐步演进为事前预判与过程干预，调度与应急指挥建立在实时状态之上，为深部开采条件下的安全治理与稳定运行提供了可持续支撑。

在工程型、项目型企业场景中，相关实践围绕数据中台重构了经营认知方式。通过以项目为核心对象，贯通合同、预算、采购、结算与财务数据，企业逐步摆脱了阶段性报表驱动的管理模式，建立起对项目收支、成本偏差与风险敞口的连续判断能力。经营管理从“看结果”转向“盯过程”，为项目统筹、资源配置与风险控制提供了更具前瞻性的决策基础。

在铜业加工场景中，实践重点落在生产现场与经营分析的协同。通过全厂级实景建模、人员定位与风险感知能力建设，企业构建了覆盖多车间、多工序的实时运行视角；在此基础上，将产量、能耗、设备状态与关键经营指标关联分析，使管理层能够在空间语境中理解经营结果的形成过程。数字孪生演进为支撑生产协同、应急处置与经营分析的综合载体。

在集团层面，中国燃气的实践展现了数据中台与经营分析在超大规模组织统管中的价值。通过统一数据治理与分析体系，集团将分散在多业态、多区域、多层级的经营与运行数据重新组织，形成可对比、可追溯、可下钻的集团级分析视角。经营、工程、人力与客户服务等关键领域逐步纳入统一认知框架，集团管理由“看得到数据”转向“推得动管理动作”，为规模化发展背景下的稳健运行与治理升级提供支撑。向左滑动查看更多

图：财务经营分析场景建设框架

图：组织绩效分析场景建设框架

图：干部画像分析场景建设框架

图：抄收＆保修场景分析建设框架

图：工程运营场景建设框架

实践共性路径及方法论总结

在矿山、冶炼、加工与集团四类企业的实践中，可以看到一个高度一致的结论：能源矿产行业的数智化挑战，来自业务复杂性、风险密度与治理半径的持续放大。当生产环境高度不确定、经营链条高度耦合、组织层级不断拉长，仅靠零散系统叠加或局部智能化，很难形成稳定、可持续的管理能力。真正起作用的，是一套能够长期运行、持续演进的体系化路径。“一体两翼”的价值，正体现在这种体系能力之上。

一方面，通过统一的数据底座与指标体系，把分散在现场、系统与组织中的信息，转化为可被理解、可被比较、可被追溯的经营与运行认知；

另一方面，通过空间化能力与智能分析能力，将这些认知嵌入到真实业务场景中，服务于安全监管、生产协同、经营分析与集团统筹等关键决策动作。

这使得数智化逐步参与到企业运行方式本身。从地下矿山的实景监管，到冶炼企业对生产—能耗—经营链路的穿透分析；从加工企业在复杂现场中构建整体态势感知，到集团层面对跨区域、跨业态运行与经营的统一统筹，这些实践并未追求“一步到位”的智能化目标，而是围绕各自最核心的业务矛盾，选择合适的切入点持续推进。也正是在这种渐进式、可复用的建设过程中，数智化能力开始真正沉淀为企业的治理能力。这或许是能源矿产行业在不确定性时代的一条现实路径：以能否降低风险暴露、提升经营透明度、增强组织协同为最终检验。Data+AI数智化转型的意义，不在于让企业“看起来更先进”，而在于让企业在复杂环境中运行得更稳、更清楚，也更有韧性。回到这本白皮书所呈现的，不是一套标准答案，而是一组来自真实实践的路径参考。无论是矿山、冶炼、加工企业，还是集团型组织，只有尊重行业特性、正视业务矛盾，在统一底座之上持续积累认知与能力，数智化才可能从“项目建设”走向“长期能力”。在能源博弈加剧、产业周期波动加深的时代背景下，这种能力本身，正逐渐成为企业最重要的竞争壁垒。我们也希望，这些实践与方法，能够为更多行业参与者提供启发——不是为了追逐概念，而是为了在不确定的时代，找到一条更稳健、更可持续的前行路径。

1.需求场景

在智能驾驶等复杂业务场景中，模型往往具备​多任务分支结构​，例如在同一个网络中同时包含​​ BEV 动态任务​（如目标检测、跟踪、运动预测）与​​ BEV 静态任务​（如地图构建、车道线提取、可行驶区域预测），这些任务对推理频率（Frames Per Second， FPS）的要求通常并不相同。也就是有不同任务分支 推理不同帧率的需求，例如 BEV 动态任务 20 帧，静态任务 10 帧这种情况，BEV 模型结构简单示例如下所示。

2.技术分析

以 BEV 动静态任务为例，实现不同任务分支推理不同帧率（动态 20 帧，静态 10 帧），很容易想到两种方案：

​方案 1-​拆分为三个子模型：模型 1-公共部分（backbone+neck）、模型 2-动态 head、模型 3-静态 head

1. 模型 1 推理 20 次，输出分别送给模型 2 推理 20 次，模型 3 推理 10 次。
2. 优点：应用层可灵活调度 3 个子模型的推理；模型 1-公共部分 只需要推理 20 次；
3. 缺点：模型 1-公共部分的输出内存需要额外存储，增加 load/store 带宽消耗；拆分次数多，影响编译时的全图优化，可能会增加 latency；

​方案 2-​拆分为两个子模型：模型 1-公共动态（backbone+neck+ 动态 head）、模型 2-公共静态（backbone+neck+ 静态 head）：

1. 模型 1-公共动态推理 20 次，模型 2-公共静态推理 10 次。
2. 优点：应用层可灵活调度 2 个子模型的推理；只需准备整个模型输入/出内存，无需准备公共部分输出的内存；拆分次数少，编译时可全图优化，减小 latency；
3. 缺点：公共部分（backbone+neck）需要推理 30 次，造成 latency 增加与 BPU 资源浪费；公共部分需要存储两份；

为了兼顾方案 1 与方案 2 的优点，同时实现不同任务分支推理不同帧率，工具链提供了 link 打包功能，具体打包方式如下：

工具链提供的 link 功能，能够 复用 不同 模型/任务 的公共部分 constant 常量（包括权重等），即不会存储多份，在模型加载时，公共部分只会占用一份静态内存，需要注意推理时动态内存不会复用（​作为不同模型处理​），关于内存占用相关介绍可见文章《<u>【地平线 J6 工具链入门教程】板端部署 UCP 使用指南-内存占用</u>》。

上图中将模型 1 与模型 2 link 打包生成的模型 3，相比于模型 1 体积不会大多少，同时具备推理模型 1 与模型 2 的功能。根据需求，调整模型 1 与模型 2 的推理次数，即可实现不同任务采用不同帧率部署。

如下图所示：推理一次模型 1，可实现动态任务 head 与静态任务 head 各推理一次，推理模型 2 可实现仅推理一次动态任务 head，当模型 1 推理 10 次、模型 2 推理 10 次时，即可实现动态推理 20 次，静态推理 10 次的效果。（公共部分 backbone+neck 仅推理 20 次）

3.方案实现

3.1 模型 link 打包

根据需求场景，先将多任务模型拆分导出为不同子任务的 qat.bc，然后分别将他们编译成 hbo 文件，最后将多个 hbo 文件 link 打包为一个 hbm 模型。

在工具链用户手册《<u>HBDK Tool API Reference</u>》章节中详细介绍了 compile 与 link API，可以看到：

• compile 输出同时支持 hbm 与 hbo 两种文件格式，可通过配置文件后缀名为"。hbm" or ".hbo"来区分。
• link 支持将多个 hbo 文件打包生成一个 hbm 文件。

将两个 hbo 文件通过 link 打包生成一个 hbm 模型，示例代码如下：

from horizon_plugin_pytorch.quantization.hbdk4 import export
from hbdk4.compiler import load, convert, compile, link
# export 阶段记得配置 name
qat_bcA = export(qat_model_A, example_input, name="1_backbone_head1_head2")
quantized_modelA = convert(qat_bcA, "nash-m")
# 注意：此时compile生成的模型后缀名为.hbo
hbo_nameA = "nameA_compiled.hbo"
hboA = compile(quantized_modelA, path=hbo_nameA, march="nash-m", opt=2, progress_bar=True, jobs=48)

qat_bcB = export(qat_model_B, example_input, name="2_backbone_head1")
quantized_modelB = convert(qat_bcB, "nash-m")
hbo_nameB = "nameB_compiled.hbo"
hboB = compile(quantized_modelB, path=hbo_nameB, march="nash-m", opt=2, progress_bar=True, jobs=48)

# link生成打包模型，后缀名为.hbm
hbm_name = "compiled.hbm"
hbm = link([hboA, hboB], hbm_name)
# 如果在其他地方已经生成了hbo
# 可以通过 hbo = Hbo(hbo_name) 进行加载 所需头文件： from hbdk4.compiler.hbm import Hbo

3.2 打包模型推理

3.2.1 hrt\_model\_exec 工具推理

通过 hrt_model_exec model_info --model_file compiled.hbm 可查看打包模型的数量，输入输出等信息，示例如下

This model file has 2 model:
[2_backbone_head1]      [1_backbone_head1_head2]
---------------------------------------------------------------------
[model name]: 2_backbone_head1

input[0]:
name: ...

output[0]:
name: ...

---------------------------------------------------------------------

---------------------------------------------------------------------
[model name]: 1_backbone_head1_head2

input[0]:
name: ...

output[0]:
name: ...

output[1]:
name: ...

结合--model\_file 与--model\_name 即可实现对打包 compiled.hbm 模型中的某一个模型进行推理。

以 perf 评测打包 compiled.hbm 模型 中 2\_backbone\_head1 的性能为例，参考命令如下：

hrt_model_exec perf --model_file compiled.hbm --model_name 2_backbone_head1

3.2.2 UCP API 推理

在工具链用户手册《<u>统一计算平台 UCP - 模型推理开发 - 模型推理 API 手册 - 功能接口</u>》中，详细介绍了加载打包模型 hbDNNInitializeFromFiles 与 获取单个模型句柄 hbDNNGetModelHandle 的使用方式，截图如下：

在工具链开发包路径：OE/samples/ucp\_tutorial/dnn/basic\_samples 下方的示例中有用到这两个接口，可参考使用。

3.3 多任务不同帧率推理

根据需求，调整打包模型 compiled.hbm 中的 模型 1 backbone\_head1\_head2 与模型 2 backbone\_head1 的推理次数，即可实现不同任务采用不同帧率部署。

3.4 性能数据示例

下表中，backbone\_head1 是公共部分，​注意​：公共部分权重是一样的

可以看到，compiled.hbm 体积相比于 1\_backbone\_head1\_head2.hbm 并没有增加多少。

模型加载推理时，ION 内存差异如下：

加载 1\_backbone\_head1\_head2.hbm，直接推理：

加载 compiled.hbm，推理 1\_backbone\_head1\_head2：

可以看到，compiled.hbm 占用的内存相比于 1\_backbone\_head1\_head2.hbm 并没有增加多少。

前言

最近 AI 圈有个“红色胖龙虾”火得离谱。

它原来叫 Clawdbot，因为太火被 AI 巨头 Anthropic 盯上，直接一份<span style="color: red;font-size: 16px">“友好通知”</span>说你侵权。于是连夜改名 Moltbot，最后成了现在的 openClaw。

最魔幻的是，因为这玩意的爆火，全球的 Mac Mini 居然被这帮极客买涨价了。

大家都在传：只要 1 分钟，你就能在手机上远程白嫖一个 24 小时待命的“数字员工”。

作为一名不折腾会死星人，我也在本地部署折腾了几天。体验下来发现：

<span style="color: red;font-size: 16px">它确实很不错，是一个称得上“住”在你电脑并且拥有管理员权限的管理员，当然，如果姿势不对，它就是你硬盘的“拆迁办”。</span>

核心拆解：为什么是 openClaw？

很多兄弟会问：我用网页版 Claude/Gpt 不香吗？非要折腾这个？

这就是 openClaw 设计聪明的地方。它内置了非常丰富的 function calling 功能，并且拥有终端系统权限。

简单来说，以前的 AI 是关在笼子里的，只能跟你聊聊天。而现在的 openClaw 相当于给 AI 做成一个智能终端。它不再只是“建议你删掉多余文件”，而是会有可能直接一句“好的老板”，然后顺手在你的某个目录敲下<span style="color: red;font-size: 16px">rm -rf。</span>

这种从“问答”到“执行”的范式转变，才是让极客们高潮的根本原因。

技能树：全能战神 or 电子垃圾？

打开 openClaw 的 Skill 列表，多达 7 个分类，49 个默认 skill 可供配置。说实话，这地方最能体现“卖家秀”和“买家秀”的区别。

不过在我看来，绝大部分都是“洋垃圾”，大陆用户用不上。

那些会让你觉得“神了”的功能

亲身体验下来有几个组合功能比较值得推荐。

• TG+群聊机器人：将 openClaw 接入 Telegram，由于默认就有“长期记忆”功能，所以它能记住你们绝大部分对话，从而实现体验良好的私人或群聊机器人（也可以配置到飞书/企微）。
• 浏览器自动化：openClaw 原生具备控制浏览器的能力，能帮你在不方便打开电脑时操控电脑网页，并生成截图，对网页进行总结等等，效果不错。（浏览器万岁！）
• 定时提醒到手机：<span style="color: red;font-size: 16px">极其有用的一个功能</span>，并且因为可以连通到手机，这让 Agent 有望成为低配版本的“贾维斯”，比方说，你可以让它定时每天推送 GitHub Trending 并加以总结给你；又或者把你经常逛的新闻网站让 openClaw 爬取然后每天推送给你；更有甚者，可以尝试把日程安排全做成定时任务，让 openClaw 变成你的“个人助理”。
  
• 本地文件管理： 由于拥有终端权限，你可以让 openClaw 化身 C 盘清理专家，帮你清理本地垃圾文件或查询需要的文件等。
  

我们再来看下部分知乎用户对其的讨论

劝退指南？谁在给这只“龙虾”交税？

当然，作为一个还在“长身体”的开源项目，openClaw 远没到小白上手即用的程度。在折腾了一周后，我搜集了各大平台的反馈，基本可以总结为三个字：<span style="color: red;font-size: 16px">坑挺大</span>。

Windows 用户：“后妈”生的

目前来看，这款产品的评价呈现极端两极分化：Mac 用户直呼真香，Windows 用户直呼退钱。
大概率是因为作者和核心贡献者都是基于 Mac 环境开发的，导致 Windows 版的 Bug 密集成灾：路径识别错误、依赖冲突、环境变量玄学报错。如果你不是一个习惯折腾环境的开发者，<span style="color: red;font-size: 16px">千万别在 Windows 上挑战自己的血压</span>。
实在想玩，可以去买云厂商搞好的 9.9 元月付套餐，花杯奶茶钱买个清静。

手机写代码：“赛博行为艺术”？

有人吹嘘 openClaw 能让你在手机上远程撸代码。但听小弟一句劝，在手机上改 Bug 绝对是伪命题。
我做手机上尝试让它在帮我修复一个 JS 逻辑，结果......完全没有反馈，我就已经开始 瑟瑟发抖了，我对“盲写”并没有兴趣。你可以用它来紧急重启个服务，或者跑个自动化脚本，但真要拿它写代码？<span style="color: red;font-size: 16px">那你很牛。</span>

致命伤：“死循环”偷钱可能性

虽然发生概率很少，但这是 Agent 架构目前比较无解的痛点。

笔者之前有幸在 cursor 上体验过几次，由于提示词或大模型本身的判断逻辑出现异常，AI 有时会陷入一种“鬼打墙”的状态。

比如：你让它找一个文件，它找不着，然后触发“重试”技能；重试又找不着，再触发“搜索”技能……在这个过程中，它每动一下都在疯狂调用 API。

当你发现它还没干完活时，它可能已经在短短几分钟内烧掉了你一顿饭钱。如果不设 Token 熔断，可能会让你有亿点点肉疼。

最后

虽然有不少毛病，并且未必有啥提高产能的能力，但我依然对 openClaw 保持高关注，为什么？

因为这个项目的 Agent 具备了<span style="color: red;font-size: 16px">“权限”</span>。以前我们用 AI，是“一问一动”；现在是“一问多动”，甚至你设置好定时任务，它是“不问也动”。

<span style="color: red;font-size: 16px">这个项目开始，实现了从“对话”到“接管”。</span>

尽管它现在还会“拆家”，还会“乱花钱”，但这种架构值得我们共同关注。

本文由mdnice多平台发布