你们的数仓要给Agent用，你会先改哪三件事？

-- 数据状态表：Agent 查询前先读取，判断数据是否可用
CREATE TABLE meta_table_health (
  table_name        STRING,
  latest_partition  STRING,     -- 最新就绪分区
  expected_ready_at TIMESTAMP,  -- 按 SLA 应该就绪的时间
  is_delayed        TINYINT,    -- 是否延迟
  dq_status         STRING,     -- PASS / WARN / FAIL
  dq_message        STRING,     -- 如：订单量较近7日均值下降明显，排查中
  known_issue       STRING,     -- 已知问题说明，如：10-08 支付渠道数据缺失待补
  updated_at        TIMESTAMP
);

# 工具层：查询前检查数据状态，把状态信息一起返回给 Agent
def query_metric(metric, time_range, user_ctx):
    tables = semantic_layer.tables_of(metric)
    health = [meta.health(t) for t in tables]
    result = semantic_layer.run(metric, time_range, user_ctx)
    warnings = [h.dq_message or h.known_issue for h in health
                if h.is_delayed or h.dq_status != "PASS" or h.known_issue]
    return {"data": result, "freshness": [h.latest_partition for h in health],
            "warnings": warnings}       # Agent 必须在回答中转述 warnings

这样，当数据有延迟或质量问题时，Agent 的回答会是：“上周 GMV 为 xxx。注意：10 月 8 日的支付渠道数据存在缺失，正在补数，该日数据可能偏低。”这比给出一个错误的数字要负责得多。

衡量标准：核心表的新鲜度和质量状态覆盖率；Agent 回答中正确提示数据问题的比例。

第三件事：统一访问入口和权限（让数据用得安全）

如果没有统一入口，每个团队做 Agent 时都会自己写一套连数据库的代码，权限、校验、审计各不相同，有的甚至直接用高权限账号。这就像没有数据服务层时，每个应用都直连数据库一样混乱。

• 统一入口：提供标准化的数据访问服务（MCP Server 或数据 API），所有 Agent 通过它访问数仓。

• 统一控制：在入口实现身份透传、只读校验、分区强制、成本预估、资源隔离、审计日志（第 08 题的五层防御）。

• 统一复用：语义层、数据状态检查都通过这个入口提供，Agent 开发团队不需要重复造轮子。

衡量标准：通过统一入口访问的 Agent 占比；越权和超大查询的拦截数；审计日志覆盖率。

为什么没有选其他事情

面试官很可能追问“为什么不先做 XX”。提前准备好几个“暂缓”的理由，体现你的取舍是经过思考的：

暂缓的事情	为什么暂缓
全面重构数仓模型	成本太高、周期太长；先在现有模型上补元数据和语义层，见效更快
建设向量化的数据目录	有用，但前提是元数据本身完整；元数据质量差时，向量检索只会更快地找到错的表
实时化所有数据	大部分问数场景 T+1 足够；按场景需求推进，而不是一刀切
自研数据 Agent 框架	先把数据底座做好，Agent 框架可以用现成的；数据团队的核心价值在数据侧

实战经验：这些事和 Agent 出现之前就该做的治理是一回事

回顾我做过的工作：在某出海硬件品牌做的埋点治理，本质上是第一件事（让数据看得懂）；在某短剧出海公司做的 SQL 代码质量治理，本质上是在提升数据的可信度。这些事情在没有 Agent 的时候就应该做，只是那时候有人兜底，做得不够好也勉强能运转。

Agent 的出现把数据治理从“锦上添花”变成了“必要条件”。这是我对这道题最核心的观点，面试时可以作为收尾的一句话。

追问链

追问一：这三件事需要业务方配合吗？怎么推动？

需要。口径定义需要业务方确认，元数据补齐需要各表负责人参与。我的推动方法是：先选一个业务方痛点最强的场景（比如某个部门的取数需求最多）做试点，用试点的效果（取数响应时间缩短、口径争议减少）说服其他团队。同时把元数据补齐纳入数据开发规范，新表上线必须填写，存量表按使用热度分批补。

追问二：如果只能做一件事，你选哪件？

选第一件：元数据和语义层。因为它的影响面最广——不仅 Agent 受益，人查数也受益；而且它是其他两件事的基础：质量状态要挂在认证表上，统一入口要依赖语义层提供标准查询。如果数据看不懂，后面两件事做得再好，Agent 也会用错数据。

追问三：怎么证明这三件事做完了，Agent 的效果真的变好了？

用评测集做前后对比（第 11 题）：在同一批问题上，统计改造前后的正确率，并按错误类型拆解——“选错表”“口径错误”这两类应该明显减少，对应第一件事；“基于问题数据回答”应该减少，对应第二件事；越权和超大查询应该被拦截，对应第三件事。每件事都有对应的指标，效果可以量化。

加分说法 vs 减分说法

✔ 加分说法	✘ 减分说法
明确三件事：看得懂、信得过、用得安全	罗列十件事，没有优先级
站在 Agent 的视角分析失败模式	都很重要，都要做
每件事有做法和衡量标准	先重构整个数仓
能说出暂缓其他事情的理由	直接上向量数据库
数据治理从锦上添花变成必要条件	没有衡量标准

怎么挂到你的项目上

话术模板：“我会先做三件事：让数据看得懂、信得过、用得安全。看得懂是元数据和语义层，因为 Agent 不会问同事；信得过是把质量和新鲜度状态暴露给 Agent，让它在数据有问题时主动提示；用得安全是统一访问入口和权限。我之前做埋点治理和 SQL 质量治理时就有一个体会：这些事情本来就该做，Agent 的出现让它们从锦上添花变成了必要条件。”

总结

这道题考的是优先级判断力。三件事——看得懂、信得过、用得安全——对应 Agent 使用数据的三个失败模式。每件事都要有做法、有衡量标准，还要能说出为什么暂缓其他事情。用一句“Agent 让数据治理从锦上添花变成必要条件”收尾，就是一个有观点、有结构的高分回答。

下一篇是最后一题：说一个你用 AI 提效的真实案例，效果怎么量化？

如果让你给自己公司的数仓打分，“看得懂、信得过、用得安全”三项各打几分？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长