作者：Kirk Marple

原文：https://www.graphlit.com/blog/context-layer-ai-agents-need

场景图谱系列— 第1部分（共3部分）

这是探索新兴场景图谱基础设施层的三篇系列文章之一，首先探讨智能体为何需要运营场景才能捕获决策轨迹，然后深入研究构建时间事实存储的技术架构，最后解决困扰业界的本体论问题。这些文章共同描绘出一幅完整的图景，展现了构建企业人工智能所需的上下文层究竟需要哪些要素。

第一部分：上下文层（本文）

第二部分：事件时钟

第三部分：本体论问题

Foundation Capital 近期发表的文章《上下文图谱：人工智能的万亿美元机遇》是我见过的对企业级AI发展方向最清晰的阐述。Jaya Gupta 和 Ashu Garg 认为，下一个万亿美元平台并非通过将人工智能添加到现有记录系统中构建而成，而是通过捕捉企业从未系统性存储过的信息来构建：即决策轨迹（Decision Traces），它展现了规则如何应用、例外情况如何被允许，以及行为发生的原因。

他们的观点没错，但他们的论点中还有一点值得关注：如果不先解运营层面的场景问题，就无法捕捉决策轨迹。智能体需要了解谁拥有什么、实体之间如何关联、哪些内容发生了变化、变化的时间，以及信息如何在系统间流动——才能有效地记录决策的原因。

这一基础层是构建场景图谱的基石，而它在当前的领域中却严重缺失。

场景图谱论题

这场争论始于对当前人工智能格局的批判。像 Salesforce、Workday 和 SAP 这样的数据记录系统，凭借其掌握的权威数据，发展成为价值万亿美元的平台。如今的争论焦点在于，这些系统能否在向智能体转型后继续生存下去。

他们的答案是：智能体并不能取代记录系统，但它们确实揭示了缺失的一层，正如他们所说：

这个洞察非常敏锐。当保险公司的续保智能体提出20%的折扣，而政策规定折扣上限为10%时，它会从多个系统中提取相关信息：PagerDuty的事件历史记录、Zendesk的客服升级讨论串，以及之前的审批记录，财务部门批准了该折扣，CRM系统只记录了一条信息：“20%折扣”。

所有使该决策清晰易懂的要素——输入信息、政策评估、例外处理流程、审批链——都消失了。将数据与行动联系起来的推理过程，从一开始就从未被视为数据。

他们将这些决策轨迹所积淀形成的结构化体系称之为场景图谱，并给出定义：“这是一套跨实体、跨时间串联而成的决策轨迹动态记录体系，让过往的实践先例可被检索、可被复用。”

这篇文章的分析远不止于此。上下文图谱不仅仅是更好的治理或语义契约，它更是一种全新的记录系统——它记录的是决策，而不仅仅是对象。

智能体需要的两层场景

我想在这里补充一点，构建场景图谱需要两个截然不同的上下文层级，而大多数企业两者都不具备。

运营场景：一切的基石

在了解决策背后的原因之前，决策者需要了解决策发生的组织现实（Orgnizational Reality）：

• 身份解析。Sarah Chen是谁？她是否就是邮件往来、Slack提及和会议记录中出现的那个Sarah？如果同一个人在不同工具中以碎片化的文本形式出现，智能体就无法推断其身份、账户或系统。
• 所有权和关系。谁拥有 Acme 账户？哪位工程师负责支付服务？支持升级流程如何与产品团队的路线图衔接？这些关系存在于人们的记忆中，分散在各个系统中——但它们很少被建模为可查询的数据。
• 时间状态。做出决定时，合同是如何规定的？续约时客户的年度经常性收入（ARR）是多少？智能体需要了解事情的发展演变，而不仅仅是现状。
• 跨系统整合。客户服务主管查看CRM中的客户级别，查看Zendesk中的未解决升级问题，阅读Slack上标记客户流失风险的讨论串，然后决定升级。这种整合过程发生在他们的脑海中，没有任何系统能够记录下来。

运营场景主要包括：身份信息、所有权、关系、时间线，让智能体能够像人类一样对组织进行推理。

决策场景：下一个层面

一旦具备了运营场景，就可以构建作者所描述的决策层场景：

