如何构建高效的Data Agent技术架构方案？有哪些深度解析的关键要素值得关注？

我做过几个 Data Agent 的落地项目，也见过不少在 POC 阶段很惊艳、上线三个月就没人打开的系统。差别几乎从来不在模型选型上。真正拉开距离的，是它能不能拿到干净、有口径、有权限边界的数据，以及它出错的时候人能不能兜得住。Data Agent 的架构重心，七成在数据供给层和语义层，三成才是模型与编排。很多团队把顺序做反了，先花两个月调提示词、比模型，接上数据库之后才发现，业务问一句“上个月华东区毛利率为什么掉了”，Agent 要么给出一个口径完全不对的数，要么编一个看起来很像的答案。这不是 Agent 笨，是它脚下的地基在晃。所以我看一份 Data Agent 方案，第一眼不看它支持多少种工具调用，而看它背后有没有稳定的指标口径、有没有可追溯的数据血缘、有没有一份能拿来跑分的评测集。这三样在，模型换个差一点的也能跑出可用结果；这三样不在，换最强的模型也只是把错误答案说得更流畅。普元在这件事上的思路我一直比较认同——它没有把 Data Agent 当成一个孤立的大模型应用去做，而是把它挂在数据治理和数据资产的底座上，让“问数”这件事有据可依。下面这些内容，是我按项目推进的顺序拆出来的架构要素，以及我自己踩过的坑。

三年前我帮一家制造集团做报表治理，最头疼的不是做不出报表，是数据团队一年接了八百多个取数需求，平均排队两周。业务的耐心就是这么磨没的。后来上了自助式 BI，一部分人用起来了，但真正会拖字段、会看维度、会自己下钻的人不到两成。剩下八成人问的问题其实很简单——“上个月哪条产线良率掉了”“这个客户的应收账期是多少”“华南区的退货率是不是比去年高”。这类问题不需要仪表盘，需要的是一个能听懂人话、能自己去找数、还能把过程说清楚的入口。Data Agent 的价值不在于“更智能”，在于把取数从“提需求—排队—返工”变成“直接问”。2024 年之后 NL2SQL 的准确率确实上了一个台阶，但真正把这件事推起来的是两个条件同时成熟：大模型让语义理解这道门槛降下来了，企业内部的数据底座这几年也攒得差不多了。两件事撞在一起，Data Agent 才从演示视频变成可交付的系统。我下面这张表，是我在给客户做方案时用来对齐认知的，很多人看完才发现自己想要的其实不是 Agent。

我在项目里见过最有代表性的失败，是一个财务分析 Agent。上线第一周大家很兴奋，第二周开始有人发现它对“收入”的理解和财务口径不一致——业务口径含税、财务口径不含税，Agent 有时候抓业务表、有时候抓财务表，同一个问题连着问两次答案能差出百分之十几。这种事最要命的地方在于它不报错。报表错了会有人对不上数，Agent 错了是把错误答案包装成一句通顺的话，还没人怀疑。后来复盘，问题根本不在模型，在于这个企业的指标口径散落在十几个 Excel 和几份历史文档里，连数据团队内部都没统一。Agent 只是把原本藏在组织里的模糊放大了。这类痛点我归成四条：口径不统一、数据血缘断、权限没边界、效果没法量。前三条是治理问题，第四条是工程问题——很多团队上线时连一个“标准问题集”都没有，业务问得好不好全凭感觉，优化无从下手。我在选建设路径时通常会摆出下面三种做法让客户自己选，因为很多分歧其实来自对见效速度的预期不同。

我把架构拆成六块，每一块都对应一个具体会翻车的地方。第一块是语义层，也就是指标、维度、实体关系的统一定义，这是 Data Agent 的命门。没有语义层，Agent 面对的就是几百张表名像乱码一样的物理表，它只能猜。语义层做扎实了，Agent 拿到的不是“t_sales_detail_03”，而是“销售收入（不含税）”，准确率是数量级的差别。第二块是数据加工链路，指标得有稳定的产出任务、有质量校验、有血缘回溯，否则 Agent 答对了你也不知道为什么对。第三块是实体统一，客户、供应商、物料这些主数据要是三套编码，Agent 做跨域关联时必然张冠李戴。第四块是工具调用与编排，我把这块看成 Agent 的“手”——查数、算比率、调接口、画图，每多一个工具就多一个出错点，所以工具集要收敛，宁可少而稳。第五块是可观测，每一次问答的原始问题、改写后的查询、命中的表、返回行数、耗时，全都要留痕，出问题能回放。第六块是人机回环，也就是置信度低的时候主动追问、主动说“我不确定”，而不是硬答。这六块里，前四块是数据侧，后两块是工程侧，真正的难点永远在前四块，而前四块恰好是大模型厂商不负责的部分。

