推特热议、AI 万亿美元新赛道，「上下文图谱」到底是什么？创业机会在哪？

最近，关于「上下文图谱（Context Graph）」的讨论在 X 上持续发酵。

先是 SaaS 知名专栏作者 Jamin Ball 写了一篇文章。Ball 认为，Agent 不仅不会杀死传统的软件系统，反而会让企业内部对数据定义和解释这事，变得更重要且值钱。

Foundation Capital 合伙人 Jaya Gupta 接着这个话题进一步往下延展。她认为，Ball 只说对了一半。这个理论建立在一个大前提下：Agent 需要的数据已经存在了，只需要更好地访问和治理就行。

但实际上，企业在日常运营中，有着大量非结构化、隐性的决策信息，包括各种例外情况、临时的特批、可供参考的过往案例，以及做决策时跨系统的上下文。这类信息，叫做「决策轨迹」。这些决策轨迹积累起来，形成了上下文图谱。

上下文图谱的核心是捕捉决策过程，而不只是数据本身。下一个万亿级美元的平台，关键不在于给现有记录系统加上 AI，在于抓住「数据」和「行动」背后的「推理」过程。

PlayerZero 的创始人 Animesh Koratana，又接着写了一篇文章，来探讨上下文图谱的构建具体要怎么实践。他认为，上下文图谱本质上是组织的「世界模型」，通过积累 Agents 的执行轨迹，来学习组织的动态结构和决策规律。同时，又提出了实践过程中的三个关键点。

我们汇总了两篇文章的要点，试图讲清楚以下三点：

• SaaS 系统决策背后的「为什么」才是最值钱的；

• 要想收集到这些「为什么」，需要从根本上重新思考数据和决策的捕捉方式；

• 新的捕捉方式，将是下一个万亿美元级别的创业机会。

⬆️关注 Founder Park，最及时最干货的创业分享

超 17000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。

邀请从业者、开发人员和创业者，飞书扫码加群：

进群后，你有机会得到：

• 最新、最值得关注的 AI 新品资讯；
  

• 不定期赠送热门新品的邀请码、会员码；
  

• 最精准的AI产品曝光渠道

上一代企业软件，通过成为各个领域的「记录系统」（Systems of Record），创造了一个万亿美元规模的生态系统。Salesforce 用于管理客户，Workday 用于管理员工，SAP 用于管理企业运营。成功逻辑很简单：谁拥有最权威的数据，谁就掌握了核心工作流，谁就能锁定客户。

当下的争论点在于，AI Agents 的存在是否冲击了传统的软件系统。Jamin Ball 最近有篇文章《记录系统永存》很火。他反驳了「Agent 将颠覆一切」的观点，认为 Agent 不会取代记录系统，反而会对「好的」记录系统提出更高的要求。

我们同意这一观点。Agent 天然是跨系统、以行动为导向的。工作的用户体验（UX）正在与底层的「数据平面」逐渐分离。Agent 将成为新的交互界面，但其背后仍需一个权威的数据源作为支撑。

但 Jamin Ball 只说对了一半。他的理论有个前提是：Agent 需要的数据早就已经存在，我们只需提供更好的访问权限，并辅以更完善的治理、语义契约和明确的规则。但这忽略了真正让企业运转的决策轨迹（Decision Traces）。

决策轨迹是企业运营中关于「为什么」的记录，包含了各种例外、特批、过往案例以及跨系统的上下文。这些信息，现在正散落在 Slack 的聊天记录、销售部门的讨论、升级处理的电话会议，以及员工的脑海里。

要理解这一点，关键在于区分两个概念：

• 规则：告诉 Agent 在通常情况下应该怎么做。比如，「报告必须使用官方的年度经常性收入（ARR）数据」。

• 决策轨迹：记录了在某个具体案例中实际发生了什么。例如，「我们基于 Z 先例，根据 v3.2 版政策，通过副总裁的特批，为这个客户采用了 X 定义来计算 ARR，并对以下部分进行了调整」。

Agent 不仅需要规则，还必须能访问这些决策轨迹，才能理解规则在过去是如何被应用、例外在什么情况下被批准、冲突如何解决、决策由谁批准，以及哪些先例在现实中真正起作用。

