代理分析时代：数据团队的新角色与语义基础设施
上周，在本系列的第一部分中，我们解释了为什么两位分析师会根据同一份数据得出两个不同的结论，以及为什么 AI 智能体（AI agents）会让这个问题变得更加严重。如果没有定义指标和业务逻辑的共享语义层，AI 生成答案的速度虽然会加快，但可靠性却无法保证。今天，我们将重点探讨这种转变带来的实际后果。
数据分析师的角色正在迅速演变。数据分析作为一门学科并不会消失，但其重心正在发生转移。
在仪表板时代，成为一名优秀的数据分析师意味着要快速编写查询、制作图表并提取数字。而在现代，要在这个领域出类拔萃，则意味着要清晰地定义指标、构建语义契约、制定治理和版本控制标准、设计防护栏（guardrails），并管控一个能够交付可靠且可重复结果的系统。
你将不再是“写故事的人”，而是要制定故事发生背后的“宇宙规则”。通过这样做，你将不再需要支付“信任税”。
这不仅仅是购买一个更智能的模型的问题，而是要构建一个足够坚实的基础，即使是一个弱模型也无法产生错误的结果。
因为事实是：AI 系统的可信度完全取决于你赋予它的含义。
2026 年必备的智能分析栈（如果你想保持理智）
为了确保 AI 驱动的分析是可靠的，你需要具备三个基本要素：
指标即代码（Metrics as code）
你的指标定义不能只存在于某人的脑海里、一张截图中，或者是一个每个人都在使用的通用仪表板中。
它们必须在代码中标准化，并存在于一个旨在定义和强制执行指标一致性的系统中。例如 dbt 或 Cube 的语义层方法、LookML 风格的建模以及类似的模式。重点在于方法论，而非供应商。业务定义必须是可执行的。
基于 Git 的一切（Git-based everything）
如果你无法回答诸如“我们是在什么时候观察到收入变化的？”、“谁对这次变化负责？”以及“它还影响了什么？”之类的问题，那么这就不值得信任——这只是在瞎猜。
将指标定义放入 Git 中，并要求每一次变更都通过拉取请求（Pull Request）和审核。是的，这可能让你觉得繁琐且沉闷——直到有一天，它让你免于向董事会展示错误的数字。
硬性防护栏（Hard guardrails）
智能体需要边界。它们需要真正的防护栏，而不是像“请遵守规则”这样模糊的指令。
只允许使用经过批准的指标和关联方式（joins）。如果某个指标不存在，不要虚构它！将其升级给数据团队进行审核。这就是防护栏的作用。它们强制 LLM 系统在定义的约束内运行，而不是即兴发挥。
下一个模型是小型智能体团队，而非一个巨大的聊天机器人
一种在实际工作中行之有效的模式正在浮现。人们构建的不再是一个什么都能做的单一智能体，而是一组分工明确、相互校验的小型智能体。此类智能体的示例包括：
探索智能体（Discovery agent） （或者说：“等等，你指的‘收入’是什么意思？”）
该智能体与业务用户沟通，并在触碰数据之前澄清意图。它会问人类经常忘记问的问题：
- “是预订收入还是确认收入？”
- “是毛收入还是净收入？”
- “是否包含退款？”
- “使用哪种货币？”
- “哪个地区？”
- “哪个日期字段？”
- “是月度至今（MTD）还是全月？”
语义层创作智能体（Semantic layer authoring agent） （或者说：“找到官方定义。”）
该智能体查阅语义层，并将请求映射到已批准的指标。 如果指标存在，它会直接选择；如果不存在，它会根据可用数据和元数据提出新指标，绝不会悄悄虚构。它会生成一个差异对比（diff），供人工审核。
审计智能体（Auditor agent） （或者说：“试着找出破绽。”）
该智能体充当独立审查员。它检查生成的查询或指标用法，寻找缺失的筛选器、错误的关联、重复计算、时区错误或请求意义与交付结果之间的不匹配。 换句话说，它是以对抗性的视角进行阅读。仅此一点就能防止大量“看起来正确”的错误发生。
人在回路（Human-in-the-loop） （人类仍然是老板）
最后由人类进行签字确认——不是针对每一个探索性的问题，而是针对任何成为指标或共享报告的内容。 工作流程变得简单：AI 提出语义层变更，数据团队成员批准（或拒绝）。系统在不失去控制的情况下运行得更快。
这就是如何在不让你的分析团队沦为全职“保姆”的情况下降低信任税。
市场现实：文本转洞察（Text-to-insight）正在分化
今天，你已经可以看到行业正在向三个大方向分化：
端到端的对话式分析平台 它们旨在完成所有工作：连接数据、定义含义、回答问题并生成洞察。 虽然速度快，但如果你需要深度定制或严格的治理，这些系统存在风险。而且不久之后，你可能会发现自己被供应商锁定——这是一个不容忽视的风险。
企业 BI + AI 插件 你已经有了 BI 生态系统，所以你在上面叠加了 AI。如果你的语义层很成熟，这种方法效果很好。但如果你的定义是碎片化的，这会很痛苦。
无头语义基础设施（Headless semantic infrastructure） 你将语义层构建为引擎，然后插入不同的 UI 和不同的智能体。这需要更多的前期投入，但它赋予了你控制权、可移植性，以及在不被单一前端锁定的情况下演进真理层（truth layer）的能力。 如果你关心规模化下的信任，第三条路径会随着时间的推移变得越来越有吸引力，因为它将“含义”视为基础设施，而不是功能。
Databao 正是建立在这种范式之上，为现代语义基础设施提供构建模块，并实现全公司的自助式分析。
值得关注的重大转变：开放语义交换（OSI）
2025 年 9 月，“开放语义交换”（Open Semantic Interchange, OSI）的发布是一个明确的信号，表明行业终于意识到了语义层面的问题。这是一项由 Snowflake 和其他行业合作伙伴共同发起的倡议，旨在定义一个供应商中立的标准，用于在不同工具间描述和交换语义模型（指标、维度、关系）。
如果 OSI 取得成功，我们将迈向一个定义变得可移植的世界：收入的定义可以从 BI 流向智能体，再流向数据仓库，而无需被重写，也不会被困在单一工具的私有模型格式中。
你可以整天争论标准（人们也确实会这样做），但方向才是最重要的。含义层正在成为一等公民。
这很重要，因为智能体不会消失，仪表板也不再是分析的唯一消费者。智能体也是消费者，而且它们比人类更需要一种共享的语言。
关于 Databao
Databao 是 JetBrains 推出的全新数据产品，旨在帮助数据团队创建和维护共享的语义上下文，并在此基础上构建他们自己的数据智能体。我们的目标是提供一种业务用户可以信任的 AI 原生分析体验，使他们能够用简单的语言查询和分析数据。
Databao 的模块化组件——上下文引擎和数据智能体，可以独立运行，无论是在本地还是在你的现有基础设施内，并使用你自己的 API 密钥。
我们诚邀数据团队与我们一起构建概念验证（POC）：我们将探讨你的用例，定义上下文构建过程，并向选定的业务用户组授予智能体访问权限。随后，我们将共同评估响应的质量和整体价值。