治理总览

Analytics Agent 的治理能力用于回答三个问题：

谁可以进入系统并使用哪些功能。
谁可以进入某个分析域，并使用域内哪些资源。
当用户发起问答、修改配置或导出数据后，管理员如何追踪操作记录。

治理配置不只是一组权限开关。它会影响用户能看到哪些分析域、能使用哪些数据资产、能否编辑指标或答案构建器，以及问答生成 SQL 时是否会自动附加数据范围约束。

从使用效果看，业务人员越不需要理解底层字段、SQL 和系统配置，治理和语义维护就越重要。管理员和维护者需要提前把“谁能问什么、按什么口径问、能看到哪些数据、错了由谁处理”配置清楚。否则自然语言入口只是降低了提问形式的门槛，并不会自动消除表误选、字段歧义、口径冲突和权限错配。

因此，治理的目标不只是防止越权访问，也包括提高问答准确性、降低业务用户理解成本和缩短问题排查路径。

管理配置的本质：让大模型成为可控的企业分析 Agent

Analytics Agent 不是让大模型直接面对企业所有数据自由推理。企业数据分析要求口径一致、权限可控、结果可验证、问题可追踪，因此必须通过管理配置把通用大模型约束和增强成适合企业分析场景的 Agent。

可以这样理解管理工作的价值：

管理配置	对大模型起到的作用	对业务用户的价值
分析域	划定业务上下文和可用数据范围	用户不用说明“去哪些表里找”。
字段语义	告诉模型字段的业务含义、别名、用途和可见性	用户可以说业务词，不必说字段名。
指标	固化高频聚合口径	用户问核心指标时不需要每次解释计算规则。
知识	补充业务术语、同义词、制度说明和口径解释	用户使用公司内部语言时，模型更容易理解。
答案构建器	封装复杂分析逻辑和动态参数	复杂分析可以在可控模板内执行。
权限与行级权限	限制模型可访问的数据范围	用户不能通过自然语言绕过权限边界。
推荐问题	给模型和用户一组稳定的业务入口	用户第一次进入分析域时更容易问对问题。
反馈与审计	记录问题、修复和变更过程	错误可以被定位、分派、修复和追踪。
问答验证	用真实业务问题检查配置是否生效	上线前证明 Agent 能稳定回答。

所以管理员和维护者做的不是“后台配置杂项”，而是在为大模型建立企业分析所需的上下文、语义、口径、权限和验证边界。配置越完整，业务用户越能用简单自然语言得到可信答案。

分析域本身也是治理边界

分析域不是简单的数据目录或问答入口。它本身就是 Analytics Agent 中非常重要的治理手段，可以把不同业务主题、数据资产、指标口径、知识和用户访问范围隔离开。

一个分析域通常对应一个明确的业务场景，例如销售经营分析、财务分析、会员运营分析或人力资源分析。用户进入某个分析域后，系统只会围绕该域内已经加入和配置的资源进行问答，包括表、文件、知识、指标和答案构建器。这样可以避免用户在自然语言提问时跨到不相关的数据资产，也能减少模型在多个业务上下文之间误选表、误用字段或混用口径。

从治理角度看，分析域至少有以下价值：

治理价值	说明
业务边界隔离	将不同业务主题拆分到不同分析域，减少跨主题误问和误答。
数据资产隔离	只有加入当前分析域的表、文件、知识、指标和答案构建器才参与该域问答。
口径隔离	不同分析域可以维护各自的指标、知识和答案构建器，避免财务口径、运营口径、销售口径混用。
人员范围隔离	通过分析域权限控制哪些用户可以进入该域。
问答上下文收敛	模型在更小、更明确的资源集合中选表、选字段和选指标，通常更容易生成准确答案。
上线与变更控制	可以按分析域分批上线、分域验证、分域回溯审计日志，降低配置变更影响范围。

因此，推荐先用分析域完成第一层治理隔离，再用角色授权、资源数据权限、字段隐藏和行级权限做更细粒度控制。不要把所有表和所有用户都放在一个“大而全”的分析域里，否则会增加权限治理、口径治理和问答准确性排查的复杂度。

大规模组织如何规划分析域

