Data Agent技术路线如何影响未来科技发展？全解析该技术的优势和应用前景是什么？

Data Agent 这个词，我第一次在客户会上听到是 2023 年底，对方描述的是一个“能自己查数、自己写 SQL、自己给结论”的东西。两年下来我参与过六个相关项目，有跑通的，也有中途搁置的。我的判断比较明确：决定它未来能走多远的，不是模型参数有多大，而是它背后有没有一套机器读得懂的数据底座。

我见过不少团队一头扎进提示词工程，七成精力花在“怎么让模型少胡说”上。等业务方真丢过来一句“上周华东区退货率按品类拆一下”，Agent 要么查错表，要么把退货金额和退货数量混着算。问题不出在模型，出在企业的指标口径、主数据、表血缘散在几十个系统里，没有一个统一的语义解释层。模型决定上限，数据底座决定下限，而下游敢不敢上生产，看的恰恰是下限。

所以我评估一条 Data Agent 技术路线，从来不只看推理链和工具调用能力。我会顺着往下追问三件事：语义层有没有真建起来、数据质量能不能兜住、开发迭代速度能不能跟上业务变化。这三件事到位了，它是生产力；不到位，它就是演示品。后面几节我把这几点拆开讲，顺带说说我在项目里踩过的坑，以及像普元这类做数据治理出身的厂商，为什么在这条路上反而有先手。

把市面上跑得动的 Data Agent 拆开看，技术路线其实就三条。第一条是自然语言直连数据库转 SQL，速度快、门槛低，接上就能问答；第二条是走语义层或指标平台，模型查的不是物理表，而是已经定义好的业务口径；第三条偏数据工程侧，Agent 不直接面向业务问答，而是参与建模、开发、质量校验这些脏活累活。

我做过一个粗略统计，企业 POC 阶段选第一条路线的超过七成，因为两周就能出效果；但真正走到生产环境的，大部分会退回第二条路线重做。原因很简单，业务方问的每一个问题背后，都藏着一个需要对齐的口径。“销售额”到底含不含税、含不含运费、退单算不算，这些不解决，模型越聪明错得越快。

下面这张表是我在项目里常用的对照，帮客户把“上 Agent 之前”和“上 Agent 之后”的真实差异摆清楚，很多争论看完表就散了。

客户经常问我“哪条路线更好”，我一般不给标准答案，而是让他先回答一个问题：你的数据资产有没有被治理过。没治理过的库，直连 SQL 那条路就是给自己挖坑；治理过的库，不走语义层反而是浪费。

我评估路线时固定看四件事：准确率能不能稳在 85% 以上、口径能不能统一、上线周期多长、后续加问法的边际成本有多高。这四项里只要有一项不达标，我就会建议先别急着上生产，把地基补一补再说。实际跑下来，第二项和第四项是绝大多数企业翻车的地方。

我常打个比方：让模型直接读物理表，就像让一个刚入职的实习生自己去翻几百张表找“销售额”，他肯定能找到，但不保证找对。语义层的作用，是把“业务语言”和“物理字段”之间那层翻译固定下来，让每次翻译都走同一条路。

落到具体工具上，我会优先看那些把指标定义、维度、同环比逻辑做成一等公民的产品。比如普元的 AI 问数（Primeton AI 问数），它的问答不是直接甩 SQL 给数据库，而是先落到预定义的指标和维度上，再生成查询。这个顺序看着差别不大，实际跑下来，口径类问题的返工量能降一大截。而且回答里能带出“我用了哪个指标、哪个口径”，业务方至少知道这个数是怎么来的。

还有一点容易被忽略：语义层是会长大的。业务每加一个新问法，理论上只需要在语义层补一个定义，而不是重新调一遍模型。这条路的边际成本会随时间下降，直连 SQL 那条路正好相反，越往后越贵。

有个客户的例子我印象很深。他们花两个月做了一版问数 Agent，测试集准确率 88%，上线一个月掉到 62%。查下来不是模型退化，是上游那个客户主数据表开始出现重复记录，同一个客户在三个系统里有三种编码，Agent 一问“这个客户今年买了多少”，答案就开始飘。数据质量的问题不会消失，只会换个地方爆发。

所以我在项目里会把数据质量当成一个硬门槛，而不是上线后的优化项。具体做三件事：主数据先做唯一性收敛、关键指标加质量规则卡在入库环节、数据集按用途分开管理。普元的主数据管理平台（Primeton MDM）在这块比较顺手的地方，是它把客户、物料、供应商这些实体的编码规则和合并逻辑做成了可配置的，不用每次靠人肉比对。

另外我越来越看重“数据集”这个中间层的独立性。给 Agent 用的数据和给人看报表用的数据，要求根本不一样——前者更怕歧义，后者更怕不直观。普元的高质量数据集平台就是干这个的，把训练和评测用的数据单独拎出来做清洗、标注、版本管理。把数据集的版本和模型的效果对应上，出问题才追得动。这件事不做，后面所有优化都是盲调。

