字数 3353，阅读大约需 17 分钟

知识图谱的Agent可供性：从“有什么”到“能做什么”

现在大模型Agent做任务，越来越依赖知识图谱（KG）来获取结构化知识、支撑推理判断。但实际用起来，很多时候更像开盲盒：查不到结果，到底是事实本身不存在，还是KG没收录？同一个概念名，Agent理解的含义和KG里定义的，真的是一回事吗？返回的查询结果，能不能直接拿来做可靠的逻辑推导？

目前行业通用的KG元数据标准，比如VoID和DCAT，基本都在回答“KG里有什么”：三元组规模、实体类型分布、引用的Schema、许可协议等等。但站在Agent的视角，这些信息远远不够。Agent真正关心的问题是：这个KG能不能支撑我完成当前任务？我从里面得到的结论，在认知上是可靠的吗？

最近利物浦大学与开放大学的研究团队，把二十年前语义Web服务领域的成熟思路拓展到知识图谱场景，提出了**Agent可供性画像（Agentic Affordance Profile, AAP）**的四维度形式化框架，试图系统性解决这个问题。今天我们就来拆解这套框架。

一、老问题的新场景：从Web服务到知识图谱

其实“调用前先判断资源合不合适”这个问题，早在二十年前的语义Web服务（SWS）领域就被深入研究过。当时诞生了OWL-S和WSMO两套经典框架，核心就是用本体来形式化描述服务能力，让不同本体承诺的Agent可以在调用前，判断服务能不能用、哪里需要做语义桥接。

OWL-S把服务描述拆成了三个部分，分别对应Agent的三个核心问题：

  • • Profile：这个服务能做什么？用于服务发现与匹配

  • • Process Model：内部执行逻辑是什么样的？用于服务组合

  • • Grounding：具体怎么调用？用于协议对接

放到知识图谱场景，这三个问题同样成立：

  1. 1. 我能用这个KG做什么？哪些查询有意义、哪些推理可靠

  2. 2. 查询和推理遵循什么规则？闭包假设是什么

  3. 3. 我该怎么访问它？SPARQL端点、权限、联邦能力

现在的技术已经把第三个问题解决得很好，但前两个问题，尤其是第一个，始终很薄弱。现有标准只描述KG的内容属性，不描述它对特定任务、特定Agent的可用价值。

WSMO还贡献了另一个关键思路：把中介（Mediator）作为一等公民。它不是简单的转换脚本，而是有明确语义输入输出的桥接组件，Agent可以在规划阶段就判断它能不能补上语义缺口。这个思路放到KG互操作场景同样适用：对齐服务、推理服务都应该是可被规划的对象，而不是出了问题才临时调用的修复手段。

二、什么是Agent可供性？四个维度讲清楚

“可供性（Affordance）”这个概念来自生态心理学，核心意思是：一个事物的价值不是它固有的，而是相对于特定使用者而言的。同样一段台阶，对成年人可供行走，对轮椅使用者就不具备这个可供性。

放到知识图谱场景，一个KG的可供性，就是它能让特定Agent在特定任务上做什么、做到什么可靠程度。论文把它拆解成了四个维度，彼此之间的交互关系如下图所示：

图片

图1 AAP四个维度的交互结构。语义表达力约束了信任范围的上限，也决定了任务接地的计算成本；可发现性是元维度，依赖另外两个维度的信息是否公开；任务接地和信任范围共同决定了任务最终是否可行。

这四个维度同时也对应了知识图谱“本体连续统”的属性/可供性、语义/语用两个正交划分，如下表所示：

| | 属性（KG固有）

|

可供性（相对Agent与任务）

语义（形式化/推理）

|

-

| G

：任务词汇签名接地

| |

语用（工程/运行）

| ε

：语义表达力（DL片段）

| R

：推理机制与闭包假设

|

表1 AAP四维度与本体连续统的映射关系。其中D（Agent可发现性）是元维度，衡量有多少可供性信息能从元数据里直接查到。

