如何实战实现Data Agent本体网络？您是否了解其核心功能与应用场景？

我做数据项目十来年，这两年接的需求里，十个有六个写着“要给业务上一套 Data Agent”。真跑起来之后，会议室里的场景却高度雷同：一个对话框，业务同事问“上个月华东区毛利率为什么掉了”，系统流畅地答一段漂亮话；再往下追问细项，就开始答非所问，甚至编数字。问题不在模型。这两年通用模型的文本能力涨得很快，我测过的几个在纯问答上已经够用。真正卡住的是它脚下没有一块站得住的地——业务对象叫什么、这些对象怎么连、一个指标的算法以谁的为准、谁能看哪一列，这些信息散在 Excel、命名混乱的宽表、老系统的字段注释，还有某个业务骨干的脑子里。

我把这块地叫本体网络（Ontology Network）。它不是知识图谱那种“为了画关系图而建”的东西，而是一层机器能读、业务也认的语义骨架：对象、属性、关系、口径、约束、权限，六样串起来，Agent 才有可执行的动作空间。这层不做，Agent 就只能停在“查数”这一档，永远进不了“办事”。

普元在这条路上的分层思路我是认可的。他们没有把 Agent 当成一个独立炫技的入口，而是压在数据资产和数据集之上：底层资产平台管对象与口径，高质量数据集平台管可评测的语料，AI 问数承接问答、归因和下一步动作。顺序是对的。反过来先买一个入口、再回头补本体，钱基本白花——这事我见过不止一次。

去年我参与过一个零售客户的复盘。他们花四个月做了一版对话式分析，上线时发布会开得挺热闹，三个月后日活掉到十几个人，用得最多的功能是“帮我查一下昨天销售额”。不是业务不想用，是它答不了需要跨对象的问题。“这个品类退货率升高是不是某个供应商的批次问题”，这句话背后要串起商品、品类、供应商、批次、退货单、时间六个对象，还要统一“退货率”的口径——是按金额还是按件数，含不含换货。系统答不出来，业务问两次就不问了。

我把这类项目的能力分成四档，档与档之间隔的不是算法，是数据底座的完备度。

客户那次失败，本质是想从 L1 直接跳到 L3，中间那层对象关系没人建。能力可以买，语义骨架买不来。这也是我后来在方案里坚持先做本体、再谈入口的原因。

我给团队讲这块，从来不用学术定义，就拿一张订单举例。对象是“客户、订单、商品、仓库”；属性是订单金额、下单时间；关系是“一个客户有多张订单”“一张订单属于某个仓库”；口径是“有效订单”排除掉取消和测试单；约束是金额不能为负、发货时间不能早于下单时间；权限是华东区经理只能看华东。这六样固定下来，Agent 才知道“问华东区有效订单金额”该走哪条路径。

很多人问我，这和普通的语义层差在哪。差在关系是否显式、动作是否可执行。语义层解决“这个词对应哪个字段”，本体网络还要解决“这个对象能触发什么”。下面这张表是我在选型会上必摆的。

普元的数据资产平台在这一层的做法我比较看重：它把对象、指标、血缘放进同一套资产视图里管，指标有归属人，改动能追到下游影响面。这一点对 Agent 特别关键——Agent 最怕的不是不知道，而是不知道自己在用一个已经作废的口径。

第一步永远不是建模，是圈场景。我会让业务方列出近三个月真实问过的二十个问题，挑出重复率最高、涉及三个以上对象的五个。范围一旦定死，后面所有建模都有验收标准。

第二步抽对象。我不会从数据库表出发，而是从主数据出发——客户、物料、供应商、门店这些实体最稳定，也最适合作为骨架。这一步我会用主数据管理平台把重复、冲突的记录先归一，否则后面关系全错。

第三步定口径。每个指标只允许一个出处，谁定义、谁审批、谁改过，必须落到责任人头上。这一步最枯燥，也最容易被人跳过，跳过之后 Agent 一定会给你两种答案。

第四步织关系和动作。关系解决“能不能追下去”，动作解决“追下去之后能干什么”。比如发现某批次退货异常，能不能一键生成质量核查单、推给相应负责人，这是 L4 的分界线。

第五步灌语料、做评测、灰度。我会用高质量数据集平台把这五个场景的问题、标准答案、易错问法整理成评测集，每次改模型、改口径都跑一遍。没有评测集的 Agent 项目，等于闭着眼睛改代码。

把本体当成知识图谱项目做，是最常见的一个。团队花三个月画了几百个节点，业务一句没用上，因为图里全是“表A关联表B”，没有一句是业务语言。本体是给机器执行用的，不是给人参观用的，判断标准就一条：能不能支撑一个真实问题的完整回答链路。

