前面五章把 RAG 讲透了，但需要提醒一句：RAG 只是 LLM 众多用法中的一种，专门解决"知识"这一类问题。真实世界里，把 LLM 用起来的方式还有好几种，各自对应不同的需求。本章梳理这几种形态，说明 RAG 在其中所处的位置及其适用边界。

区分这几种形态，可以从一个具体场景入手：当你拿到一个任务、准备交给模型时，先问一句——要完成它，模型缺的是什么？ 是缺知识，还是缺自主判断，还是缺某种能力？顺着这个问题往下分，下面五种形态各自对应一种情形。

任务不依赖外部知识 → 直接用提示词（Prompt）

翻译、改写、总结你贴给它的文本、按要求生成一段文字——这些任务要么模型本来就会，要么根本不涉及"知识"，只是纯粹的语言加工。这种情况不需要任何额外机制，把要求写清楚交给模型即可。这也是日常用量最大的一类。

资料就在手边、量也不大 → 长上下文（Long Context）

如果答案在几份文档里，而这些文档整个加起来也塞得进模型的上下文窗口，那最简单的做法就是把它们全部放进提示词，让模型直接读。2026 年前沿模型的上下文窗口已达百万 token 级别，一份几百页的手册可以整个装下，不必切块、不必检索。代价是每次提问都要把全部资料重读一遍，量一大就又慢又贵，而且资料越长、关键内容越容易被模型忽略。

资料太多，塞不下 → RAG

当知识库大到无法整个放进上下文（成千上万份文档、且不断更新），就必须先"查"出相关的几段再喂给模型——这正是前五章讲的 RAG。它的本质是：用检索把"太多"筛成"刚好"。所以 RAG 和长上下文其实是同一个知识问题的两种解法，分界线就在于资料量塞不塞得下。

缺的不是资料，是"下一步做什么"的判断 → Agent

有些任务卡住不是因为缺知识，而是没法一步到位——要先查这个、根据结果再决定查那个，甚至要真的动手操作外部系统。这时需要的是让模型自己规划、调用工具、循环推进，也就是第四章的 Agent。据 Gartner 预测¹，到 2026 年底将有四成企业应用带上面向特定任务的 Agent，而一年前这个比例还不到 5%。

缺的是能力或行为本身 → 微调（Fine-tuning）

前面几种都不改动模型。但如果问题是模型的行为不对——输出格式不稳定、语气不合要求、某类专门任务（如工单分类、特定 schema 的 SQL 生成）总做不好，那就要靠第二章讲的微调，把稳定的行为压进模型权重。记住那条分界：微调管形式，RAG 管事实——会变的知识用检索，稳定的行为用微调。

喂资料这条路的内部功夫：上下文工程

一旦选了要给模型喂资料的路线（长上下文、RAG，或 Agent 里带的检索），就会遇到一个新问题：上下文窗口空间有限，检索到的资料、对话历史、工具返回的结果、长期记忆，这些到底放哪些、怎么排列、何时压缩或丢弃，直接决定模型的表现。管理这件事的功夫叫上下文工程（Context Engineering）——它是"提示词工程"的升级版，关注的不再是"怎么写好一句指令"，而是"怎么组织模型一次能看到的全部信息"。随着系统越做越复杂，这一层正从事后的调优，变成架构设计阶段就要认真对待的核心决策。

小结：选哪种，取决于你缺什么

面对一个任务，逐项过一遍就能定下方案：缺知识就补资料（量小用长上下文，量大用 RAG），需要多步自主就上 Agent，行为不稳定就用微调。缺一样补一样，缺几样就叠几样——真实系统多半是这样按需拼出来的组合，而非单一形态。

整本书讲的这套 RAG，是这张地图上最常用、也最适合入门理解的一块，但它终究只是一块，更多时候是和别的形态搭配着一起用的。