好的，谢谢大家前来参加。我是吉尔·费格（Gil Feig），Merge 的联合创始人兼首席技术官。Merge 致力于帮助企业轻松构建生产级人工智能应用，我们是连接一切的底层基础设施，让所有组件协同工作。今天我将探讨为什么你需要一个上下文图谱（Context Graph）以及如何构建它。我不会讨论你应该使用哪些具体技术，你可以去问你的 AI 代理，会有很多优秀的技术支持这一需求。本次演讲的重点在于：为什么你需要一个上下文图谱，以及在更高层面上如何构建它、其组件应包含什么，以及如何让这些部分协同工作以打造公司最强大的“大脑”。顺便提一下，如果你还没有拿到帽子，我的团队正在四处分发。他们说这象征着“紧密连接”。好了，让我们深入主题。

我不会花太多时间介绍 Merge，只是简要概述一下：我们拥有超过 400 家企业客户，包括 OpenAI、Ramp、Netflix、Perplexity 等各行业公司，用于内部及面向客户的 AI 用例。我们有三款产品：Unified、Agent Handler 和 Gateway，涵盖了该领域的许多组件。Merge 由我和联合创始人沈石（Shen Shi）六年前创立，已完成三轮融资，目前在世界上三个最美丽的城市拥有 130 名员工。好的，以下是今天的议程：第一，我们将讨论什么是上下文图谱以及为什么每家公司都需要它；第二，探讨不同层级的上下文、哪些类型的数据和逻辑应纳入图谱；第三，讨论上下文选择策略，即如何为代理在任意时刻挑选最相关的内容或语境。

第四部分将涉及可追溯性和来源证明，即我们如何知道数据来自何处、谁请求的、何时产生的以及是否新鲜等。最后是几个关键结论，结束后我会留下来回答大家的问题，欢迎随时上来交流。那么，在这个演讲中什么是上下文图谱？我们不会深入探讨真实图基础设施中的节点和边连接细节，而是关注公司“大脑”的概念。你的企业上下文图谱由许多不同组件构成：包括第三方数据，如你使用的其他系统（NetSuite、Jira 等）；结构化上下文，这可能来自第三方或你放入上下文层的数据。

还包括静态文档（希望始终传递给代理的内容）、记忆功能（在使用代理过程中形成的内容，如指示其记住某些事项，或代理自行判断应记忆的事项）。此外还有技能（Skills），这是上下文图谱中非常重要的一部分，我们稍后会详细讨论。好的，看到有些图片了，不错。接下来我们通过一个例子来说明：仅连接单个或几个 MCP 服务器并就此止步是不够的。让我们问一个简单的例子问题：“为什么客户 A 上周生气了？”这是一个很简单的问题，代理可以访问 Zendesk 工单系统进行检查。

它会查看该客户上周提交了哪些工单，发现 API 同步中断及具体错误细节。我们还看到该客户总共提交了三张工单，这足以回答这个问题。但如果我们要扩展问题：“哪些客户上周生气了？”这就难多了，因为代理必须加载 Zendesk 中过去一周的所有工单。如果是“过去一年哪些客户生气了？”我们也应能回答，但如果代理必须每次实时查询并一次拉取 100 张工单，直到超时都无法回答。因此，MCP 并未完全解决这些问题，因为这些平台 API 的底层访问模式不支持实时查询方法。

如果票务系统能语义化地回答，例如 Jira 提供一个端点允许你用英语查询“上周哪些客户生气了”并返回数据，那就太好了。但没有平台愿意这样做，因为向量化处理需要成本，且这会减少用户访问其平台的频率。因此，你需要在此之上构建一个同步层（Syncing Layer）。不能仅靠 MCP 实时查询那些需要深入分析或语义提问的内容，你必须将数据副本同步到本地。这并不适用于所有情况。例如对 Stripe 的静态查询，我们总是针对特定客户提问或执行单一操作，这可以通过 MCP 实时完成。

