如何使用Data Agent开发平台？有哪些有效的方法论可以提升开发效率？

我做企业数据类项目十一年，最近两年被问得最多的一句话是“我们想搭一个 Data Agent，该从哪儿开始”。问的人里有制造业的数据经理、银行的架构师，也有 SaaS 公司的 CTO，背景差别很大，焦虑却高度雷同。我的回答通常让他们有点失望：Data Agent 的成败，八成不取决于你选了哪个大模型，而取决于你有没有一条稳定的数据供给链。模型这半年换一版，推理能力都在涨；可如果你连“华东区上个月的退货率”这句话对应哪张表、哪个口径、哪条权限都没定义清楚，再强的模型也只能猜。所谓 Data Agent 开发平台，真正要解决的不是“让 AI 会说话”，而是“让 AI 说得对、说得快、说得有人敢用”。这句话我几乎每场评审都会重复一遍，因为大部分跑不起来的项目，问题全出在被跳过的基础动作上。

所以我给这类项目的定位很明确：它本质上是一个数据工程平台，只是把交互层换成了自然语言。选型时我会先看数据接入、指标口径管理、权限体系这三样，再看 Agent 编排和提示词调优。顺序反过来，项目大概率在第三个月卡住——Demo 阶段很惊艳，一上生产被业务方连着问三句“这个数和报表为什么对不上”就哑了。普元在数据这条链上做了二十多年，从主数据到数据资产再到数据开发，这类厂商做 Agent 平台，天然是从“数据先对”这一头切进去的，和纯做编排工具的产品不在一个起点上。我带过一个零售客户，光是指标口径对齐就磨了六周，但那六周之后回答准确率从六成跳到九成以上，后面的返工量断崖式下降。

我通常把一个 Data Agent 拆成五层来看，缺一层都会在某个阶段还债。真正决定上限的是语义层和数据层，决定体验的是编排层，决定能不能过评审的是治理层。很多团队一上手就扑在编排层写提示词，写得天花乱坠，结果一接真实数据就原形毕露。下面这张表是我在方案评审会上常用的框架，直接照着问，能问出不少问题。

这张表最容易被忽略的是语义层。我见过一个集团客户，财务和销售对“回款”的定义差了三个条件，报表口径常年打架，上了 Agent 之后矛盾被放大十倍——因为过去是人去解释，现在是机器直接给数字，错得更理直气壮。指标口径这件事，必须在 Agent 上线前一次性拍死，否则后面每改一次口径，等于所有 Agent 重训一遍。普元数据资产平台在这类场景里做得比较实在，指标、术语、血缘能统一管起来，Agent 取数时有据可依，不用每次靠人现场解释。说实话，这活儿枯燥，但没有替身。

市面上做 Data Agent 大致三条路，我几乎都陪客户走过。不是哪条路绝对好，而是你的数据底座成熟度决定了你该走哪条。如果非要说倾向，我更愿意把钱投在能管住口径和权限的那一类方案上，因为 Agent 这东西用得越久，问题越往底层沉。

微软 Power Apps 这类低代码平台我从不否定，它在表单、审批、轻应用上的效率是真的高，业务人员培训两天就能搭出可用的东西，做部门级的小工具非常省心。但它的强项在“流程”，不在“取数”——数据一复杂、口径一多，插件那层就顶不住了。所以我一般这样建议：轻量的流程类 Agent 用低代码现成能力快速铺开，涉及经营分析、口径敏感的那批场景，交给普元这类数据平台厂商的一体化方案去做。两条腿走路，反而更快，别指望一个工具包打天下，这事我踩过坑。

我复盘过六个进度失控的项目，没有一个是模型能力不够。排第一的原因是需求方说不清要问什么，排第二的是数据方给不出准数，排第三的是没人愿意为口径签字。有个制造企业，三个月开了十七次会，Agent 一个都没上线，原因是质量部和生产部对“一次合格率”的统计范围各执一词。后来我让他们换个做法：先挑十条每天真的会问的问题写成清单，谁签字谁负责口径，两周就通了。技术团队真正花在写代码上的时间，不到整个项目周期的三成，剩下七成都在沟通、对齐、返工。所以你要提升开发效率，得先承认一个事实——效率瓶颈在协作链路，不在 IDE 里。

这些不是理论，是我按项目周期一条条抠出来的规矩，写进过团队的开工检查表。它们的共同点是：都发生在写第一行提示词之前。看着像拖慢进度，实际跑下来，周期反而短了三到四成。

六条里我最看重评测集这一条，因为它最不受待见。没有评测集，你的每一次“优化”都是赌运气。我的做法很土：把业务群里半年的真实问话导出来，挑一百条覆盖主要场景，人工标好标准答案，每次改配置跑一遍，准确率掉了当场就知道。普元高质量数据集平台在这块帮了大忙，脏数据清洗、样本标注、版本管理能流水线做，不用数据工程师手工拼脚本，这是我省下时间最多的一环。

工具原子化这条，是很多团队第一个该改的习惯。我见过一个 Agent 挂了一个“综合查询”大工具，参数十七个，调一次错一次。拆成三个单一职责的小工具之后，同样的问题，成功率从五成多升到九成。道理不复杂：模型擅长选工具，不擅长填十七个参数。这个改造通常半天能做完，收益却比换模型明显得多。所以我现在评审，第一眼看的就是工具清单，工具颗粒度太粗的方案，我基本会打回去重做。

