Data Agent 落地，从一个业务场景建立语义闭环

先向各位读者朋友问声好，祝大家复工顺利。

假期之后，经营复盘、目标跟进和日常分析重新提上日程。接着前两期关于“祛魅”和“壁垒”的讨论，《大模型不是 Data Agent 的护城河》、《Data Agent 不必依附 BI，企业真正要补的是数据治理》，本期我们把问题落到具体工作中：企业准备开发或试用 Data Agent 时，应该从哪里开始？

企业做 Data Agent，最容易犯的错误，是把“接入更多数据”误认为“具备了更强能力”。

于是项目一开始就接入数据仓库、指标平台、知识库和权限系统，做一个面向全公司的问数入口。演示时，系统看起来可以回答很多问题；只是一旦进入真实业务，问题就随之出现：不同的人被识别成同一个人，同一个指标在不同部门有不同结果，同一个月因为时间口径不同得出两套答案。

可这些问题并不说明大模型不够强，它们说明企业并没有把自己的业务关系讲清楚。

无论企业准备开发 Data Agent，亦或者准备试用市面上的产品时，都应该从一个业务场景开始。这里的“开始”不等于必须自研，也不意味着要先搭建一套完整平台；无论采用开发、采购还是试用的方式，都需要先用真实业务问题检验产品和数据基础。这个场景表面上要足够简单，业务人员一听就知道它有什么用；底层又要足够复杂，能够暴露企业在实体、关系、指标、时间和权限上的真实问题。

这不是把目标做小，而是先找一个可以被验证的切口，证明企业能不能把一句业务语言，稳定地转换成正确的数据结果。

01 语义闭环不是给字段加注释

很多企业已经有数据字典，也有指标平台，这并不是说就已经拥有了适合 Data Agent 的语义体系。

字段说明解决的是“这一列大概是什么”；语义闭环要解决的是“用户提出一个业务问题时，系统如何确定对象、关系、口径和边界，并给出可解释的结果”。

一条完整的语义链，至少包括以下几件事：

第一，确定业务实体。用户说“张三”、“店铺”、“客户”“销售额”，系统必须知道这些词分别对应什么对象，而不是只在字段名中寻找相似文本。

第二，确定实体之间的关系。订单属于哪家店，店属于哪个区域，店由谁负责，目标又是按什么对象下达的，这些关系决定了数据能否被正确连接。

第三，确定指标口径。销售额按下单、支付还是完成计算；退款是否扣除；目标按自然月还是财务月计算，都必须有明确规则。

第四，确定时间和权限。一个人可能在不同时间负责不同店铺，一个用户可能只能看到本区域数据。没有时间和权限，结果即使算对，也不一定应该返回。

第五，确定验证和处理方式。结果如何核对，出现数据缺失时如何提示，发现异常后是否要交给人确认，这些决定 Agent 能不能进入实际流程。

因此，语义闭环不是一张表，也不是一个知识库。它是一套从用户表达，到业务对象、关系、指标、数据、权限，再回到业务动作的可验证链路。

02 结合大量实操，分享3个典型场景

案例1：同名不同号，先解决“你说的是谁”

上期大模型不是 Data Agent 的护城河提到过“同名不同号”的问题：公司里可能有多个叫张三的人，姓名相同，员工编号却不同。它说明，企业数据中的名称和身份需要明确区分。

沿着这个例子继续往下看。当业务负责人问“张三负责的店铺销售额是多少”时，系统不仅要确认是哪位张三，还要确定他与店铺之间的关系，以及销售额的统计范围。

假设企业里有多名员工叫张三，业务负责人问：

张三负责的店铺，本月销售额是多少？

如果系统只做文本匹配，结果通常有三种：1、把所有张三的数据合并。2、随意返回其中一个张三。3、直接报错。这三种结果都不能满足企业使用要求。

问题的根源不在姓名，而在于企业是否把“员工”作为一个有唯一身份的业务实体来管理。

一个可用的回答至少要经过以下判断：

• “张三”对应哪些员工编号；
• 这些员工分别属于哪个组织和区域；
• 哪一个人在目标月份担任店长、区域负责人或管理员；
• 他和店铺之间是当前负责关系，还是历史负责关系；
• 当前提问者是否有权查看这些店铺的数据。

如果无法唯一确定，Agent 应该先澄清，而不是猜测：

