很多企业第一次做 Data Agent，最先讨论的往往是一个问题：
大模型选哪一个？——DeepSeek、GPT、Claude，还是企业自己的私有模型？
但项目真正进入企业内部以后，很快就会发现，模型反而没有想象中那么难选。
更麻烦的问题是：
Data Agent 到底怎么接企业数据？Agent 到底应该去哪找答案？
直接查 ERP、CRM 的业务数据库？调用系统提供的 API？去数仓查已经加工好的经营数据？还是从合同、价格政策和客户管理制度中找依据？
这几种方式都可以，但它们解决的根本不是同一种问题。
如果把企业 Data Agent 的数据访问方式拆开，大体可以归纳为四类：数据库直连、API 调用、数仓/数据平台、知识库/RAG。
真正成熟的企业 Data Agent 通常不是四选一，而是四种方式组合使用。
下面我们就从 Data Agent 最底层的数据访问问题开始，一层层拆开来看。
一、Data Agent 接企业数据，到底是在接什么？
传统软件访问数据，逻辑其实比较简单。系统提前知道自己要查哪张表、调用哪个接口、展示哪个字段，开发人员把流程写好，用户按照预设路径操作即可。
Agent 最大的不同，是用户的问题并不固定。
比如一句："最近库存是不是有点高？"
背后可能需要同时查看库存余额、销售出库、采购入库、未来订单、安全库存、库龄，以及企业内部对于"呆滞库存"的定义。
再比如："这个供应商最近是不是有风险？"
可能既要查采购系统中的准时交付率，又要看质量系统中的异常记录，同时还要结合合同条款、整改报告和企业自己的供应商分级标准。
所以 Data Agent 接企业数据，本质上不只是建立一个数据库连接，而是要解决三件事。
第一是数据在哪里。数据库、业务系统、数仓和文档分别承载什么内容？
第二是数据是什么意思。什么叫有效订单，销售收入怎么计算，客户等级如何划分？
第三是 Agent 可以做什么。只能读取数据，还是能够调用接口、创建任务、触发审批甚至修改业务状态？
这三件事如果没有提前设计清楚，Agent 接得越多，后续治理反而越复杂。
二、方案一：数据库直连——最快，但也最容易踩坑
最直接的一种方式，就是让 Data Agent 访问 MySQL、Oracle、SQL Server、PostgreSQL 等数据库。
用户提出问题以后，Agent 根据数据库 Schema 识别相关表和字段，生成 SQL，执行查询，再将结果整理成答案。
很多早期 Text-to-SQL 项目，本质上走的就是这条路线。
它最大的优势就是：上线快。
比如企业想快速验证一个库存分析 Agent，数据库本身已经存在商品、库存和出入库记录，那么给 Agent 开放一定范围的只读查询权限，就可以开始验证：
"哪些商品已经低于安全库存？""哪些 SKU 最近 60 天没有出库？""昨天新增了多少缺货商品？"
对于结构相对简单、业务规则也比较明确的问题，数据库直连确实很好用。
但一旦进入真实企业环境，问题也会马上暴露出来。
业务数据库不是为分析设计的
一套 ERP 可能有几百甚至几千张表。字段名可能是 biz_type、status_flag、order_detail_v2，一个完整业务对象还可能需要跨多张表才能还原。
开发人员知道这些字段是什么意思，不代表 Agent 天然知道。
所以 Agent 直接面对业务数据库时，经常遇到的问题不是"没有数据"，而是：数据很多，真正可理解的业务语义却很少。
SQL 正确，不代表业务答案正确
比如有人问："这个月新品实际卖了多少？"Agent 可能直接汇总订单金额。从 SQL 角度没有任何问题。
但企业真正统计新品销售时，可能要求剔除内部试销、赠品、取消订单和退款。于是代码正确，业务结果仍然可能错。
Agent 真正缺的并不是 SQL 能力，而是：企业自己的业务口径。
生产数据库也不能任由 Agent 查询
还有一个更现实的问题，就是性能和安全。如果 Agent 生成一个复杂 SQL，直接扫描生产库中数亿行数据，很可能影响正常业务。更不用说让 Agent 拥有 UPDATE、DELETE 这类写权限。
所以数据库直连更适合 Demo 验证、简单实时查询，或者放在只读副本、查询网关和严格权限控制之下使用。
它很好地解决了"Agent 能不能拿到数据"，但单靠这一层，很难解决"这些数据能不能长期稳定、准确、安全地给 Agent 使用"。
三、方案二：API——不一定适合大规模分析，但非常适合让 Agent"做事"
第二种方式，是不让 Agent 直接碰底层数据库，而是调用企业业务系统开放出来的 API。
例如 CRM 提供客户查询接口，ERP 提供订单状态接口，WMS 提供实时库存接口，OA 提供审批状态接口，工单系统提供创建任务接口。
它和数据库最大的区别在于：数据库暴露的是数据，API 暴露的是业务能力。
比如 Agent 需要查询某 SKU 当前可销售库存。如果直接查数据库，它可能需要自己理解现有库存、冻结库存、已占用库存和在途库存之间的关系。但如果 WMS 已经提供"可用库存查询"接口，那么复杂计算仍然由 WMS 自己负责，Agent 只需要知道什么时候调用这个能力。
这会让 Agent 的边界清晰很多。
更重要的是，API 能够让 Agent 从"回答问题"走向"执行动作"。
比如供应链负责人问："未来两周哪些核心物料存在断供风险？"
Agent 分析后发现有 5 种高风险物料。如果只接数据库，它最多告诉你是哪 5 种；如果同时接入采购系统、任务系统和消息接口，就可以进一步查询供应商最新承诺到货日期，创建采购跟进任务，再提醒对应负责人。
这时候 Agent 才真正从"知道发生了什么"，开始走到"协助完成下一步"。
不过 API 也有明显边界。它非常适合查询当前状态和执行具体业务动作，但如果要分析过去三年的客户订单、利润、回款、库存和采购变化，全部通过 API 一点点拉取，效率和维护成本都会变得很高。
这也是为什么企业 Data Agent 做到经营分析阶段后，通常还需要第三种数据源：数仓。
四、方案三：接数仓——企业经营分析最值得做的一层
如果 Data Agent 真正要进入企业经营分析，数仓往往绕不过去。
原因很简单。业务数据库中的数据，首先是为交易服务的；而数仓里的数据，是经过采集、清洗、转换和建模之后，专门面向分析使用的。
ERP、CRM、WMS、MES、财务系统的数据进入数仓以后，可以形成统一的客户、订单、产品、库存、供应商和利润主题。
这时候 Agent 面对的就不再是十几套系统、几千张底层表，而是一套相对清晰的数据资产。
比如管理层问："为什么最近重点客户收入还在增长，利润贡献却越来越低？"
如果让 Agent 自己去 CRM 识别重点客户，再去 ERP 找订单，去财务系统找成本和费用，最后自己把几套系统的数据拼起来，整个链路非常容易出问题。
但如果数仓已经把客户、订单、产品、收入和成本关系提前建好，Agent 只需要在统一的数据模型上继续分析。
这也是 Data Agent 数据架构里一个很重要的原则：
不要让 Agent 每问一次问题，都重新理解一次企业的数据世界。那些长期稳定、反复使用的数据关系，应该提前沉淀下来。
五、真正容易被忽略的，是业务系统到数仓这一段
说到这里，其实还有一段经常被 Data Agent 文章一笔带过：数据到底怎么进入数仓？
企业的数据不会自己跑进去。ERP 有自己的数据库，CRM 又是一套结构，MES、WMS、财务系统的数据格式也完全不同。
有些系统支持数据库读取，有些只能走接口；有些每天批量更新，有些又要求分钟级甚至实时同步。
所以真正开始建设 Data Agent 之前，企业通常还得先解决一个很基础的问题：怎么把分散的数据稳定地汇到一起。
比如同一个客户，在 CRM 里使用客户 ID，在 ERP 里使用客户编码；同一个商品，在电商、库存和财务系统里可能又是三套命名。
这些数据如果不先同步和整理，Agent 即使接上一个所谓的"统一数据平台"，底下依然可能是一团乱麻。
真正落地时，这一段通常需要数据集成工具来承接。
比如用 FineDataLink 把 ERP、CRM、MES、WMS 等系统里的订单、客户、生产和库存数据持续同步到数仓，在同步过程中完成增量抽取、字段转换和必要的数据处理。等数据先稳定汇到一起之后，再交给 Data Agent 分析，整个链路会比让 Agent 逐个直连业务系统清晰得多。
这其实也是很多 Agent 项目最容易低估的一层。AI 入口做得再漂亮，如果底下的数据每天还靠人导 Excel、复制文件、手工拼表，Agent 很难真正进入生产环境。
六、Agent 时代，为什么数据集成反而更重要了？
以前做传统分析时，数据链路里有些问题还能依靠分析人员人工处理。
ERP 某个字段有异常，分析师知道要修一下；CRM 里的客户编码换了，业务人员知道该对应到哪个客户；财务这个月统计口径变化了，做报表的人知道手工调整。
这些"经验补丁"，过去大量存在于人的脑子里。Agent 不知道。
一旦企业希望 AI 自动完成分析，这些原来依赖人工兜底的东西，就必须逐渐变成明确规则。
比如客户编码怎么统一，重复订单怎么处理，空值如何补齐，哪些订单状态需要剔除，数据多久同步一次，源系统字段发生变化后谁来发现。
所以企业真正要建设的，不只是一条"能跑通"的数据链路，还需要考虑这条链路能不能稳定运行。
现实项目里，例如通过 FineDataLink 建立 ERP、CRM、MES、WMS 到统一数据平台的同步任务以后，真正重要的不是"第一次把数据抽过来了"，而是后续能否持续增量同步、处理字段变化和异常，让上层 Data Agent 每次拿到的数据保持相对稳定。
从这个角度看，Agent 更像数据链路最上游的使用者。上层分析能做到什么程度，很大程度上取决于下面的数据管道有没有先铺好。
七、方案四：知识库/RAG——解决数据库回答不了的问题
前面几种方式主要处理的是结构化数据。但企业里大量真正重要的信息，其实并不存在数据库里。
比如合同、制度文件、产品手册、招投标资料、供应商整改报告、项目方案和会议纪要。这些内容更适合通过知识库和 RAG 交给 Agent。
它和数仓解决的问题完全不同。
数仓比较擅长回答：发生了什么、有多少、趋势怎么样。知识库则更适合回答：规则是什么、文件怎么规定、合同里怎么约定。
比如员工问："超过 50 万元的采购合同需要走哪些审批？"这个问题显然不应该去扫描采购事实表，而应该检索企业制度。
再比如："这个客户合同约定的付款周期是多少？"答案很可能就在 PDF 合同中。
所以知识库不是数仓的替代品，它们承担的是两类不同的信息。
八、真正有价值的，是把"数据事实"和"企业知识"放到一起
Data Agent 真正比传统查询工具有意思的地方，是它可以组合不同来源的信息。
比如财务人员发现某客户已经逾期 45 天，于是问："为什么这个客户还可以继续发货？"
数仓可以告诉 Agent：客户目前有多少应收、逾期多久、最近还有多少未发订单。
但要判断现在还能不能继续发货，还需要读取企业信用管理制度：逾期多少天应该限制发货？哪些客户可以例外？需要谁审批？
这样一次完整分析就可能变成：数仓查询事实 + 知识库读取规则 + API 确认实时状态或执行后续动作。
这时候 Agent 才开始真正发挥它作为"调度者"的价值。它不一定自己拥有所有数据，而是知道：这个问题应该去哪里查。
九、数据库、API、数仓、知识库到底怎么选？
如果一定要简单归纳，可以这样理解：
数据库适合底层实时明细。优点是直接、实时，适合快速查询，但业务语义较弱，对性能和安全要求也更高。
API 适合实时业务能力和动作执行。既可以查询业务系统当前状态，也可以让 Agent 创建任务、发起流程或者调用其他系统能力。
数仓适合稳定的跨系统经营分析。数据经过集成、清洗和建模以后，更适合做长期、可信、可复用的数据分析。
知识库适合企业非结构化知识。制度、合同、方案、说明书、会议资料都更适合放在这一层。
所以企业 Data Agent 真正的架构不是四选一，而是明确分工：数据库补充实时明细，数仓承担经营数据，知识库提供业务知识，API 承担动作执行。
十、一个完整的 Data Agent，实际会怎么工作？
比如供应链负责人问："这批订单为什么一直交不出去？"
一个成熟的 Data Agent 不会只生成一条 SQL。
它可能先从数仓查询订单交期、库存、生产进度和缺料情况，发现大多数延期订单都集中在同一种关键物料上。
随后通过采购系统 API 读取该物料最新预计到货时间，再从知识库中调取供应商历史整改记录和相关合同条款。
如果企业进一步开放任务系统，还可以继续生成异常跟进任务，分配给对应采购负责人。
而数仓里这些订单、库存、采购和生产数据，本身可能就是持续从 ERP、MES、WMS 等系统同步而来的。
例如企业原本就已经通过 FineDataLink 跑着几条数据同步任务，把不同业务系统的数据汇到数仓，那么 Agent 需要做的就不是重新连接每一套业务系统，而是直接复用现有的数据链路。
整个过程其实可以概括为：
业务系统产生数据 → 数据集成 → 数仓沉淀 → Agent 分析 → API 执行动作。知识库则在其中补充规则、合同和业务背景。
到这一步，Data Agent 才真正从一个"会聊天的数据查询工具"，变成企业数据和业务能力的智能调度入口。
十一、很多 Data Agent 项目最大的坑，是让模型直接理解所有原始数据
不少项目刚开始的想法非常简单：企业有很多数据，大模型又很聪明，那就把数据直接给它。
真正做起来，往往问题不少。
因为企业数据最麻烦的从来不是单纯"量大"，而是：复杂、分散、历史包袱重。
同一个客户可能存在多个编码，同一个指标不同部门可能采用不同定义，订单状态几十种，底层表里还充满各种历史字段。
如果用户每提一个问题，都让大模型从头理解一次这些关系，准确率很难长期稳定。
更合理的原则应该是：能提前确定的事情，就不要每次都让大模型猜。
比如订单、库存、客户这类数据长期都要使用，就先建立稳定的数据同步链路；能通过数仓建模确定的数据关系，提前建好；能够统一的指标，提前统一；能够整理成知识库的制度和业务规则，也提前沉淀。
数据集成层同样如此。如果 ERP、CRM、MES 里的数据每天都要进数仓，与其每次由 Agent 临时读取，不如通过固定的数据同步任务把这条链路先跑稳定。比如用 FineDataLink 配置增量同步和转换规则，本质上是在把原本需要 Agent 临时处理的数据工程工作，提前固化到稳定的数据管道里。
Agent 真正应该发挥作用的，是：理解动态问题、规划分析路径、选择数据源和调度工具。而不是每次都重新做最基础的数据搬运工作。
十二、企业落地时，应该从哪里开始？
如果企业现在准备做 Data Agent，我反而不建议第一天就想："把所有系统都接给 AI。"
更现实的做法，是从一个明确场景开始。比如库存分析。
先确定这个场景需要订单、库存、采购、出入库和商品主数据，再找到这些数据目前分别在哪些系统。
如果现在每天仍然需要人工导表，那么第一步甚至不是做 Agent，而是先把数据链路跑通。
比如订单在 ERP，库存和出入库在 WMS，采购信息又在另一套系统，就可以先把这些数据通过固定同步任务汇到统一平台。这里完全可以用 FineDataLink 这样的方式去做数据抽取和增量同步，先让订单、库存和采购数据按稳定频率进入同一个数据环境。
接下来再处理商品编码、订单状态、库存口径这些问题。这些基础工作完成以后，再让 Agent 去回答：
库存为什么上涨？哪些 SKU 存在缺货风险？是采购过量还是销售下降？
如果进一步需要读取库存管理制度，再接知识库；如果要通知采购人员处理，再接任务或消息 API。
这样的路径有一个很大的好处：每接一类数据、增加一个工具，都是为了回答一个真实的业务问题。而不是为了"我们要做 Data Agent"，先把整个公司的系统全部接进去。
写在最后
Data Agent 接企业数据，看起来像一个技术连接问题。真正做下去以后，会发现它其实重新暴露了一遍企业过去的数据基础。
数据库保存底层事实，API 暴露业务能力，数仓承载经过治理的经营数据，知识库保存制度、合同和经验，而中间的数据同步和整合，则负责把原本散落在不同业务系统里的信息持续汇到一起。
这也是为什么企业真正开始做 Data Agent 以后，经常会重新重视过去看起来没那么"性感"的数据工程。
因为 Agent 最终需要的数据，不是今天人工导一份 Excel 给它，而是能够长期、稳定、按统一规则持续更新的数据。
企业原本如果就在通过 FineDataLink 之类的工具建设 ERP、CRM、MES、WMS 到数仓的数据链路，这些基础能力完全可以直接成为 Data Agent 的数据来源，而没有必要为了 AI 再重新造一套数据接入体系。
所以做 Data Agent 最容易走错的一条路，就是：先把所有原始数据扔给模型，再期待 AI 自己理解企业。
真正更可行的路径恰恰相反：先把能确定的数据同步规则、数据关系、指标口径和业务知识沉淀下来，再把那些无法提前穷举的问题交给 Agent。
因为企业 Data Agent 最终拼的，从来不只是模型有多聪明。还要看：企业有没有能力把分散的数据稳定地接进来、整理好，再交给 AI 使用。
从这个角度看，Agent 时代并没有让数据集成变得过时，反而让它重新变成了一项非常基础、也非常关键的能力。
过去的数据集成，是为了让人更方便地使用数据；现在，还要进一步让 AI 能够稳定地使用企业数据。