这恰恰是「Agent 系统」初创公司的结构性优势所在。它们天然就处于工作流的「执行路径」上，能够在决策的瞬间捕获完整的上下文信息：跨系统收集了哪些输入数据、评估了哪项政策、调用了哪个例外处理流程、由谁进行了审批，以及最终写入了什么状态。

把这些轨迹存下来，你就得到了一个今天大多数公司都没有的东西：一个关于决策是如何制定的、可供查询的完整记录。

我们将这些决策轨迹积累形成的结构称为上下文图谱（context graph）。它不是大模型的「思维链」，而是一份动态更新的、跨越实体和时间的决策记录，把「先例」变成了可搜索的数据。

随着时间的推移，上下文图谱将成为实现企业自主运营的真正事实来源，因为它不仅解释了「发生了什么」，更解释了「为什么允许它发生」。

因此，真正的核心问题不是现有系统能否幸存，而是：一个记录「决策」而不是记录「对象」的全新系统，能否崛起，并成为下一个万亿美元平台？

02没能捕捉的信息具体是哪些？

当 AI Agent 进入真实的合同审查、报价收款、客户支持等工作流时，很快就撞上了一堵墙。这堵墙，不是因为缺数据，而是因为缺少决策轨迹。

Agent 遇到的问题，和人类员工每天用判断力和组织记忆解决的问题，是一样的。但人类做判断时依赖的那些关键信息，从来没被当成持久的数据资产存下来。

具体来说，以下几种关键信息是缺失的：

• 存在于经验中的例外规则。很多决策逻辑，只存在于老员工的经验里，是口口相传的「部落知识」（Tribal Knowledge）。比如，「医疗行业的客户采购流程特别麻烦，我们一般会多给 10% 的折扣。」这在 CRM 系统里是找不到的。

• 来自过往决策的参考先例。商业决策高度依赖先例。「上个季度我们为 X 公司设计过一个类似的方案，这次应该保持一致。」没有任何一个系统，能把这两个单子关联起来，更别说记录当初为什么要那么设计。

• 跨系统的综合分析。一个决策，往往是综合了多个系统信息的结果。一个支持主管决定要不要升级问题。他可能会：在 Salesforce 里看客户的 ARR；在 Zendesk 里发现两个未解决的升级请求；在 Slack 里注意到客户流失风险。整个分析过程只发生在他的脑海里，最终工单上只留下一句「已升级至三级支持」。

• 系统之外的审批流程。关键的审批，尤其是高层决策，往往发生在系统之外。一个 VP 可能在 Zoom 或 Slack 私信里批了个非常规的折扣。最终销售机会记录里只更新了价格，但谁批准的、为什么批准，这些关键上下文完全丢失了。

这就是「从未被捕捉」的真正含义。问题不在于数据是否脏乱或孤立，在于那个连接数据与行动的推理过程，从一开始就没被当作一种正式的数据来对待。

03上下文图谱：

把隐性知识变成核心数据

真正的解决方案，是打造一个能捕捉和沉淀决策轨迹的「持久层」。当一家创业公司能做到在 Agent 每次运行时，都生成一条结构化的决策轨迹，它就拥有了当今企业最稀缺的资产。

我们来拆解一个 case：一个续约 Agent 提议给 20% 的折扣。公司政策上限是 10%，除非有「服务影响」的例外获批。

于是，Agent 开始跨系统干活：

• 从 PagerDuty 调取了三个严重等级为 1 的服务事故记录

• 从 Zendesk 找到了一个「不解决就取消合同」的升级请求

• 引用了上季度 VP 批准类似例外的先例，它把这些信息打包成例外申请，路由给财务部。财务批准。

最终，录入 CRM 的只有一个简单事实：「20% 折扣」。

但背后所有的「为什么」，都被完整记录了下来。

一旦有了这样的决策记录，「为什么」就从隐性知识变成了核心数据。时间一长，这些记录自然会连成一个强大的上下文图谱（Context Graph）。

