做数据这行的朋友，大概都熟悉这个流程：业务抛过来一个取数需求，你得先搞清楚人家说的"活跃用户"到底是哪个口径，然后翻表结构写SQL，跑完数还得跟业务对齐一遍，"这个数字跟你预期差多少？"整个流程走下来，快的两三天，慢的一周都不稀奇。 但2026年的风向已经很明朗了，这一切正在被Agent改写。 微软在Fabric里嵌入了Data Agent，阿里云推出了Agentic Lake，安克创新也在公开场合分享了第三代AI数据平台的架构设计。这些头部玩家不约而同在做同一件事：让数据仓库从一个"被动等着你查"的存储系统，变成一个"能理解你要什么、能自己想清楚该怎么做"的智能体底座。 这不是PPT上的画饼。接下来，我会基于当前已经公开的行业实践和技术走向，把Agent和数仓融合这件事拆开讲清楚，进展到哪一步了、架构长什么样、落地有哪些坑。 一、先纠正一个认知偏差，Agent要改造的不是数仓本身 很多人的第一反应是"Agent要替代数仓"，这个理解是有偏差的。 数据仓库真正的护城河，统一的数据存储、标准化的建模体系、稳定的计算性能，这些东西Agent替代不了，也不需要替代。Agent改变的是另外两件事：第一，人和数仓怎么打交道；第二，数仓自己怎么管自己。 具体来说，Agent在数仓场景里解决三个层面的问题： 门槛问题。业务人员不用再学SQL了，说人话就能查数据。但要注意，这跟早年那些"自然语言查数"产品有本质区别。那些产品本质上是个翻译器，你问一句它翻一句SQL，准确率惨不忍睹。Agent的做法是：先理解你的业务意图，再决定查哪些表、怎么关联、用什么口径，生成SQL之后还会自动校验，语法对不对、业务规则有没有违反、跑出来的数据合不合理，全部过了才给你结果。 效率问题。数据治理、质量监控、ETL调度这些日常运维工作，Agent能扛下来大部分。自动发现数据异常、沿血缘链路追踪问题源头、生成治理报告，这些以前需要数据工程师花大量时间做的事情，现在可以让Agent去跑。 决策问题。传统数仓的交互模式是"你问它答"，本质上是被动的。Agent驱动下的数仓能主动发现问题、提出建议，甚至在明确规则下直接执行修复。这形成了一个"感知-分析-决策-执行"的闭环，数仓从"被查询的工具"变成了"主动服务的系统"。 二、数仓架构的三代演进 要把Agent和数仓融合这件事讲透，得先把数仓自身的演进脉络捋清楚。大致可以分成三代： 第一代：传统数仓（约2000-2015年）。关键词是"批处理ETL +固定报表"。数据通过定时任务从业务库同步到数仓，工程师写ETL脚本做清洗转换，分析师写SQL出报表。这套东西跑起来很稳，但太笨重了，业务要加一个分析维度，可能要改好几个层级的表结构和ETL脚本，响应速度跟不上。 第二代：湖仓一体+语义层（约2015-2024年）。数据湖解决了非结构化数据的存储问题，湖仓一体进一步把存储和计算打通。语义层（比如dbt的Semantic Layer）让指标定义有了统一标准，业务方理论上可以自助取数了。但"自助分析"的门槛还是不低，你得懂数据模型，还得学BI工具怎么用。 第三代：Agent原生数据平台（2025年起）。在湖仓和语义层的基础上，Agent作为一层"智能中间件"插进了人和数据之间。它能理解自然语言意图、自动编排数据访问路径、自主执行治理任务。数仓不再只是个"存储+计算引擎"，而是一个具备感知和执行能力的智能体底座。 三、Agent原生数据平台的五层架构 综合微软Fabric、阿里云Agentic Lake、安克创新等公开实践，Agent原生数据平台的架构可以拆成五个层次。下面逐层讲。 1. 交互层：业务侧的入口 交互层支持文字、语音、图片等多模态输入。用户用自然语言描述需求，比如"帮我看看华东区上个月各品类的销售走势"，交互层负责把这个模糊的需求转成结构化的任务指令。 这里有一个关键的行业认知需要澄清：交互层的核心不是做一个"好看的聊天框"，而是意图理解的准确率。直接拿通用大模型来理解业务查询，准确率通常只有60%-70%，离生产可用差很远。真正的解法是在交互层和Agent编排层之间加一层语义校验机制，Agent生成的SQL要过三道关：语法校验、业务规则校验、数据合理性校验，全部通过后才返回结果。 2. Agent编排层：多智能体协作的中枢 这是整个架构的核心。它不是一个Agent单打独斗，而是一个由多个专业Agent组成的协作网络。根据当前公开案例，常见的Agent角色包括： Agent角色 核心职责 当前成熟度 意图识别Agent 解析自然语言，识别查询意图、筛选条件和聚合维度 较高 SQL生成Agent 基于语义层和元数据，生成可执行的SQL 较高 数据质量Agent 监控数据质量异常，自动触发告警和修复 中等 ETL调度Agent 智能调度数据同步任务，处理依赖和异常 中等 指标管理Agent 维护指标定义，检测口径冲突，自动对齐 早期 多个Agent之间怎么协作？当前行业主流的做法是"编排式"架构，一个中央编排器（Orchestrator）根据任务类型分派给对应的专业Agent。好处是可控、可审计；缺点是复杂任务的协作规则需要预先定义，灵活性受限。 另一种是"对等式"多Agent架构，各Agent自主协商完成任务。但目前基本还在学术研究阶段，企业级生产环境落地的案例非常少。 3. 语义与知识层：Agent的"业务常识" 这一层是Agent准确理解业务的前提。没有语义层，Agent就像一个精通SQL语法但完全不懂业务的人，能写出语法正确的查询，但结果可能南辕北辙。 语义层的建设核心包括三块： 业务词汇表。定义业务术语与物理表字段的映射。比如"活跃用户"在不同业务场景下怎么算、数据从哪来、计算逻辑是什么。这是Agent理解业务意图的地基。 知识图谱。存储数据之间的关联，数据血缘、指标依赖、业务实体关系。Agent做根因分析时，需要沿着图谱的关联路径进行推理。 指标存储。标准化的指标定义和管理，保证同一个指标在不同Agent、不同场景下的计算结果一致。 阿里云在2026年峰会上提出的"Agentic Lake"架构，核心思路就是把DLF（数据湖管理平台）升级成Agent的"记忆底座"，让Agent记住企业的数据资产关系、业务口径和历史交互上下文。这个思路很关键：语义层不只是翻译字典，更是Agent的长期记忆。 4. 数据存储与计算层 这一层本质上还是湖仓一体的存储和计算引擎，架构层面变化不大。核心组件包括数据湖（Iceberg/Hudi/Delta Lake）、数仓计算引擎（Spark/Flink/StarRocks等）、实时和离线两条计算链路。 Agent在这一层的价值主要体现在执行优化上，根据查询特征自动选择最优的计算引擎和资源配比，而不是靠人工经验配置。Snowflake的Cortex和Databricks的AI/ML功能已经在这个方向上做了不少探索。 5. 数据源层 结构化数据库、日志系统、SaaS应用、IoT设备、文件系统等，与传统架构没有本质区别。但Agent可以自动化完成更多的数据接入和Schema推断工作，降低运维成本。 四、数据治理，Agent最有可能率先规模化落地的场景 数据治理是数仓运营中最吃人力、也最容易被Agent改造的环节，值得重点展开。 传统的数据治理高度依赖人工，工程师发现问题、分析原因、修复问题、更新文档。整个链路是被动响应式的，出了事才处理，效率很低。 Agent驱动的数据治理，核心转变是从"被动响应"到"主动闭环"，六个环节形成自动化链条： 感知层：Agent充当数据哨兵 通过持续的数据探查（Data Profiling）和变更监控，自动捕捉异常。比如某个字段的空值率从2%突然跳到15%，或者某张表的行数同比减少了30%。这些异常散落在海量监控数据中，人工很难第一时间发现，但Agent可以7×24小时不间断扫描。 理解层：Agent充当数据侦探 发现异常后，Agent沿数据血缘链路追踪问题源头。比如某张报表数据异常，Agent可以自动追溯到上游ETL任务的调度延迟、源表Schema变更、或上游业务系统的数据传输故障。这一步技术难度最高，严重依赖元数据管理的完善程度。 决策层：Agent充当治理参谋 根据异常的严重程度和影响范围，Agent给出处理建议：低优先级问题自动创建工单排队，高优先级问题（如影响核心报表数据）立即告警并推荐修复方案。 执行层：Agent充当自动修复工 对于规则明确的问题（数据格式不统一、字段缺失、编码错误等），Agent可以直接执行修复。对于需要人工判断的问题（如业务口径变更），Agent生成详细的诊断报告和修复建议，交给数据治理专员审核后执行。 需要实话实说：完全自动化的数据治理闭环目前还做不到。行业实践采取的是人机协同策略，Agent处理80%的常规任务，剩下20%需要人类判断的复杂问题交给专员处理。这个比例在未来一两年内有望继续提升。 五、现实的进度条，哪些已经能落地，哪些还在画饼 已经可以落地的场景 Text-to-SQL查询。技术已相对成熟，dbt Copilot、Microsoft Fabric Data Agent等产品已支持生产级使用。前提条件是语义层建设到位，且查询场景相对标准化（如固定维度的销售分析、用户分析）。 自动化数据质量监控。规则明确的质量检测（空值率、唯一性、格式校验等）已可自动化。Agent在此基础上能做异常根因的初步分析和影响评估。 元数据管理和文档生成。Agent可以自动扫描表结构、生成数据字典、维护血缘关系文档。这是目前落地门槛最低的Agent应用场景之一。 仍在探索中的场景 自动化ETL开发。Agent能根据业务需求生成ETL脚本，但复杂的数据转换逻辑（多表Join、窗口函数、自定义UDF等）仍然需要工程师深度介入。当前Agent生成的ETL脚本需要人工Review的比例在60%以上。 智能数据建模。Agent可以根据业务描述建议维度模型的设计（事实表、维度表的选择），但数据建模需要对业务有深度理解，完全自动化尚不现实。 多Agent自主协作。"对等式"多Agent架构在学术层面有不少探索，但企业级生产环境的案例极少，可靠性和可审计性都不够。 一句话概括当前状态：Agent在数仓场景中的定位是"提效工具"，不是"替代方案"。它能显著降低数据消费的门槛、减少治理的人力投入，但离"完全自主运行"还有相当距离。2026年是Agent+数仓从POC走向规模落地的关键年份，但短期内的务实预期是"人机协同"，而非"全自动"。 六、给想动手的团队三条建议 如果你所在的数据团队正在考虑引入Agent能力，基于当前行业实践，有三条务实的切入路径： 第一条，先把语义层建好。语义层是Agent理解业务的前提。没有语义层，Agent就是"瞎子摸象"，能写SQL但不理解业务。语义层建设不依赖AI技术，核心是梳理业务指标体系、定义标准口径、建立术语表。这个工作即便不引入Agent，也是数据治理的基础工程，早做早受益。 第二条，从数据治理场景切入。相比直接让Agent写SQL给业务方用（涉及数据安全和准确性风险），让Agent先承担数据质量监控、元数据管理、文档生成等内部运维任务，风险更低、见效更快。这也是目前行业落地最成熟的路径。 第三条，建立 信任分级 机制。Agent在数仓场景中生成的SQL、做出的治理决策，必须经过可信度分级。高置信度的操作自动执行，低置信度的必须人工审批。微软Fabric Data Agent的设计中就包含明确的权限和审批机制，这个思路值得借鉴。 写在最后 Agent与数据仓库的融合，正在从技术讨论变成工程现实。2026年的信号已经非常清晰：头部云厂商和标杆企业都在围绕Agent重新构建数据平台的能力边界。 但作为从业者，需要保持清醒的认知。Agent不是万能药，不会一夜之间颠覆数仓的底层逻辑。数据仓库的核心价值，统一、标准、可信的数据基座，依然不可替代。Agent真正改变的是"人怎么用数仓"和"数仓怎么管自己"这两件事。 真正值得思考的问题不是"Agent会不会取代数仓"，而是"你的数仓准备好迎接Agent了吗"，语义层是否完善、元数据管理是否到位、治理流程是否标准化。这些基础功课做扎实了，Agent能力的引入才会水到渠成。 来源（公众号）：华哥聊数据