如果企业有上万张表、上百个业务部门和数千名用户，不建议把所有表和所有用户都放进一个“大而全”的分析域。

原因不是系统不能容纳更多资源，而是这种组织方式会削弱分析域作为治理边界的价值：

问题	影响
业务上下文过大	用户提问时，模型需要在过多表、字段、指标和知识中选择，误选概率上升。
权限边界不清	不同部门用户混在同一个域内，后续需要依赖更复杂的角色、字段隐藏和行级权限补救。
指标口径冲突	不同部门可能对“收入”“活跃用户”“有效订单”等概念有不同口径，放在一个域内容易混用。
配置维护困难	字段语义、知识、指标、答案构建器都集中在一个域内，任何调整都更难评估影响范围。
问答排查困难	当答案不准确时，很难判断是选错表、字段歧义、知识冲突、指标口径错误还是权限限制导致。
上线风险变大	一个域承载过多业务，配置变更可能影响大量用户和问题场景。

更推荐按“业务主题 + 使用人群 + 数据口径”规划多个分析域。

划分维度	适用方式	示例
按业务部门	每个部门维护自己的核心分析域。	财务分析域、销售分析域、运营分析域、人力资源分析域。
按业务主题	同一部门下按稳定分析主题拆分。	销售线索分析、合同回款分析、客户续费分析。
按数据敏感度	敏感数据单独建域，严格控制成员和字段。	薪酬分析域、财务凭证分析域、客户隐私分析域。
按用户群体	不同角色使用不同粒度的数据域。	管理层经营总览域、区域经理分析域、一线运营分析域。
按上线阶段	先建设核心高频问题域，再逐步扩展。	先上线销售经营分析，再补充渠道、线索、回款专题。

判断一个分析域是否过大

如果出现以下情况，通常说明分析域应该拆分：

用户经常问“为什么系统选了另一张表”。
同一个业务词在不同部门有不同口径。
域内表数量过多，维护人员难以逐张补充字段语义。
推荐问题、知识、指标覆盖了多个互不相关的业务主题。
不同用户群体的数据权限差异很大，需要大量例外规则。
问答准确性问题很难定位到具体表、字段、知识或指标。

实操建议

不要从“我有哪些表”出发规划分析域，而要从“哪些用户围绕哪些业务问题做分析”出发。

一个健康的分析域应该满足：

业务主题清晰。
使用人群相对明确。
表和指标围绕同一组业务问题。
口径可以在域内保持一致。
维护人员能持续管理字段语义、知识和指标。
问答效果可以通过一组代表性问题验证。

如果某张表会被多个部门使用，也不一定要放进一个大域。更好的方式是按部门或主题把该表加入不同分析域，并在各自域内配置符合该场景的字段语义、知识和指标口径。

治理对象

治理对象	配置入口	主要作用
账号	管理 > 用户管理 > 账号管理	管理可登录系统的用户，并可从用户行的更多菜单配置行级权限。
角色	管理 > 用户管理 > 授权管理	管理用户的功能权限和资源数据权限。
行级权限点	管理 > 用户管理 > 行级权限	定义某个权限点应作用到哪张表、哪个字段。
分析域成员	分析域配置 > 权限	将用户加入分析域，使用户可以访问该域。
域内资源	分析域配置 > 数据	配置表、文件、知识、指标、答案构建器等可被问答使用的资源。
全量下载权限	管理 > 用户管理 > 授权管理	控制角色是否可以使用全量下载能力。
审计日志	管理 > 审计日志 > 操作记录	查看登录、新增、修改、删除、导出等操作记录。

权限之间的关系

Analytics Agent 中常见的权限配置不是互相替代的关系，而是分层生效。

