一个 Data Agent 能回答“本月成本是多少”，不代表它已经能帮助企业做成本管理。成本上升后，业务人员会继续问：增加发生在哪个环节，为什么发生，接下来该怎么处理？数字查对了，归因却可能仍然来自模型的一般性经验，而不是企业当前的数据。

本体能否帮助 Agent 跨过这一步，是我们在建设 OceanBase DataPilot 时面对的具体问题。

查询一个数字，需要可靠的数据连接、指标口径和查询生成；

解释变化，还需要理解业务对象之间的关系，并找到可以核实的证据；

辅助后续行动，则要知道哪些流程和工具可用，以及操作的权限边界。

我们逐渐认识到：让 Agent 理解企业的业务世界，不能只把表结构翻译成自然语言，还需要让业务对象、关系、知识和可执行能力形成一套可验证、可维护的共同语言。

这也是我们探索本体技术的出发点。

本体（Ontology）不是大模型时代才出现的新技术。

它原本是知识表示与数据互通的一种方法：先明确一个领域里有哪些对象、各自具有什么属性、彼此是什么关系，再为这些概念约定一致的含义。W3C 的 OWL 本体语言就是这一传统中的一种标准表达方式。

注：本文讨论的企业本体侧重业务建模，并不意味着产品必须采用 OWL。

它要解决的老问题是：同一个“客户”可能散落在多套系统、拥有不同名称和口径，业务人员理解的是一个完整对象，数据系统保存的却是分散的记录。没有一层共同语义，人和软件就很难稳定地共享、复用这些知识。

大模型让这道老问题变得更迫切。AI 能生成查询和分析文字，却不会天然知道企业内部“成本”如何计算、“客户”包含哪些记录，或某个判断应沿着什么业务关系核实。缺少这层上下文，它可能答出一个数字，却给出似是而非的归因；缺少对权限和操作的描述，也难以安全地进入后续业务流程。

过去本体建模与维护的人工成本很高，如今大模型也有机会辅助抽取和整理业务知识，减少其中的重复劳动。而在用户增长等场景中，业务对象还需要连接到受控的行动，才能从“可查询”走向“可运营”。

在面向企业 Agent 的产品探索中，本体不仅用于整理概念与关系，也成为组织业务对象、分析能力和行动能力的一种方式。

Palantir 的 Foundry 就通过对象、关系和行动来表示企业的业务世界；不同产品也在探索更轻量、从具体场景逐步生长的路径。但行业尚不能把“自动建好本体、交给 Agent 自行决策”当成成熟答案。关于大模型辅助本体工程的系统性综述也指出，评测方法不统一、结果难以复现，以及如何结合模型自动化与人工专家经验，仍是需要解决的问题。

因此，当前更可行的重点是从高价值场景出发，让模型辅助建模、让专家校验，并用真实业务反馈持续修正。

DataPilot 最初面对的是一个很具体的问题：如何让自然语言问数足够准确。

传统的做法是建设语义层，为数据表、字段和指标补充业务定义，让模型知道“客户”“成本”“收入”在企业内部究竟指什么。这个方向是有效的。模型有了可靠的业务语义，才更可能把用户的问题映射到正确的数据和口径上。

但用户的期待不会停留在“给我一个数”。他们会继续追问“为什么”，希望看到归因、判断和下一步建议。此时，如果 Agent 只掌握表和指标的名称，分析很容易退回到大模型的一般性经验：文字看起来合理，却未必与企业当前的数据和业务过程相符。对于经营决策而言，这种“像是对的”并不够。

本体提供了一种进一步组织语义的方式。

它以业务对象为中心，描述对象的属性、对象之间的联系，以及围绕对象能够进行的查询、分析或操作。这样，Agent 面对的不再只是分散的数据表和工具清单，而是一个有业务含义、可追溯到数据与规则的工作空间。

语义层和本体并不是对立关系。我们更愿意把本体理解为一种面向业务对象的语义建模方法。关键差别不在于有没有字段说明，而在于 模型的组织中心从底层数据结构转向了真实业务对象。

以“用户”为例，企业数据库中可能有用户基本信息表、详细信息表，以及来自不同系统的用户记录。某一张表未必等于业务人员所说的完整“用户”。

在本体模型中，“用户”可以由多处数据经过关联、合并和口径统一后形成；它还可以与订单、合同、服务记录等对象建立关系。业务人员询问“某类客户的成本为什么上升”时，Agent 才有机会沿着这些关系找到对应的数据证据，而不是根据一张表的名字猜测答案。

同样，企业知识也不只有结构化数据。指标定义、业务规则、文档、分析方法和工具接口，往往散落在不同系统中。本体的价值是为它们提供相对一致的业务语义，让 Agent 在同一问题下知道该查什么、如何解释、哪些能力可以调用。这里的目标不是把所有系统物理上合并，也不是宣称一个模型能自动消除所有歧义，而是减少业务语言与数据、知识、工具之间反复“翻译”的损耗。

在 DataPilot 中，我们已经把业务对象、属性、关系和指标纳入语义层。

本体不是另起一套与产品割裂的体系，而是在这些语义资产的基础上，逐步形成 Agent 可以使用、可以治理、可以持续演进的业务模型。

本体的价值容易理解，难点在于构建和维护。我们曾在内部成本分析场景做过一轮验证：

由既懂成本业务、又熟悉本体方法的人员参与人工建模，形成较准确的初始模型仍花了约两周。