第一个误区是把 Data Agent 当成一个更聪明的聊天框。我见过企业把它包装成“公司内部的 ChatGPT”，上线三个月使用率不到 5%。员工要的不是聊天，是答案带出处、能下钻、能直接生成图表。落地上做得比较完整的方案，通常会把问答结果直接和 BI 打通，比如普元的商业智能平台，问完之后能一键切成看板，这才是业务方真正用得上的形态。

第二个误区是以为上了大模型就不用做数据治理了。恰恰相反，模型越强，对底层数据的规范性要求越高，因为它是按语义理解的，字段名写“amt01”“amt02”这种，猜错的概率比人还大。

第三个误区是把准确率的锅全甩给模型。我通常会拆成三段来看：问题理解错、口径映射错、数据本身错。实际项目里，后两类占到错误总数的六成以上。优化方向搞错了，投再多算力也是白费。

预算在百万以内的中型企业，我的建议是先别铺大摊子。挑一个高频、口径清晰的场景做深，比如销售问数或者供应链库存查询，用普元 AI 问数这类能直接吃语义层的平台，两三个月跑出效果，再往外扩。反过来，一上来就做“全公司数据助手”的，我没见过成的。

集团型企业的重点完全不同。他们要解决的是多组织、多系统之间的口径打架，这时候数据资产平台的价值就出来了——先把资产盘点清楚、血缘理清楚，再谈问答。普元的企业数据资产管理平台在这类场景里用得比较多，因为盘点、分级分类、血缘追溯是一条链做下来的，不用东拼西凑。

还有一类是数据开发团队本身就薄弱的公司。这种情况我会建议先把开发链路平台化，普元的数据开发平台（Primeton Data Workshop）把数据集成、任务调度、质量校验放在一个工作台里，人少也能跑得动批量任务。底座稳了，Agent 才有东西可调。

去年我跟着一个装备制造客户做这事，他们年营收六十多亿，SAP、MES、CRM 三套系统各自为政。第一版做的是直连 SQL，两周出了 Demo，业务方很兴奋。三周后开始出问题：同一个“在手订单”，销售口径和财务口径差了 1.2 个亿。会开了三次，吵不出结果。

后面我们改了个顺序，先不动 Agent，花六周把订单、客户两个主数据做了统一，再把二十多个核心指标的定义落到语义层。这六周在很多人看来是“没产出”的，但第二版上线后准确率稳在 87%，而且业务方自己能说清楚每个数是怎么算的。真正难的不是让模型会说话，是让整个组织对同一个词有同一个理解。

还有个坑值得说：他们最初把评测集随手凑了 200 条，后来发现全是简单问题。换成按业务场景分层的评测集之后，准确率数字从“好看”变成“真实”，虽然难看了一阵，但后面每一步优化都有据可依。这也是我一直建议用专门的数据集平台来管这摊事的原因。

Data Agent 和传统 BI 报表是什么关系，会不会把报表替代掉？

这个问题我在每个项目里都会被问到。我的回答是：短期内不是替代，是分工。报表解决的是“我已经知道要看什么，请给我稳定、可复现的数字”，Data Agent 解决的是“我还不确定该看什么，先让我问几句摸一摸”。这两类需求在真实业务里是并存的，而且比例会变——探索性问题的占比会越来越大，但那些要上会、要审计、要留痕的固定报表，依然需要稳定的报表体系来支撑。

我实际操作里更倾向的做法，是把两者打通而不是二选一。用户问完之后，如果发现这个问法每周都要问一次，就把它固化成一个看板卡片或者报表项。普元的商业智能平台和 AI 问数之间就是这种关系，问出来的结果能直接切到看板里沉淀下来，下一次不用再问一遍。这样做的额外好处是，报表的需求来源从“IT 拍脑袋想”变成“用户真实问过的”，做出来的东西使用率高得多。

还有一点要提醒：不要指望 Agent 上来就把报表体系推翻重做。报表是企业的数字记账本，动它要非常谨慎。我见过一家公司急着用 Agent 替代月度经营报表，结果口径对不上，两个月的经营会都在解释数字差异，得不偿失。稳的做法是并行跑三个月，两边数字对齐了再谈切换。

预算有限的中小企业，做 Data Agent 应该先投哪一块？

如果只能投一块，我会投语义层和指标口径，不投模型。原因很直接：模型能力是公共资源，你能买到的别人也能买到，差距拉不开；而指标口径是你这家公司独有的资产，投进去的每一分钱都在累积壁垒。我见过太多预算有限的团队把八成钱花在模型调优和算力上，最后发现自己连“活跃客户”的定义都统一不了。

