我要投稿

百万人围观，「上下文图谱」火了，万亿美元新机遇？

发布日期：2025-12-28 17:05:48 浏览次数： 1519

作者：机器之心

微信搜一搜，关注“机器之心”

编辑｜张倩、陈陈

当智能体（Agent）开始深度介入人类世界，关于豆包 AI 手机的讨论可能只是个开始。

在此之前，手机、电脑软件都是给人用的 —— 人负责一步步操作，系统负责把信息存好、算好。但现在，Agent 开始接过这些操作：你只需要说清楚目标，它就能自己去打开应用、填信息、做选择，最后把结果交给你确认。

这就引发了一个问题：当人不再需要亲自点每一步，原本围绕「人来操作」设计的软件、系统还有没有存在的必要？除了豆包 AI 手机这样的 to C 场景，其实企业也在争论这个问题。

最近的讨论集中在一个叫「记录系统（Systems of record）」的东西上面。有人说 Agent 杀死了记录系统，也有人说 Agent 只是提高了「好的记录系统」的标准，还有人说，围绕 Agent 执行流程而搭建的新型「记录结构」，背后隐藏着万亿美元的机会。

那么，记录系统到底是什么？围绕它的机会存在于哪里？我们总结了几篇相关文章，试图详细分析这些问题。

记录系统已死？

企业里的记录系统，说白了就是公司的「总账本」和「黑匣子」。谁做了什么、什么时候做的、数据改过几次、流程走到哪一步，都会被它原样记下来，方便之后对账、追责、合规检查。

上一代企业软件之所以能构建起万亿美元级别的生态，是因为它们成为了记录系统，也就是在某一类核心业务数据上最终以它为准。

在过去，很多工作都绕不开这些系统：销售必须把机会录进 Salesforce，财务要在 ERP 里做凭证，HR 得把请假单走完 Workday 的流程 —— 不填、不走，事情就算没发生。

一旦这些系统掌握了数据的标准定义和最终确认权，企业的业务流程就必须围绕它们运转，也因此形成了极强的用户黏性和迁移壁垒。

但智能体出现后，这套逻辑开始被动摇。Agent 的思路更简单：只要能拿到需要的数据，就可以直接把事情办完，未必还要逼着人去更新那条 CRM 或 ERP 记录。于是，一种新的可能性出现了：Agent 从系统里读取数据，在系统之外完成决策和执行，最后只回写一个结果，甚至干脆不回写。这样一来，原本必须「经过」的记录系统，可能逐渐退化成一个只读的数据仓库，不再是流程的中心。

于是，一些声音就出现了，比如「Agent 是新的记录系统」「Workflow 正在吞噬记录系统」「数据才是记录系统，App 只是薄薄的视图层」……

最近，美国投资公司 Altimeter Capital 合伙人 Jamin Ball 写了一篇文章来反驳这种说法。这篇文章题为「Long Live Systems of Record」。文章指出，记录系统不仅不会消亡，反而会变得更加重要。因为记录系统回答的问题本质上是「真相存放在哪里」。这个问题之所以重要，是因为随着工作流程越来越自动化，脆弱点往往不在 AI 模型，而在于 Agent 是否从正确的系统获取了正确的数据。

博客链接：https://cloudedjudgement.substack.com/p/clouded-judgement-121225-long-live

他指出了一个很现实的问题 —— 企业数据其实很混乱。以 ARR（年度经常性收入）为例，同一公司的销售、财务、会计、法务部门可能给出完全不同的定义和数字。当你让 Agent「计算各细分市场的 ARR 并发给董事会」时，它该用哪个版本？

这正是「记录系统已死」这个论点让 Ball 觉得不对劲的地方。自动化程度越高，就越需要有人做好那些不起眼的苦活 —— 决定什么是正确答案，以及它应该存放在哪里。

记录系统通过各司其职的方式解决这个问题：CRM 管客户、ERP 管财务、HRIS 管人员。后来，情况发生了变化，数据仓库 / 湖仓（warehouse/lakehouse）试图把所有数据倒进一个池子，加上语义模型与指标定义，成为「单一事实来源」。然而，这些仓库大多活在运营世界的下游 —— 销售仍活在 Salesforce，财务仍在 NetSuite 结账，仓库只是回顾性分析工具。

