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

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

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

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

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

如果答案在几份文档里，而这些文档整个加起来也塞得进模型的上下文窗口，那最简单的做法就是把它们全部放进提示词，让模型直接读。如今 Anthropic、OpenAI、Google 的旗舰模型，官方标注的上下文窗口都在百万 token 左右（Claude Opus 5 / Sonnet 5、GPT-6 Astra 约 105 万、Gemini 3.1 Pro 约 100 万），Meta 的开源模型 Llama 4 Scout 更标到 1000 万³，一份几百页的手册理论上可以整个装下，不必切块、不必检索。但标称值不等于实际可用：NVIDIA 的 RULER 测试发现，宣称支持 32K 以上上下文的模型里，只有一半能在 32K 长度上仍保持令人满意的表现。⁴ 而且就算模型稳得住，代价依然摆在那：每次提问都要把全部资料重读一遍，量一大就又慢又贵，资料越长，关键内容也越容易被忽略。

资料太多，塞不下 → RAG

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

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

有些任务卡住不是因为缺知识，而是没法一步到位——要先查这个、根据结果再决定查那个，甚至要真的动手操作外部系统。这时需要的是让模型自己规划、调用工具、循环推进，也就是第四章的 Agent。据 Gartner 预测¹，到 2026 年底将有四成企业应用带上面向特定任务的 Agent，而一年前这个比例还不到 5%。不过 Gartner 同时预测，到 2027 年底，将有超过四成的 Agent 项目会因为成本攀升、商业价值不明或风险控制不足而被取消²。所以，会不会用 Agent 是一回事，用得值不值又是另一回事。

缺的是"想清楚"的时间 → 推理模型

有些任务卡住，既不是缺资料，也不是要动手操作，而是需要一步步推演：多条件的规则判断、需要先拆解再验证的问题、复杂的计算。这类任务适合交给推理模型，它会先在内部推演一遍再作答，代价是更慢、更贵（见第三章 3.3）。推理模型和其他几种形态并不冲突，现在很多 Agent 的"大脑"本身就是推理模型。

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

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

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

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

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

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

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