结构化摘要

文章主旨：

数据智能体接管取数与分析后，指标口径不能再依赖分析师个人经验兜底，必须转化为有人定义、机器可读、可复核、可追责的生产规则；智能体可以执行口径、发现口径冲突，但不能自行成为口径 Owner。

关键要点：

1. 取数自动化让口径争议提前暴露：争议不再是“SQL 谁写错了”，而是“谁授权系统这样理解业务”。
2. “新增付费客户”这类指标涉及业务事件、去重对象、时间字段、退款回冲等多重定义，模型没有资格替组织拍板。
3. 指标进入智能体前需拆开四种责任：业务指标负责人、数据团队、平台团队、结果使用者，分别对业务含义、工程实现、权限审计和具体决策负责。
4. 生产指标需要“指标契约”，写清 Owner、统计对象、事件与时间、公式与过滤、数据源、权限、校验规则和版本，并配套基准查询与回归测试。
5. 出错时应沿证据链回放定位“哪一层控制失效”，并在上生产前守住三条红线：Owner 缺失不开放、绕过语义层需限制、无日志版本回放不进入高风险决策。

内容结构：

一、取数变快以后，口径争议会更早暴露

文章以某技术会议中快手 Data Agent 的议题介绍为引子，指出其已覆盖找数取数、数据开发、归因报告、人群洞察、AB 分析、埋点分析等数据全链路场景。议题介绍披露其主动会话周活跃用户数近万，可作为企业内部使用规模的公开信号，但不能据此推断准确率、节省工时或业务收益。企业级数据智能体的难点，已从“能不能生成一条 SQL”转向“能否在复杂知识、权限和责任体系中稳定工作”。当找数、开发、归因、实验分析都交给 Agent，个人脑中的补充规则会失效，系统会严格执行它拿到的定义，哪怕定义只写了半句。

二、“新增付费客户”为什么能算出四个答案

文章举例说明：业务问“本月新增付费客户数”，实际至少要确认“新增”按首次下单、首次支付成功还是首次履约；支付后退款是否计入；老客户换号注册按账号还是统一客户 ID 去重；试用转正式、续费转套餐、员工测试单如何处理；“本月”按支付时间、入账时间还是业务自然月，跨时区如何截断。这些条件散落在订单、支付、退款、客户主数据、商品和测试账号清单中。Agent 能找到表、写连接、生成图，也可能从历史查询中学习“最常用写法”，但选择哪个业务事件作为“付费成立”属于经营规则，按什么对象去重属于客户管理规则，退款如何回冲涉及财务与业务确认，模型无权替组织决定。因此口径问题不能简单归给数据部门；业务部门也不能误以为“自然语言说清楚”就等于需求说清楚了，自然语言恰恰最容易省略边界。

三、四种责任拆开，谁负责就清楚了

• 业务指标负责人：对业务含义负责。使用指标管理业务、配置资源或评价结果的业务域应指定指标 Owner，确认统计对象、业务事件、时间范围、排除项、适用场景和变更生效时间；跨部门指标可由治理委员会协调，但最终要落到明确责任人。
• 数据团队：把口径变成可执行、可测试、可版本化的规则，将业务语言转换为字段、关联关系、过滤条件、计算公式和质量校验。文章引用 dbt 官方文档说明，语义层集中定义指标、供不同下游工具使用同一套定义，AI 工具可连接受治理的指标，避免直接猜测原始表；语义层正成为数据智能体的业务上下文。
• 平台团队：对权限、运行边界和可追溯性负责，包括 Agent 可访问的数据源、执行身份、是否允许查询明细、能否调用外部工具、失败后如何降级。文章引用微软 Fabric 数据代理说明，代理查询继承用户对底层数据的权限，行级与列级安全继续生效，发布版本与草稿版本区分管理；原则是“会问问题，不等于自动获得更多数据权限”。
• 结果使用者：为具体决策负责。同一结果用于个人探索、经营例会、财务披露或绩效考核，风险不同；进入高影响决策前，需由指定角色复核适用范围、异常说明和数据时点。报告生成自动化不等于决策责任转移给系统。

