最近Ontology本体驱动Agent这个东西很火也都在提但还是太抽象包装的很不错大致就是【本体不是单纯的“知识库”而是Agent的“业务宪法”和逻辑框架、本体驱动的本质是让Agent的认知步骤规划、推理、执行都在本体规定的语义逻辑框架下进行】。而国内许多公司都在说这个事情所以来看看底层的一些实现机理从技术可行性角度来看看一个剖析分解成GraphRAG、规则引擎、Workflow三者分别对应事实检索、逻辑约束、流程固化形成“弱控制强约束确定性执行”的层级这个其实是一个工程上的集成性产物其实并没有那么唬人做好很简单但是怎么集成成一个好的方案做好其实还是不容易的。另外一个就是来做个歧义解释“静态本体”和“动态本体”这两个词之所以混乱就是因为说话人经常在不指明是哪一层含义的情况下使用这个也是对上一篇本体ontology的后续补充。PART 01关于本体驱动Agent的几个现实玩法本体驱动Agent是当前企业AI应用中炒的最火的一个概念。本体 (Ontology)刻画了该领域的实体如“员工”、“订单”它定义了实体间的复杂关系、业务流程和判断规则可以比作是针对特定领域精确、标准化的知识地图或字典【当然更细节性的标准的区分可以看看之前那个辨析文章】Agent负责规划、决策并调用工具来完成任务具有解读和使用 “知识地图” 的能力。本体驱动Agent的提法核心就是利用“本体”为AI提供一个无误的“业务大脑”使Agent能够理解业务、自主完成复杂任务最终目标是达成“本体就是Agent的‘宪法’——规定概念、关系、规则并约束所有行为必须遵循逻辑推导而非概率猜测。但是这个东西还是太抽象包装的很不错国内许多是在做这个事情图来自于悦点科技因此还是需要落到具体的实现上这就涉及到具体的如何做处理来看下机制看了下就三个调用GraphRAG查事实、调用规则引擎做判定、调用Workflow走步骤GraphRAG【将本体知识库、标准化、无歧义的数据做外外围的输入进行增强】、规则引擎【进行事务性制定、干预】、Workflow【基于领域本体将业务流程固定为若干个实现流程规划增强】这些对应到当前Agent的执行环节中【规划、执行、推理生成】。非要搞个层级就是合顶层【GraphRAGLLM负责模糊意图识别和生成弱控制】、中层【规则引本体做逻辑剪枝强约束】、底层【Workflow做原子指令序列的可靠执行确定性】先看一个例子给定任务处理订单456的延误向客户发送道歉邮件并提供补偿方案对应的执行机制可以如下1、GraphRAG增强Agent规划及生成传统RAG做的是“向量相似度检索”返回文本块再塞给LLM这有两个问题信息碎片化、丢失逻辑关系。GraphRAG以本体Ontology定义的实体-关系图为索引检索时不只是找“相似的文本”而是沿着关系路径找到逻辑上相关的实例集合这一步可以在规划和生成阶段执行。例如LLM在生成CoT思维链或ReAct中的“思考”时GraphRAG提供的是可直接注入prompt的结构化三元组如(Order#123,hasStatus,Delayed)(Delayed,causedBy,SupplierShortage)让LLM的下一步推理不是纯概率预测而是基于事实图谱的逻辑跳转。例如用户问“为什么订单123延误”标准LLM会编一个原因。GraphRAG驱动的Agent会先查询图谱123→hasStatus→DelayedDelayed→hasReason→SupplierShortage然后生成“根据知识图谱延误原因是供应商缺料”。2、Workflow增强Agent规划规划阶段的核心任务是生成一个合法的动作序列。Workflow在某种意义上就是预先定义好的规划模板比如请假流程的固定步骤直接给出了步骤顺序和依赖关系因此Workflow是规划的一种固化形式它增强的是规划减少 LLM 的搜索空间例如告诉 Agent要完成这个任务你必须有步骤 A→B→C。这可以降低LLM规划时的复杂度。大的背景是规划环节的核心是生成一系列动作序列以满足目标LLM作为规划器容易产生“幻觉步骤”例如为了补货直接“命令供应商发货”但缺少权限。而即使规划正确LLM直接调用工具也可能因顺序错误、缺少事务性、异常未处理而失败无法跳转所以Workflow通常以DAG或状态机形式将规划结果编译为可执行的流程定义所以Workflow也可以作为一个标注流程库进行干预。例如Workflow给出一个标准退单流程模板查询订单→检查退单资格→发起退款→关闭订单。Agent直接使用这个模板作为规划结果无需LLM从头生成其本质上是提供预定义的步骤蓝图减少LLM的规划负担。这种的执行有几种情况一种是确定性状态迁移每个步骤的输出作为下一步的输入严格保证顺序。例如先“创建发货单”再“扣减库存”不允许倒序。一种是事务补偿若某步骤失败Workflow引擎可自动回滚已执行步骤调用反向API。一种是可观测性每个步骤的状态pending/running/succeeded/failed被记录便于调试和审计。此外也留出与LLM的交互入口Workflow中可嵌入“LLM步骤”例如“调用LLM生成邮件内容”但整体控制流由Workflow引擎主导而非LLM自主决定下一步。3、规则引擎增强Agent规划执行规则引擎也能增强Agent规划执行如下表在规划阶段规则引擎可用于约束剪枝例如任何涉及金额1000 的操作都需要审批」→ 规划时自动插入审批步骤这里与Workflow存在区别规则引擎作用于规划阶段的空间约束而Workflow作用于执行阶段的顺序固化一个是“哪些动作不允许”一个是“动作必须按什么顺序做”。在执行阶段规则引擎可用于动态路由例如如果当前库存 安全库存则跳过正常发货转到采购流程。这里重点看执行阶段执行阶段的核心任务是按计划调用工具并处理动态环境规则引很适合常适合在执行过程中根据当前状态比如库存突然变为0触发中断、分支选择或补偿动作。具体的看有如下几个一个是动作空间剪枝在LLM生成每一步动作之前先由规则引擎过滤掉所有被禁止的动作例如在执行检查退单资格这一步时调用规则引擎规则1IF订单状态已发货THEN退单资格拒绝、规则2IF订单金额5000THEN需要人工审批。一个是后验证与修正LLM生成完整规划后规则引擎进行可满足性检查。若违反规则返回违反的规则ID要求LLM重新规划类似约束满足问题的回溯。一个是实时干预在规划执行过程中若状态变化触发规则如“库存从充足变为短缺”规则引擎可动态中止当前规划触发重新规划。当然说到这里很多人会简单地以为Agent调用知识库GraphRAG、调用规则服务规则引擎、调用流程引擎Workflow就完事了跟真正的“本体驱动”没关系。实际上可以包装成关系打法怎么做那就是让Agent的每一个认知步骤推理、规划、执行都变成在语义逻辑框架下的推导全在这个的大框架里打转。具体的三个点其一本体作为统一的知识骨架。GraphRAG的图结构由本体定义规则引擎的谓词如Supplier_high_risk来自本体的概念Workflow的节点如CreateShipment也是本体中定义的动作类三者共享同一套TBox术语集。例如GraphRAG返回的“供应商A”与规则引擎里判断“高风险”的“supplier_A”是否是同一个实体没有本体保证只能靠字符串匹配或者embedding这种相关性其二做约束LLM不仅要“读取”本体它的输出规划、生成的参数也会被本体约束解码确保符合本体的值域和关系类型例如LLM不能在规划中生成一个不属于本体的动作【这就是上面的规则引擎】例如 Workflow中定义的动作“CreateShipment”可能在本体中根本不是一个动作类或者缺少前置条件约束Agent可以“合法地”调用一个在业务逻辑上无意义的动作【的确无法排除设计的时候乱写】其三可解释性这也是可观测性。最终执行的每一步都可以回溯到本体的某条公理或规则——因为规则R17禁止X所以没有选择该动作。但不够深刻不够精髓。当Agent做错了无法回溯到“是哪条规则或公理导致了这一步”。因为错误可能来自LLM的幻觉、规则引擎的漏判、或Workflow的编排错误。所以这是不是有种按个Harness的味道PART 02再看看静态本体和动态本体之分“静态本体”和“动态本体”这两个词之所以混乱就是因为说话人经常在不指明是哪一层含义的情况下使用先来看看这个问题。1、什么是静态本体和动态本体当有人说“本体是静态的”他可能是指“本体的概念公理不随时间变化”语义网和知识图谱都符合也可能是指“本体不能执行动作”语义网和知识图谱符合但Palantir不符合。与此对应的有个概念就是“静态schema”一个在数据库、知识图谱和数据处理系统中常用的概念静态schema是预先定义好、轻易不能改的表结RDF图本身就是动态schema的极端形式预先严格定义类、属性、约束几乎不允许运行时更改这是静态schema的极致任何实体都可以有任意类型的属性谓词不需要事先声明。与此对应的动态schema则是可以随数据或业务需求变化而演化、甚至每行数据可以有不同属性的结构。例如知识图谱本体即schema层可以事后添加可以先插入大量数据再逐渐为其加上类型约束这种“类型系统可以后补、演化”也被称为动态schema。而到了这个palantir的语境只得又是另一个东西了本体包含可执行的行动”这个有属于动作了有function有action。类型框架预先定义但实例属性可以任意类似动态且Action可以产生新的对象类型实例→混合框架静态实例动态所以“动态schema”通常指的是数据写入时不需要严格遵循预定义模式的机制。2、静态本体和动态本体可以很好区分么其实静态本体和动态本体是你中有我我中有你分别看Palantir的本体Palantir Ontology中框架对象类型、链接类型是相对稳定的但它支持属性的动态添加、状态机的动态变迁、以及通过Action在运行时创建新的对象类型实例。这不算纯粹的schema-less而是受控的动态schema框架可演化且实例可以携带框架未预定义的时间窗口等元数据。知识图谱的本体schema最初定义时通常是静态的例如定义实体类型Person、Movie和关系类型actedIn、directedBy。表现为固定的类型标签集合、固定的属性名集合但是实际中并不严格静态因为知识图谱的本体可以增量扩展-新的类型、新的关系可以随时加入例如谷歌知识图谱不断新增类别。而进一步的知识图谱本体自身不强调“动态”但它的实例层即图谱中的数据是高度动态的实例的增删改【实体频繁加入、属性值更新】、时间标注可选【部分知识图谱支持时间戳或有效时间如Wikidata的P585属性】、状态属性【实例可以携带当前状态如“订单状态已支付”】只是但本体层本身几乎不包含动态规则或行动。所以因此在讨论时最好明确说出你指的是“数据/状态是否时变”还是“模型是否可执行”。如果不说清楚静态/动态就是一个滑动的概念怎么解释都可能对也可能完全错。往期推荐RECOMMEND1论文浅尝 | ORT本体引导的逆向思维增强大模型知识图谱问答能力ACL 20252东南大学漆桂林教授干货分享基于动态本体的灵活可更新知识库3论文浅尝 | SEMMA一种语义感知的知识图谱基座模型EMNLP2025OpenKGOpenKG中文开放知识图谱旨在推动以中文为核心的知识图谱数据的开放、互联及众包并促进知识图谱算法、工具及平台的开源开放。点击阅读原文进入 OpenKG 网站。
技术动态 | Ontology本体驱动Agent究竟是个啥？技术起底及静态、动态本体怎么区分？
最近Ontology本体驱动Agent这个东西很火也都在提但还是太抽象包装的很不错大致就是【本体不是单纯的“知识库”而是Agent的“业务宪法”和逻辑框架、本体驱动的本质是让Agent的认知步骤规划、推理、执行都在本体规定的语义逻辑框架下进行】。而国内许多公司都在说这个事情所以来看看底层的一些实现机理从技术可行性角度来看看一个剖析分解成GraphRAG、规则引擎、Workflow三者分别对应事实检索、逻辑约束、流程固化形成“弱控制强约束确定性执行”的层级这个其实是一个工程上的集成性产物其实并没有那么唬人做好很简单但是怎么集成成一个好的方案做好其实还是不容易的。另外一个就是来做个歧义解释“静态本体”和“动态本体”这两个词之所以混乱就是因为说话人经常在不指明是哪一层含义的情况下使用这个也是对上一篇本体ontology的后续补充。PART 01关于本体驱动Agent的几个现实玩法本体驱动Agent是当前企业AI应用中炒的最火的一个概念。本体 (Ontology)刻画了该领域的实体如“员工”、“订单”它定义了实体间的复杂关系、业务流程和判断规则可以比作是针对特定领域精确、标准化的知识地图或字典【当然更细节性的标准的区分可以看看之前那个辨析文章】Agent负责规划、决策并调用工具来完成任务具有解读和使用 “知识地图” 的能力。本体驱动Agent的提法核心就是利用“本体”为AI提供一个无误的“业务大脑”使Agent能够理解业务、自主完成复杂任务最终目标是达成“本体就是Agent的‘宪法’——规定概念、关系、规则并约束所有行为必须遵循逻辑推导而非概率猜测。但是这个东西还是太抽象包装的很不错国内许多是在做这个事情图来自于悦点科技因此还是需要落到具体的实现上这就涉及到具体的如何做处理来看下机制看了下就三个调用GraphRAG查事实、调用规则引擎做判定、调用Workflow走步骤GraphRAG【将本体知识库、标准化、无歧义的数据做外外围的输入进行增强】、规则引擎【进行事务性制定、干预】、Workflow【基于领域本体将业务流程固定为若干个实现流程规划增强】这些对应到当前Agent的执行环节中【规划、执行、推理生成】。非要搞个层级就是合顶层【GraphRAGLLM负责模糊意图识别和生成弱控制】、中层【规则引本体做逻辑剪枝强约束】、底层【Workflow做原子指令序列的可靠执行确定性】先看一个例子给定任务处理订单456的延误向客户发送道歉邮件并提供补偿方案对应的执行机制可以如下1、GraphRAG增强Agent规划及生成传统RAG做的是“向量相似度检索”返回文本块再塞给LLM这有两个问题信息碎片化、丢失逻辑关系。GraphRAG以本体Ontology定义的实体-关系图为索引检索时不只是找“相似的文本”而是沿着关系路径找到逻辑上相关的实例集合这一步可以在规划和生成阶段执行。例如LLM在生成CoT思维链或ReAct中的“思考”时GraphRAG提供的是可直接注入prompt的结构化三元组如(Order#123,hasStatus,Delayed)(Delayed,causedBy,SupplierShortage)让LLM的下一步推理不是纯概率预测而是基于事实图谱的逻辑跳转。例如用户问“为什么订单123延误”标准LLM会编一个原因。GraphRAG驱动的Agent会先查询图谱123→hasStatus→DelayedDelayed→hasReason→SupplierShortage然后生成“根据知识图谱延误原因是供应商缺料”。2、Workflow增强Agent规划规划阶段的核心任务是生成一个合法的动作序列。Workflow在某种意义上就是预先定义好的规划模板比如请假流程的固定步骤直接给出了步骤顺序和依赖关系因此Workflow是规划的一种固化形式它增强的是规划减少 LLM 的搜索空间例如告诉 Agent要完成这个任务你必须有步骤 A→B→C。这可以降低LLM规划时的复杂度。大的背景是规划环节的核心是生成一系列动作序列以满足目标LLM作为规划器容易产生“幻觉步骤”例如为了补货直接“命令供应商发货”但缺少权限。而即使规划正确LLM直接调用工具也可能因顺序错误、缺少事务性、异常未处理而失败无法跳转所以Workflow通常以DAG或状态机形式将规划结果编译为可执行的流程定义所以Workflow也可以作为一个标注流程库进行干预。例如Workflow给出一个标准退单流程模板查询订单→检查退单资格→发起退款→关闭订单。Agent直接使用这个模板作为规划结果无需LLM从头生成其本质上是提供预定义的步骤蓝图减少LLM的规划负担。这种的执行有几种情况一种是确定性状态迁移每个步骤的输出作为下一步的输入严格保证顺序。例如先“创建发货单”再“扣减库存”不允许倒序。一种是事务补偿若某步骤失败Workflow引擎可自动回滚已执行步骤调用反向API。一种是可观测性每个步骤的状态pending/running/succeeded/failed被记录便于调试和审计。此外也留出与LLM的交互入口Workflow中可嵌入“LLM步骤”例如“调用LLM生成邮件内容”但整体控制流由Workflow引擎主导而非LLM自主决定下一步。3、规则引擎增强Agent规划执行规则引擎也能增强Agent规划执行如下表在规划阶段规则引擎可用于约束剪枝例如任何涉及金额1000 的操作都需要审批」→ 规划时自动插入审批步骤这里与Workflow存在区别规则引擎作用于规划阶段的空间约束而Workflow作用于执行阶段的顺序固化一个是“哪些动作不允许”一个是“动作必须按什么顺序做”。在执行阶段规则引擎可用于动态路由例如如果当前库存 安全库存则跳过正常发货转到采购流程。这里重点看执行阶段执行阶段的核心任务是按计划调用工具并处理动态环境规则引很适合常适合在执行过程中根据当前状态比如库存突然变为0触发中断、分支选择或补偿动作。具体的看有如下几个一个是动作空间剪枝在LLM生成每一步动作之前先由规则引擎过滤掉所有被禁止的动作例如在执行检查退单资格这一步时调用规则引擎规则1IF订单状态已发货THEN退单资格拒绝、规则2IF订单金额5000THEN需要人工审批。一个是后验证与修正LLM生成完整规划后规则引擎进行可满足性检查。若违反规则返回违反的规则ID要求LLM重新规划类似约束满足问题的回溯。一个是实时干预在规划执行过程中若状态变化触发规则如“库存从充足变为短缺”规则引擎可动态中止当前规划触发重新规划。当然说到这里很多人会简单地以为Agent调用知识库GraphRAG、调用规则服务规则引擎、调用流程引擎Workflow就完事了跟真正的“本体驱动”没关系。实际上可以包装成关系打法怎么做那就是让Agent的每一个认知步骤推理、规划、执行都变成在语义逻辑框架下的推导全在这个的大框架里打转。具体的三个点其一本体作为统一的知识骨架。GraphRAG的图结构由本体定义规则引擎的谓词如Supplier_high_risk来自本体的概念Workflow的节点如CreateShipment也是本体中定义的动作类三者共享同一套TBox术语集。例如GraphRAG返回的“供应商A”与规则引擎里判断“高风险”的“supplier_A”是否是同一个实体没有本体保证只能靠字符串匹配或者embedding这种相关性其二做约束LLM不仅要“读取”本体它的输出规划、生成的参数也会被本体约束解码确保符合本体的值域和关系类型例如LLM不能在规划中生成一个不属于本体的动作【这就是上面的规则引擎】例如 Workflow中定义的动作“CreateShipment”可能在本体中根本不是一个动作类或者缺少前置条件约束Agent可以“合法地”调用一个在业务逻辑上无意义的动作【的确无法排除设计的时候乱写】其三可解释性这也是可观测性。最终执行的每一步都可以回溯到本体的某条公理或规则——因为规则R17禁止X所以没有选择该动作。但不够深刻不够精髓。当Agent做错了无法回溯到“是哪条规则或公理导致了这一步”。因为错误可能来自LLM的幻觉、规则引擎的漏判、或Workflow的编排错误。所以这是不是有种按个Harness的味道PART 02再看看静态本体和动态本体之分“静态本体”和“动态本体”这两个词之所以混乱就是因为说话人经常在不指明是哪一层含义的情况下使用先来看看这个问题。1、什么是静态本体和动态本体当有人说“本体是静态的”他可能是指“本体的概念公理不随时间变化”语义网和知识图谱都符合也可能是指“本体不能执行动作”语义网和知识图谱符合但Palantir不符合。与此对应的有个概念就是“静态schema”一个在数据库、知识图谱和数据处理系统中常用的概念静态schema是预先定义好、轻易不能改的表结RDF图本身就是动态schema的极端形式预先严格定义类、属性、约束几乎不允许运行时更改这是静态schema的极致任何实体都可以有任意类型的属性谓词不需要事先声明。与此对应的动态schema则是可以随数据或业务需求变化而演化、甚至每行数据可以有不同属性的结构。例如知识图谱本体即schema层可以事后添加可以先插入大量数据再逐渐为其加上类型约束这种“类型系统可以后补、演化”也被称为动态schema。而到了这个palantir的语境只得又是另一个东西了本体包含可执行的行动”这个有属于动作了有function有action。类型框架预先定义但实例属性可以任意类似动态且Action可以产生新的对象类型实例→混合框架静态实例动态所以“动态schema”通常指的是数据写入时不需要严格遵循预定义模式的机制。2、静态本体和动态本体可以很好区分么其实静态本体和动态本体是你中有我我中有你分别看Palantir的本体Palantir Ontology中框架对象类型、链接类型是相对稳定的但它支持属性的动态添加、状态机的动态变迁、以及通过Action在运行时创建新的对象类型实例。这不算纯粹的schema-less而是受控的动态schema框架可演化且实例可以携带框架未预定义的时间窗口等元数据。知识图谱的本体schema最初定义时通常是静态的例如定义实体类型Person、Movie和关系类型actedIn、directedBy。表现为固定的类型标签集合、固定的属性名集合但是实际中并不严格静态因为知识图谱的本体可以增量扩展-新的类型、新的关系可以随时加入例如谷歌知识图谱不断新增类别。而进一步的知识图谱本体自身不强调“动态”但它的实例层即图谱中的数据是高度动态的实例的增删改【实体频繁加入、属性值更新】、时间标注可选【部分知识图谱支持时间戳或有效时间如Wikidata的P585属性】、状态属性【实例可以携带当前状态如“订单状态已支付”】只是但本体层本身几乎不包含动态规则或行动。所以因此在讨论时最好明确说出你指的是“数据/状态是否时变”还是“模型是否可执行”。如果不说清楚静态/动态就是一个滑动的概念怎么解释都可能对也可能完全错。往期推荐RECOMMEND1论文浅尝 | ORT本体引导的逆向思维增强大模型知识图谱问答能力ACL 20252东南大学漆桂林教授干货分享基于动态本体的灵活可更新知识库3论文浅尝 | SEMMA一种语义感知的知识图谱基座模型EMNLP2025OpenKGOpenKG中文开放知识图谱旨在推动以中文为核心的知识图谱数据的开放、互联及众包并促进知识图谱算法、工具及平台的开源开放。点击阅读原文进入 OpenKG 网站。