下面我们逐个拆解这四个维度：

1. 语义表达力（Semantic Expressivity, ε）

这是整个框架的基础，描述KG的Schema所使用的本体语言表达能力，以及实际数据和Schema的符合程度。
从无结构的纯RDF，到RDFS，再到OWL 2的EL、QL、RL等轻量子语言，直到OWL 2 DL、OWL 2 Full，表达能力逐步增强。
它的重要性在于：Agent要做推理，就得知道边界在哪里。比如要做传递性推理，Schema就得支持传递属性链；要做基于查询重写的本体数据访问，就得是OWL QL这类子语言。
现实里一个很常见的坑是：KG标称用了OWL DL的Schema，但实际部署的三元组存储根本没开推理，实际可用的只有基础SPARQL查询能力。这种“标称”和“实际”的脱节，是现有元数据完全看不到的认知隐患。

2. Agent可发现性（Agentic Discoverability, D）

这是一个元维度，它不描述KG本身的内容，而是描述：Agent不用真正发起查询，仅通过元数据就能判断出多少可供性信息。
现实中的KG在这个维度上差异很大：

  • • 最差的只有一个裸SPARQL端点，Agent只能自己探

  • • 好一点的有VoID/DCAT元数据，能看到基础结构信息

  • • 更好的有完善的自然语言文档

  • • 最理想的是有完整的AAP画像，Agent在规划阶段就能精确评估适用性

D值越高，Agent的试错成本就越低，不用一个个调用踩坑，就能完成KG选型。

3. 任务相关接地（Task-Relative Grounding, G）

这个维度回答一个核心问题：KG的词汇体系，能不能真正覆盖Agent任务需要的概念？
注意，这不是简单的名字匹配。论文用了Beth可定义性：哪怕KG的Schema里没有同名的类，只要通过现有公理能隐式定义出这个概念，就算完成了接地。
举个论文里的例子：两个KG里都出现了Invited_speaker这个实体。第一个KG基于Conference.owl构建，TBox里有完整的公理约束这个概念的含义；第二个KG只是在数据里用了这个IRI，Schema里没有任何定义。表面看都有这个词，但第一个是真正语义接地的，第二个只是标签相同，含义没有约束，Agent用起来很容易出现语义偏差。
G值就是任务签名中的概念，有多少比例能被KG的签名闭包覆盖。当G<1时，缺口就明确指出了哪些概念需要做本体对齐或词汇中介。

4. 认知信任范围（Epistemic Trust Scope, R）

这是最容易被忽略、但对推理可靠性至关重要的维度：Agent拿到查询结果，能在多大程度上把它当成可靠的结论来用？
核心就是世界闭包假设。比如查询“两种药物是否存在禁忌症”，如果返回空结果：

  • • 封闭世界假设（CWA）下，空结果=不存在，是可靠的否定结论

  • • 开放世界假设（OWA）下，空结果=未记录，不能得出否定结论
    现实中更多是局部封闭世界（LCWA）：部分谓词是封闭的，其余开放。SHACL的Closed Shape就是工程上常用的实现方式。
    R维度由三部分组成：一致性状态、声明的推理机制、谓词级别的完整性声明。它直接决定了Agent哪些推理是认知上可靠的，哪些结论不能乱下。
    很多公开KG的问题就在于：Schema写得很复杂，但实际运行时既不开推理，也不声明闭包假设。这种KG的实际可供性远低于标称水平，但光看元数据根本发现不了。

三、实战例子：三个学术KG，为什么只有一个能用

论文用一个学术搜索场景做了非常直观的演示：会议程序主席需要筛选“近年在知识工程领域发表过成果、但从未担任过大会特邀讲者的研究者”。
这个任务的关键在于：必须能可靠地判断“某人不是特邀讲者”，也就是需要对Invited_speaker谓词做可靠的否定推理。

