过去做一个数据需求通常要经历一整套流程理解需求 → 找表找字段 → 写SQL取数 → 清洗加工 → 建表 → 校验 → 上线。真正耗时间的往往不只是写SQL而是不断确认指标怎么算、数据从哪里来、异常怎么处理、结果为什么对不上。Agent出现以后这条链路正在发生变化。过去大模型更多是“帮你写一段SQL”现在Agent开始能够围绕一个任务连续完成理解需求、寻找数据、生成处理逻辑、调用工具、检查结果甚至继续排查异常。这意味着数据开发正在进入一个新的阶段很多过去必须人工逐步完成的工作开始具备被Agent接手的条件。在正式展开之前我整理了一套《“AI”场景落地实战白皮书》如果正在做数据集成、数据开发或者关注AI进入数据工作后的应用方式可以结合文章一起参考。需要自取https://s.fanruan.com/hti40复制到浏览器但真正值得讨论的不是“Agent会不会做数据开发”而是取数、清洗、建表、校验到底哪些工作已经可以交出去哪些只能半自动哪些现阶段仍然不能放权判断标准其实只有四个任务是否确定、结果能否验证、错误影响有多大、执行权限有多高。一、取数Agent已经能做很多真正难的是“允许它查到哪里”取数可能是目前最容易Agent化的一类数开工作。业务提出一句查一下华东区最近三个月销售额下降最多的20个客户。过去数据开发要自己完成找订单表、找客户表、确认组织关系、判断关联字段、理解销售额口径、写SQL、执行查询。如果Agent能够访问元数据、数据字典和查询工具这套过程已经可以变成理解问题 → 搜索表和字段 → 判断关联关系 → 生成SQL → 执行 → 检查结果。所以像这些工作已经非常适合先交给Agent根据业务问题寻找相关表根据字段说明定位指标来源自动生成SELECT、JOIN和GROUP BY根据数据库报错修改SQL解释复杂SQL对明显低效的查询给出优化建议。但企业真正应该担心的并不是Agent“会不会写SQL”。而是这条SQL到底能不能执行。假设Agent拿着生产库高权限账号业务人员一句“分析一下今年所有客户”可能直接触发几十亿行扫描一个错误的多对多JOIN也可能让查询结果迅速膨胀。更麻烦的是权限。业务人员有权看华东区数据不代表Agent就应该拥有全国数据权限。所以企业里的Agent取数合理链路应该是自然语言 → 身份与权限判断 → 已治理的数据范围 → 受控SQL → 执行 → 结果校验。这也是为什么Agent越往企业生产环境走越需要已有的数据集成和数仓体系。如果ERP、CRM、MES等系统的数据已经通过FineDataLink按照固定频率同步到数仓或分析库Agent就没必要为了回答一个临时问题再逐个连接业务系统。日常的数据源连接、增量同步、任务调度继续留在固定的数据开发链路中Agent面对的是已经准备好的分析数据负责判断这次应该查哪些表、怎样组织SQL。这样两类职责就能分开Agent解决“一次问题怎么取数”FineDataLink解决“数据长期怎么稳定到达”。这也是Agent真正进入企业数据环境的前提之一。二、清洗Agent擅长把规则写出来但不能替企业决定什么叫“正确”清洗同样很适合Agent参与。一张客户表里可能同时存在“浙江”“浙江省”“ZJ”三种省份写法日期格式不统一手机号包含空格和特殊字符金额字段混入字符串同一身份证号对应多个客户ID某个字段空值率突然从1%升到20%。面对这类问题Agent可以快速完成数据剖析再生成对应的SQL或者Python逻辑。例如格式标准化、类型转换、字符串处理、空值检测、基础去重、异常值识别、规则代码生成。这类工作的共同特点是规则一旦明确代码本身并不难。真正困难的是规则从哪里来。订单金额为负到底是错误还是退货、库存数量小于0是数据质量问题还是企业业务允许负库存一个客户有三个手机号到底应该保留最新的、最常用的还是全部保留同一统一社会信用代码对应两个客户名称能不能直接合并这些问题并不存在一个“AI凭常识就能得出的正确答案”。它们依赖的是企业自己的主数据规则、业务流程、历史口径和责任机制。因此清洗工作的Agent化应该分成两层。第一层由人确定哪些情况属于错误哪些只是异常出现冲突以后以谁为准。第二层再由Agent把这些定义转换成可执行的数据处理逻辑并辅助检查处理结果。所以Agent真正擅长的并不是“把一堆脏数据自动洗干净”。而是把已经明确的数据标准快速翻译成SQL、Python或者ETL规则。这也是为什么企业数据标准越混乱Agent反而越难真正发挥作用。三、建表DDL已经不是难点真正难的是“为什么要这样建”如果只是告诉Agent建一张客户月度销售汇总表包含月份、客户ID、收入、销量、订单数和毛利。它生成字段名、字段类型、注释、DDL和基础加工SQL已经没有太高门槛。但这并不意味着“数据建模也可以全部交给Agent”。因为真正的数据建模首先要回答一行数据到底代表什么是客户月份客户产品月份还是客户区域产品月份粒度不同后面的指标计算、数据量、查询性能和使用方式都会不同。继续往下还会遇到更多问题客户从华东调到华南以后历史订单算哪个区域订单今天完成明天退款汇总表如何更新客户属性发生变化要不要保留历史版本每天新增数百万订单是全量重算还是增量更新同一个销售额指标出现在不同主题表里口径怎样保持一致所以必须区分两件事Agent会建表不等于Agent会做数据建模。现阶段更合理的做法是让Agent读取已有模型、字段规范、数据字典和需求文档先生成模型草案 → 字段设计 → DDL → 加工SQL → 测试SQL。数据开发人员重点审核粒度、主键、历史策略、增量方式、模型关系和指标口径。审核通过以后再把确定的数据加工链路落到FineDataLink里长期运行。这里FineDataLink承接的已经不是“一次SQL查询”而是数据同步、转换、任务依赖、调度周期、失败重跑等生产链路。Agent可以帮助开发人员更快生成和修改逻辑但生产环境不能每次运行之前都让Agent重新理解一遍“今天这个任务应该怎么跑。”因此Agent解决“这次怎么开发”数据开发平台解决“以后每天怎么稳定执行”。这条边界非常重要。四、校验可能是比自动写SQL更值得优先Agent化的工作很多人讨论数据Agent第一反应是让它自动写SQL。但从实际的数据开发流程来看校验反而可能是更值得优先Agent化的一类工作。因为大量数据校验具有两个特点规则相对明确而且结果容易验证。例如一张销售汇总表上线以前至少可以检查四个层次。结构校验检查字段是否缺失数据类型是否变化主键是否重复必填字段是否为空上游字段是否发生Schema变更。数量校验昨天源表新增100万条目标表为什么只有82万条某张表平时每天新增5000条今天突然只有300条问题出在哪里数量的异常波动往往是数据链路出错最早出现的信号。业务逻辑校验例如发货时间不能早于下单时间折扣率应该位于合理范围已完成订单金额原则上不能为0订单客户ID必须能关联到客户主数据订单状态之间必须符合业务流转顺序。结果对账这是很多团队最容易忽略的一层。源系统当天销售额1.26亿元数仓为什么只有1.21亿元以前遇到这种问题开发人员往往需要自己一层层写SQL排查。Agent则可以围绕差异继续拆哪个区域开始出现差异 → 哪个产品出现差异 → 哪类订单状态异常 → 哪张上游表数据量变化 → 哪个同步任务开始异常。这样一来校验不再只是“告诉你数据错了。”而会逐渐变成“告诉你可能从哪里开始错。”真正进入生产以后可以把已经确认的质量规则放进FineDataLink的任务链路中固定执行Agent则参与另外两件事情一是根据字段结构、历史分布和已有异常记录补充新的检查建议二是在固定规则触发报警以后继续读取上下游任务、SQL和运行信息辅助定位问题原因。这样才能形成一套更稳定的分工固定规则负责发现确定性问题Agent负责处理不确定性排查。否则每天都让Agent凭经验判断“今天的数据看起来有没有异常。”这种方式很难成为真正的数据质量体系。五、能不能交给Agent核心不是“它会不会”而是“做错以后怎么办”所以判断一项数开工作能不能交给Agent不能只看模型有多聪明。更实用的方式是看四件事结果能不能自动验证、异常能不能及时发现、执行能不能被阻断、失败能不能快速回滚。按照这个标准目前的数据开发工作大致可以分成三层。第一层已经可以大量交给Agent包括找表找字段、生成查询SQL、基础格式处理、字段映射、测试SQL、DDL草稿、校验SQL、日志解释、报错分析。它们的共同特点是任务相对明确、结果容易检查、失败影响有限。这一类工作未来很可能越来越少需要开发人员从零开始做。第二层Agent先做人来审核包括复杂清洗规则、指标加工逻辑、数仓模型设计、增量策略、历史数据回刷方案、复杂性能优化。Agent完全可以给出第一版方案甚至把大部分代码写出来。但真正困难的是这类问题往往不存在唯一答案。例如一张亿级大表采用每日全量、按日期增量、CDC还是按业务状态回刷都可能实现需求。最终选择哪个方案需要综合考虑数据规模、延迟要求、数据库压力、开发成本和后续维护成本。这已经不是“会不会写代码”而是架构取舍。第三层Agent只能提供建议不应该直接放权包括删除生产表、修改核心指标口径、调整数据权限、大规模历史重算、覆盖生产数据、修改核心任务依赖。原因并不是Agent绝对做不了。而是这类操作一旦错误影响范围可能已经超过自动校验能够兜住的程度。所以企业真正需要建设的不是一个“什么都能做、什么权限都有”的数据Agent。而应该是一套Agent负责理解和生成规则负责约束数据平台负责执行权限体系负责控制人保留高风险操作的最终决策权。结语Agent进入数据开发以后真正发生变化的并不是有没有数据开发人员。而是数据开发人员每天应该把时间花在哪里。过去大量时间消耗在找字段、写重复SQL、修改格式、建临时表、写校验脚本、分析报错日志。这些重复度高、规则明确、容易验证的工作会越来越多地交给Agent。人的工作则会继续向上移动定义业务口径、制定数据标准、设计数据模型、规划数据架构、管理数据权限、控制生产风险。所以判断一项数开工作能不能交给Agent可以记住一个非常实用的原则越确定、越重复、越容易验证越适合交给Agent越涉及业务定义、架构取舍和高风险生产操作越需要人保留最终控制权。未来的数据开发大概率不会变成“Agent把所有工作自己做完。”而会形成另一种协作方式人定义目标和边界Agent承担大量具体开发动作数据平台负责稳定执行人只在真正需要判断的地方介入。当这套分工真正跑起来以后Agent带来的价值就不只是“少写几行SQL”。而是开始重新分配整个数据开发链路里人的注意力到底应该放在哪里。