现在做 Data Agent，最容易出现的一张架构图是： ERP、CRM、MES、数据库、数仓 → 大模型 → 对话框。 看起来只要把数据库连给大模型，企业数据就"接通"了。 但真正落地以后，很快就会遇到一堆问题： 用户问"本月销售额"，Agent 到底查订单表、出库表还是财务收入表？ 问"华东区域"，到底按销售组织、客户归属还是收货地址划分？ 一个区域经理提问时，Agent 能不能顺手把其他区域的数据也查出来？ 同一个利润指标，为什么 Agent 今天算出来是18%，明天又变成了19.2%？ 所以，Data Agent真正难的从来不是把数据库地址、账号和密码交给大模型，而是把企业原本复杂的数据体系，转换成一套Agent能够稳定理解和调用的数据能力。 从数据架构角度看，一个真正可用的企业级 Data Agent，至少应该经过： 数据源层 → 数据准备层 → 数据对象层 → 语义层 → 权限层 → Agent执行层 → 结果验证层。 在正式展开之前，如果你正在关注 AI 分析与企业数据结合，也可以先体验一下 FineBI Next： 它比较值得关注的地方，不只是自然语言问数，而是把前面的数据连接、数据准备、分析过程和后面的AI分析放在一条链路里。理解这条链路之后，再回头看 Data Agent 的数据架构，会更容易明白：AI其实只是最上面的一层，真正决定答案质量的，大量工作发生在AI下面。

一、第一步不是让Agent连库，而是先设计"数据入口" 很多 Data Agent 项目的第一版，采用的是最直接的方式： 大模型读取数据库Schema → 自动生成SQL → 查询数据库 → 总结结果。 Demo阶段确实很好用。 但企业一旦有几百张、几千张表，这条路线就会迅速暴露问题。 首先是复杂度问题。 订单可能散落在订单主表、订单明细表、退款表、商品表、客户表中；模型需要自己判断表之间怎么 Join。 其次是稳定性问题。 底层系统一旦改字段、改表名或者调整业务逻辑，Agent过去生成正确的SQL，第二天可能直接失效。 第三是性能问题。 如果让Agent自由探索生产库，它并不知道哪些表有几十亿行、哪些字段没有索引、哪些查询会造成大量扫描。 因此企业真正应该设计的，不是一个数据库连接，而是不同层次的数据入口。

通常可以分成三类： 第一类：原始数据入口。 面向数据工程和少量探索场景，可以访问底层数据库和数据湖。 第二类：分析数据入口。 把订单、客户、库存、收入等数据提前加工成稳定的数据集、市集或主题模型。 第三类：业务能力入口。 直接封装"查询销售指标""获取客户画像""查询库存风险"等高层工具。 越往上，Agent自由度越低，但确定性越强。 一个成熟架构并不是禁止 Agent 查数据库，而是遵循： 确定性越高的业务场景，越应该使用加工后的数据；探索性越强的问题，才逐渐向底层开放。 这也是 FineBI Next 在 Data Agent 场景里比较自然的一个切入点。企业的数据往往不只存在数据库里，还可能散落在 Excel、业务应用以及其他数据源中。先通过数据连接把这些数据纳入分析层，再利用数据准备完成抽取、清洗、转换、合并和汇总，就可以把大量底层整理工作提前完成。Agent 后续面对的，不必是几十张结构各异的原始表，而可以是一批已经完成基础加工的分析表。

本质上是在做一件事：把"每次提问都临时理解数据"，变成"提前建设稳定的数据入口"。

二、第二步不是整理字段，而是建立"业务对象" 接下来一个经常被忽略的问题是： 数据库保存的是表，但业务人员讨论的是对象。 CRM里有客户表，ERP里也有客户表，财务系统里可能叫往来单位。 如果 Agent 直接面对这些表，它看到的是三个不同的数据实体。 但业务人员认为： 这就是同一个客户。 因此 Data Agent 建设之前，需要先把企业最重要的业务对象抽象出来。 例如： 主体对象：客户、供应商、员工、组织、商品、设备。 交易对象：订单、合同、采购、付款、发票。 经营对象：收入、成本、库存、应收、现金流。 真正重要的是建立它们之间稳定的关系。