系统中有 3 位名为张三的员工。请确认您指的是华东区域员工，还是员工编号为 A1024 的张三。

这一步不是对话体验上的“多问一句”，而是企业数据正确性的必要条件。姓名、简称、别名都只是展示属性，不能作为唯一身份。真正稳定的识别，需要依靠实体编号、组织关系、生效时间和权限范围。

这个案例也说明，实体消歧不能只在大模型层解决。模型可以识别“张三”可能存在歧义，但究竟有哪些张三、各自负责什么、谁能看到什么，必须由企业的主数据和语义关系提供答案。

同样的问题还会出现在客户、供应商、商品和门店上：不同系统可能使用不同编码，同一个对象可能有历史名称，一个名称也可能对应多个真实对象。Data Agent 要可靠，首先要能处理这些差异。

案例2：达成率的难点不在公式，而在关系

达成率是企业最常见的指标之一：

达成率 = 实际完成金额 ÷ 目标金额

各店铺管理员负责的店铺，本月销售目标达成率是多少？

这个问题有一个容易被忽略的关键：实际金额和目标金额，并不是沿着同一条关系得到的。

计算实际金额时，需要从人员找到他负责的店铺，再从店铺找到订单；而目标金额则是直接落在人员身上。也就是说，实际金额的链路是：

店铺管理员 → 店铺 → 订单表 → 实际金额

目标金额的链路则是：

店铺管理员 → 目标表 → 目标金额

这两条链路并不直接对等。Agent 必须先识别“人员”和“店铺”的实体关系，再把通过店铺汇总出来的实际金额，与直接属于人员的目标金额放在同一统计口径下比较。

Agent 还必须处理几个决定结果的细节。

第一，实际完成金额按什么状态统计。是订单创建就算，还是支付成功才算，或者必须完成交付才算？取消和退款是否扣除？如果这个问题没有统一答案，达成率只是一个带小数点的争议。

第二，店铺管理员按哪个时间点确定。如果某个店铺在月中更换管理员，整月销售额归给谁？按当前管理员回溯，还是按每天的历史关系拆分？这不是技术细节，而是考核责任的定义。

第三，目标和实际是否处于同一层级。目标表按管理员记录，订单却按店铺记录。一个管理员管理多个店铺时，订单需要先沿店铺关系汇总到管理员，再和目标比较。

第四，员工身份是否统一。目标表中的管理员可能使用姓名，店铺表使用员工编号；如果“张三”在两张表中不是同一个标识，关联结果就会产生遗漏或重复。

第五，目标月份如何定义。自然月、财务月和经营周期可能并不相同。时间维度不统一，数据再新也不能直接相除。

因此，达成率场景非常适合作为企业的能力测试。它表面上是一个简单指标，实际上同时检验了：

• 实体是否统一；
• 跨表关系是否完整；
• 指标公式是否明确；
• 订单状态是否有口径；
• 历史关系是否可追溯；
• 时间周期是否一致；
• 权限是否能落到管理员和组织层级。

如果 Data Agent 只是把三张表机械地连接起来，结果很可能看起来有数字，却没有真正理解业务关系。只有当它能够识别这两条不对等的链路，把实际金额和目标金额正确对齐，并告诉用户采用了什么口径，它才具备了进入经营分析场景的基础。

案例3：新客和复购，检验时间与状态

再来一个常见的运营问题：

本月新客数量是多少？复购率是多少？

许多系统可以很快返回一个数字，但这两个指标真正困难的地方，在于“新客”和“复购”并不是数据库天然存在的字段。

企业需要先确定：

• 新客按注册时间、首单时间还是首笔支付成功时间定义；
• 取消订单和退款订单是否算作首单；
• 同一个客户在不同渠道、不同系统中的账号如何合并；
• 企业客户的联系人和客户主体如何区分；
• 复购是指自然月内再次购买，还是在指定周期内再次购买；
• 复购率的分母是本月全部客户，还是具备复购机会的历史客户。

这个场景至少涉及客户主数据、订单、支付状态、退款状态和时间日历。它测试的不是跨表关联本身，而是企业有没有把“第一次”、“有效”、“再次”这些业务词定义成可执行的规则。

如果没有统一定义，Agent 输出的“新客 1,238 人、复购率 26%”看起来很精确，却无法回答最基本的问题：这个数字到底是按照什么规则算出来的？

这类场景说明，语义治理的重点不是把所有概念解释得更长，而是把会影响结果的判断条件明确下来。

