作者：Eyal Toledano
原文：https://x.com/EyalToledano/status/2008965413162430508
最近关于本体论的争论很多，先是预设的本体论，还是后天习得的本体论；Palantir公司聘请的昂贵顾问，还是从智能体轨迹中涌现出来的本体论？
观看这场辩论时，我不禁觉得我们忽略了一个影响深远的细微差别。
整个讨论都假定组织知识存在于某个地方，只是需要更好的组织方式。更好的模式，更好的学习算法，更好的图结构。仿佛这些知识就存放在系统中，等待着被妥善整理。
但请注意功能上线后实际发生的情况：
- 项目经理编写规格说明。
- 工程师们在 Slack 上提出疑问以寻求澄清。
- 有人意识到规范与技术限制相冲突。
- 双方会进行15分钟的通话，做出权衡取舍。
- 范围缩小，方法改变。
- 根据实际情况，最终的实现方式与最初的规范有所不同，这些新的变化在整个组织中的落实程度也各不相同。
- 该功能已上线。
现在，推理过程在哪里？
这份规范很可能已经过时了，它描述的是最初的意图，而不是最终交付的内容。Slack 讨论串已经沉寂很久了，通话没有录音，PR 描述只写着“实现了 X 功能”。提交信息都是技术性的，缺乏上下文信息。
真正塑造最终产品的决策，存在于那次电话会议的三位参与者的脑海中。迫使他们做出权衡取舍的限制因素，他们否决的替代方案，以及他们选择这种方法而非另一种方法的原因。
六个月后，他们中的一人将离开公司，而他们的思维方式也将随之消失。
这种情况每天都会在每个软件组织中发生数千次。决定产品实际构建方式的决策，是在对话中做出的，而不是在系统层面。
在不断滚动的 Slack 对话串中，在结束后消失的 Zoom 通话中，在走廊过道谈话中，这些在数字系统中根本没有存在过。
任何本体论，无论是预设的还是后天习得的，都无法组织从未被记录过的知识。
kirk Marple在回应这场辩论时，提出了一个很有价值的观点：实体建模问题已经基本解决。Schema.org定义了人员、组织和事件。微软的通用数据模型定义了帐户、联系人和商机。医疗保健行业使用 FHIR，金融行业使用 FIBO。
这些名词都是已知的。我们不需要学习“账户”是一个实体，也不需要发现“联系人”与“组织”相关。这些工作多年前就已经完成了。
那么，我们为什么还在争论本体论呢？
我认为问题在于，讨论一直停留在错误的层面。我们知道存在哪些类型的事物，但究竟发生了什么以及为什么会发生，仍然是个谜。
Palantir 的方法成本很高，但这并非因为预设本体本身难以实现。成本高昂的原因在于，前线部署的工程师必须坐在会议室里，手动重建原本从未被记录的上下文。他们要采访相关人员，阅读旧文档，从零碎的信息中拼凑出事件的真相。他们在进行考古工作。
本体论部分很简单，真正耗时的是重建工作，需要几个月的时间。
“习得本体论”的愿景存在另一个问题，它假设智能体的运动轨迹会揭示组织结构，让智能体自由运行，观察它们访问的内容，学习哪些内容是重要的。
但智能体轨迹只能揭示已存在的数据模式。如果推理过程发生在智能体无法访问的 Slack 对话中，或者没有转录的 Zoom 通话中，又或者只是某人的内心独白，那么这些推理过程就不会出现在轨迹中。你无法从从未记录过的信息中学习结构。
这里还潜藏着一个引导问题。只有当智能体能够有效运行时，才能从它们的轨迹中学习。但智能体如果没有基础上下文就无法有效运行。“运行智能体并让结构自然涌现”的前提是，你必须有可供智能体运行的上下文。图谱必须先存在才能在其上遍历。
因此，这两种方法都是在事后解决问题。一种方法依靠人工重建，另一种方法则希望通过机器学习进行推断。但它们都没有触及问题的核心：最有价值的组织知识在产生的那一刻就消逝了。Jaya Gupta 关于决策轨迹的文章提出了一个重要的观点：“将数据与行动联系起来的推理从未被记录为数据。”
我们一直在问如何组织组织知识，但或许更重要的问题是，我们如何在推理过程消失之前将其记录下来。一旦你这样看待它，就会发现关于场景图谱的辩论框架的一些有意思的地方。
它被视为一个基础设施问题。我们如何构建更好的数据库？更好的查询层？更好的时间模型？我们如何对现有工作流程进行检测以捕获正在发生的事情？这就像在汽车时代制造更快的马一样。
但仪器只能捕捉系统中流动的信息，最重要的推理过程并不在系统中流动，而是在系统之间的缝隙中发生。
项目经理的规范说明可能写在 Notion 里，工程师的问题可能在 Slack 上，权衡讨论可能是在 Zoom 上进行的，最终的决定是口头做出的，没有留下任何书面记录。实现代码在 GitHub 上，UI/UX设计在 Figma 的某个地方，最终结果显示在分析仪表盘里。
你可以构建世界上最复杂的场景基础设施，连接所有系统，监控所有工作流程。但你仍然会错过背后的推理过程，因为推理发生在你的基础设施无法触及的空间。
正是这一点让我们相信，场景捕获从根本上来说关乎工作流程，而不是基础设施。
解决这个问题并非通过在现有系统之间铺设更好的管道，而是要从根本上改变工作发生的地点。
妨思考这一，为什么使用 Cursor或 Claude的开发者，在一次性对话中能获得更完整的场景，而使用 ChatGPT 的开发者却做不到？原因并非前者的集成能力更优，而是工作本身就发生在这个工具环境内—— 代码就在这里，文件就在这里。。场景并非从外部系统拼凑而来，而是这个环境的原生能力。
同样的道理也适用于组织知识。如果在 Slack 上进行目标一致性讨论，讨论中的逻辑推理会散落在各个讨论串中，最终消失。但如果在一个旨在记录目标一致性的系统中进行讨论，这些逻辑推理就会自然而然地保留下来。
场景图谱的机遇或许并非在于构建基础设施，来观察和组织其他地方发生的事情，而在于构建真正开展重要工作的界面。在那里，意图得以明确，权衡取舍得以做出，最终达成共识。
如果你是决策发生的地方，你不需要重建决策过程，只需将其作为输出物输出即可。
这重新定义了需要建设的内容。
基础设施建设的重点在于读取路径，我们如何查询组织知识？我们如何为智能体提供所需的场景信息？这些都是实际存在的问题，但它们只是更复杂问题的下游问题。
机遇在于正确的路径，组织知识在哪里产生？如果你身处其中，那么读取路径自然迎刃而解。知识之所以存在，是因为它诞生于你的系统中，而非从其他地方拼凑而成。
软件团队中存在速度差距是有原因的。个人使用人工智能可以几个小时就完成交付，而团队仍然需要几周时间，瓶颈从实现阶段转移到了协调阶段。这指的是，确定要开发什么以及如何确保每个人都达成共识的过程，分散且缺乏记录。
组织知识正是在这种协调一致的过程中产生的。每次团队就开发目标达成一致时，他们都会生成相关的场景信息：意图、限制条件、权衡取舍以及最终决策。然而，目前这些信息却都消散在 Slack 和 Zoom 等工具以及无人更新的文档中。
现在的本体论之争实际上是在争论如何组织艺术博物馆，而真正的机遇在于亲临艺术创作的工作室。
我们需要构建的远不止是更完善的本体论（无论是预先设定的还是后天习得的），也不仅仅是更完善的时间数据库，或决策追踪基础设施（尽管这些也很重要）。
关键在于团队在哪里开展工作，这是产生场景信息的第一现场。
预设框架与习得框架之争将持续不断，因为两者都试图通过观察来解决信息获取问题，另一种选择是停止观察，开始主导。
身处决策发生的地方，场景图谱会自然填充。