零点未来 · 技术科普

五张「图」，一张图讲明白

Ontology · Knowledge Graph · Context Graph · Code Graph · Graph Engineering
五个高频词，其实分两类：前四个回答「系统知道什么」，最后一个回答「系统怎么干活」。

总览图 · 点击任意节点，直达对应章节
AI SYSTEM 🧠 Knowledge / Context Layer · 知道什么 ⚡ Execution Layer · 怎么干活 Ontology · 本体——跳转到对应章节 Ontology · 本体 定义概念和关系 · 规则书 Knowledge Graph · 知识图谱——跳转到对应章节 Knowledge Graph 知识图谱 Context Graph · 上下文图谱——跳转到对应章节 Context Graph 上下文图谱 Code Graph · 代码图谱——跳转到对应章节 Code Graph 代码图谱 operational knowledge 任务状态 · 事件 · 历史 · 证据 software/code structure 代码结构 · 调用关系 · 依赖关系 前四张图 = 系统知道什么（What it knows） Graph Engineering · 图谱工程——跳转到对应章节 Graph Engineering 图谱工程 构建和运行 Graph 驱动的 AI 系统 Agent Graph · 智能体图——跳转到对应章节 Agent Graph 智能体图 🤖 Agent 🔧 Tool 🧠 LLM ✅ Evaluator 👤 Human 🔁 Loop 节点 = 数据处理、查询、推理、工具调用或 Agent 能力 边 = 数据流、控制流或推理路径 图谱工程 = 系统怎么干活（How it acts）

🟣 紫色 = 描述世界（知道什么）　🟡 琥珀色 = 描述执行（怎么干活）——记住这两块颜色，后面每个图都按这个逻辑来。

0核心结论：知道什么 vs 怎么干活

这五个词里都带「图」，但其实是两类完全不同的东西：

🧠 知识层 · 描述世界 Ontology · Knowledge Graph · Context Graph · Code Graph
回答「系统知道什么」——像地图与燃料
⚡ 最后一个 · 描述执行 Graph Engineering
回答「系统怎么干活」——像轨道与发动机

知道什么，决定 Agent 答得对不对；怎么干活，决定 Agent 做得稳不稳。

一个记法：前四个描述系统知道什么，Graph Engineering 负责让 Agent 使用这些知识完成任务。

1Ontology 本体 — 定义业务世界、规则与可执行能力

打个比方，本体就是公司的「标准术语表 + 家规」：它不记张三李四，只规定——「客户」这个词怎么定义、「客户」和「订单」之间允许有什么关系、哪些规则永远成立。它是字典和语法书的合体，而且严格到机器也能读懂。

Palantir Ontology = Objects + Links + Properties + Logic + Actions + Security

对象 + 关系 + 属性 + 推理规则 + 可执行操作 + 权限安全——本体不只定义「有什么、什么关系」，还定义「谁能做什么、什么条件下能做」。注意：这里的「操作」是一条许可规则（比如「折扣超过 15% 需要 VP 审批」这条规矩本身），真正把多个操作串成一条可执行流程，是图谱工程（第 5 节）的活。

什么时候用它：多个团队/系统要统一口径（医疗里的「诊断」绝不允许有两种意思）；要让机器自己推理出新知识（药 X 治 Y 病 + 患者有 Y 病 ⇒ 药 X 可能适用）；领域知识稳定、精度比速度重要（金融 FIBO、医疗 FHIR）。

装的是什么概念类型、属性、关系规则——不是实例数据
回答什么问题「诊断」是医疗诊断还是软件缺陷？两种「收入」是不是一回事？
多久变一次很少变，改一次走审批、留版本
主要给谁用所有图共同遵守的「语义契约」
规则书长什么样 · 类型 + 关系 + 推理
📖 允许存在的「类型」 Person 人 属性：姓名 · 出生年 Company 公司 属性：名称 · 行业 City 城市 属性：名称 · 国家 📜 允许的关系与规则 worksAt 就职于（一人可多家） Person Company headquarteredIn 总部在（1 对 1） Company City ✍️ 规则示例 knows 是对称的：A 认识 B ⇒ B 认识 A 约束：一张订单只能属于一个客户 🔮 规则能「推理」出新知识 药 X 病 Y treats 治疗 患者 Z has 患有 ⇒ 推断：或可治疗 两条已知事实 ⇒ 一条新知识

本体最值钱的本事是推理：不用人工写死「患者 Z 该吃什么药」，规则自己推出来。

