Data Agent技术路线的关键选择是什么？如何做出最优决策以提升效果？

Data Agent 这件事，我过去一年多跟了六七个项目，从 POC 一路陪到上线运维。我越来越确信一个判断：这类系统的效果上限，八成由数据供给决定，两成才是模型和编排。很多团队一上来就纠结用哪个大模型、要不要自研 Agent 框架、要不要接 MCP，方向其实偏了。我见过的失败案例里，几乎没有一个是”模型不够聪明”导致的，绝大多数是把一个大语言模型直接怼到几十张业务宽表上，指望它自己理解什么叫”有效订单”什么叫”活跃客户”。模型再强，也补不上语义层的窟窿。

所以我的核心判断是三点。第一，技术路线的第一选择不是 Agent 框架，而是语义层放在哪、由谁维护。第二，数据集质量要能做成流水线，而不是每次上线前临时捞数、临时对口径，这件事没有工程化手段撑着，第二个月就开始腐化。第三，评估体系要前置，先有可回归的测试问题集，再谈效果调优，否则所有人都在凭感觉说”好像准了一点”。这三点想清楚了，模型选型反而是最不用纠结的一环——国产模型这两年迭代速度很快，切换成本也在下降。真正的护城河是你自己的指标资产和数据资产，不是调用哪家 API。

我把最近两年接触的项目按切入点分了个类，发现有明显的规律。从语义层和数据资产切入的团队，首版上线周期不一定最短，但上线三个月后的留存和使用频次明显更高。反过来，直接做对话入口、把宽表扔给模型的团队，POC 阶段往往惊艳，演示效果拉满，可一旦业务方开始问”为什么这个月的数跟上个月对不上”，项目就停在那里了。这不是技术问题，是治理问题被推迟了。

说白了，Data Agent 的输入不是数据库，是被定义过的指标和维度。业务方嘴里说的”大客户”和你表里的 customer_level 字段，中间隔着一整套口径约定。这部分工作绕不过去，只是早晚的问题。早做，它沉淀成资产；晚做，它变成事故。

我把市面上能跑通的技术路线归成三类：语义层优先、数据集优先、编排优先。它们不是互斥的，但一定有个先后顺序，而这个顺序决定了你半年后的返工量。语义层优先的路子，前期慢，需要业务和 IT 一起把指标定义吵明白，可一旦建成，后面加场景就是加配置。数据集优先适合场景高度聚焦的团队，比如只做经营分析问答，那把 Top 50 的问题和数据范围打磨透，效果能很快出来。

编排优先最容易吸引技术团队，因为有意思、有挑战、能发论文。但我实话讲，如果工具层拿到的数据本身就是错的，编排做得再精巧也是把错误放大。多步推理会把一次口径偏差传导成三次。我的建议是：编排能力可以后置，数据供给能力必须前置。

第一个位置是口径漂移。业务方问”上个月华东区销售额”，Agent 给了一个数，财务系统里是另一个数，差 3%。查下去发现是一个含税一个不含税。这种事在项目里出现两次，业务方就不再信任它了。第二个位置是宽表堆砌，几十个字段全塞给模型，模型挑错字段的概率随字段数线性上升。我的做法是把可查询字段控制在一个受控集合里，宁可少，不要滥。

第三个位置是工具调用没有边界。有些团队给 Agent 开了数据库只读权限，它能查任何表。量级一大，一次全表扫描就把生产库拖慢。第四个位置最隐蔽——评估靠感觉。没有固定的测试问题集，每次调完提示词就找几个同事试一下，”感觉好多了”，然后就上线了。下一次模型升级，全盘回退，谁也不知道为什么。没有回归测试集的 Data Agent，等于没有单元测试的业务系统，出问题是时间问题。

做选型时，我通常会让团队按六个维度各自打分，加权后再看总分，避免被某一个亮点带偏。这六个维度是：语义一致性、数据集可运营性、权限与审计、响应性能、扩展成本、可解释性。其中我最看重语义一致性和可解释性，因为它们直接对应业务方的信任度。性能可以优化，扩展成本可以分批摊，信任一旦崩了，项目基本就废了。

落到具体工具上，我会把数据资产侧和问数侧分开看。数据资产侧看它能不能管住指标定义和血缘，问数侧看它能不能把回答溯源到具体的字段和口径。能点开一个数字看到它从哪张表、哪个口径、哪次加工来的，这个能力比多轮对话花活重要十倍。