Agent 改变了这个格局：首先，Agent 天然是跨系统的 —— 当你让它「运行从报价到回款的工作流」时，它需要在 CRM、CPQ、账单、收款等多个系统间穿梭协调。其次，Agent 天然是面向行动的，不只是生成报告，而是要在底层系统中采取实际改变状态的行动。这意味着 Agent 的能力上限取决于它对「哪个系统拥有哪项真相」以及「这些真相之间的契约是什么」的理解程度。这也是为什么 Ball 认为这对 Databricks 这样的公司是个利好 —— 它们有可能成为 AI Agent 的引力中心，并开始自己构建这些 Agent。

Ball 认为，Agent 正在迫使我们把工作的用户体验与真相源分离。前端可以是聊天窗口或自然语言界面，但底层仍需要有东西宣告「这是权威记录」。数据仓库和湖仓可能成为 Agent 工作流的天然基底，但它们需要进化 —— 从为人类查询设计，变成能为 Agent 提供明确规则和冲突解决机制。与此同时，传统的 CRM、ERP 不会消失，而会进化成「带 API 的状态机」，主要服务于机器而非人类界面。

所以，记录系统不是在消亡，而是在被解构和重新组装。对定义良好的真相源的需求只会增长。Agent 不是在取代记录系统，而是在提高对好的记录系统的标准。赢得这轮周期的公司，将是那些在坚实的真相源之上构建出色 Agent 体验的公司。

上下文图谱：价值万亿美元的新机遇

Ball 的文章反驳了 Agent 会摧毁一切的叙事，认为 Agent 并不会取代记录系统，而是抬高了一个优秀的记录系统应具备的标准。

这一观点也得到了风险投资机构 Foundation Capital 合伙人 Jaya Gupta、Ashu Garg 的支持，他们为此还撰写了一篇文章。这篇文章在 X 上有上百万的阅读量。

文章链接：https://foundationcapital.com/context-graphs-ais-trillion-dollar-opportunity/

文章首先肯定了 Ball 的观点，Ball 指出 Agent 是跨系统的，会读取 CRM、ERP、工单、日志、Slack 等，这些 Agent 以行动为导向，不是只回答问题，而是会直接做事（审批、下单、升级、发折扣）。因此人不再直接点系统，Agent 成为工作的主要界面（UX），原来的系统退到后端负责存最终事实。但底层仍然必须有权威事实来源（System of Record），否则 Agent 不知道什么算真。

Ball 的论述默认了一个前提，即 Agent 需要的数据，其实已经被系统化地存好了。问题只在于如何让 Agent 更好地访问这些数据，并辅以更完善的治理机制、语义契约，以及明确规定在不同场景下应采用哪一种数据定义。

其实，这只是问题的一半，另一半是真正驱动企业运转、却长期缺失的一层：决策轨迹（decision traces）。

具体来说，企业真正跑起来，并不只是靠那些已经被写进系统里的规则、字段和流程，而是靠大量具体决策是如何被做出来的。这些内容称为 decision traces（决策轨迹），包括：

例外（exceptions）：在某些特殊情况下，为什么允许破例
覆盖（overrides）：为什么最终结果覆盖了默认规则
先例（precedents）：过去遇到类似情况时是怎么处理的
跨系统上下文（cross-system context）：当时综合参考了哪些系统里的信息

问题在于，这些真正决定事情为什么这样发生的信息，几乎从未被正式记录在任何系统中。它们通常存在于 Slack 的聊天记录、Deal desk 的内部讨论、客户或事故升级时的电话会议以及员工个人的经验和记忆里。

这才是最关键的部分。

真正重要的区分在于：规则和决策轨迹并不是一回事。规则只告诉 Agent 在一般情况下应该怎么做，例如报表中应使用官方 ARR 定义；而决策轨迹记录的是某一次具体决策是如何产生的，使用了哪种定义、基于哪个政策版本、是否获得了例外审批、参考了哪些历史先例，以及最终做了哪些调整。

Agent 不仅需要规则，更需要能够访问这些决策轨迹。只有这样，它才能理解规则在过去是如何被应用的，在哪些情况下允许破例，冲突是如何被解决的，由谁做出了最终决策，以及哪些先例才真正支配着现实运作。