• 决策过程。收集了哪些输入信息？评估了哪项策略？援引了哪项例外情况？谁批准了决策？
• 先例即资产。当遇到类似情况时，智能体可以查询：“我们之前是如何处理这个问题的？结果如何？”
• 可审计性。不仅要审计发生了什么，还要审计为什么允许它发生——同时保留完整的背景信息。

这些层之间的关系至关重要，如果智能体不知道参与者是谁、实体之间有何关联，或者决策发生时世界处于何种状态，就无法捕捉到有意义的决策轨迹。运营场景是基础，决策场景则是构建在其上的内容。

目前，绝大多数企业两者都缺乏。

为什么RAG和AI记忆还不够

市场针对这些场景问题提出了两种应对方案：RAG（检索增强生成）和“AI记忆”平台，但这两种方案都无法解决实际运营中的上下文问题。

RAG 检索的是文本片段，而非理解组织结构。当你问“关于API 集成Sarah说了什么？”时，RAG 会找到包含这些关键词的文档，但它无法理解 Sarah 是一个拥有完整交互记录的人，也无法理解 API 集成是一个涉及三个团队的项目，更无法理解对话是如何在 Slack、电子邮件和会议记录中展开的，RAG 存储的是相似性，而非实际意义。

大多数AI记忆平台存储的是聊天记录，而非组织的真实面貌。它们记录了与人工智能对话的内容，但并未对构成组织结构的实体、关系和时间状态进行建模。例如，记录“用户讨论了Acme的定价”与将Acme理解为一个拥有关系历史、利益相关者关系图和决策轨迹的账户截然不同。

这种差距是结构性的，这些方法将组织知识视为需要嵌入的文件或需要记住的对话。但组织知识是一个图谱：人员与账户相连，账户与项目相连，项目与决策相连，决策与结果相连——所有这些都随着时间推移而不断演变。

如果没有这张关系图，智能体就无法理解所处的场景。它们可以检索到相关的文本，但无法理解所有权归属、决策如何演变，或者哪些先例真正适用于现实。

运营场景层是什么样的

那么，构建运营场景这个基础层究竟需要什么？将一个组织分散的、多模态的工作转化为一个身份可解析、时间可感知的知识图谱的基础设施又需要什么呢？

核心能力

• 身份解析实体。人物、组织、地点和事件被建模为规范实体——理想情况下符合Schema.org等标准。Sarah Chen 不是在不同工具中呈现不同的零散文本，她是一个已解析的实体，与她参与的每一次对话、每一份文档和每一个决策都息息相关。
• 多模态数据摄取。Slack、电子邮件、会议录音、文档、代码、CRM 数据、项目管理工具——来自企业各处的内容，连同结构一起得以保留，而不仅仅是提取文本。
• 时间建模。不仅要考虑当前状态，还要考虑实体和内容随时间演变的方式。智能体需要推断出哪些内容发生了变化，何时发生变化，以及变化的顺序。
• 关系图。实体之间相互关联，人员隶属于组织，内容与项目相关，决策涉及利益相关者。该图将这些关系作为一级数据进行捕获。
• 智能体互操作性。场景层需要能够通过标准协议被任何智能体访问，而不能被锁定在单一供应商的生态系统中。
• 企业部署选项。对于有数据治理要求的组织，场景层需要在自身的基础设施中运行，并满足必要的合规性要求。

我们在Graphlit构建什么

这是我们从 2021 年以来一直在努力解决的问题，Graphlit 为 AI 智能体提供运营场景层——该基础设施接收多模态内容并将其转换为身份解析、时间感知的知识图谱。

我们的目标是构建一个现代化的媒体和传感器数据系统，而非文档存储库。我们保留了数据的结构、来源和时间信息，而不是将所有内容扁平化为文本块进行嵌入。正是这种架构选择使得运营场景成为可能，也使我们能够随着市场的发展为决策提供上下文支持。

从运营场景到决策图谱

Foundation Capital 的投资理念指明了市场的发展方向，我们与这一方向一致， Graphlit的2026 年发展路线图将引领我们进一步向他们所描述的领域迈进。

我们今天所处的位置

