夜雨聆风很多企业 AI 应用做到最后，会遇到一个看似技术、实则业务的问题：
AI 能读懂一句话，但未必读懂一句话背后的业务世界。
用户说“帮我看看这张报销单能不能过”，这句话本身并不复杂。真正复杂的是，系统需要知道什么是报销单、报销单关联哪些发票、发票金额怎么算、员工属于哪个部门、费用类型对应什么标准、当前审批人有没有权限、超过某个金额以后应该走什么流程。
这些信息不是单纯的数据，也不是几条规则，更不是靠大模型临场猜出来的知识。它需要一套稳定的结构来描述业务对象和关系。
我最近看到 Rillet 官网的一张架构图，里面把 Business Context 放在 Rillet ERP 和 Aura AI Engine 之间，并且在 Business Context 下面并列写了三件事：Rules、Policies、Ontology。
这张图有意思的地方，不在于它用了多少新概念，而在于它把企业 AI 的一个关键问题摆到了台面上： AI Engine 要稳定工作，不能只接工具、调 API 、连 MCP ，还需要一个能承接业务上下文的中间层。
这个中间层里， Rules 和 Policies 很重要，但真正决定 AI 能否“理解业务”的基础，是 Ontology 。
Ontology ：把字段还原成业务对象
Ontology 通常翻译为“本体”。这个词听起来偏学术，但放到企业 AI 语境里，可以先用一句话理解：
它回答的不是“这条 SQL 怎么写”，也不是“这个按钮怎么点”，而是更基础的问题：
这是什么业务对象？ 它有哪些关键属性？ 它和哪些对象有关？ 哪些属性代表身份、分类或状态？ 哪些关系会影响后续判断？
以财务场景为例， Ontology 可以定义：
Invoice是发票；InvoiceLineItem是发票明细；一张 Invoice可以包含多条InvoiceLineItem；ExpenseReport是报销单；一张 ExpenseReport可以关联多张Invoice；Employee属于某个Department；Approver是在特定流程节点上有审批权限的人。
这些定义看起来朴素，但对 AI 很关键。
如果没有 Ontology ， AI 看到的是一堆字段和文本： amount 、 dept 、 approver 、 invoice_no 、 project_code 。它可以根据语言经验猜测这些词大概是什么意思，但很难稳定理解它们之间的业务关系。
有了 Ontology ， AI 才能知道：invoice.amount 不是孤立金额，它可能需要和明细汇总比对；employee.department 不只是一个字符串，它可能影响成本归属和审批路径；expense_type 不只是费用类别，它可能决定后续要应用哪些策略。
所以， Ontology 的价值不是“多建一层概念”，而是把字段背后的业务含义变成机器可以引用、解释和推理的结构。
BusinessContext ：把语义放进当前任务
如果 Ontology 偏“定义”，那么 BusinessContext 更偏“现场”。
Ontology 告诉系统：业务世界里有什么对象、属性和关系。BusinessContext 告诉 AI ：当前这个任务里，哪些对象、数据、状态、规则和策略正在发生作用。
比如用户问：
BusinessContext 需要把这个问题背后的现场组织起来：
当前对象是一张报销单； 它关联了哪些发票； 发票有哪些明细； 申请人是谁，属于哪个部门； 费用类型是什么； 当前审批流走到哪一步； 哪些字段参与金额校验； 哪些策略会影响流程走向。
这不是简单地把数据库字段全部塞给 AI 。字段越多，不代表上下文越好。真正有用的 BusinessContext ，是把字段、对象、关系、状态和业务含义组织起来。
也就是说， Ontology 提供语义骨架， BusinessContext 把这套语义骨架放进一个具体业务请求里。
在 Rillet 的图里， Ontology 、 Rules 、 Policies 并列出现在 Business Context 下面。它们不是同一类东西，但都会影响 AI Engine 的业务判断。
可以先用三句话区分：
Ontology 解决的是：这是什么，和谁有关。 Rules 解决的是：怎么算，合不合法。 Policies 解决的是：谁能做，按什么标准，走什么流程。
放回 Business Context 里，它们的分工更清楚：
Ontology 定义业务世界。Rules 执行确定性校验。Policies 处理场景化管控。Aura AI Engine 基于这些上下文进行理解、推理和行动。
Rules ：适合机器自动执行的确定性逻辑
Rules 是规则，重点是刚性、明确、可计算。
它回答的是：
典型例子包括：
借贷必须平衡； 发票金额必须等于明细金额之和； 报销单金额必须等于关联发票金额之和； 税额必须按照指定公式计算； 必填字段不能为空； 会计科目组合必须有效； 日期不能超出允许范围。
这些判断通常适合机器自动执行。因为输入明确，逻辑明确，输出也比较明确。
例如“发票金额 = 明细金额之和”，这不应该交给大模型自由发挥，也不应该让人工凭感觉判断。系统直接读取发票总金额和明细金额，加总后比对即可。
在 Aura AI Engine 中，更稳妥的方式是： AI 负责理解用户意图和定位业务对象，真正的规则校验由确定性逻辑执行。
Policies ：更接近企业管理制度
Policies 是策略。它不是单纯计算，而是带有权限、标准、审批和例外的管理原则。
它回答的是：
典型例子包括：
超过 10 万元的发票需要总监审批； 某类费用可以报销，但必须附上证明材料； 住宿报销标准与城市和员工职级有关； 敏感数据只有特定角色可见； 某些供应商付款需要额外风险审核； 超标准费用可以特批，但必须说明原因。
Policies 通常不是简单的“对 / 错”。它更多是在告诉系统下一步怎么走。
例如一张 12 万元的发票，金额本身未必错误。但如果策略规定“超过 10 万元需要总监审批”，那系统应该输出的不是“失败”，而是：
再比如住宿费用超过标准，也未必一定要直接拦截。如果公司允许项目特批，那么系统可以提示：
Rules 更像硬逻辑， Policies 更像制度和流程。前者适合机器直接判断，后者更适合由 AI 结合上下文解释、路由和提醒，并在必要时引入人工审批。
Aura AI Engine ：在业务语义上执行任务
Aura AI Engine 可以理解为业务推理与执行层。
它的重点不是“替代所有规则系统”，也不是“让大模型直接决定业务结果”。更合理的定位是：基于 BusinessContext ，把用户的自然语言请求转化成可解释、可执行、可追踪的业务动作。
它至少需要做四件事。
第一，理解用户意图。
用户通常不会说“请执行发票金额一致性校验规则，并应用费用审批策略”。用户只会说：
AI Engine 要把这句话识别成一个业务审核任务。
第二，定位业务对象。
它需要知道这里涉及报销单、发票、发票明细、员工、部门、费用类型、审批流等对象。这一步依赖 Ontology 和 BusinessContext 。如果没有清晰的对象定义， AI 很容易把字段和语义混在一起。
第三，调用 Rules 。
对于确定性规则，它应该调用系统逻辑，而不是让模型自由判断。比如金额是否一致、税额是否正确、借贷是否平衡、编码组合是否有效。
第四，解释 Policies 。
对于策略，它需要结合用户身份、组织层级、金额、费用类型、流程状态等上下文，判断是否需要更高级审批、是否允许当前用户提交、是否需要补充材料、是否可以走特批。
最后， Aura AI Engine 给出的结果不应该只是一句“可以”或“不可以”，而应该拆成几类：
哪些是规则错误，必须修正； 哪些是策略要求，需要审批； 哪些字段缺失，需要补充； 哪些情况可以走特批； 下一步应该由谁处理。
这也是企业 AI 和普通聊天机器人的区别之一：它不只是生成回答，而是要在业务语义上推动流程继续向前。
这里可以用 Oracle 体系里的 Flexfield 做一个例子。
对不了解 Oracle 的读者来说，不需要记住这个术语。可以简单理解为： Flexfield 是一类企业软件里的可配置字段机制，用来让企业在不改底层代码的情况下表达自己的业务差异。
其中有两个常见类型：
KFF ， Key Flexfield ，可以理解成“多段核心编码”。比如会计科目可能由公司、部门、科目、项目、产品线等 segment 组合而成。 DFF ， Descriptive Flexfield ，可以理解成“业务对象的附加属性”。比如采购订单上额外记录客户项目编号、预算来源、监管分类。
它们和 Ontology 的关系，关键不在于名字，而在于边界：
比如系统里有一个 DFF 字段叫 project_code_ext。字段本身只是一个扩展字段。 Ontology 需要进一步说明：
它代表客户项目，还是内部预算项目？ 它关联哪个业务对象？ 它是否影响成本归属？ 它是否影响审批策略？ 它和部门、预算、合同之间是什么关系？
只有完成这层语义映射，这个字段才真正进入了 BusinessContext ，成为 AI 可以理解和推理的业务信息。
从这个角度看， Flexfield 这类机制更像是业务语义的入口。它把企业差异记录到了系统里，但这些差异还需要被进一步解释：哪些是对象，哪些是属性，哪些是分类维度，哪些会影响规则或策略。
这一步，才是 Ontology 真正要承担的工作。
一个完整例子：报销单审核
假设用户提交了一张报销单，并问：
系统首先通过 Ontology 和 BusinessContext 识别相关对象：
报销单； 发票； 发票明细； 员工； 部门； 会计科目； 费用类型； 审批流程。
如果这个企业使用了类似 Flexfield 的机制，会计科目可能不是一个简单字段，而是公司、部门、科目、项目等 segment 的组合。某些额外字段也可能来自自定义扩展，比如客户名称、出差城市、住宿天数。
但 AI 真正需要理解的，不是这些字段来自哪套产品机制，而是它们在业务上意味着什么。
接下来，系统执行 Rules ：
发票金额是否等于明细金额之和； 报销单总额是否等于所有发票金额之和； 税额是否符合计算公式； 会计科目组合是否有效； 必填字段是否完整。
然后系统应用 Policies ：
当前金额是否超过审批阈值； 当前用户是否有提交权限； 当前费用是否符合员工职级标准； 超标费用是否允许特批； 是否需要总监或财务复核。
最终，一个比较理想的 AI 输出应该类似这样：
这个回答背后， Ontology 提供了业务对象和关系， Rules 提供了确定性校验， Policies 提供了流程和权限判断， BusinessContext 把当前任务组织起来， Aura AI Engine 则把用户问题转成了业务动作。
结语：企业 AI 的核心挑战，是业务语义
企业 AI 的难点，不只是模型能力，也不只是接入更多工具。更基础的问题是：系统是否知道自己正在处理什么业务对象，这些对象之间有什么关系，哪些判断可以自动校验，哪些判断需要进入流程。
Ontology 是这套能力的基础。 BusinessContext 把它放进具体业务现场， Aura AI Engine 再基于它理解用户意图、调用规则、解释策略，并推动流程继续向前。
从这个角度看， Rillet 图里的 Business Context 不是一个普通中间层，而是企业 AI 从“读懂一句话”走向“读懂一件业务”的关键位置。
