垂直软件已经赢得了上下文图谱之争

上下文图谱（Context graphs）已成为企业软件领域的新战场。@JayaGup10 和 @ashugarg 认为，下一个万亿美元级别的平台机会不在于记录系统（systems of record），而在于捕捉记录系统所遗漏的决策轨迹 。这固然没错，但它忽略了一个关键点：垂直软件公司十多年来一直在构建这些上下文图谱。

 

什么是上下文图谱？为什么它对智能体（Agent）至关重要？

一个上下文图谱是一个可查询的业务逻辑记录：它包含了推理过程、先例和决策轨迹，用以解释为什么会发生某些事，而不仅仅是发生了什么 。理论上，每家公司都拥有一个。它是关于业务运作方式的累积知识：被批准的例外情况、主导决策的先例，以及存在于人们脑海中的隐性知识。

智能体需要这些信息才能从自动化走向自主化。智能体可以运行工作流，但如果没有权限访问过去决策背后的推理过程，它就无法处理异常情况或应用先例。上下文图谱是将一个只会遵循规则的智能体与一个能够进行判断的智能体区分开来的关键。

在大多数公司和产品中，上下文图谱在理论上存在，但在实践中却并非如此。 它之所以零散、隐晦且难以获取，是因为：

• 没有人记录决策背后的逻辑。 副总裁在 Zoom 通话中批准了这项异常，但从未记录原因。
• 系统捕捉的是结果，而非上下文。CRM 显示的是最终折扣，而不是背后的服务中断或流失威胁。
• 现有的上下文处于孤岛状态。 它散落在各个工具中，而这些工具并没有统一的世界观。

这些不是产品缺陷，而是通用型 SaaS 的结构性特征。 通用平台使用灵活的抽象概念来模拟任何业务，这意味着它们无法精准地模拟任何特定业务。 人类必须填补“系统捕捉到的信息”与“决策如何制定”之间的鸿沟。但人类不会留下审计追踪。

那个价值万亿美元的问题是：谁来解决这个问题？目前主流的观点是，Agent 初创公司具有结构性优势。它们在决策时刻处于执行路径中，因此可以捕捉到记录系统从未见过的上下文。这种假设认为上下文图谱需要从头开始构建。但这并不完全正确。

 

垂直软件几十年来一直在悄无声息地构建上下文图谱

这场辩论存在一个盲点：它完全聚焦于通用型企业软件。

想想一家典型公司的业务流程和软件栈。它是由各种通用型工具拼凑而成的，每种工具都为广泛的场景而设计，且没有一个是真正为了协同工作而打造的。当然，它们拥有 API 和集成功能，但即使是最好的集成，在数据和操作流转过程中也会丢失大量的上下文。由于这些工具没有共同的世界观，上下文图谱变得支离破碎。

但垂直领域软件则不同。这种差异始于我之前写过的内容：数据模型。

像 Salesforce 这样的通用平台使用通用的抽象概念（如“账户”、“联系人”、“机会”），几乎可以为任何业务建模。这种灵活性有助于拓展广度，但却损害了深度。其本体论无法映射到任何特定行业的运作方式。它是一块空白的画布，必须由客户自行配置出意义。

垂直领域软件则从相反的假设出发。其数据模型并非灵活多变，而是具有鲜明的观点、专为特定目的构建，并与该行业的现实情况相映射。

看看 Toast 的数据模型。你会看到诸如订单、菜单项、顾客、出餐台等对象。这些并不是用自定义字段包装出来的通用交易记录。它们是具有内置关系的顶级实体：订单作为原生概念，连接着顾客、菜单项、地点和支付。其本体即是该领域本身。

相比之下，看看 Salesforce 的数据模型：账户、机会、导语、联系方式等。这些是强大的抽象，但它们描述律师事务所、餐厅或火箭制造商的效果都一样。也就是说，它们对哪一个领域的描述都不够精准。配置、集成和人类记忆必须填补其中的鸿沟。

 

具有主见的模型引导了上下文图谱的构建

在垂直软件中：

推理过程被记录下来 ，因为系统是围绕实际业务决策构建的。当建筑平台跟踪变更单时，它会以结构化数据的形式捕捉变更发生的原因 （天气延误、分包商违约、范围变更），而不是记录在通用的“活动”字段中。

上下文不再孤立 ，因为垂直平台将各项功能整合到了一个系统中。建筑平台不仅仅是项目管理，它还涵盖了调度、采购、计费和现场作业。一个系统，一个数据模型，一个真实视角的呈现。

完整的决策轨迹是可追溯的 ，因为本体架构支持这一点。当从估算到发票的所有环节都存在于一个围绕菜单项、工地或患者治疗而构建的系统中时，你就可以追踪价格是如何变化的、时间线为何推迟，或者是什么促成了折扣。

 

推断密度：捕捉“为什么”的另一种方式

关于上下文图谱（context graphs）的运作方式，有一个更深层的观点。最初的上下文图谱论点假设决策轨迹需要显式捕获：即代理在决策瞬间记录下“我因为 Y 而做了 X”。但“为什么”变得可获取还有另一种方式：通过推断密度（inferential density）。当图谱足够丰富时，推理过程可以从节点之间的关系中重构出来。

