设计一个数据开发Agent：写SQL、排查失败、修数据质量
本文目录
30秒版回答
我会按“价值高、风险低”的顺序分三期做：
一期，只读诊断：任务失败自动拉日志、匹配已知错误、查上游和资源，给出根因和建议；数据质量告警自动做影响分析，顺着血缘找出受影响的下游表和报表。这一期不碰任何写操作，风险最低，但能显著减少夜间值班的排查时间。
二期，辅助生成：根据需求和元数据生成 SQL 初稿、补全表注释、生成数据质量规则、做 SQL 方言转换。产出物全部走代码评审和测试，不直接上线。
三期，受控执行：重跑任务、补数这类操作由 Agent 生成方案，人确认后由调度系统执行。删除、覆盖核心表这类操作始终不交给 Agent。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
面试官：「假设我们要做一个面向数据开发团队的 Agent，帮大家写 SQL、排查任务失败、处理数据质量告警。你会怎么设计？哪些能力先做，哪些不做？」
这道题和智能问数不同：智能问数面向业务，数据开发 Agent 面向工程师，它要接触的是代码、调度、日志、元数据和生产环境，风险更高，但提效空间也更大。
面试官想看你有没有产品判断力：不是把所有能力都堆上去，而是知道哪些场景价值高、风险低、适合先做，哪些场景必须保留人工。同时也要看你对数据开发日常工作的理解够不够深。
面试官在考什么
• 能否拆解数据开发的工作流，找出最适合 Agent 化的环节。
• 是否有优先级和风险意识：先做只读诊断，再做辅助生成，最后才考虑自动修复。
• 能否设计出工具体系和上下文来源：代码仓库、元数据、血缘、调度、日志。
• 是否有质量保障：生成的代码怎么验证，修复动作怎么防误操作。
展开一：工作流拆解与优先级
| 场景 | 价值 | 风险 | 建议阶段 | 关键依赖 |
|---|---|---|---|---|
| 任务失败诊断 | 高（夜间值班） | 低（只读） | 一期 | 日志、调度状态、错误知识库 |
| 质量告警影响分析 | 高 | 低（只读） | 一期 | 血缘、下游报表清单 |
| SQL 初稿生成 | 中高 | 中（需评审） | 二期 | 元数据、语义层、代码规范 |
| 表/字段注释补全 | 中 | 低 | 二期 | 样例数据、上下游 SQL |
| SQL 方言迁移 | 高（迁移项目） | 中（需双跑对数） | 二期 | 方言规则、测试数据 |
| 重跑/补数 | 中 | 中高 | 三期（人确认） | 调度 API、幂等设计 |
| 删除/覆盖核心数据 | 低 | 极高 | 不做 | — |
展开二：工具体系和上下文
数据开发 Agent 的能力上限由它能拿到的上下文决定。我会给它接这几类工具，全部以只读为默认：
# 数据开发 Agent 的工具清单（按意图设计，而不是按后端接口）
tools = [
tool("diagnose_task", "输入任务ID，返回最近运行状态、错误日志摘要、上游状态、资源使用"),
tool("search_error_kb", "按错误信息检索历史故障案例和处理方法"),
tool("get_table_meta", "表结构、粒度、分区、负责人、最近更新时间、数据量趋势"),
tool("get_lineage", "上下游血缘，支持指定深度；返回受影响的报表和负责人"),
tool("read_code", "读取任务对应的 SQL/脚本（只读）"),
tool("run_readonly_sql","在隔离队列执行只读 SQL，用于验证数据，强制分区和行数限制"),
tool("propose_action", "生成重跑/补数方案，提交审批，不直接执行"),
]注意最后一个工具叫 propose_action 而不是 rerun_task——Agent 只能“提议”，不能“执行”。这个命名本身就体现了权限设计。
展开三：任务失败诊断怎么做到又快又准
这是一期最核心的能力。结合第 01 题讲的混合架构，我会这样设计：
• 错误知识库优先：把历史故障的错误特征、根因、处理方法沉淀成知识库。OOM、分区未就绪、文件不存在、权限不足、上游延迟这类高频问题，规则匹配就能解决。
• 日志预处理：日志动辄几万行，先用规则提取异常栈、关键报错行、最后几十行，再交给模型。不要把整个日志塞进上下文。
• 多源交叉验证：同时看调度状态、上游任务、集群资源、最近代码变更，模型基于多源证据推理。
• 输出结构化报告：根因、证据、建议操作、置信度、相关历史案例链接。
【任务失败诊断报告】dws_trade_order_d 2026-10-10 03:12
根因（置信度：高）：上游 dwd_order_detail_d 分区 dt=2026-10-09 未就绪
证据：
1. 错误日志：Path does not exist: .../dt=2026-10-09
2. 上游任务状态：运行中，已比历史平均耗时多 47 分钟
3. 上游输入量较近 7 日均值上涨明显，疑似源端补数
建议：等待上游完成后重跑；如需提前，请联系上游负责人 @xxx
相关历史案例：#1023（同类问题，2026-08-15）
[一键提交重跑申请]（需负责人确认）展开四：SQL 生成与方言迁移——必须有验证闭环
生成 SQL 不难，难的是证明它是对的。我在某出海硬件品牌做过 EMR 到 Databricks 的全链路迁移，100 多个 Spark 作业分批迁移，其中大约 20% 的 SQL 因为方言差异需要微调，最后用双写双读灰度的方式零故障完成。
当时这些方言修改都是人工做的。放到今天，这类工作非常适合交给 Agent 做初稿，但验证方法不能变：新旧两边对同一批数据双跑，逐表对比行数、主键唯一性、关键指标汇总值、抽样明细，全部一致才能切换。
-- Agent 生成的 SQL 必须通过双跑对数才能合并（示意）
WITH old AS (SELECT dt, COUNT(*) cnt, COUNT(DISTINCT order_id) uk,
SUM(pay_amount) amt FROM legacy.dws_trade_order_d
WHERE dt BETWEEN '2026-10-01' AND '2026-10-07' GROUP BY dt),
new AS (SELECT dt, COUNT(*) cnt, COUNT(DISTINCT order_id) uk,
SUM(pay_amount) amt FROM migrated.dws_trade_order_d
WHERE dt BETWEEN '2026-10-01' AND '2026-10-07' GROUP BY dt)
SELECT o.dt, o.cnt, n.cnt, o.uk, n.uk, o.amt, n.amt,
CASE WHEN o.cnt = n.cnt AND o.uk = n.uk
AND ABS(o.amt - n.amt) < 0.01 THEN 'PASS' ELSE 'FAIL' END AS result
FROM old o FULL JOIN new n ON o.dt = n.dt; -- FULL JOIN 防止某天整天缺失这段对数 SQL 的思路是：Agent 可以写代码，但验收标准由人定、由确定性的程序执行。生成和验证分离，是 AI 辅助开发最重要的原则（第 17 题会展开）。
展开五：一个真实事故给的启示
我在某元宇宙社交应用时遇到过一次事故：有同事用 client 模式提交生产 Spark 作业，然后合上笔记本下班，Driver 跟着挂了；还有一次 client 模式的 Driver 把跳板机内存吃满，导致其他人都登录不上去。
这类问题恰好是数据开发 Agent 的好场景——代码评审和提交前检查。把“生产作业必须 cluster 模式”“必须设置合理的 executor 内存”“禁止 SELECT *”这类团队规范交给 Agent 在提交前检查，比靠人记住所有规范靠谱得多。规范检查是只读的、风险低、价值高，非常适合一期就做。
追问链
追问一：错误知识库怎么建立和维护？
冷启动时从历史值班记录、故障复盘文档、工单里抽取“错误特征 → 根因 → 处理方法”三元组。上线后形成闭环：每次 Agent 诊断完，值班同学确认根因是否正确，正确的案例自动入库，错误的案例标记后人工修正。时间长了，知识库会覆盖绝大多数高频故障，Agent 的诊断越来越快。
追问二：Agent 诊断错了，误导了值班同学怎么办？
三个措施：一是输出证据而不只是结论，值班同学能快速判断推理是否靠谱；二是给出置信度，低置信度时明确提示“建议人工排查”；三是诊断报告只是建议，不自动执行任何操作。另外要统计诊断准确率，按错误类型看哪类问题 Agent 判断得不好，针对性补充知识库和工具。
追问三：怎么衡量这个 Agent 的价值？
按场景分别度量。诊断：平均故障定位时间、诊断准确率、值班同学的采纳率。SQL 生成：初稿采纳率、评审中发现的问题数、开发周期变化。规范检查：拦截的违规提交数。最后一定要算投入产出：模型调用成本和维护成本，对比节省的人力时间。
加分说法 vs 减分说法
| ✔ 加分说法 | ✘ 减分说法 |
|---|---|
| 按价值高、风险低排优先级，分期上线 | 一上来就做全自动修复 |
| 一期只读诊断，写操作只提议不执行 | 让 Agent 直接拿调度系统的写权限 |
| 错误知识库 + 日志预处理 + 多源证据 | 把完整日志塞给模型 |
| 生成和验证分离，双跑对数做验收 | 生成的 SQL 看起来对就上线 |
| 规范检查是低风险高价值场景 | 说不清怎么衡量价值 |
怎么挂到你的项目上
话术模板：“我之前做过 EMR 到 Databricks 的迁移，100 多个作业里约 20% 的 SQL 因方言差异要改，当时靠双写双读和逐表对数保证零故障。如果今天做数据开发 Agent，我会让它负责方言转换的初稿，但验收仍然用双跑对数这套确定性流程。整体上我会分三期：只读诊断、辅助生成、受控执行，写操作永远需要人确认。”
总结
数据开发 Agent 的设计重点是分期和边界：先做只读诊断，再做辅助生成，最后做人确认的受控执行。每个能力都要有验证闭环，生成和验证分离。把你做过的迁移、值班、规范治理经历带进来，这道题会非常有说服力。
下一篇是一道带数字约束的系统设计题：500 万文档、300 QPS 的企业知识库 Agent，数据链路怎么设计？
如果有一个数据开发 Agent，你最想让它先帮你做什么？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长