本体的亲戚们 · 语义复杂度递增
① Taxonomy 分类法 只管父子层级：水果＞苹果 ② Thesaurus 词表 补同义词：SODA＝汽水 ③ Ontology 本体 加规则与推理 ④ Knowledge Graph 填进实例与事实 语义复杂度递增 →

四个词不是平级的：一个比一个装得多，本体站在「立规矩」这一级。

本体像建筑规范：规定「墙要多厚、房间怎么连、承重怎么算」，但规范本身不盖房子。知识图谱就是照着规范盖出来的房子。

2Knowledge Graph 知识图谱 — 填满事实的世界网

把本体这套「规矩」真正用起来，往里面填进一个个真实的人和事，就织成了一张「谁——什么关系——谁」的网。你可以把它想成一本长了神经的百科全书：不光查得到条目，还能顺着关系一路问下去。它是世界模型：回答「什么是普遍为真的」这类常识问题。

Knowledge Graph = Ontology Schema + Object Instances + Relationships

本体规则 + 具体实例 + 它们之间的关系——本体定义「客户」和「订单」能有什么关系，知识图谱把「张三」「订单 #8821」这些真实的人和事填进去，回答「企业有什么、它们怎么关联」。

什么时候用它：回答通用常识（巴黎在哪个国家？谁在哪家公司？）；做推荐（「看过这部电影的人还喜欢…」）；让大模型顺着关系网检索而不是瞎猜（GraphRAG 玩法，不挑哪张图）、多跳问答。

装的是什么实体实例 + 类型化关系（谁 → 什么关系 → 谁）
回答什么问题巴黎在哪个国家？谁在哪家公司工作？这类通用常识
多久变一次按需增删，跟着数据走
主要给谁用搜索、推荐、通用问答、GraphRAG
实例网 · 点 = 实体，线 = 关系，小字 = 属性
👤 张三 职位：工程师 🏢 零点未来 行业：AI 软件 🏙️ 北京 国家：中国 👤 李四 职位：架构师 worksAt 就职于 worksAt 就职于 headquarteredIn 总部在 knows 认识 ● 节点 = 实体　● 边 = 类型化关系　● 盒内小字 = 属性

血统：语义网老传统（RDF / OWL / SPARQL），2012 年 Google 知识图谱让它出圈，Wikidata 是代表。

本体 vs 知识图谱 · 规则书与填了内容的网
Ontology · 空的规则书（Schema） 谁 什么关系 谁 只有格式，没有具体的人和公司 填数据 Knowledge Graph · 填满事实的网（Data） 张三 零点未来 北京 张三 ─就职于→ 零点未来 ─总部在→ 北京
维基百科那样的「世界网」：谁和谁什么关系，全世界通用。但注意——它只知道「普遍为真」的事，不知道你们公司此刻发生了什么。这就引出下一张图。

3Context Graph 上下文图谱 — 任务上下文图

Knowledge Graph 描述实体、关系和事实；Context Graph 在此基础上加入任务、状态、事件、证据和历史决策，形成面向 Agent 决策的业务上下文地图：哪张表现在质量如何、谁负责、改一处谁会坏、谁批准过什么例外，而且跟着业务实时更新。它是给 AI Agent 准备的「可信业务上下文地图」。

Context Graph = Knowledge Graph + Task Context + Runtime State + Events + Decisions + Evidence

知识图谱 + 任务上下文 + 运行时状态 + 正在发生的事 + 决策 + 证据——不是缩小范围，而是在「有什么」的基础上叠一层「此时此刻」：现在什么状态、发生了什么事、谁批了什么、凭什么批的，让 Agent 知道当下该关注什么、该怎么决策。

什么时候用它：AI Agent 要进公司干活、需要「可信业务上下文地图」时；做影响分析（改这张表，哪些仪表盘会坏）；审计合规要追溯「谁在何时、因为什么、批准了什么」。

装的是什么数据资产 + 血缘 + 负责人 + 质量 + 权限 + 决策轨迹
回答什么问题哪个仪表盘可信？改了这列谁会坏？谁批的例外？
多久变一次持续更新——管线、负责人、政策都在变
主要给谁用企业 AI Agent 的「锚定层」
企业 Agent 的可信业务上下文地图 · 资产 + 血缘 + 负责人 + 决策
🗄️ sales.orders 订单表 质量 98% ⚙️ dbt 管线 数据加工 📊 Q3 收入 仪表盘 ✅ 已认证 feeds 喂养 produces 产出 👤 王小明 数据负责人 owns 负责 📝 决策轨迹 VP 批准 20% 折扣例外 approver · reason · precedent approves 批准 🤖 AI Agent MCP 查询 ① 语义基础：本体——这些词是什么意思 ② 运行元数据：血缘 · 质量分 · 负责人 · 访问权限（怎么来的、能不能信） ③ 决策轨迹：谁批准了例外、为什么、先例是什么