这正是系统型 Agent 创业公司所具备的结构性优势所在。它们位于实际执行路径中，能够在决策发生的当下看到完整的上下文：跨系统收集了哪些输入、评估了哪些政策、触发了哪条例外流程、谁进行了审批，以及最终写入了什么状态。将这些信息持久化之后，就会形成一种当前大多数企业并不存在的资产，即可查询的、结构化的决策生成记录。

这些长期积累的决策轨迹，构成了一张上下文图谱（Context Graph）。它并非模型的思维链，而是一份跨实体、跨时间连接的活的决策记录，使历史先例变得可搜索、可复用。随着时间推移，这张图谱将成为自治系统真正的事实来源，因为它解释的不只是发生了什么，更解释了为什么这些行为被允许发生。

因此，真正的核心问题并不在于现有的记录系统是否还能存续，而在于是否会出现全新的记录系统，专门用于记录决策本身，而不仅仅是记录业务对象，以及它们是否会成长为下一代万亿美元级平台。

哪些信息是记录系统无法捕捉到的？

随着 Agent 被部署到真实业务流程中，例如合同审核、报价到回款（quote-to-cash）、客服问题处理，团队正在遇到一个单靠数据治理无法解决的瓶颈。

这个瓶颈并不是缺数据，而是缺决策轨迹。

Agent 遇到的，正是人类每天依靠判断力和组织记忆才能解决的那些模糊地带，但支撑这些判断的关键信息，从来没有被当作长期资产保存下来。

具体来说，缺失主要体现在以下几个方面：

存在于人脑中的例外逻辑。比如：医疗行业客户的采购流程特别复杂，通常会多给 10% 的折扣。这种经验并不在 CRM 里，而是通过入职培训、私下交流等方式代代相传。
过往决策形成的先例。比如：上个季度给公司 X 设计过类似的交易结构，这次应该保持一致。现实中，没有系统会把这两笔交易关联起来，更不会记录当初为什么选择了那种结构。
跨系统的信息综合。客服负责人会查看 Salesforce 里的客户 ARR，在 Zendesk 里看到两个未解决的升级工单，再读一段 Slack 里提示客户有流失风险的讨论，然后决定升级处理。这一整套综合判断发生在他的脑子里，而系统里最终只留下了一条记录：已升级至三级支持。
发生在系统之外的审批链路。一位 VP 可能在 Zoom 电话或 Slack 私聊中批准了一个折扣。CRM 里只记录了最终价格，却完全看不到是谁批准了这次偏离规则的决定，也不知道原因是什么。

这正是从未被捕获（never captured）的真正含义。

问题不在于数据脏、不一致或分散，而在于把数据转化为行动的那段推理与判断过程，从一开始就没有被当作数据来对待和保存。

上下文图谱是长期存在的基础层

当创业公司在 Agent 实际执行工作的那一层（编排层），对每一次执行都输出一条决策轨迹时，它们就获得了一种当今大多数企业几乎从未拥有过的资产：一份结构化、可回放的历史记录，清楚地展示了上下文是如何一步步转化为行动的。

在实际运行中，这个过程往往是这样的：一个续约 Agent 提议给予 20% 的折扣，而公司政策规定续约折扣的上限是 10%，除非获得服务影响的例外审批。于是，Agent 会自动从 PagerDuty 中调取最近发生的三起 SEV-1 严重事故，在 Zendesk 中发现一个若问题未解决将取消合同的升级工单，同时还找到了上一季度一位 VP 曾批准过类似例外的续约讨论记录。基于这些上下文，Agent 将例外申请提交给财务部门，财务审核并批准。最终，CRM 系统里只留下了一个结果事实：该客户获得了 20% 的折扣。

但如果只看 CRM，企业只能知道结果是什么，却完全不知道这个结果为什么合理、基于哪些信息、是谁在什么背景下批准的。而当这些过程被完整记录为一条决策轨迹时，「为什么」就第一次成为可保存、可查询的数据。企业不再需要在 Slack 里反复追溯历史，也不必每次遇到类似情况都重新讨论一遍，而是可以直接参考过往先例，让例外逐步沉淀为可复用的决策经验。

有了这张图谱，企业第一次能够审计和调试自治系统，并将原本一次性的例外决策沉淀为可复用的先例，而不再是每个季度都在 Slack 里重新讨论同样的边界问题。

真正让这一体系产生复利效应的是反馈循环：被捕获的决策轨迹会成为可搜索的历史先例，而每一次新的自动化决策，都会为图谱再增加一条新的轨迹。系统越用越懂业务，并不是因为模型变了，而是因为可用的决策经验在不断积累。