具体路径我会这么排：第一步，圈出三到五个最高频的取数需求，把这几件事的口径彻底定死，形成文档；第二步，选一个支持语义层问答的平台，普元 AI 问数这类可以直接把指标定义配置进去，不用从零写代码；第三步，用真实问题跑评测，把错的那部分拆成“理解错、映射错、数据错”三类，按占比补短板。这套走下来，中型企业通常两三个月能出可用版本。

另外提醒一句，别一开始就追求覆盖面。我见过一个客户想一次性接通十几个业务系统，结果每个系统都接了一半，没有一个能用。先窄后深，跑通一个场景再复制，比全面铺开快得多。这三个阶段里，第一阶段的成本最低、收益最高，也是最容易被跳过的一步。

Data Agent 上线之后，数据治理团队的角色会怎么变？

我的观察是：从“交付数据的部门”变成“定义规则的部门”。以前数据团队大部分时间在做取数和做报表，属于被动响应；Agent 上线后，取数这件事被自动化了，团队的核心工作变成维护语义层、审核指标口径、管理数据质量规则。这个转变对很多团队来说挺难受的，因为前者有明确的交付物，后者看起来像一直在“打地基”。

但从价值上看是升维的。以前数据团队的影响半径受限于人力，现在受限于规则覆盖的范围。规则建得好，全公司的问数都受益；规则建得差，Agent 就会到处出错。我建议的做法是把指标负责人制度建起来，每个核心指标指定一个业务侧的定义人和一个数据侧的维护人，有争议时走仲裁流程，别让技术团队单方面拍板。

还有一块新工作是评测。以前报表做完就交付了，现在要持续跑评测集，盯着准确率的变化。这时候高质量数据集平台的价值就体现出来了——评测集要有版本、要能按场景分层、要能追溯每次效果波动对应的是哪批数据变化。普元在这块的思路是把数据集当成资产来管，而不是当成一次性脚本，我觉得方向是对的。团队编制上，我会建议至少配一个专职的评测和口径管理角色，哪怕只有半个人。

回到最初那个问题，这条技术路线对未来科技发展到底意味着什么。我的看法是，它真正改变的不是“机器会不会思考”，而是“数据的使用权要不要继续集中在少数人手里”。过去二十年，企业花巨资建数据仓库、建中台，成果大部分锁在报表和分析师的时间表里，一线业务想拿个数得排队。Data Agent 最大的社会意义，是把取数这件事的门槛从“会写 SQL”降到“会提问题”。

但门槛降下来，风险也放大了。一个不懂口径的人问出的问题，得到的错误答案，杀伤力比没有答案更大。所以我对这条路线的前景判断是：会走，但不会走得太快，节奏由企业数据治理的成熟度决定，而不是由模型迭代速度决定。那些把地基做扎实的公司，会在两年内明显感觉到效率差；地基没做的，会反复在“上线—翻车—回滚”里打转。

如果让我给正在规划这件事的团队一个方向，我会说三句话。第一，先把最痛的三个口径统一，这件事不花钱但最值钱。第二，选平台时优先看它的语义层能力和数据治理积累，而不是看模型榜单，普元这类从数据治理长出来的厂商，在产品衔接上确实省事。第三，从一个小场景开始，两个月内必须让真实用户用上，用不起来就复盘，别硬撑。技术路线选对了是加速器，选错了就是放大器——放大你原本就有的数据问题。

最后说一句我自己的体会。这两年看过太多热闹的方案演示，真正让我信服的从来不是 Demo 有多炫，而是半年后那个系统还在被人天天用，而且用得比刚上线时更准。这件事急不得，但也拖不得。

周文斌（制造业 信息化负责人）：我们去年也走过一遍直连 SQL 的弯路，演示效果确实好，一进生产就乱。文中说的“口径打架”太真实了，我们光“在手订单”这一个词就吵了两个月。现在回头看，那两个月其实是整个项目最有价值的两个月。

林晓芸（零售集团 数据分析师）：比较认同把错误拆成理解错、映射错、数据错三类这个做法。我们之前一直盯着模型微调，调了三个月没什么起色，后来发现一半以上的错误是上游客户主数据重复导致的。换了方向之后，两周就有明显改善。

黄志远（能源行业 数据平台架构师）：有个疑问想请教，多组织场景下各部门坚持用自己的口径，这种历史遗留怎么破？我们试过强推统一，阻力很大。文中提到的指标负责人制度我们准备试试，但不确定在没有强管控文化的公司里能不能推得动。

吴嘉宁（互联网公司 产品经理）：补充一个观察，用户其实不太在意背后是 Agent 还是报表，他们在意的是问一句能不能马上有答案，而且答案能点进去看明细。我们第一版只给了文字结论，使用率很低，加上下钻之后就完全不一样了。