Merge 背景与演讲核心议程

Gil Feig 作为 Merge 的联合创始人兼 CTO，介绍了公司致力于通过连接基础设施帮助企业轻松构建生产级 AI。Merge 拥有超过 400 家企业客户，包括 OpenAI、Netflix 和 Perplexity 等知名公司，其产品线涵盖 Unified、Agent Handler 和 Gateway。本次演讲聚焦于“为什么需要上下文图谱”以及“如何构建”，而非具体技术选型，旨在探讨公司大脑的结构、组件及数据整合逻辑。演讲议程包括定义上下文图谱及其重要性、分析不同层级的上下文（如第三方数据、结构化背景、记忆和技能）、讨论上下文选择策略，以及确保数据的可追溯性和来源证明（Provenance）。Gil 强调，上下文图谱并非传统的图数据库节点与边结构，而是企业 AI 的“大脑”。它由多个关键组件构成：包括来自 NetSuite、Jira 等系统的第三方数据，静态文档等结构化背景信息，以及随交互形成的记忆和 Agent 的技能。这些组件共同作用，为 AI 提供全面且精准的信息支持。

MCP 实时查询的局限性与数据同步层的必要性

为了说明为何仅依赖 Model Context Protocol (MCP) 服务器不足以解决复杂问题，Gil 提出了一个具体案例：当用户询问“客户 A 上周为何不满”时，Agent 可以通过 MCP 实时查询 Zendesk 工单系统获取具体细节。然而，当问题升级为“哪些客户上周不满”或更长时间的年度分析时，实时查询便失效了。Gil 指出：“如果你需要任何形式语义查找或超越简单查询的分析，你就必须同步一份数据副本。” 原因在于大多数平台（如 Zendesk）并未提供语义查询接口，且向量化处理成本高昂；同时，平台缺乏动力让用户减少访问频率。因此，对于需要跨大量数据集进行分析的场景，必须建立同步层（Syncing Layer）。这一层级将数据从第三方系统拉取并存储在企业本地的向量数据库中，从而支持复杂的语义搜索和历史数据分析。Gil 强调：“你无法仅靠 MCP 进行实时查找来解决深层语义问题。” 这种本地缓存与同步机制是构建强大上下文图谱的基础，它弥补了实时 API 调用在批量分析和语义理解上的不足。

数据整合：路由器与摘要器的关键角色

在建立了实时查询（MCP）和本地同步数据层后，面临的下一个挑战是如何整合海量信息。Gil 指出：“我们不能将检索到的巨大上下文直接倾倒给 Agent。” 为了解决这一问题，需要引入路由器（Router）和摘要器（Summarizer）。路由器的作用是在处理提示词初期，将请求分发到正确的数据源或处理方式。Gil 提到：“路由器在开始时发送事物到正确的位置。” 这意味着系统需要根据问题的性质，智能判断是调用实时 API、查询本地向量数据库，还是使用静态文档。这种分层架构确保了 Agent 既能获取最新的实时状态（如 Stripe 的单笔交易查询），又能进行深度的历史数据分析。Gil 总结道：“你需要在 MCP、实时查找和同步/缓存查找之间建立平衡。” 通过这种结构化的数据整合，企业可以构建一个既灵活又强大的 AI 上下文层，避免因信息过载或访问延迟导致的 Agent 失效。最终目标是形成一个能够理解复杂业务逻辑、具备记忆能力并能准确调用技能的“公司大脑”。

技能与记忆：定义数据获取的企业逻辑

在构建上下文层时，记忆（Memory）和技能（Skills）是决定数据获取逻辑的核心要素。仅仅聚合数据是不够的，因为不同公司对“上下文”的定义截然不同。例如，“上周哪位客户感到不满”这一概念，在一家公司可能意味着查看工单数量，而在另一家不使用传统工单系统的公司，则可能需要优先查阅 Qualtrics 的调查数据以评估客户满意度。

“Skills are important because you need skills like how do we determine if a customer is happy?”

因此，Agent 的处理流程必须首先检查是否有关联的技能或记忆。如果有，则执行相应逻辑；如果没有，再进入数据检索阶段。这种机制确保了 Agent 能够根据公司的特定原则和流程来确定数据来源。例如，通过本地缓存查询所有客户的工单数量、总结工单内容并给出状态，这种复杂的语义检索无法仅靠实时 API 调用实现，而是需要同步缓存数据库（Synced Cache DB）与实时 MCP 查找的结合。

上下文分层架构：从实时 API 到衍生数据