一、传统数仓的“三座大山” ETL脚本上千行，调度任务上百个，元数据却一团乱麻。传统数仓的“三座大山”：开发效率低，一个ETL任务从需求到上线至少两三天；治理靠人工，元数据补全、质量监控还在用Excel维护；分析门槛高，业务方看个数据得排队，分析师70%的时间花在取数上。 2025年至2026年，AI Agent技术突然火了，给这些老问题带来了新解法。这篇文章不扯概念，直接说怎么落地。 二、Agent + 数仓到底是个啥？ 先说清楚，Agent不是来取代数据工程师的，就是个辅助。说白了就是给大模型接上API，让它能看懂元数据、能写SQL、能调接口、能盯着任务跑、出问题了还能自己试着修。数据工程师的角色从“写代码”变成“指挥Agent干活”，把精力腾出来做更有价值的事。 Agent + 数仓的核心逻辑很简单：把那些确定性的、重复的工作交给机器，不确定的、需要判断的留给人。不是无人驾驶，是辅助驾驶。 从架构上看，大概分三层： 三、四个能落地的方向 1. 智能ETL 这个方向目前落地最多。以前做个ETL任务，先跟业务对需求，再写SQL，配调度，上线后发现数据不对还得排查。现在Agent可以这么干：你丢一句“把昨天新增用户按省份汇总”，它自己去查元数据找到对应的表和字段，把SQL写好，跑测试用例校验数据质量，配好调度和告警，任务失败了还能自动翻日志找原因。 我们在一个200多张表、日均500多个任务的数仓上试过，ETL开发效率大概提了60%，数据质量出问题到发现的时间从小时级降到了分钟级。当然，复杂的业务逻辑和模型重构还是得人盯着。 2. 元数据管理 干过数仓的都懂，元数据基本是“欠债”状态。字段没注释、表关系不清楚、口径文档跟实际代码对不上——太常见了。 Agent在这块能干三件事：一是自动补全，读SQL脚本推断字段的业务含义，准确率能到85%以上，人工过一遍就行；二是血缘解析，自动建字段级的血缘关系，上游表结构变了能评估影响范围；三是对口径，对比同名指标在不同报表里的SQL实现，发现不一致的地方标出来。 注意，Agent不是从零建血缘，它是在已有的SQL解析结果上补充业务语义，让血缘关系变得“能看懂”。 3. 数据质量 传统质量监控两个痛点：规则全靠人工配，太累；告警太多，看不过来。Agent的做法是：根据字段的数据类型和分布特征，自动推荐质量规则，你审核一下就行。告警触发了，Agent自动拉上下游数据分析原因，给出修复建议。常见问题像空值填充、格式标准化这些，Agent直接修了，复杂问题生成方案等人确认。 在某电商数仓项目里，质量规则覆盖率从35%干到了79%，误报率降了大概36%。 4. 智能BI 这个场景用户感知最强。业务方直接问“上个月华东区销售额TOP10品类是哪些”，Agent理解问题、查元数据、生成SQL、出结果。追问“按周看趋势”，Agent保持上下文继续往下分析。还能定时扫关键指标，发现异常主动推预警。 但别指望Agent替代分析师，它只是把“取数”这个环节的门槛降低了。真正有价值的洞察，还得靠人。 来源（公众号）：华哥聊数据

数字化转型浪潮下，企业IT运维正在经历一场深刻变革。传统的"救火式"运维模式已难以应对日益复杂的IT环境，AI驱动的智能运维（AIOps）正成为企业IT管理的新范式。 一、传统运维的困境 过去十年，企业IT环境发生了翻天覆地的变化： 系统复杂度激增：微服务架构、容器化部署、混合云环境让系统拓扑变得极其复杂 数据量爆炸：监控指标、日志数据、告警信息每天以TB级增长 响应压力剧增：用户对系统可用性的期望从"99%"提升至"99.99%" 传统运维团队面临的核心挑战是：如何在海量数据中快速定位问题根源，并实现主动预防而非被动响应？ 二、AIOps的核心能力 AIOps（Artificial Intelligence for IT Operations）通过机器学习、大数据分析和自动化技术，为运维带来三大核心能力： 1. 智能异常检测 传统阈值告警存在两大问题：阈值设置依赖经验，且难以适应动态变化的业务场景。AI驱动的异常检测能够： 自动学习系统正常行为模式 实时识别偏离基准的异常信号 降低误报率，提升告警精准度 某大型电商平台实施AIOps后，告警数量减少70%，有效告警比例从15%提升至85%。 2. 根因定位自动化 当系统出现故障时，运维人员往往需要在数十个甚至上百个组件中排查。AI能够： 自动关联分析日志、指标、变更记录 构建因果推理模型，快速定位故障源头 生成修复建议，加速问题解决 实际案例显示，AIOps将平均故障定位时间（MTTD）从30分钟缩短至5分钟。 3. 预测与预防 这是AIOps最具价值的场景——从"事后补救"转向"事前预防"： 预测资源容量瓶颈，提前扩容 识别性能下降趋势，主动干预 分析历史故障模式，推荐预防措施 一家金融服务公司通过AI预测模型，在CPU负载达到阈值前24小时发出预警，避免了数次潜在的系统崩溃。 三、实施路径与实践建议 第一步：数据整合 AIOps的基础是高质量的数据。企业需要： 统一监控平台，整合日志、指标、追踪数据 建立数据治理规范，确保数据质量 构建事件关联图谱，打通数据孤岛 第二步：场景切入 不要试图一步到位。建议从以下场景切入： 场景 预期收益 实施难度 告警降噪 告警减少50-70% 低 异常检测 误报降低60% 中 根因分析 定位时间缩短80% 中高 预测预防 故障减少30% 高 第三步：团队转型 技术变革需要组织变革配合： 运维人员技能升级：从脚本编写到数据分析 跨团队协作机制：DevOps与AIOps团队深度融合 决策流程优化：建立AI辅助决策的信任机制 四、挑战与应对 AIOps实施并非一帆风顺，常见挑战包括： 数据质量问题 问题：数据缺失、格式不一致、噪声干扰影响AI模型效果。 应对：投入数据清洗和标准化工作，建立数据质量监控机制。 人才缺口 问题：同时懂运维和数据科学的复合型人才稀缺。 应对：内部培养与外部引进结合，建立学习型组织文化。 组织阻力 问题：运维团队对AI决策的信任度不足，担心自动化带来的风险。 应对：从小场景开始验证效果，逐步建立信任；保留人工干预机制作为安全网。 五、展望：智能运维的未来 2026年，AIOps正在从"辅助工具"演进为"核心能力"。未来趋势包括： 自愈系统：AI不仅发现问题，还能自动执行修复 运维大模型：基于LLM的运维助手，提供自然语言交互 边缘智能运维：将AI能力下沉到边缘节点，实现分布式运维 对于CIO和IT管理者而言，AIOps已不再是选择题，而是必答题。那些能够率先实现智能运维转型的企业，将在数字化竞争中占据先机。 结语 从被动响应到主动预防，AI正在重塑IT运维的本质。这不仅是技术的升级，更是运维思维的根本转变。 当AI能够提前预警潜在故障，当系统具备自愈能力，当运维团队从"救火队员"转型为"预防专家"——这才是数字化运维应有的样子。 行动起来吧，让AI成为你运维转型的加速器。 来源（公众号）：IT管理知识库