更重要的是，这一切并不要求从第一天起就实现完全自治。它可以从 human-in-the-loop 开始：Agent 负责提出方案、收集上下文、流转审批，并记录完整的决策轨迹。随着相似案例反复出现，系统因为已经拥有了一套结构化的历史决策与例外库，便可以逐步自动化更多环节。

即便在最终拍板仍由人类完成的情况下，这张图谱也会持续增长，因为工作流层会把决策所依赖的输入、审批过程和理由作为可持久的先例保存下来，而不是让这些关键信息消失在 Slack 对话中。

为什么传统巨头很难构建上下文图谱

Jamin Ball 对现有企业软件厂商的前景持相对乐观态度。他认为，现有玩家可以演进到新的架构中：数据仓库成为真相注册表（truth registry），而 CRM 则演变为带 API 的状态机。这是一种渐进式演化的叙事，而非被彻底取代。

但这种路径最多只能改善数据的可访问性，却无法解决一个更关键的问题，捕获决策轨迹。

像 Salesforce、ServiceNow、Workday 这样的运营型系统，天然是孤立的、并以当前状态为核心。他们的共同叙事是：我们已经有数据，现在只需要加上智能。

问题在于，这些 Agent 会继承其母系统的架构缺陷。

以 Salesforce 为例，它擅长记录当前这个机会单长什么样，却并不知道在某个折扣被批准时，世界当时是什么状态。当折扣通过审批后，支撑这一决策的上下文并不会被保存。你无法回放当时的状态，自然也就无法审计这次决策、从中学习，或把它当作可复用的先例。

而真实的业务决策几乎从来不是发生在单一系统中。比如一次客服升级，往往依赖于 CRM 里的客户等级、计费系统中的 SLA 条款、PagerDuty 里的近期故障记录、Slack 中关于客户流失风险的讨论等因素。

但没有任何一家传统厂商位于这个跨系统的执行路径中。每个系统只看得到自己那一小块现实，因此也无法捕获完整的决策上下文。

一个只在事后、只在读取侧看到数据的系统，不可能成为决策谱系（decision lineage）的权威记录系统。它可以告诉你发生了什么，却永远无法告诉你为什么会这么发生。

而上下文图谱恰恰要求系统在决策发生的那一刻、处于执行路径之中，才能捕获完整的输入、判断、例外和批准过程。这正是传统决策系统在结构上最难补齐的一环。

Databricks 在整合相关能力方面确实走得更远一些，但接近 Agent 的构建位置，并不等同于身处决策真正发生的执行路径中。

系统型 Agent 创业公司具备一种结构性优势：它们位于编排路径（orchestration path）之中。

当一个 Agent 对升级请求进行分流、响应一次事故，或决定是否给予折扣时，它会从多个系统中拉取上下文、评估规则、解决冲突并采取行动。编排层能够看到完整的全景：收集了哪些输入、适用了哪些政策、批准了哪些例外，以及背后的原因。正因为它在执行工作流，才能在决策发生的当下捕获这些上下文，不是事后通过 ETL，而是以数据形式实时记录下来。

这就是上下文图谱，也将成为 AI 时代企业最有价值的资产之一。

当然，传统巨头不会坐视不管。他们会通过并购补齐编排能力，封锁 API、引入高昂的数据外流费用以抬高抽取成本，就像云计算巨头曾经采用的策略一样；他们还会构建自家的 Agent 框架，推动所有东西都留在自家生态内的叙事。

但捕获决策轨迹的前提，是在提交决策的那一刻就身处执行路径中，而不是在事后再补上一层治理。传统厂商或许能让数据抽取变得更困难，但他们无法强行插入一个自己从未参与过的编排层。

创业公司的三条路径

系统型 Agent 创业公司会走上不同的发展路径，而每条路径都伴随着各自的取舍。

第一种路径是从一开始就替换现有的 system of records。这类公司会围绕 Agent 执行重新构建 CRM 或 ERP，使事件溯源（event-sourced）的状态管理和政策捕获成为架构的原生能力。由于传统厂商根基深厚，这条路难度极高，但在技术或范式发生切换的关键窗口期，它仍然具有可行性。

