RAG vs Context Engineering：我会在什么场景下选哪个

这两个概念到底在同一决策里分别扮演什么角色

我们在设计 AI 应用时，常常会遇到一个绕不开的矛盾：模型需要更多、更准的上下文，但上下文窗口不是免费的——它既增加延迟，又可能让模型在无关信息中丢失关键信号。RAG（Retrieval-Augmented Generation）和 Context Engineering（有时称为 Loop Engineering 或上下文工程）正是从两个不同方向解决这个矛盾的。

RAG 的核心动作是“从外部知识库中检索”，你通过向量相似度、关键词召回等方式，从文档库中精准捞出和用户查询最相关的片段，然后拼入 prompt 让模型使用。它解决的是“模型不知道的事情”的问题——即私有数据、最新动态或长尾知识。

Context Engineering 则完全不同，它关心的是“如何设计和维护对话的上下文结构”。当你使用多轮对话、工具调用（function calling）或 Agent 循环时，你需要决策：哪些历史轮次要保留、哪些工具输出要注入、角色系统提示该如何编排、上下文窗口满了该截断哪些内容。它解决的是“模型应当如何理解当前状态”的问题——即对话流、中间状态和工具调用历史。

两者的分工可以用一句话概括：RAG 拉入外部信息，Context Engineering 编排内部状态。在同一个产品中，它们往往协同工作：RAG 为模型补充领域知识，Context Engineering 确保模型不会在长对话中迷失身份或遗忘关键指令。

我会在什么真实场景下选 A 而不是 B

场景：开发一个内部文档问答 Bot

假设你在团队里接到一个需求：做一个能回答公司内部技术文档和流程文档的机器人。这个场景下，用户问题大多是一次性的（“Server 部署流程是什么？”），对话轮次通常很短（1-3 轮），不需要记忆历史上下文。这里的核心矛盾是：模型不知道公司内部文档内容。

你应该先选 RAG。 原因很直接：Context Engineering 对你几乎没有帮助——单轮问答不需要精心编排上下文结构，而 RAG 解决了知识缺失这个主要矛盾。你可以搭建一个简单的检索链路：将内部文档切块后向量化存储，用户提问时检索 Top-K 相关块，拼入 prompt 后交给模型回答。你甚至不需要额外维护对话状态。

场景：开发一个持续多轮的项目管理 Agent

现在换一个需求：做一个 Agent，让它帮助团队追踪项目任务状态、自动分配任务、处理多轮澄清和确认。用户可能先问“当前 Sprint 还有哪些未完成的任务”，Agent 返回 JSON 列表。用户接着追问“把最紧急的两个分配给我”，Agent 调用创建函数并返回确认。用户再问“那上个月延期的那几个谁负责？”——此时 Agent 需要知道前面提到的“最紧急的任务”是指当前 Sprint 内的。

你应该先选 Context Engineering。 RAG 解决不了“模型记不住三分钟前自己输出的 JSON 结构”的问题。你需要设计一个上下文管理方案：每次函数调用后，将执行结果以结构化摘要的形式写回上下文；当上下文接近窗口上限时，舍弃最旧的、不再相关的中继轮次；同时维护一个“关键状态”固定区域，比如当前项目 ID、用户角色等不变信息。这是典型的 Context Engineering 工作。

最常见的错配方式与代价

我见过最典型的错配是：一个只有 3 轮对话的简单问答产品，团队却在花大精力设计上下文窗口压栈、截断策略、状态压缩。代价是开发周期从 2 周拉长到 6 周，而用户体验几乎没提升。反过来，在一个需要 20 轮以上对话的复杂 Agent 场景里，团队只在 RAG 上堆向量库和重排序模型，却忽视上下文丢失导致的工具调用失败，结果 Agent 经常答非所问、重复操作，用户满意度极低。

另一个常见误区是“RAG 和 Context Engineering 能互相替代”。有人以为只要把历史对话全部丢进 RAG 索引就能实现记忆，但 RAG 的检索粒度是片段级别的，它无法保证模型重建连贯的上下文状态。例如，用户上一轮说“把任务指派给张三”，这一轮问“他完成了吗”，如果模型只检索到“把任务指派给张三”这个片段，它无法知道“他”指代谁。Context Engineering 通过显式维护指代映射（比如在上下文中存一个 {action: "assign", user: "张三", task: "..."} 的结构）来解决这类问题。

如果团队现在只能先落一个，应该先做哪一个

核心判断标准是：知识缺口 + 对话轮次。

如果用户的典型场景是单轮或短对话（≤5轮），且问题涉及大量私有或动态知识，先做 RAG。因为此时 Context Engineering 能带来的边际收益很低——简单的 prompt 指令足以维持上下文。你可以在后续迭代中再补充上下文历史管理，甚至一开始就用截断“最后 N 轮”的粗暴方法。

如果用户的典型场景是多轮复杂任务（执行 >5 轮的工具调用或状态流转），且知识不是主要矛盾（模型已有的训练数据已覆盖），先做 Context Engineering。因为上下文丢失会直接导致 Agent 无法完成目标任务，这是致命缺陷。而知识不足可以用临时方案弥补，比如让模型在回答中说“我找不到相关信息，请提供更多上下文”。

一个实用的经验法则：当你发现模型错误大多是“忘记之前说了什么”导致的，优先 Context Engineering；当错误大多是“不知道这个知识”导致的，优先 RAG。

做出选择后下一步要补什么能力

如果你先做了 RAG，下一步要关注：

• 分块策略优化：文档切块大小、重叠窗口、元数据编排直接影响检索质量。
• 检索质量监控：引入重排序模型（Cohere Rerank、BGE Reranker）或混合检索（BM25 + 向量）来降低噪声。
• 上下文注入设计：检索到的片段如何自然插入 prompt，既不能打断角色指令，也不能被模型忽略。

如果你先做了 Context Engineering，下一步要关注：

• 状态持久化与对齐：如何将对话中的关键状态（用户身份、任务状态、上下文指纹）持久化，并在多轮中保持对齐。
• 上下文压缩与摘要：在上下文窗口耗尽前，自动对历史内容进行摘要压缩，保留关键信息。
• 工具调用的反馈循环：每个工具调用后，将执行结果结构化地注入上下文，供后续决策使用。

两者最终都会走向融合：一个成熟的 AI 产品需要 RAG 持续补充知识，也需要 Context Engineering 维持状态。但初期取舍决定了团队的投入产出比，选错方向可能浪费数月时间。

具体的决策场景比“哪个更好”更值得讨论

如果你刚接触这个话题，不妨梳理一下自己当前想做的产品：它需要模型回答它不知道的事情吗？用户会连续问 10 轮以上吗？把这两个维度画成一张决策矩阵，大概率能快速定位当前最应该发力的方向。不要因为 RAG 是热门词就先上 RAG，也不要因为 Agent 大火就觉得 Context Engineering 是万能药。两者各有边界，清晰定义问题才能选出正确的工具。