上下文的构建分为四个层级，每一层都有其特定的用途和成本结构。提示词技能与记忆驱动数据获取方向；实时 API 调用（Live Lookups）易于构建且运行成本低，适用于简单的检索场景；缓存数据（Cached Data/Vector DB）虽然设置复杂、运行昂贵且需持续同步以保持更新，但对于语义数据检索和深度问题是必不可少的；最后是衍生上下文（Derived Context）。

“Context is anything that's being passed into the agent. We're going to put this all here because they all belong in your context layer.”

衍生上下文是指在从第三方拉取数据时，额外生成的结构化信息。例如，在实时获取客户全套工单的同时，系统可以自动总结这些数据并将其存储在结构化存储上下文（Structured Stored Context）中。这样做的目的是避免未来面对常见问题时重复进行查找和总结，从而提升效率并丰富上下文数据。这种混合了实时与缓存、原始与衍生数据的架构，为任何提问提供了丰富的数据支持。

以Acme客户为例解析Context Graph的数据获取与推理流程

在构建企业级上下文图谱（Context Graph）时，核心在于如何高效、准确地整合分散的数据源。以更新客户Acme的状态为例，系统首先需要检查账户摘要的缓存状态。如果缓存中存在有效数据且未过期，则直接调用；若缺失或陈旧，系统会通过实时API查询CRM（客户关系管理）数据。接着，为了获取最近的支持互动记录，系统会查询工单系统。由于实时查找存在超时风险，策略上仅拉取最近的5张工单而非完整历史记录。这种设计平衡了数据的新鲜度与系统稳定性，确保在SLA（服务等级协议）范围内获取最新互动信息。最终，系统将整合后的数据生成一个派生摘要（derived summary），该摘要既可作为临时结果返回，也可存储以供后续复用。这一过程展示了Context Graph如何通过协调缓存与实时API，在避免性能瓶颈的同时提供完整的业务视图。

Context Graph的本质：超越工具的数据、流程与技能整合

许多企业误以为引入更多AI工具即可解决问题，但Gil Feig强调：“工具不是上下文（tools are not context）”。Context Graph的真正价值在于帮助组织跨越单一应用，对公司整体进行推理。它不仅仅是工具，更是数据、同步后的数据以及业务流程的结合体。例如，当客户投诉时，系统需要知道具体的处理流程、文档规范以及如何将问题路由到正确的部门。这些被称为“技能（skills）”，它们本质上是公司的业务流程、数据结构和所需执行的动作的综合体。只有将公司特有的流程和数据结构化，AI才能像人类员工一样理解业务逻辑并做出正确决策。这种整合使得Context Graph成为连接孤立数据孤岛与自动化行动的关键桥梁。

高质量数据优先：避免信息过载并确保决策可追溯性

在数据处理策略上，“更多的数据并不总是更好的（More data, not always better）”。企业应追求新鲜、高质量且按需获取的数据，而非盲目同步海量信息。当必须同步数据时，关键在于将其结构化以便以正确的方式访问。此外，可追溯性是AI决策的底线。每一个回答都必须具有可追溯性（every answer has to be traceable）。如果AI做出了错误决策，企业必须能够清晰地追溯其推理路径和数据依据。避免让AI在缺乏解释的情况下做出糟糕决定，是建立企业信任的关键。通过确保数据来源清晰、逻辑链条完整，Context Graph不仅提升了效率，更增强了AI决策的透明度和可控性。

Merge平台提供的企业级上下文层解决方案

为了帮助企业构建这样的Context Graph，Merge提供了一系列预建的基础设施。其Gateway作为LLM路由器，Unified用于从第三方平台同步数据，而Agent Handler则提供了涵盖数百种工具的预建MCP（模型上下文协议）连接。这些解决方案内置了治理身份和溯源功能，支持内部及面向客户的使用场景。通过这种即插即用（plug and play）的方式，企业可以快速搭建起强大的上下文层。Enterprise AI runs on us，Merge旨在通过简化数据同步和工具连接，让企业专注于业务逻辑而非底层技术集成。

结论

Context Graph并非传统图数据库，而是整合实时API、本地同步缓存及企业特有技能与记忆的“公司大脑”。其核心优势在于通过路由器平衡实时性与深度语义分析，解决MCP无法处理的批量查询与复杂推理。构建关键在于建立数据同步层以支持向量检索，并严格遵循“高质量优先”与全链路可追溯原则。该架构适用于需跨系统整合数据、具备特定业务流程的企业，能有效避免信息过载并提升AI决策透明度。然而，其实施依赖复杂的缓存同步机制与结构化数据治理，并非单纯引入工具即可实现。