实体本体已被标准解决，上下文图的真正挑战在于时间有效性、决策轨迹与事实解析，应采用已有基础再聚焦学习新颖内容。
作者背景：本文作者系 Graphlit 联合创始人，过去三年专注于构建支持 AI 代理的上下文基础设施，深度参与上下文图相关技术实践与行业讨论。
Context Graphs：本体论之争错在哪？——一个被忽视的真相
如果你最近两周在 AI 圈子里混过，那你不可能没听过“上下文图”（Context Graphs）这个词。这股热潮最初由 Foundation Capital 的重磅报告《上下文图：AI 的万亿美元机遇》点燃，紧接着 Animesh Koratana（阿尼梅什·科拉塔纳）在 X 上发表了一篇关于“坐标系统”的技术长文，把讨论推向了技术深水区。
随后 Daniel Davis（丹尼尔·戴维斯）又发布了《上下文图宣言》，把这场讨论与早已沉寂的语义网（Semantic Web）传统重新连接起来。我本人也撰写了两篇回应文章，分别聚焦于“操作上下文层”和“构建事件时钟”。
这场对话非常重要。因为大家提的问题极其关键：我们如何赋予 AI 代理组织记忆？如何捕获决策轨迹？如何构建能从真实工作流中学习的系统？这些都是对的方向。然而，我注意到一种正在成形的叙事框架——它虽然听起来很酷，却从根本上误解了问题所在。由于我过去三年一直在构建上下文基础设施，今天必须站出来说点实话。
我的观点很简单：实体本体（entity ontologies）在很大程度上已经被现有的标准解决了。真正未被攻克的难题，是时间有效性（temporal validity）、决策轨迹（decision traces）和事实解析（fact resolution）。学习型方法在这里才有用武之地——而不是在实体建模层。真正的分野不是“预设 vs 学习”，而是“先采用已有基础，再用学习捕捉新颖内容”。
被过度简化的“预设 vs 学习”二分法
目前的讨论已经固化成一个二元对立：一边是 Palantir（帕兰蒂尔），另一边是“未来”。
支持帕兰蒂尔的一派认为：这家公司靠预设本体构建了一个 4000 亿美元市值的巨头——先定义好 Schema，再把混乱的企业数据强行映射进去，最后派“前线工程师”到客户现场做高度定制。这套方法有效，但成本高昂、速度慢、无法规模化。
而另一派则鼓吹“学习型本体”：让结构从真实工作中自然涌现，而非由人提前设计。AI 代理的行动路径（agent trajectories）就是训练数据，决策轨迹会自动编译成组织的世界模型。本体不是被声明的，而是被“发现”的。
Jaya Gupta（佳雅·古普塔）最近一篇帖子说得更直白：“下一个 500 亿美元公司，将建立在学习型本体之上。结构应从真实工作流中涌现，而非按你预设的方式发生……传统记忆假设你知道该存什么、怎么取。但最有价值的上下文，是你根本不知道存在、直到代理通过使用才发现的结构。”
阿尼梅什进一步用技术语言包装：他提出五大坐标系统（时间线、事件、语义、归属、结果），它们之间没有共享主键。解决方案是用代理轨迹作为训练信号，学习能编码“跨坐标可连接性”的嵌入（embeddings）。本体，就从这些“行走路径”中自然浮现。
这个框架很优雅，听起来是“民主化的未来”对抗“昂贵的旧世界”。但它忽略了一个事实：过去二十年，本体工程早已积累了海量成果，却被当前讨论集体无视了。
被遗忘的“第三条路”：站在巨人肩膀上
当前的争论只给出了两个选项：
1. 帕兰蒂尔路线：花数月甚至数年，靠前线工程师为客户手搓定制本体。贵、慢，但有钱人能用。
2. 学习路线：让代理自由奔跑，结构自动生成。不预设，只发现。
但其实还有一条隐藏路径被完全忽略了：采用已有标准，在需要处扩展，把学习精力聚焦于真正新颖的部分。
争论双方好像都忘了——本体不是非黑即白的“从零造轮子”或“等 AI 自动发明”。事实上，大量本体工作早已在生产环境中运行多年。让我带你回顾几项被忽视的“前人成果”。
首先是 Schema.org。这是由谷歌、微软、雅虎和 Yandex 在 2011 年联合发起的协作型结构化数据词汇表。它定义了网络世界中最核心的实体类型：Person（人）、Organization（组织）、Place（地点）、Event（事件）、Product（产品）、CreativeWork（创意作品）等数百种。这绝非纸上谈兵——全球数十亿网页都在用它。你在谷歌搜索看到的富媒体摘要（如活动日期、商品价格、菜谱评分），背后就是 Schema.org 标记在起作用。
一个“人”有姓名、职位、所属组织；一个“组织”有名称、位置、雇员；一个“事件”有开始时间、结束时间、地点、主办方……这些类型清晰、关系明确，正是上下文图所需的实体建模基础。这不是需要你从头构建的定制本体——它已经存在、被维护、且专为这类场景设计。
再看微软的 Common Data Model（通用数据模型，简称 CDM）。很多人不知道，CDM——驱动 Dynamics 365、Power Platform 等微软企业套件的底层 Schema——其实是从 WAND 公司授权而来的。WAND 已深耕企业分类法和本体数十年，远早于当前 AI 热潮。当微软需要一套企业级实体模型（如 Account、Contact、Lead、Opportunity、Case、Product、Campaign）时，他们没自己造轮子，而是直接买了现成的。
CDM 不是理论模型，而是运行在成千上万家企业的生产系统中。这说明：企业本体问题早已有人反复打磨，微软的选择恰恰证明——复用比从零开始更高效。
此外还有行业专用标准：医疗有 FHIR（用于临床数据交换）和 SNOMED（医学术语）；金融有 FIBO（金融商业本体）；制造业、物流、能源等各领域都有自己的本体规范。这些都不是学术玩具，而是真实世界的基础设施。比如 FHIR 定义了如何表示患者、病症、药物、观测数据和临床工作流。当我们帮生物医药公司构建药物研发知识图谱时，并不会从零定义“化合物”是什么——而是直接采用 FHIR 基元，在必要处扩展，把精力集中在真正新颖的问题上，比如“某个化合物的观测数据如何随临床试验阶段演变”或“如何跨研究连接发现”。
关键点不是某个本体能解决所有问题，而是：“什么是患者？什么是账户？”这类基础问题，过去几十年已被反复定义、验证、优化。地基已经打好，就看你愿不愿意用。
帕兰蒂尔到底做错了什么？
丹尼尔·戴维斯曾一针见血指出：“我不明白为什么大家都觉得帕兰蒂尔有什么本体技术。他们根本没有。他们靠前线工程师花数月甚至数年为客户手搓本体。这不是规模化构建上下文图的方式。”
这话值得深挖。帕兰蒂尔的昂贵，并非因为“预设本体本身难”，而是因为他们拒绝复用已有标准，坚持为每个客户从零定制。这是一种商业选择，而非技术必然。
你可以直接采用 Schema.org 类型，结合 CDM 模式，再按需添加领域实体——完全不必陷入经年累月的手工建模。帕兰蒂尔模式的本质，是“披着平台外衣的高端咨询”，其瓶颈不在于本体预设，而在于拒绝站在已有成果之上。
学习型本体真正该用在哪儿？
我并不全盘否定学习型本体的理念，但它被用错了地方。
像 Person、Organization、Account、Contact、Event 这些实体，根本不需要 AI 去“发现”。我们人类早知道它们存在，类型稳定，关系清晰。让代理跑上百万次才“意识到账户和联系人很重要”，就像让搜索引擎跑一百万次才“发现名词存在”一样荒谬。
这里有个绝佳类比：CRM（客户关系管理）的定制化，本质上就是本体建模。
当 VC 基金配置 CRM 时，他们会定义 Fund（基金）、Investment（投资）、Portfolio Company（被投公司）、LP（有限合伙人）等对象及其关系；招聘公司会建模 Candidate（候选人）、Position（职位）、Client（客户）、Placement（入职）；房产中介则追踪 Property（房产）、Listing（挂牌）、Buyer（买家）、Agent（中介）。
这不就是本体设计吗？只是没人叫它这个名字。
如今一批“AI 原生 CRM”初创公司（如 Lightfield、Clarify、Forge AI、Day.ai）正试图跳过这步——不提前配置 Schema，让系统自动推断。这正是学习型本体在 CRM 领域的落地尝试。
但即便最激进的“自建 CRM”方案，也默认你知道“交易有阶段”、“联系人属于账户”、“活动连接人与机会”。为什么？因为 Salesforce、HubSpot、Attio 的标准对象高度相似——核心实体在跨行业间具有惊人稳定性。
AI 真正能帮上忙的地方是：发现哪些自定义字段实际被用、哪些关系频繁触发、哪些对象对这个团队真正关键。这才是组织智能（organizational intelligence）——它建立在稳定基础上，而非取代基础。
具体来说，学习型方法应聚焦于组织特有层：
- 某个账户中，到底哪位联系人对这笔交易真正有决策权？
- 实际决策流程是什么（而非组织架构图上的虚线）？
- 哪些例外会被批准，哪些会被拒绝？
- 真正指导决策的先例是什么？
这些是“隐性知识”（tacit knowledge），不存在于任何标准本体中，只存在于员工头脑、Slack 聊天记录、审批模式里。这才是学习型本体的正确战场——不是“发现账户是实体”，而是“发现 Sarah Chen 才是真 boss，尽管 CRM 写的是她上司”。
当前的学习型本体叙事混淆了两个根本不同的问题：
1. 实体建模：存在哪些事物类型？它们如何关联？（已有标准可解）
2. 组织智能：这个特定组织如何实际运作？决策受哪些模式支配？（需学习）
前者是基础设施，后者是洞察。两者需要完全不同的方法论。
冷启动悖论：没有地图，如何行走？
学习型本体还有一个致命漏洞：你无法在代理有效运行前就获得轨迹数据，但代理又需要基础上下文才能有效运行。
正如我在前文所说：“你不能等上千次代理 RAG 查询后才‘发现’Sarah Chen 是 Acme Corp 的员工。你必须在代理开始推理前就知道这一点。否则每次轨迹都要重新解决身份识别问题——你得为这种混乱支付高昂的 token 成本、延迟和错误率。”
阿尼梅什用的 node2vec 类比其实恰恰证明了这点：node2vec 是从已有图结构的“行走路径”中学习嵌入，它并不从零发现节点和边。图必须先存在。
AI 代理同理：代理引擎是在预建的“地图”上调用工具。这张地图就是操作上下文——包含已解析的实体、已建立的关系、时间状态。
先建地图，再让代理高效行走。
那么如何冷启动？学习型本体对此没有清晰答案。“让代理跑起来，结构自现”这说法，假设你已经有东西可跑。
实际做法是：先采用现有本体打地基，再用学习优化扩展。
- 用 Schema.org 定义实体类型
- 用 CDM 模式处理企业对象
- 用这些标准类型从内容中提取实体
- 解析身份（邮件中的 Sarah Chen = Slack 中的 @sarah）
- 构建初始图谱
然后才运行代理，从轨迹中学习：哪些关系最常用？哪些模式反复出现？哪些例外成了先例？
这根本不是“预设 vs 学习”的对立，而是“先采用，再学习”——地基先行，智能叠加。
真正未解的难题：时间、决策与事实
如果实体建模已被解决，那上下文图真正的硬核挑战是什么？
答案是：不是名词，而是时间与决策层。
首先是时间有效性（Temporal Validity）。
大多数系统只能告诉你“现在什么为真”，却无法回答“过去某刻什么为真”或“真相如何演变”。
“Paula 在微软工作”是个事实，但不完整。她何时入职？现在还在吗？2022 年时情况如何？
这就是阿尼梅什所说的“事件时钟”——追踪状态如何随时间变化的基础设施。事实应带 validAt 和 invalidAt 时间戳，系统应能查询“做那个决策时，我们对这个账户的认知是什么？”
现有本体（如 Schema.org、CDM）完全不支持这种时间维度。这是真正需要从零构建的新基础设施。
其次是决策轨迹（Decision Traces）。
Foundation Capital 的原始报告点出了关键：连接数据与行动的推理过程，从未被当作数据捕获。
比如，续约代理提议 20% 折扣（尽管政策上限是 10%），财务批准了。CRM 只记录“20% 折扣”，但所有让这决策成立的上下文——多系统数据、政策评估、例外路径、审批链——全部消失。
捕获决策轨迹不是本体问题，而是埋点问题。你必须嵌入决策执行路径，不仅记录“发生了什么”，更要记录“为何被允许发生”。
现有本体根本没有“本决策基于 v3.2 版政策，经 VP Sarah Chen 特批，参考了 Q2 Acme 交易先例”这类原语。这是全新领域。
最后是事实解析（Fact Resolution）。
从内容中提取的事实只是“断言”，未必是真相。内容可能错误、过时或矛盾。
比如，三月邮件说“客户要续约”，九月 Slack 说“客户已流失”。两者都是提取的事实，但不可能同时为真。
事实解析要判断：哪个是权威版本？哪个被后续信息覆盖？如何综合时间线上的碎片观测？
这需要对时间有效性、信源权威性、证据更新机制做判断。这不是本体工程，而是维持信念一致性的 AI 难题。
对构建者的启示：别在已解决的问题上浪费子弹
企业端的需求很明确。Box CEO Aaron Levie（亚伦·列维）最近说：“21 世纪最关键的竞争优势，是一家公司捕获、管理并围绕正确上下文构建流程的能力。” 他说对了。企业正意识到：AI 代理的好坏，取决于它接收到的上下文质量。
但如果你正在构建上下文基础设施，框架选择决定了你的精力分配。
“学习型本体”叙事会引导你聚焦轨迹捕获、嵌入学习、结构涌现——试图让代理从零发现本体。
而我主张：聚焦真正未解的难题。
- 实体建模？直接采用现有标准。别花数月定义“账户”是什么——微软早从 WAND 买了现成方案。
- 时间有效性？这才是战场。构建带时间戳的事实，支持历史状态查询，把时间作为一等公民。
- 决策轨迹？这才是机会。嵌入执行路径，把推理过程数据化。
- 事实解析？这才是硬核 AI。用 LLM 判断权威性、处理矛盾、合成时间线事实。
- 组织学习？轨迹确实有用——但必须建在地基之上，而非取代地基。
未来的赢家，不会是那些从零学习本体的公司，而是善用已有基础、全力攻克新难题的团队。
我们在做什么：Graphlit 的实践
在 Graphlit，我们从 2021 年起就采用上述思路。让我们意外的是：本体从来不是瓶颈。我们早期就采用 Schema.org 类型，再没回头。真正的难题始终在别处。
我们用 Schema.org 类型（Person、Organization、Place、Event）作为实体基础，以 JSON-LD 序列化。我们不迷信 RDF 或三元组存储，只关心类型和关系。带 @type 字段的 JSON，既兼容 Schema.org，又无需开发者学习语义网技术栈。
现实迫使我们构建的是混合存储系统：实体同时存在于向量库、JSON 元数据存储和图数据库中。这让我们能跨多维度联合查询：
- 时间维度：这事何时为真？
- 地理维度：这事发生在哪里？
- 语义维度：什么内容与之相似？
- 全文维度：哪些文本提及它？
- 图谱维度：它如何关联他人？
组织知识天然跨这些维度——一场销售会议有具体时间、城市、关联账户、语义内容（类似其他对话）、人物与产品关系。你必须能同时查询所有维度。
我们正构建现有本体缺失的时间层，扩展决策轨迹能力。我们的 MCP 服务器嵌入代理的上下文检索路径。当代理通过 Graphlit 执行工作流时，我们不仅能捕获其访问的内容，还能记录其推理模式。
我们也在构建事实解析引擎——用 LLM 驱动的基础设施，从累积断言中判断当前真相，从碎片观测中合成时间线事实，维持证据积累下的信念一致性。
本体地基不是难点——Schema.org 给了我们。难点是之后的一切：时间、决策、解析、学习。
我们正聚焦于此。
语义网终于赢了——只是换了一身衣服
这场讨论其实有一条隐藏主线：语义网社区（RDF、OWL、链接数据）几十年来一直在解决这些问题。Schema.org 正是从这一传统中诞生的。机器基于结构化、互操作数据进行推理的愿景，并非 2024 年 AI 圈的新发明。
甚至“上下文图”一词也有学术渊源。2024 年 6 月一篇 arXiv 论文正式将 Context Graphs 定义为知识图谱的扩展，加入时间有效性、地理定位和来源溯源——这正是三元组表示所缺失的维度。研究者证明，加入这些上下文层能显著提升知识图谱任务的推理性能。Foundation Capital 为 AI 企业界普及的概念，其实在学术界早已被形式化。
当初阻碍语义网普及的，不是理念，而是语法。RDF、SPARQL、OWL 的学习曲线太陡，多数开发者望而却步。
LLM 改变了这一切。它们能原生读取 JSON-LD，从训练数据中理解 Schema.org 类型，无需定制查询语言或形式推理引擎就能处理结构化数据。
语义网的理念赢了，语法输了——而 JSON-LD 让我们享受红利，免付税。
上下文图讨论，本质是语义网思想借 LLM 之身重生。
三条原则，通往可扩展的上下文图
“预设 vs 学习”的二分法太干净，也太误导。实体不需要被学习——它们需要被采用。Schema.org、CDM、WAND——工作早已完成。
真正需要构建的，是时间与决策层：随时间变化的事实、作为数据的推理、维持一致性的解析机制。
这才是真正新颖之处，也是机会所在。
我总结三条原则：
1. 采用基础，勿重复造轮。实体建模问题已足够解决。别把创新预算浪费在重新发现轮子上。
2. 构建时间层。带有效期的事实、可查询的历史、时间作为一等维度。
3. 聚焦真正新颖的学习。组织模式、决策动态、特定于本组织的隐性知识。轨迹在此有用——但必须建在地基之上，而非取代地基。
上下文图愿景可实现。问题只在于：我们是站在前人肩膀上，还是浪费数年重新发现已被验证的答案？
我们知道自己的选择。
这已是我就上下文图讨论撰写的第三篇文章。前两篇分别是《AI 代理真正需要的上下文层》和《构建事件时钟》。
了解更多：graphlit.com
附录：AI 原生 CRM 与学习型本体的现实检验
“AI 原生 CRM”浪潮是检验学习型本体理念的绝佳试验场。这些初创试图通过使用模式推断结构，跳过传统 CRM 配置。但细看之下，它们其实分两类：
第一类：Schema 演化型。以 Lightfield（Tome 创始团队新作）为代表，明确宣称从非结构化输入中推断并演化数据结构。他们提到“灵活、回填的 Schema”和“按组织需求对非结构化数据进行结构化”。这最接近字面意义的“学习型本体”。
第二类：AI 辅助配置型。大多数属于此类——本质是“经典 CRM 模型 + AI 降低配置摩擦”：
- Clarify 宣称“自动配置的 CRM”：你命名字段，AI 自动选类型、写说明、自动填充。
- Forge AI 说“描述你的流程，看 CRM 自动构建”。
- Day.ai 捕获通讯内容，自动结构化为 CRM 记录。
但你仍操作于可识别的对象（账户、联系人、交易、活动）中。AI 减少摩擦，但未消除底层 Schema。
这一区别对本体争论至关重要：即使最激进的“学习”方案，仍依赖稳定的基础对象。学习发生在组织层——哪些字段重要、哪些关系被用——而非实体类型层。