但如果需要任何形式的语义查询、分析超出简单查找且需跨越大量数据集，你就必须同步副本。这成为上下文层中同步层的下一部分：你有 MCP 实时查询，也有从第三方获取的已缓存或同步查找。你将这些数据放入本地的向量数据库中（AI 可以相对容易地构建该数据库）。你需要制定策略，决定如何在上下文层中存储和检索数据以支持同步到缓存的层级。但下一个问题是：现在我们有了所有相关数据，从向量数据库获取语义数据，并对其他所需数据进行实时查询。我们需要将这些数据整合起来，因为我们不能将大量检索到的上下文直接倾倒给代理。

这就是引入路由器和摘要器的地方。路由器在开始时将内容发送到正确的位置，提示词进入后，它决定……

由谁来处理，以及发送到哪里。一旦数据全部聚合在其中，我们的摘要器随后会从同步上下文和实时上下文中提取这些数据进行总结，并将其发送回发出提示的代理。但你们可能注意到，我们这里有一件事还没谈到，那就是记忆和技能。它们可以独立存在。为什么这对你的上下文层很重要？原因是获取上下文本身就是一个包含公司原则和流程的集合。例如，“上周哪位客户感到不满”对一家公司和另一家公司来说可能意味着完全不同的事情。它可能是指打开的工单数量，但如果是积极的工单呢？如果我们不使用工单系统，而是为了客户满意度需要始终先查看 Qualtrics 并查看调查数据呢？因为这就是我们公司的工作方式。我们是不同的。

这就是技能重要的原因，因为你需要有这样的技能：如何确定客户是否满意？因此，现在你的代理在开始检查同步层或实时层以获取数据之前，应先检查技能。然后进行总结并返回结果。所以这里的流程是：提示进入后路由到正确的代理，代理查看是否与手头的问题或任务关联了任何记忆或技能。基于此，它就知道在同步缓存数据库和实时 MCP 查找中何处寻找数据，然后进行总结并返回。这里没有魔法，真的没有任何魔法。只要你知道如何计算，在你的特定用例中表现良好即可。

之前我们看到的开放工单数量的这种流程，仅靠实时查找是不可能实现的，但通过本地查找则非常简单。我们基本上能够收集所有客户及其工单数量，总结他们的工单状态，并为每个客户提供状态。因此，这是实时查找和缓存查找的结合体，它们在这里共同作用，为任何提出的问题构建丰富的数据。好的，所以存在不同层次的上下文，有些人可能会争论提示、技能和记忆是否属于上下文。任何传递给代理的内容都是上下文。我们将它们全部归入此处，因为它们都属于你的上下文层。

你有提示、技能和记忆。我们讨论了它们如何驱动我们要从何处获取数据？你还有实时 API 调用。这些更容易构建，更易于添加，比同步上下文运行成本更低。因此，当你确定需要进行简单查找或检索时，应优先使用这些方式。如果需要语义数据、复杂查找或对任何数据进行深入提问，缓存数据则是绝对必要的。但请记住，它的设置和构建稍微复杂一些。运行成本也更高，因为你必须拥有向量数据库并不断同步数据。因此，保持其更新难度较大。

最后一点是我们尚未完全讨论的衍生上下文，这基本上是指从第三方拉取数据时创建的额外上下文。例如，当我们实时拉取所有工单时，每当一个客户的完整工单集进入时，我们也会对这些内容进行总结。实际上，我们将这些数据存储在存储的上下文中——即结构化存储上下文里，我们存储了拉入数据的摘要。这样在未来如果有常见问题时，我们就无需再次重新查找和总结所有内容。太棒了。所以这四种方式结合在一起，你们看到了图表展示它们是如何做到的。是的，这些就是层级结构。

