ontology 是什么：给 AI 装上「概念字典」

大多数 AI Agent 处理问题的方式是这样的：你问它「DeepSeek R1 和 Claude 3.7 哪个更适合代码任务」，它开始检索、召回、推理……但它对这三个概念之间的关系，其实没有结构化的理解。它只是在向量空间里做相似度计算。

ontology 技能要解决的，就是这个问题：给 AI Agent 装上一张「概念关系网络」，让它知道概念之间的层级、类型、属性、关联。

在 ClawHub 上，ontology 技能有 126k+ 下载量，是下载量排前三的技能之一。我们实际用了三周之后，来说说它到底在解决什么问题。

安装与基础配置

安装很简单：

clawhub install ontology

安装后会在 workspace 生成 ontology/ 目录，核心文件是 ontology.json，这是你的知识图谱定义文件。

基础结构长这样：

{
  "version": "1.0",
  "namespace": "sfd-lab",
  "entities": {
    "Agent": {
      "type": "class",
      "properties": ["name", "role", "capabilities", "limitations"],
      "relations": {
        "reports_to": "Agent",
        "collaborates_with": "Agent",
        "owns": "Project"
      }
    },
    "Project": {
      "type": "class",
      "properties": ["name", "status", "stack", "repo"],
      "relations": {
        "assigned_to": "Agent",
        "depends_on": "Project"
      }
    }
  }
}

这是我们给 SFD 实验室自定义的 ontology 结构——把「Agent」和「Project」都定义成实体类，再定义它们之间的关系。

实战场景一：多 Agent 协作中的角色推断

没有 ontology 的时候，我派任务需要手动附加很多上下文：小蜜蜂要部署哪个服务器、仓库地址是什么、有没有 SSH 权限。Agent 没有这些上下文就要猜、要追问。

装了 ontology 之后，我们在知识图谱里定义：

{
  "instances": {
    "小蜜蜂": {
      "type": "Agent",
      "role": "DevOps",
      "capabilities": ["SSH", "PM2", "Nginx", "Docker"],
      "servers": ["wafcdn-prod.sfd.com", "149.104.44.34"]
    },
    "wafcdn-prod": {
      "type": "Server",
      "ip": "149.104.44.34",
      "services": ["nginx", "pm2"],
      "owner": "小蜜蜂"
    }
  }
}

派任务时，ontology 技能会自动 resolve 这些关系，把相关上下文注入任务描述。小蜜蜂收到的是一个「完整的」任务，不需要反复追问。

实战场景二：知识图谱 + 图查询

ontology 技能内置了图查询接口，用自然语言来查：

ontology query "who owns database"

输出：
小章鱼 (role: Backend Dev)
- owns: PostgreSQL (sfd-prod)
- owns: Redis (bacaku-cache)

这不是向量相似度搜索，是图遍历——结果是精确的，不是「最相近」的。在需要明确归属和权限边界的场景下，这个精确性非常有价值。

实战场景三：文档自动关联

给文档打实体标签后，Agent 处理相关任务时会自动关联：

ontology tag docs/prd-wafcdn.md   --entities "Project:WAFCDN, Agent:变色龙, Agent:小蜜蜂"

变色龙写代码不需要自己去找 PRD，ontology 已经帮它找好了。相关文档在任务开始前自动注入上下文。

踩坑记录

坑 1：格式验证很严格
ontology.json 任何拼写错误或关系类型不匹配，加载都会静默失败。每次改完建议跑：

ontology validate ontology/ontology.json

坑 2：instances 不要定义太细
我们最开始把每台服务器的每个端口都定义进去，文件膨胀到 500 行，查询变慢。按「需要跨 Agent 协作才需要共享的信息」这个原则精简到 120 行，反而更好用。

坑 3：与 MemOS 的关系
ontology 是结构化关系定义，MemOS 是语义记忆。两者互补：ontology 管「谁是谁，谁负责什么」，MemOS 管「这件事以前怎么做的」。我们两个都在用，分工很清晰。

和其他技能的配合

ontology + multi-agent-cn：最强组合。multi-agent-cn 负责协调调度，ontology 提供每个 Agent 的能力边界和资源图，任务路由精准度大幅提升。

ontology + self-improving-agent：错误发生时，ontology 能精确定位「这个错误属于哪个 Agent 的职责范围」，让 lessons 记录更有结构。

SFD编者注

我们装 ontology 的初衷是解决信息孤岛，用下来发现更大的价值是「降低协作歧义」。15个 Agent 说「数据库」，每个人可能指的不是同一个。ontology 强迫你把模糊概念显式化，这个过程本身就让团队协作更清晰了。

126k 下载不是白来的。