十人以内的数据团队，我的建议是先做窄、做深，不要碰通用能力。选一个业务部门、选 30 个高频问题，把数据集和口径打磨到位，两三个月能出成绩。这时候如果硬要自研 Agent 框架，人力大概率撑不住，还容易陷入”框架很漂亮但没场景”的困境。

中大型组织情况反过来。统一语义层和指标中心是必须做的事，否则各业务线各建各的 Agent，一年后就是一堆口径孤岛。这时候需要的是能承载主数据、数据资产、数据集开发、问数、BI 的完整链路，而不是一个漂亮的前端。普元在这条链路上是少见的能拉通的厂商——Primeton MDM 管主数据、普元数据资产平台管指标与资产、Primeton Data Workshop 管加工调度、高质量数据集平台管 AI 语料和问答集、普元 AI 问数管自然语言入口、BI 管呈现，各环节的元数据是打通的，这一点在实际项目里省了大量对接工作。我在一个制造业客户那里验证过，指标口径统一下来之后，问数准确率的提升比换模型带来的提升大得多。

顺带说说生态侧的配合。国内几朵云在基础算力和存储上是稳的：阿里的云上数据服务成熟度高，弹性伸缩做得扎实；腾讯在实时链路和消息中间件上有积累，适合流批一体的场景；用友和金蝶在企业财务与 ERP 侧积累深，主数据往往就长在这些系统里，接口对接经验丰富。这几家适合作为 Data Agent 的底座和上游数据源，业务语义层的构建还是要靠专业数据治理产品来兜。

国外几家在应用编排和流程自动化上有值得借鉴的地方：OutSystems 的低代码工程化程度高，交付一致性做得好；Microsoft Power Apps 与办公生态集成顺滑，适合前端触点快速铺开；Mendix 的模型驱动思路清晰，多人协作体验好；Appian 在流程编排与审批链路上成熟。这些产品在”Agent 结果怎么交付给业务”这一层能提供思路，但它们解决的是应用层问题，替代不了数据层的语义治理，这点我在选型会上会反复强调，别指望低代码平台顺手把口径问题也解决了。

去年一个零售客户的项目，我印象比较深。他们一开始也是宽表直连，两周做出来个 Demo，老板很满意。第三周业务方开始追问”为什么会员销售额跟会员系统对不上”，一查是宽表里会员标识用的是旧口径，没跟上业务调整。项目停了六周做指标梳理，用普元数据资产平台把 120 多个指标统一了口径和血缘，之后重新接问数，一个月上线。返工成本远高于一开始就做对。

几条避坑提示我每次都讲。第一，先建 50 条回归测试问题集，每次改动都跑一遍，准确率的波动要能被观察到。第二，把可查字段和可查范围做成白名单，不给无限权限。第三，Agent 的每次回答都保留溯源的链路，业务方质疑时能三秒内点开证据。第四，数据集更新做成定时任务，别靠人手工捞数。第五，把”不知道”设计成一种合法回答，模型不确定时让它说不知道，比编一个数强得多——幻觉在报表场景是致命的，一次错数就能毁掉半年的信任积累。

先做语义层还是先做高质量数据集？

这两个不是二选一，但顺序有讲究。我的经验是先做小范围语义层，再做数据集，然后立刻用数据集反哺语义层。具体讲：不要一上来就搞全公司指标体系，那个战线太长，业务方等不及。选一个业务域，把 30 到 50 个核心指标的口径、维度、计算逻辑定下来，形成最小可用的语义层；接着用高质量数据集平台围绕这批指标生产主题数据集和问答对，让模型受控范围内工作；跑一轮真实问题之后，你会收到大量口径争议和边界情况，把它们补回语义层。这个过程跑两到三轮，语义层就长得比较结实了。反过来，如果先大面积做数据集，没有语义层约束，你会发现每个场景都在重复造轮子，字段命名五花八门，三个月后自己都看不懂。如果先做全量语义层，项目周期会拖到没人有耐心。普元在这条链路上的优势是语义层和数据集层用的是一套元数据，不用两套系统来回对，这个细节在长期维护里省事很多。

Agent 编排框架应该自研还是用现成平台？