让我们快速梳理一下当查询或提示进入时的工作流程图。首先，我们是否有匹配的技能或记忆？如果有，是的，我们要执行该技能。如果该技能需要外部数据吗？如果没有，那么我们就直接生成响应并发送回去。不幸的是，事情并不总是这么简单。如果我们没有匹配的技能或记忆呢？如果没有，那么让我们直接进入数据选择环节。如果该技能需要外部数据也是如此。所以我们说“是”，我们要做的第一件事就是检查我们的缓存或同步数据存储，并询问数据在这里是否新鲜？是否在 SLA（服务等级协议）范围内？我们可以使用这些数据吗，因为它被视为足够新？如果是，那么我们就使用该缓存上下文。

如果不是呢？那很不幸，我们必须向下调用实时 API。一旦我们拥有足够的上下文，我们将循环执行几次以构建所需的上下文。一旦有了足够的上下文，我们可能希望将刚刚发现或推断出的内容存储为记忆，然后生成响应并发送回去。同样的情况也适用于我们没有足够上下文时：我刚才展示了这一点，但我们需要调用实时 API，然后我们将生成响应并发送回客户端。我就在这里停一下。我看到有些人正在观看和拍照。

好的，最后一部分几乎在最后：可追溯性和来源证明。起初似乎并不重要。不要忽略数据的来源，始终存储它。你从 MCP 那里获得这些信息，如果你将任何内容同步到向量数据库中，还有一种叫做元数据的东西。你想将其存储在那里，它与数据相关联。这是至关重要的。这类似于你在 ChatGPT 或你使用的任何表面上看到的情况：当它陈述一个事实或说某事时，最后它会列出三个来源并链接到出处。当基于这些数据做出关键业务决策时这一点尤为重要。

当数据被版本控制、可能过时，或者让它基于一年前同步的数据做出决策时。你不希望这样发生。所以你需要知道它来自哪里：我们是在何时获取的？（这里没有显示）。在什么理念、ID 和范围下？谁访问了数据？使用了哪些权限来访问它？是否经过了转换？原始样子是什么？最后，什么应该使其失效？例如年龄。如果数据超过一个月大，我们就不想再考虑它了。这对于在你的平台中显示非常重要；即使不是为了在内部平台或你构建的任何其他平台上显示，也是为了能够在出现问题时进行调查，因为问题总会发生。

将所有内容结合起来，这里是另一个我们可能会使用的示例。所以，“请给我一个关于……”

关于客户 Acme 的状态更新，需包含续约风险和上次支持交互记录。首先，我们将检查账户摘要的缓存；我们假设这里没有技能数据，因此会进行检查。如果仍然缺失或不存在，我们将通过实时 API 查询调用 CRM。接着，我们会针对上次支持交互记录查询票务系统；如果这在服务等级协议（SLA）范围内，则会被缓存，否则可能需要进行实时查询。我们只希望拉取五张工单；无法拉取完整历史记录，因为正如之前所述，当我们进行实时查询时，会面临超时风险。最后，我们将生成一个衍生摘要；我们可能会存储该衍生摘要并将其传回。

关键要点在于，工具并不等同于上下文。上下文图谱将帮助你在全公司范围内进行推理；这不仅仅是关于工具，更是关于数据、同步的数据以及作为企业所拥有的流程。谁在记录当客户投诉时我们该做什么？它如何知道始终将请求路由到正确的位置？这就是技能。这是你公司的技能、流程和数据，以及你需要采取的工具和行动。数据并非越多越好；你想要的是新鲜且高质量的数据。你只应拉取所需的内容。当你确实需要同步数据时，需要对其进行适当结构化，以便以正确的方式访问它。

最后，每个答案都必须是可追溯的；你不想陷入 AI 做出了错误决定而你完全不知道原因的境地。最后一部分，顺便提一下 Merge；企业级 AI 运行在我们之上。我们为许多公司提供这些功能支持。我们有 Gateway，这是一个 LLM 路由器；有 Unified，它帮助你从第三方平台同步客户数据。此外还有 Agent Handler，它在数百种工具之间提供了预构建的实时 MCP 连接，内置了治理身份、溯源等功能。是的，它即插即用，适用于内部和客户面向的使用场景。因此，如果你想构建一个简单的上下文层，请联系我们。感谢大家的聆听。