Agent 把 SQL 写对了，业务为什么还是不敢用？
——从“能问数”到“可信取数”，DataAgent 要翻过的那座山
周一早会，某头部调味品集团的经营分析室里，高管对着大屏问了一句：“上个月最后一周，蚝油品类的收入为什么掉了？”
Agent 三秒钟返回了一张趋势图和一段归因分析。看起来很美。但散会后数据负责人复核发现：用的“收入”是出货口径，高管心里想的是零售动销口径；区域按发货仓切分，业务惯例却是经销商属地；那周恰有大促订单在途，新鲜度还差两天。图是对的，SQL 是通的，结论是偏的。
这不是段子，而是我们在交付现场反复遇到的第一现场。它揭示了行业集体面对的落差：模型写 SQL 的能力已足够惊艳，但企业把 Agent 放进经营流程的勇气，还远远不够。
一、榜单很强，进生产还是不够
先看两组公开数据。
BIRD-SQL 是业界公认最接近真实数据库的 Text-to-SQL 基准：12,751 个问题-SQL 对、95 个大库、跨 37 个行业域。人类专家的执行准确率是 92.96%，而榜单第一的综合方案只有 81.95%，裸模型普遍落在 60 到 75 分区间。另一侧，被 ICLR 2025 接收为 Oral 的 Spider 2.0 更贴近企业现实：632 个真实工作流、SQL 横跨两大方言、动辄上百行，DBT 赛道最好成绩仅 65.6 分。
换句话说，在最接近企业场景的考卷上，最先进的模型距离“人类稳定水平”还有十到三十个百分点的差距。而生产环境对问数的要求不是“平均能对”，是“高频问题稳定接近 95%，剩下的错误能解释、能追溯、能修复”。
企业从“能问数”走向“可信取数”，中间隔着一座山。山脚是“能返回结果”，往上依次是口径正确、权限可控、数据新鲜、可解释可追溯——峰顶才叫“敢上线”。
二、用户问的是业务问题，系统执行的是数据任务
很多人把 DataAgent 理解为“更强的 NL2SQL”，这是第一处误判。
NL2SQL 解决语法转换，ChatBI 解决问数入口，而 DataAgent 要处理的是数据任务闭环：意图识别、语义映射、资产发现、权限校验、查询执行、解释与回归——SQL 生成只是其中一步。把上面那句“蚝油收入为什么掉了”拆开，它同时牵连六个待裁决项：收入口径、区域维度归属、时间窗口、大促与测试渠道是否过滤、当前提问者的权限边界、数据新鲜度。任何一项默认错了，后面每一步都在放大错误。
这条风险链是递增的：取错数 → 错指标 → 错归因 → 错策略 → 信任崩塌。一次越权展示、一次过期数据、一次口径打架，消耗的都是业务方对系统的信任。对分析型 Agent 而言，取数不是全部能力，却是生产化的第一道门槛。（见图 1）
图 1 风险递增链：一次取错数，如何逐级演变为信任崩塌
三、行业的答案：不是更大的模型，而是可治理的上下文
有意思的是，全球头部玩家给出的解法高度收敛。Snowflake 推 Agent Context Layer 与 Semantic Views，Databricks 用 Genie 加 Unity Catalog 的本体约束，OpenAI 与 Anthropic 分别在强调 data context 与 verification，开源侧有 OSI 开放语义交换规范、dbt Semantic Layer 与 MetricFlow。剥掉产品话术，抽象出来是三层：
最上层是 Agent 上下文层——表、字段、文档、历史 Query、使用记录；中间是受治理的语义层——指标、维度、实体、关系，以及经过审核的定义与版本；底层是评测与回归 harness——工具调用策略、golden SQL、Badcase 与回归集。（见图 2）
图 2 行业三层上下文抽象：Agent 上下文层 / 受治理语义层 / 评测与回归 harness
这三层上下文，主体都不是人写出来的，而是机器抽出来的——原料就是元数据。上下文层里的表、字段与历史 Query 本身就是活跃元数据；语义层里一个指标敢不敢被 Agent 引用，靠 owner、血缘、新鲜度这些元数据信号打分；harness 里该测哪些用例，也靠血缘与漂移监测指路。上下文层的成熟度，取决于元数据的自动化程度。
自动化路径有三步。第一步解析：扫描器读遍各类数据源与 ETL 工具里的 SQL、存储过程与遗留调度脚本，把“哪个字段被哪段逻辑加工、写进了哪张表”变成机器可读的字段级血缘——这是上下文的骨架。第二步感知：采集访问热度、更新频率、任务成败等操作元数据，回答“表还活着吗、指标还有人信吗”。第三步校验：影响、溯源与对比分析把血缘从静态图变成执行前关卡——SQL 跑之前，先说清指标出自哪一层、经过哪些字段、上游变更波及谁、是否按时到位。我们在交付中把这三步交给元数据产品览众数据图谱承担——行业里叫元数据控制面。（见图 3）
图 3 元数据控制面：执行上下文如何被组织成 Agent 可调用的一层
三步走完，元数据的消费方式发生三个转变：消费者从人变成 Agent——不再翻目录页面，而是通过 API 与 MCP 读取结构化信号；时机从事后查变成执行前注入——权限、新鲜度、血缘校验嵌进执行路径，不通过即拦截；形态从文档变成可计算字段——信任分、新鲜度、权限级别成为规划器能比较、能引用的参数。三个转变完成，“给机器用的执行前上下文”才从口号变成事实。
而企业真正的缺口在于：这些上下文散落在 Catalog、BI、指标平台、权限系统、文档和历史 SQL 里，从未被组织成 Agent 可在执行前调用的一层。元数据不再是“给人看的数据目录”，它要变成“给机器用的执行前上下文”。
四、六轮收敛：一个零售集团的实战复盘
我们在某头部零售品集团的“AI 战情室”项目里，把这座山爬了六轮。该企业数据栈的典型特征是多源并存：内部出货（ERP）、零售动销（终端 POS）、线上销售（京东、天猫、直播..)、外部市场监测，SKU 与渠道主数据在各源中编码不一，历史报表口径数十套。
第一轮，我们把 Schema、历史 SQL、文档、BI 报表全接进去，答案依然不稳。于是先停下补工具的冲动，做失败分型：选错表、算错口径、越权、数据过期、无法复盘——五类失败，五条治理路径。
第二轮解决“同一业务对象十几张表，Agent 凭什么选”。答案不是人工白名单，而是把“可信”拆成可计算的元数据信号：owner 是否有人负责、生产或废弃状态、血缘是否可追溯、新鲜度、权限与敏感级别、真实使用热度、质量画像。这些信号不靠人工登记：览众数据图谱的 AI 驱动扫描器自动解析 60 余种数据源与 ETL 工具中的 SQL、存储过程与遗留脚本，生成 99% 精准度的字段级血缘，再叠加访问热度等操作元数据，让每张表的“信任分”持续更新。白名单会过期，信号才会随数据一起呼吸。
第三轮解决业务黑话：“有效销售额”“大盘转化”“老客复购”在系统里没有同名字段。文档库能召回解释，但不能裁决生产口径——它的正确用途是把业务语言映射到受治理的语义对象：指标、维度、实体。
第四轮解决“同一个指标，每次问出来都不一样”。我们的做法是 verified metric 优先：口径版本化、绑定 owner、经审核发布、写回统一目录，Agent 命中即复用；未命中时由 AI 生成候选口径，进入编译校验、冲突检测与人工审核，通过后才能晋升为 verified metric。生产指标不应该在运行时被反复临时解释。
第五轮解决“SQL 有结果，但业务不能直接用”。语义对象经编译生成 SQL 后、执行之前，插入四道校验：权限、新鲜度、血缘、审计。血缘校验由览众数据图谱的全链路字段级血缘支撑：从指标层逐层穿透至汇总、明细与源系统，影响面在执行前自动评估。先校验，再执行——把治理做进执行路径，而不是做在事后报告里。
第六轮解决“今天修好、明天又错”。按 case 改 Prompt 是饮鸩止渴；真正让系统变稳的，是把每个错误绑定到 query、metric、table、owner、version，沉淀进 Badcase 库，并对 Schema 漂移、策略漂移、业务漂移、新鲜度漂移建立回归闭环。
六轮下来，交付物不是更聪明的 Demo，而是一条链路：主数据映射字典（覆盖率 ≥98% 方可冻结）、双方会签的指标字典 v1.0、在其上升级的语义层、以及以 MCP 工具接口向 Agent 开放的 discover / describe / validate / audit 四项能力。这套能力轴心，后来被完整沉淀进公司数据智能产品 Metaflow 的产品骨架。（见图 4）
图 4 六轮收敛：从失败分型到漂移回归，逐轮收窄自由度
链路通不通，最终要看业务方敢不敢点。如今在这家企业的战情室大屏上，出货、动销、份额带源标签同屏呈现，品类可下钻至 SKU 与渠道热力；高管点任意数字，侧栏展开它的指标定义、版本、来源表、过滤条件与血缘路径——问数过程透明化之后，“敢不敢用”才第一次有了肯定答案。
五、最小可信闭环：先跑通一个业务域
常有客户问第一条可信取数链路怎么搭。我们的经验是克制：一个业务域、一个核心 Catalog、5 到 10 个 verified metrics、10 到 20 个真实问题；必须验证权限拦截、指标冲突、新鲜度、语义漂移、Badcase 回归；验收不是“答得多”，而是五种能力：能回答、能解释、能拦截、能追溯、能修复。
比技术更难的是组织：指标口径、数据资产、权限策略、Badcase 修复各有 Owner，发布要过评审，每次变更都进入 review、release、regression、audit 流水线。生产化的难点从来不只是模型，而是责任链是否闭环。
想跑得更快，可以把这套动作压缩进一次 4 到 6 周共创：第一周现状诊断与 Badcase 基线；第二周梳理可信资产与候选指标；第三周接入 Agent、语义层与元数据控制面；第四周权限、新鲜度与回归验证；最后两周生产化评审与扩展规划。六周结束，拿到的不是一份 POC 报告，而是一条能被审计、能被回归、能被扩展的取数链路。
这也是 Metaflow 的设计原点：元数据侧由览众数据图谱以全链路字段级血缘与主动元数据承担控制面角色，语义侧以 verified metric 与受治理语义层统一口径，再加执行前校验与回归闭环做成产品化能力，让 Agent 的每一次取数都站在可审计的地基上——用了哪个指标、哪个版本、哪张表、什么过滤条件、什么权限、血缘在哪里，全部透明可查。
结语：信任是一条链路，不是一个模型
回到开头那个问题。“蚝油收入为什么掉了”值不值得一个三秒钟的回答？值得，但前提是这三秒背后站着口径、权限、血缘与回归测试。
模型能力的曲线还在上扬，而信任的工程才刚刚开始。榜单会刷新，benchmark 会被刷穿，但企业里那张“敢不敢把 Agent 放进经营例会”的选票，只投给能把错误解释清楚、追溯到底、修复闭环的系统。
从元数据到 DataAgent，这条路没有捷径。但好消息是：山就在那里，路径已经有人踩出来了——一次一个业务域，一次一个 verified metric，一次一个回归用例。
取对数，才配谈智能。