编者按：今年政府工作报告首次提出“打造智能经济新形态”，并指出要深化数据资源开发利用，健全数据要素基础制度，建设高质量数据集。为探索工业数据“采”“集”“用”有效路径，工业和信息化部近日印发通知，启动工业数据筑基行动，开展面向人工智能赋能的高质量行业数据集建设先行先试，业界反应热烈。安徽省工业和信息化厅二级巡视员、安徽省新经济联合会会长潘峰特为本报撰写文章，就高质量数据集建设路径展开讨论。 在“人工智能+”行动深入推进的时代背景下，高质量数据集已成为驱动产业智能化转型、培育新质生产力的核心要素。其价值不仅在于数据本身的精准性与标准化，更在于通过集群化效应实现从单点突破到面状发展的跨越式赋能。如何构建可持续、可推广、可落地的高质量数据集发展体系，推动高质量数据集建设收获“规模红利”，并向“质量红利”“生态红利”跃递？笔者在此提出“三二一”思路，希望能为这项创新性工作做些抛砖引玉的尝试。 坚持三个导向 所谓“三”，是指坚持问题导向、价值导向、市场导向这三个导向，以期锚定高质量数据集解决实际问题、创造核心价值、实现持续运转的生命根基。 问题导向是高质量数据集的立身之本。数据集的成功，关键就在于精准切入全产业链发展中的痛点，有针对性地解决生产决策、供需对接、研发制造过程中的难点问题。合肥的杰士杰公司是一家生产改性工程塑料和高分子复合材料的公司，在企业发展过程中，一个难题就是，客户越来越多，需求品种已经超过了5000种，每一个品种的配方都要千百次地研发尝试，科研成本效率亟待提升。后来公司找到芜湖智唐科技公司，该公司直面这个棘手问题，从相关数据搜集、清洗、统一标准、标注等开始，建立起高质量数据集，然后用高质量数据集“喂”出相应的工业模型，最终打造出工业智能体，一举解决了这个问题。现在，相应的产品配方都是AI自动生成的了，研发效率提升80%以上，大大节约了科研成本。杰士杰公司对此成就感到惊喜，立刻又着手和智唐公司合作解决其他棘手问题，目前已打造出三个智能体，全面提升了企业效率。这个案例让我们充分认识到，只有聚焦企业的难点、痛点问题，所构建的高质量数据集才能体现出价值，使之真正成为企业降本增效的“利器”，这也是人工智能赋能新型工业化的核心逻辑。问题导向下的数据集建设，拒绝“为建而建”的形式主义，坚持“有用才建”的务实原则，让数据真正成为破解产业发展瓶颈的“金钥匙”。 价值导向是高质量数据集的推广之要。我们今天有声有色地开展高质量数据集建设，是为了让更多的企业从中受益，最大程度地摊开价值之饼。如何做到呢？就是要从成功的个性案例中萃取出共性的东西来，然后用这个共性的东西，为更多的企业送去福音。第一步，基于个性化的共性萃取。笔者在此提出“因式分解+取最大公约数+共性模型化处理”的方法。“因式分解”，就是把解决企业问题的数据集细分成若干单元因子。“取最大公约数”，就是把解决同一类问题（不同案例）的相同单元因子取出来。“共性模型化处理”，就是把同一类问题带有共性的单元因子处理成模型单元。第二步，借助共性化模型单元，结合企业具体情况，加以微调处理，形成众多不同企业的个性化解决方案。这样，就可以实现从单点应用到批量赋能的辐射效应，实现高质量数据集建设的价值更大化，实现解决一类问题，带动一片产业。合肥的零壹数智公司正在这方面进行积极探索，并取得一定的成效，在为阳光电源、雅迪这样的大公司建设高质量数据集的过程中，已经形成若干共性的模型单元，这让它们有条件为更多的企业高效地送去AI赋能服务。 市场导向是高质量数据集的续航之基，旨在通过市场化运作逻辑实现可持续发展。数据采集、治理、标注、更新等数据全生命周期环节均需持续投入，单纯依靠政策扶持或公益投入难以长久。市场导向下的高质量数据集建设，不仅要考虑技术可行性，更要设计清晰的价值变现路径，通过数据产品、技术服务、授权使用等多元模式，让数据要素在流通中实现价值增值，为数据集的持续迭代提供不竭动力。杰士杰公司和智唐公司就有意把他们基于高质量数据集建设起来的三个智能体剥离出来，成立新的AI赋能公司，以一种新的业态开展普适性的服务。在这项崭新的数字技术实践过程中，我们希望能有更多的新模式、新业态与之匹配。 尝试两条路径 所谓“二”，是指“可解耦”和“不可解耦”两条路径，以期破解高质量数据集的推广难题。 当前高质量数据集建设面临的最大难题就是共享与隐私之间形成的矛盾。龙头企业走出了高质量数据集建设之路，但是出于对企业隐私的顾虑，多数企业不愿意把自己的数据集拿出来共享。怎么解决？笔者提出可解耦与不可解耦两条路径并行发展之策，以期既兼顾中小企业的共享需求，又尊重龙头企业的隐私诉求，实现“普惠性”与“特殊性”的有机统一。 可解耦路径，主要是针对产业集群的共性需求，通过数据共享构建“普惠型”高质量数据集。在中小企业密集的产业集群中，单一企业的数据规模小、覆盖面窄，难以形成高质量数据集，但众多企业的共性问题为数据共享提供了基础。通过行业联盟或第三方平台组织，引导企业贡献非涉密的共性数据，经过标准化治理，形成可剥离、可共享的数据集，能够有效降低中小企业的智能化转型成本。中国农业科学院构建的企业典型作业场景多模态数据集，正是通过“申请-授权”的共享机制，整合多家生产单位的作业数据，支撑AI算法研发与智能装备创制，帮助相关企业节省劳动力10%以上。这种路径的核心价值在于“聚沙成塔”，让中小企业无须单独投入高昂成本，即可享受高质量数据集的赋能，同时通过数据共享进一步丰富数据集的多样性与完整性，形成“共享-赋能-共赢”的良性生态。我们今天已经建成许多产业集群，完全可以针对不同细分行业的共性生产问题，构建起跨企业的可解耦数据集，推动整个产业集群的智能化水平提升。 不可解耦路径，立足龙头企业的隐私保护与生态引领，通过“数据集+大模型+生态”模式实现“辐射型”赋能。龙头企业往往拥有海量高价值数据，但这些数据涉及商业秘密或核心技术，难以直接共享。对此，可以鼓励龙头企业依托自身数据资源构建私有高质量数据集，训练行业专用大模型与智能体，通过生态合作的方式，带动上下游企业发展。西门子与微软联合推出的工业元宇宙计划，正是依托西门子的工业全生命周期数据构建专有数据集，通过大模型赋能生态合作伙伴的生产优化与创新研发。国内医疗领域的龙头医院联合科研机构构建的专病病例库，虽未直接开放原始数据，但通过模型输出诊断辅助方案、科研分析结果等方式，赋能基层医疗机构与相关企业，实现了“数据不流出、价值流出去”的效果。这种路径既保障了龙头企业的数据安全，又发挥了其技术与资源优势，通过带动100家、200家生态企业共同发展，形成产业生态的“领头雁”效应，同样是高质量数据集集群化赋能的重要实现方式。 打造一个联合体 所谓“一”，是指打造一个联合体，以期凝聚起高质量数据集的建设合力。 高质量数据集建设涉及数据采集、治理、标注、应用等多个环节，跨越政府、企业、科研机构等多个主体，单靠任何一方都难以完成系统性建设，构建“政产学研金服用”联合体是破解协同难题的关键。联合体的核心价值在于整合各方优势，形成“数据资源+技术研发+场景应用+政策保障”的闭环体系。政府部门发挥政策引导与资源协调作用，通过出台扶持政策、制定行业标准、搭建公共平台等方式营造良好环境。研究机构则聚焦核心技术攻关，突破智能标注、数据安全流通、质量评估等关键技术，为数据集建设提供方法论与工具支撑。制造企业、数字化企业、软件企业，包括金融单位、相关服务单位等作为关联主体，既是数据集的使用者，也是数据资源的提供者与应用场景的贡献者，从各自角度为数据集建设提供支撑保障。在联合体机制下，各方通过联合攻关、成果共享、风险共担，能够有效破解“数据孤岛”、技术壁垒、标准不一等突出问题。例如，针对工业高质量数据集建设中存在的标准缺失问题，可由政府主导、科研机构牵头、企业参与，共同制定数据采集、标注、质量评估等系列标准；针对数据安全流通难题，可通过联合体共同研发隐私计算、区块链等技术方案，在保障安全的前提下，促进数据要素流动。最终，依托联合体构建的高质量数据集，能够形成“数据集-大模型-工业智能体”的技术链条，针对具体产业问题实现精准赋能，让数据要素的价值在协同创新中充分释放。 高质量数据集的建设不是孤立的技术工程，而是关乎产业升级、生态协同、可持续发展的系统工程。“三个导向”明确建设的价值逻辑，确保数据集“有用、能用、好用”；“两条路径”破解共享与隐私的矛盾，实现不同主体的差异化赋能；“一个联合体”凝聚了多方合力，为建设工作提供了组织保障。三者相互支撑、有机统一，可以共同构成高质量数据集从建设到应用、从单点到集群、从短期突破到长期发展的完整路径。 来源（公众号）：CDO之家

