一文讲透 Ontology 的运行机制——AI Agent 如何通过本体完成一次真实的企业业务操作？

本体（Ontology）不应仅是 Agent 启动时读取的静态“说明书”，而应成为其在查询、判断、执行过程中持续调用的运行时服务。

随着 Palantir 等技术架构的普及，企业级 Ontology 建设日益受到关注。许多团队构建了完善的业务对象模型（Object/Property/Link/Action），但在实际应用中常面临困境：Agent 何时读取定义？如何基于本体查询数据库？如何校验操作合法性？如何感知业务状态变更？

若无法回答上述问题，本体极易退化为高级“数据字典”。理解 Ontology 的关键视角在于：

本文将通过一个典型的企业业务场景——“找出华东区逾期超过 30 天的客户，并为其创建跟进任务”，拆解 Agent 与 Ontology 交互的 17 个关键步骤，揭示以 Ontology 为核心的企业 Agent 架构实践。

假设企业内存在 CRM、计费系统和任务系统三个独立业务系统。面对“找出华东区逾期超 30 天客户并创建任务”的需求，直接让大模型生成 SQL 虽能快速演示，但在生产环境中会引发诸多歧义：地区字段定义、逾期计算方式、多账单处理逻辑、数据同步延迟及人员离职情况等。

此外，模型查到的多个 ID 是否属于同一业务关系，也需要明确验证。因此，首先需要构建稳定的业务定义，即 Ontology。

1. 定义对象：业务实体而非数据库表

本场景涉及四类核心对象：

• Customer（客户）：ID、名称、地区、状态等；
• Bill（账单）：ID、到期日、未结清金额、结清状态等；
• CustomerManager（客户经理）：负责人信息；
• FollowUpTask（跟进任务）：ID、负责人、状态等。

Ontology 中的对象是业务视角的抽象，可能聚合了来自 CRM、风控、计费等多个系统的数据，而非单一数据库表的映射。

2. 定义关系：确立业务关联

关键关系包括：

• Bill → Customer（账单属于客户）；
• Customer → CustomerManager（客户由经理负责）；
• FollowUpTask → Customer/Bill/CustomerManager（任务关联多方）。

这些关系决定了操作的合法性，需经过严格验证，而非简单拼接 ID。

3. 定义规则：明确业务逻辑

定义规则 PendingFollowUp：账单未结清且逾期超过 30 天。需注意，“逾期”的计算逻辑（自然日/工作日、大于/大于等于）应由规则明确定义，而非由模型临场决定。规则变更应通过治理机制更新，而非修改 Prompt。

4. 定义行动：设定操作契约

定义 Action CreateFollowUpTask，包含参数 customerId、billId、assigneeId 等。同时需明确权限约束、前置条件（如账单归属验证）、接口映射及幂等性要求。这些定义在系统设计阶段建立，运行时 Agent 仅引用执行，确保业务规则的稳定性和可控性。

查询过程分为以下关键步骤：

1. 意图识别与定义获取

用户提出业务目标后，编排层向 Ontology Runtime 请求当前任务所需的业务定义（对象、属性、关系、规则）。返回的定义片段经过权限裁剪，仅包含用户有权访问的内容。注意，此时返回的是元数据定义，而非实际业务数据。

2. 生成逻辑查询请求

模型基于本体定义，生成结构化逻辑查询请求（非 SQL）。例如，指定查询 Customer 对象，过滤条件为 region=华东 且命中 PendingFollowUp 规则。这种设计避免了模型直接接触底层数据库结构，降低了耦合度，并统一了权限治理。

3. 本体服务执行查询

本体查询服务验证请求合法性后，根据对象映射生成实际数据访问计划（SQL 或 API 调用），并注入数据访问权限。查询结果从各业务系统返回后，本体服务将其还原为具有明确身份、关系和来源的业务对象，解决跨系统 ID 不一致问题。

4. 规则推导与结论保留

基于还原后的业务对象事实（如账单 B036 逾期 42 天），规则引擎依据 PendingFollowUp 规则推导出结论（客户 C018 需跟进）。关键在于分离事实与结论，并记录推导依据（事实来源、规则版本、计算时间），以支持审计和重新计算。

