Context Graph 与 Graph RAG：听起来像，其实不像

一个容易混淆的名字

最近读到 Foundation Capital 的一篇文章，标题很抓人："Context Graphs: AI's Trillion-Dollar Opportunity"。万亿美元的机会，谁不想了解一下？

但读着读着，我有点困惑。Context Graph？这不就是 Graph RAG 吗？都是图，都是为了给 AI 提供更好的上下文，有什么区别？

后来仔细一想，发现这两个概念虽然名字相似，解决的却是完全不同的问题。搞清楚这个区别，其实能帮我们理解 AI Agent 发展的一个重要方向。

让我慢慢讲。

先说 Graph RAG

Graph RAG 不是什么新概念了。它是 RAG（检索增强生成）的一个升级版。

传统 RAG 的逻辑很简单：用户问问题，我去知识库里找相关的文档片段，塞给大模型，让它基于这些内容回答。问题是，文档被切成一块一块的，彼此之间的关系断了。

比如你问"我们对企业客户的退款政策是什么"，传统 RAG 可能只找到退款政策那一段。但实际上，企业客户有特殊条款，特殊条款又关联到 SLA，SLA 又影响退款流程。这些关系，传统 RAG 看不到。

Graph RAG 的思路是：先把知识组织成图。文档里提到的人、产品、概念变成节点，它们之间的关系变成边。查询的时候，不只是找相似的文本，而是沿着关系往下走，把相关的上下文一起带回来。

这很有用。检索更准，回答更完整，幻觉更少。

但 Graph RAG 本质上还是在做一件事：帮你更好地找到已有的知识。

Context Graph 在说什么

Foundation Capital 说的 Context Graph，解决的是另一个问题。

他们的原话是这样的：

"我们把这些轨迹形成的累积结构称为 context graph：不是'模型的思维链'，而是跨实体和时间缝合的决策轨迹的活记录，使先例变得可搜索。"

翻译一下：Context Graph 不是用来找信息的，而是用来记住"我们为什么这样决定"的。

这话听起来有点抽象，让我举个例子。

假设你是一家 SaaS 公司的销售。有个大客户续约，按政策只能打九折，但客户威胁要走。你找 VP 审批，VP 说："行，给他打八五折，上次 ACME 那个客户我们也这么干过。"

最后 CRM 里记录了什么？"折扣：15%"。

没了。

那些关键信息呢？这个客户为什么能拿到超出政策的折扣？VP 是基于什么判断的？上次 ACME 的情况是怎样的？这些都没记录。它们存在于 Slack 聊天记录里，存在于那通电话里，存在于 VP 的脑子里。

三个月后，你离职了。新来的销售遇到类似情况，完全不知道有这个先例。AI Agent 更不知道，你让它去哪找？这些信息从来没有变成过"数据"。

Context Graph 要捕获的就是这个：决策本身，以及做这个决策时的所有上下文。谁批准的，为什么批准，参考了什么先例，当时各个系统里的状态是什么。

这不是检索问题。这是记录问题。

两种图，两种思路

现在区别应该清楚了：

Graph RAG 问的是：我们知道什么？

Context Graph 问的是：我们决定了什么，为什么？

Graph RAG 是从现有文档里提取知识，构建成图，方便检索。它的数据来源是静态的：你的知识库、文档、手册。图是离线构建的，定期更新。

Context Graph 是从实际的业务执行中捕获决策，记录下来，形成先例。它的数据来源是动态的：每次有人（或 AI）做决策，就产生新的数据。图是实时增长的，随着业务运转不断积累。

一个帮你找到答案。

一个帮你记住为什么。

一个场景，两种帮助

让我用同一个场景说明两者的区别。

还是那个客户续约的例子。AI Agent 需要处理这个案子。

Graph RAG 能帮什么忙？

Agent 问："企业客户的标准续约条款是什么？"

Graph RAG 遍历知识图谱：续约政策 → 适用于企业客户 → 标准折扣上限 10% → 但如果签年度合同可以额外 5%……

Agent 拿到了规则。它知道按政策应该怎么做。

Context Graph 能帮什么忙？

Agent 问："这个客户以前有过类似的情况吗？我们是怎么处理的？"

