很多企业第一次做 Data Agent最先讨论的往往是一个问题大模型选哪一个——DeepSeek、GPT、Claude还是企业自己的私有模型但项目真正进入企业内部以后很快就会发现模型反而没有想象中那么难选。更麻烦的问题是Data Agent到底怎么接企业数据Agent到底应该去哪找答案直接查ERP、CRM的业务数据库调用系统提供的API去数仓查已经加工好的经营数据还是从合同、价格政策和客户管理制度中找依据这几种方式都可以但它们解决的根本不是同一种问题。如果把企业Data Agent的数据访问方式拆开大体可以归纳为四类数据库直连、API调用、数仓/数据平台、知识库/RAG。真正成熟的企业Data Agent通常不是四选一而是四种方式组合使用。在正式展开之前我整理了一套《“AI”场景落地实战白皮书》里面涉及企业多源数据接入、数据同步、数据开发以及数据链路建设等内容。对于正在规划Data Agent、数仓或统一数据平台的企业来说可以先参考其中的数据架构和落地思路再反过来看Agent应该接哪些系统、哪些数据应该提前沉淀。需要自取https://s.fanruan.com/hti40复制到浏览器下面我们就从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、数仓、知识库到底怎么选如果一定要简单归纳可以这样理解数据库适合底层实时明细。优点是直接、实时适合快速查询但业务语义较弱对性能和安全要求也更高。PI适合实时业务能力和动作执行。既可以查询业务系统当前状态也可以让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能够稳定地使用企业数据。
