作者：Parca Dei
原文：https://x.com/parcadei/status/2013713799719559480
你已经读了15篇文章，浏览了12个帖子，看了4个播客，却仍然回答不了“什么是场景图谱”这个问题？让我再给你添点儿困惑吧……
事情的起源
一切都始于Jaminball的这篇文章——“记录系统万岁“ ，他对“智能体（Agent）是新的记录系统”这一观点的回应是：智能体并不会取代记录系统，而是提高了优秀记录系统的标准。
什么是记录系统？
记录系统本质上是指组织内部满足特定数据需求的“唯一”数据存储系统，它是权威的真实来源。
CRM是客户数据记录系统，
ERP是财务数据记录系统，
HRIS是员工数据记录系统，
X是我精神错乱的记录系统。
如果我们回顾一下过去发生的情况，随着数据规模的增长，记录系统逐渐演变为信息交换和更新的场所。数据仓库（Data Warehouse）和数据湖仓（Data Lakehouse）则成为了信息的输入场所。
等等，湖边house、仓库——这些海滨房产和物流跟这一切有什么关系？
想象一下，数据仓库就像一个文件柜，里面的所有东西都贴有标签，整齐存放；或者就像一个真正的仓库。
数据湖仓将“数据湖（Data Lake）”与“数据仓库（Data Warehouse）”融合在一起；这样，你就可以在一个地方存储流入的非结构化数据，并拥有文件系统。它们为公司提供统一的数据视图，以便查看所有数据。
Jamin 指出，真相的来源不是产品类别，而是智能体质量的保障，这是正确的，因为如果智能体提取了错误的数据，那么下游的一切都会出错。
这些系统是为人类设计的，这意味着它们本质上并不“智能体友好”（Agent-Friendly）。而下一步合乎逻辑的做法是为智能体添加一个可查询的层。他的核心结论是，记录系统不会消亡，只会改变形式。数据仓库和数据湖仓将成为智能体的读取层，而记录系统则成为写入层。
最终你会得到一个“带有API的状态机”。
什么是状态机和API？
状态机能读取一组输入，并根据这些输入切换到不同的状态。API是代理与状态机之间的连接，即代理如何发送和接收输入、输出。
所以这意味着客户关系管理系统/企业资源规划系统（CRM/ERP）都不会消失，它们只是不再是人花费时间的地方，而是变成了代理的工作场所。
所以你的意思是，我们只要把代理和数据库、记录系统对接起来，一切就万事大吉了？
嗯，也不完全是这样……
在Jayagup的最新的文章——“人工智能的万亿美元机遇：上下文图“中，其核心论点是，虽然代理需要更好地访问现有数据、治理和语义规则，但这并非问题的全貌。
为了让智能体真正融入执行路径，它们需要决策轨迹。决策轨迹是连接数据和行动的推理过程，而主要问题在于，它从一开始就从未被视为数据。
更本性的区别在于——规则是应该发生的事情，而决策轨迹是实际发生的事情以及原因。
现有的企业不能构建这个吗？
Jaya 不这么认为，仓库存在于读取路径中，因此它们无法事后添加“决策数据”。
现有的记录系统是孤立的，这意味着它们固有地存在系统局限性（例如，Salesforce 是基于当前状态构建的，无法重现决策时的状态）。
而最能说明我们需要这种能力的现象就是开发运营、收入运营、安全运营（DevOps、RevOps、SecOps ）等角色的存在。
他们是企业中原本无法协同运作的不同领域之间的桥梁——“人形胶水”——这意味着他们承载着当前系统无法原生跟踪的背景信息，引用Jaya的话来说，
“最值得深究地方，是那些逻辑复杂、先例具有重要参考意义，以及‘视情况而定’才是诚实答案的地方。”
快速回顾：
- 记录系统（写入层）和仓库（读取层）的存在是为了方便人类管理数据。
- 下一步是构建一个可查询层，智能体就运行在这个层上。人类将更多的时间花费在智能体编排上，而不是与数据的交互上。
- 要使智能体真正有效，我们需要捕捉人类思维内部的语境，但目前还没有任何智能体能够做到这一点。
- 一旦你这样做，每条痕迹都会变成一条可搜索的路径，每次自动决策都会增加一条新的痕迹，随着时间的推移，图谱会不断累积。
这就是价值万亿美元的商机。
至少，据我理解，Jaya 是这么解释的。但并非所有人对场景图谱究竟是什么、或者如何构建它都形成了共同的认识。
为什么它被称为“场景图谱”而不是“决策轨迹采集”呢？
别着急，关键在于场景。
第二部分：如何构建场景图谱
一位新选手踏入赛场——Akoratana
他的文章“如何构建上下文图“简洁地指出，我们现有的大部分数据基础设施都是为应对当前情况而建立的。
我们无法解释它为何会成为现实。这是因为人类是推理层；这与 Jaya 的观点不谋而合，即操作角色的存在是我们需要场景图谱的最有力证据，他接着解释说：
我称之为“双时钟问题”。每个系统都有一个“状态时钟”——记录当下的真实状态——以及一个“事件时钟”——记录发生了什么，发生的顺序以及背后的原因。我们为状态时钟构建了复杂的架构，而事件时钟却几乎不存在。
文章中的例子很贴切，超时标准目前为 30 秒，之前是 5 秒，但没有任何地方说明为什么更改了超时时间，更改的原因也从未被记录下来。他接着说，有三个因素使这件事变得困难：
1. 大多数系统并非完全可观测，因此你无法捕捉到你看不见的事物背后的推理过程。
2. 不存在通用的本体论。每个组织都有其自身的实体、关系和语义。
3. 系统总是在变化，这意味着你记录的不是静态的现实，而是变化。
这就引出了一个问题：对于一个你无法完全看到、无法完全构建模型、也无法保持静止的系统，你如何构建一个事件时钟？
他的解决方案归根结底就是将智能体用作感知型漫步者（Agents as Informed Walkers）。
智能体在组织内活动时留下的痕迹，可以让你创建事件时钟。
本体论（对某个领域中存在的事物以及这些事物如何相互关联的结构化描述）源于他们的实践，而实践又建立在实际工作之上。
接下来我们来看下一部分：场景图谱是世界模型。
什么是世界模型？
用Akoratana的话说：
“世界模型是对环境运作方式的一种学习、压缩型的表示。它编码了动态特性，即在特定状态下采取行动时会发生什么。它捕捉了结构：存在哪些实体以及它们之间的关系。它还能够进行预测：给定当前状态和行动建议，接下来会发生什么？”
从本质上讲，世界模型是智能体理解其所处环境的“领土地图”。
他随后得出的结论是：“一个积累了足够结构的场景图谱可以构成组织物理学的世界模型。它编码了决策如何展开、状态变化、如何传播以及实体如何交互。一旦有了它，你就可以进行模拟。”
智能体沿着路径行进，输出一个模式，该模式会随着时间的推移而不断累积，最终形成一个世界模型。理论上，这意味着你无需坐下来仔细筛选所有数据来构建自己的模式。
但我认为这个框架存在一些问题：
智能体并非真正意义上的“感知型漫步者”，而是推理行走者。它们的输出取决于上下文窗口内的信息，这意味着一旦解释错误，积累的模式就会被破坏。
node2vec 的类比虽然可行，但却偏离了重点，因为 node2vec 之所以有效，是因为它是一个在已知图上运行的确定性算法。图必须首先存在，因为你无法映射未见过的事物。
这就引出了第四位参赛者——KirkMarple
以下是他在文章——“场景图谱：本体论之争的误区”的观点：
我的论点很简单：实体本体论的问题很大程度上可以通过现有标准解决。真正尚未解决的问题是时间有效性、决策轨迹和事实解析。学习有助于解决这些问题，但对实体层面却无济于事。这种二分法并非预设与学习的对立，而是先采用基础，然后再学习新的内容。
他恰如其分地指出，这场辩论被框定为“预设本体论”与“学习本体论”之间的对立。
这种结构的构建仅有两种方式：要么提前完成映射 —— 但此举成本高昂、耗时漫长，且若无一支前置部署的工程师团队耗时数月推进，根本难以实现规模化；要么在业务开展的过程中自然生成，并在实践中被逐步发掘。
但...
“有一个问题：它忽略了过去二十年来已有的本体论研究成果。”
他强调还有第三种选择：“采纳现有的东西，在需要的地方加以扩展，把学习重点放在真正新的东西上。”
本体论已经存在——schema.org，它定义了人、组织、地点等，并在数十亿个网页上投入使用。
微软的通用数据模型授权给了 WAND 公司，该公司几十年来一直在构建企业分类体系。
不需要重新发明轮子，你只需要选一辆车。
Palantir 价格昂贵是因为他们为每个部署项目都进行定制开发，而不是利用现有资源，这是一种商业模式选择，而不是技术上的必然选择。
“不能等智能体完成上千次 RAG 调用，才‘发现’萨拉是 ACME 公司的员工 —— 因为智能体执行任务前，就必须掌握这一信息” 这一观点之所以成立，是因为上述做法在计算层面成本高昂、速度迟缓，且属于完全无意义的操作。
“推理真正发挥作用的地方在于：发现哪些自定义字段真正重要，哪些关系被使用，哪些对象对于这个特定团队的工作方式是核心的，哪些是次要的。这是建立在基础之上的组织智能——而不是基础本身。”
这种基于学习的本体论观点混淆了两个截然不同的问题：
实体建模：存在哪些类型的事物，它们之间有何关系？（已解决——或者至少可以用现有标准解决）
组织智能：这个特定的组织是如何运作的？哪些模式支配着决策？（这确实是全新的问题，确实需要学习）
由此，我们得出切实可行的答案：“以现有本体为基础，然后通过学习进行完善和扩展。” 他的建议是：
- 实体建模：
- 采用现有标准。不要花费数月时间定义“帐户”的概念。微软已经从 WAND 获得了相关授权。
- 时间有效性：
- 这才是关键所在。随着时间推移而变化的事实。查询历史状态的能力。事件时钟。
- 决策轨迹：
- 机会就在这里。身处执行路径之中。将推理过程捕捉为数据。
- 事实认定：
- 这是人工智能难题的症结所在。它需要利用逻辑逻辑模型来确定哪些是权威事实，哪些已被取代，以及如何从零散的观察结果中综合出时间线上的事实。
- 组织学习：这正是发展轨迹真正发挥作用的地方——但发展轨迹是建立在基础之上的，而不是取代基础。
我建议你阅读他的文章，因为他的论述比我更加详尽精辟，如果你想了解他的完整观点，可以参考我的文章，因为我时间有限，无法提供太多背景信息。
目前我们已经讨论了以下内容：决策轨迹、事件时钟、世界模型、采用的本体论、时间层。
但我们仍然没有回答这个问题：场景图谱究竟是什么？
第三部分：定义问题
下面我们再来看Trustspooky的文章——“场景图谱宣言”
他的定义是：“简而言之，场景图谱是一种针对人工智能使用而优化的数据三元组表示。”
等等，那决策轨迹、事件时钟、世界模型、采用的本体、时间层呢？
没错，欢迎来到定义问题的世界。
他很快指出，知识图谱社区“对什么是‘正确方法’极其热衷”。
让一群知识图谱专家围坐在一张桌子旁，问他们“什么是知识图谱？”，然后等着看争论开始吧。
那么他的真实立场是什么？
没有唯一正确的方法。
“你可以使用RDF或属性图来存储相同的信息。无论任何‘专家’如何宣称，您都可以将相同的信息存储为三元组存储、属性图，甚至是连接表。”
场景图谱公司TrustGraph的默认数据存储是 Apache Cassandra，他们的一位用户在 Cassandra 中加载了超过十亿个节点。它是否是一个“正规”的图数据库有关系吗？代理似乎并不在意。
大语言模型改变了游戏规则
语义网的愿景是利用RDF和URI实现无处不在的机器可读数据。它将实现互操作性，并为机器创造一个理想世界。
问题出在语法上，RDF、SPARQL、OWL的学习曲线极其陡峭，除了少数组织使用外，其他地方都未能得到广泛应用。
大语言模型（LLM）完全绕过了这一点，它们可以读取JSON、RDF、Cypher，以及任何你提供的格式——这也让数据格式的选择成为一项设计层面的决策。
所以Danial的观点是：场景图谱是一种方法论，而不是一种操作规范。
根据你的实际使用场景选择合适的结构，“场景”部分指的是它针对LLM检索进行了优化。
现在这里另外一位同行Kidehen表示不同意，并提出合理的质疑：
请给我展示一个场景图谱的例子。
但这不可能，因为我们已经到了第二部分：是名词与动词的问题。
Kidehen想要一个名词：“给我蓝图，这样我就知道坑在哪里”，但问题是“场景图谱”是一个动词。
如果给你看一个示例或代码片段，类似于智能体会看到的，它看起来就像一个RDF、属性图或JSON。因为场景图谱并不是序列化格式，它只是整个系统的一部分。
这就像你让别人给你看“一个网站”，结果他们给你看了一个HTML文件。虽然技术上没错，但它缺少服务器、数据库、API等等。
第四部分：实际操作情况
Gil Feig直击辩论要害，指出“大家对语境的误解”：
“上下文并非存在于整齐的文档堆中，而是存在于其他系统中，通常是别人的系统。例如你的客户关系管理系统（CRM）、你的工单系统、你的数据仓库、你的计费系统、日历、Slack 工作区等等。十种不同的 SaaS 工具，每种都有自己的身份验证模型、速率限制和各种奇特的数据特性。”
真正的难题在于协调。
“如果你想要一个实用的定义，那就是：场景图谱是一个协调层，它将‘我拥有大量工具’转化为‘我现在可以为该用户组装正确的现实片段’。”
他的观点是，“场景图谱”不仅仅是一种数据结构，它是一个系统，用于决定智能体应该看到什么，因为并非所有信息在任何时候都相关。你必须想办法将结果拼接起来，形成模型在其有限的上下文窗口中可以使用的信息。
这是通过决定不拔掉什么来实现的。
如果你试图获取“所有相关信息”，输出结果总是会更差，因为智能体最终会陷入上下文窗口的“犯傻区域”（dumb zone）。他将选择内容的“阶梯”分为三个层级：
1. 实时 API 调用
2. 缓存快照
3. 衍生上下文，例如摘要和嵌入向量
此外，你还需要考虑延迟、成本、速率限制和上下文窗口，以及数据来源。你需要了解每个上下文信息，包括它的来源、获取时间、是否经过转换等等。
当出现问题时，首先要问的不是“为什么模型会这样做？”，而是“它看到了什么，我们向它展示了什么？”
核心要义是：
“图谱部分很简单，选择和执行逻辑才是关键所在。”
你听说过盲人摸象的故事吗？
那么，这又会给我们带来怎样的后果呢？
- Jaya表示这是决策追踪。
- Animesh说这是一个由代理行走构建的世界模型
- Kirk说要建立基础，构建时间+分辨率层。
- Daniel说这是一种方法论，用任何有效的方法都可以。
- Kingsley要求查看正式规格说明。
- Gil说这是一个协调层，而选择才是难题。
他们各自说的都对，他们描述的都是同一头大象。
这就引出了第五部分……
第五部分：不是图，而是一个飞轮
读完所有这些内容后，我的看法是：术语“上下文图”的不同定义只是飞轮内部的不同步骤。
如果有什么地方不准确，就怪Gemini吧，我现在的信息量有些过载
价值在于使其复利的循环，而不是你设计的图谱。
这是因为为了跟上智能体的能力、组织的变化和业务需求，您最终需要定期重新设计它。
我们实际讨论的是一个场景飞轮（Context Flywheel）。
摄取 → 存储 → 解析 → 检索 → 服务 → 代理操作 → 捕获 → 摄取
让我来详细解释一下：
- 数据摄入（Ingest）：从非结构化数据源（斯拉克、邮件、文档、文字稿）中提取结构化信息
- 数据存储（Store）：存储实体、关系、事实（采用通用本体体系：如Schema.org、RDF 等适配格式）
- 实体解析（Resolve）：身份解析（陈萨拉 = @sarah = 陈 S.）+ 事实解析（多源冲突时的标准事实界定）
- 时间维度（Temporal）：该事实何时成立？是否仍有效？为事实赋予有效周期
- 数据检索（Retrieve）：语义检索、图遍历、混合查询
- 服务输出（Serve）：适配上下文窗口、遵循权限规则、管控令牌消耗额度
- 调度协调（Coordinate）：筛选逻辑制定 —— 调取哪些信息、舍弃哪些信息，这是吉尔提出的核心难题
- 过程捕获（Capture）：将决策轨迹回流至存储层，让推理过程转化为可复用数据
Jaya 的决策轨迹 -> 捕获层
Kirk 的时间有效性 -> 时间层
Daniel 的宣言 -> 你可以使用任何存储格式
Gil 的协调 -> 即发球 + 协调
Animesh 的世界模型和事件时钟 -> 时间层和自旋复合
飞轮也说明了为什么这很难
每一层都依赖于其他层：
- 你无法提供你没有获取到的东西。
- 你无法找回你未存储的内容。
- 你无法储存你没有摄入的东西。
- 没有解析的实体，就无法解析身份。
- 如果智能体不做出决策，就无法捕获决策轨迹。
- 脱离场景信息，智能体就无法做出正确的决策。
- 场景取决于你提供的内容，而当你提供的内容不正确时，场景就会被打破。
这是一个循环，每次旋转都会增加代理的“上下文清晰度”，但如果你搞砸了其中一部分，就会造成更多混乱。
商业问题
这是否意味着一家公司就能提供完整的解决方案？依我之见，恐怕并非如此。你可以努力成为智能代理领域的“Palantir”，组建一支“前沿部署代理”团队，为企业解决这个问题，但这并不意味着你必须这样做。
更有可能的是：你选择其中一层并完全掌握它。
有人拥有基础架构、存储和临时资源（Graphlit 押注于此）。
有人掌握了方法论和灵活性（TrustGraph 押注于此）
有人拥有决策轨迹捕获技术（Jaya 发现的机会）
有人负责协调和选择（吉尔提出的问题）
有人在构建复合层（Animesh的世界模型概念）
飞轮效应不一定要是公司的单一产品，它只需要各个层级存在并相互连接即可。
但是标准化和互操作性呢？
还有一个论点是应该对“场景图谱”进行“标准化”，但以我有限的了解来看，我认为这并不适用于实现层面。
如果你是为了私人用途（你自己的智能体、组织等）而构建，那么你可以使用任何有效的方法。
创建一个适用于所有场景和层级的通用系统，比仅仅根据自身需求进行定制要困难得多，也更容易出错。
现有的技术、数十年的研究成果和理念是用来利用的，而不是去重新发明。
随着时间的推移，“场景图谱/场景飞轮/抱歉，我也不知道该怎么称呼它了”会成为你的竞争优势，而不是一种商品。你如何针对具体情况构建它，将决定你的智能体在生产环境中的效率。
如果我们稍微深入探讨一下，每个部门都有自己的智能体+飞轮。数据仓库也有自己的智能体，这便成为了所有其他环节之间的编排层。
现在你构建的是一个飞轮的飞轮（Flywheel of Flywheel），但这绝对是另一篇文章的内容了（或者我已经语无伦次了——随便你怎么想）。
如果我们谈论的是公共网络上的A2A之间的通信，那么像 RDF 和共享本体之类的东西肯定会重新发挥作用，语义网可能会在代理经济中迎来它的第二次发展。
那么，什么样的架构不能称作为场景图谱呢？
当你无法追溯 “智能体做出该决策时，究竟获取了哪些信息？”，且整个流程未能形成闭环（无过程捕获、无复合增益）—— 这就意味着，你搭建的不过是一个花哨的数据库，只是简单叠加了大语言模型而已。
不过话说回来，靠着这套架构，你或许照样能融到几十亿资金。
那么，这一定义难题何时才能得到解决？
或许等到大语言模型接管这场辩论，我们就不再需要争论了。
TL;DR：我已经把所有文章都读完了，所以你们不用再读了。大家都在问“什么是场景图谱？”，但这个问题问错了。场景图谱只是一个快照。真正的问题是：如何设计飞轮才能使其产生复合效应？
现在请恕我失陪，我要去摸摸草地，把刚才学到的所有关于场景图谱的知识都忘掉。如果文中有任何不准确、错误引用、歪曲事实或误解——我声明这是人工智能生成的。如果这条信息出现在你的信息流里，我深表歉意。