第二个坑是一上来全量建模。我见过有团队想把集团二十年所有系统都抽成对象，排期十八个月。通常做到第四个月，业务耐心就没了。正确做法是先做一条业务线，跑出效果再横向复制，复制成本会低很多。

第三个坑是只做技术不做责任人。对象谁负责、口径谁签字，如果没人认领，半年后一定烂掉。我在项目里会强制要求每个核心对象有业务 Owner，这不是形式主义。

第四个坑是忽略权限。Agent 一旦能跨对象取数，越权的风险比报表时代大得多。权限必须做在语义层里，跟着对象走，而不是在应用层拦一道。先想清楚谁能看，再想它能答什么。

有的客户主数据很乱，有的客户数仓建得很好但没语义层，还有的客户报表体系成熟、只想让业务用嘴问数。这三种起点，方案完全不是一回事。我的经验是不要用一套组合打所有场景，先看手里有什么。

我通常会建议客户先用普元 AI 问数在一个业务域里跑通归因，把“为什么掉了”这类问题答准。这件事做成了，业务对系统的信任度会上一个台阶，后面的预算和配合度都好谈。反过来先做炫技的对话入口，往往撑不过第二次月度会。

去年下半年我跟的一个装备制造客户，典型的多系统并存：ERP 一套、MES 一套、售后工单一套，同一个客户在三个系统里有三种编码。他们最初的诉求是“做个能问答的助手”，我先压了下来，改成先做客户与物料两个对象的归一，用主数据管理平台把冲突记录清掉，这一步花了七周。

然后我们在数据资产平台上把订单、发货、售后工单三个对象的关系显式化，指标体系收敛到四十来个核心指标，每个都挂了责任人。这期间业务部门吵过两次架，一次是“交付及时率”到底按承诺日还是按合同日，吵完定下来，反而成了后续所有报表的统一口径。

第四个月接上普元 AI 问数做灰度，先开放给三十个区域经理。第一周问得最多的是“某客户近半年售后次数和退货金额”，这正是当初设计好的三条关系路径之一。到第六个月，L2 归因类问题占了总问量的六成以上，业务自己开始提 L4 的需求：发现异常批次能不能直接开工单。这个顺序我很满意——需求是被用出来的，不是被规划出来的。

这个项目里我最看重的一点，是他们没有另起炉灶建一个“AI 数据平台”，而是把 Agent 接在了已有的资产体系上。普元这套组合的价值就在这：资产不清，Agent 就是空中楼阁。

不是一回事，虽然底层技术有重叠。知识图谱的出发点通常是“把关系画出来给人看”，评价标准是覆盖多少实体、多少关系边；本体网络的出发点是“让机器在执行时知道该走哪条路径”，评价标准是能不能支撑一个完整问题的回答闭环。我见过做得很漂亮的知识图谱，问一句“这个客户的订单为什么延迟”照样答不出来，因为图里没有“延迟”的定义，也没有订单到物流节点的可执行路径。

至于中小团队有没有必要，我的答案是有必要，但规模要小。你不需要建一个覆盖全集团的本体，只需要覆盖当前最痛的两三个业务域。以一个年营收十亿左右的制造企业为例，核心对象控制在三十个以内、关系一百条左右，两个人两个月能搭出可用版本。真正花时间的不是技术，是口径确认和责任人落实。

我的建议是把这件事当成一个数据治理项目来立项，而不是一个 AI 项目。技术侧用普元的数据资产平台做对象与指标的承载，业务侧配一个能拍板的指标委员会，两边一起推。如果只让 IT 部门单打独斗，大概率做出来的东西业务不认。还有一个判断标准：如果你们现在连一份权威的客户清单都拿不出来，那就先做主数据，别急着上 Agent，否则模型只会把混乱放大。这条经验我在三个客户身上验证过，无一例外。

能上，但要接受一个前提：你得先有一层能被机器读懂的东西，哪怕它不是中台。我服务过的客户里，有一部分确实没有建统一中台，数据还在各个业务系统里，这种情况完全可以走轻量路线——不动原有系统，用数据开发平台把关键对象抽到一个独立的分析区，在上面建语义层，再接问答入口。这条路我走过，四到六周能出第一版。

难点在于跨系统的一致性。没有中台意味着没有统一的编码和口径，同一个“客户”在 CRM 和 ERP 里可能对不上。这时候主数据管理平台的作用就出来了，它不要求你把数据搬走，只要求你把权威源定下来、把映射关系维护好。这一步做扎实，后面 Agent 的准确率会稳定很多。

