Data Agent 需要语义层，正在成为一个普遍的行业共识。
但企业真正开始建设 Data Agent 之后，很快会遇到一个更现实的问题：语义层接上了，企业文档也放进了知识库，甚至还把分析流程做成了 Skill，为什么 Agent 给出的答案仍然不像一个真正懂业务的分析师？
它可能知道“销售额”的定义，却选错了具体指标；能够检索库存制度，却把制度规定当成当前事实；按照一套分析流程查了很多数据，最后仍然无法说明结论是怎样得到的。
问题往往不在于 Agent 掌握的知识太少。恰恰相反，很多企业已经给了 Agent 太多未经区分的上下文。语义定义、业务制度、历史案例、分析方法和当前数据被放在一起，希望大模型自己判断哪些内容应该使用、在什么时候使用，以及发生冲突时应该相信谁。
这正是企业 Data Agent 从“能够回答”走向“真正懂业务”时，必须跨过的一道门槛。
01
我们通常会把“懂业务”理解成掌握大量行业知识。但在真实的数据分析工作中，一个人是否懂业务，不只取决于他记住了多少概念，更取决于他能否把几类不同性质的信息放在正确的位置上。
例如，一位业务人员问：
为什么重点产品 A 最近销售下降？
这里至少包含四类问题：
•“销售下降”应该使用销售额、销量还是订单量判断；
•“重点产品”在这家企业里如何认定；
•应该先看门店、渠道、价格，还是直接检查库存；
•发现库存异常后，是否有足够证据继续分析补货和供应履约。
这些问题并不属于同一种知识。有些是正式指标和业务对象的定义，有些是企业制度，有些是分析人员长期形成的方法，还有一些必须通过当前数据才能回答。
如果 Agent 不能区分它们，就容易出现一种典型现象：每一句话听起来都有道理，放在一起却不能支持一个可信的业务判断。
所以，判断一个 Data Agent 是否懂业务，不能只看它能检索多少文档、连接多少数据源，更要看它能不能区分：
哪些是定义，哪些是方法，哪些是规则，哪些是当前正在发生的事实。
02
当前企业建设 Data Agent，经常会同时提到语义层、Skill 和知识库。这三类能力都重要，但不能简单理解成给大模型增加三份背景材料。
企业里很少只有一个“销售额”。它可能是含税销售额、未税销售额、净销售额，也可能需要扣除退货、取消订单和内部交易。即使指标名称相同，不同部门使用的时间口径、统计对象和适用范围也可能不同。
语义层首先要解决的是：
•企业正式使用哪个指标；
•指标基于什么统计范围；
•产品、门店、仓库、供应商等业务对象如何被识别；
•不同分析模型中的同一业务对象如何保持一致；
•哪些业务关系已经得到企业确认。
它建立的是企业分析所使用的公共语言。没有这层公共语言，Agent 即使能够生成正确的查询语句，也可能非常准确地计算了一个错误的问题。
知道销售额是什么，不等于知道销售下降应该怎样分析。一个成熟的分析方法，通常包含先后顺序和判断条件：先确认变化是否真实，再定位主要贡献对象；发现问题集中在部分门店后，才进一步检查库存、价格或渠道；只有出现相应证据，才继续进入补货和供应履约分析。
Skill 的价值，是把优秀分析人员反复使用的方法沉淀下来，让 Agent 面对相似任务时，不必每次重新发明分析过程。
但 Skill 也不能变成一张固定检查清单。如果每次销售下降都机械地查询销售、库存、供应商、天气和舆情，得到的不是深度分析，而是更多无关结果。
真正有用的 Skill，应该让 Agent 知道什么时候继续、什么时候转向，以及什么时候证据不足，需要停止推断。
知识库中适合保存的是企业制度和组织经验，例如：
•重点产品认定标准；
•安全库存与缺货规则；
•供应商履约要求；
•促销活动说明；
•业务术语和管理办法；
•历史分析案例与处置经验。
这些内容可以帮助 Agent 理解企业真实的经营环境。但知识库不能代替数据计算。
文档中写着“可售天数低于 7 天属于库存预警”，并不能证明产品 A 当前已经低于 7 天。前者是判断规则，后者必须由当前库存和销售数据计算得出。
因此，企业语义模型仍然应该承担可信计算，知识库提供规则和解释，二者不能混为一谈。
03
很多 Data Agent 的问题，并不是完全没有正确的信息，而是正确的信息出现得太早、太晚，或者出现在了错误的分析环节。
还是以“重点产品 A 为什么销售下降”为例。一个真正有业务分析能力的 Agent，不应该一开始就把所有可能因素都列出来，而应该逐步建立证据。
首先，它需要确认企业所说的“销售下降”对应哪个正式指标，比较的是同比、环比还是某个业务基线。
其次，它需要通过真实数据确认下降发生在哪些产品、区域、渠道和门店，而不是直接从知识库中检索一份“销售下降的常见原因”。
如果下降主要集中在部分门店，并且同期出现了低库存，再进入库存变化和补货过程分析才有意义。如果库存正常，就应该回到价格、促销、渠道或客户变化等其他方向，而不是为了完成既定流程，强行寻找供应商问题。
在这个过程中，知识库中的安全库存规则、促销计划和供应商履约标准，应当在对应问题出现时参与判断；Skill 负责保持分析方法的一致性；真实数字仍然回到企业已经治理的语义模型中计算。
最终输出也需要区分不同强度的结论：
•哪些是数据已经确认的事实；
•哪些是同时发生、值得关注的相关因素；
•哪些只是有待进一步验证的假设。
这才是“懂业务”在数据分析中的具体表现。
不是能够说出更多原因，而是知道每一个判断需要什么证据。
04
大模型的发展，让企业可以给 Agent 提供越来越多的上下文。但在 Data Agent 场景里，上下文数量和业务理解能力并不是简单的正比关系。
企业可能拥有几十个语义模型、上千个指标、数百份制度文档和多套分析方法。如果把这些内容一次性全部交给 Agent，反而会带来新的问题：
•同名指标相互竞争；
•已经过期的制度影响当前判断；
•不同部门的分析方法被错误混用；
•Agent 选择了不相关的数据模型；
•分析过程越来越长，却越来越难解释。
我们认为，企业级 Data Agent 需要的不是“最大上下文”，而是与当前问题匹配的“有效上下文”。面对一次具体分析，它只需要获得完成当前任务所必需的指标、业务对象、关系、方法和规则。
不是最大上下文，而是与当前问题匹配的有效上下文。
这也是为什么，企业不能只关注知识库里放了多少文档、Agent 连接了多少工具，还需要关注三个更实际的问题：
1.Agent 有没有识别到正确的业务对象和指标；
2.Agent 有没有按照适合当前问题的方法展开分析；
3.最终数字和结论能不能回到企业数据与业务依据中复核。
05
我们在规划智能小V时，一个持续坚持的判断是：企业并不缺一个更会组织语言的聊天工具。企业真正需要的，是一个能够在既有数据资产和业务规则之上，完成可信分析的 Data Agent。
因此，智能小V并不试图用知识库重新解释所有指标，也不让大模型重新发明企业已经治理好的计算逻辑。
企业已有的 Power BI、SSAS 等语义模型，继续负责 Measure、DAX、数据关系、权限和真实计算。
在此基础上，指标语义本体帮助 Agent 理解指标的业务含义、业务对象之间的关系，以及当前问题所处的业务上下文；Skill 沉淀可复用的分析方法；知识库提供制度、规则和企业经验。
智能小V希望解决的，是让这些不同类型的业务资产在一次真实分析中各自承担正确的职责。我们更关心的不是 Agent 调用了多少模型、查询了多少数据，而是：
使用的指标有没有明确口径，展开的分析有没有业务依据，引用的知识有没有来源，得到的数字能不能复核，形成的结论是否与证据相匹配。
从这个角度看，“更懂业务”并不是一个抽象的模型能力，而是一套可以被建设、验证和持续改进的企业分析机制。
06
如果企业必须先完成全域指标治理、整理全部业务文档、建立所有分析 Skill，才能启用 Data Agent，那么大多数项目都会停在准备阶段。
更现实的方式，是从一个真实、重要、能够验证的业务场景开始。
例如先选择商品销售分析、库存异常分析或供应商履约分析，复用企业已经成熟的语义模型和报表，梳理其中最关键的指标和业务对象，再把优秀分析人员处理这类问题的方法沉淀成 Skill。
在真实任务运行过程中，企业会逐步发现：
•哪些指标定义仍然存在歧义；
•哪些业务关系尚未确认；
•哪些制度已经过期；
•哪些分析步骤缺少数据支持；
•哪些判断可以稳定复用。
这些问题被不断修正，企业的语义、知识和分析方法也会随之完善。Data Agent 的建设因此不再是一次漫长的“知识准备项目”，而是围绕真实使用逐步扩大业务范围的持续过程。
语义层、Skill 和知识库，正在成为企业 Data Agent 的重要基础。但把三者连接起来，并不会自动产生一个懂业务的 Agent。
语义层要保证 Agent 使用企业确认的业务语言，Skill 要让 Agent 按照专业的方法工作，知识库要让分析符合企业真实的制度和经验，当前事实则必须回到可信数据中计算。
只有当定义、方法、规则和事实能够在正确的分析环节协同，Agent 才有可能从“知道很多”，走向“做出可信的业务判断”。
这也是智能小V希望推动的方向：
不只是让企业数据可以被 Agent 读取，而是让指标有口径、分析有方法、知识有来源、数字可复核、结论有证据。
当这些能力逐步进入企业的数据分析体系，Data Agent 才真正具备走进经营现场、承担实际分析工作的基础。
想让 Data Agent 真正读懂你的业务？
申请试用，与顾问聊聊你的场景 →
在线咨询
