作者｜沙丘智库研究团队
来源｜沙丘社区（www.shaqiu.cn）
本体到底是一种新产品，还是知识图谱换了个名字？看过几家大厂的介绍，这个问题可能更难回答了。
阿里云RDS AI可以根据数据库结构推断对象、关系和动作类型，再生成Agent可加载的Skill。同在阿里云，UModel关心的却是另一个问题：服务出了故障，Agent怎样沿着服务、容器和主机之间的关系找到原因？
两者都涉及本体，却很难放在同一张功能表里直接比较。
类似的差异也出现在火山引擎、百度、SAP和Palantir之间。有的重点介绍知识如何组织，有的从既有业务应用出发，有的已经具体到Agent以谁的身份调用哪个动作。
近期，“本体”正成为一个被共同使用、交付范围却不一致的产品用语。企业若按这个名字采购，很可能把本来不同的建设任务，当成了同一种产品的不同报价。
01
同在阿里云，一个帮助建模，一个服务于故障诊断
RDS AI从数据库结构中推断对象类型、关联类型和动作类型，允许用户预览、调整，再注册本体并生成Skill。这套流程试图减少开发者把数据库接入Agent时的建模和配置工作。
这里有个容易被忽略的细节：推断结果还要经过调整。数据库中的表和外键提供了线索，但业务规则未必都写在表结构里。
例如，“客户”在销售系统里可能指签约主体，在服务系统里可能指实际使用方。自动建模可以发现两边各有一张客户表；究竟按谁来统计客户、两者如何关联，仍要由业务团队确认。这个工作量不会因为生成了一份Skill而消失。
因此，RDS这条路径首先值得验证的是：从数据库到可用业务模型，人工整理和修改的工作能减少多少。文档中的示例数据由大模型生成，不能把演示里的数值当作客户成效。
UModel则把问题收得更窄。它面向可观测性，将服务、容器、主机及其关联组织起来，并连接日志、指标和链路数据。对故障诊断Agent来说，知道某条异常日志属于哪个服务、这个服务依赖什么，比单独多查几条日志更有意义。
这条路线已有具体实验可看。UModel团队在2026年6月发布的论文中，用138个注入故障比较传统数据模型与UModel，两组均采用Qwen3-max。包含冗余惩罚的根因定位指标LA从55.96升至64.08，增加8.12分。团队还说明，为保证比较能够进行，传统方案已被预先提供所需的可观测性数据。
图片来源：UModel研究团队论文《UModel: An Agent-Ready Observability Data Modeling Method at Scale》，第8页表IV。截图保留原表，LA行对应上文的55.96、64.08与8.12分增量。
至少在这组披露的测试中，数据拿得到之后，如何组织对象、关系与分析工具，仍会影响Agent定位故障的表现。它给出了领域任务上的证据，尚不能据此推算企业全面建设本体的收益。
RDS与UModel的差别由此清楚了：前者的文档展示如何生成并调整模型，后者的研究检验一套领域数据模型如何支持诊断。两条路线连验收重点都不同。“是否支持Ontology”这个勾选项，装不下这些差别。
火山引擎DataAgent的提供了另一种观察角度。它的本体语义构建功能围绕对象类型、实例、属性和关系展开，配置项涉及知识库、主键及属性来源。读这份文档，最容易看清的是资料如何被组织成可查询、可管理的业务对象。至于这些对象随后如何参与执行，还要结合相应的运行和集成能力判断。
SAP的出发点更接近企业已有的业务应用。其AI原生架构文档把业务语义、API、数据产品元数据与客户扩展放进基础层，并提出共享企业本体、连接领域知识图谱的长期愿景。对这条路线，企业要追问的是现有应用中的业务定义能复用多少，而不能把愿景中的每一项都当作当前可交付的功能。
图中是按专家调研与公开材料呈现的主要入口归类，包含下文讨论的百度与Palantir。各类能力可以交叉，不代表厂商排名或完整产品边界。
这些产品的差异，与厂商过去积累的能力相吻合。数据库厂商从结构和查询入手，可观测性平台围绕运维对象展开，应用层厂商则从业务对象和流程出发。我们的判断是，理解这轮本体产品化，首先要看各家如何用已有平台接入Agent，而非假设市场上突然出现了一批从零开始、可以直接互换的本体产品。
02
从业务建模到业务执行，权限如何控制？
另一个分歧集中在Action。
RDS的建模流程已经涉及动作类型，所以用“国内只有知识查询，国外才能执行”来概括，会漏掉重要事实。但动作类型出现在模型里，还不足以说明一次业务操作将如何受到控制。
以调拨库存为例，定义“发起调拨”这个动作，可以说明它面向什么对象、需要哪些参数。真要提交时，还得确认调用者有无权限、库存是否仍然可用、是否需要审批。这几项检查可能分布在业务系统和Agent运行环境中，需要一起核实。
百度胜算的官方产品页列出了供应链决策、门店经营分析、智能驾驶等应用场景。例如，供应链方案通过接入ERP、MES、PLM等系统，支持风险识别、异常分析和替代料推荐；门店经营方案则围绕客流、转化率、客单价等因素分析经营问题。页面还列有大模型训练、RAG知识库和数据中台升级等用途。
对应这些场景，百度在产品架构中设置了本体管理、逻辑建模和闭环执行三部分，并将权限控制、沙箱与审计列为运行保障。
图片来源：百度智能云“百度胜算”官方产品页。本体管理、逻辑建模与闭环执行位于应用层，底层另设安全与权限等能力。
Palantir在2026年6月的Ontology MCP公告中说明，企业在Foundry中已有的对象类型、动作类型和函数，可以作为MCP工具开放给Agent。每次调用都使用已认证用户的现有Foundry权限。也就是说，Agent接入后仍受原有权限约束，企业需要提前配置好相应的对象、动作与访问权限。
我们建议企业选一个准备上线的场景验证。例如，计划让Agent发起库存调拨，就请供应商演示它如何读取可用库存、校验权限、提交审批，以及在接口超时后确认调拨是否成功。需要新接哪些系统、补哪些配置，也一并列进实施清单。这样才能判断方案能否满足业务要求，以及从演示到上线还需要多少投入。
03
本体项目里，企业究竟在为什么付费
把上述差异带回一个具体问题：企业已经有ERP、数据平台和几个Agent，还需要再建一层本体吗？
单凭大厂开始提供这些功能，得不出购买结论。RDS式的路径要证明建模工作有所减少；UModel式的领域方案要证明目标任务做得更好；接入动作的方案则需要说明，企业还要投入多少工作，才能让原有权限和业务规则在Agent调用时继续生效。
这些收益不能相互替代。建模快了，不代表故障更容易定位；动作能调用，也不代表多个Agent对同一个业务指标已经采用相同口径。
仍以库存为例。如果采购Agent、销售Agent和计划Agent各自维护一份“可调拨量”的解释，每增加一个Agent，企业就多出一份定义和一份变更工作。假如本体建设能让它们复用经业务确认的口径，并在规则变更时同步更新，这才出现了一项可以验证的共同收益。它可以落实在已有平台，也可能需要补建，名称并不决定部署位置。
检验这种收益，需要观察一项具体变更：口径改了以后，有多少处要人工修改，哪些Agent受到影响，谁负责确认修改完成。第一次建模的演示看不到这些，长期维护却会不断遇到。
这也是沙丘智库在《企业本体研究报告：Agent业务语义层的建设与落地》中单独讨论工程效率的原因。对象图画得多大、生成了多少定义，都不直接回答维护成本有没有下降。
图中框架源自沙丘智库《企业本体研究报告：Agent业务语义层的建设与落地》
UModel的实验可以放在这里理解：它提供了任务质量的证据，后续仍要计算部署和维护成本，再观察业务结果。企业自己的试点也一样。若同时更换模型、清洗数据、补齐接口，成效应先归于整套改造；没有进一步对照，就不宜全部记在本体名下。只读项目不必为了显得完整而增加执行环节，读取权限仍须检查。
当模型更换、Agent增加时，企业就要重新检查：过去确认过的客户身份、指标口径和业务规则，能否继续使用？本体值得投入多少，很大程度上取决于它能否减少这些重复建设，以及企业能否持续维护这些定义。
从这个角度看，大厂之间真正值得研究的差异，是业务定义放在哪里、谁有权修改、怎样被Agent使用，以及使用它需要先具备什么条件。只比较功能列表，很容易低估接入现有系统和持续维护的工作。
对正在将Agent接入业务流程的企业，下一步应明确哪些业务定义可以复用、哪些规则需要补建，再据此确定本体的建设范围。沙丘智库《企业本体研究报告：Agent业务语义层的建设与落地》进一步讨论的，正是这些定义应由现有平台承载还是另建、业务与技术团队如何分工，以及试点达到什么条件才值得扩大。看清大厂的差别之后，企业还需要算清自己要补的那一段。
参考资料：
〔1〕阿里云：《知识图谱-Ontology能力》https://help.aliyun.com/zh/rds/apsaradb-rds-for-postgresql/knowledge-graph-ontology-capabilities
〔2〕阿里云：Cloud Monitor—UModel Overviewhttps://www.alibabacloud.com/help/en/cms/cloudmonitor-2-0/overview/
〔3〕UModel研究团队：UModel: An Agent-Ready Observability Data Modeling Method at Scale，2026年6月3日https://arxiv.org/abs/2606.04799
〔4〕火山引擎：《本体语义构建》https://www.volcengine.com/docs/86760/2479044
〔5〕SAP：AI-Native North Star Architecture—Foundation Layerhttps://architecture.learning.sap.com/docs/ai-native-north-star-architecture/foundation-layer
〔6〕百度智能云：百度胜算官方产品页https://cloud.baidu.com/product/databuilder?track=2026create
〔7〕Palantir：June 2026 Announcements—Ontology MCP is now generally available，2026年6月25日https://www.palantir.com/docs/foundry/announcements/2026-06
更多AI研究内容可前往【沙丘智库小程序】搜索查阅