本文根据 DataFun 与云器科技联合分享「Agent 要懂业务，知识从哪里来？」整理，分享人为云器科技 AI 产品负责人巴志欣，扫描下方二维码获取 PPT。

从知识接入、蒸馏到管理，看云器如何连接企业业务含义与数据实现。

企业已经积累了大量数据、SQL、报表和业务文档。当 Agent 接入这些资产后，一个看似简单的问题，仍可能得到不同的答案。

例如，“统计本月新车销量”。业务文档将其定义为当月签订购车合同的订单数，数据加工链路统计的是已付定金且未退订的订单，历史查询却按本月交付的车辆去重计数。这些结果都可能由合法的 SQL 计算得出，但它们并不一定在回答同一个问题。

问题不只是 Agent 能不能找到表、能不能写出 SQL，更在于它是否知道：业务说的“销量”指哪个阶段，采用哪个时间字段，哪些状态需要排除，以及这套定义适用于什么场景。

数据记录业务发生了什么，业务知识则决定如何理解和使用这些数据。 对企业 Agent 而言，接入数据只是起点，还需要把散落在文档、查询和加工链路中的定义、规则与经验，转化为能够被验证、追溯和复用的知识。

在云器的知识工程方案中，这项工作由知识接入、知识蒸馏和知识管理衔接完成。它要解决的不是“再建一个文档库”，而是让企业已经积累的信息，真正进入 Agent 的数据开发与分析过程。

知识建设的起点，不是把所有材料都交给模型

企业开始建设语义层或业务本体时，往往首先遇到一个实际问题：到底应该提供什么？

报表、代码、业务 Wiki、群聊都可能包含有用信息，但材料越多，不代表知识越可靠。输入不足，Agent 缺少必要的定义与约束；输入过多，过期口径、重复描述和相互矛盾的说法又可能一起进入分析过程。

云器在实践中将几类信息作为重要的知识输入。

已经被业务实际使用的报表查询 ，能够反映被消费和认可的取数逻辑。稳定运行的数据加工 Pipeline ，能够说明指标在数据上究竟如何计算、依赖哪些上下游表。指标口径文档 记录业务定义、统计规则和适用范围，但需要核对版本，确认它与当前数仓实现一致。企业内部的业务术语和黑话 ，则用于补齐业务表达与数据定义之间的差异，避免模型仅凭字面含义猜测。

这些来源各自提供不同证据，不能简单地互相替代。SQL 能说明“怎么算”，未必完整说明“为什么这样算”；业务文档能说明意图，也可能没有跟上底层表结构的变化。

因此，在产品所设计的接入流程中，多源信息进入后，还需要按知识类型识别、拆分，并从覆盖度、完整度、可对齐性、时效性和噪声等方面做预评估。发现缺少查询目的、业务词条无法对应到数据字段，或口径长期未更新时，应先提示补充和核实，而不是直接进入后续构建。

回到“新车销量”的例子，仅上传一段 SQL，模型也许能推测它在统计什么，却无法可靠地判断它代表订购、有效订单，还是最终交付。把查询对应的报表、指标名称和业务目的一起提供，才为知识构建补上了关键上下文。

同名指标有多个定义，不一定意味着只能保留一个

当多源信息接入后，另一个问题会浮现：同一个指标名称，可能存在多套计算逻辑。

对于“新车销量”，按签约订单统计，可能用于观察订单获取；按已付定金且未退订的订单统计，可能用于观察有效订单；按交付车辆统计，则用于观察实际交付。这些差异有可能来自合理的业务分工，也可能来自定义已经调整、文档却没有同步，或加工逻辑出现遗漏。

图 1｜同样叫“新车销量”，业务文档、加工链路和历史查询可能采用不同定义。（图中销量用于口径差异示例，不代表本文核验的客户经营数据。）

因此，治理不能仅凭名称相似就合并指标，也不能因为某段 SQL 能运行，就认定它代表当前有效口径。真正需要确认的是：定义是否有效、服务什么场景、采用什么时间和状态约束，以及有哪些依据支撑。

这也是知识工程与信息抽取之间的一条重要分界。把几种定义找出来，只是识别了候选信息；判断它们应当分别保留、更新还是纠正，还需要结合业务目的和数据实现。

