你问数据 Agent：“今天该暂停哪些广告？”它很快写出 SQL——查询数据库的语言——算出每个广告活动的投入产出比，再给出一份停投名单。数字算得没错，建议却可能错了：有的平台转化数据还没到齐，有的收入尚未扣除取消订单，还有的数据按另一个时区结算。
这正是 Shafeeq Ur Rahaman 在 Towards Data Science 署名文章中提出的问题：数据仓库能被 Agent 查询，不等于能被 Agent 正确理解。数据仓库（Data Warehouse）是企业集中保存和整理业务数据、供分析查询的系统。过去，分析师通常会在查询结果与业务行动之间做一次人工判断；Agent 开始自动选数据源、写 SQL、解释结果，甚至调用工具修改营销活动后，这道检查关口变弱了。
本文全部具体论断来自这一篇署名文章。作者没有提供对照实验、准确率或其他量化证据，广告案例也是依据个人经历整理的组合场景，而非一宗可核验的真实事故。
表能查，不代表意思写清了
一个现代数据仓库可以把数据集中起来，监控处理管道，配置访问权限，并为表格添加说明。这些工作解决的是“能不能找到、能不能读取”，却没有完整回答“这个数字应该怎样用”。
例如，数据库结构可以告诉 Agent，“campaign cost”是一个数值字段，却未必说明它是否包含代理费用、不同币种是否已经统一、退款是否已经扣除。表刚刚更新，也不代表最新的转化数据已经完整进入。
作者还以 BigQuery data agents 为例称，当前系统处理查询时会依赖选定的知识来源、元数据和针对具体用途的指令，而不只看表名。不过文章没有附上 Google 官方文档印证这一实现细节，因此更适合把它视为作者的描述，而非经多方确认的产品结论。
更深的问题是，企业对指标的定义常常散落在不同地方：一部分藏在数据转换逻辑中，一部分写在仪表盘公式里，还有一些只存在于文档或分析师的经验中。人可以凭上下文补齐这些规则，软件却只能根据拿到的信息自行判断。
SQL 正确，决策仍可能错误
作者用一个广告分析的组合场景说明这种错位。公司汇总多个平台的广告花费、点击、转化和归因收入，要求 Agent 找出今天应该暂停的活动，以保护 ROAS——广告支出回报率，也就是每投入一单位广告费带来多少收入。
Agent 按名称挑选了看似相关的原始表，生成有效 SQL，正确计算并排列指标。但这些表背后的时间和口径并不一致：某个平台的转化尚未加载完成；另一个平台的收入还没扣除取消订单；第三个平台采用不同的报表时区。公司日常使用的仪表盘处理了这些差异，Agent 却绕过了它。
这不是文章证明了“所有传统仓库都会犯错”，而是一个机制性提醒：计算过程可以完全正确，输入的适用范围和业务含义却可能不适合当前决定。
缺的不是更多表注释
作者主张加入语义层（Semantic Layer）——把底层表和字段翻译成统一业务概念与计算口径的一层。比如，它不仅保存“收入”字段，还明确哪个来源权威、退款怎样处理、必须使用哪些筛选条件，以及哪些表之间可以组合。
传统治理主要回答“谁有权读取”。Agent 还需要回答：“这份数据是否适合支撑这类决定？”表格新鲜度也不够。广告花费可能几分钟内到齐，转化却要几小时后才可靠。数据可信度元数据——描述新鲜度、质量检查、负责人和适用范围的“关于数据的数据”——因此也要进入判断过程。
数据沿袭（Data Lineage）同样重要。它记录一个指标来自哪些源表、经过哪些转换，像数据的家谱。这样，Agent 看到的不只是最终数字，还能判断数字从哪里来、规则变化会影响什么。
从数据合同走向“决策合同”
文章把缺少的架构层称为 decision contract，即“决策合同”。普通数据合同规定数据生产方必须交付什么；决策合同则规定，自动化系统可以怎样把数据用于某一类决定。
以广告预算建议为例，它可以写明获准使用的数据源、最低历史时间范围、指标定义、数据最多可以多旧、哪些完整性检查必须通过、允许哪些过滤条件，以及 Agent 只能提出建议，还是可以直接执行。它还可以要求统一媒体成本、使用归因后的净收入，并排除归因窗口尚未关闭的平台。规则采用机器可读格式并保留版本，团队便能随数据模型和政策一起审查变更。
这层设计值得关注，因为它把“懂业务”从分析师脑中的默契，变成软件可以检查的基础设施。仓库接上 Agent 后，竞争点不再只是让模型更会写 SQL，而是让它知道哪些数字可信、采用什么口径，以及行动边界在哪里。
局限与未知
- “Agent-Ready”和“决策合同”目前是作者提出的概念框架。文章未给出统一定义、量化门槛或对照实验。
- 文中没有披露具体模型、评测数据和准确率，也未证明加入这层设施后能把错误建议降低多少。
- 供稿原文在解释错误来源处截断，不能据此扩展作者对“幻觉”等问题的完整结论。