我最近有两个特别反感的地方。第一，人们把语义学中一些众所周知的技术，改名为“语境”，然后宣称整个话题是全新的，好像人工智能刚刚创造出来似的。第二，专家们讲解元数据、语义学、分类学、本体论、知识图谱和语境时，一个例子都不举，结果反而让听众更加困惑。 在我的职业生涯中，我目睹了所谓的“护城河”在整个技术栈中不断摇摆。早期，存储数据的供应商（关系型数据库供应商）掌握着主导权。后来，护城河转移到了应用层（ERP系统），再到API网关，最终到达了BI工具。最近，基础架构模型公司也开始声称拥有同样的地位。 现在，整个技术栈的供应商都围绕着“上下文层”重新定位，声称上下文是重心，将解决概率模型和代理对企业数据缺乏真正了解的缺陷。 在这篇文章中，我将用具体的例子来阐释上下文概念背后的原理，这也是我希望更多人能做到的。最后，我会分享自己关于如何构建上下文层的看法。 为什么是现在？ 过去两年发生的四件事使得一个由来已久的争论突然变得迫在眉睫。 首先，自主代理出现了。它们代表我们读取文档、编写代码、提交工单和调用API，取代了以往软件仅提供信息的功能。 其次，出错的代价也随之增加。如果仪表盘上“收入”的定义模糊不清，首席财务官就会感到恼火。同样定义模糊的代理人可能会基于错误的数字发放退款、发送电子邮件或提交合规报告。 第三，技术终于成熟了。LLM（大型语言模型）能够从非结构化文本中提取实体和关系，图数据库已经成熟，OSI、MCP、Delta Share和Iceberg REST 目录等标准正在快速融合。非结构化数据现在可以像结构化数据一样发挥作用了。 第四，数据消费者发生了变化。过去，人类每天只进行少量查询，可以通过判断和对话来接受缓慢或不一致的答案。而智能代理发出的查询数量级要多得多，它们既不具备判断力，也不具备沟通能力。 当人们从三份不同的报告中得到三个不同的收入数据时，我们会通过对话来调和这些不一致之处，从而容忍这种混乱。但一旦消费者成为代理人，同样的混乱就会演变成运营风险。如果我们现在不解决语义问题，人工智能不仅无法解决我们的一致性问题，反而会加剧这个问题。 常见问题解答 供应商经常把元数据、语义、分类、本体、知识图谱和上下文等术语混用。买家不知道该问什么，而中间的架构师则不得不负责翻译。但这六个术语并非相互竞争的概念，它们构成了一个技术栈。每一层都负责特定的任务，缺一不可。正是这个技术栈区分了会产生幻觉的人工智能代理和不会产生幻觉的人工智能代理。 这篇文章是我在任何关于架构的讨论深入之前都需要向别人提供的常见问题解答。为了使内容更具体，我举了两个例子：我最近购买的MacBook Air，以及一位客服人员正在处理的一个零件缺陷投诉。这两个例子几乎出现在每个答案中。 1.元数据、语义、分类、本体、知识图谱和上下文的定义是什么？ 2. 它们之间有什么关系？ 3. 语义层物理上位于哪里？ 4. OSI（开放语义交换）等标准的作用是什么？ 5. 上下文层是如何构建和持久化的？ 1. 这些定义是什么？ 随着这些话题从学术会议上的趣味话题转变为首席数据官（CDO）的优先事项，定义是第一步。抽象的定义容易被遗忘，但举例子能让它们变得具体。 (1)元数据 元数据是关于数据的数据。例如，MacBook Air 出厂时带有序列号、型号标识符、生产日期、原产国、保修起始日期、订单号和发货时间戳。这些信息都不是笔记本电脑本身，而是对笔记本电脑的描述。 在笔记本电脑内部，每个文件都会被赋予元数据：创建日期、修改日期、所有者、权限和 MIME 类型。元数据使资产可查找、可管理且值得信赖。它是其他所有层级赖以生存的基础。 元数据进一步分为技术元数据、操作元数据、社交元数据和业务元数据： 技术元数据就是我们过去所说的数据字典：表格的结构，包括列名、数据类型和长度等。 操作元数据描述动态数据：新鲜度、上次刷新时间、管道运行持续时间、错误计数、查询延迟。 社交元数据是用户贡献的隐性知识：管理者的认可、评分、评论以及诸如有多少仪表板使用该表格之类的信号。 业务元数据描述了资产对组织的意义。名为 cust_addr_st 的列本身没有任何意义，直到它被定义为“这是客户所在的州，美国两位字母邮政编码，取自 ISO 3166-2:US 列表”。 这就是我们从元数据过渡到语义的地方。 (2)语义 语义是指赋予数据的意义。例如，列中的字符串“M5 MacBook Air”只有在经过编码后才能被理解为一台笔记本电脑，它指的是苹果公司的某个特定产品线。语义的作用在于将符号转化为事物：它告诉我们一行代表一个客户，一列代表一个价格，一个值代表一种货币，一个代码代表一个国家。 语义涵盖了围绕资产建立意义的一切要素，包括： 定义：商业术语的精确且共同的含义。“活跃客户”是指在过去 90 天内至少进行过一次交易的客户。“流失客户”不包括已暂停的账户，但包括降级到免费套餐的客户。 指标和关键绩效指标：数字的计算方式。“月度经常性收入”是指月末有效订阅价值的总和，不包括一次性费用和按比例计算的金额。每个指标要么只有一个标准定义，要么没有标准定义。 业务规则：政策和计算方法的适用范围。佣金仅适用于超过 10,000 美元的交易。30 天内的退款不计入销售配额。新客户价格仅适用于前 90 天。 层级结构和分类：概念如何层层递进。产品归类，客户细分，交易分阶段。这就是分类体系的运作方式。 语义是商业智能工具、分析师以及日益普及的人工智能代理在利用数据之前必须掌握的关键信息。没有语义，所有用户都只能靠猜测，从而导致结果不一致。 (3)分类 分类法是一种层级式分类，它将概念组织成父子关系。我的 MacBook Air 就位于任何电商网站都会使用的分类体系中：电子产品 → 电脑 → 笔记本电脑 → 苹果 → MacBook → MacBook Air → 13 英寸 → M5。每一层级都缩小了范围。正是有了分类法，你才能在不列举所有型号的情况下，简单地查询“显示所有笔记本电脑”。 企业在各个方面都依赖分类体系。产品归类，客户细分，交易流程分阶段，员工组织架构，行业分类（例如北美行业分类系统 (NAICS) 或全球行业分类系统 (GICS)）等标准，采购支出分类（例如联合国系统分类标准 (UNSPSC)），医疗诊断分类（例如国际疾病分类第十版 (ICD-10)）。每一种分类体系都构成一个父子树，并且都能帮助我们解答汇总问题。 同一资产通常同时属于多个分类体系。例如，我的 MacBook Air 就同时属于产品目录分类体系（笔记本电脑类）、支持分类体系（苹果硬件类）、监管分类体系（锂离子电池设备类）和会计分类体系（资本设备类）。大多数企业都有多个分类体系，每个体系都由不同的团队负责管理。 分类法无法描述 MacBook Air 运行 macOS 系统、与 iPhone 共享 iCloud 账户，或者与 AirPods 是同一订单购买的。这些都是关联关系，而非分类。一旦你需要描述关联关系，你就已经从分类法跨入了本体论的范畴。 (4)本体论 本体论是对实体、实体属性以及实体间关系的正式模型。分类法告诉你 MacBook Air是一种笔记本电脑，而本体论则告诉你 MacBook Air配备M5 芯片、预装macOS 系统、由客户拥有、通过订单销售，并且享有保修服务。名词是实体；连接实体的动词是关系。该模型同时编码了实体和关系。 本体由三个部分构成： 实体（正式名称为类）。领域中存在的事物。例如：客户、产品、订单、地址、保修、账户。 属性。每个实体所具有的特性。客户有姓名和电子邮件地址。产品有 SKU、价格和芯片代数。订单有日期和总金额。 关系。实体之间的法律联系。客户下订单。订单包含一件或多件产品。产品享有特定期限的保修服务。 分类法只提供层级结构。本体论则添加了属性和关系，并使这三者都可被机器读取。 本体是用RDFS和OWL等形式化语言编写的，这样软件不仅可以显示本体，还能对其进行推理。大多数领域已经存在行业标准本体：Schema.org为开放网络提供共享词汇表；FIBO为金融领域提供共享词汇表；SNOMED CT为临床医学领域提供共享词汇表；GS1则为全球供应链中的产品标识符提供标准化。 本体让机器能够推理意义，但它本身仍然只是一个模型。它定义了可能存在的事物、事物之间的关联以及可以推断出的信息。要回答一个实际的问题，你需要用真实的客户、真实的订单和真实的MacBook Air数据来填充它。填充后的版本就是知识图谱。 (5)知识图谱 知识图谱是本体与真实数据结合的产物。本体描述“每个客户都有订单，并且居住在某个地址”。知识图谱则描述“Sanjeev Mohan，账号 12345，于 2026 年 5 月 17 日下了订单号为 99887 的订单，购买了一台 MacBook Air（序列号 C02XYZ123），发货地址为 Main Street 123 号，并搭配了一部 iPhone（序列号 F2L456789），符合 AppleCare 服务计划 AP-2026-0517 的资格”。本体是模式，知识图谱则是填充了数据且可查询的该模式实例。 关于术语的说明：这种基于本体的视图描述的是一个RDF知识图谱。另一种常见的风格是带标签的属性图，它存储相同的节点、边和属性，但不需要正式的本体。我描述的是基于本体的这种类型，其中图是模型的填充实例。 知识图谱由三个结构要素构成： 节点。实际的实体。我的MacBook Air。我的Apple ID。我下的订单。 边。它们之间的实际关系。这台 MacBook Air 由这位顾客购买。此订单已发货至此地址。此 AppleCare 服务计划涵盖此序列号。 属性。节点和边所附加的属性。MacBook Air 节点包含序列号和芯片代数。“购买者”边包含购买日期和购买渠道。 其杀手锏功能在于多跳推理。SQL 几乎无法表达“查找所有与 30 天内退回同一型号商品的客户地址相同的客户”这样的需求，而知识图谱则能轻松实现。 具体到人工智能领域，GraphRAG 通过知识图谱构建检索流程，使智能体不仅能看到相关文档，还能看到围绕该文档的关联实体网络。这正是背诵型智能体和推理型智能体之间的区别。 在上面的例子中，知识图谱捕捉到了交易的所有信息：谁、什么、何时、何地以及如何进行。但它没有捕捉到我为什么选择这台 MacBook Air。这些决定存在于完全不同的信息库中。例如我的网络搜索记录、我之前提交的关于旧笔记本电脑的支持工单，以及我和家人的对话。将所有这些信息整合起来，针对特定时刻和特定用户，这就是我们所说的“上下文”。 (6)语境 上下文是凌驾于一切之上的情境感知。它连接各种记录系统，使客服人员不仅能够推断发生了什么，还能推断为什么会发生。关于客户交易的上下文可能存在于 Confluence 页面、查询日志、Slack 消息、电子邮件、Web 日志和产品文档中。 请注意，其中一些信号是实时信号，而非历史信号。上下文信息并非仅仅由存储的数据构成，它需要实时数据流。IBM于 2026 年斥资110 亿美元收购Confluent，其明确目标是“将实时数据打造为企业人工智能和智能体的引擎”，这正体现了这一点。如果没有上下文层下方的流式基础设施，你始终只能使用昨天的数据。 以客户支持为例。一位客户来电咨询MacBook Air键盘故障。客服人员掌握着结构化的记录：购买历史、保修状态、之前的工单。这部分比较容易处理，占比仅为10%。真正决定结果的上下文信息存在于数据库之外： 零件文档PDF文件，描述了特定生产批次中已知的缺陷模式。 网络服务器日志显示，该客户本周访问故障排除页面七次。 顾客在推特上公开批评了该品牌。 支持搜索栏的查询日志显示，他们在两天内输入了三次“退货政策”。 上周，一位现场工程师诊断出另一位客户的机器存在同样的缺陷，以下是与该工程师的电子邮件往来记录。 这些信息并非集中存在于某个地方，而且只有经过整合才能发挥作用。上下文正是将这些信号整合在一起的运行时行为。如果没有上下文层，智能体拥有数据，却无法做出判断。有了上下文层，智能体每次都能将意义、历史、意图和策略整合在一起进行推理。如果语义层提供词汇，知识图谱提供事实，那么上下文层则提供当下情境。 如果你听信硅谷风投的说法，上下文或许会成为下一个万亿美元的商机。但批评者认为，它不过是一个由来已久的知识工程难题，本体论专家们一直在努力解决。就目前而言，它看起来像是一个理论概念，之前的尝试屡屡失败。不过是旧瓶装新酒罢了。 2. 它们之间有什么关系？ 它们是堆叠结构中的层级，而非竞争关系。定义部分按照含义递增的顺序逐一讲解；而堆叠结构则按照相互依赖关系排列。 图 1：人工智能与自信满满的错误答案之间的屏障。 从下往上： 底层是物理数据：数据仓库、湖屋、操作数据库、文档库、消息队列、日志文件。元数据位于这一层之上，用于描述每一项资产。 上一层是本体，即意义的形式化模型。它定义了什么是顾客，产品有哪些属性，以及它们之间有哪些合法关系。分类体系存在于本体内部，是分类方案的层级骨架。 知识图谱使用真实的实体和关系来实例化本体。它是模型的填充版本，可以进行查询：是企业的持久上下文。 语义层位于所有这些之上，作为受监管的业务契约。它是语义的部署：指标、KPI、业务规则和计算逻辑。它提供的API会显示“本季度活跃客户数 = 12,847，以下是具体的统计方法”。它基于相同的定义为BI工具、分析师和AI代理提供服务。 最上面一层是上下文层：运行时程序集从下面的每一层提取正确的切片，加上用户身份、会话状态、最近的操作和适用的策略，并在做出决定时将其交给人类用户或自主代理。 将我的 MacBook Air 逐层分析，就能明白每一层的重要性。元数据层提供序列号和保修到期日。本体层定义了什么是笔记本电脑，以及它包含电池、芯片和保修。知识图谱层记录了我的笔记本电脑序列号为 C02XYZ123 并已关联到我的 Apple ID 等信息。语义层解释了“符合免费更换电池条件”的计算方式：保修有效且电池循环次数超过 1000 次且之前未更换过电池。上下文层在我发起支持聊天时，会将所有这些信息，包括我最近的搜索记录和技术人员的角色信息整合起来，并打包发送给回复我的客服人员。 跳过任何一层，系统都会不出所料地崩溃。没有元数据，就找不到任何信息。没有本体，每个人对“客户”的定义都不一样。没有知识图谱，你可以回答“卖了什么”，但回答不了“哪些东西和哪些东西关联”。没有语义层，每个仪表盘都会互相干扰。没有上下文层，代理拥有数据，却没有判断力。 下图显示了嵌入了我的 MacBook 示例的堆栈。 图 2：一台笔记本电脑从序列号到实际提供帮助的代理的整个流程。 3. 语义层物理上位于哪里？ 理论就到此为止。实践者面临的最大问题是如何以经济高效的方式实现这些概念。这些层应该具有持久性，以便人类和智能体可以互换使用。元数据已经持久化到数据目录中，通常被称为业务术语表。然而，随着我们向上层架构的构建，持久化问题变得更加复杂，这主要受可用性、可移植性和一致治理的需求驱动。例如，无论数据以何种方式和原因被使用，随着使用规模的扩大，性能损失都应该降到最低。 这要求很高。我们既想鱼与熊掌兼得。其中一些要求需要权衡取舍。错误的决策会导致这些理念与数据脱节，最终导致投资失败。 本节我们将探讨语义层持久化。我们看到每个供应商都声称自己是最佳存储位置。然而，实际上，存储这些概念的位置各有利弊。答案不出所料，取决于具体情况。这取决于最终用户群的规模、数据变化的频率和数量，以及谁最了解数据，从而最有能力保持这些概念的更新。 在我们探讨上下文层将位于何处之前，首先需要承认我们尚未解决一个更简单的问题：语义层目前位于何处？答案是，无处不在，又无处可寻： 商业智能 (BI) 工具：语义的概念最早由Business Objects公司在 20 世纪 90 年代初提出。自那时起，几乎所有 BI 工具都声称自己是存储语义的最佳平台。Looker在这方面做出了巨大努力，但微软的Power BI才是真正的标杆，它声称拥有超过 2000 万个语义模型。BI 工具市场依然活跃：一款相对较新的 BI 工具Omni最近以 15 亿美元的估值融资 1.2 亿美元。优点：对于真正了解数据及其使用模式的用户来说，操作最为直观。缺点：BI 工具可能存在用户锁定问题，并且可能与不支持 BI 的 AI 代理不兼容。 独立层：无论语义层存在于何处，它始终会造成某种程度的锁定。因此，像AtScale和Cube.dev这样的独立语义层供应商提供了一种独立的服务，供所有用户调用。优点：提供了一个独立的语义层，确保所有 BI 和 AI 用户的数据一致性。缺点：增加了数据工具的数量，并带来了一些运维开销。 数据治理工具： Collibra、Informatica、Atlan、Alation以及ServiceNow（收购data.world后）等数据目录一直是存储元数据、展示数据沿袭和应用访问策略的核心。它们声称能够存储语义，如今又能够存储上下文，这是一种自然而然的发展，正如Databricks的 Unity Catalog Metrics 等新产品所展现的那样。数据治理工具还包括Profisee和Reltio（已被SAP收购）等主数据管理 (MDM) 供应商，因为 MDM 的设计初衷就是通过黄金记录的概念来提供语义一致性。优点：语义与数据沿袭、策略和黄金记录并列，而数据管理员已经在这些方面开展工作。缺点：目录通常侧重于描述而非执行，因此定义可能与查询的实际运行方式存在偏差。 数据集成供应商：组织内部的大部分业务逻辑都位于数据集成层，因此像dbt （已被Fivetran收购）这样的供应商 声称自己是存储语义数据的理想场所。事实上，dbt 已根据 Apache 2.0 开源了 MetricFlow，并使用 Git 来存储指标。优点：非常适合数据沿袭分析。缺点：对业务用户来说不够直观。 数据存储供应商：Snowflake和BigQuery都引入了语义层，该语义层最接近数据表，并且无论使用者类型如何，都会强制执行。例如，AI 代理可以使用 MCP 等协议来访问语义层。优点：强大的集中式治理。缺点：本质上是特定于某个供应商的。 人工智能代理：代理通过提示上下文和工具描述来学习语义理解。这是目前人工智能厂商竞相研发的领域。优点：持续学习。缺点：应用范围有限，且该领域尚不成熟。 企业平台供应商： Palantir 的 Foundry 方案提供了最全面的集成，其本体嵌入平台内部，并由其前线部署工程师维护。优点：AI 代理可以原生运行在受管控的、可操作的本体之上。缺点：本体实际上是租用的，而非拥有的。治理工作由供应商负责，而非您。 这些层级分别由不同的角色使用，例如数据工程师、数据分析师、数据管理员和业务用户。仅由一个角色创建语义是有限的，因为他们的优先级和业务知识各不相同，这可能导致语义过时。语义需要经过测试和版本控制，以避免与底层数据发生偏差。幸运的是，由于开放标准的出现，语义层与底层数据的这种泾渭分明的界限正逐渐模糊。 4. OSI 等标准的作用是什么？ 企业数据领域一个不为人知的秘密是：每种工具都对“真相”有着各自不同的解读。商业智能工具有自己的指标库，数据目录有自己的术语表。转换工具中的语义层对“月度经常性收入”的定义可能与人工智能代理提示模板中的语义层定义不同。六种工具，六种MRR定义，一致性荡然无存。 标准打破了这种恶性循环。 开放语义交换 (OSI) 是此技术栈最相关的标准。OSI 的目标是以标准且可移植的格式定义指标一次，使其在任何地方都能被识别，无需手动重新映射。如果您的“活跃客户”定义符合 OSI 标准，那么您的Tableau仪表板、Snowflake语义视图、LangChain代理和 GraphRAG 查询都将读取相同的定义。该定义具有可移植性。截至 2026 年 5 月，已有超过 30 家公司注册支持 OSI，其中包括Salesforce和Databricks。 OSI 引入了更高层次的可移植性。例如，Snowflake 语义视图中定义的语义与Hex、ThoughtSpot和Omni等 BI 工具具有双向读写功能。这使得不同的用户可以选择由谁来创建和维护语义，并确保语义在技术栈的不同层级之间保持同步。 OSI 是更广泛模式的一部分。增量共享 (Delta Sharing) 正在成为跨组织数据共享的开放标准。Iceberg REST 目录正在逐渐成为表元数据的标准。模型上下文协议 (MCP) 最初由 Anthropic 公司提出，并于 2025 年底捐赠给 Linux 基金会旗下的 Agentic AI 基金会，如今已成为将 AI 代理连接到工具、数据和应用程序的事实标准。 本体论由一系列 W3C 标准构建而成。RDFS 提供基本的类和属性模型。OWL 提供推理结构，使软件能够推断新的事实。SKOS 负责分类法和术语表的词汇控制。PROV-O 对事实的来源（即其沿袭）进行建模。在此基础上，构建了之前介绍的领域本体论，例如 Schema.org、FIBO、SNOMED CT 和 GS1，它们都是符合 W3C 标准的词汇表，可供整个行业共享。 正是因为有了标准，美国邮政编码中的“加利福尼亚州”才用“CA”表示，而不是“加拿大”。令人遗憾的是，ISO 3166 标准中“CA”指的却是加拿大，而这正是标准存在的意义所在——为了规范这种歧义。 对于智能体人工智能而言，标准至关重要，不容商榷。一个需要调用五种工具并遍历三个数据源的智能体，不可能学习五种专有语义方案。OSI、MCP 和开放表格格式是智能体的通用语言。 5. 上下文层是如何构建和持久化的？ 我们已经花了相当多的时间来解释语义的各个方面。现在，是时候了解当今的上下文层是如何构建和存储的了。语义和上下文术语这两个术语经常被混用。希望这篇文章已经阐明，上下文层比语义层要大得多。也许这正是问题所在。当范围过于庞大时，实现起来就变得困难了。 前沿模型将上下文视为短暂的，仅在运行时为单个代理回合构建并丢弃。然而，跨会话持久化上下文可以让系统直接回答常见查询，从而减少昂贵的 LLM 往返次数和令牌成本。 在《设计人工智能驱动的数据基础》一书中，引入了“提取、上下文、链接”（ECL）模式来构建上下文层： 提取：上下文信息分散在各个地方，存在于结构化数据库、PDF、电子邮件、聊天记录、支持工单、产品评论和网页日志中。因此，首要需求是能够访问所有这些数据源。现有的集成模式（ETL、ELT、联合）是为人工通过 SQL 查询结构化表格数据而设计的，并非为这种混乱的多格式环境而设计。ECL 可以连接到所有数据源，无需您先将数据复制到一个数据仓库，即可从每个数据源中提取实体及其元数据。 上下文：找到数据源并不等同于理解它。一旦识别出实体，大型语言模型（LLM）就会推断它们的语义：每个实体是什么，它在您的业务中意味着什么，以及它与其他实体之间的关系。正是在这里，90% 的企业非结构化数据最终变得可用。零件文档 PDF 不再是一堆文本，而是变成了“产品 Z 上的缺陷模式 X，影响批次 Y”。这些上下文理解以本体的形式存储在目录中。 链接：最后一步通过知识图谱将提取出的上下文信息整合到企业内存中。它在遵守安全策略和业务流程的前提下，将数据库、文档和通信系统中的实体和上下文信息连接起来。其优势在于，代理可以通过 API 或 MCP 查询单一端点，而无需手动集成十几个系统。 这就是向上下文架构转变背后的微妙变化。传统的 RAG 架构在模型运行前将数据推送给代理，预先猜测其所需内容。上下文层则完全颠覆了这一模式：代理在运行时通过一个受控的端点获取其所需的确切数据。数据检索过程并未消失，而是得到了有效管理。 让我们回到之前提到的MacBook Air故障电话。提取功能会访问订单数据库、零件PDF、网络日志、客户的推文以及支持搜索日志。上下文功能会从每条信息中提取出具体含义：客户、序列号、故障模式、情绪和意图。链接功能会将这些信息整合到一个图中，这样客服人员看到的就是一个完整的故事，而不是几个互不关联的片段。这个可查询的链接视图就是上下文层。 一个值得注意的细微差别。当数据集在组织内部生成时，您可以通过数据契约预先定义其上下文，该契约声明了模式、字段语义和质量阈值。但当数据来自组织外部时，例如第三方数据源、合作伙伴数据或缺乏所有者的、管理不善的内部数据源，则无法预先定义上下文，而必须进行推断。ECL 正是自动化这一推断过程。 结束 在缺乏治理的元数据和不一致的语义之上构建上下文层，只会加速出错。在本文中，我们探讨了元数据、语义、分类法、本体、知识图谱和上下文的概念，但尚未涉及企业最关心的议题，例如安全性、治理、规模和成本。正如语义层几乎可以存在于技术栈的任何位置一样，上下文层最终也可能分布在多个层级，而不是集中在一个地方。 来源（公众号）；数据驱动智能

