一句话回顾为什么 Agent 需要本体本体为 AI Agent 提供了一幅“业务地图”。有了这幅地图的导航Agent 才能在复杂的业务环境中看清方向减少幻觉和错误。01误区本体不是另一个数据库或图谱很多人第一次接触“本体 Agent”时可能会有一个疑惑是不是要把企业所有数据都装进本体里让 Agent 直接查本体这是一种完全错误的想法。本体不是关系数据库或者知识图谱不适合存储海量业务数据。本体的核心价值在于承载业务语义结构与规则也就是 TBox而不是当现实数据源使用ABox。这是“地图”和“仓库”的区别“地图”承载的是业务概念客户、订单、库存等、关系谁依赖谁、谁属于谁、谁拥有谁、规则什么条件可以发货什么客户是VIP、语义映射客户在哪些系统里有对应等等。“仓库”承载的则是海量明细数据、事务更新、分析结果等。本体的定位不是和数据源平行的一条路它不存储数据但它可以作为 Agent 与企业系统/数据源之间的语义层。举一个例子Agent 如果发现需要做一个规则判断比如这个订单能否加急发货不应该“想当然”的推理而可以让本体来告诉你是否符合规则。理解本体的定位非常重要这关联到你如何来应用本体。02本体放到 Agent 系统中长什么样在 Agent 中引入本体本质上并不会改变现有 Agent 系统构建的架构与方法主要的变化无非是你需要在必要的时候借助本体这个统一的语义层来帮助 LLM 完成它并不擅长的部分 — 理解业务语义、判断业务规则、推理业务结果。那么如果把本体放到 Agent 系统中其高层概念架构如下所示在这张图中展示了一些本体在 Agent 系统中的价值和承担职责比如规则引擎比如告诉 Agent 什么算符合“加急发货”的条件。复杂关系推理典型的比如多跳关联 — 如集团股权穿透。充当映射层把业务语言翻译成数据库实现。统一业务视图比如将客户映射到不同系统中的数据实体。查询语义层告诉 Agent 复杂查询怎么查哪些过滤条件和关系。这些用法我们将在下文进行案例实操演示。【 构建基础的本体 Agent】为了让 Agent 能够借助本体最简单的方式是给 Agent 增加本体工具查询业务概念、推理业务规则、查找数据库映射等。用以下技术构建一个DemoAgent 框架LangChain后端数据层PostgreSQL本体存储推理owl文件 owlready2 HermiT 推理机LLMOpenAI Liketools [ # 数据库直接查询 query_customer, list_orders, query_order, # 本体规则推理根据实际需要修改定制 check_shipment_eligibility, check_expedite_eligibility, # 本体规则查询等 get_business_rules, ] system_prompt ( 你是一个本体增强的企业管理助手。你背后接入了基于 OWL 本体的业务推理引擎。 ## 工具选择原则\n - 日常查询客户、订单列表→ 直接用数据库查询工具 - 规则判定能否发货、能否加急等→ 使用本体推理工具 - 基于语义概念查询VIP客户、待处理订单等→ 使用语义概念查询 ## 回答原则 - 推理结果要说明判定依据 - 用简洁清晰的中文回答 ) llm ChatOpenAI(modelgpt-5-mini, temperature0) return create_agent(llm, tools, system_promptsystem_prompt)后续我们都会在这个 Agent 基础上做完善增加新的工具解决新的问题。【是否一定要用到推理机】尽管推理机是本体的重要设施。但在使用本体的过程中也并非每次都一定用到。具体来说本体也有两种不同的使用方式。使用推理机推理不使用推理机查阅场景比如做规则推理、多跳关系推理比如查询“客户”关联的概念、对应的数据实体调用需要调用推理机直接查询属性性能较慢较快实现把实例数据注入交给推理机计算直接读取本体中的定义、属性、注解所以不经过推理机不代表不经过本体。在企业系统中可以灵活根据自身需要来使用本体。03案例一用本体做基本业务规则判断延续上一篇中的场景客户要求对一笔订单进行加急发货如何判断加急规则在这个业务中有两条规则可发货条件订单已占用库存且质检通过可加急条件在可发货基础上客户还是 VIP这两条规则当然可以用 if/else 搞定。但问题在于企业规则很少只有两条也很少永远不变。比如明天可能变成“VIP 且订单金额超过10万才可以申请加急“后天又限定了某些特殊品类不能加急......。很快就会发现规则一旦散落在各个工具函数里代码会越改越碎解释也越来越难。而基于本体的 Agent 做法是首先把“什么才算符合条件”用形式化方式声明出来OWLAgent 按需调用本体里的这些规则做推理Agent 根据推理反馈来决定下一步动作如回复客户【本体定义】使用 Protégé 本体定义工具进行定义并导出成 OWL 文件用于推理在真实应用中通常会使用图数据库。详请参考我们上一篇文章。【推理逻辑实现】Agent 基于本体推理的核心逻辑可以概括成三步从数据库取事实订单、客户、库存、质检状态ABox把这些事实临时注入本体相当于把“各种事实”摆上台面让推理机根据规则分类这笔订单是否属于“可发货”“可加急”这两个类型核心的推理实现大致如下把方法包装成 Tool 给 Agentclass OntologyReasoner: 按需将单笔订单数据注入本体推理后返回业务分类结果。 def reason_order(self, customer_tier, customer_id, order_id, required_qty, allocations): onto self._base_onto self._clear_abox() # 清空旧的临时实例数据 # 1. 注入客户 cust_cls self._cls(VIPCustomer) if customer_tier VIPelse self._cls(Customer) cust_ind cust_cls(customer_id) # 2. 注入库存与质检信息 alloc_inds [] for a in allocations: alloc_ind self._cls(InventoryAllocation)(a[id]) alloc_ind.qcPassed [a[qc_passed]] alloc_inds.append(alloc_ind) # 3. 注入订单并建立关系 order_ind self._cls(Order)(order_id) order_ind.hasCustomer [cust_ind] order_ind.hasAllocation alloc_inds # 4. 调用推理机 with onto: sync_reasoner(infer_property_valuesTrue) # 5. 读取推理结果 return { ready_to_ship: order_ind in self._cls(ReadyToShipOrder).instances(), expedite_eligible: order_ind in self._cls(ExpediteEligibleOrder).instances(), }这里推理机做了什么它根据 TBox 中的等价类定义自动判断这笔订单有库存占用 - 质检通过了 - 属于 ReadyToShipOrder客户是 VIP - 属于 ExpediteEligibleOrder注意这里的判断是本体中规则驱动的而不是把数据让 LLM 来判定。【Agent运行效果】当用户询问“ORD-2024-001 能否加急发货”Agent 的工作流程是Demo的运行效果如下这里可以看到本体带来的可解释性 — 每个结论都能追溯到具体规则而不是 LLM 来自通用知识的模糊解释。每一个推理结果都是推理机根据本体TBox 规则自动分类既不是 LLM 推理也不是 if/else 编码判断。04案例二基于属性组合的多维归类假设这样一个场景需要对产品做自动分拣归类/打标签 — 哪些是危险品、哪些是冷链产品、哪些是出口管控产品、哪些需要特殊处理等等。要做到这样的精准分类当然不难。但问题不在于分类本身而在于很多时候会有维度交叉。 比如某个产品既是危险品又是冷链产品某个产品既需要冷链又是管控物资等等当分类维度变成5个10个复杂度就会上升。传统的做法是用简单的IF/ELSE类似于def classify_product(product): categories [] if product[is_hazardous]: categories.append(危险品) if product[requires_cold_chain]: categories.append(冷链) if product[is_export_controlled]: categories.append(出口管控) if categories: categories.append(特殊处理) return categories不过当规则变复杂时问题就来了产品属性从数据库来分类规则写在代码里 — 两处维护新增一个分类维度就要改代码与回归测试多个不同厂家的 Agent 可能会各自维护一套分类逻辑想知道系统里有哪些分类规则 — 只能翻代码没有统一视图而借助于本体的做法是在本体声明分类业务规则也就是“什么产品是危险品”等从数据库获取数据注入本体做推理得出产品类型一个产品可以同时属于多个类型 — 本体不要求类之间互斥多重分类是默认行为这和传统编程中一个对象只属于一个类型有区别。【本体定义】也就是Tbox的声明用 Protégé 这样的工具定义后导出OWL也可以直接用代码来定义owlready2# 危险品含危险成分 → 自动归类 class DangerousGoods(Product): equivalent_to [Product isHazardous.value(True)] # 冷链产品需要冷链运输 → 自动归类 class ColdChainProduct(Product): equivalent_to [Product requiresColdChain.value(True)] # 出口管控产品受出口管制 → 自动归类 class ExportControlledProduct(Product): equivalent_to [Product isExportControlled.value(True)] # 特殊处理产品 ①②③ 的并集 class SpecialHandlingProduct(Product): equivalent_to [Product ( isHazardous.value(True) | requiresColdChain.value(True) | isExportControlled.value(True) )]这里SpecialHandlingProduct 是三个类的并集不是第四个独立维度。它的 equivalent_to等价类定义 引用了前三个类的条件推理机自动处理这层聚合。【推理逻辑实现】主要的推理流程与上一节案例类似即查询事实 -- 注入本体 -- 推理结果defreason_product_classification(self, products): 把产品属性注入本体推理机自动完成所有分类。 onto self._base_onto self._clear_abox() prod_cls self._cls(Product) # 四个分类类别全部在本体初始化时由 equivalent_to 声明 category_classes { DangerousGoods: self._cls(DangerousGoods), ColdChainProduct: self._cls(ColdChainProduct), ExportControlledProduct: self._cls(ExportControlledProduct), SpecialHandlingProduct: self._cls(SpecialHandlingProduct), } # 1. 将数据库中的产品属性注入本体ABox individuals {} for p in products: ind prod_cls(p[name]) individuals[p[name]] ind ind.isHazardous [p.get(is_hazardous, False)] ind.requiresColdChain [p.get(requires_cold_chain, False)] ind.isExportControlled [p.get(is_export_controlled, False)] # 2. 推理机一次运行 —— 所有分类自动完成 with onto: sync_reasoner(infer_property_valuesTrue) # 3. 读取分类结果不是 if/else是检查推理机的归类结论 .......省略......现在比如我们要求 Agent “把所有产品做个分类告诉我哪些是需要特殊处理的产品”那么最终 Agent 的运行结果注意到某个产品可以同时被归为 DangerousGoods 和 ColdChainProduct 两个类别。传统做法需要显式处理这种交叉但在本体中多重分类是默认行为。而且实现非常优雅。在以上的两个案例中本质上展示的都是用本体来实现规则推理从而让 Agent真正的调用业务规则提高准确度与可解释性。当然这里只是非常基础的例子。而实际上这样的能力可以驱动更多的业务场景比如需求智能匹配与推荐、供应商智能匹配、仓储策略推荐等 — 所有有明确业务规则定义的地方。规则越复杂、变化越频繁越适合本体。最后总结关于规则的两个可能疑问。【两个问题】这些规则用 if/else 也能写为什么要用本体区别在于if/else 是硬编码在代码里的改一条规则就要改代码、重新部署而本体规则是声明式的改模型文件即可Agent 代码不用动。当企业有几十上百条业务规则时这个差别会非常明显。* 之前也有一些独立的规则引擎产品和本体有什么区别传统的规则引擎产品通常是脚本定义的多条 IF/THEN 规则 — 更像把业务规则写成一条条可执行脚本条件命中就触发直观高效。但当规则一多不同规则之间容易重复定义概念口径不一致跨规则复用困难改一处条件往往要连带排查多条规则。而本体承载规则时并不是堆很多规则定义脚本而是先把“什么是可加急订单”这类概念定义清楚再由推理机去判断某个对象是否属于这个概念。其好处是多个判断共享同一套概念和关系业务口径更统一规则变更也更容易收敛到业务模型层而不是散落在大量IF/THEN规则条目里。