例如分析"客户利润"时，Agent至少需要知道： 客户对应哪些订单； 订单对应哪些产品； 收入采用什么确认方式； 成本如何归集； 费用如何分摊。 如果这些关系不提前建好，大模型只能每次根据字段名称猜。 所以一个很重要的数据架构原则是： 能够通过主数据、数据模型和业务规则提前确定的关系，就不要让大模型每次重新推理。 Agent真正应该推理的是： 业务问题下一步应该从哪个方向分析。 而不是： customer_id到底应该和哪个字段Join。

免费试用

三、真正拉开Data Agent准确率差距的，是语义层 数据整理完成以后，问题仍然没有结束。 因为数据正确，不代表Agent理解正确。 例如数据库里同时存在： 销售额、开票收入、出库金额、财务收入。 业务问： 今年销售增长多少？ Agent应该选哪个？ 这就是语义层要解决的问题。 一个面向 Data Agent 的语义层，至少应该保存四类信息： 指标、维度、业务口径、指标关系。 例如"销售收入"不能只有一个公式，还应该明确： 数据来自哪里； 时间按什么字段统计； 是否含税； 退货如何扣除； 哪些订单状态计入； 统计到什么粒度； 适用于哪些业务场景。 更进一步，还应该建立指标之间的关系。

比如： 利润 = 收入 - 成本 收入继续拆： 收入 = 销量 × 平均售价 销量继续拆： 销量 = 客户数 × 购买频次 × 单次购买量 这样用户问： 为什么利润下降？ Agent就不必在几十个字段中随机寻找相关性，而可以优先沿着既定的业务逻辑： 利润 → 收入/成本 → 销量/价格 → 客户/产品 逐层分析。 这里的关键并不是把所有分析过程写死。 而是把： "什么叫利润"固定下来，把"为什么利润下降"交给Agent判断。 前者是确定性知识，后者才需要模型推理。 如果企业本身已经通过 FineBI Next 在建设分析数据，可以把这层语义基础提前沉淀在分析资产里。 例如利用分析表把多源数据进行清洗、合并、分类汇总和指标计算，再将成熟结果作为企业数据供其他分析使用；同时，分析过程采用步骤化方式保留下来，字段参与了哪些后续计算也可以继续追踪。这样 Agent 使用的就不是一张只有字段名的"裸表"，而是一套已经经过业务加工、能够继续复核的数据资产。

Data Agent最怕的不是数据少，而是同一个业务概念存在五种解释。

四、权限不能写进Prompt，而应该长在数据架构里 企业 Data Agent 和普通问答机器人最大的区别之一，就是： 它面对的不是公共知识，而是有权限边界的企业数据。 一个销售只能看自己的客户； 区域负责人可以看本区域； 总部可以看全国； 普通员工可以看到部门成本，却不应该看到个人薪酬。 如果 Agent 拿的是数据库超级账号，再通过 Prompt 告诉模型： 不要回答用户没有权限的数据。 这并不是真正的权限控制。 因为 Prompt 解决的是： 模型应该怎么做。 权限系统解决的是： 模型从物理上能拿到什么。

企业至少需要考虑四层权限： 数据源权限：能不能访问这个数据源； 对象权限：能不能使用这张表、这个指标； 行权限：能看到哪些组织、区域、客户； 字段权限：哪些敏感字段可以返回。 更进一步，还应该遵循一个重要原则： Agent不能拥有比当前用户更大的数据权限。 也就是说，用户身份应该贯穿： 提问 → Agent → 工具调用 → 数据查询 → 结果返回 整条链路。 否则前端虽然显示"张经理正在提问"，数据库实际收到的却永远是同一个超级账号，所谓权限控制就只剩下一层界面。 这一层如果企业已经在 FineBI Next 中管理分析应用，可以先把组织、成员和数据使用边界建立起来。 FineBI Next 本身支持统一用户、组织和权限管理，数据源也可以按成员进行授权，实际数据分发场景还能依据行权限让不同角色看到不同的数据范围。对 Data Agent 来说，这类机制最大的意义不是"控制一张看板谁能看"，而是给后续 AI 数据消费建立一套现成的权限边界。