上面这些边（喂养、产出、负责、批准）才是这张图的核心——不是抽象的「关系」，而是能查出「谁负责、信不信得过、谁批准过什么」的运行记录。

这里说的「上下文图谱」是数据平台厂商（DataHub、Atlan）的用法——锚定一家公司，重决策轨迹和治理。学术圈还有一篇论文也叫《Context Graph》（IDEA Research，2024），讲的是另一件事：给放之四海皆准的知识图谱的每条边多打「时间 · 地点 · 出处 · 置信度」标签（例如「奥巴马 —总统→ 美国（2009–2017）」），解决「A 先生住在上海」和「A 先生住在北京」这类三元组因为丢了语境而自相矛盾的问题——它锚定的还是整个世界，不是一家公司，只是撞了同一个名字，别混为一谈。
有什么 vs 现在该怎么办 · 事实之上叠一层决策上下文
Knowledge Graph · 有什么 什么是「客户」？巴黎在哪个国家？ 静态事实，到处都成立 VS Context Graph · 现在该怎么办 财务部现在该信哪张客户表？为什么？ 事实 + 任务 + 状态 + 决策，实时更新

不是缩小范围那么简单——上下文图谱在事实上面叠了任务、状态、事件和决策，回答的是「现在该关注什么、该怎么决策」，不只是换个「锚定点」。治理五件套：资产盘点 · 血缘 · 负责人 · 质量 · 权限——没治理的上下文图谱，幻觉更难被发现。

Knowledge Graph 告诉 Agent 「企业有什么」；Context Graph 告诉 Agent 「当前为什么重要，以及如何基于这些信息做决策」。

4Code Graph 代码图谱 — 代码的内部管网图

代码图谱是把代码的「内部管网」画出来：函数、类、模块是节点，谁调用谁、数据怎么流、谁继承谁、文档在哪是边。改一行代码之前，先顺着图看看「下游谁会遭殃」。

Code Graph = Source Code + AST + Dependencies + Execution Relationships

源代码 + 抽象语法树（AST）+ 依赖关系 + 执行关系——源代码先解析成 AST，再从 AST 里提炼出「谁调用谁、数据怎么流」，把整个软件系统变成一张能查询的图。

什么时候用它：仓库大到「人脑记不住谁调用了谁」时做代码导航；改公共 API 之前评估影响面；让 AI 编程 Agent 快速读懂陌生代码库、找 bug。

装的是什么类 / 函数 / 方法 + 调用 · 数据流 · 继承 + 文档链接
回答什么问题这个函数被谁调用？改了 read_csv 谁受影响？
多久变一次跟着提交走，代码一变图就变
主要给谁用代码导航、影响分析、编程 Agent
代码图谱 · 调用 / 继承 / 文档 / 影响分析
📄 main.py 入口脚本 📄 utils.py 工具函数 🧩 pandas.read_csv 第三方函数 calls 调用 calls · flowsTo 🧩 sklearn SVC.fit 分类模型训练 🧩 BaseSVC 父类 / 基类 subClassOf 继承 📚 StackOverflow 「SVC.fit 怎么用？」 文档 / 论坛链接 ⚠️ 下游受影响 utils.py · main.py 改这里 → 谁能坏？ 四种边：calls 调用 · flowsTo 数据流 · subClassOf 继承 · doc 文档链接

真实案例：IBM 的 GraphGen4Code 拿 130 万份 Python 文件 + 4700 万论坛帖，建成 20 亿条三元组的代码知识图谱，服务程序搜索、代码理解、bug 检测。

代码世界的「水电管网图」：管线怎么走、阀门在哪、关掉这里哪片会停水——改代码前的风险预演，全靠它。

5Graph Engineering 图谱工程 — 让 Agent 可靠运行

图谱工程就是给 Agent 画「流程图」：一个节点 = 干一件事，一条边 = 干完去哪。哪些步骤必须按规矩走、哪些地方放手让模型自己判断，图上画得一清二楚——而不是让模型全程自由发挥、错了再补。

Graph Engineering = Data Engineering + Graph Modeling + Retrieval + Reasoning + Agent Orchestration