云器的处理思路是，让能够确定的信息进入标准化加工，对无法自动判断的口径冲突保留来源，并交由相关人员确认。人工参与的重点不是重新整理每一段材料，而是裁决系统无法确定的业务含义与适用边界。

知识蒸馏：从“抽到了信息”到“Agent 可以使用”

这里所说的知识蒸馏，是把企业多源信息加工为可供 Agent 使用的知识资产。它不是让模型概括一遍文档，而是一条包含抽取、转换、索引、评估和服务的工程链路。

图 2｜从候选信息到可用知识，需要完成数据绑定、证据索引和质量评估。

首先，抽取候选信息，并保留出处。 文档里的业务定义、SQL 中的过滤条件、Pipeline 中的加工关系，都可以成为候选。但在这一步，它们还不能直接被当作已经确认的知识。

接着，把业务表述绑定到真实的数据实现。 一个指标描述得再清楚，如果无法对应到当前数仓中的表、字段和计算逻辑，仍不能直接支撑查询。它可能引用了已经下线的表，也可能描述的是尚未完成建设的新需求。转换环节需要检查这些对应关系，识别相似对象和口径差异，并将无法确认的部分交给人工处理。

再通过索引保留证据链。 结构化定义与原始材料需要保持关联。当用户质疑一个指标时，应当能够追溯到对应文档的具体出处，或相关的加工链路。这样，口径确认就有了依据，而不是让人面对模型生成的结论再次猜测。

最后，用业务问题检验产出。 知识是否可用，不能只看定义是否完整，还要看它能否支持真实的查询任务。云器在分享中介绍了使用标准问答测试集评估蒸馏结果的方式：将产出与经过确认的问题、答案和取数逻辑对照，检查口径约束是否正确。

这些测试样例可以从已有报表查询、历史分析任务中梳理，再由企业确认，并尽量贴近 Agent 后续要承担的业务场景。有限测试集的结果不能直接外推为开放场景下的准确率保证；知识尚未覆盖的问题，仍需要补充信息和验证。

这条链路的核心，是用工程流程约束模型输出：模型可以参与理解、抽取和比对，但一个定义能否成为可用知识，还要经过数据映射、冲突确认与质量评估。

让业务和数据共同确认知识，而不是各自维护一套解释

完成蒸馏后，知识该以什么形式管理？

如果只给业务人员看表结构和 SQL，他们很难判断业务流程是否完整；如果只给数据人员看概念描述，又不足以确认取数逻辑能否落地。云器在方案中通过三类相互关联的产物，分别承接这两种视角。

业务本体（Ontology） 面向业务人员和领域专家，表达业务对象、属性与关系。例如，在汽车销售场景中，区分购车订单、车辆和交付，明确“订购”与“交付”的业务含义。业务人员可以据此确认对象和关系是否符合实际，补充流程中缺失的约束。

语义视图（Semantic View） 面向数据开发和分析人员，表达数据集、字段、维度、指标及关联关系，把业务口径落实为具体的状态过滤、时间选择和去重规则。数据人员据此检查，这套定义是否与真实数据一致。

业务数据映射（Mapping） 连接两者，将业务对象、属性和关系对应到语义模型中的数据实现。它使 Agent 不仅知道“交付”是一个业务环节，也能找到支撑该环节分析的具体数据定义。

三者不是三份彼此独立的文档，而是同一套知识的不同视角。业务负责判断含义是否成立，数据负责判断实现是否正确，映射关系则让这两类判断能够对应起来。

在分享展示的架构中，这些能力由知识引擎 SingKnowledge 承接，底层连接云器 Lakehouse，上层服务面向数据开发的 Data Agent、面向数据分析的 Analytics Agent，并设计了与企业自有 Agent 对接的路径。知识因此不只用于解释问题，也可以继续约束后续的数据生产和消费。

图 3｜分享所展示的知识工程架构：在 Lakehouse 数据底座之上，通过知识引擎连接数据开发、分析与企业自有 Agent。

欢迎扫描下方二维码，优先体验云器知识蒸馏能力。

从“成功率是多少”到“为什么用户仍然觉得不好用”

为什么仅有指标定义还不够？一个远程开空调的例子，可以说明业务流程与数据口径之间的差距。

用户在 App 上点击“开空调”，背后可能依次经历平台能力校验、唤醒车辆、下发指令、车端检查和执行返回。假设现有报表只覆盖下发指令之后的环节，那么它统计的就不是用户从点击开始的完整体验。

