企业AI · Agent · 业务语义
Agent 越来越能干，企业为什么又开始补本体这一课
模型会推理、会调用工具之后，企业开始补一层更基础的能力：让机器理解业务对象、关系、规则和责任。
最近看 Agent 相关的论文和产品文档，会反复碰到一个有点古老的词。
Ontology。
中文通常译作本体。这个译法很学术，第一次看很容易把人劝退。可微软正在 Fabric IQ 里把本体交给 Agent 使用，Palantir 多年来一直把 Ontology 放在产品中心，Google 和 Databricks 也在强调语义层、知识图谱和业务定义。
这些公司用的名称并不完全相同，做的事情却在靠近同一个问题。
企业把越来越多的任务交给 Agent 以后，机器光能找到资料已经不够了。它还要知道资料里的对象是谁，彼此有什么关系，哪种动作被允许，做完会影响什么。
从存下数据，到让机器看懂业务
过去二十多年，企业处理数据时关心的问题一直在变。
数据库解决存储和查询。数据仓库、数据湖把散落在各个系统里的数据集中起来。搜索、知识库和 RAG 又让模型能从大量文档中找到相关片段。
这段历史并没有整齐地分成三个互相替代的阶段。今天的企业仍然同时需要数据库、搜索和知识图谱。变化发生在使用数据的角色上。
过去，人看报表、读文档，再根据经验判断下一步。Agent 开始执行任务以后，中间那段由人补上的常识，也得用机器能够处理的方式表达出来。
这就是本体重新受到关注的原因。
普通 RAG 会找到词，却未必找得到影响关系
拿一个运维场景来说。
公司里有一台 Server-01，上面运行 Instance-01，Application-A 又部署在这个实例上。监控系统发现 CPU 持续升高，值班 Agent 准备重启服务。
普通的向量检索可以找出包含 Server-01、CPU、Restart 的文档片段。它可能找到一份重启手册，也可能找到上个月的故障记录。
可 Agent 在动手以前还得回答几个问题。
Application-A 是否依赖 Instance-01。这个实例还承载了哪些应用。重启需要谁批准。当前时间是否处于变更窗口。应用中断以后会影响哪一类订单。
答案分散在配置数据库、监控平台、工单规则和业务系统里。其中包含对象、关系和约束，单靠几段相似文字很难表达完整。
这里需要补一句。RAG 并非只能检索文档。Graph RAG、结构化查询和混合检索都能处理关系。问题出在最常见的那种"文档切块加向量搜索"上。它擅长召回相关内容，却不会自动获得一套稳定的企业业务模型。
Ontology 可以理解成企业世界的机器说明书
本体通常定义四类东西。
第一类是实体类型，例如客户、订单、应用、服务器和供应商。每种实体带有属性。订单有金额和状态，服务器有位置和运行状态。
第二类是关系。客户提交订单，应用运行在实例上，实例依赖数据库。关系让机器能够顺着一件事找到受影响的另一件事。
规则和约束也会被写进去。例如生产服务器只能在批准的变更窗口内重启，退款金额超过某个数值需要人工复核。
最后还要把这些定义绑定到真实数据。否则本体只是一张画得很漂亮的概念图。
知识图谱和本体也不宜直接画等号。可以粗略理解为，本体负责规定世界里允许有哪些类型、关系和规则，知识图谱保存符合这些定义的具体对象与事实。工程系统里两者经常紧密结合，边界也会因产品而不同。
AgentO 想统一的，是 Agent 自己的世界
2026 年公开的 AgentO 论文把这件事推进了一步。
过去的本体大多用来描述客户、设备和订单。AgentO 描述的对象变成了 Agent、任务、工作流、资源及其依赖关系。
研究者把来自四个 Agent 框架的 66 个工作流映射到一套基于 OWL 和 RDF 的模型中，又测试了工作流重建、跨场景复用与审计等用途。
这项研究给出了一个很有意思的方向。以后团队复用的内容可能会超出 Prompt 文件。一个 Agent 会什么，能调用哪些资源，任务之间怎样依赖，执行过程如何审计，都可以拥有机器可读的统一描述。
不过，66 个工作流的映射实验只能证明这种描述方式可行。它还没有把不同 Agent 框架变成一个通用标准，也没有解决企业里的权限、数据质量和执行可靠性问题。
论文是路标，不是竣工通知。
本体正在从查询背景进入 Agent 的执行过程
更值得留意的变化，发生在工具调用这一层。
传统做法由开发者先写好工具，再把工具名称、参数和说明交给模型。模型根据 Prompt 决定调用哪个工具。
一篇 2026 年的预印本提出了另一种办法。系统从本体定义中生成带类型约束的工具接口，Agent 必须通过这些接口创建和修改知识图谱。参数类型、对象关系和可执行动作因此可以在运行时接受检查。
这条路线有实际吸引力。模型不必在一大段自然语言说明里猜字段含义，错误参数可以更早被挡住，越权动作也更容易留下明确的控制点。
它目前仍是研究方案。把本体编译成工具不能自动消除幻觉，更不能单独解决提示注入。系统还需要身份认证、权限检查、人工审批、执行日志和回滚机制。
几家大厂正在从不同入口靠近语义层
Palantir 的路线最明确。它把 Ontology 定义为组织的 operational layer，把数据、分析、业务对象和可执行动作连在一起。AIP Agent 可以通过 Ontology 资源和平台工具工作。
微软 Fabric IQ 的本体功能会定义实体类型、属性、关系、规则及数据绑定。它还可以通过 MCP 向 Fabric Agent、Copilot Studio 和自建 Agent 提供企业语境。官方文档在 2026 年 8 月仍将这项能力标为预览。
Google 没有在所有产品中统一使用本体这个词。Looker 用语义层管理指标和业务定义，Gemini Enterprise 的 Knowledge Graph 则用实体关系改善搜索和语境理解。Google 公布的内部测试称，Looker 语义层可使生成式 AI 自然语言查询中的数据错误最多减少三分之二。这个数字来自厂商测试，适合看方向，不能直接套到每家企业。
Databricks 的入口又不一样。Unity Catalog 管数据、权限和血缘，Genie Agent 还会使用经过整理的语义定义来理解数据。它更像从数据治理和分析问答逐步补足业务语义。
所以，厂商并没有同时押注一套相同的 Ontology 技术栈。它们的共同动作，是把业务定义、实体关系、治理规则和 Agent 放到更近的位置。
企业现在要不要建设本体
大多数公司不必先成立一个本体工程项目，更不用急着把所有数据重建一遍。
可以从 Agent 眼前必须做对的一项任务开始。列出它会碰到的业务对象，给每个对象确定唯一身份，再画清关键关系。随后补上会改变执行结果的规则，并把定义连接到真实数据和权限系统。
还是前面的重启场景。第一版只需要覆盖应用、实例、服务器、负责人和变更窗口。Agent 能查清依赖范围，找到审批人，并在执行前验证时间和权限，这套小模型就已经有价值。
等相邻场景开始复用同一批对象和规则，再逐步扩展。企业本体需要长期维护。业务改了，定义和数据绑定也要跟着改。没人负责维护的本体，很快会比旧文档更让人困惑。
还有一条边界很重要。文档问答、制度查询和内容搜索如果已经能被普通 RAG 稳定解决，没必要为了赶潮流加一套复杂模型。本体更适合关系密集、需要跨系统判断、会触发真实动作的任务。
Agent 时代，企业开始交付自己的业务解释
数据库保存事实，检索系统帮人和模型找到材料。本体给这些事实补上共享的类型、关系和规则。
当 Agent 只负责回答问题时，语义不够准确，常见后果是答案差一点。等它开始重启服务、批准退款、调整库存或安排生产，同一个误解会变成真实动作。
企业因此需要把过去存在于员工经验、制度文件和系统代码里的业务解释，逐步整理成机器能够读取、检查和复用的形式。
Ontology 这个老词重新出现，大概就是因为机器已经走到了要动手的那一步。
参考材料
• Google Gemini Enterprise 知识图谱说明
— 完 —