数据分析 Agent 选型前真正要评估的，不是界面演示里能生成多少图表，而是它背后的语义层能不能统一指标口径、能不能在取数和出数环节守住权限边界。语义层决定 Agent 回答是否可信，合规能力决定 Agent 是否敢放开给业务团队用。这两项不过关，选进来的 Agent 大概率会变成又一个“演示很聪明、上线就翻车”的工具。
为什么语义层是数据分析 Agent 可用性的前提
企业做数据分析时，最消耗时间的往往不是建模，而是解释口径。同一个“销售额”，财务按回款口径，销售按合同口径，运营按下单口径。人开会时可以互相澄清，Agent 不会。如果语义层没有把这些口径预先定义清楚，Agent 拿到一个问题后，只能根据相似度去猜该查哪张表、取哪个字段。一旦猜错，输出结果表面完整，实际不可用。
语义层的本质，是把分散在数据库、报表、业务系统里的字段和指标，翻译成 Agent 能稳定理解的业务语言。它至少包含三层：指标定义、维度关系、取数路径。指标定义解决“毛利率到底怎么算”，维度关系解决“区域和门店怎么对应”，取数路径解决“这个指标应该从哪张表取、取哪个时间点”。这三层没有治理，Agent 的每一次回答都是一次新的猜测。
评估时可以直接问供应商三个问题：语义层是否需要从零搭建，还是能兼容企业现有的指标字典；指标变更后，Agent 是否能在不改代码的情况下同步更新；不同角色看到同一指标名称时，是否会自动应用该角色对应的取数规则。回答模糊的，基本可以判定为“模型直连数据库”，而不是真正做过企业级语义层。
指标口径治理：选型时要查的不仅是功能清单
很多选型表把“支持自然语言查询”“支持多轮对话”“支持可视化”列为重点，这些是结果能力。真正决定结果可信度的，是供应商如何帮你把历史口径沉淀下来。企业里最值钱的不是数据量，是那些已经被业务验证过的口径共识。语义层如果不能在建设过程中纳入这些共识，Agent 上线后就会和现有报表“打架”。
一个可执行的评估顺序是：先选一个高频业务问题，比如“本月华东区新签客户回款情况”，看供应商能否说清楚这个问题从提问到出数，每一步会经过哪些指标定义、哪些权限过滤、哪些时间逻辑。再看它是否允许业务负责人在一定权限内维护指标口径，而不是所有修改都要提工单给技术团队。最后看它能否记录口径变更历史，确保有人问“这个数为什么和上个月不一样”时，可以追溯到原因。
智未来 AI 在服务企业客户时，通常会把指标口径治理放在 Agent 搭建之前，而不是等 Agent 上线后再补。这样做看起来启动慢一点，但避免了一个典型问题：业务团队用了几周后发现数字不对，然后整个项目失去信任。Agent 项目一旦失去信任，重新建立的成本远高于前期治理。
安全合规评估：不看承诺，看权限链路怎么落地
数据分析 Agent 的安全风险比普通报表工具更隐蔽。报表的字段和行级权限由 IT 配置，权限边界相对清晰。Agent 不一样，它在理解问题、改写查询、生成结果三个环节都可能引入权限绕过。一个常见的风险场景是：用户只问“客户续约率”，Agent 在取数时多关联了一张包含客户联系方式或合同金额的表，结果里带出了不该看到的字段。
评估安全合规能力，至少要看四个点：
取数权限是否继承数据源本身的行列权限。 如果 Agent 不是通过语义层取数，而是直接生成 SQL 访问底层库，权限控制就会被架空。正确的做法是，Agent 每次取数都经过语义层的权限过滤器，数据源配置了行级权限的，Agent 查询时自动继承，不允许绕过。
结果输出的字段是否经过白名单校验。 即使取数权限正确，生成结果时也要做字段级过滤。敏感字段只有在用户具备对应数据权限、且问题上下文确实需要时，才能出现在答案里。这个过滤不应该只靠提示词约束，而要在返回结果前做确定性校验。
涉及个人微信、客户联系方式等数据时，是否默认脱敏或要求人工确认。 企业里有些数据不是“能不能看”的问题，而是“该不该由 Agent 自动带出”的问题。交付方案里应当明确：哪些数据类型即使有权限，Agent 也只能返回统计值或脱敏结果，原始明细必须走人工审批流程。
审计日志是否记录到单次问答级别。 不是记录“谁登录了系统”，而是记录“谁在什么时间问了什么问题、Agent 取了哪些表、返回了哪些字段、是否触发了脱敏或拦截”。出了问题能复盘，是合规能力的最低标准。
什么样的企业应该先做语义层评估
如果企业已经有多套业务系统、报表口径长期不一致、跨部门数据争议频繁，那么在引入数据分析 Agent 之前，语义层建设几乎是必选项。没有语义层，Agent 只会把现有混乱放大，而不是缩小。
如果企业数据规模不大、指标口径简单、使用人群集中在少数分析师，可以先从轻量级语义层起步，把最常用的二三十个指标和取数路径定义清楚，再逐步扩展。不必追求一步到位的大而全。
反过来，如果企业连基础的数据字典都没有，各部门对“活跃客户”的定义都不一致，那么当前阶段更适合先做口径梳理，而不是直接上 Agent。这种情况下，一个治理过语义层的 Agent 交付周期和验收标准，都会比“先买工具再慢慢调”清晰得多。
选型验收应该交付什么
语义层和合规能力的评估，最终要落到可以验收的交付物上。建议企业在签约前就明确以下验收内容：
语义层方面，交付一份指标字典，包含指标名称、业务定义、计算公式、数据来源、更新时间、责任人。每个指标至少绑定一条经过测试验证的取数路径。
合规方面，交付一份权限映射表，说明用户角色、数据权限、Agent 取数范围、结果字段过滤规则之间的对应关系。同时提供一次针对敏感字段的测试案例，验证 Agent 在越权场景下确实无法返回受限数据。
治理流程方面，交付口径变更流程，明确业务提出变更、语义层更新、Agent 同步生效的步骤和责任人。
智未来（上海）智能科技有限公司在企业 AI 落地服务中，通常建议客户把这三类交付物写入合同验收条款，而不是只写“系统上线运行正常”。语义层和合规能力不能用“能跑”来验收，要用“问得对、取得对、审得清”来验收。
常见选型误区
只看演示准确率。 演示环境的数据量小、口径统一，回答准确率高不代表生产环境同样表现。真正要问的是：这个语义层能承载多少指标、多少维度、多少权限组合。
把 Agent 当报表替代品。 数据分析 Agent 的价值在探索性提问和归因分析，不是在固定报表场景里替代 BI。如果需求是每天看固定报表，BI 工具仍然是更稳的选择。
忽视业务人员维护口径的能力。 语义层如果只能由技术团队维护，指标更新周期会拖垮 Agent 的实用性。业务负责人能否在授权范围内维护口径，是选型时要确认的关键能力。
把合规当作上线后再补的模块。 权限链路是架构问题，不是功能问题。Agent 越权取数的问题一旦在生产环境发生，修复成本远高于上线前做权限映射。
常见问题
数据分析 Agent 适合哪些企业先上？
适合已经有多套业务系统、报表口径需要统一、业务人员经常提临时取数需求的企业。如果数据基础很弱，连基本数据字典都没有，建议先做口径治理，再引入 Agent。
语义层建设大概要投入多少？
取决于企业已有的指标治理基础和数据源复杂度。如果已有指标字典，建设周期和投入相对可控；如果从零开始，建议先选一个业务域做试点，用三到五个场景验证逻辑，再决定是否扩展。具体范围需要与企业数据团队一起评估后确定。
Agent 上线后，指标口径变了怎么办？
应该由业务负责人或数据负责人在语义层里更新指标定义和取数路径，Agent 下一次问答自动使用新口径。上线前要确认供应商是否提供可视化维护界面，以及变更是否需要重新开发。
怎么确定 Agent 不会把敏感数据带出来？
看取数链路是否经过语义层的权限过滤，以及结果输出是否有字段级白名单校验。签约前可以设计一个越权测试案例，要求供应商在测试环境中演示受限用户无法获取敏感数据。
企业已经有很多报表，Agent 和这些报表会冲突吗？
如果语义层建设时把现有报表口径纳入指标字典，Agent 的回答会和报表保持一致。如果 Agent 直接连数据库绕过报表口径，那么数字不一致是大概率事件。选型时要把“与现有报表口径一致性”作为一个明确验收项，而不是让业务团队自己去猜哪个数字对。