以 Toast 中的一笔订单为例。孤立来看，它只是一次带有属性的交易。将其与库存关联，你就能知道哪些商品卖得比预期快，以及哪些需要补货。将其与顾客数据关联，你就能知道谁是你最有价值的顾客，他们点了什么，以及何时下单。将其与支付关联，你就能按支付方式了解收入情况，并掌握哪些订单尚未结清。

现在，当你看到退款量激增时，不需要有人专门记录出了什么问题。你可以看到这种激增与某个特定的菜单项相关，库存系统显示该配料因缺货而被替换，且受影响的顾客多为你最高价值的群体。推论就蕴含在这些关联关系之中。

每一项新功能的加入，都为图中已有的内容增添了推理能力。库存数据让订单更具意义；顾客数据让库存决策更具意义；支付数据则让顾客关系更具意义。上下文图谱不仅在变得更宽，而且变得更稠密 。这种稠密性使得无需显式记录，也能重构出行为背后的“原因”。

这就是垂直平台在智能体时代所拥有的结构性优势。

 

垂直软件如何从边缘扩展上下文图谱

垂直软件公司构建这些上下文图谱并非偶然。 由于无法向广度扩张，他们被迫向深度挖掘 。 一家建筑平台或牙科诊所系统面临着天花板：建筑公司的数量有限，牙科诊所的数量也有限。如果你无法通过跨行业增加顾客来实现增长，你就必须通过从行业内的每个顾客身上获取更多价值来实现增长。

嵌入式支付就是最好的证明。 当垂直平台嵌入支付功能（例如通过 Rainforest）时，它不仅仅是增加了一个变现层。它正在将上下文图谱扩展到新的类别。平台不仅知道发生了什么交易，还掌握了完整的经济现状：支付速率、现金流量模式、违约率。每一笔交易都在增加积累的知识储备。

同样的逻辑现在正驱动着下一波浪潮。垂直平台已经花了十年时间来整合运营核心。但边缘活动（客户获取、采购、劳动力管理）仍然发生在平台之外。营销在 Mailchimp 中进行，采购在电子邮件往来中完成，会计则使用 QuickBooks。每一个环节都代表了图谱中的一个缺口。

 

为什么垂直平台现在能够吸收更多的边缘功能

基础已经存在。 垂直平台拥有特定领域的本体论、核心业务模块以及深厚的客户关系。它们理解什么是施工现场，什么是患者的治疗方案，以及菜单上的商品成本是多少。这正是边缘函数需要接入的精确业务逻辑。

金融层已就位。 嵌入式支付让垂直平台能够洞察客户业务中的资金流向。这种财务背景对于处于运营与资金交汇点的采购和会计业务至关重要。

AI 改变了经济模式。 营销、采购和簿记都需要劳动力。这些工作属于判断密集型，且高度依赖背景信息。AI 现在可以处理以前需要人工完成的工作流。而拥有深厚背景图谱的垂直平台，正是承载这些能力的理想底层架构。

我们正在追踪的几个类别如下：

• 营销将获客环节拉入图谱中。Reach 通过垂直平台本身路由客户沟通和其他营销数据，将获客成本与其产生的客户直接关联。
• 会计将财务分类拉入图谱中。通过 Layer 或 Tight，交易在平台内部进行分类，而不是导出到 QuickBooks，从而闭合了业务运营与账目之间的环路。
• 采购将购买行为拉入图谱中。像 Sticker 和 Faliam 这样的公司将供应商关系从电子邮件往来中提取出来，并纳入记录系统，使支出与业务运营同步透明化。

每一项都遵循相同的模式：吸收相邻的功能，将上下文与财务数据融合，部署人工智能，并深化关系图谱。

 

那又怎样？

通用型 SaaS 将失去阵地。 这些公司拥有品牌权益、数据引力和深度的流程集成。但它们将失去市场份额，一部分流向那些善于构建上下文图谱的智能体优先（agent-first）初创公司，另一部分则流向那些正在蚕食客户的垂直领域老牌企业，因为客户已经厌倦了缝合各种通用型解决方案。

智能体优先的初创公司面临冷启动问题。 上下文图谱理论认为智能体可以捕获决策轨迹，这固然没错。但垂直软件已经掌握了数百万家企业的业务流程。一家为餐厅开发的智能体初创公司，要面对的是 Toast 的分销渠道、数据以及长达十年的上下文积累。这是一个难以逾越的差距。

垂直软件老牌企业的价值被低估了。 市场根据营收和增长为垂直软件定价，却并未将上下文图谱计入价格。随着通用型 SaaS 陷入困境，以及智能体初创公司面临分销挑战，拥有密集上下文图谱的垂直平台拥有市场低估的结构性优势。

嵌入式服务提供商是一个值得关注的新兴类别。 并非每个垂直平台都会内部构建图谱扩展。嵌入式解决方案将更具吸引力。内部营销、采购和会计。它们的增长与垂直软件的扩张相辅相成。随着垂直平台吸收更多功能，赋能这些功能的底层基础设施提供商将变得更有价值。

万亿美元级别的上下文图谱机遇是真实存在的。但抓住这一机遇的不会是那个开发出最强智能体的人，而是已经拥有最深厚图谱并懂得如何扩展它的人。