Nyk (@nyk_builderz) 发了篇文章，标题很直接：Context Engineering killed RAG。

RAG 是什么：解决稀缺问题的工程方案

RAG（检索增强生成）最初被设计出来是因为上下文窗口太小。放不下整个文档，所以把文档分块、向量化、检索、注入相关片段。它能工作，但本质上是把一个搜索问题做成了大量 plumbing。

现在上下文窗口已经 1M token 了。Claude Opus 4.6 在 2026年3月13日发布，1M token 无价格溢价。75万个词，3000页，一个代码库加文档全塞进去还有余。

瓶颈已经转移了。大多数团队还没有注意到。

错误源变了

超过 70% 的现代 LLM 应用错误来自不完整、不相关或结构不好的上下文——不是来自模型能力不足。模型已经够聪明了，但收到的上下文不够好。

RAG 解决的是稀缺问题。但当你有 1M token 时，问题不再是稀缺，而是 curation——策划。往窗口里塞东西很容易。知道放什么进去、留什么在外面，才是难点。

从 retrieval engineering 到 context engineering 的转变，是当前应用 AI 领域最重要的变化。

RAG 没有死，只是重新定位

这篇文章不是"RAG 已死"的宣言。RAG 在以下场景仍然赢：

规模超过窗口大小。 如果知识库是数百万文档——企业 wiki、法律档案、医学文献——永远不会塞进上下文窗口。RAG 仍然是必需的。

成本在规模上的差异。 一个设计良好的 RAG pipeline 检索 5-20 个相关片段，总计 2000-10000 token。比起每次查询上传全部上下文，RAG 减少 50-200 倍的输入 token。在规模上，这个差异是每年几十万美元。

新鲜度。 RAG 可以秒级索引新文档。长上下文需要重新上传全部内容。对于每小时更新的知识库，RAG 的增量索引是结构性优势。

访问控制。 RAG pipeline 可以在检索前按用户权限过滤。长上下文方案没有文档级访问控制的内置机制。

诚实答案：大多数团队应该两者都用

检索以缩小语料库，然后把相关子集完整传入，而不是继续分块。

"迷失在中间"问题

Stanford 研究者在 2023 年证明了这一点：模型对窗口内所有内容的注意力不是均匀的。它们总是过度关注开头和结尾，忽视中间部分。在 1M token 的窗口里，"中间"涵盖数十万 token。

在 Anthropic 自己的 MRCR v2 基准测试中，256K 到 1M token 之间有 15-17 个百分点的性能下降。在完整窗口下，1/4 的多针检索会失败——即使是在为测试这个场景设计的合成基准上。

Anthropic 内部把这个退化叫做"context rot"。一个 GitHub issue 认为"1M 上下文窗口"和可靠的 ~200-256K 有效上下文之间的差距构成一个缺陷。

实际阈值：1M 是理论最大值。可靠性能在 500-700K 范围。如果有关键信息必须让模型用到，放在开头或结尾。中间放置是赌博。

上下文工程的四个支柱

Context engineering 不是一种技术，是一种纪律——设计 AI 运行的整个信息环境的实践。它有四个支柱：

1. 知识检索 — 怎么找到并选择正确的信息。可以是 RAG、agentic search、直接读文件、MCP server 查询。方法不如结果重要：高信号、低噪音的上下文。

2. 记忆管理 — 怎么在多次对话和 session 之间持久化信息。CLAUDE.md 文件、自动记忆、skill 文档、压缩摘要。没有记忆管理，每个长 session 都会溺死在过时的上下文里。

3. 上下文编排 — 怎么在窗口内结构化和排序信息。文档放置（开头和结尾优于中间）、优先级排序、token 预算。目标是"找到最小可能的高信号 token 集，最大化你期望结果的概率"。

4. 质量监控 — 怎么衡量上下文是否有效。检索准确率、幻觉率、任务完成率、token 效率。大多数团队完全跳过这个支柱——然后当输出变差时指责模型。

Prompt engineering 优化单个查询。Context engineering 管理整个系统。输出质量的差异不是增量式的，是结构性的。

决策框架

  • 文档 < 500K token：跳过 RAG，直接加载。用上下文编排把关键信息放在边界处。
  • 文档 500K-1M token：谨慎使用，测试检索准确率，观察"迷失在中间"退化。
  • 文档 > 1M token：RAG 检索，然后把检索到的子集完整加载。混合方案。
  • 频繁更新的知识：RAG 做索引，长上下文做综合。
  • 多用户带访问控制：RAG 加权限过滤，长上下文没有等价方案。