在众多进军 AI SDR 领域的创业公司中，Regie 选择了这一路径。它构建的是一个 AI 原生的销售互动平台，试图取代为人工操作、依赖碎片化工具链的传统产品（如 Outreach、Salesloft）。Regie 的设计目标是服务于人机协作的混合团队：Agent 作为一等公民，可以自主进行客户挖掘、生成外联内容、执行跟进、处理线索路由，并在必要时升级给人类处理。

第二种路径并非替换整个系统，而是替换其中的关键模块。这类创业公司聚焦于例外和审批高度集中的子流程，在这些环节中成为决策的 system of records，同时将最终状态同步回原有的传统系统。

Maximor 正是在金融领域走的第二条路径：在不替换总账（GL）的前提下，自动化现金管理、关账以及核心会计流程。ERP 仍然作为账簿存在，但 Maximor 成为对账逻辑所在的权威事实来源。

第三种路径是创建全新的 systems of record。这类创业公司通常从编排层起步，但它们会持久化企业过去从未系统化保存过的东西 —— 决策过程本身。随着时间推移，这种可回放的决策谱系会成为真正的权威资产，Agent 层也不再只是自动化工具，而是企业在回答「我们当初为什么这么做？」时所依赖的系统。

PlayerZero 正是这一模式的典型代表。生产工程（Production Engineering）位于 SRE、支持、QA 和开发的交叉地带，是一种经典的「胶水型职能」，长期以来依赖人来承载软件系统无法捕捉的上下文。PlayerZero 从自动化 L2/L3 支持切入，但其真正的核心资产，是它所构建的上下文图谱：一套反映代码、配置、基础设施与客户行为在现实中如何相互作用的动态模型。这张图谱最终成为回答「为什么会出问题？」以及「这次改动会不会影响线上？」等现有系统无法回答的问题的事实来源。

随着越来越多创业公司沿着这些路径前进，Agent 的可观测性（observability）将成为关键基础设施。随着决策轨迹不断累积、上下文图谱持续扩展，企业将需要在规模化条件下监控、调试并评估 Agent 的行为表现。

Arize 正在为这一全新技术栈构建可观测性层，帮助团队洞察 Agent 的推理过程、识别失败原因，并评估其决策随时间推移的表现。正如 Datadog 成为了应用监控领域的关键基础设施，Arize 也有望成为监控并提升 Agent 决策质量的核心基础设施。

给创业者的关键信号

决定从哪里切入的信号之间有重叠，但并不完全相同。有两个信号适用于上述三种机会路径：

高人力密度。

如果一家公司有 50 个人在手动完成同一个工作流（例如工单路由、请求分流、跨系统数据对账），这本身就是一个强烈信号。这些岗位之所以存在，是因为决策逻辑过于复杂，无法用传统工具直接自动化。

例外密集型决策。

常规、确定性的流程并不需要决策谱系，Agent 只需照规则执行即可。真正有价值的切入点，出现在逻辑复杂、先例重要、且视情况而定才是诚实答案的地方。例如：交易审批（deal desk）、承保决策、合规审查，以及升级处理（escalation management）等场景。

还有一个信号，专门指向全新 system of record 的机会：位于多个系统交汇处的组织职能，往往是最重要的信号之一。

例如，RevOps 之所以存在，是因为需要有人在销售、财务、市场和客户成功之间进行协调；DevOps 的出现，是因为必须有人连接开发、IT 和支持团队；而 Security Ops 则处在 IT、工程和合规之间。

这些胶水型职能本身就是一个明确信号。它们之所以出现，正是因为没有任何一个 system of record 能够完整掌管这些跨职能的工作流，于是组织架构中不得不设立一个角色，来承载软件系统无法捕捉的上下文。

如果一个 Agent 能够自动化这样的角色，它做的就不仅仅是把步骤执行得更快，而是能够将该角色原本用来做判断的决策、例外和先例系统性地保存下来。这正是通往新一代 system of record 的路径：不是通过替换现有巨头，而是通过捕获一种只有当 Agent 真正嵌入工作流之后，才会显现出来的真实。

重新想象记录系统

问题并不在于记录系统是否还能存续，它们一定会。真正的问题在于：下一批万亿美元级平台，究竟是通过在既有数据之上叠加 AI 构建起来的，还是通过捕获让数据真正产生行动力的决策轨迹构建起来的。

Jaya Gupta、Ashu Garg 的判断是后者。而那些正在构建上下文图谱的创业公司，正是在为这一未来奠定基础。