越重要的规则，越不能依赖大模型自觉遵守。 权限如此，数据隔离同样如此。

五、Agent真正应该调用的，是"数据能力"，而不是无限制SQL 做到前面几层以后，才真正进入 Agent。 很多早期 Text-to-SQL 架构只有一个工具： execute_sql() Agent可以自己读Schema、写SQL、执行查询。 但企业规模一大，这种工具粒度就太低了。 一个更稳定的方法，是逐渐把底层能力封装成高层工具，例如： query_metric()：查询标准指标； compare_period()：执行同比环比； query_customer()：获取客户经营信息； drill_order()：下钻订单； query_inventory_risk()：查询库存风险； get_metric_definition()：获取指标口径。 这样 Agent 的任务就发生了变化。

免费试用

过去是： "我要自己想办法查数据库。" 现在变成： "为了回答这个问题，我应该调用哪些数据能力？" 比如用户问： 华东利润为什么下降？ Agent可以先调用利润指标，发现下降12%； 然后按收入、成本拆解； 发现主要来自收入； 继续拆区域产品； 最后定位到某产品销量下降。 整个执行链实际上变成： 理解问题 → 制定分析计划 → 调用工具 → 获取数据 → 判断结果 → 决定下一步 → 输出结论。 这才是真正的 Agent，而不仅仅是"自然语言转SQL"。 FineBI Next 的 AI 分析放在这里会更贴合这一层：用户可以直接围绕已有数据提出问题，AI根据意图继续选择维度、计算指标、生成分析表和图表；如果发现某个异常，还可以在已有分析基础上继续追问。更关键的是，中间生成的分析步骤可以查看和编辑，而不是模型在后台完成一次不可见的黑盒计算。

对于经营分析来说，这一点非常重要。 因为企业需要的不只是： AI告诉我答案是什么。 还需要知道： 它是怎么一步一步得到这个答案的。

六、最后还要加一层：验证系统 很多 Data Agent 架构做到"生成答案"就结束了。 但真正进入财务、经营、供应链等场景以后，还必须增加： 结果验证层。 至少要检查三件事。 数据是否新鲜 如果库存表最后更新时间是三天前，Agent不能把结果描述成"当前库存"。 数字是否闭合 如果 Agent 认为三个原因导致利润减少1000万元，那么三个原因的影响金额至少应该能够和总变化基本对应。 结论是否有证据 "销量下降"和"市场需求下降"不是一回事。 前者数据可以直接证明； 后者可能还需要市场数据、客户行为或者销售反馈。 所以成熟的 Agent 应该能够区分： 事实、推断和假设。

数据已经证明的，可以明确输出； 数据支持但不能完全证明的，应该标记为判断； 证据不足的，则应该告诉用户还需要哪些数据。 这其实是企业级 Data Agent 很重要的一种能力： 不是永远给答案，而是知道什么时候不能武断地下结论。

结语：Data Agent的上限，最终取决于下面的数据体系 表面上看，Data Agent 是一个 AI 项目。 但真正把它拆开以后就会发现，大量工作仍然属于传统数据架构： 数据接入、数据清洗、主数据、数据建模、指标口径、权限管理、血缘追踪、数据质量。 AI改变的主要是最上面一层。 过去，用户需要自己找报表、选指标、做分析； 现在，用户可以直接说： 帮我看看华东利润为什么下降。 然后由 Agent 自动组织后面的分析过程。 但前提始终没有改变： 下面必须有一套值得信任的数据体系。 所以 Data Agent 真正成熟的架构，不应该是： 业务系统 → 大模型。 而应该是： 业务系统 → 数据准备 → 业务对象 → 语义与指标 → 权限体系 → 数据工具 → Agent → 验证。 其中能提前确定的东西，尽量提前确定； 真正存在判断空间的地方，再交给 Agent 推理。 这才是从数据架构角度理解 Data Agent 最核心的一句话： 不要让大模型替企业重新理解一遍数据，而要先把企业已经确定的数据知识变成它可以调用的能力。 做到这一步，Agent才真正从"会查数据库的聊天机器人"，变成一个能够进入企业经营体系的数据分析入口。