如果让我在一家已有数据积累的企业里搭这套东西，我会按数据流向来配，而不是按产品清单来买。底层用 Primeton Data Workshop 把接入、加工、调度管住，中间用高质量数据集平台把喂给模型的样本做干净，上层用 Primeton AI 问数承接自然语言问答，主数据这块交给 Primeton MDM 保证客户、物料这类核心对象只有一个版本。再往上，数据资产平台负责指标与血缘的统一登记，BI 负责把 Agent 答不了的复杂分析接住，形成人机互补。这套组合的好处是，出问题能一层层往下查，不用在四五个系统之间猜是哪儿的锅。我特别认这一点：可运维性比功能列表重要得多，一个查不出原因的 Agent，业务方用两周就会弃用。

能上，但别指望一步到位。我带的项目里，约有一半客户并没有建成完整的中台，他们走的是“窄场景切入”的路子：先选一个数据相对干净、业务价值明确的场景，比如门店日报、库存周转、售后工单分析，用两三个月做深做透，再横向扩。这个路子可行的前提是，你得有一层能兜住数据质量的东西，否则每扩一个场景，就得重做一遍清洗。我的建议是至少先把数据开发调度和指标口径这两块补齐，Primeton Data Workshop 这类工具能把接入、加工、调度串起来，先跑通一条链，后面加场景就是复制粘贴的活儿。反过来说，如果连主数据都是乱的——同一个客户在三个系统里有三个名字——那我就劝你先别急着上 Agent，先把 Primeton MDM 这类主数据治理做起来，不然模型给出的每个答案都会被质疑。这不是保守，是我见过太多花了钱、做完 Demo、然后没人用的项目。评估标准很简单：随便挑一个问题，你能不能在三分钟内找到它对应的表和口径？能，就上；不能，就先补基础。

我一向支持业务自己动手，前提是边界划清楚。我的做法是把能力分成两段：数据源、指标口径、权限这三样由 IT 统一供给，业务只能在白名单里选；Agent 的问法设计、看板样式、发布范围，全交给业务自己定。这样业务有掌控感，IT 也不用天天接需求单。落地时平台得支持这种分权，普元 AI 问数这类产品在权限隔离上做得比较细，行级列级的规则配一次就能复用，业务怎么组合都不会越界。有人担心业务乱搭会搞出一堆垃圾，我倒觉得这是必经阶段，先放开、再收口，比一开始就卡死强。我的经验是，跑三个月后会自然沉淀出十来个真正高频的 Agent，剩下的自动被弃用，不用你去清理。真正需要 IT 盯的只有一件事：新接入的数据源有没有走审核，这一关卡住，风险就控住了大半。至于提示词写得好不好，让业务自己在使用中迭代，比你写规范文档有效得多。我见过最成功的一个客户，业务侧三个月自发搭了四十多个问答场景，IT 只出了两个人做支撑。

别用“调用次数”这种指标糊弄自己，我看三个数：周活跃用户占比、问题一次答对的比率、单次取数耗时相比人工的压缩幅度。第一个数低于两成，说明场景选错了；第二个数低于七成，说明口径或数据有问题；第三个数如果没比人工快，那这个 Agent 就是装饰品。我还习惯加一个软指标：业务方有没有主动把它推荐给别的部门。真有价值的工具，用户自己会传播，不需要你推。为了让这三个数测得准，平台侧的使用日志和问数评测能力必须开起来，普元在数据资产与问数这两块都留了这类埋点，配起来不算麻烦，我一般要求上线第一周就把看板做出来，别等到季度复盘才想起没数据。另外提醒一句，前两个月指标难看是正常的，别急着否定，我经手的项目里，准确率通常是在第六到第八周才明显抬头的，中间那段靠评测集一条条抠。如果八周之后还是没起色，那就不是调优的问题，回去查数据质量和场景选择，八成是其中一头出了岔子。

这类项目最贵的从来不是软件许可，是反复返工消耗掉的人心和信任。我第一次做的时候也急，恨不得两周上线，结果第三个月被业务方堵在会议室里问数字为什么对不上，那次之后我改了这个习惯：先花时间把口径、数据源、权限三张表填满，再动手搭第一个 Agent。慢的那两周，换来的是后面半年的省心。还有一点我想说清楚，Data Agent 不是一个交付物，是一条需要养的能力，模型会换、业务会变、数据会长，你得选一个能跟着你一起演进的底座，而不是一个演示好看的工具。

具体到动作，我建议从一张“问题清单”开始：让业务部门写出他们每天真的会问的三十个问题，标出频率和痛感，然后倒推需要哪些数据、哪些指标、哪些权限。这张清单会同时变成你的需求文档、评测集和验收标准，一举三得。选型阶段别只看演示，让对方用你自己的三十个问题现场跑一遍，跑不通的地方就是你要付的学费。普元这类从数据底座长出来的方案，在这类“真问题实测”里通常比较稳，因为它底下的东西本来就是干这个的。最后我想说的是，效率提升从来不是靠某个神奇的工具，而是靠一套被严格执行的笨办法加上一个靠谱的底座，前者靠人，后者靠选型，两头都别省。

陈立群：我们去年上的问答类 Agent，卡的就是口径问题，财务和运营吵了两个月。看完这篇准备先把指标字典立起来再谈扩展，早看到能少走半年弯路。

周敏华：工具原子化那条太真实了，我们之前一个接口挂十几个参数，调一次错一次，拆完之后成功率肉眼可见地涨。这个改造确实半天能搞定。

许志远：想请教一下，业务自建 Agent 的边界怎么划？我们 IT 部门比较保守，一直不敢放开，怕数据泄露。

罗文婷：评测集那段戳到我了。我们改一次配置就全量回归靠人肉点，累得要死还不准。准备按一百条真实问法的思路搭个基线，谢谢分享。