龙石数据质量管理平台社区版现已正式开放，快来体验吧。

龙石数据质量管理平台·社区（免费）版将于明日正式上线。欢迎关注产品动态，体验企业级数据质量管理能力。

AI 时代最贵的成本，不是模型采购费用。而是在错误数据基础上的反复试错。 做 AI 之前，先看一眼你的数据。花一两周做一次数据质量体检，可能会省下半年甚至一年的试错。这可能是整个 AI 项目中投入最小、回报最高的一步。

随着重点领域行业高质量数据集的逐步建成，以及“场景—数据—模型—应用”双向循环反馈机制的形成，我国有望建立起一条完备的数据安全供给链。通过全面落实《实施方案》中的各项技术与治理举措，人工智能治理得以在数据输入端筑起坚实的合规屏障，实现技术快速演进与治理体系协同共生的新局面。

AI+数仓不是噱头，它能落地，但需要选对场景、管好预期、打好基本功。别指望AI一步到位解决所有问题，也别因为AI有缺陷就否定它的价值。用对了地方，它就是提升效率的好工具。

龙石数据联合江苏省市场监督管理局数据中心、苏州大学共同申报的“高质量数据集智能底座”项目，顺利入选。

最近跟几个做数据治理的朋友聊天，大家的焦虑感出奇地一致：大模型在元数据标注、数据质量检测、血缘分析这些场景上越做越好，很多以前需要人工干的活，AI能自动干了。那数据团队以后还能干什么？ 这个问题问得好，也问得及时。2026年以来，AI+数据治理已经成为行业共识——IT之家、天极网等多家技术媒体近期发布的分析报告都指出，数据治理平台正在从"被动规则引擎"转向"主动智能协同中枢"。三维天地、数语科技等厂商也相继推出了AI驱动的治理产品。 但我想先把一个关键认知摆在这里：AI接管的不是数据团队的工作，而是数据团队工作中那些重复性高、标准化程度高的部分。剩下的部分——策略制定、复杂判断、跨部门协同、业务价值评估——恰恰是数据团队真正应该投入精力的地方。 一、AI在数据治理中到底能干什么？ 在讨论"数据团队该干什么"之前，先明确"AI能干什么"。目前来看，AI在数据治理中的价值主要集中在四个场景。 场景一，元数据智能管理。传统模式下，元数据的采集、标注、分类分级几乎全靠人工——逐张表、逐个字段地写注释、定义业务含义。大模型在自然语言理解上的能力，可以自动识别字段的业务语义、推断数据分类、推荐数据分级建议。人需要做的是审核和确认，而不是从零开始标注。 场景二，数据质量智能检测。传统数据质量治理依赖人工定义检核规则——空值检查、格式校验、一致性比对等。AI可以从历史数据中自动发现异常模式，推荐质量检核规则，甚至预测潜在的数据质量问题。比如AI发现某个字段的值分布突然发生偏移，可能是上游系统变更导致的，它会主动预警，而不是等问题被业务方投诉了才发现。 场景三，数据血缘自动追踪。传统血缘分析依赖人工维护或工具半自动采集，覆盖范围有限且容易断裂。AI可以通过分析SQL逻辑、ETL脚本、API调用链路，自动生成端到端的数据血缘图谱，并在数据变更时自动评估影响范围。 场景四，合规风险智能识别。随着《数据安全法》《个人信息保护法》的实施，数据合规成为治理重点。AI可以自动识别敏感数据字段（如身份证号、手机号等），匹配合规策略，并生成合规风险报告，帮助团队提前发现潜在的合规风险。 下面这张图展示了AI与人在数据治理中的协作关系。 从图1可以看出，AI和人各有分工、相互配合。AI负责执行和辅助，人负责决策和审核。这个关系定义清楚了，后面的事情就好 二、AI治理的能力边界在哪？ 谈AI赋能，不能只说好处不说局限。AI在数据治理中能做到什么程度，我画了一张成熟度模型来界定。 如图所示，我把它分成了四个层级。需要客观说明的是： L1（人工规则驱动）是目前不少企业所处的阶段。治理工作高度依赖人工，效率低但可控。这个阶段不丢人，关键是要有向L2升级的意识。 L2（AI辅助治理）是当前可行的目标。AI负责生成初稿（规则、标注、报告），人负责审核确认。这个阶段投入产出比相对较高，也是目前头部厂商产品主推的方向。 L3（AI深度参与）需要较强的数据基础。要让AI主动检测异常、推荐治理策略，前提是元数据完善、数据质量基线清晰、治理流程标准化。如果这些基础没打好，AI的能力也无法充分发挥。 L4（自治治理）目前更多是愿景。完全由AI自主处理治理任务、人只在关键节点把关——这个目标在技术上还有不少挑战需要克服，短期内不建议作为企业的主要目标。 务实建议：大多数企业应该把目标定在L2到L3之间——让AI承担执行层面的重复工作，让人聚焦于策略和判断。不要被厂商的营销话术带着跑，以为买了个AI治理平台就能直接跳到L4。 三、数据团队的角色怎么变？ AI接管的越多，数据团队就越需要重新定义自己的价值。我用一张图来说明这个转变。 如图所示，数据团队的角色正在从"治理执行者"转向"数据资产运营者"。具体来说，有四个变化。 3.1 从 写规则 到 审规则 以前数据团队的大量精力花在编写和维护数据质量规则上——一张表几十个字段，每个字段可能需要好几条检核规则，几百张表下来就是海量的规则维护工作。AI介入后，这部分工作可以大幅缩减。AI根据数据特征和历史模式推荐规则，数据团队的重点变成审核这些规则是否合理、是否覆盖了业务关注的质量维度。 3.2 从 做治理 到 建体系 AI能帮你发现数据质量问题，但"发现之后怎么办"需要人来设计：这个质量问题由谁负责？修复优先级怎么排？跨部门的数据口径冲突怎么协调？这些是治理体系建设的问题，AI替代不了。数据团队需要把更多精力放在治理组织架构、流程机制、考核标准的建设上。 3.3 从 对内支撑 到 对业务赋能 传统数据治理大多是"对内"的——给技术团队用、给数据团队用，业务方的感知很弱。AI介入后，数据团队可以从重复性工作中释放出精力，去思考一个更关键的问题：治理的成果怎么转化为业务价值？比如，数据质量提升之后，报表的准确率提高了多少？决策效率改善了多少？这些量化评估能让业务方看到治理的实际价值，从而更愿意配合治理工作。 3.4 从 被动响应 到 主动运营 以前数据治理的模式是"出了问题再处理"——业务投诉数据不准，再去排查修复。AI的主动检测能力让"事前预防"成为可能。数据团队可以基于AI的预警信息，提前介入处理潜在的数据风险，把治理从被动响应转变为主动预防与持续优化。 四、落地过程中容易踩的坑 基于行业观察和实践经验，总结几个常见的坑。 坑一，跳过基础建设直接上AI。有些团队元数据管理还没做起来、数据标准还没建立、质量基线都没量，就急着引入AI治理工具。结果AI生成的建议质量很差——因为连AI都不知道哪些字段是什么含义。数据基础是AI治理的前提，这个顺序不能颠倒。 坑二，把AI治理当成纯技术项目。数据治理本质上是一个管理问题。AI能提升治理的执行效率，但"数据标准由谁制定""质量不达标的责任怎么界定""跨部门数据冲突由谁协调"这些管理层面的问题，AI解决不了。必须有配套的治理组织、流程和机制。 坑三，期望AI完全自动化。目前阶段，AI在数据治理中更适合"辅助"定位。让AI自动执行所有治理任务、完全不需要人工介入——这个目标在当前技术条件下不现实。尤其在涉及敏感数据分级、合规判断等场景，人工审核环节不能省。 坑四，忽视AI自身的治理风险。网易的一篇文章提到，当AI Agent从"能对话"演进到"能执行"时，其引发的数据治理与安全风险较传统AI显著提升。比如AI在执行数据治理任务时可能误操作敏感数据，或者AI生成的治理规则本身存在偏见。因此，对AI的治理行为本身也需要建立监控和约束机制。 五、几个关键的优化建议 最后，给几个实操层面的优化建议。 建议一，分场景逐步引入AI，不要贪多。建议从元数据管理和数据质量检测这两个场景切入——这两个场景标准化程度高、效果容易衡量、投入产出比相对明确。验证成功后再逐步扩展到血缘分析、合规识别等场景。 建议二，建立"AI生成+人工审核"的标准流程。无论哪个场景，都应该设计明确的人机协作流程：AI生成治理建议→人工审核确认→执行→记录反馈→优化AI模型。这个闭环是AI治理效果持续提升的关键。 建议三，量化治理效果，让价值可见。AI介入前后，数据质量问题的发现效率提升了多少？元数据标注的人工投入降低了多少？数据治理报告的出具周期缩短了多少？这些量化指标不仅能评估AI治理的实际效果，也能帮助数据团队向管理层和业务方展示治理工作的价值。 建议四，关注AI治理平台的安全与合规。引入AI治理工具时，要确认其对敏感数据的处理方式——数据是否会上传到云端？是否支持私有化部署？对AI的治理行为是否有审计日志？《数据安全法》和《个人信息保护法》对数据处理有明确要求，AI治理工具也必须满足这些合规要求。 六、写在最后 回到开头的问题：当AI介入数据治理，数据团队该干什么？ 答案其实很清楚：AI接管的是"执行"，数据团队应该聚焦于"策略、协同和价值"。制定治理策略、审核AI的建议、推动跨部门协同、量化治理的业务价值——这些才是数据团队在新阶段的核心工作。 换个角度看，AI不是在抢数据团队的饭碗，而是在帮数据团队从繁琐的执行工作中解放出来，去做更有价值的事。关键在于你能不能抓住这个转变的窗口期，主动调整自己的定位和能力结构。 来源（公众号）：华哥聊数据