每隔几个月，同样的架构争论就会再次出现：企业 AI 系统是否需要 RDF 和 OWL，还是属性图就足够了？ 问题在于，这个问题本身就是错误的。 两者都以可预见的方式犯了错。 真正的问题不在于RDF/OWL是否比属性图更好，而在于：你要解决的是哪种语义问题？ 如果你正在构建一个具有明确关系且需要快速遍历的单系统代理，那么属性图可能正是合适的选择。但如果你正在构建跨平台、受监管、可审计的代理工作流，并且系统之间需要就含义达成一致，那么形式化本体论就显得尤为重要。 本指南为架构师提供了一个结构化的决策框架——以生产部署为基础——并明确规定了正式本体何时能够证明其成本合理，以及何时会增加复杂性而没有相应的收益。 我们究竟在选择什么？ 这场争论常常将不同层面的实施选择混为一谈。 RDF（资源描述框架）是一种数据模型：它由具有全局唯一URI的主语-谓语-宾语三元组组成，是W3C制定的链接数据标准表示方法。 OWL（Web本体语言）是一种用于RDF的模式语言。它允许您定义类、属性、关系，以及至关重要的推理规则。OWL推理器（例如Pellet或HermiT）可以推导出未显式存储的事实：如果AFxSpotContract是B的子类FinancialInstrument，推理器会自动推断出这种成员关系，而无需为每个实例显式存储。 SPARQL是 RDF 图的查询语言，相当于三元组存储的 SQL 语言。 SHACL（形状约束语言）是一种 RDF 词汇表，用于表达随数据一起传递的数据验证约束，而不是锁定在应用程序代码内部。 属性图（Neo4j、TigerGraph、Amazon Neptune）存储带有键值属性的节点和边。它们针对显式关系和操作遍历进行了优化。但它们并不提供 RDF/OWL 所设计的基于标准的语义模型、可移植的推理语义或全局共享的标识符规范。 问题不在于哪个“更好”，而在于它们是为了解决不同的问题而设计的。 影响决策的五个维度 1. 知识范围：单一系统与跨界 当您的知识仅限于单个应用程序、数据库或团队时，属性图就足够了。如果您拥有整个数据模型，属性图可以以极低的设置成本为您提供所需的一切。 当需要在组织或系统边界之间共享、比较或验证知识时，RDF/OWL 就变得至关重要了。 设想一个典型的企业采购环境。同一供应商同时出现vendor_id在ERP系统、party_ref合同管理系统、supplier_code发票平台和counterparty_id风险管理系统中。对于人工分析师而言，这只是日常的摩擦；而对于自主智能体来说，这却是一道难以逾越的障碍。 当你部署一个采购代理，需要验证供应商是否已获得合同批准才能发出采购订单时，你就是在要求它实时协调四个标识符、三个状态分类和两个“已批准供应商”的定义——而且没有人会注意到它何时连接错误。 “首选供应商”、“可寻址支出”、“合同价格”和“批准类别”等概念缺乏跨系统通用的定义。而RDF/OWL + SHACL则弥补了这一空白：本体只需定义Supplier一次，即可包含所有有效状态和约束。SHACL将这些约束表达为任何系统都能独立验证的形式。新加入工作流的代理导入本体，运行验证器，即可获知供应商是否符合共享定义。语义契约得以共享，集成工作量也随之减少。 2. 推理要求：存储的事实与推导的知识 这是大多数建筑师容易低估的一个方面。 属性图存储的是你输入的内容。添加一个新的子类后，你必须更新所有依赖于该层次结构的查询和应用程序。OWL 推理器会自动推断——你只需定义一次类层次结构，其含义就会自动在整个图中传播。 RDF/OWL 在以下情况下值得使用： 你需要发现其中存在的隐含矛盾（两个不可能同时为真的事实）。 您的域具有复杂的继承层次结构，并且会随着时间的推移而增长。 为了符合合规性或审计要求，您需要可证明的完整性。 属性图在以下情况下是正常的： 你需要快速遍历明确的、稳定的关系。 查询性能比推理完备性更重要 State Street GFRO 部署中使用了 Pellet（一个 OWL DL 推理器）进行工具层面的监管报告——因为这类报告需要完整性。基金层面的报告则使用参数化的 SPARQL，而没有使用完整的推理器，因为这类报告不需要推理的完整性。在需要完整性的地方使用推理器；在不需要完整性的地方则不使用。 3. 治理模型：应用所有制 vs. 数据可移植制 大多数属性图和专有平台部署都用作封闭式操作系统：平台决定哪些数据存在、哪些数据有效以及允许哪些操作。治理规则存在于平台逻辑、API、工作流定义或应用程序代码中。它们功能强大，但无法随数据一起流动。 RDF/OWL 提供开放的、基于标准的语义。SHACL 则通过可移植的验证机制对其进行补充。OWL适用于需要共享语义和推理的情况。SHACL 适用于需要可导出、版本化并由其他系统（包括发布机器可读要求的外部审计机构或监管机构）执行的数据质量约束的情况。 对于拥有复杂专有模型的平台而言，合适的框架在于：平台边界内的运维能力与跨平台边界的语义互操作性。两者都是合理的架构选择——问题在于你的多智能体设计实际需要的是哪一种。 4. 代理架构：单系统与跨平台协调 当一个平台上的AI代理将任务移交给另一个平台上的代理，而该代理又调用第三个平台上的工具时，认知协调机制并未建立。代理要么拥有共享的语义契约，要么做出一些会向下游传播的假设。 微软的 GraphRAG 研究（Edge 等人，2024/2025）展示了一种截然不同的方法：基于 LLM 的图结构。GraphRAG 并非预先定义模式，而是从非结构化文本中提取实体和关系，构建属性图，并利用莱顿社区检测将其划分为主题聚类。对于语料库级别的非结构化文本意义构建，GraphRAG 的性能显著优于传统的向量 RAG，其全面性胜率高达 72%–83%。 GraphRAG 和 RDF/OWL 并非对同一问题的相互竞争的答案。GraphRAG回答的是“该文档语料库的主题是什么？”，而 RDF/OWL 回答的是“该金融工具在我们五个源系统中是否符合巴塞尔协议 III 对一级资本的定义？”。第一个问题没有预先存在的模式；第二个问题则需要一个权威的模式。 5. 投资期限：短期速度与长期杠杆 RDF/OWL 确实存在前期成本：本体工程需要专门的技能，三元组存储的操作特性与关系数据库不同，而且 SPARQL 不如 SQL 常见。 属性图能让你更快地构建出可用的原型。Neo4j 的开发者体验远胜于任何三元组存储。 微积分发生变化的地方： 语义协调工作需要在多个源系统和团队之间重复进行——尤其是在添加新系统时。 数据质量溯源的外部监管要求 已建立的行业标准本体（金融领域采用 FIBO，医疗保健领域采用 SNOMED CT / HL7 FHIR，建筑领域采用 IFC） 跨组织或供应商边界运行的人工智能代理 在这些关键节点，RDF/OWL 的前期成本会分摊到所有使用该本体的系统中。道富银行团队向开放标准贡献了 62 个 FIBO 扩展——这项工作惠及所有符合 FIBO 标准的机构，而不仅仅是道富银行。 决策框架 首先，何时开始使用 RDF/OWL？ 何时使用属性图谱 + API： 实践中效果最佳的混合模式 在设计良好的企业系统中，这两种方法都不会被全盘采用。生产部署倾向于采用三层架构，其中每种图类型都承担其擅长的任务： 智能体记忆图/情景知识图谱——捕捉智能体的行为、决策及其原因；具有双时态溯源性；决策轨迹作为一种不断累积的制度资产。图式在交互过程中涌现，而非预先设定。（类似Zep的框架在此发挥作用。） 属性图谱 + GraphRAG在操作知识层——显式参考知识、语料库意义构建、快速遍历以进行推荐和检索。在此，领域知识变得可查询。 OWL 本体 + SHACL在语义契约层——跨组织边界共享含义、类层次结构、在需要时进行形式推理、外部各方无需导入您的平台即可执行的可移植验证。 三种需要避免的模式 模式 1：过早的形式本体论 一个团队构建单租户内部知识库，却花了六个月时间进行 OWL 建模、SPARQL 端点设计和推理器调优——而属性图只需两周就能解决这个问题。当既不需要跨边界交换，也不需要推理时，形式化本体就毫无价值。 模式二：大规模的图谱蔓延 一个团队为一个用例构建了一个属性图，并将其扩展到另外五个用例，然后与三个外部合作伙伴共享——结果发现他们之间没有统一的URI方案，没有可移植的约束，也无法验证合作伙伴对节点的解释是否一致。每个新的集成点都需要定制的协调方案。成本不断累积。 模式 3：将平台级语义层误认为可移植语义标准 许多企业平台都自带所谓的“本体”——一种跨平台共享的语义模型，能够在其生态系统内良好运行。其实，它本质上就是一个平台级的语义层。它解决了同一厂商内部的集成问题，但无法解决跨厂商的互操作性问题。 如果没有 OWL 导出、SPARQL 访问或可移植的 SHACL 约束，平台级语义层就无法作为跨平台代理协调的语义标准。从外部加入的新代理必须调用源平台的 API 并信任其解释，才能对其进行验证。 关于为何这种差距持续存在，需要说明一点：对于拥有成熟语义模型的平台而言，实现可移植语义契约在技术上并不困难。但在平台经济中，谁拥有协调层，谁就能获得不成比例的价值——而可移植标准打破了这种依赖关系。历史模式一脉相承：可移植性只有在监管机构强制要求（例如医疗保健领域的 FHIR，金融领域的 FIBO）或企业买家将其作为采购条件时才会出现。在此之前，应将可移植性视为一项需要明确定义的架构需求，而不是供应商会主动趋同的特性。 总结 对于受监管的行业而言，跨组织边界运营，拥有长期存在的数据资产，需要由您无法控制的系统和代理进行一致的解释，因此 RDF/OWL 并非过度设计。 对于语义含义稳定、易于理解且永远不需要外部方验证的单团队、单平台部署来说，这样做是过度的。 属性图并非“精简版的RDF”。它们是一种不同的工具：操作速度快、开发人员操作方便、并且具有LLM友好的归纳结构。 企业人工智能的未来不在于选择哪个图论阵营，而在于了解何时需要推断含义，何时需要验证含义，何时需要传递含义，以及何时只需要快速查询。 来源（公众号）：数据驱动智能