Context Graph 返回：2024 年 Q2，这个客户续约时也威胁过要走。当时 VP 批准了 15% 折扣。决策依据是：客户 ARR 20 万，有 3 个未解决的技术问题，竞争对手正在接触。VP 的判断是"高价值客户 + 流失风险，值得额外投入维护关系"。

Agent 拿到了先例。它知道这种情况以前怎么处理的，为什么那样处理。

Graph RAG 给的是规则。Context Graph 给的是判例。

规则告诉你应该怎么做。判例告诉你实际上怎么做的，而且为什么那样做是对的。

为什么这个区别重要

Foundation Capital 的论点是：Context Graph 可能是下一个万亿美元的机会，因为它会成为一种新的"记录系统"。

传统的记录系统（Salesforce 记录客户，Workday 记录员工，SAP 记录交易），它们记录的都是"发生了什么"。

Context Graph 记录的是"为什么允许它发生"。

这个"为什么"，以前一直散落在各个角落，从来没有被系统性地捕获过。但在 AI Agent 越来越自主的时代，这个"为什么"变得至关重要：

• 合规团队需要审计 Agent 的决策
• Agent 需要从过去的例外中学习
• 新员工需要继承老员工的判断力
• 组织需要保持决策的一致性

Graph RAG 帮不上忙，因为这些信息从来就没有写进过文档。你无法检索不存在的东西。

Context Graph 能帮忙，因为它直接在决策发生的那一刻捕获这些信息。

为什么现有巨头做不了

Foundation Capital 还有一个有意思的观点：现有的企业软件巨头很难构建 Context Graph。

为什么？因为它们不在"执行路径"上。

Salesforce 知道客户信息，但它不知道这笔交易是怎么谈下来的。Snowflake 能存储历史数据，但数据到它那儿的时候，决策上下文已经丢了。ETL 只搬运结果，不搬运过程。

要捕获决策的完整上下文，你必须坐在决策发生的地方。你必须是那个执行工作流的系统，而不是事后接收数据的系统。

这就是为什么 Foundation Capital 认为，构建 Agent 编排层的创业公司有结构性优势。它们天然在执行路径上，能看到决策的全貌：从哪些系统拉了什么数据，评估了哪条政策，走了哪个例外流程，谁批准的，最后写了什么状态。

把这些记录下来，就是 Context Graph。

两者可以共存

说了这么多区别，其实两者并不矛盾。它们解决不同的问题，可以一起用。

Graph RAG 是知识层：帮 Agent 找到相关的规则、政策、背景信息。

Context Graph 是先例层：帮 Agent 找到类似的历史决策，理解组织的实际做法。

一个完整的 AI Agent 系统，可能两者都需要。用 Graph RAG 理解"规则是什么"，用 Context Graph 理解"规则是怎么被执行的"。前者提供知识，后者提供判断力。

对构建者的启示

如果你在做 AI Agent 相关的产品，这个区分或许有用：

如果你的用户困于"找不到信息"，Graph RAG 是答案。这个领域已经有不少工具了：LlamaIndex、LangChain、Neo4j 都在做。你是在改进检索。

如果你的用户困于"不知道为什么这样决定"，Context Graph 是机会。你需要想办法进入执行路径，捕获决策的完整上下文。这是一个更新的领域，可能也是更大的机会。

当然，如果你在构建一个完整的 Agent 平台，两者大概都需要。

最后

Graph RAG 和 Context Graph，名字像，但解决的问题完全不同。

一个让 AI 更会找东西。

一个让 AI 更会记事。

两者都重要。但如果 Foundation Capital 的判断是对的，后者可能是下一个大的平台机会。因为找东西这件事，很多人在做了。记住"为什么"这件事，几乎没人在做。

而在 AI Agent 越来越自主的世界里，记住"为什么"，可能比找到"是什么"更重要。

---

发布日期： 2025年12月27日
主题： AI Agent、知识图谱、企业 AI、RAG、记录系统

参考资料：

• 微软研究院："From Local to Global: A Graph RAG Approach to Query-Focused Summarization"（2024）
• Foundation Capital："Context Graphs: AI's Trillion-Dollar Opportunity"（2025年12月）