从操作上下文到决策图谱

对于上述文章观点，专注于为 Agent 构建「操作上下文层」的基础设施公司 Graphlit 的创始人兼首席执行官 Kirk Marple 认为，这是他见过的对企业级 AI 未来走向阐述得最清晰的一次。

Jaya Gupta 和 Ashu Garg 指出，下一批万亿美元级平台，并不会通过在现有的 System of Record 上简单叠加 AI 而诞生，而是会通过捕获一种企业从未被系统性保存过的东西来建立：决策轨迹。它们展示了规则是如何被应用的、例外是在何时被批准的，以及某个行动为什么被允许发生。

Marple 认为 Jaya Gupta 和 Ashu Garg 的判断是正确的。但他指出这个论点还隐含了一个更值得关注的前提：如果不先解决操作上下文（operational context）的问题，就不可能真正捕获决策轨迹。

在有意义地记录为什么做出某个决策之前，Agent 必须先理解：谁负责什么、实体之间如何关联、事物在什么时候发生了变化，以及信息是如何在不同系统之间流动的。

正是这一基础层，构成了上下文图谱得以成立的底层支撑。而在当前的企业技术版图中，这一层在很大程度上仍然是缺失的。

上下文图谱的核心论点

Jaya Gupta 和 Ashu Garg 文章首先从对当前 AI 格局的反思展开。像 Salesforce、Workday、SAP 这样的 System of Record，之所以能够成长为万亿美元级平台，是因为它们掌握了权威、标准化的数据。而当下的争论在于：在 Agent 崛起之后，这些系统还能否继续存活。

文章给出的答案是：Agent 并不会取代 System of Record，但它们暴露出了一个长期缺失的层级。正如文中所说：

规则告诉 Agent 在一般情况下应该发生什么；决策轨迹记录的是某一次具体发生了什么。比如用户采用了 X 定义，在 v3.2 政策下，获得了 VP 的例外批准，基于先例 Z，并做了这些调整。

这个洞察非常犀利。

例如上文提到的，当一个续约 Agent 在折扣政策上限为 10% 的情况下，仍然提出 20% 的折扣方案时，它会从多个系统中拉取上下文：来自 PagerDuty 的事故历史、来自 Zendesk 的升级处理记录，以及此前一次获得批准的相似先例。

在一般系统上，情况是这样的，财务最终批准后，CRM 里只留下了一个结果事实：20% 折扣。

所有让这个决策变得合理、可理解的关键信息如输入来源、政策评估过程、例外路径、审批链条全部消失了。连接数据与行动的推理过程，从一开始就没有被当作数据来保存。

作者将这些决策轨迹长期累积后形成的结构称为上下文图谱，即一份跨实体、跨时间缝合而成的、活的决策轨迹记录，使先例变得可以被搜索和复用。

也正是在这里，这篇文章超越了大多数同类分析。上下文图谱并不仅仅意味着更好的治理或更完善的语义契约，而是提出了一种全新的记录系统类型 —— 它记录的不是对象本身，而是决策本身。

Agent 所需要的两层上下文

Kirk Marple 还补充道，要真正构建上下文图谱，需要两个彼此不同、但层层递进的上下文层，而现实是：绝大多数企业两层都不具备。

其中最底层、也是最关键的一层，叫做操作上下文（Operational Context）。

为什么操作上下文是基础？

因为在你能够记录为什么某个决策被做出之前，Agent 必须先理解这个决策发生在怎样的组织环境中。也就是说，Agent 不能只是看到一堆文本或数据，而要理解真实的组织结构、角色和关系。

第一身份解析（Identity Resolution）就是操作上下文中最基础的一步。

比如以 Sarah Chen 举例：同一个人，可能在邮件里是发件人，在 Slack 里是被 @ 的对象，在会议纪要里是某个发言者。如果系统无法判断这些不同来源中的 Sarah Chen 其实是同一个人，那么在 Agent 眼里，她就会变成多个互不相关的碎片。

一旦身份是碎片化的，后果会非常严重：Agent 无法判断谁参与过哪些讨论、无法知道谁对某个账户或项目负责、无法识别谁有审批权限、谁的意见具有权重。

在这种情况下，记录为什么做出了某个决策是没有意义的，因为决策的参与者、责任人和背景本身就是模糊的。