10%存储拖垮90% GPU投资？ 去年公司花1000万买了60台A100，老板把我叫到办公室问我AI项目的ROI怎么样。 我当时支支吾吾说不上来，后来才发现GPU利用率只有30%，大部分时间都在等数据。 这让我想起2023年我犯的一个错，以为买了顶级的GPU就能出效果，结果被存储系统拖垮了整个项目。 那个教训花了公司快100万，差点让我离职。 今天把这段经历分享出来，是想告诉各位IT管理者：存储不是配角，是GPU价值的放大器。 你GPU利用率低、AI推理速度慢、算不过来，问题可能不在GPU本身，而在被你忽略的存储系统。 一个反认知的观点 先说个反认知的观点：很多IT管理者认为存储就是存数据的，够用就行。 这种想法在AI时代特别危险。 IBM最新的研究发现，不到10%的存储投入，可能拖垮90%的GPU投资。 什么概念呢？ 你花1000万买GPU，只花100万配存储，结果GPU利用率只有30%，相当于700万的GPU投资被浪费了。 我给你一个参考数据，2023年那个项目，我们就是因为存储系统跟不上，导致GPU空转率高达70%，每个月的电费就要多交20万，这种隐形成本很容易被忽略。 为什么存储会成为GPU的瓶颈？ 为什么存储会成为GPU的瓶颈？我给你一个实用的判断方法。 AI训练的典型流程是这样的：GPU先从存储读取训练数据，然后进行计算，计算完成后再把结果写回存储。 这个过程中，如果存储的读写速度跟不上GPU的计算速度，GPU就会一直等待，就像法拉利装了个拖拉机引擎。 IBM的研究显示，AI训练过程中70%的时间GPU在等待数据，只有30%的时间在真正计算。 而存储系统的性能，直接决定了这70%等待时间的长短。 一个真实案例：50万撬动450万价值 我给你一个真实案例，去年我帮一个客户做AI平台优化，他们的GPU利用率一直维持在30%左右，老板以为GPU买少了，准备再投500万扩容。 我让他们先做一次存储诊断，发现存储系统的随机读写性能只有GPU需求的1/3。 后来他们只花了50万升级存储系统，GPU利用率直接从30%提升到65%，节省了450万的不必要GPU投资。 这个案例特别典型，很多IT管理者看到GPU利用率低，第一反应是买更多GPU，而不是先查存储瓶颈。 三个已验证的方法 具体怎么做？我给你三个已经验证过的方法，都是我踩过坑总结出来的。 方法一：全链路诊断 第一个方法是做一次全链路诊断，从数据采集、数据传输、到GPU加载，每个环节都要测速。 这个诊断不用花很多钱，找存储供应商做个免费的PoC测试就行，重点看三个指标：存储的随机读写IOPS、顺序读写带宽、数据传输延迟。 这三个指标如果任何一个低于GPU需求的50%，你就知道瓶颈在哪里了。 我去年用这个方法帮5个客户做过诊断，其中有4个发现了存储瓶颈，而不是GPU不够用。 方法二：AI智能调度 第二个方法是用AI智能调度存储数据。 这个方法是IBM最新的研究成果，他们把AI Agent直接塞进了存储系统，让存储系统自己学会优先调度热点数据。 具体做法是这样的，你在存储系统中部署AI Agent，它会自动分析哪些数据集被GPU频繁访问，然后把这些热点数据放到高速存储层，冷数据放到低速存储层。 这种智能调度可以让GPU的等待时间减少60%以上。 IBM自己的测试数据显示，使用AI智能调度后，GPU利用率可以从30%提升到70%，而存储投入只需要增加不到10%。 这个方法特别适合那种GPU投资已经很大、但利用率一直上不来的场景。 方法三：分层存储架构 第三个方法是做分层存储架构。 这个方法特别实用，你把数据分为热数据、温数据、冷数据三层。 热数据是GPU正在频繁访问的训练数据，放到NVMe SSD层；温数据是偶尔访问的验证数据，放到SATA SSD层；冷数据是历史归档数据，放到大容量HDD层。 这种三层架构可以让存储成本下降40%，同时GPU利用率提升20%以上。 我去年在一家AI公司落地过这个方案，他们原来全部用NVMe SSD，存储成本很高，后来做了分层架构，存储成本从800万降到500万，GPU利用率反而从45%提升到55%。 存储是GPU价值的放大器 如果你正在筹备AI项目，或者GPU利用率一直上不来，建议你先把存储系统查一遍。 存储投入可能只占IT预算的10%不到，但直接决定了90%的GPU投资能不能发挥价值。 就像那个客户，本来准备花500万买GPU，后来只花了50万升级存储，就搞定了问题。 这种投资决策，需要IT管理者跳出传统思维，不是GPU越多越好，而是要看整体ROI。 存储不是配角，是GPU价值的放大器。 你花1000万买GPU，如果存储跟不上，GPU利用率只能到30%，相当于700万被浪费了。 反过来，你只需要多投入10%在存储上，GPU利用率就能从30%提升到70%，相当于用100万撬动了700万的价值。 这个账，IT管理者一定要会算。 2026年AI推理会迎来大爆发，到时候GPU的需求会是现在的3-5倍。 如果你的存储系统现在就有瓶颈，到时候问题会被放大3-5倍。 不如现在就开始布局，把存储系统从配角变成价值放大器，让每一分GPU投资都发挥最大价值。 来源（公众号）：IT管理知识库

