> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 上下文图：智能体的"RAG杀手"
- URL: https://www.hubwiz.com/blog/context-graphs-the-rag-killer-for-agents/
- Published: 2026-08-24T07:37:59.000Z
- Updated: 2026-10-13T15:13:52.000Z
- Description: 这个说法很大胆。但事实更有用：RAG告诉你发生了什么。上下文图教它为什么做出某个决定。
- Author: admin
- Tags: AGENT, #Import 2026-10-14 14:41

![Post cover image](https://www.hubwiz.com/blog/content/images/2026/08/1-Gwr5R1BEhLF5PasnijGSvw.png)

我使用过的每个RAG系统都能告诉我文档说了什么。但没有一个能告诉我，为什么我们团队在上个季度做出了那个决定。

这个差距现在有了名字。

它叫做**上下文图**，2026年是它开始出现在严肃的AI基础设施对话中的年份，而不仅仅是研究论文。

**有些人称之为RAG杀手。**

这有点戏剧性，但读完这篇文章，你就会知道为什么。但炒作背后的真实故事确实值得你花六分钟时间了解。

## 1\. RAG擅长事实，但推理能力很弱

RAG的工作原理是将文档切成小块，将每个块转换为向量，然后检索与你的问题最匹配的块。

这对于简单的查找非常有效。询问政策文档说了什么，RAG能快速找到正确的段落。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-Cklc5qFwzLuazkE-AYfaQg.png)

问题出现在更难的问题上。

分块将文档切成碎片，碎片之间失去了相互联系。

向量搜索无法重建文档被切碎时断裂的关系。

询问需要多个相关事实的问题，RAG通常返回无法构成真正答案的片段。

## 2\. 上下文图记住的是决策，而不仅仅是文档

上下文图是一个结构化的、不断更新的记录，记录了组织如何真正做出决策，而不是文档所说应该如何运作。

**它不存储文本块，而是存储决策事件。**

谁在什么条件下决定了什么，参考了哪个早期决策，授予了哪个例外。随着时间的推移，这些事件相互关联，先例变成了你可以搜索的东西，而不是埋在某人记忆中的东西。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-Q77siNYnxqwDJqPglFc-Lg.png)

这是RAG从未被设计来做的事情。RAG检索文档说了什么。上下文图跟踪你的组织实际如何运作。

## 3\. 数据、上下文和决策痕迹是三件不同的事

大多数团队认为"数据"和"上下文"是一回事。它们不是，这种差异解释了很多AI代理错误。

**数据告诉你发生了什么。**

一笔交易结束了，一个工单被升级了，一个请求被批准了。上下文告诉你为什么这样发生，以及在什么条件下被允许发生。

介于两者之间的是大多数公司从未捕捉到的东西：决策痕迹。在特定情况下发生的特定记录，在哪个政策下，由谁批准，以及为什么。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-6W17fvWixUrj2ewuOHLBTg.png)

没有中间层，AI代理要么过于字面地遵循规则手册，要么因为没有先例可以参考而将所有事情升级给人工处理。两者都不是模型问题。两者都是缺失的基础设施问题。

这在实际部署中表现为两种特定的失败模式。

- **第一种**是代理完全按照书面政策执行，错过了管理规则实际如何在实践中被弯曲的机构细微差别。
- **第二种**是代理几乎将所有事情升级给人工，因为它没有先例记录可以依靠，这悄悄地消除了使用代理的全部效率优势。

更强的模型或更聪明的提示都无法修复这两种失败。两者都可以追溯到同一个缺失的层：没有人构建捕捉决策如何实际做出的基础设施。

## 4\. 上下文图和知识图谱不是一回事

这两个经常被混淆，它们回答的是真正不同的问题。

**知识图谱映射当前存在的内容：**哪些实体与哪些相关，谁拥有什么，哪些记录连接到哪些项目。它是查询时冻结的结构快照。

上下文图映射你是如何到达这里的。它将决策本身视为图中的对象，并将时间视为数据的真实结构部分，而不是贴在旁边的标签。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-_xGBNeXCGAtJtwF4cN2uZw.png)

它们也不是竞争对手。

上下文图通常构建在知识图谱基础设施之上，添加了普通知识图谱从未捕捉到的决策层。

## 5\. 构建一个需要四个不同的层

这不是简单的数据库替换。真正的上下文图系统由四个协同工作的层组成。

**第一层**监视原始活动：编辑的文档、更新的字段、发送的消息，按它们在系统中发生的顺序。

**第二层**将这些原始活动解释为有意义的内容。三天内的一系列编辑和消息可能代表一个定价例外，即使没有系统曾经这样标记过。

**第三层**将所有内容组织成一个图，时间作为真正的结构部分内置其中，这样代理不仅可以查询发生了什么，还可以查询在发生的确切时刻什么是真实的。

**第四层**让图持续增长。每次代理运行都会添加新的决策痕迹，因此系统使用越多就越准确。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-I0su0U9FDjTTBpD7mWtxeg.png)

这是真正的基础设施工作，不是你周末就能安装的插件。

## 6\. 所以它真的是RAG杀手，还是完全不同的东西

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-S7MYJzCVAHA8XgLwSszQsg.png)

这是诚实的答案，直接来自构建这项技术的人。RAG提高了模型所知道的。

**上下文图提高了代理的决策能力。**这是不同的工作，大多数严肃的部署两者都需要。

RAG仍然是简单事实查找的更快、更便宜的答案。上下文图在更难的问题上证明其成本：边缘情况、例外情况，以及正确答案取决于没有人写下来的先例的决策。

"RAG杀手"框架卖的是标题。更有用的框架是，上下文图是代理AI缺失的层，坐在你已经构建的一切之上，而不是取代它。

## 7、你的项目需要哪个

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-bP-kMfFNUGghqs2YtoLYkQ.png)

## 8、值得保留的一个想法

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-4naYBpniVsD3vATEZqPLuw.png)

RAG回答"这个说了什么。"上下文图回答"我们之前真正如何处理过这个，以及为什么。"

这些是真正不同的问题，大多数真正的AI代理失败都可以追溯到只有第一个问题的答案。不是更聪明的模型。不是更好的提示。是一个没有人构建的机构记忆缺失层。

如果标题需要，可以称之为RAG杀手。更准确的故事是，代理AI终于得到了它一直缺失的第二部分。

---

原文链接：[Context Graphs: The RAG Killer AI Agents Actually Need](https://medium.com/@yadavdivy296/context-graphs-the-rag-killer-ai-agents-actually-need-203288a4782f?ref=hubwiz.com)

汇智网翻译整理，请转载文章时标明出处。

> **这是「RAG / 数据 / 文档智能」专题的一部分。**完整地图见：[RAG / 数据 / 文档智能完全指南](https://www.hubwiz.com/blog/rag-data-stack/)