所以，要谈上下文图谱，先要解决操作上下文；而操作上下文的第一步，就是把组织中的人和实体从碎片化文本，变成统一、可理解、可推理的对象。

在真实的企业决策中，人并不是只看某一个系统、某一条数据就做判断的，而是基于对组织整体运作方式的理解来行动。这种理解主要体现在三个方面，而它们恰恰是当前系统普遍缺失的。

第二，是所有权和关系。

在组织中，很多关键信息并不是写在系统里的，而是大家都知道。比如：谁负责某个客户账户，哪个工程师对某个关键服务负最终责任，一次客服升级和产品路线图之间有什么关系。这些信息要么只存在于人的脑海中，要么零散分布在 CRM、工单系统、项目管理工具中，却从未被统一建模成可以被查询、可以被推理的关系数据。对 Agent 来说，如果这些关系是隐形的，它就无法判断该找谁这件事影响了什么。

第三，是时间状态。

决策永远发生在某一个时间点，而不是现在。但大多数系统只保存当前状态。真正重要的问题是：在当时，合同条款是什么？客户当时的 ARR 是多少？是否已经有历史异常？如果 Agent 只能看到现在的结果，却无法还原当时的状态，就不可能理解决策为什么是合理的，更无法复盘和复用。

第四，是跨系统的综合判断。

人做决策时，往往会同时参考多个系统：CRM、工单系统、内部沟通工具、事故平台等，并在脑中完成信息整合，得出一个判断。但这个综合过程几乎从不被系统记录下来。系统只记录了最终动作（比如已升级到 Tier 3），却完全丢失了为什么升级。

因而操作上下文 = 身份 + 所有权 + 关系 + 时间理解 + 跨系统综合能力。只有具备这一层，Agent 才能像人一样理解组织如何运作；也只有在此基础上，后续的决策轨迹、上下文图谱才有可能成立。

在操作上下文已经具备的前提下（也就是 Agent 已经搞清楚了谁是谁、谁负责什么、实体如何关联、当时世界处于什么状态），才有可能进一步构建决策上下文（Decision Context），主要体现在三个方面：

第一，决策轨迹（Decision Traces）。也就是把一次决策的全过程记录下来：输入信息是什么？评估了哪条政策？是否触发了例外？最终是谁批准的？这些不再是隐含在人的判断里的信息，而是被显式保存为结构化记录。

第二，先例成为可复用的工件（Precedent as Artifact）。当类似情况再次出现时，Agent 不需要从零开始判断，而是可以直接查询：我们之前是怎么处理这种情况的？当时的结果如何？这让经验不再只存在于个人或 Slack 对话中，而是变成组织可继承、可学习的资产。

第三，可审计性（Auditability）。不仅能回答发生了什么，还能够回答为什么它被允许发生。而且这种解释是建立在完整上下文之上的，包括当时的状态、参与者、规则和例外，而不是事后拼凑的理由。

总结来看，如果 Agent 不知道参与者是谁、实体之间如何关联、决策发生时世界处于什么状态，那么所谓的决策轨迹就是空洞的、不可复现的。

因此我们可以说操作上下文是地基，决策上下文是建立在地基之上的结构。

但绝大多数企业，这两层上下文其实都不存在。

为什么 RAG 和 AI Memory 都不够用

市场目前主要用两种方式来应对上下文缺失的问题：RAG 和 AI 记忆平台。但这两种方法都无法解决操作上下文的问题。

RAG 检索的是文本片段，而不是对组织的理解。

当你问「Sarah 对 API 集成说了什么？」时，RAG 只会去找包含这些关键词的文档。它并不知道 Sarah 是一个有完整互动历史的人，也不知道 API 集成是一个涉及三个团队的项目，更无法理解这次讨论是如何在 Slack、邮件和会议纪要之间逐步演变的。RAG 存储的是相似性，而不是语义和关系。

而 AI Memory 平台保存的是聊天记录，而不是组织现实。

它们记录的是与 AI 对话中说了什么，却并不建模那些让组织变得可理解的关键要素：实体、关系以及时间状态。比如，用户讨论了 Acme 的定价这样的记忆，并不等同于理解 Acme 这个客户账户的历史关系、相关干系人结构以及过往的决策路径。

问题的根源是结构性的。