这个图谱，把公司关心的所有东西（客户、合同、工单、审批人）都通过「决策事件」和「为什么」的链接关联了起来。

公司就能审计自动化系统，把例外变成先例，不用每个季度都在 Slack 里重复踩坑。

这个过程会产生强大的复利效应：被捕捉的决策轨迹成为可搜索的先例，同时每一次自动化决策又会为图谱增添新的轨迹。

这事儿不需要一步到位。它可以从「human-in-the-loop」开始：Agent 提建议、收信息、跑流程，人类来拍板，但整个过程都被忠实记录下来。即便是人来做决策，上下文图谱依然在持续增长，因为它确保了决策的输入、审批过程和背后逻辑被作为持久化的先例保留下来，而不是消失在海量的聊天信息中。

04构建上下文图谱，

要解决三个核心问题

那上下文图谱到底该怎么构建？

答案不是给 Agent 加个记忆库或者连接到某个 MCP 那么简单。「Graph」这个词本身都有点误导，因为它体现的是一种静态结构，但我们要处理的东西，动态和不确定性要高得多。

每个公司都在交一笔「碎片化税（fragmentation tax）」，信息散落在各个系统里，需要人手动拼凑上下文。上下文图谱，就是为了消除这笔「税负」而生的基础设施。

这就需要我们从根本上重新思考数据和决策的捕捉方式。上下文图谱本质上是一个组织的「世界模型」，通过积累 Agents 的执行轨迹，来学习组织的动态结构和决策规律。

必须要解决的三个核心问题：

双时钟问题

为什么这么难？有个直觉帮我理清了思路：我们现有的系统，都只围绕着时间的一个维度来构建。

• 你的 CRM，只记录成交价，不记录谈判过程。

• 你的工单系统，只记录「已解决」的状态，不记录排查思路。

• 你的代码库，只记录当前代码的状态，不记录当初的架构争论。

我们花了万亿美金，构建了现在庞大的基础设施，只为了记录「现在是什么」，但几乎没有针对「为什么会这样」做任何事。

过去，人就是推理层，这没问题。组织的智慧大脑在每个人脑子里，靠开会、聊天就能把事情拼凑起来。现在，我们想让 AI 做决策，却发现它根本没有决策依据。我们要求模型拥有判断力，却不给它看「判例」。这就像只给律师看判决结果，却不给他们看卷宗和庭审记录一样。

代码里一行配置 timeout=30s，Git 记录显示，它之前是 5s，有人把它改了。但为什么？Git 的追溯记录（blame）能显示是谁改的，但背后的思考过程却消失了。

这种情况到处都是：

• CRM 显示「交易失败」，但没告诉你，其实你是客户第二选择，第一名只比你多一个你下季度才上线的功能。

• 病历记录了「换用 B 药」，但没说 A 药其实有效，只是病人保险不报销了。

• 合同显示「60 天可解约」，但没说这是你用责任上限条款换来的，客户一开始想要 30 天。

我把它叫做「双时钟问题」。每个系统都有两个时钟：

• 状态时钟（state clock）：记录当前的事实；

• 事件时钟（event clock）：记录事情的经过、顺序以及为什么发生；

我们把状态时钟做到了极致，事件时钟却几乎不存在。

「状态」很简单，存数据库就行。但「事件」很难，因为它转瞬即逝。状态可以被覆盖，但事件必须追加记录。而事件时钟里最关键的「推理」部分，从没被当成数据对待，它们只存在在人脑里、Slack 聊天记录里和没被录音的会议里。

这件事很难，还有三个原因：

• 多数系统是「黑箱」：任何真实系统都存在黑箱，遗留代码、第三方 API、复杂系统里的突现行为，看不透，自然也抓不住背后的推理逻辑；

• 没有通用标准（Ontology）：每个组织都有自己独特的实体、关系和语义。「客户」一词在 B2B 软件公司和在消费者电商平台上的含义截然不同。你没法预设一个标准，只能让系统自己学；

• 一切都在动态变化：你建模的对象每天都在高速迭代。你记录的不是一个静态的现实，而是在追踪一个动态的过程。