这是这个具体场景的建模经历，不是通用的建设工期。它提醒我们，一个平台不能假设每位客户都拥有同时精通业务和本体建模的专家。

在这轮验证之后，我们把人工建模中可复用的经验沉淀下来，借助大模型的推理能力辅助识别业务对象、关系和规则，先形成初阶模型，再由业务专家验收、补充和纠错。这里“自动构建”要减少的是重复劳动，而不是让模型替业务人员决定正确的业务定义。业务目标、口径和可采取的行动，仍需要人来把关。

我们也配套了问答回流工具，将用户使用中的问答结果和纠错反馈带回建模过程。初始模型不必一次覆盖所有问题，但需要在真实使用中持续修正：对象映射是否正确，关系是否完整，分析路径是否符合业务。把辅助建模、专家验收和使用反馈接起来，本体才能从“刚好可用”逐步走向“稳定好用”。

在我们的实践中，大模型既参与整理和建立业务语义，也成为这些语义的直接使用者。本体因此不应只是一项前期数据工程，而应与 Agent 的日常使用形成闭环。

如何判断一套本体是否建成？我们的答案是：把它放进最小可行的真实业务场景中，看它能否改善结果。

内部成本分析就是一个例子。

原有方式可以给出成本变化的数字，但在追问原因时，分析可能滑向缺少企业数据支撑的概括。

在本体化建模后的最小可行场景（MVP）验证中，Agent 已能进一步区分成本变化来自云上运行成本、未及时释放的开发资源，还是特定客户带来的增量需求。

这个结果来自具体业务场景的验证，并不意味着任意场景都能得到同样准确的归因。重点并非预设哪一个原因正确，而是 每一种解释都应对应可检查的数据与分析路径。

对象之间存在关系，并不意味着它们天然构成因果关系。本体能帮助 Agent 找到相关数据、组织分析路径，但“为什么上涨”的判断仍要结合指标口径、明细数据和业务规则核实。例如，怀疑开发资源未释放导致成本增加，就应核对资源状态、使用记录和费用明细，而不能仅凭资源与成本对象之间有一条关系就下结论。

因此，评价本体对 Data Agent 的贡献，至少要看四件事：

• 答案是否更可靠；

• 归因路径是否可追溯、可复核；

• 业务人员能否据此作出判断和行动；

• 行动后的结果能否再反馈到系统。

只展示一张关系图，或者在演示中回答几个预设问题，不足以证明它已经进入业务流程。能够在日常使用中持续创造价值，才是真正的检验标准。

这也是“从问数走向辅助决策”的准确含义：我们希望 Agent 更好地辅助人的判断，而不是替人承担未经验证的决策。

在能力治理上，我们把只读分析和执行类操作分开考虑。涉及写回系统、触发流程等有副作用的操作，需要执行前的人工确认，以及明确的权限和审计边界。Agent 给出了建议，不代表它就获得了执行权限；写回和外部集成也需要随着治理能力的成熟逐步开放。

企业知识会变化。业务规则更新、指标口径调整、系统结构迁移，都可能让一条曾经正确的关系逐渐失效。更隐蔽的问题是：有些知识长期无人使用，团队便很难察觉它是否过期，等到 Agent 再次调用时才暴露错误。

我们关注两条相互连接的路径。

第一条是使用回流：记录 Agent 解决问题时实际经过了哪些业务对象和关系，收集被确认的好案例与错误案例，让维护者知道哪些知识有效、哪些知识需要修订。

回流反馈也不能直接视为正确知识。

不同用户可能给出互相冲突的解释，同一条反馈也可能只在特定业务条件下成立。更稳妥的做法是先把反馈整理成待确认的修订建议，由熟悉业务口径的人判断适用范围，再决定是否更新共享模型。使用得多，可以增加发现问题的机会，但不能替代知识确认。

第二条是促进复用，这是我们继续探索的方向：先从一个业务领域构建能够解决具体问题的本体，再把经过使用验证的高质量知识沉淀为可共享的资产，供其他相关领域参考和订阅。

后者不是简单地把各部门模型拼成一张大图。不同领域可能对同一对象有不同定义，跨领域融合仍需要处理口径、权限与冲突。

我们的方向是让高质量知识在受控条件下被更多场景使用；使用带来更多反馈，反馈推动更新，更新再支撑新的场景。这个飞轮能否真正转起来，取决于业务人员是否愿意持续使用，以及产品能否把反馈变成有效的模型改进。

本体技术对 Data Agent 的意义，不在于创造一个更大的名词，它要解决的是一个长期存在的断层：企业已经积累了数据、规则与流程，Agent 却常常只看见表名、字段名和零散接口。

OceanBase DataPilot 的探索路径，是从用户实际提出的业务问题出发，以语义层为基础，把对象、关系、指标和可复用的分析能力逐步组织起来；借助模型降低建设成本，同时保留专家校验；再通过真实使用和反馈，持续验证并更新这些资产。

我们相信，只有当 Agent 能沿着可信的业务语义完成查询、解释和辅助行动，本体才不只是静态的知识图，而会成为企业 AI 应用可生长的基础。

如果你正在评估本体是否适合自己的 Data Agent，不必先把企业全部知识建成一张图。可以从一个反复出现、需要追问原因的业务问题开始，明确对象、指标口径和可核实的分析路径，再观察答案是否更可靠、错误是否更容易定位。先让一个具体问题得到更可信的回答，再根据使用反馈扩展模型，比一开始追求完整的关系图更有意义。

立即试用 OceanBase 企业版，体验国产数据库能力 立即试用