面向 AI Agent 的本体层：从实体对齐到可验证的工具边界

一位用户问：“华星制造目前有多少逾期应收款？”Agent 需要先确认用户说的是哪家“华星制造”，再知道哪个系统负责应收账款，最后查询那套系统中的当前余额。若图谱里存着一份上周同步的金额，模型可能给出一个看似完整、实际上过时的答案；若客户身份被错误合并，查询甚至可能落到另一家公司的账户上。

因此，面向 Agent 的本体层并不只是把业务对象画成图。它还要界定系统中的对象是谁、关系依据什么成立、事实在何时有效、Agent 可以通过什么接口读取，以及系统如何证明这套结构确实改善了回答。

Brijesh Dave 在 《9 Things to Know Before You Build Your Ontology Layer for AI Agents》 中列出九项工程建议。本文不按清单逐条复述，而是沿一条实际调用链来读：先界定问题，再确认实体和事实，最后限制 Agent 能查什么，并用任务结果检验这套设计。

图：从问题定义到评估与治理的概念流程，表示本文整理的依赖关系，不是实测架构。

01 从问题开始，而不是从图开始

图数据库能表达复杂关系，但这并不自动构成本体层的理由。先列出 Agent 必须完成的任务，再看它们是否真的需要跨系统、多跳查询。如果多数问题只是按键读取字段，关系数据库和受控 SQL 工具可能更直接。

Dave 建议从真实问题及其已知答案开始，整理成可重复运行的测试集。新增的每种实体和关系都要能对应到具体问题；暂时没有问题需要的类型，就没有理由先放进首版模型。

例如，询问“华星制造的逾期应收款”至少包含两个不同操作：先识别用户指的是哪家企业，并解析出对应的规范客户，再从负责应收账款的权威系统读取余额。第一步属于身份与关系问题，第二步属于业务事实查询。若把这两者混成“从图里找一个金额”，架构就很容易复制本不该由图谱托管的数据。

02 图谱负责关系，业务系统负责变化中的事实

一种常见的职责划分是：图谱保存实体身份、跨系统关系、权威来源、定义、所有权、血缘和策略；高频变化、大规模明细或需要聚合的数值继续留在原业务系统。图谱不一定要复制余额，可以记录“哪个系统对这个客户的应收负责”以及在该系统中定位记录所需的键。

沿着华星制造的例子，Agent 先调用实体解析接口确认目标企业并得到规范客户 ID。图谱根据该 ID 找到 ERP 中对应的客户键，并标明 ERP 是应收事实的权威来源。随后，一个参数化查询工具带着这个键读取 ERP 或仓库，返回金额、查询时点和来源。

数据放在哪里仍要看查询和更新方式。需要频繁遍历的关系可以留在图中；变化缓慢、且允许作为快照使用的数值也可能适合复制。无论采用哪种方式，都要标明权威来源和更新时限，否则图中的副本可能在不知不觉间落后于业务记录。

03 身份解析先于关系遍历

跨系统图谱的关系只有在端点指向正确实体时才有意义。CRM 里的客户 4471、ERP 里的 C-90210 和数据仓库中一个拼写略有差异的名称，是否代表同一家企业？如果系统把两个不同客户错误合并，后续遍历越完整，错误可能传播得越远。

误拆分和误合并通常不是对称的。误拆分会让一个实体分散在多个节点上，答案可能不完整；误合并则可能把另一家公司的合同、联系人或财务信息带进结果，进一步影响授权和业务动作。风险敏感的场景不宜用一个未经验证的相似度阈值自动合并所有记录。

原文提出按置信度分层：高置信匹配可以自动关联，中间区间进入人工复核或要求模型列明证据字段，低置信度则不建立链接。更重要的是保留源记录，把它们通过带有方法和置信度的关系指向规范实体，而不是物理合并后丢掉原始身份。发现错误时，系统可以撤销或修正链接，并保留调整依据。

阈值需要由具体领域的标注样本和错误成本来校准。原文给出的样本量和工具建议是作者的起点，不应被当作普遍标准。对于银行客户、患者或员工等高风险身份，复核策略显然不能只照搬普通商品目录的做法。

04 事实要回答“何时”和“来自哪里”

实体关系不是永远成立。供应商可能更换负责人，仓库可能停用，合同会到期。一个查询如果只知道“系统当前存有这条边”，却不知道它何时在业务上成立、系统何时获知，就无法可靠地回答“现在是谁负责”或“上个月我们依据什么作出判断”。

因此，关系通常需要携带至少两种时间：业务有效时间，以及系统记录时间。再加上来源系统、来源记录、置信度和认证状态，查询就能区分“这件事当时为真”与“我们何时知道这件事”。失效事实可以关闭有效期而非直接删除，从而保留审计历史。