这几个问题交织在一起，让重建「事件时钟」成了一个几乎不可能的任务。大多数「知识管理」项目之所以失败，是因为它们把这个问题当作静态任务来处理：导入文档，建立一个知识图谱，然后供人查询。但文档是被「冻结」的状态，而「事件时钟」真正要捕捉的，是整个动态变化的过程。

那如何为一个看不全、无法预设模式、且持续变化的系统构建事件时钟呢？

把 Agent 看作是有目标的探索者

「本体」问题（Ontology）看起来像个死结。每个公司都不一样，你怎么可能去定义一套标准的决策流程？

但有一种存在，天生就是用来在任意系统中穿梭的：AI Agent。

当一个 Agent 要解决问题时，它会自己搞清楚该关注哪些东西、它们之间有什么关联、需要什么信息、能做什么操作。

Agent 解决问题的路径，就像在系统里走了一遍，画出了一张地图。这张地图不是预设的，而是在实际使用中跑出来的。

我们平时用的嵌入（embeddings）是基于语义的，意思是「含义相近，向量就相近」。但这不够。我们需要的是能编码结构的嵌入，意思是「扮演的角色相似」或者「在决策中经常一起出现」。

换句话说，语义嵌入编码的是「意义」。但组织推理需要的，是对决策的结构和形态进行建模。

所以，信息的核心变了。不再是「意义」，而是推理的形态。它回答的是这些问题：

• 解决一个问题，通常会牵扯到哪些部门和系统？

• 什么事件总是先于另一些事件发生？

• 在整个组织的信息系统里，最常被走通的路径是哪几条？

图表示学习里有一个技术是 node2vec，它的思路很有启发：你不需要看全整张图，只要在图上随机走足够多的步数，就能学到图的结构。哪些节点总是一起出现，它们之间就有很强的关联。

这个思路把问题反过来了：你不需要先理解一个系统，才能表达它；而是先去充分地遍历它，表达自然就涌现了。模式（Schema）是结果，不是起点。

怎么走，决定了你能学到什么。在图里小范围溜达（局部走），能发现「物以类聚」（同质性 Homophily）。而满世界乱逛（全局走），则能发现「角色相似」（结构对等性 Structural Equivalence）。

举个例子： 公司里有两个资深工程师，一个做支付，一个做通知系统，平时工作毫无交集。

只看局部关系，他俩毫无关联。但从整体结构上看，他们扮演的角色、处理问题的模式是高度相似的。结构对等性就能说明这一点。

AI Agent，就是有目标的探索者（Informed Walkers），不是随机的。

它解决问题的过程，就是一次穿越组织信息空间的行走，会接触系统、读取数据、调用 API。它走的每一步，都是由当前问题驱动的。一开始可能全局摸排，找到线索后就深入局部。

如果设计得当，无数次 Agent 行走的轨迹，就构成了「事件时钟」。

每一条轨迹，都是对组织结构的一次采样。成千上万次采样之后，一个通过实际应用学习而来、能反映组织真实运作方式的表示就诞生了。

这里有个很巧妙的经济模型：公司部署 AI Agent，是为了解决能赚钱的业务问题。而上下文图谱，只是这个过程中的「副产品」。但这个「副产品」反过来又能让 Agent 变得更强，解决更复杂的问题，更多的轨迹又进一步丰富上下文，形成一个正向飞轮。但前提是：投入产出比得是正的。AI Agent 创造的价值，必须大于它消耗的算力成本。

上下文图谱是组织的「世界模型」

上下文图谱的本质是什么？一个概念很关键：世界模型（World Models）。

简单说，世界模型就是一个通过学习得到的、关于环境如何运转的压缩表示。它知道在特定状态下采取行动会引发什么后果，会推断接下来会发生什么。

AI 能在自己脑子里，建一个真实世界的「模拟环境」。这个模拟环境虽然是简化的，但抓住了世界运行的核心规律。

这在机器人领域很好理解。机器人可以在一个模拟物理定律的世界模型里训练、学习，先在虚拟世界里训练策略，再把学习到的能力用到到现实世界中。物理模型越精准，模拟训练就越有效。