2025年年底，推荐性国家标准《数据管理能力成熟度评估模型》（GB/T 36073-2025，简称DCMM2.0）正式修订发布。DCMM 2.0在标准一级能力域由8个增加至9个，新增数据资产域。 国家市场监督管理总局和国家标准化管理委员会正式发布推荐性国家标准《数据管理能力成熟度评估模型》（GB/T 36073-2025），即DCMM 2.0，这一新版标准将于2026年7月1日正式实施，目前已进入“即将实施”阶段。新标准由全国信息技术标准化技术委员会（TC28）提出并归口，由中国电子信息行业联合会会同50多家行业协会、央国企、高校及科研机构共同起草。 新版标准着力构建一个以数据价值实现为核心的资产化、业务化、智能化、可信化新框架。 “资产化”旨在确立数据作为可交易要素的经济属性，为数据资源的市场化定价与流通奠定基础，呼应数据要素市场化配置的改革方向； “业务化”与“智能化”相结合，确保数据供给能精准、高效地支撑具体业务创新与人工智能应用； “可信化”则为数据跨组织、跨域的安全有序流通构建制度与技术并重的信任环境，从而系统推动数据从“管理对象”向“经营要素”转变。 DCMM 2.0在标准架构上实现显著拓展与前瞻布局。一级能力域由8个增加至9个，新增数据资产域。二级能力项由28个增至33个。 DCMM 2.0的核心价值在于为培育和建设全国统一的数据要素市场提供统一的能力标尺。通过评估模型，帮助广大企事业单位建立系统化的运营体系与方法论，成为组织构建数据治理新范式的核心操作指南与支撑体系。 DCMM 2.0 的发布不仅是标准版本的迭代升级，也承载着在数据要素市场化配置背景下，为企业构建统一数据管理能力参照体系的现实意义，体现出数据治理模式由内部管控向要素化、价值化方向演进的趋势。推动数据治理从传统管理向现代化要素运营演进，为“十五五”时期做强做优做大数字经济提供坚实支撑，标志着我国数据治理体系建设进入以激活要素价值为导向的全新阶段。 DCMM1.0 和DCMM2.0系统对比 DCMM2.0（GB/T 36073-2025）于2025年12月31日发布、2026年7月1日实施，核心是新增数据资产域、升级能力项与成熟度规则，适配数据要素市场化与合规要求，相比DCMM1.0更聚焦价值释放与安全可控。 以下是系统对比与核心内容梳理： 一、修订背景 二、能力域对比 1. 能力域架构升级 DCMM1.0：8个能力域、28个能力项、445条评估指标，覆盖数据战略、治理、架构、应用、安全、质量、标准、生命周期。 DCMM2.0：9个能力域、33个能力项，核心调整如下： 新增数据资产域含权属管理、价值评估、资产运营，支撑数据资产入表与价值释放。原“数据应用”调整为数据应用流通：新增外部数据管理，规范数据合作与引入合规。数据安全衔接《数据安全法》《个人信息保护法》，细化个人信息保护、跨境数据治理；数据质量新增非结构化数据标注与检索规则等。 2. 能力项关键变化 三、成熟度等级与评估规则调整 1. 等级划分优化 DCMM1.0：5级（初始级1→受管理级2→稳健级3→量化管理级4→优化级5），无甲乙双方差异化设定。 DCMM2.0：合并初始级（1级）至受管理级（2级），首次申报最低从2级起评。按甲方（需求/应用方）、乙方（服务/提供方）业务属性，差异化设定评估指标与要求。优化级（5级）门槛提升：新增持续创新、数据驱动业务变革等硬性要求，强调数据价值最大化与生态协同。 2. 评估指标与术语更新 指标体系适配新能力域，补充数据资产、流通合规等相关指标，强化可操作性。 更新“数据文化”“数据流水线”等18个关键术语，贴合当前数据管理实践。 四、核心价值与适用场景 DCMM1.0：以基础数据管理体系建设为核心，帮助企业搭建标准化制度与组织架构，规范全流程管理，适用于数字化转型初期的企业。 DCMM2.0： 突出数据资产价值。助力企业实现数据从成本中心到价值中心的转变，支撑数据资产入表与市场化交易。 强化合规与安全。全面满足数据安全与个人信息保护合规要求，降低合规风险。 适配新技术场景。支撑AI训练数据治理、隐私计算等新技术应用，推动数据驱动创新。 适用场景：数字化转型进阶期企业、数据要素流通活跃的行业（金融、互联网、制造等）、涉及跨境数据处理的企业。 五、企业应对建议 对照新能力域梳理现状。重点排查数据资产权属、价值评估、外部数据管理等短板。 升级数据管理制度。完善数据资产相关制度，修订数据安全、质量、流通等流程，适配新合规要求。 分阶段推进能力建设。优先夯实数据资产基础能力，再拓展数据应用流通与创新能力，结合自身业务属性（甲方/乙方）制定差异化提升路径。 提前准备评估。熟悉DCMM2.0评估规则，针对优化级新增要求，提前布局数据驱动业务变革与持续创新机制。 来源（公众号）：数据要素社

在数字化转型浪潮中，数据已成为组织最核心的资产。然而，传统数据治理模式往往陷入“大而全、长周期”的困境——耗时数月甚至数年梳理数据，最终却因业务需求变化或价值不明确而半途而废。如何打破这一困局？敏捷数据治理正成为破局的关键。 一、敏捷治理：以价值驱动的“小步快跑” 传统数据治理常以“建标准、理资产、治质量”为线性路径，导致治理与业务需求脱节。而敏捷治理的核心在于“价值优先、场景切入”，通过快速解决业务痛点证明价值，逐步积累治理资产。 核心策略： 聚焦高价值场景：直接对接业务需求（如组织机构数据不准、分析需求无法满足），以此为治理起点。 最小可行治理（MVG）：将庞大体系拆解为可独立交付的小模块，优先解决核心问题。 自动化工具赋能：利用元数据发现、数据血缘解析等工具替代手工盘点，提升效率。 轻量化协作：成立虚拟敏捷小组，以2-4周为周期冲刺，简化审批流程。 持续迭代优化：设定可衡量指标，定期回顾并调整优先级。 二、高校数据治理：从“痛点”到“速赢”的闭环 高校数据治理面临三大痛点：标准不一致、原始数据质量低、数据价值呈现不足。传统线性路径难以快速见效，而“以用促治、单点突破”的敏捷闭环则能在2-3个月内初见成效。 行动框架： 选定“速赢”场景：选择业务部门痛点深、领导关注度高的场景（如“人员身份治理”“教师一站式办事”）。 反向定义主数据与规则：围绕场景需求，锁定核心主数据（如“学生”“课程”），制定最小化标准和质量规则。 轻量级技术整合：建立临时数据视图，实施质量稽核与整改，快速开发场景应用。 沉淀资产并复制推广：将治理成果固化为资产，向全校展示并征集下一个痛点场景，形成治理飞轮。 三、学生关爱系统：敏捷治理的“小切口”实践 以学生关爱系统为例，敏捷治理可在4-6周内交付可见价值。核心思路是“反向驱动、精准治理”，通过解决“主动发现重点关注学生”的场景需求，快速打通数据。 敏捷步骤： 精准定义场景：与学工部、保卫部等部门确定痛点（如“识别多重风险学生”），转化为数据产品需求。 梳理最小数据需求：围绕“学业、经济、心理、社交”四类风险，列出必要数据清单，确认唯一主数据（学号）。 治理与整合并行：成立虚拟小组，轻量级对齐主数据，自动化探查并修复数据问题，构建“关爱数据专区”。 快速应用与反馈：开发预警看板，试点后收集反馈，形成持续优化闭环。 四、敏捷治理的关键要点 范围最小化：只治理场景必需的数据，不求全。 决策扁平化：虚拟小组拥有现场决策权，避免层层审批。 工具轻量化：优先利用现有工具和脚本，避免等待大型平台。 价值即时化：以“周”为单位交付成果，持续获得业务支持。 结语：让治理“于无形”中创造价值 敏捷数据治理的精髓在于“治理于无形”——通过快速解决业务痛点证明价值，逐步培养组织习惯，自然演化出完善的治理体系。高校数据治理应摒弃“四面出击”的传统思维，集中火力打造“治理飞轮”，让数据在业务场景中真正释放价值。 敏捷治理，让数据从“资产”变为“价值”，数据治理不再是一项“工程”，而是一种“能力”。通过敏捷方法，组织能快速响应业务需求，让数据治理真正服务于业务创新，实现从“被动治理”到“主动赋能”的转变。 来源（公众号）：数智转型洞察