数据工程 + 图建模 + 检索 + 推理 + Agent 编排——前四块「怎么把数据变成图、怎么查、怎么推理」，其实就是第 2～4 节在做的事；本节聚焦最后一块：怎么把这些查询和推理串成一条 Agent 能可靠执行的流程。

什么时候用它：业务流程有固定套路、要稳定可预期（客服先分类再回答、合规审批后才能对外操作）；流程里需要重试、等人审批、回炉重做；要把多个子 Agent 编排成一条流水线（如 LangGraph）。

装的是什么节点 = 动作（代码 / LLM 调用 / 工具 / 子 Agent）
边 = 转移（固定 or 条件）
回答什么问题先干什么后干什么？失败怎么重试？何时等人审批？
多久变一次跟着业务流走，经常调整
主要给谁用Agent 编排（如 LangGraph）
一个真实工作流 · 把「改文档」这件事画成图
💬 Slack 请求 分类 classify 一次 LLM 调用 📖 参考文档 Agent 完整子 Agent 💡 概念文档 Agent 完整子 Agent 综合 synthesize 一次 LLM 调用 ✅ 提交 PR 同一个图里，不同节点自由度不同——这就是「确定性 ↔ 自由度」的混合
灰 = 确定性代码 紫 = 一次 LLM 调用 深紫 = 完整子 Agent
生产级 Agent 图很少是「无环图」 · 循环是家常便饭
🤖 Agent 🔧 Tool 工具 查询 · 写操作 ✅ Evaluator 检查干得咋样 👤 Human 审批 · 补充信息 🏁 结束 干活 检查 不够好？回炉重试 通过 → 等审批 放行

重试、追问、改答案、等审批，全是「回头路」——所以 Agent 图通常不是 DAG。循环其实就是最简单的图；一个节点里还能装下一整个子 Agent。

⚙️ 确定性代码
全自动，无模型 🧠 一次 LLM 调用
模型只判断一步 🤖 完整子 Agent
自由度最高
给 LLM 装「轨道」：路口让模型自己判断，其余路段按既定轨道走——既给自由，又保靠谱。LangGraph 三年 6500 万月下载，靠的就是「确定性轨道 + 智能判断」这个平衡。

6五张图放一起比

概念 一句话大白话 装的是什么 类比 回答什么问题 变多快 给谁用
Ontology本体 定义业务世界、规则与可执行能力 类型 · 关系 · 规则（没实例） 游戏规则、城市规划图 「诊断」到底指什么？ 很少变，改一次走审批 所有图的语义契约
Knowledge Graph知识图谱 填满事实的世界网 实例 + 类型化关系 游戏里的角色和建筑 巴黎在哪个国家？ 按需增删 搜索 · 推荐 · 通用问答
Context Graph上下文图谱 事实之上叠的决策上下文地图 资产 + 血缘 + 决策 + 权限 当前游戏关卡、任务目标、资源状态 哪个仪表盘可信？改这列谁坏？ 持续更新 企业 Agent 的锚定层
Code Graph代码图谱 代码的内部管网图 类 / 函数 + 调用 + 依赖 游戏引擎里的代码结构 谁调用了这个函数？ 每次提交都可能变 代码导航 · 编程 Agent
Graph Engineering图谱工程 让 Agent 可靠运行 节点 = 动作，边 = 下一步 游戏引擎和运行系统 先干什么？失败怎么重试？ 跟着业务流常调 Agent 编排

一句话记忆法：规则书 → 世界网 → 业务上下文地图 → 代码管网图，最后一张是 Agent 轨道。

什么场景用哪张图 · 速查

你的场景用哪张图
多个团队要统一术语，或要机器自动推理出新结论Ontology · 本体
通用常识问答、推荐、多跳问答Knowledge Graph · 知识图谱
Agent 要进公司干活、影响分析、审计追溯Context Graph · 上下文图谱
代码导航、改公共 API 前评估影响、编程 AgentCode Graph · 代码图谱
有套路的业务流程编排，要稳定可控的 Agent 流水线Graph Engineering · 图谱工程

💡 补充：GraphRAG 不是某一张图，而是「顺着关系网检索」的玩法——知识图谱、上下文图谱都能接，别把玩法和图划等号。

7它们怎么串起来

全景架构参考图（原始素材，英文，信息密度更高）
原始架构图附件暂缺。原图描述：Define / Represent / Engineer / Application 四层；Ontology 定义 Schema、Logic Contract、Action Contract、Governance，连接 Knowledge Graph、Context Graph 与 Code Graph，再通过 Graph Engineering 支持 Agent 工作流。下方保留原文解读。

