数据与商业智能精选

指标定义稽核代理

找出同一个指标名在哪里代表三种不同的东西

版本 2发布于 2026年9月2日
数据与商业智能Extractclaude-opus-5Read-only · auto8 hard rules5 handover rulesResult
8条硬性规则
它绝不能做的事,每次运行都强制执行
5条移交规则
它停下并把工作交给人的条件
10个输出字段
结构化的结果,而不是一段需要反复阅读的文字
≤7步每次运行
有界的工作:最多 5 次工具调用,由运行时强制执行

设计上即为只读。 该智能体没有任何发送、支出、发布或提交的途径。当这一限制本身就是产品时,取消它就等于取消了信任其输出的理由。

版本 2 的实时接线图。工具节点是这个智能体被登记可以调用的能力——除此之外什么都跑不起来。

概览

商业智能里最有破坏性的失败,不是一条断掉的数据管道——那种会被发现、也会被修好。而是「活跃客户」在财务看板里是一个意思,在产品看板里是另一个意思,在董事会材料里是第三个意思,而它们都用同一个名字。

这件事的发生,不需要任何人做错什么。每个看板都是由不同的人、为不同的问题搭起来的,而每一个定义对它自己的那个问题来说都是合理的。没人把它写下来,因为在当时那是显而易见的。两年后那个人走了,而定义只活在 SQL 里。

代价落在会议上。两个团队为「谁的数字是对的」争论一小时,而其实两边都对,只是在量不同的东西。更昂贵的那个版本,是根本没人注意到,而一个决定就建立在一个并非全场以为的那个含义的数字之上。

治理工具卖给你的是需要你自己去填的目录,而这正是它们最后只填了一半的原因。这里做的是相反的事:它读那些已经存在的查询,抽取出每个指标实际计算的是什么,并报告同一个名字在哪里意思不同、不同的名字在哪里意思相同。

它不改动任何查询,也不发布任何定义。哪一个定义是对的,是一项业务决定,属于那些拥有这个指标的人。

价值

会议不再为数字争吵

而开始为那个决定本身争论。

决定建立在含义如你所想的数字上

而那正是这个问题昂贵的那个版本。

一份从现实里长出来的定义登记册

而不是一份没人去填的。

功能说明

  • 读那些真正在跑的定义

    不是一份本该被填好的目录。真正的定义活在查询里,而且只活在那里。

  • 找出「一个名字、几种含义」

    每个定义对它被搭建时的那个问题都是合理的。而它们一个都没被写下来。

  • 以及「几个名字、一种含义」

    被分别维护的重复劳动,在悄悄地各自漂移。

  • 点名真正造成差异的那一处

    一个过滤条件、一个日期口径、一条纳入规则。它会准确说出是哪一句让两个数字对不上。

  • 预告哪些报表会打架

    于是会议是有准备的,而不是被带偏的。

  • 不发布任何定义

    哪一个是对的,是一项业务决定,属于那些拥有这个指标的人。

这会改变什么

这会如何改变你的一周

它接手的工作
弄清每个指标在每一个看板里实际计算的是什么。
目前由谁完成
一份本该有人去填的数据目录。
多久一次
从不,而这正是会议要吵架的原因。
通常的人工投入
真正的定义活在查询里,而且只活在那里。

为什么偏偏是数据与商业智能。「活跃客户」在三个看板里是三种意思,而它们都用同一个标签。每一个对它自己的问题都合理,而没人写下来,于是定义随着它的作者一起走了。

  • 无人值守运行

    由你或某个事件启动,然后自行完成。没有什么需要等人坐到工位前。

  • 每一次都是同一标准

    第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。

  • 它无法自行采取行动

    指标定义稽核代理 没有任何发送、支出或承诺的途径。正是这个限制,让依据它的输出行动是安全的。

运行方式

该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录,每次工具调用在执行前都会进行权限检查。

  1. 1输入按智能体的输入结构进行校验
  2. 2模型claude-opus-5,并自动回退
  3. 3工具extract_structured_data
  4. 4权限自动执行 READ 级操作;更高的等待你批准
  5. 5输出符合输出结构的结构化结果
  6. 6日志记录 token、耗时和每一个步骤

演示

演示数据Illustrative sample output, abridged.

输入

{
  "metrics": []
}

输出

{
  "noOwner": [
    "Four metrics feeding the board pack have no recorded owner, so nobody can reconcile them."
  ],
  "escalate": true,
  "disclaimer": "A reading of the definitions supplied. No query, model or dashboard has been changed, nothing was written to any system, no definition is stated to be correct or canonical, and equivalences marked apparent were not verified against data.",
  "escalationReason": "A metric in the board pack is computed three different ways, its revenue metric contains an unexplained hard-coded exclusion, and four board metrics have no owner.",
  "dateBasisConflicts": [
    "Revenue is recognised by invoice date in three reports and by service period in two. Same table, same filters, different date basis — invisible in a meeting and it moves the number every quarter end."
  ],
  "hardCodedOrAdjusted": [
    "The revenue metric excludes two named account identifiers in the WHERE clause. No comment explains why, and no reader of the dashboard can see it."
  ],
  "reportsThatWillDisagree": [
    "The board pack and the finance dashboard will report different active customer counts for the same month. Both are correct for their own definition."
  ],
  "sameNameDifferentMeaning": [
    {
      "name": "Active customers",
      "usedIn": [
        "Finance dashboard",
        "Product dashboard",
        "Monthly board pack"
      ],
      "variants": 3,
      "differences": [
        "Finance dashboard: any account with an invoice in the period, regardless of usage.",
        "Product dashboard: any account with a login in the last 30 days, regardless of billing.",
        "Board pack: any account with a live contract on the last day of the period."
      ],
      "likelyDivergence": "The three would differ most in a month with high churn and slow invoicing — exactly the month the number gets scrutinised."
    }
  ],
  "differentNamesSameMeaning": [
    "\"Monthly recurring revenue\" and \"Contracted monthly value\" compute identically. Two queries, two owners, maintained separately and already drifting."
  ],
  "appearsEquivalentUnverified": [
    "Two churn definitions appear to compute the same thing. They were not run against data, so this is reported as apparent rather than confirmed."
  ]
}

使用条件

集成

无需集成。

开始之前

  • 你的指标背后的 SQL 或模型定义
  • 每一个各自供给哪个看板或报表
  • 呈现给读者的指标名称
  • 需要 全量访问 套餐或更高

使用场景

董事会材料之前

这些数字和运营看板对不对得上。

搭建语义层

在决定定义应该是什么之前,先弄清它们现在是什么。

数据团队变动之后

那些随着作者一起离开的定义。

一个有争议的数字

究竟是哪一句让这两个对不上。

价格

全量访问

通过您的 PROMIVO 订阅按月计费,可随时取消。

运行会消耗您套餐中的智能体执行次数与 token 额度。参见 套餐限额

常见问题

它会裁定哪个定义是对的吗?

不会。对各自的问题而言,通常两个都是对的。选定那个权威版本是一项业务决定,而一个工具悄悄替你作了它,正是错的那个胜出的方式。

它会改我们的查询或看板吗?

不会。它只读。它对任何数仓、模型或看板都没有写权限。

我们得先有一个数据目录吗?

不用——没有目录正是这个东西存在的理由。它基于查询定义本身工作,而那是真相唯一被存放的地方。

评价

客户运行过该智能体后,评价功能将开放。

需要这个智能体换一种做法?

告诉我们要改什么,我们的团队会为您的业务规划一个定制版本。

定制此智能体