现有三个候选KG，它们的AAP画像和规划结论如下：

| | ε

|

D

|

G

|

R

|

规划结论

KG 1

|

RDFS

|

低

|

0.5

|

Simple

|

G失败：Invited_speaker无TBox接地

| |

KG 2

|

OWL EL

|

中

|

1

|

EL，无闭包声明

|

R失败：否定推理不可靠

| |

KG 3

|

OWL DL

|

高

|

1

|

DL + SHACL封闭

|

全部满足，可选用

|

表2 三个候选KG的AAP对比与规划结论。表面看都是学术领域KG，但从任务视角看可用性天差地别。

我们逐个看：

  • • KG1：只有基础RDFS Schema，只定义了研究者、论文、作者关系。虽然数据里可能有Invited_speaker这个标签，但Schema里没有任何公理定义它，语义上没有接地。对应的补救措施是引入本体对齐服务，补上缺失的TBox定义。

  • • KG2：有完整的OWL EL本体，词汇全覆盖，但没有任何完整性声明，默认开放世界。它能准确查出谁是特邀讲者，但查不到的人不能断定“不是”。对于需要否定结论的任务，认知上不可靠。这种情况修内容没用，要么换KG，要么补充闭包声明。

  • • KG3：完整OWL DL Schema，有正式AAP画像，Invited_speaker通过SHACL Closed Shape声明为局部封闭。四个维度全部满足，可以直接选用。

这个例子清晰地说明：只按主题选KG是远远不够的。同样是学术领域KG，有的能用，有的只能用一半，有的看起来能用但推理结论站不住脚。有了AAP框架，Agent在规划阶段就能定位缺口、匹配补救方案，而不是调用之后才发现问题。

四、落地之路：还有五件事要做

论文也明确提出了五点研究议程，说明这套框架要真正成为可落地的基础设施，还有不少工作要推进：

  1. 1. AAP本体形式化：需要把四个维度的描述做成标准OWL本体，让Agent可以自动解析和匹配。现有标准只能覆盖ε和D的部分信息，G和R相关的标注词汇目前还是空白。

  2. 2. 任务接地的可计算性：轻量级本体（如OWL EL、QL）计算G值有成熟高效的方法，但表达力更强的本体计算Beth可定义性成本很高。如何做可靠的近似，让它在大规模KG上跑得动，是核心工程挑战。

  3. 3. 组合可供性语义：多KG联邦场景下，可供性不是简单相加。不同KG的公理可能冲突，闭包假设可能不兼容，组合后的认知可靠性需要重新刻画。

  4. 4. 知识服务规范：用于补缺口的对齐服务、推理服务，也需要标准化的能力描述。Agent要能在规划阶段就判断一个中介能不能补上语义缺口，而不是调用之后才知道。

  5. 5. 工程集成与落地：需要工具帮助KG发布方自动计算各维度取值，还要和现有Agent规划框架无缝对接。尤其是LLM驱动的Agent，如果能把AAP校验作为工具调用的前置检查，可以大幅减少无效调用。

结语

总的来说，AAP框架并不是要取代现有的KG元数据标准，而是在VoID、DCAT之上增加一层语义描述，把描述视角从“发布方看KG有什么”，切换到“Agent看KG能做什么”。

现在Agentic AI发展很快，大家都在优化Agent的规划能力、工具调用能力，但对知识资源本身的语义描述，整体还比较粗放。很多Agent调用知识图谱、调用外部工具，都是“先试了再说，不行再调整”，既浪费算力，又容易得出不可靠的结论。

从“试错式调用”走向“规划期预判”，是Agent走向可靠、高效的必经之路。而知识图谱的Agent可供性画像，正是这条路里一块很扎实的拼图。

<span></span><code data-language-pending="" data-raw-code="https://arxiv.org/pdf/2605.19186" data-show-line-number="false"><span leaf="">https://arxiv.org/pdf/2605.19186</span></code>