这张图把全文的主线画全了：最上层 Ontology 定规则；中间 Knowledge Graph / Context Graph / Code Graph 三张同形状、不同锚定范围的图；再往下 Graph Engineering 把它们变成可查询、可执行的系统；最底层 Agent 按「理解目标 → 查图 → 推理决策 → 执行动作 → 写回学习」把任务走完。原图信息密度高、术语为英文，点击可在新标签页打开大图看清细节。

一个真实场景 · 采购供应商寻源 Agent

场景：一个 Agent 要自动寻找、评估并推荐供应商——五张图分别在这个任务里干什么活：

Agent 要做的事对应技术
定义采购业务世界：什么是供应商、品类、零件、工厂、合同、评价指标，以及它们之间的关系Ontology
查询企业已有供应商、供应关系、历史采购记录、价格、质量、交付表现等事实数据Knowledge Graph
根据当前寻源任务理解业务背景：本次采购品类、需求数量、目标成本、交付要求、区域限制、供应商策略、历史决策原因Context Graph
理解供应商管理系统、SRM、ERP、采购平台的代码结构，分析新增寻源能力的影响范围Code Graph
构建 Agent 的数据接入、图查询、关系推理、供应商评分、候选推荐、流程编排、审批执行能力Graph Engineering

8总结：两张图

五个等式 · 一眼看懂每张图装的是什么

概念一句话描述 / 等式
Ontology Palantir Ontology = Objects + Links + Properties + Logic + Actions + Security
对象 + 关系 + 属性 + 推理规则 + 可执行操作 + 权限安全——把企业数据、业务语义、计算逻辑和「能做什么」统一成一套业务操作模型。
Knowledge Graph Knowledge Graph = Ontology Schema + Object Instances + Relationships
本体规则 + 实例 + 关系——本体定义对象和关系能有什么，知识图谱把具体的实例填进去，回答「企业有什么、怎么关联」。
Context Graph Context Graph = Knowledge Graph + Task Context + Runtime State + Events + Decisions + Evidence
本体实例 + 运行时上下文 + 事件 + 决策 + 证据——在「有什么」上再叠一层「此时此刻」，让 Agent 理解现在该关注什么。
Code Graph Code Graph = Source Code + AST + Dependencies + Execution Relationships
源代码 + 抽象语法树 + 依赖 + 执行关系——把软件系统转换成图结构，让 AI 理解代码对象、调用关系和修改影响范围。
Graph Engineering Graph Engineering = Data Engineering + Graph Modeling + Retrieval + Reasoning + Agent Orchestration
数据工程 + 图建模 + 检索 + 推理 + Agent 编排——构建和运行基于图的 AI 系统，让 Agent 能可靠查询、推理和执行。

AI Agent 正在出现「两张图」：
一张描述世界，一张描述执行。

前四张图回答「知道什么」，图谱工程回答「怎么干活」——两张都齐，Agent 才既懂行、又靠谱。

9参考文件

  1. 3 Years of Graph Engineering with LangGraph — LangChain Blog · 2026-07
    图谱工程三年实践：节点/边建模、生产 Agent 通常不是 DAG、循环是最简单的图、节点里可装完整子 Agent。
  2. Context Graph vs Knowledge Graph: What's the Difference? — DataHub Blog · 2026-04-30
    核心区别不是结构而是「范围与锚定点」：知识图谱是世界模型，上下文图谱是组织模型。
  3. Context Graph vs. Ontology: Differences, Roles & Use Cases — Atlan · 2026-01-27
    上下文图谱三层：语义基础、运行元数据、决策轨迹；治理五件套；Agent 通过 MCP 在推理时查询。
  4. Taxonomy vs. ontology vs. knowledge graph: What's the difference? — Neo4j Blog · 2026-06-17
    分类法是层级、本体是语义与规则、知识图谱是装数据的实现层——蓝图与成品的关系。
  5. A Toolkit for Generating Code Knowledge Graphs（GraphGen4Code） — IBM Research · 论文（arXiv:2002.09440）
    代码知识图谱工具包：130 万 Python 文件 + 4700 万论坛帖 → 20 亿三元组，服务程序搜索与 bug 检测。论文原文：https://arxiv.org/abs/2002.09440
  6. Context Graph（CGR3 推理范式） — IDEA Research · 学术论文
    三元组缺「语境」：时间、地点、出处、置信度；CGR3 = 检索 → 排序 → 推理，迭代补充上下文。论文原文：https://arxiv.org/abs/2406.11160
← AI 战略认知 · 全部文章