层级	解决的问题	示例
账号是否存在	用户能否登录系统。	`tester` tester 用户可以被添加到分析域。
角色授权	用户能访问哪些功能、哪些资源类型。	例如，可为财务人员配置指标可查看、答案构建器不可编辑等权限。
分析域隔离	用户进入哪个业务上下文，哪些域内资源参与问答。	财务分析域和销售分析域分别维护表、指标、知识和成员。
分析域权限	用户能否进入某个分析域。	将 `tester` tester 加入 `doc_ops_test_domain_20260608` doc_ops_test_domain_20260608 。
域内资源配置	进入域后，哪些表、文件、知识、指标可被问答使用。	表已经加入域，文件已经加入域，知识已启用。
字段和列配置	问答时哪些字段可见、可筛选、可聚合、可分组。	隐藏字段不会优先暴露给问答，实际可起到列级可见性控制作用。
行级权限	同一张表中，不同用户能看到哪些行。	华北销售只能看到华北区域数据。
全量下载	用户能否批量导出可见数据。	只给需要离线分析或复核的角色授予全量下载。
审计日志	谁在什么时间做了什么操作。	查看某用户是否修改过域配置、创建过答案构建器或导出过数据。

因此，用户“能否问到某个数据”通常不是由单个配置决定。排查时应同时检查角色、域成员、资源加入状态、字段隐藏和行级权限。

常见治理场景

让用户访问一个分析域

至少需要满足以下条件：

用户账号存在。
用户拥有可使用 Analytics Agent 相关功能的角色。
用户已加入目标分析域的权限列表。
分析域中已加入必要的数据表、文件、知识、指标或答案构建器。

在实操中，分析域“权限”页添加用户时，只选择用户，不选择角色。用户显示的角色来自账号已有的全局角色，而不是在分析域内单独指定。

控制用户能用哪些功能

在“授权管理”中配置角色。自定义角色可以编辑，内置角色可能受系统限制。

实操中，自定义角色“财务人员”可以进入编辑态，并配置：

功能 & 操作权限。
数据权限。

功能权限决定用户能否看到和操作相关模块；数据权限决定用户对答案构建器、数据源、知识、表、文件、指标等资源的可见或编辑范围。

其中，“全量下载”应单独评估。它关系到用户是否可以批量导出可见数据，不建议默认授予所有业务用户。

控制同一张表中不同用户看到不同数据

使用行级权限。

行级权限分两步：

在“行级权限”页面定义权限点，并映射到目标表和目标列。
在“账号管理”中打开用户的更多菜单，进入“行级权限”，为该用户配置权限规则值。

实操中，用户行的更多菜单包含“行级权限”入口；授权表单支持选择已定义的行级权限点，并配置“枚举值”或“表达式”类型的规则。

控制字段是否暴露给问答

在表字段配置中使用隐藏、字段用途、列类型、字段描述等能力。

隐藏字段虽然不是底层数据库权限，但对 Analytics Agent 问答来说，可以达到列级可见性控制效果：被隐藏的字段不应作为问答优先可见、可选或可解释的字段。

适合隐藏的字段包括：

不希望业务用户看到的敏感字段。
中间计算字段。
容易被误用的技术字段。
与当前分析域无关的冗余字段。

追踪配置变更和用户操作

使用审计日志。

实操确认，“管理 > 审计日志 > 操作记录”支持按时间范围、操作人和操作类型筛选。表格字段包括用户名、用户账户、时间、操作类型和操作内容。

操作类型筛选项包括：

登录
新增
修改
删除
导出

审计日志适合用于上线后排查“谁改了配置”“谁导出了数据”“某个答案构建器是谁创建的”等问题。

治理上线建议

上线一个面向业务用户的分析域前，建议完成以下检查：

检查项	建议
角色是否明确	不要让所有用户都使用管理员角色。为财务、运营、销售等角色分别配置权限。
域成员是否最小化	只把需要使用该域的用户加入域权限列表。
资源权限是否分级	对答案构建器、表、文件、知识、指标区分可查看和可编辑。
字段是否治理	隐藏敏感字段，补充字段别名、描述、用途和列类型。
行级权限是否验证	用测试用户验证受限用户只能看到授权范围内的数据。
全量下载是否受控	只给确有需要的角色授予全量下载，并检查导出审计。
审计日志是否可追踪	确认关键配置变更能在审计日志中看到。

除了检查配置项本身，管理人员还需要用一组代表性业务问题验证这些治理动作是否已经生效。例如，高频问题是否能稳定回答、歧义问题是否还会误选字段、不同角色账号看到的数据范围是否符合预期。治理工作是否做到位，更适合通过这类问题反向验证，而不只是检查后台配置是否已经填写。