因此，查询结果不应只有实体名称，还要带回采用的时点、事实来源，以及结果是否限于认证事实。Agent 才能说“截至某时点，ERP 记录为……”，而不是把一份有时间边界的快照说成当前事实。

05 给 Agent 的不是数据库，而是受约束的能力

数据库 schema 主要面向存储和查询；Agent 还需要理解类型名称、关系方向和每个关系的业务含义。DEPENDS_ON 或 OWNED_BY 比含糊的 RELATED_TO 更能约束模型的解释。路径深度、结果条数和截断状态也应由工具执行逻辑限制，而不是寄希望于提示词提醒模型“不要查太多”。

与开放一个通用查询端点相比，一组窄工具更容易审查和测试。例如：先按名称解析实体，再用规范 ID 查询有限深度的依赖关系；或者按给定客户 ID 从指定系统读取当前余额。输入可以限定 ID、时点和最大深度，输出则包含来源、结果数量、查询时点和是否截断。

如果两个客户候选难以区分，实体解析工具应返回“无法确定”，而不是挑一个最相似的名称继续查询。Agent 可以据此追问用户。这样，匹配的不确定性会沿工具结果传到对话里，不会被隐藏在一次看似成功的图遍历中。

06 权限必须跟着调用者进入查询

提示词不能承担图数据的访问控制。允许 Agent 读取一个节点，不代表它也能读取所有相邻节点。遍历结果、邻居数量或错误提示，都可能让它推断受限对象是否存在。

因此，调用者身份应进入工具调用，权限过滤应在查询执行路径中应用到节点和关系。模型可以决定何时调用工具，却不能决定跳过授权检查。测试也不应只确认“允许的结果能查到”，还要用受限节点样本检查它是否会出现在结果、计数、路径或错误提示中。

本体提供对象和关系的语义，访问策略则决定某个身份可以看见和操作哪些对象。两者可以协同描述，但本体本身不是授权令牌，也不能替代业务服务在写操作前检查权限、状态和并发条件。

07 候选事实不能悄悄变成权威事实

Agent 可以从文档中抽取实体和关系，但抽取结果不应因为进入图数据库就自动成为可信知识。一个更可控的路径是区分来自治理系统的认证事实与模型提出的候选事实：候选关系附带文档位置等证据指针，经规则验证或人工审查后，再按明确流程晋升。

摄取过程还应可重复执行。相同批次重放时，不应创建重复实体或关系；不符合约束的记录应进入拒绝或隔离流程，并说明原因，而不是静默丢弃。对于多来源冲突，保存各自断言与出处，再按业务规则选择当前优先值，比覆盖旧值更容易审计和纠错。

08 用任务基线判断图谱是否值得维护

节点和关系的数量不能证明图谱有用。可以用同一组任务比较向量检索、改进 schema 后的 SQL 工具，以及图谱配合专用工具的方案。如果图谱在跨系统或多跳问题上没有带来可观察的改善，就要重新衡量额外的建模、同步、授权和治理成本。

评估不应只报告一个平均分。单跳查询与多跳依赖分析的难度不同；错误实体、陈旧事实、空结果、工具错误、延迟和成本也可能暴露平均正确率掩盖的问题。上线后，数据源变更、关系失效或上游 schema 漂移都可能让过去正确的答案逐渐失效，因此需要持续监控并明确领域负责人。

原文建议把任务集接入变更回归，让模型、映射或工具接口变化后能发现回答退化。这是一种可检验的治理思路；它并不意味着图谱必然胜过向量检索或 SQL，也不提供可直接套用的效果承诺。比较结果需要来自自己的任务、数据和运行环境。

09 本体层的边界

可以把这组职责概括为 Agent 与企业事实系统之间的“语义控制面”：它说明对象如何对应、关系为何成立、事实何时有效，以及 Agent 可以通过哪些工具读取它们。“语义控制面”是本文为解释这些机制采用的说法，不是原文术语或行业标准。

这层结构并不总值得单独建设。如果任务主要是简单字段查询，跨系统身份问题很少，也没有复杂的时态、溯源或关系授权需求，schema 加 SQL 工具可能更轻便。反过来，当 Agent 需要在多个系统间解析同一实体、解释关系并审计事实来源时，身份链接、时间信息和工具边界就不再是图谱的附属细节，而是答案能否被信任的一部分。

是否建设本体层，取决于任务是否需要跨系统关系、事实是否必须带来源和时点、身份错误的代价，以及 SQL 或向量检索能否达到相同结果。把这些条件放进同一组任务里验证，才能判断新增的工程复杂度是否值得承担。

参考资料

• Brijesh Dave, “9 Things to Know Before You Build Your Ontology Layer for AI Agents”, Medium。页面于 2026-11-12 核对；未显示可确认的具体发布日期。