Graphlit 提供运营场景层：身份解析、实体提取、关系映射、时间建模，以及跨 30 多个数据源的多模态数据摄取。连接到 Graphlit 的智能体能够理解所有权归属、事物之间的关系以及变化情况——这是任何有意义的决策的基础。

我们将去往何方

CRM 作为实体核心骨架。我们与使用 Attio 的客户合作确定了重点事项：CRM 对象（客户、联系人、交易）为组织多模态内容提供了最清晰的结构化骨架。一旦规范实体存在，其他所有内容——Slack、电子邮件、文档、代码——都能清晰地解析到图谱中。我们正在深化 CRM 集成，将其作为架构楔入企业场景的关键。

智能体记忆和决策日志记录。当智能体通过 Graphlit 执行工作流时，我们正在构建基础设施，不仅用于捕获它们访问的内容，还用于捕获它们产生的推理轨迹。收集了哪些输入？合成了哪些上下文？采取了哪些操作？

工作流监控。作者的观点是正确的，要捕获决策轨迹，就必须位于执行路径中。我们的 MCP 服务器已经位于智能体的上下文检索路径中。接下来，自然而然地会将其扩展到捕获决策输出——批准、例外情况、先例。

决策轨迹需要一个标准

这里有一个值得借鉴的类比，语言大模型（LLM） 可观测性领域——例如 LangSmith、AgentOps、Arize 和 Braintrust——已经发展成熟，主要围绕捕获执行轨迹：输入、输出、延迟、工具调用和令牌使用情况。这对于调试和优化固然重要，但这并非 Foundation Capital 文章所描述的内容。

决策轨迹运行在更高的抽象层次上，它并非描述“智能体使用这些参数调用了此工具”，而是描述“此决策是根据此策略、此例外情况、由此人批准并基于此先例做出的”，决策轨迹是在执行遥测数据之上构建的业务级语义。

如果决策轨迹成为一种新型记录系统的基础，那么其模式就不能各自为政，由不同的编排平台独占。我们需要行业标准——就像 OpenTelemetry 规范了可观测性，或者 Schema.org 规范了实体标记那样。否则，每个平台对决策的捕获方式都不同，跨系统的先例查询将无法进行。

Graphlit 的架构选择在此领域至关重要，我们已经使用 Schema.org 和 JSON-LD 对实体进行建模——它们是人物、组织、地点和事件的规范表示。将其扩展到决策轨迹（策略版本、异常类型、审批人、先例引用）是自然而然的演进。而且，由于我们基于开放标准而非专有模式进行构建，因此我们能够支持行业最终采用的任何决策轨迹格式。

诚实框架

我们并非声称目前自己已经是完整的“决策记录系统”，这需要我们深入决策执行的编排层，而不仅仅是信息检索的场景层。

但我们正在构建决策图谱的基础架构。如果没有身份解析、关系建模和时间状态，就无法捕获有意义的决策轨迹，而这正是运营场景所提供的。随着我们扩展到智能体记忆、决策日志记录和工作流检测，各个部分最终会汇聚成它们所描述的愿景。

为什么这件事现在很重要

三个因素汇聚在一起，使之成为最佳时机：

ChatGPT 催生了对企业级应用场景的需求。每个组织都希望人工智能能够理解自身的业务，而不是基于公共网络训练的通用模型。这种需求真实存在，而且不会消失。

模型场景协议（MCP） 实现了智能体的标准化互操作性。 MCP为我们提供了一种标准方法，可以将上下文信息暴露给任何代理。只需构建一次上下文层，它就能与 Cursor、Claude、自定义代理以及未来的任何代理兼容。

每家公司都在尝试使用智能体，但却缺乏使其有效运作的场景层。本文指出的正是这一差距：智能体遇到的障碍仅靠治理无法解决。它们需要运行上下文才能进行正确的推理，也需要决策上下文才能从先例中学习。

总得有人来构建场景基础设施，这就是我们目前关注的重点。

从现在开始

场景图谱的愿景引人注目，而且是可以实现的。它从运营场景入手：组织多模态知识中的身份、所有权、关系和时间理解。

我们构建这套基础设施已经三年多了，如果你要部署的智能体需要了解你的组织（而不仅仅是检索文档），那么上下文层就是你应该着手的地方。

了解更多信息，请访问graphlit.com。