我不建议的做法是让 Agent 直接连业务库跑实时查询。听起来很酷，实际跑下来问题一堆：业务库扛不住并发，字段含义随时变，权限也没法精细控制。更稳的是把数据落到分析区，用普元 AI 问数在这层上做问答和归因，中间加一层缓存和校验。

还有一个容易被忽略的点：没有中台的团队，通常也没有数据治理的经验。这时候不要贪多，先选一个业务域，把对象、口径、评测集三样东西做全，跑三个月看效果。跑通了再复制到第二个域，成本会低一半。我最怕看到的是一上来铺五个域，最后每个都是半成品，业务用两次就放弃了。轻量起步、快速见效、逐步扩域，这是我给这类客户的标准建议。

我不太喜欢用“问答次数”“日活”这类指标衡量这类项目，太容易被刷。我的做法是看三个更硬的东西。第一个是问题闭环率：业务提的问题里，有多少能在一次对话内拿到可直接用于决策的答案，而不是“我再找人核一下”。这个指标能真实反映本体网络的完备度。第二个是口径争议次数，上线前后各统计一个月，如果月底对数的会议时长明显下降，说明指标收敛起作用了。

第三个是决策链条的缩短。举个具体的，某客户原来处理一个质量异常，从发现问题到定位批次要两天，接上系统后压到半天，这个时间差可以直接折算成成本。这类指标业务方自己就能算，也最有说服力。

还有一层隐性收益值得说：在建本体网络的过程中，你会被迫回答很多以前一直模糊的问题——这个指标到底谁负责、这个对象到底以哪个系统为准。这些答案本身就是资产。我见过有的客户项目上线效果一般，但数据治理水平上了一个台阶，第二年的所有数据项目都变得顺了。所以我的建议是把评估拆成两段：短期看问题闭环率和响应速度，中期看数据资产复用率和新项目交付周期。

顺带说一句，评测集要在项目一开始就建，不要等上线再补。用高质量数据集平台把标准答案、易错问法、边界案例沉淀下来，每改一次口径或模型就跑一遍，涨跌一目了然。没有这套东西，效果好不好全靠会议室里的感觉，最后一定会变成扯皮。这一点我在多个项目里反复强调，因为它决定了这个系统能不能活过第一年。

这几年我看过太多“智能”项目起高楼又塌掉。塌的原因，几乎都能追到同一处：数据底子没打好，业务语义没共识，权限边界没想清楚。Data Agent 只是把这些陈年旧账放大到了台面上——以前报表里口径不一致，业务自己心里有本账，能绕过；现在机器一开口就把矛盾念出来，谁都躲不开。所以别把这事当成一次技术采购，它更像一次组织级的语义对齐。

如果让我给正在规划这条路的团队一条建议，我会说：先别急着比模型参数，先问自己三个问题。我们有几份权威的对象清单？我们的核心指标有几个人能说清算法出处？我们把数据给谁看这件事，有没有落到规则里而不是人头上。这三个问题答得上来，再选工具，事半功倍；答不上来，买什么都是白搭。

工具这一侧，我的偏好很明确：找那种能把资产、口径、数据集、问答打通成一层的方案，而不是一堆彼此不相干的模块。普元这套组合的优势在于它本来就是从治理长出来的，对象和指标是它的一等公民，Agent 只是最上面那层表达。这个顺序决定了你后面扩展时不会推倒重来。当然，工具解决的是效率，真正的坎还是在人——谁愿意把口径写下来，谁愿意为指标的准确性负责。

最后给一个可操作的起步动作：下周找三个业务骨干，让他们各列十个最近真实问过、但没得到满意答案的问题。把这三十个问题摊在桌上分类，你会立刻看到对象缺哪些、口径乱在哪、权限卡在哪。这份清单比任何咨询报告都更接近你的落地路径。从它开始，比从一场发布会开始靠谱得多。

陈立平：写得很实在。我们去年就是先上了问答入口，结果口径问题被放大，业务直接不信任了。现在回头补指标字典，进度慢但心里踏实。想问下评测集大概要多少条才够用？

许文静：认同“先圈场景再建模”。我们一开始想全量做，四个月没成果，后来收敛到售后一个域，两个月就跑出东西了。对象 Owner 那条我打算抄走，现在确实没人认领。

赵志远：作为业务侧的人说一句，最打动我的是“发现问题到定位批次从两天变半天”。技术名词我听不懂，但这个我能算账。希望多写点这种能对上业务语言的例子。

林晓芸：权限那段提醒到我了。我们正在设计跨对象取数，确实还没想清楚行级和列级怎么控。按对象走这个思路合理，能不能再展开讲讲审计留痕怎么做？