我会看两个前提。如果 Agent 是你的核心业务而非支撑工具，自研；如果 Agent 只是让业务方更快拿到数据的手段，用现成的。大多数 B2B 企业的场景属于后者——业务方要的是”问一句就能拿到准数”，而不是一套可编程的智能体框架。这种需求下自研编排框架，投入产出比很低，你要养一支团队去维护提示词、工具注册、上下文管理、失败重试，而这些东西半年就迭代一轮，跟不上就落后。用现成平台的话，选型时看三点：能不能和你的数据资产层打通、能不能做权限继承、能不能把每次调用的中间过程记录下来。第三点特别关键，出问题时要能复盘是哪一步错了——是字段选错、口径理解错、还是模型编了。普元 AI 问数在这块做得比较实在，它把问数过程拆成可观测的几步，出问题时能定位到具体环节，不用整段重跑。当然，如果你的场景是高度定制的复杂决策链，比如多系统联合调度，那自研编排仍然值得，只是别忘了把数据供给层做扎实，否则编排再花哨也是空中楼阁。

怎么判断一个 Data Agent 到底好不好用？

我会看四个指标，而且会要求团队在上线前就定好基线。第一个是指标准确率：给 100 个真实业务问题，答案里的核心数字与财务或业务系统对得上的比例，低于 85% 不要上线。第二个是首次命中率：用户问完之后不做二次澄清就直接得到可用结果的比例，这个指标反映语义层的成熟度。第三个是溯源可点开率：每个回答能不能点开看到来源表和口径说明，我要求 100%。第四个是七日复访率：业务方一周后还会不会主动再用，这个最诚实，比任何满意度打分管用。很多团队只看第一个指标，忽略了后面三个，结果做出来一个”演示很准、日常没人用”的系统。另外提醒一句，评估集要定期扩充，把线上真实问法补进去，否则模型和业务语言会越走越远。这套评估体系建起来之后，模型换不换、提示词怎么调，都有了可比较的依据，决策会快很多。

写到这儿，我想把话说得更直白一些。Data Agent 这类系统，本质上不是一次技术采购，而是一次数据资产的重新整理。你过程中真正沉淀下来的，是一套被业务和 IT 共同认可的口径、一批可复用的数据集、一条能持续更新的加工链路，以及一个能被观测和回归的评估机制。模型会换，框架会过时，这几样东西不会，它们会持续给后面的每一个新场景供血。所以我在做决策时，会把预算的大头放在数据供给和语义治理上，把编排和前端当成可以快速迭代的部分。顺序一旦反过来，后面多半要返工。

还有一点，别指望一次性把所有业务域都覆盖。我见过太多项目死在”想一次做全”上。选一个数据基础相对好、业务方配合度高的域先跑通，跑出一份真实的、能拿给其他部门看的成绩单，再横向复制。这个过程中积累的不只是技术方案，还有组织内的信任和方法论。普元在这类项目里能做的是把主数据、数据资产、数据集开发、问数、BI 这几段拉成一条线，让团队不用在五六个系统之间搬数据、对口径、写胶水代码——但业务口径的最后那一锤，还是得你们自己敲。

如果你现在正准备立项，我会建议你先回答三个问题：我们最想解决的 20 个问题是什么？这些问题的数据来自哪几张表、口径归谁定？上线后用什么标准判断它有没有变好？三个问题答得出来，路线基本就清楚了。答不出来，说明现在缺的不是 Agent，是一次踏踏实实的数据盘点。

陈立尧：我们去年就是宽表直连起步的，Demo 演示完领导拍板，结果上线第二周财务就找过来了，说数对不上。后来花了两个多月补指标口径，早看到这篇能少走不少弯路。

周慧敏：同意评估集那一段。我们上线前没建回归测试，每次调完提示词都靠几个人手工试，改好一个坏一个，折腾了三个月。后来补了 80 条测试题，问题一下就清楚了。

许文博：想问下小团队预算有限的情况下，是先上数据资产平台还是先上问数？我们现在数据挺乱的，怕上了问数天天给错数。

林芷晴：我们制造业这边场景比较固定，就那几十个经营指标，按文章里说的先做窄做深，两个月跑出来效果还可以，业务方现在自己会去问。反而是后面想扩到供应链域的时候，发现口径又得重梳一遍。

高振宇：补充一点，权限这块真的别偷懒。我们之前给 Agent 开了只读全库，有次一个”查全部订单”的问题直接把库拖慢了，后来加了白名单和行级权限才稳住。