在分享课件的示意数据中，1,000 次发起操作经过平台校验和车辆唤醒后，有 750 次进入指令下发，最终 735 次执行成功。

按指令下发后的口径计算，成功率为 735 ÷ 750＝98% ；按用户发起操作的全流程计算，成功率则为 735 ÷ 1,000＝73.5% 。

以上为说明口径差异的示意数字，不代表客户实测结果或产品性能。

图 4｜只统计指令下发后的成功率，与从用户点击开始统计，观察的是不同范围。

两个比例的计算都可以成立，但回答的是不同问题。只看后半段指标，Agent 可能判断执行成功率很高；结合完整业务流程，才会注意到前置校验和唤醒环节尚未被当前指标覆盖。

课件进一步设置了一个业务条件：部分车型配置不支持远程空调，App 却仍展示操作按钮，用户点击后在平台校验环节被拦截。如果这条规则没有与数据关联，Agent 就很难解释，为什么报表指标看起来正常，用户仍然反馈功能不可用。

这正是本体、语义视图与映射关系共同发挥作用的地方。语义视图说明指标计算覆盖什么；业务本体补充流程、对象和限制条件；映射关系帮助 Agent 将业务环节与相关数据对应起来，形成有依据的排查路径。

分享中的产品 Demo 也沿着这条路径展开：先从带有业务目的的历史查询构建语义资产，再在数据开发中使用这些定义约束指标与加工逻辑，最后将业务知识和数据结合，用于远程调控问题的分析。

从分析方式看，这里既包含按区域、车型等维度逐层定位异常，也包含沿业务流程追踪相关环节。前者帮助确定问题集中在哪里，后者帮助补充可能的业务解释。对于已经有明确排查规范的特定场景，还可以把既定分析路径和策略沉淀为知识，供后续任务参考。

需要注意的是，有依据的诊断和排查，并不等于已经完成严格的因果证明。知识与数据的结合，首先让分析过程更完整、结论更可检查，而不是让模型跳过验证直接下结论。

知识不是一次性建成的，还要跟着业务变化

企业知识会过期。表可能下线，字段可能调整，指标可能改版，业务流程也可能增加新的环节。如果知识仍停留在旧版本，Agent 即使严格遵循已有定义，也可能给出不再适用的答案。

因此，存量信息的蒸馏只是冷启动。分享中介绍的后续维护思路，是通过变更追踪和应用反馈，识别知识的新增、调整与失效，将需要更新的信息提示给用户，经过确认后再更新知识。

这里需要区分两个动作：发现变化，不等于自动确认新口径。尤其涉及业务含义时，更新仍然需要明确依据，不能仅因为底层发生变化，就由模型自行决定新的组织级定义。

建设范围同样需要控制。与其一开始覆盖整个数仓，不如先围绕目标业务场景圈定数据域和相关 Schema，梳理已经被使用的报表、查询与加工链路，再逐步扩展。对于已经形成稳定明细层和服务层的数仓，也没有必要为了建设语义，把所有原始层字段都直接变成面向 Agent 的查询入口。

这不是降低知识建设的要求，而是让知识范围、验证问题和应用目标彼此匹配。先把一个业务域中的定义建准、用起来，再通过真实反馈持续补全，比单纯追求材料数量更有意义。

企业需要的，是一条从信息到可用知识的链路

Agent 不懂业务，未必是因为企业缺少信息。更常见的问题是，已有信息尚未经过整理、验证和关联：SQL 缺少业务目的，文档没有对应到当前数据，同名指标缺少适用边界，业务流程与统计口径之间又存在断层。

云器知识工程的构建路径，是把这些环节衔接起来：接入时识别信息类型与缺口，蒸馏时完成抽取、映射、溯源和评估，管理时连接业务本体、语义视图与数据实现，再让知识进入数据开发和分析任务，并随业务变化持续维护。

对企业而言，知识工程的价值不在于多生成了多少概念，而在于那些原本需要反复找人确认的定义、规则与经验，能否成为人与 Agent 都能理解、检查和复用的资产。

让 Agent 真正懂业务，起点不是再给它更多材料，而是让已有信息成为有依据、能落地、可维护的业务知识。

---

🎁 新用户专享福利

✅  1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验

➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package