夜雨聆风前两天跟一个做数据平台的朋友聊天，他们团队正在搞 Data Agent。我问做什么方向的，他说自然语言查数，让业务方用中文问问题，Agent 生成 SQL 返回结果。
我说挺好，然后呢？
他说，就这一个方向，先做好再说。
我当时没接话。但心里想的是，自然语言查数只是 Data Agent 的一种形态，甚至不是最有价值的那种。数据工程师的日常工作场景里，至少能抽出五种完全不同的 Agent 原型。它们共享同一套底层能力，但解决的问题、推理逻辑、产出形态完全不一样。
只盯着「查数」这一个方向做，就像你开了一家餐厅，厨房里所有设备都齐了，但菜单上只有一道菜。
我自己过去几个月一直在做 Data Agent。最开始也是从一个具体场景切入的，需求审查。做着做着我发现，很多能力是通用的，schema 解析、血缘追踪、ETL 代码理解。这些能力组合起来，能覆盖的场景远比我最初想的多。
所以我花了一些时间把数据开发的日常场景全部梳理了一遍，看看哪些场景能被 Agent 化。最后发现至少有五种形态清晰的原型。
我把它们一个一个聊聊。
这是我目前做得最深的一个。输入是一份需求文档加上现有的 ETL 实现，输出是它们之间的差异清单——哪些需求已经实现了、哪些没做、哪些做错了。
核心动作：「逆向」+「对比」。 Agent 需要先逆向理解已有的 ETL 代码到底在干什么，然后拿这个理解去对照需求文档，找出不一致的地方。
你可能觉得这事人也能干，为什么要 Agent？因为一个经验丰富的数据开发可能管着几十张表、几百条 ETL pipeline。每次需求变更的时候，人工 review 的覆盖率其实很低。你只会看你觉得可能受影响的那几条，其他的靠经验判断「应该没事」。但「应该没事」这四个字在数据领域是要命的。
Agent 不会偷懒。它会把所有相关的 pipeline 都过一遍。
适用场景：新需求上线前的 review、历史 ETL 的口径确认、数据治理时的批量合规检查。
原型二：新建开发型
输入一份需求文档，输出表结构设计加 ETL 代码。这是最直觉的「AI 写代码」场景，没有已有实现需要逆向，不需要做差异诊断。核心动作：「理解需求」+「生成代码」。
坦率地讲，这个方向是大家最容易想到的，也是最容易低估难度的。
难在哪？你让 Agent 从零写一段 ETL，它写出来的东西可能语法正确、逻辑也能跑通。但它不知道你们公司的命名规范，不知道你们的分层策略是 ODS-DWD-DWS 还是别的结构，不知道你们对 NULL 的处理约定，不知道某个业务指标在你们团队的口径定义。
这些东西全藏在历史实现里。 Agent 必须「知道公司怎么做事」才能写出合规的 ETL。所以新建开发型 Agent 对知识库的依赖最重，你得把规范、历史案例、口径定义全部灌进去。
我自己的判断是，这个原型在短期内最适合做「初稿生成」，人来做二审和调优。完全自主的端到端生成，对大部分团队来说还早了点。
原型三：血缘影响分析型
某张表要改字段类型了，或者某条 pipeline 要下线了。影响面多大？哪些下游会受影响？需要通知谁？
核心动作：「追踪血缘」+「评估传播」。 Agent 沿着血缘 DAG 往下游走，看每一层的依赖关系，判断变更是否会导致下游 break。
看起来最简单对吧？不需要逆向代码，不需要理解业务逻辑，只是在图上走。
但它对工具层的要求反而最高。你需要一张完整的、实时的血缘图。很多公司的血缘信息是残缺的，只覆盖了核心链路。你还需要 schema 变更兼容性判断的能力，比如 STRING 改 INT 在哪些场景会 break、哪些不会。
我见过一些团队想做这个方向，卡在血缘图不全上。Agent 再聪明，看不到完整的图就没法判断。所以这个原型的前置条件是你的数据基础设施得到位。
原型四：数据排查型
数据对不上了。某个报表的数字跟昨天差了 30%，老板问你怎么回事。你得从结果倒推原因。
核心动作：「逆向」+「假设验证」。 Agent 沿着血缘往上追，逐层看 ETL 逻辑和中间表数据，定位「在哪一步出了问题」。
它跟需求审查型有什么区别？审查型的基准是需求文档，「实现跟需求一致吗」。排查型的基准是数据应有的状态，「数据为什么不对」。
排查型可能需要 run_query 的能力，去中间表实际查数来验证假设。比如 Agent 怀疑是某一步的 JOIN 条件有问题，它需要跑一条 SQL 看看那步的中间结果是不是真的有异常。
这个原型在实际工作中的价值非常高。 每个数据团队都经历过那种「数据对不上，所有人停下来排查」的时刻。一个能自动沿着血缘排查的 Agent，哪怕只是把排查范围缩小到某几步，都能省大量时间。
原型五：口径答疑型
有人问你，「这个指标怎么算的」「这张表的 XX 字段啥意思」「GMV 口径包不包含退款」。
你回答这类问题的方式是什么？去看 ETL 代码，追一下血缘，找到源头的计算逻辑，然后翻译成人话告诉对方。
核心动作：「阅读」+「解释」。 最轻量，但使用频率最高。
我跟几个数据团队的人聊过，他们日常工作里有 20-30% 的时间花在回答各种口径问题上。产品经理问、运营问、分析师问、新入职的同事问。每次都是打开代码看一遍然后用人话解释。
这个场景太适合 Agent 了。它不需要做复杂的推理，只需要准确地读代码、追血缘、给出可追溯的解释。
我觉得这可能是 Data Agent 里 ROI 最高的一个方向。 实现难度相对低，使用频率高，效果立竿见影。
五种原型的共性：一套底座撑起全部
你可能注意到一件事，这五种原型虽然解决的问题完全不同，但依赖的底层能力高度重叠：
• schema 解析——五种都需要 • 血缘追踪——五种都需要 • ETL 代码理解——五种都需要 • 防幻觉机制（证据驱动、引用校验）——五种都需要
这就是我想说的核心观点。
你不需要做五个 Agent。你需要做的是一套扎实的工具底座，加上一套可靠的防幻觉框架，然后在上面搭五种不同的编排骨架。
get_schemaget_lineage、get_etl_code、run_query | |||
一旦底座和框架做好了，新增一种编排骨架其实很快。反过来说，如果底座没做好，每种原型都得从头造轮子。这就是为什么很多团队做 Data Agent 进展缓慢——不是编排难，是底座不够扎实。
回到开头那个问题
他们只做自然语言查数。其实查数这个场景连我列的五种都不在里面，因为查数更偏 BI 方向，不是数据工程的核心场景。
我不是说查数不重要。但如果你是数据工程团队，最痛的点可能不是「业务方不会写 SQL」，而是：
• 需求变更时 review 不全导致线上出问题 • 数据异常排查太慢 • 口径答疑占了太多时间
这些场景的 Agent 化，对数据工程师自己的效率提升是最直接的。
我目前的优先级
• 需求审查型——做得最深，已在跑真实 case • 口径答疑型——正在搭建，实现成本低、见效快 • 排查型 & 血缘分析型——规划中，等工具底座再完善 • 新建开发型——暂时放最后，知识库积累还不够
五种原型不需要同时做。但你得知道它们的存在，这样在搭底座的时候才能做出正确的抽象。如果你一开始就只为「查数」设计工具层，后面要做审查或排查的时候，大概率得推倒重来。
一套工具底座，一套防幻觉机制，五种编排骨架。覆盖数据工程师 80% 的日常。
这就是我理解的 Data Agent 的全貌。不是一个单点工具，是一个体系。