写操作直接改变业务状态，风险更高。流程如下：

1. 提出 Action Request

模型基于查询结果提出创建任务的请求，包含客户、账单、负责人 ID。需区分 Intent（意图）、Action Request（请求）与 Action Execution（执行）。

2. 业务关系与状态复核

在执行前，必须验证业务关系（如账单是否确实属于该客户、经理是否负责该客户）以及最新业务状态（TOCTOU 问题，防止数据在查询与执行间发生变化）。仅验证 ID 格式合法是不够的。

3. 人工确认与审批

对于高风险操作，系统应向用户展示业务对象、依据及后果，由人工确认。人机协作的核心是审批业务决策，而非检查技术细节。

4. 受控执行与幂等保障

确认后，Ontology Action Service 验证所有前置条件，并通过受控接口调用业务系统 API。设计中需考虑幂等性，防止因网络超时或重试导致重复创建任务。最终成功与否以业务系统的真实回执为准。

1. 业务变更回流

任务创建成功后，需通过事件通知或回调将变更同步回本体视图，建立新任务与相关对象的关联。需注意数据一致性策略，明确强一致性与最终一致性的适用范围。

2. 目标完成度检查

编排层需对比初始目标与实际执行结果。例如，10 个符合条件的客户中，可能仅有 7 个新建任务，其余因已有任务或状态变更而未执行。Agent Loop 的核心是不断对照目标与真实状态，直至任务完成或需人工介入。

3. 交付业务结果

最终交付物应包含清单、推导依据及执行结果（任务编号、状态等），准确表达已完成的工作边界，避免将“发起动作”混淆为“解决问题”。

企业 Agent 架构可划分为五层：

1. LLM / Agent：理解意图，生成逻辑请求，不负责业务权威；
2. Agent Harness：调度、状态管理、异常恢复；
3. Ontology Runtime：提供业务定义、查询、身份解析、规则推导、行动契约及治理能力；
4. Domain Services：领域服务、事务处理、接口适配；
5. Data / Business Systems：权威业务数据存储。

Ontology Runtime 不应替代 DDD 领域服务或 MCP，而是作为连接模型与业务系统的语义与操作契约层。它通过 MCP 暴露能力，但核心价值在于解决跨系统身份映射、业务规则统一及操作合法性校验。

• 缺乏稳定身份体系：跨系统对象 ID 未统一映射，导致关系错误；
• 规则硬编码在 Prompt：导致规则分散、版本混乱，应集中管理于本体；
• 仅验证参数类型：忽略业务关系和前置条件校验，导致非法操作；
• 忽视并发与重试：缺乏幂等设计和状态复核，引发数据不一致；
• 误以为本体即实时真相：忽略数据同步延迟，关键操作需向权威系统验证；
• 混淆动作与结果：将接口调用成功等同于业务目标达成，缺乏后续状态追踪。

建议选择一个包含完整读写闭环的小场景（如逾期客户跟进）作为切入点，逐步构建对象、映射、规则、查询接口及 Action 服务，并接入 Agent Harness 进行端到端测试。重点测试异常场景（如关系不符、状态变更、权限不足等），确保架构具备健壮性。

评估本体成熟度的指标应包括：通过统一契约运行的操作数量、集中管理的规则比例、跨系统关系解析可靠性、高风险操作的拦截率及任务实际完成率等。

Ontology Runtime 的价值在于将对象映射、规则引擎、权限控制等企业现有技术组织成一套面向业务世界的统一语义与操作契约。它让 Agent 面对的是一个有对象、有关系、有规则、有权限、有可执行动作的结构化世界。

企业 AI 的核心挑战已从“模型能否回答问题”转向“模型能否正确参与业务”。合理的分工应是：模型负责意图理解与请求提出，本体负责提供定义、依据与契约，业务系统负责权威执行，编排层负责全流程核验。唯有如此，Agent 才能成为有能力、懂业务、守规则且可追溯的执行系统。