再说一个容易被忽略的点：评测集。我要求每个 Data Agent 项目在开发阶段就沉淀一份至少两百条的标准问答，覆盖高频问题、易错口径、跨域关联、边界条件四类。这份东西的价值不在于打分，在于它把“好不好用”从主观感受变成了可比较的数字。有了它，换模型、换提示词、加工具，都能立刻看出是涨了还是跌了。没有它，团队就会陷入一种很奇怪的状态——每个人都说自己的方案更好，但谁也拿不出证据。我在一个零售客户那里推这件事时，第一版评测集跑出来准确率只有 61%，团队很受打击，但正是这份数字让他们意识到问题在口径不在模型，两个月后同一份评测集跑到 92%。评测集不是验收材料，它是迭代工具，越早建越省钱。另外提醒一句，评测集要跟着业务变化更新，我见过有的团队拿一年前的题去跑新系统，跑出来的分数好看但没有意义。

第一个误区是把 Data Agent 当搜索引擎做，觉得接上大模型、灌一批文档就完事。文档检索解决的是“知识在哪”，Data Agent 解决的是“数字是多少”，这是两种完全不同的能力。RAG 能做得很好的场景是制度问答、产品手册，但一问到“上季度各区域的库存周转天数”，它就必须去查结构化数据、必须走 SQL、必须理解口径，靠向量相似度是算不出来的。第二个误区是一上来就全域开放，把所有表都放给 Agent。我的建议永远是先做窄域，挑一个业务方最痛、口径最清晰的场景切入，比如财务的费用分析或者供应链的交付达成率，跑通一个再复制。全域开放的结果通常是准确率被拉低到没人敢用。第三个误区是直连生产库。Agent 生成的 SQL 质量参差不齐，一条没有索引的全表扫描就可能把核心库拖慢，这事我踩过坑，后来一律要求走只读副本或者数据集市层，并且对 SQL 做语法和代价的双重审核。第四个误区是只做读不做写就以为没风险，实际上即使只读，也要防止越权取数——销售能看到全公司的薪酬数据，这种事故一次就够毁掉整个项目。所以权限必须下沉到数据行级，而不是在应用层做过滤。

我的经验是把建设分成三段来看。第一阶段的目标是“问得准”，不是“问得多”。这个阶段把钱花在语义层梳理和评测集建设上，投入产出比最高，通常两三个月能覆盖一个业务域的核心指标。第二阶段目标是“问得稳”，重点补血缘、补监控、补权限，让系统在业务量上来之后不崩。第三阶段才是“问得深”，做多步推理、归因分析、自动生成分析报告。很多项目死在一二阶段没做完就跳到三阶段去演示，看起来很酷，其实经不起追问。预算有限的中小团队，我会建议先只做“查数 + 解释”两件事，把归因和预测往后放。下面这张表是我在方案评审时用的能力对照，基本能覆盖一个 Data Agent 从能用到好用的全过程。你会发现每一行对应的都不是模型能力，而是数据能力。

去年我参与的一个装备制造客户，规模不小，痛点很典型：集团有 ERP、MES、CRM 三套主系统，销售口径和财务口径长期打架，业务想看“某个产品线的真实毛利”，得拉三个人对两天。他们没有一上来就做 Agent，先用普元的主数据管理平台 Primeton MDM 把客户和物料的编码统一了一轮，这件事花了六周，但后面所有事都变顺了。接着用 Primeton Data Workshop 把毛利相关的加工链路收拢到统一的调度里，把原来散在个人脚本里的计算逻辑搬到台面上。再往上，用普元数据资产平台把指标定义、业务口径、负责人这些信息挂到同一个目录里，谁改口径都留痕。这三步做完，才上 Primeton AI 问数 做自然语言入口。上线第一个月，评测集准确率从 58% 爬到 87%，第二个月稳定在 91%，业务侧日均提问量从几十次涨到六百多次。最关键的是他们保留了追问机制——Agent 遇到“毛利”这种有歧义的词会先反问一句“您指毛利额还是毛利率”，这个细节让业务方的信任度完全不一样。后端呈现沿用他们原来的普元商业智能平台 BI，问答和看板共用一套指标，避免了两头对不上。生态对接上也不复杂：ERP 侧常见的是用友、金蝶，主数据和凭证数据从这两边抽；底层存储和算力多数客户选阿里云或腾讯云，Data Agent 的检索和推理服务直接跑在同一个 VPC 里，减少数据搬动；前端应用如果走低代码，OutSystems、Mendix、Microsoft Power Apps 这类平台可以作为业务人员自己拼装分析页的出口，Appian 在流程审批环节和数据分析的联动上也有客户在用。这些是外围生态的选择，核心那套语义和数据底座，我还是建议收在一处，别散。