组织也一样，只不过它的「物理定律」不是牛顿力学，而是「决策动力学」：

• 一个异常审批是怎么通过的？

• 一次故障是怎么逐级上报的？

• 在某个功能开关开启的情况下，修改配置会发生什么？

状态告诉你「是什么」，事件时钟告诉你「系统是如何运转的」，后者是模拟的基础。

一个足够强大的上下文图谱，就成了一个组织的「世界模型」。它搞清楚了决策是怎么走的、连锁反应是怎么发生的、不同部分是怎么互动的。掌握了这些，你就能开始模拟未来了。

在 PlayerZero，我们在做代码模拟。我们会问模型：「如果我这样改代码，线上会出什么问题？影响哪些客户？」这种模拟不是魔法，而是对成千上万次历史轨迹进行推理的结果。

模拟，是检验理解程度的试金石。如果你的上下文图谱能回答「如果... 会怎样？」，那它才算成了。否则，充其量只是一个搜索引擎。

这对当前关于持续学习（continual learning）的争论也有新的启发。很多人觉得 AI 没法在工作中持续学习，所以潜力有限。

但世界模型提供了另一种思路：基础模型可以不变，但推理依据的「世界模型」可以持续更新。

Agent 每次解决问题，都在为世界模型提供新的证据。决策时，它基于这个不断丰富的世界模型进行推理和模拟，看起来就像它「学会」了新东西一样。轨迹越多，推理就越精准。

并且，因为世界模型支持模拟，还可以实现反事实推理。不仅能问「过去类似情况是怎样的？」，还能问「如果我采取这个行动，会发生什么？」。AI Agent 可以想象多种结果，然后评估优劣，做出选择。

这正是经验丰富的员工与新员工的核心区别。他们不是大脑结构不同，而是脑子里有一个更精准的「世界模型」。他们能下意识地模拟出「周五发版，周末就要加班救火」这种后果。这不是检索记忆，这是推理。

所以，未来可能不是死磕模型的持续学习，而是给模型打造一个能持续进化的世界模型。

基础模型是引擎，而上下文图谱就是那个让引擎能够发挥作用的世界模型。

05为什么大厂做不了这个事？

Jamin Ball 很看好大厂，认为数据仓库会变成「事实注册表」，CRM 变成「带 API 的状态机」。

这个想法，对让数据更好用有点帮助，但解决不了捕捉决策轨迹的根本问题。

运营系统巨头：困在「当前状态」和「数据孤岛」里

Salesforce 推出了 Agentforce，ServiceNow 有 Now Assist，Workday 也在为 HR 部分构建 Agent。

它们的逻辑是：「我们有数据，现在我们加智能。」

但它们的 AI 继承了母体平台的两大缺陷：

「当前状态」陷阱。Salesforce 的核心是基于「当前状态」的存储。它只知道一个销售机会现在是什么样，但不知道在三个月前决策制定时是什么样的。当一笔折扣被批准后，所有支撑决策的上下文都丢失了。你没法「回放」现场，自然没法审计和学习。

视野盲区。这些系统本质上是数据孤岛。一个客户支持决策，上下文可能散落在 Zendesk、CRM、计费系统、PagerDuty 和 Slack 里。没有任何一个大厂能看到全景。

数据仓库厂商：困在「只读路径」上

Snowflake 和 Databricks 被认为是未来的「事实注册表」层。它们也在疯狂投入 AI。

Snowflake 推出了 Cortex，还收购了 Streamlit；Databricks 收购了 Neon，并发布了 Lakebase 和 AgentBricks。

它们的想法是：数据平台将取代传统的记录系统，成为 AI Agent 的基础。

但它们有个致命问题：它们在数据的「读取路径」（read path），而不是「写入路径」（write path）。

数据是在决策发生之后，才通过 ETL 进到数据仓库的。当数据到了 Snowflake，关键的决策上下文早就丢了。

一个只能事后看结果的系统，能告诉你「发生了什么」，但没法告诉你「为什么」。

Agent 初创公司：具有编排路径的结构性优势