有一个关于盲人摸象的古老故事。每个人都摸到了大象的不同部位，然后都确信自己了解了大象的全部。有人摸到了象鼻，说它像蛇；有人摸到了象腿，坚持说它像树；还有人摸到了象身，说它像墙。 企业级人工智能看起来很像那样。 问工程师公司应该如何使用人工智能，你可能会听到代理、编排、API、评估和应用架构等术语。问顾问，你可能会得到一份转型路线图。问领域专家，你可能会听到某个应该立即自动化的高价值工作流程。 这些观点本身并没有错，但它们都不全面。而且大多数观点都忽略了一点：真正每天从事实际工作的人，往往才是最先发现人工智能在哪些领域能发挥作用的人。 这一点很重要，因为企业在人工智能领域早期犯的最大错误是认为实现价值的途径是从训练或构建开始的。 通常的模式是这样的：首先，公司培训员工如何撰写简洁明了的内容以及如何安全使用人工智能。然后，公司筛选出一些有前景的工作流程，并委托开发定制应用程序来实现自动化。这两个步骤听起来都很合理，也都有帮助。但单独来看，它们都无法解决根本问题：有效的AI实践仍然分散、地域性强，难以复用。 结果不出所料。一个团队开发出一个巧妙的客户支持分诊提示。另一个团队创建了一个内部代理，帮助分析师准备周报。一位开发人员找到了一个强大的 MCP 集成方案，使代理能够访问内部文档、问题跟踪器和分析系统。还有人构建了一个 Claude Code 工作流，可以将缺陷单转化为实施计划草案。所有这些都很有价值。然而，在大多数企业中，它们仍然局限于个人笔记本电脑、Slack 讨论、笔记本或一次性演示中。 这就是企业人工智能的重大秘诀：企业并非仅仅通过培训员工使用人工智能或构建孤立的人工智能应用就能获得最快的回报。相反，当企业创建一个共享平台，让有用的提示、代理、技能、工具和支持多级协作平台（MCP）的功能能够被发现、改进、管理和复用时，才能获得更快的回报。 为什么独自训练效果不佳 想象一下，给每位员工的办公桌上都放上一款功能强大的AI工具，比如OpenClaw，然后说：“它几乎可以自动化所有事情。去用吧。” 这听起来很有启发性。但实际上，这往往会导致犹豫不决。 大多数人醒来时并没有一份清晰明了的“值得自动化的任务”清单。他们有工作要做，有截止日期要赶，还有几十个细小的决策需要做出。他们每天的精力往往分散在各种例外情况、判断、反复沟通和碎片化的系统中。他们或许能从人工智能中获益匪浅，但他们可能无法提前明确哪些工作应该通过提示、自动化、代理或应用程序来实现。 这就是为什么最初的热情过后，推广应用往往会停滞不前的原因之一。员工可能会尝试，但这些尝试并不会自动转化为组织共享的能力。 这与更广泛的市场数据相符。麦肯锡对人工智能现状的研究发现，各组织机构正在迅速提高人工智能的采用率，但只有极少数机构能够大规模地看到人工智能对企业盈利的实质性影响。德勤的报告也指出，尽管各组织机构热情高涨且投资巨大，但许多机构仍然难以从试点阶段过渡到规模化应用，从而创造价值。这种差距通常并非源于缺乏创意，而是缺乏可复制性、推广性和运营化。 培训能帮助人们跨越最初的障碍，但它本身并不能修建道路。 为什么“让我们开发一个应用”的范围太窄 当企业不再局限于培训时，他们通常会直接着手为特定用例构建定制软件。 这并没有错。有些流程确实需要专门的产品体验。例如，受监管的承保工作流程、临床审核流程或关键任务型开发平台，可能都需要一个功能完善、针对特定任务的应用程序，该应用程序应具备可审计性、基于角色的控制以及结构化的界面。 但这对于大多数机会来说，起点太高了。 企业人工智能价值的最初体现往往并非一个完整的应用程序，而是一个每天能节省 20 分钟的提示模板，或者是一个可复用的研究工作流程，又或者是一个能够从文档中提取上下文信息、总结工单、撰写回复、比较合同、生成初步 SQL 查询语句或准备代码审查清单的智能体。这些并非微不足道的成果，规模化应用后，其价值将成倍增长。 假设一家公司拥有 2000 名知识型员工。如果其中只有 25% 的员工每天通过可复用的 AI 技能和共享代理工作流程节省 20 分钟，那么一年下来就能节省超过 4 万小时。即使在流程重新设计之前，这也能带来显著的运营效益。而且，与单个定制应用程序不同，这些效益可以同时在多个团队中实现。 问题在于，大多数企业仍然缺乏获取、改进和推广这些成功经验的机制。 缺失的层面：共享的企业公共领域 企业需要的不仅仅是人工智能的使用权限，还需要用于共享的人工智能基础设施。 这意味着存在一个公共层，人们可以在该层上贡献代码并发现可重用的功能，例如： 能够可靠地执行有价值任务的提示 协调多步骤工作的代理 具备将可重复的方法或工作流程打包的技能 将人工智能与业务系统连接起来的工具 MCP 服务器可安全地向代理应用程序公开数据、系统和服务。 模板和评估模式使成功应用得以复现 团队认可的适用于 Claude Code、Codex 和其他代理工作空间等应用程序的最佳实践 这一层充当人工智能使用的组织记忆。 令人惊讶的是，我还没有遇到过哪个工程团队能够自主创建这种编码共享平台。 如果没有它，每个员工都将从零开始。有了它，一位员工的洞察力就能加速其他团队的工作。良好的内部提示将成为标准操作工具。实用的 MCP 集成将惠及全公司。高效的开发人员调试工具将成为每个工程团队可复用的功能。法务部门开发的合同汇总工作流程也将成为采购和销售运营部门值得信赖的工具。 这就是本地实验如何转化为企业优势的过程。 从个人发现到组织能力 企业人工智能最重要的转变不是从“人工操作”到“自动化”，而是从孤立的发现到共享的能力。 想想这在实践中会如何发展。 一位产品经理发现，结构化的提示加上文档检索工具，就能将杂乱的客户访谈记录整理成一份清晰的每周洞察简报。这本身对一个人来说就很有用。但如果将这一工作流程打包成一项可复用的技能，并编写文档、共享，同时将其发布到公司的AI工作区，那么其他几十位产品经理就能立即使用。随着时间的推移，还可以通过改进检索功能、优化架构和完善评估标准来进一步提升效率。 以软件工程为例。一位资深开发人员创建了一个 Claude Code 工作流，该工作流读取 GitHub 问题，检查相关代码库，识别可能需要修改的文件，制定计划并提出测试用例。这个工作流最初可能只是个人提高效率的小技巧。但一旦在内部共享，它就变成了一种可复用的工程能力。如果再添加一个 MCP 服务器，提供对代码库元数据、项目文档和 CI 信号的安全访问，那么这个工作流就会变得更加健壮，用途也更加广泛。 同样的逻辑也适用于整个企业： 在销售中，可重复使用的代理可以汇总客户信息、生成通话准备材料，并根据 CRM 环境起草后续跟进内容。 他们可以提供支持，对工单进行分类，识别重复出现的问题，并根据帮助中心的内容提出解决方案。 在财务方面，他们可以解释预算差异、撰写评论，并准备初稿董事会报告材料。 在法律领域，他们可以比较条款、识别风险并组织合同审查。 在操作中，它们可以将零散的标准操作程序转化为引导式执行流程。 共享资源使这些模式可见且易于移植。 为什么MCP比它们乍看起来更重要 模型上下文协议 (MCP) 服务器之所以重要，是因为真正有用的企业级人工智能很少仅仅关乎模型智能，它还关乎在正确的时间获取正确的上下文、工具和系统。 缺乏业务背景的模型虽然条理清晰，但却流于表面。而通过精心设计的管理控制点（MCP）连接的模型，则能真正发挥作用。 例如： 与从零开始的编码代理相比，连接到版本控制、问题跟踪和内部文档的编码代理可以提供更好的实现支持。 连接到产品文档、帐户历史记录和已知事件的支持代理可以生成更准确的回复。 连接到内部报告、分析和客户笔记的研究代理可以综合出原本需要数小时手动整理才能得出的见解。 因此，企业面临的挑战不仅仅是“我们应该使用哪种模型？”，而是“我们如何在整个组织内提供最佳功能（上下文、工具、提示和代理模式），使其可重用、可管理？” 领先者不仅可以使用前沿模型，还将拥有围绕这些模型构建的可重用功能的内部生态系统。 机遇背后的统计数据 越来越多的数据支持这一观点。 麦肯锡的报告指出，生成式人工智能每年可为全球经济创造数万亿美元的价值，其中大部分价值集中在客户运营、市场营销、软件工程和研发等知识密集型工作领域。与此同时，许多调查也显示出一个熟悉的模式：企业都在大力投资，但只有少数企业能够成功地将人工智能扩展到所有工作流程中。 IBM 的企业人工智能研究发现，领导者们认为数据复杂性、技能差距和工具碎片化等障碍是实现人工智能价值的主要阻碍。微软和 LinkedIn 的工作趋势指数也显示，员工已经开始将人工智能应用于工作中，其速度往往快于企业制定正式的使用规范。这是一个至关重要的信号：人工智能正在被广泛采用。问题在于，企业能否将分散的使用转化为共享优势。 基于共享资源的方法恰好弥补了这一缺口。它减少了重复工作，加快了新用户上手速度，总结了最佳实践，使治理能够应用于可重用的资产，而不仅仅是一次性的实验。此外，它还能帮助组织识别哪些新兴工作流程值得转化为产品。 更完善的企业人工智能成熟度模型 大多数公司实际上都遵循着如下的成熟度模型： 对人们进行人工智能基础知识培训。 先试运行几个试点项目。 开发一些自定义应用程序。 尝试按比例缩放。 更好的模型是： 让团队能够使用功能强大的AI工具。 为提示、代理、技能、工具和 MCP 创建一个共享的企业公共资源。 让员工贡献、发现、调整和改进可重用的工作流程。 观察哪些能力能够真正推动应用并创造可衡量的价值。 必要时，将最重要、经过验证的工作流程推广到专用应用程序或产品中。 为什么？因为它既降低了实验成本，又保留了标准化的优势。企业无需为每个有前景的应用场景都预先开发一个软件项目，而是可以在人们已经使用的环境（例如聊天工作区、编码代理、内部助手和桌面人工智能工具）中测试和改进各项功能。 只有当一个工作流程证明了它的价值、可重复性和市场需求后，才需要将其发展成为定制产品。 这种顺序至关重要。它既能防止企业过早过度建设，又能为规模化发展创造条件。 这在一家真实的公司里是什么样的呢？ 想象一下一个拥有 5000 名员工的企业，其团队涵盖工程、财务、销售、运营和法律等各个领域。 在传统的AI部署过程中： 提供培训 一些团队进行了试验 零星的成功出现 有些商业案例是为定制应用程序编写的。 大多数有用的发现仍然分散各处。 在基于公共资源的推广中： 每个团队都可以访问企业级人工智能工作空间。 员工可以发布有用的提示、代理和技能。 精选的 MCP 服务器连接已批准的系统和数据源。 团队负责人可以推荐或批准可重用的功能。 像 Claude Code 或 Codex 这样的应用程序中使用的工具可以共享，而无需重新构建。 高效的工作流程在各部门间获得可见性。 治理、版本控制、访问控制和评估均采用集中式管理。 产品团队可以确定哪些共享功能值得进行全面的应用投资。 区别在于，现在这家公司不再仅仅是“使用人工智能”，而是在构建机构级人工智能资本。 战略回报 这种模式的战略收益不仅仅体现在生产力方面。 共享企业资源创造了： 更快实现价值，因为实用功能无需等待完整的应用程序开发即可扩展。 实验的投资回报率更高，因为一个人的发现可以使数百人受益。 更好的治理，因为可重用资产可以进行审查、版本控制、权限管理和监控。 由于人们从成熟的工作流程入手，而不是从空白聊天框开始，因此采用率会更高。 更清晰的产品信号，因为使用最广泛、影响最大的功能自然会揭示哪些体验值得专门的软件投资。 换句话说，共享平台并非企业软件的替代品，而是检验企业软件优劣的试验场。在这里，企业可以学习哪些方法真正有效。 新的竞争优势 随着智能体应用变得越来越普遍，无论是在 Claude Code、Codex、内部副驾驶系统还是未来的 AI 工作空间中，竞争优势将越来越来自企业能够在这些环境中提供的功能。 它不仅仅是一个模型，也不仅仅是一个聊天界面，而是一个由共享提示、代理、技能、工具以及基于 MCP 的真实组织环境访问构成的鲜活生态系统。 那些能做到这一点的公司之所以能发展更快，并非因为它们将每个用例都开发成了应用程序，而是因为它们使有用的功能可以移植。它们会让组织从边缘发现价值，推广行之有效的方法，并将反复取得的成功转化为记录系统和执行系统。 这才是企业人工智能的真正行动指南。 培训人员，当然要。必要时，也一定要生产产品。 但首先，要建立公共资源。 因为实现企业人工智能价值的最快途径并非要求每位员工从零开始创造，也并非强行将每个想法都转化为软件项目。而是为企业提供一种共享的方式，用于捕获、推广和复用行之有效的方法。 这就是实验如何转化为基础设施的方式。这就是个人创造力如何转化为组织杠杆的方式。 这就是企业人工智能的最大秘密。