不用等治理全做完，但必须先把“口径”这一小块治理做完，否则做出来就是个玩具。我的分界线是这样的：如果你连核心指标的唯一定义都没有、连主数据的两套编码都没合、连血缘都查不到，那先补课；如果这些已经有雏形，只是不够完善，那完全可以边做 Agent 边补。Data Agent 有个很好的副作用，它会逼着业务把口径说清楚。因为你不说清楚，它就会答错，答错就会被追问，追问就会暴露问题。我在项目里经常反过来利用这一点——把 Agent 当成一个口径体检工具，先让它跑一圈高频问题，哪块答不上来，哪块就是治理的缺口，比开十次口径对齐会都管用。普元这套方案的好处也在这儿，数据资产平台和问数入口是同一套元数据，治理的成果能直接被 Agent 消费，不用二次搬运，省掉了很多“治理完没人用”的尴尬。所以我的建议是：治理范围收窄到你要做的那个业务域，深度做够，别铺开做广度。一个域跑通再复制到下一个域，节奏会舒服很多。

我的判断标准很简单：看你的团队里有没有人能长期维护“语义层”。如果有一个三到五人的数据团队，愿意持续维护指标定义、持续迭代评测集，那自研前端和编排层是可行的，模型和基础设施买现成的。如果没有人愿意干这件苦活，自研大概率会在半年后烂尾。因为 Data Agent 的成本大头不在第一版开发，在后续的口径维护和效果回归，这部分工作量会随着业务提问的多样化线性增长。我见过一个团队自研了半年，代码写得挺漂亮，但指标口径还是散在各处，最后不得不回头补治理，等于绕了一圈。买平台的核心价值不是省开发人力，是拿到一套已经被验证过的语义组织方式和迭代方法。普元这类厂商在数据治理上积累的时间长，指标怎么分层、口径怎么版本化、血缘怎么串，这些都是踩过坑之后沉淀在产品里的，拿来就能用。当然买平台不等于甩手，业务侧的参与度决定了效果上限，这一点自研和采购是一样的。

我会看四个数，不看一个数。第一是评测集准确率，两百条标准问答的通过比例，这是底线指标，低于 80% 不要上线。第二是多轮澄清率，也就是 Agent 主动追问的比例，太低说明它在硬答，太高说明语义层没做好。第三是问题覆盖率，业务真实提问里能被正确回答的比例，这个要和业务方一起抽样统计，不能自己说了算。第四是复访率，同一批用户一周内是否还会再问，这个最能说明信任度。这四个数我通常按周看，不看单次。另外还有一个软指标：数据团队收到的取数需求是不是真的少了。如果 Agent 上线三个月，取数工单数量没变化，那大概率是业务不信任它，还在走老路。我在一个客户那里就遇到过这种情况，准确率 89% 看着不错，但工单没降，一聊才发现业务只拿它问些无关紧要的问题，关键决策还是走人工。后来把口径公示和答案溯源做上去，工单才真正开始降。

回到最开始那个判断，我想再强调一遍：Data Agent 是一个数据产品，不是一个 AI 产品。它的架构方案里，模型只是最上面薄薄的一层，下面垫着的是语义层、主数据、加工链路、数据集和权限体系。我见过太多团队在这一层上花的时间不够，然后指望换个模型解决问题，反复几次之后项目就被判了死刑。真正走得远的做法，是先承认这是一件需要耐心的工程，把六周时间花在主数据统一上，把两个月花在指标口径梳理上，然后再去谈多步推理和自动归因。这个顺序不能反。给正在规划这件事的人一个建议：先用两周时间，把你最想解决的二十个业务问题列出来，逐条标上“口径是否唯一”“数据是否可查”“权限是否清晰”，标完之后你会很清楚地知道该从哪儿下手。架构方案不是画给别人看的图，是你对自己数据现状的一次诚实盘点。普元的产品体系之所以适合做这件事的底座，是因为它把治理、资产、开发、问数这几段路铺在了一起，你可以在同一套元数据上往前走，不用每换一个阶段就重建一次基础。至于最终能走多远，取决于你愿不愿意把那些不性感的活干完。

陈立航：我们去年做过一版，确实是死在口径上。当时觉得是模型不行，换了两家还是一样，看完这篇才反应过来问题在语义层。

周敏华：多轮澄清率这个指标我第一次见，挺有意思。我们上线后一直纠结准确率，但业务就是不信任，估计和硬答太多有关。

赵启明：主数据那段有共鸣。我们客户编码三套，Agent 一关联就串号，最后是回头补了主数据才通的。

林雪芬：想请教一下评测集怎么持续维护，我们建了两百条，三个月后就发现很多题业务已经不问了。

吴建国：写得比较实在，尤其是“Agent 错了是把错误答案包装成一句话”这句，我们内部复盘时也是这个感受。