文章还引用微软 Purview 的治理角色设计，将 Governance Domain Owner、Data Product Owner、Data Steward、Data Quality Steward 等职责分开，说明业务定义、数据实现、质量维护和访问控制本就不该压在一个岗位上。

四、给每个生产指标办一张“身份证”

文章指出，很多企业的指标字典只适合人看，Agent 需要的是能参与执行的“指标契约”。一项指标进入生产级智能体，至少要写清：业务名称、同义词和禁止混用的近义词；唯一业务 Owner 及数据维护人、技术实现人和复核人；统计对象与数据粒度；触发业务事件、时间字段、时区和统计周期；计算公式、关联键、过滤条件、退款或撤销规则；权威数据源、备选数据源和数据新鲜度；可访问的明细范围、敏感字段和行列级权限；校验规则、基准查询、已知限制、版本号与生效日期。

其中最容易被忽略的是版本：口径调整后不能只覆盖原定义，否则 Agent 重跑上月报告时可能用新口径解释旧业务，数字变化却找不到原因。每个生产指标都要有唯一、可找到的业务 Owner，并保留变更记录、影响范围和回溯策略。指标契约还应准备少量经确认的基准问题，如“某月新增付费客户数”“按渠道拆分后合计是否一致”“发生全额退款后如何回冲”，既作为 Agent 示例，也作为回归测试。文章引用 dbt 对数据测试的定义，指出测试是对模型和数据资源作出断言，可检查唯一、非空、关联完整性及自定义业务逻辑；口径说明负责告诉 Agent 怎么算，测试负责证明这次确实按规则算。

五、出错时沿证据链找，不按组织架构甩锅

文章认为，数据智能体出错后，最有用的方式不是讨论“AI 靠不靠谱”，而是把一次回答拆成可回放链路：用户原问题、识别到的指标、调用的口径版本、选择的数据源、生成的 SQL 或其他代码、执行身份与权限、返回数据、分析步骤、最终结论、人工修改记录。这样可以把“谁背锅”改为“哪一层控制失效”。文章引用微软 Fabric Data Agent 的交互审计能力，其可记录时间、用户身份、关联资源、用户提示、AI 回复及生成的查询或代码；NIST AI 风险管理框架也强调明确人机协作中的角色与监督责任、持续监控，并通过文档增强人工复核和问责。

六、上生产前，至少守住三条红线

• 指标 Owner 缺失、口径只有技术说明而没有业务确认的指标，不开放给生产级 Agent；可用于探索，但输出必须标记为临时结果。
• Agent 若绕过统一语义层、直接在大量原始表中自由选择字段，至少要限制使用范围，并把生成逻辑完整展示给复核人员；经营核心指标默认调用已认证口径，发现定义冲突时停止生成确定性结论，转为提示用户选择或发起治理流程。
• 没有日志、版本和回放能力的结果，不适合直接送入经营决策；外部披露、财务结算、绩效评价、实验结论等高风险场景，需预先指定复核角色，未经指定人员复核不得直接进入决策。

七、结论

文章判断，数据智能体成熟后，企业会少写临时 SQL、少做重复报表，但指标治理的工作量不会凭空消失，而是从“解释一张报表”转向“维护一套机器能够执行的业务规则”，这项工作更靠前，也更难糊弄。最终责任划分是：业务负责人拥有指标含义的定义权和变更责任；数据团队负责工程化落地与质量验证；平台团队负责权限、运行和审计；结果使用者负责场景判断与最终决策。智能体可以执行口径，也可以发现口径冲突，但不能自行成为口径 Owner。

文章总结：

文章主张把指标口径治理前移为生产级规则与责任体系，智能体只是口径的执行者和冲突发现者，而非口径的定义者。

老司机聊数据

查看原文：业务说口径，数据写规则，Agent做执行：指标责任应该这样分

文章来源：

老司机聊数据

扫码关注公众号