企业官网建设流程全解析

过去做一个数据需求，通常要经历一整套流程：

理解需求 → 找表找字段 → 写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”。

而是开始重新分配整个数据开发链路里，人的注意力到底应该放在哪里。