来源

• 原始链接：https://www.youtube.com/watch?v=XovaGv4f39A
• 来源类型：视频逐字稿
• 来源标题：当所有上下文都重要：扩展型缓存增强生成

当所有上下文都重要：扩展型缓存增强生成高亮

文本来源是 AI Engineer 频道视频《当所有上下文都重要：扩展型缓存增强生成》的中文可读转写稿。下面按汉松兴趣画像优先保留机制解释、反常识判断和可复用 workflow，而不是做普通摘要。

一、评估、反馈与故障闭环

背景

这组高亮抓住《当所有上下文都重要：扩展型缓存增强生成》里最值得保留的反馈闭环：Agent 系统的可靠性主要来自可观测、可复现、可评分的外部结构，而不是一次性把 prompt 写得更漂亮。

然后我们只需要某个东西，把正确的问题问给正确的 bucket。为此，我们可以使用一个更聪明的模型来 interrogate 每个 bucket，并最终综合出答案。

如果你的文档集合不经常变化，GraphRAG 是一种很好的方法，可以找到细节之间的关系，从而回答用户问题。不过，我们这个非常具体的场景规定：数据不仅高度互联，而且会非常频繁地被替换。

所以我们没法只是从集合中取一部分文档传给 LLM。这只是这种方法的诸多限制之一。

兴趣匹配度很高。它对应汉松持续关注的 Agent 工程化主线：把非确定性系统放进可反馈、可回归、可复盘的闭环里，真正的壁垒在 harness、eval、trace 和人类分诊。

二、上下文、记忆与检索边界

背景

这里讨论的是 Agent 能否拿到正确材料的问题。对汉松有价值的点在于，它把上下文从背景信息变成系统的运行材料：可索引、可缓存、可审计，也可被重新组织。

这个方法看起来会像 Cache Augmented Generation（CAG）：我们使用一个拥有大 context window 的模型，把文档加载进 context，并通过存储模型的 KV matrix 来缓存这个 context。

假设我们有大量文档，每一份文档都代表一个事件，而且这个集合里的所有文档都与回答用户的一组问题相关。不仅如此，还有另一个挑战。

但在实践中，当文档之间的关系非常密集时，supervisor 往往会忽略那些第一眼看上去不相关的 domain。出于这个原因，所有文档会以没有特定顺序的方式分发。

兴趣匹配度很高。这是上下文工程的核心问题：不是给模型更多字，而是让模型在正确边界内获得正确材料，并让材料本身可维护、可验证、可复用。

三、工具、系统与工程约束

背景

这组摘录偏工程实现。它关心的不是模型能力的抽象上限，而是工具、接口、基础设施和生产约束如何决定 Agent 最终能不能稳定工作。

为此，我们只需要一个 vector database 和一个 embedding model。embedding model 会接收文档，并把它们转换成一种学习得到的数值表示，也就是 vector。

GraphRAG 有很多步骤，但基本上，它会使用 LLM 读完所有文档，并抽取关键 entity 以及它们之间的 relationship。

由于所有 cache 都可以并行加载，这个知识构建过程会明显快于 GraphRAG，同时又能提供比简单 RAG 更准确的答案。

兴趣匹配度高。这里能迁移到实际团队建设：工具选择、数据流、权限、成本、延迟和部署形态，往往比单点模型参数更能决定系统上限。

整体判断

这篇内容最值得保留的是它把《当所有上下文都重要：扩展型缓存增强生成》从一次视频分享转成了可迁移的系统判断。核心素材集中在评估、反馈与故障闭环、上下文、记忆与检索边界、工具、系统与工程约束。对汉松后续写作和团队实践来说，它可以作为 AI Agent 工程化素材库的一块：不是追逐单个工具功能，而是持续追问系统如何获得上下文、如何被评估、如何进入生产闭环，以及人类判断应该放在哪些关键节点。