发表于

本体系统要为Agent提供上下文

软件系统，本质上是在描述现实世界，对现实业务世界进行选择性的数字化抽象。

我们永远不可能建模整个世界，我们又不是Meta（😁）。

拿几个常见的系统来说，CRM关心客户、联系人、商机和合同，ERP关心物料、订单、库存、供应商和生产，项目管理系统关心项目、人员、任务和进度。每个系统都选择自己关心的那部分现实世界，定义数据模型，再围绕这些数据提供API、界面。

原先的软件系统基本上都服务于人，一个人要完成某件事情，可以打开几个页面，查几个系统，必要的时候再找人问一下。人，软件的使用者，将这些信息联接起来。

现在除了服务于人以外，软件系统还需要服务于Agent，Agent不仅需要原子化地访问数据，还需要快速构建与当前任务相关的Context。

本体系统需要把这些数据、关系组织起来，并更高效地为Agent提供上下文。

本体系统要包含哪些数据

让我们来想一个现实中的业务场景，客户来问，一笔订单能不能提前一周交付。

假设我们希望Agent回答这个问题，Agent 首先需要了解这笔订单：客户是谁，订购了什么产品，数量是多少，原定什么时候交付，目前执行到了哪一步。这些是业务对象及其结构化数据。

但只看订单本身还不够。Agent 还需要找到订单对应的生产计划，确认所需物料的库存和采购进度，了解相关供应商能否提前供货，以及负责这笔订单的销售和生产负责人。这些是业务对象之间的关系，它们把客户、订单、产品、物料、供应商和人员连接起来。

即使这些数据都齐全了，Agent 也未必能给出可靠的答复。合同里可能约定了特殊的验收条件，客户的邮件里可能提出过分批交付的要求，最近的会议纪要里可能记录了某种物料的替代方案。这些信息存在于合同、邮件、文档、会议纪要等非结构化内容中，却会直接影响这笔订单能不能提前交付。

因此，本体系统需要存储和组织的，不只是数据库里的一条条业务记录，还包括对象之间的关系，以及围绕这些对象产生的文档和其他内容。这些内容也需要保留来源、时间、版本、状态，以及与业务对象的关联。合同属于哪笔订单，邮件来自哪个客户，会议纪要里的方案是否已经确认，都会影响 Agent 对信息的理解和使用。

本体系统如何为Agent提供上下文

Agent 构建 Context 时，至少需要回答两类问题：

  • 和这个Object有关系的还有什么？
  • 和这个Word语义相关的还有什么？

前者是关系检索，可以由 Graph 模块提供。它沿着明确的 Relation 找到相关对象，并按需继续展开。后者是语义检索，可以由 Vector 模块提供。它从文档等内容中找到与当前任务相关的信息，不要求每一段文字都提前与业务对象建立显式关系。

这两种能力可以配合使用。比如先沿订单找到对应合同，再通过语义检索查找合同中有关交付和验收的条款。也可以先检索到讨论替代物料的会议纪要，再沿纪要关联的物料和生产计划，确认是否涉及这笔订单。

但语义相关不代表业务上适用。检索结果还需要保留来源、时间、版本和状态，供 Agent 判断它是否适用于当前任务。

从这个角度看，本体系统面向 Agent 提供 Graph 和 Vector 两种查询能力，是一件很自然的事情。至于背后是不是 Graph Database 或独立的 Vector Database，这是技术选型的问题，查询能力和物理存储没有必要绑死。

对本体系统来说，更重要的是：它不仅要描述这个业务世界，还要让 Agent 能够在这个世界里找到 Context。