03 如何选择第一个场景：不要凭感觉，要看6个条件

第一个场景选得好，无论企业最终选择自研、采购还是继续试用，后续工作都能围绕一个真实问题推进；选得不好，项目很容易变成一次没有验收标准的技术展示。

建议用下面6个条件筛选候选场景。

第一，场景是否高频，但不是低价值重复

高频不等于适合。每天导出一次固定报表，确实高频，但如果流程已经稳定、人工成本很低，未必值得作为第一个 Agent 场景。

更合适的是那些高频发生、又需要持续判断的问题，例如：销售异常归因、库存风险识别、目标达成分析、回款跟进和交付预警。这些工作不是简单搬运数字，而是需要在多个数据之间进行判断。

第二，场景是否有明确的责任人

如果一个问题没有明确使用者和责任人，Agent 给出的结果很难进入流程。

要能回答：谁提出问题，谁需要看到结果，谁负责确认，谁负责处理异常，处理结果由谁验收。一个有明确责任人的场景，才有机会形成从分析到行动的连续过程。

第三，场景是否同时具备“简单入口”和“复杂底层”

第一个场景最好让业务人员用一句话就能说明白，例如“本月各管理员的达成率”“张三负责的店铺销售额”“本月新客和复购率”。

但底层不能只有一张干净的宽表。场景应该适度包含跨表关系、实体映射、时间口径或权限要求。只有这样，企业才能测试 Agent 是否真正理解业务，而不是只会在演示数据上生成答案。

第四，场景的事实数据是否相对稳定

不要求数据完美，但需要知道数据从哪里来、多久更新一次、谁负责维护、哪些字段经常缺失。如果连事实来源和更新时间都说不清，问题就不应该先交给 Agent，而应先解决数据可用性。

稳定的场景不一定数据质量最好，而是数据问题能够被发现、解释和修复。

第五，场景是否能够写出“标准答案”

6、场景是否有清晰的风险边界

第一个场景可以先做只读分析、解释和建议生成，不必一开始就让 Agent 自动修改订单、调整价格或发起高风险审批。

但即使是只读场景，也要提前定义：哪些数据不能返回，哪些结果必须提示不确定性，哪些问题必须转人工确认。风险边界越清楚，试点越容易获得业务和管理者的信任。

04 一个场景跑通，企业到底留下了什么

如果项目结束时只留下一个聊天窗口，说明企业只是完成了一次产品演示。无论 Agent 是自研的，还是通过市场产品试用出来的，真正有价值的结果都应该能够脱离某一次演示继续使用。

一个真正有价值的试点，应该沉淀出以下内容：

• 一组明确的业务实体及其唯一标识；
• 一张经过业务确认的实体关系图；
• 一套指标定义、计算逻辑和适用条件；
• 一组数据来源、字段映射和更新时间说明；
• 一套语义层权限配置和组织边界；
• 一组带标准答案的真实测试问题；
• 一份异常处理和人工介入规则；
• 一条从结果到后续任务的业务流程；
• 可以持续运行的定时报告、日报、周报或异常提醒；
• 经过业务确认的固定分析模板和常用提问模板；
• 可复用的指标口径、筛选条件、输出格式和解释规则；
• 产品配置、提示词、工作流、接口和运行参数等实施记录。

这些内容才是下一次扩展的基础。下一个场景不仅可以复用员工主数据、组织关系、时间维度、权限规则和测试方法，也可以复用已经验证过的定时任务、报告结构、分析模板和运行机制，而不需要重新从零开始。

05 从第一个场景开始，不等于只解决一个问题

Data Agent 的第一步，不是把所有数据都接进来，也不是先做一个功能齐全的通用助手。

更可靠的做法，是找一个业务人员每天会问、管理者确实关心、结果能够验证，同时又足以暴露企业数据关系问题的场景。

同名不同号，检验的是企业能否确认“你说的是谁”；达成率，检验的是订单、店铺、管理员和目标能否在统一口径下对齐；新客与复购，检验的是时间、状态和客户身份能否被定义清楚。

当一个场景能够被准确解释、稳定计算、追溯来源，并且把结果送回业务流程，企业才真正拥有了第一条语义闭环。

这条闭环的价值，不在于它回答了多少个问题，而在于企业开始知道：自己的数据应该如何被理解，业务规则应该如何被维护，Agent 应该在哪些边界内工作。