一、为什么突然都在聊AI+数仓？ 过去两年，大模型的风刮到了数据基础设施领域。从Text-to-SQL到AI辅助建模，从自动化ETL到智能数据治理，各大厂商和开源社区陆续推出一系列工具，试图用大模型改造传统数仓的工作方式。 这个方向的内在逻辑不难理解。传统数仓建设有几大痛点：建模周期长、数据清洗依赖人工规则、ETL链路出问题需要运维半夜爬起来定位。每个环节都存在大量重复性劳动，而这些恰好是大模型擅长的事情——理解自然语言、生成代码、识别模式规律。 但一个有意思的现象是：同样一套技术方案，有的公司用得比较顺畅，建模效率明显提升，数据质量问题大幅减少；有的公司投入了不少资源，折腾了大半年，最后得出的结论是"大模型没啥用"。相似的底层技术，结果差别很大。 这背后的原因在哪？结合我这几年的一线观察，我总结了四个层面的关键分水岭。 二、跑得通的公司，做对了什么？ 1. 先把数据底子打扫干净 这是最基础、也最容易被忽视的一点。跑得通的公司，在引入AI之前，已经完成了数据标准化的基础工作——字段命名规范统一、数据字典完整、指标口径明确、元数据管理到位。大模型进来之后，有标准的元数据做上下文，不需要去"猜"某个字段的业务含义。 反过来，跑不通的公司往往是"数据裸奔"状态。同一个客户ID，CRM系统里叫customer_id，订单系统里叫user_no，日志系统里叫uid。大模型面对这种混乱的局面，别说生成准确的SQL，连理解都费劲。很多项目一上来就希望大模型"端到端"解决问题，结果数据质量不过关，大模型输出的东西也是错的，团队信心一下就被打没了。 一个判断标准：如果你现有的数仓连基本的指标口径都没有对齐，先别急着上AI。把标准定了，把字典建了，再谈大模型赋能。 2. 选对了切入点，从小场景开始跑 从我了解到的情况来看，跑得通的公司通常遵循"小切口、速赢"的策略。很多不会一上来就搞一个"企业级AI平台"，而是先挑一个高频、痛点明确、价值可量化的场景。 比如： Text-to-SQL查询：让业务人员用自然语言查数，减少数据开发写SQL的重复需求 数据质量自动稽核：用大模型识别异常数据，补充人工校验规则的不足 元数据自动补充：根据表结构和业务上下文，自动生成字段描述和业务定义 这些场景的共同点是：边界清晰、见效快、业务方感知强。一旦跑通一个场景，团队信心建立，后续推进其他场景就容易得多。而一上来就想"用AI重构整个数仓体系"的公司，项目周期拖得太长，业务方耐心耗光，往往无疾而终。 3. 懂得"什么该交给AI，什么不该" 这是很多技术团队容易忽略的问题。大模型不是万能的，也不是所有任务都适合交给它。从我观察到的做法来看，跑得通的公司普遍建立了一套分层分工机制： 任务类型 处理方式 典型场景 简单、规则明确的 传统脚本/SQL 基础数据校验 固定报表查询 复杂、需要语义理解的 大模型处理 模糊查询转SQL、异常归因分析 高频且对延迟敏感的 轻量级模型或规则引擎 实时数据质量拦截 低频且对准确度要求高的 大模型+人工审核 复杂建模、数据口径映射 核心原则是：大模型只做"需要理解能力"的事情，不碰"可以用规则解决"的事情。这样做既能控制调用成本，又能保证效率和准确率的平衡。 三、跑不通的公司，踩了哪些坑？ 坑一，数据没清干净就上AI 最典型的场景是：企业把全量业务数据直接丢给大模型，期望它自动完成清洗和治理。结果大模型面对各种不一致的字段、缺失的关联关系、混乱的编码体系，输出的数据质量大打折扣。 举个常见的例子：供应商名称这个字段，在不同业务系统里可能写成完全不同的格式——全称、简称、中英文混写、带标点不带标点。如果不在入库前做标准化映射，大模型花再多精力去"理解"这些变体，效果也不如先把数据洗干净再喂给模型。这背后是一个基本的顺序问题：AI不能替代数据治理，但它能加速已经标准化的数据治理流程。顺序反了，结果就是事倍功半。 坑二，一上来就搞"全场景覆盖" 这个问题在传统IT项目中就常见，到了AI时代被放大了。从我的经验来看，AI项目的不确定性比传统项目更高，因为你无法预判大模型在某个具体场景下的表现。场景越多，不确定性叠加，项目失败的几率也随之上升。 常见的情况是：公司成立AI+数据专项组，目标同时覆盖销售、运营、供应链、客服多个场景，预算和周期定得很高。结果几个月过去了，连第一个场景还没跑通——每个场景都需要不同的数据准备、不同的Prompt调优、不同的评估标准。资源有限却全面铺开，很容易每个场景都做不透。 一个务实的建议：如果团队还在探索阶段，先集中资源打穿一个场景，验证了价值再横向复制。 坑三，技术部门单干，业务部门不参与 大模型需要"学"业务知识。如果业务部门不参与需求定义、不提供高质量的业务语料、不参与结果评估，大模型生成的SQL和模型很可能跟实际业务需求对不上。 举个例子，"计算客户流失率"这个需求，不同部门的理解可能完全不同。销售部门认为"三个月未下单"就算流失，运营部门认为"六个月未登录"才算，财务部门可能按"账户余额为零"来定义。口径差异，大模型自己是"悟"不出来的。 坑四，忽视成本与效率的平衡 大模型的API调用成本因模型和厂商而异，按token计费的模式下，高频调用会产生一定的开销。如果所有数据操作都走大模型，月结时的费用可能会比较可观。 比如，日常的GMV查询、转化率报表这类高频查询，用大模型走一遍自然语言转SQL，延迟可能比直接跑一条预计算的SQL慢不少，调用成本也更高。把任务分层——高频、确定性高的走规则引擎或预计算，低频、模糊的走大模型——可能是更合理的做法。 四、优化方向，怎么从"跑不通"变成"跑得通"？ 方向一，从高频痛点场景切入，快速验证 如果你的公司还在探索阶段，可以考虑从这些场景入手： 数据质量稽核：大模型识别异常数据的能力在一些场景下已经具备实用价值，落地门槛相对较低 元数据自动补全：基于表结构和字段名生成业务含义描述，能较快提升数据字典的覆盖率 自然语言查询（Text-to-SQL）：适用于报表需求频繁、数据开发资源紧张的团队 ETL脚本辅助生成：适合数据量大、重复性ETL任务多的场景 每个场景建议先做小范围POC验证，确认价值后再投入资源做生产化。 方向二，建立闭环验证机制 大模型输出结果建议配合人工确认机制： 项目初期：人工复核比例适当提高，重点关注大模型输出是否符合预期 稳定期：复核比例逐步降低，同时建立自动化监控基线 成熟期：通过bad case反向驱动模型和Prompt的持续优化 每次发现大模型输出有误，记录下来分析原因——是Prompt写得不够精准？是数据本身有问题？还是场景超出了模型的能力边界？这些积累会成为后续优化的重要基础。 方向三，数据安全底线不能破 数仓里存储着大量业务数据和用户信息，直接送到公有云大模型接口存在合规风险。在实际落地中，建议做到： 敏感字段（手机号、身份证、邮箱等）在输入大模型前进行脱敏处理 所有API调用留存审计日志 明确数据使用边界，不超出业务需要的范围 有条件的企业可优先考虑私有化部署方案 五、未来展望，AI+数仓会走向哪里？ 从过去两年的行业实践来看，AI+数仓的发展有几个方向已经逐渐清晰： 第一，AI辅助能力会逐步融入数仓工具链。就像OLAP引擎成为数仓标配一样，AI辅助建模、智能数据质量稽核、自动化运维诊断等能力，在未来几年可能会成为数据平台的基础功能。企业需要思考的不是"要不要用"，而是"用在哪些环节最合适"。 第二，不同规模的模型会协同工作。大模型擅长复杂推理和语义理解，在需要"理解"的场景下优势明显。而小模型或规则引擎在处理高频、确定性任务时，在成本和响应速度上更具优势。两者配合使用，可能是更务实的方案。 第三，数据治理的重要性不会降低，反而会提升。AI越强，对数据质量的要求越高。一条不准确的数据口径，经过大模型处理后，可能产出一份看起来逻辑严谨但结论错误的报告。数据治理不是可以被AI替代的工作，而是需要和AI同步加强的基础工程。 第四，人机协同是现阶段较为可行的模式。短期内"AI替代数仓工程师"不太现实。更务实的路径是：AI处理重复性、规则清晰的常规任务，人工负责复杂决策、异常处理和效果兜底。从我接触到的案例来看，这个分工模式在成本、效率和质量三个维度上综合表现不错。 最后说句实在话：AI+数仓这件事没有捷径。先把数据管好，选对场景，边界划清楚，再让AI进来干活。按这个顺序走，大概率能跑通。反过来，跳过前两步直接上AI，十有八九要交学费。 来源（公众号）：华哥聊数据

做数据这行的朋友，大概都熟悉这个流程：业务抛过来一个取数需求，你得先搞清楚人家说的"活跃用户"到底是哪个口径，然后翻表结构写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能力的引入才会水到渠成。 来源（公众号）：华哥聊数据

龙石数据中台 V3.9.0版本围绕数据资产门户改版、国产化数据库适配两大核心方向迭代优化：一方面完成数据资产门户全页面 UI 视觉升级；另一方面针对主流国产化数据库，落地数据评测、对账校验、运维监控、API 资产共享全链路适配改造。