相比之下，「Agent 系统」创业公司的核心优势在于，它们从第一天起就处在工作流的「编排路径」或「执行路径」上。

当一个 Agent 需要处理升级请求、响应服务事件或决定折扣时，它会从多个系统中拉取上下文信息，评估规则，解决冲突，然后执行操作。这个「编排层」能看到完整的决策图景：收集了哪些输入、应用了哪条政策、批准了什么例外，以及背后的原因。

因为它在执行工作流，所以能在决策发生的瞬间，把所有上下文作为核心记录（first-class record）实时抓下来。

这就是上下文图谱。它将是 AI 时代企业最宝贵的单一资产。

大厂肯定会反击。它们会尝试通过收购来补齐编排能力、会锁定 API 接口并收取高昂的数据出口费，让数据提取变得困难。还会构建自己的 Agent 框架，然后鼓吹「生态内循环」。

但这改变不了一个事实：捕捉决策轨迹，需要在决策提交时身处执行路径之中，而不是事后打补丁。大厂没法把自己硬塞进一个从未参与过的、跨系统的编排层。

06初创公司的三条路

面对这个机会，创业公司有三条路可以走：

路径一：直接取代现有的记录系统。

打造一个「AI 原生」的 CRM 或 ERP，架构原生支持事件溯源和策略捕捉。这很难，但有机会。

Regie 就是这么干的，它要做的不是另一个 Outreach/Salesloft，而是一个全新的、为「人机混合」团队设计的销售互动平台。Agent 在其中扮演核心角色：它可以开发潜在客户、生成营销内容、执行跟进、分配任务，并在必要时将复杂问题上报给人类同事。

路径二：模块化渗透

不取代整个系统，而是盯住那些例外和审批特别集中的特定工作流，成为这些决策的记录系统。 Maximor 在金融领域就是这个打法。它自动化了现金、关账等流程，但并不替换企业原有的总账（GL）系统。ERP 还是那个账本，但 Maximor 成了所有对账逻辑的权威来源。

路径三：创造全新的记录系统

从一个跨系统的编排层切入，但核心战略是把企业从未有过的「决策轨迹」储存下来。 时间一长，这份能回溯的决策记录本身，就成了最权威的资产。 PlayerZero 是个典型。它从自动化 L2/L3 生产环境支持入手，最终构建了一个关于「系统为何出故障」的上下文图谱，能回答任何现有系统都答不了的问题。

不管走哪条路，Agent 的可观察性都会成为至关重要的基础设施。Arize 就在做这件事，它想成为这个新时代的 Datadog，帮助企业监控、调试 Agent 的决策质量。

07给创始人的关键信号

创业机会的信号有重叠，但也各有侧重。

所有机会都适用的两个信号

高人力成本的流程。如果一个公司有 50 号人，天天在手动处理工单、对数据，这就是一个明确的信号。这说明决策逻辑太复杂，传统工具搞不定。

充满例外的决策场景。常规的、确定性的工作流并不需要决策脉络，Agent 只需要按部就班地执行。机会在那些逻辑复杂、先例很重要、答案总是「看情况」的地方。比如：销售方案审批、保险承保、合规审查、升级管理。

一个指向「新记录系统」机会的特殊信号

那些处在系统交叉点的部门。为什么会有营收运营（RevOps）、开发运维（DevOps）、安全运营（Security Ops）这些部门？就是因为没有任何一个单一系统能搞定跨职能的工作流。公司只好创造一个新角色，由人来传递软件抓不住的上下文。

一个能自动化这种角色的 Agent，不只是提升效率。它能把这个角色要做的决策、例外和先例，都沉淀下来。这就是通往一个全新记录系统的路：不是颠覆某个现有系统，而是通过捕捉一类全新的、只有当 Agent 深入工作流之后才可见的事实。

问题不在于旧系统会不会死——它们会的。

真正的问题是，下一个万亿美元平台，到底是靠给现有数据加上 AI 功能，还是靠捕捉那些能让数据产生行动的决策轨迹？

我们赌后者。

今天正在构建上下文图谱的创业公司，正在为这个未来打下基础。

转载原创文章请添加微信：founderparker