你问 AI：“昨天活跃用户为什么下降？”它即使能访问数据库，也未必答得对。它得先知道“活跃用户”怎么算、能按哪些维度拆分、该查哪张表，以及自己有没有权限。少了这些上下文，AI 可能流畅地给出一份口径错误的分析。
Pinterest Engineering 介绍的 Metrics Board，正是想补上这层基础设施：把指标创建、质量控制和查询所需的语义信息集中管理，并进一步支持 agent-driven analytics——由 AI 代理自主寻找和分析数据。值得注意的是，目前公开信息只有 Pinterest 的官方文章，规模和效果均属公司自报，尚无独立信源或性能数据验证。
先让所有人说同一种“数据语言”
据 Pinterest 介绍，公司有数百名分析师、数据科学家和工程师，从 PB 级数据湖中创建了数千个指标。数据湖是集中保存日志、交易和实验数据的底层仓库；它能装下大量数据，却不会自动说明这些数据在业务上意味着什么。
这会带来一个常见问题：两个团队都在计算“增长”，定义、过滤条件和更新时间却可能不同。结果看似都精确，实际上无法直接比较。
Metrics Board承担的是“指标层”（metrics layer）的工作：集中管理收入、活跃用户、转化率等指标的定义，让报表、实验和代理复用同一套计算口径。Pinterest称，这个平台覆盖指标的创建、质量管控、产品体验、架构与系统集成，目标是让整个指标体系更有组织、更容易扩展，也更能应对故障和变化。
不先统一所有表，而是管住指标入口
团队设计平台时遇到过一个关键选择：先给全公司的数据表建立严格统一的数据模型，再让大家组合指标；还是允许团队提交任意 SQL——用于向数据库取数的查询语言——同时要求补齐时间列、维度等说明。
据 Pinterest Engineering，用户反馈和公司内部庞杂的数据表类型促使团队选择后者。原因很实际：为每张表预先建立完整的语义模型并不现实。
但“允许任意 SQL”不等于放任各算各的。Metrics Board用表单收集必要信息，再自动生成 YAML——一种供系统读取的结构化配置文件——并代替用户发起 Git pull request，也就是把指标变更送进类似代码修改的审查流程。这样一来，指标是谁定义的、改过什么、是否经过审核，都可以留下记录。
这也是数据治理的核心：规定谁能访问什么、定义由谁维护、变更如何审核。过去它主要防止人工分析出现口径漂移；当代理能够自主取数后，它还要防止机器越权访问或误用指标。
为什么这对 AI 代理尤其重要？
原始数据库通常只会告诉代理列名和数据类型。代理真正需要的还有“语义上下文”：指标是什么意思，适合在哪些场景使用，可以按哪些维度切分，以及哪些查询已经获得认证。它要靠这些信息，把一句业务问题翻译成正确的查询。
Metrics Board最有意味的地方，是它并非一开始就为 AI 而建。据 Pinterest Engineering，这个项目最初要解决的是人对指标失去信任：团队各自维护数据管道、重复创建指标，监控不足时常常要等下游报错才发现问题，说明与实际数据也会逐渐脱节。
等到指标定义、负责人、质量等级和认证查询被结构化之后，Pinterest发现，同一套治理信息也可以通过 MCP 提供给分析代理。MCP是一种让 AI 系统调用外部工具和数据的接口方式。换句话说，代理并不只需要“连上数据库”；它需要一张经过维护的业务地图。让指标先对人可信，恰好也构成了让代理可靠使用它们的前提。
这个需求在 Pinterest尤其突出。公司称，任意时点都有数千项实验处于活跃状态，而且实验结果是每项新功能发布的准入门槛。如果不同实验使用的指标定义不一致，比较就失去基础；让代理参与分析，只会进一步放大这种风险。因此，统一定义、质量检查和访问边界不再只是分析团队的便利工具，而开始接近 AI 数据基础设施。
局限与未知
- 官方文章没有披露代理使用的模型、准确率、查询延迟、成本或上线后的业务效果，因此“agent-ready”目前更像架构方向，不能等同于已经验证的性能提升。
- “数百名数据生产者”“数千个指标”和“数千项活跃实验”均为 Pinterest自报，缺少统计口径、具体时间点和外部印证。
- 现有材料说明了产品思路与部分设计取舍，但没有完整展示权限执行、错误查询拦截和指标变更冲突如何处理。