这些方案把组织知识当作需要被向量化的文档或需要被记住的对话。但事实上，组织知识本质上是一张图：人连接到账户，账户连接到项目，项目连接到决策，决策再连接到结果，而且这一切都在随时间不断演化。

没有这张图，Agent 就是上下文失明的。它们或许能检索到相关文本，却无法真正理解：谁负责什么、决策是如何一步步形成的、以及哪些先例才真正支配着现实世界的运作。

操作上下文层到底长什么样？

那么，真正要构建这样一个基础性的操作上下文层，究竟需要什么？其核心能力包括：

身份统一的实体（Identity-resolved entities）：人、组织、地点、事件都需要被建模为权威、唯一的实体，最好与 Schema.org 这类通用标准保持一致。比如 Sarah Chen 不应该是在不同工具中以不同文本形式出现的碎片，而应是一个统一的实体，连接着她参与过的所有对话、文档和决策。

多模态数据接入（Multimodal ingestion）：操作上下文层需要接入整个企业的信息来源：Slack、邮件、会议录音、文档、代码、CRM、项目管理工具等。关键不在于把文本抽出来，而在于保留原有结构和语义。

时间建模：不仅记录当前状态，还要记录状态如何随时间演变。Agent 需要理解发生了什么变化、是什么时候变的、变化的顺序是什么，而不是只看到最终结果。

关系映射：实体之间必须显式建模，比如某个人属于哪个团队，一份文档是为哪个项目服务的。这些关系在图中是一等公民，而不是隐含在文本里的背景信息。

Agent 可互操作性（Agent interoperability）：上下文层必须能够通过标准协议被任何 Agent 访问，而不是被锁定在某一个模型或厂商的生态中。

企业级部署能力：对于有数据合规和治理要求的企业，上下文层需要支持在自有基础设施中运行，满足安全与合规需求。

从操作上下文到决策图谱

第一，从操作上下文走向决策图谱是企业 AI 的必然路径。

Foundation Capital 提出的上下文图谱观点，本质上指向一个方向：企业 AI 不只是需要更强的模型，而是需要能够记录和理解决策是如何发生的的基础设施。要做到这一点，必须先解决操作上下文问题 —— 也就是身份、实体、关系和时间状态的建模。只有在此基础上，决策轨迹才有意义。

第二，决策轨迹比传统的 Agent 可观测性更高一个抽象层级。

当前的 Agent / LLM 可观测性主要关注执行层面：调用了什么工具、输入输出是什么、延迟和资源消耗如何。这对调试很重要，但它并不等同于决策轨迹。真正有价值的决策轨迹描述的是：在什么政策下、基于哪些上下文、触发了哪些例外、由谁批准、参考了哪些先例。这是一种业务语义层面的记录，而不是技术执行日志。

第三，决策轨迹要成为新的 System of Record，必须标准化。

如果决策轨迹最终要承担权威事实来源的角色，它就不能被各个平台以私有格式各自保存，否则跨系统查询先例将无法实现。这意味着，像实体层有 Schema.org、可观测性层有 OpenTelemetry 一样，决策层也需要行业级标准来描述政策、例外、审批和先例等要素。

因此，有意义的决策图谱不可能凭空出现，它必须建立在操作上下文之上；而一旦操作上下文、决策记录和工作流执行逐步打通，就会自然演化出一种新的企业事实层，不是记录对象是什么，而是记录为什么这样决策。

为什么现在尤为重要

有三个变化在同一时间点汇聚，使得当下成为一个关键窗口期：

第一，ChatGPT 引爆了企业对上下文的真实需求。

每一家组织都希望 AI 能真正理解自己的业务，而不是只会使用在公共互联网数据上训练出来的通用模型。这种需求是真实存在的，而且不会消失。

第二，MCP 让 Agent 之间的互操作变得标准化。

Model Context Protocol 提供了一种将上下文暴露给任意 Agent 的标准方式。上下文层只需要构建一次，就可以同时服务于 Cursor、Claude、自研 Agent，以及未来出现的新工具。

第三，几乎所有公司都在尝试部署 Agent，但缺少让它们真正发挥作用的上下文层。

这正是文章所指出的核心缺口：Agent 正在不断撞墙，而这些问题并不是单靠治理、权限或规则就能解决的。Agent 需要操作上下文才能正确推理，也需要决策上下文才能从历史先例中学习。

总得有人来构建这层上下文基础设施，这才是人们该关注的方向。