过去做一个数据需求，通常要经历一整套流程：理解需求 → 找表找字段 → 写 SQL 取数 → 清洗加工 → 建表 → 校验 → 上线。

真正耗时间的，往往不只是写 SQL，而是不断确认：指标怎么算、数据从哪里来、异常怎么处理、结果为什么对不上。

Agent 出现以后，这条链路正在发生变化。过去大模型更多是"帮你写一段 SQL"，现在 Agent 开始能够围绕一个任务连续完成理解需求、寻找数据、生成处理逻辑、调用工具、检查结果，甚至继续排查异常。这意味着，数据开发正在进入一个新的阶段：很多过去必须人工逐步完成的工作，开始具备被 Agent 接手的条件。

但真正值得讨论的，不是"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"，而是开始重新分配整个数据开发链路里，人的注意力到底应该放在哪里。