简介：本文从大语言模型应用演进的角度，系统对比 Prompt 工程、RAG 与 Agent 三类核心 AI 概念。通过一个“论文助手”的构建过程，逐一说明它们分别解决什么问题、在架构上如何配合、能力边界在哪里，以及在实际项目中应如何选择与组合。阅读本文可以帮助你不再孤立地记忆术语，而是建立一套可迁移的判断框架，理解何时优化提示词、何时引入外部检索、何时将任务交给自主代理执行。
想了解大语言模型应用的人，几乎都会遇到一串名词：Prompt、Prompt Engineering、RAG、Agent、MCP、Skill、Harness 等。如果逐个查询定义，往往会发现解释之间互相引用，越查越多，最后仍然难以判断它们在真实项目中的位置。
这种混淆的根源在于，这些概念并不是彼此独立的功能模块，而是在 AI 应用能力不断扩展过程中，逐层出现的解决方案。更有效的理解方式是沿着一条需求链条去看：人们先让模型能回答问题，然后希望它参考最新资料，接着希望它执行操作，最后希望它独立推进复杂任务。每一步新需求都暴露出上一阶段的能力限制，于是催生新的方法和组件。
本文以一个大语言模型驱动的“论文助手”为主线，将 Prompt 工程、RAG 和 Agent 放在同一个应用场景中对比。文章会先明确三者的基本定义与要解决的问题，再从架构位置、数据依赖、控制方式、适用场景等维度展开分析，最后给出选型与组合建议。
在进入详细对比之前，需要先建立三者的最小认知框架。
Prompt 工程关注的是“如何让模型正确理解任务”。它通过设计输入文本的结构、措辞、示例和约束条件，引导模型产出符合预期的结果。Prompt 工程不改变模型权重，也不引入外部系统，是成本最低、迭代最快的能力优化方式。
RAG，即检索增强生成，关注的是“如何让模型基于外部知识回答”。它在模型生成之前增加一个检索步骤，从文档库、数据库或知识库中找到相关材料，再把这些材料与用户问题一起交给模型。RAG 解决的核心问题是模型训练知识过时、专业领域覆盖不足以及容易产生幻觉。
Agent关注的是“如何让模型完成多步骤任务”。它把大语言模型作为推理和规划中枢，让模型自主决定调用哪些工具、按什么顺序执行、如何判断任务是否完成。Agent 不再只是“输入文本、输出文本”的单轮交互，而是具备目标管理、工具调用和结果校验能力的执行单元。
三者的关系可以用一句话概括：Prompt 工程优化单次交互的质量，RAG 为单次交互补充外部知识，Agent 则把多次交互组织成一条可执行的任务链。
为了更具体地理解差异，我们沿着一个论文助手的构建过程逐步推进。
最初，我们有一个基础大语言模型。它通过海量文本训练，掌握了语言规律和大量事实性知识。但“能生成文字”与“能按用户意图完成任务”之间有明显距离。如果直接输入“解释这篇摘要”，模型可能输出一段结构松散、缺乏重点的文字，有时还会自行补充摘要中不存在的信息。
此时需要的是把要求说清楚。例如：
请用中文解释这篇摘要，分别说明研究问题、研究方法和主要发现。摘要中没有提供的信息，请标注“未说明”。
这段输入就是 Prompt。它的质量直接影响输出结果的结构完整性和信息准确性。Prompt 工程则是围绕这类输入进行系统化设计、测试和迭代的方法集合。它可以包括：使用角色设定、提供少样本示例、设置输出格式、加入思维链引导、限定不可回答的范围等。
与此同时，模型训练侧也在改进。指令微调让模型学习“遵循指令”的行为模式，基于人类反馈的强化学习则让模型的回答更符合人的偏好。这些训练手段与 Prompt 工程是互补的：前者改善模型的底层行为倾向，后者在推理阶段针对具体任务做精细控制。
这一阶段论文助手的能力表现为：它已经能听懂要求，按指定格式输出解释。但新的问题出现了：它的回答依据来自训练时学到的参数化知识，无法覆盖最新文献，也无法核验具体论文的真实性。
当用户问“最近关于睡眠与记忆的研究有哪些新发现”时，仅依赖模型内部知识可能出现两种情况：一是信息陈旧，不知道近期发表的研究；二是生成看似合理但实际不存在的论文标题或引用，也就是常说的幻觉。
直接的应对方式是改变信息流——让模型先查找资料，再基于资料回答。这就是 RAG 的基本结构：系统先根据用户问题检索相关文档片段，把这些片段与问题一起组成新的输入，交给模型生成回答。模型的任务从“凭记忆回答”转变为“基于给定材料进行归纳、提取和重组”。
RAG 的典型流程可以描述为：
用户提问↓检索器在外部知识库中查找相关文档↓提取 Top-K 个相关片段↓将片段与用户问题拼接为增强后的 Prompt↓大语言模型生成回答
RAG 的价值不在于“检索”或“生成”本身，而在于它把模型的语言理解能力与外部可更新、可验证的知识源连接起来。论文助手接入文献检索后，可以引用真实存在的论文，可以覆盖训练之后新发表的研究，也可以对不同来源的信息进行交叉比对。
但 RAG 也有边界。它解决的是“知道什么”的问题，不解决“能做什么”的问题。当用户希望论文助手不只是解释摘要，而是帮忙生成文献综述文件、整理参考文献格式、发送给协作者时，单次生成已经不够用了。
一个更完整的需求可能是这样的：“帮我找五篇关于睡眠记忆巩固的近期论文，总结它们的方法差异，生成一份综述文档，并给出参考文献列表。”
这个任务包含多个子任务：检索文献、筛选相关论文、阅读摘要、提取方法信息、比较差异、撰写综述、格式化参考文献、生成文件。Prompt 工程可以帮助设计每一步的输入，RAG 可以为每一步提供文献内容，但谁来编排这些步骤的执行顺序？谁来判断某一步失败后是否需要重试？谁来决定调用哪个工具？
这就是 Agent 要解决的问题。Agent 将大语言模型从“单次问答器”提升为“任务编排器”。它接收一个目标，自主规划步骤，调用检索工具、文件写入工具、格式转换工具等，检查中间结果，并根据反馈调整后续动作。模型在其中扮演的角色不是一次性写出最终答案，而是持续进行“下一步该做什么”的决策。
一个简化 Agent 循环可以表示为：
初始化：接收用户目标↓规划：模型判断需要执行哪些步骤↓行动：调用工具，如检索、读写文件、执行代码↓观察：获取工具返回结果↓评估：判断目标是否完成↓未完成则回到规划步骤，已完成则输出最终结果
论文助手一旦变成 Agent，它就不再只是被动的回答器，而是一个可以持续推进任务的执行器。用户可以给它一个模糊目标，由它自己拆解、执行和交付结果。
为了更清晰地把握三者的区别，可以从架构位置、数据依赖、控制方式、能力边界和典型失败模式五个维度进行对比。
Prompt 工程位于模型输入层。它不添加新的系统组件，只改变输入文本的内容和结构。RAG 位于模型之前，增加了一条外部检索通路，形成“检索器 + 生成器”的链路。Agent 则位于更高的编排层，它包裹模型和工具，管理多轮交互和任务状态。
从系统复杂度看，Prompt 工程最低，几乎不需要额外基础设施。RAG 需要维护外部知识库、向量索引和检索服务。Agent 除了工具和知识库之外，还需要任务状态管理、工具调用协议和错误恢复机制。
Prompt 工程主要依赖模型已有的参数化知识，以及用户在输入中提供的信息。它的知识边界就是“模型训练时学到了什么”。RAG 的核心数据来自外部知识库，可以动态更新，不依赖重新训练模型。Agent 则同时依赖模型知识、外部知识库和工具返回的实时结果，数据来源最为多样。
这意味着：当知识更新频率高、专业领域强或需要引用具体文档时，RAG 比单纯优化 Prompt 更可靠；当任务需要执行操作、获取实时状态或跨系统协调时，Agent 的必要性就会上升。
Prompt 工程的控制方式是“静态引导”。设计者通过提示词模板、示例和规则预先定义模型行为边界。RAG 的控制方式是“证据约束”。系统用检索到的材料限制模型的生成范围，降低自由发挥空间。Agent 的控制方式是“目标驱动 + 自主规划”。模型被赋予选择工具和安排步骤的权力，控制从设计者手中部分转移到了模型本身。
这一差异也带来不同的风险特征：Prompt 工程的风险在于引导不足，模型输出偏离预期；RAG 的风险在于检索质量不佳，导致模型被无关材料干扰；Agent 的风险在于自主规划失控，可能在错误路径上消耗大量资源。
三者回答的问题是不同层级的：
| 概念 | 解决的核心问题 | 典型问题形式 |
|---|---|---|
| Prompt 工程 | 如何让模型准确理解任务并按要求输出 | “怎样表达才能让模型输出我需要的格式？” |
| RAG | 如何让模型基于最新、可验证的外部知识回答 | “怎样让模型引用真实存在的最新文献？” |
| Agent | 如何让模型自主完成多步骤、多工具的任务 | “怎样让模型独立从检索到生成完整交付？” |
三者不是互斥关系。一个成熟的论文助手应用中，Agent 在规划任务时会使用 Prompt 工程来设计每个子任务的输入，也会调用 RAG 来获取文献内容。Prompt 工程优化“单步质量”，RAG 提供“知识支撑”，Agent 解决“流程编排”。
Prompt 工程失败通常表现为输出格式错误、遗漏要求、理解偏差。这类失败容易在测试阶段被发现，修复成本低。
RAG 失败通常表现为检索不到相关文档、检索到无关文档但模型仍然使用、或者模型忽略检索材料继续凭记忆生成。这类失败更隐蔽，因为输出看起来可能仍然通顺，只是依据不可靠。
Agent 失败通常表现为任务规划不合理、工具调用错误、循环陷入重复步骤、提前终止或无限执行。这类失败的影响范围更大，因为 Agent 可能消耗大量资源后才暴露问题。
在实际系统中，三种方法通常同时存在。以下是一个论文助手处理复杂请求时的简化流程。
用户请求：“总结近三年关于睡眠记忆巩固的研究进展，生成一份综述初稿。”
Agent 接收目标后，可能将其拆解为多个子任务：
子任务 1：检索近三年相关文献子任务 2：筛选高相关度论文子任务 3：逐篇提取研究问题、方法、主要发现子任务 4：按主题归纳方法差异子任务 5：生成综述初稿文件子任务 6：检查格式并输出
在子任务 1 和 2 中，Agent 调用检索工具，此时涉及 RAG 的知识获取逻辑。在子任务 3 和 4 中，Agent 需要为每一篇论文设计合适的提取 Prompt，用明确的字段和格式约束模型输出，这就是 Prompt 工程的应用。在子任务 5 中，Agent 调用文件写入工具，将生成的内容保存为文档。在子任务 6 中，Agent 检查输出是否包含所有必需部分，如有遗漏则触发补充生成。
这个例子说明：Prompt 工程是微观层的方法，作用于每一次模型调用；RAG 是数据层的增强，为模型提供外部知识；Agent 是宏观层的编排，决定整个任务如何推进。三者属于不同层面，不存在“用哪个替代哪个”的问题，而是“在哪个环节使用哪种方法”的问题。
如果项目团队面临的问题是“是否要引入 RAG”或“是否需要构建 Agent”，可以从以下几个条件出发做判断。
当任务相对固定、输出格式明确、模型已有足够知识时，Prompt 工程是性价比最高的选择。例如，让模型按固定模板从摘要中提取结构化字段，或让模型按指定语气改写文本。此时引入 RAG 或 Agent 会增加不必要的系统复杂度。
Prompt 工程也适合作为所有 AI 应用的基础能力。即使后续引入 RAG 和 Agent，每个子任务仍然需要精心设计的提示词来保证输出质量。
当出现以下情况时，应优先考虑引入 RAG：
需要提醒的是，RAG 不是简单“加一个检索步骤”。检索质量、片段切分策略、排序方式、提示词中材料的使用方式，都会影响最终效果。如果知识库混乱、文档质量差，RAG 也可能引入更多噪声。
当任务满足以下条件时，Agent 的价值才会体现出来：
如果任务本身只是一次问答或一次生成，构建 Agent 反而会过度设计。Agent 的引入会带来更高的系统复杂度、更多的失败模式和更难的调试体验。在单步任务上，Prompt 工程加 RAG 往往更直接、更可控。
如果团队已经在使用 Prompt 工程，计划引入 RAG 或 Agent，需要关注以下几个通用问题。
知识库建设成本：RAG 的效果高度依赖外部知识库的质量。文档是否结构化、片段切分是否合理、元数据是否完整，都会影响检索结果。这些工作往往比接入检索组件本身更耗时。
工具调用稳定性：Agent 的工具调用可能因为参数传递错误、工具返回格式不符合预期、网络抖动等原因失败。需要在设计中加入超时、重试、降级和人工介入机制，不能让 Agent 在无人监控下无限执行。
安全与权限边界：Agent 拥有调用工具的能力，意味着它可能执行写操作、访问敏感数据或触发外部系统变更。需要明确工具白名单、权限范围和审计日志，避免模型自主决策越过安全边界。
可观测性需求：相比 Prompt 工程和 RAG，Agent 的执行链路更长，问题定位更困难。建议在关键节点记录模型决策、工具调用参数和返回结果，便于事后回溯。
成本控制：Agent 的多次模型调用和工具执行会放大资源消耗。设计时应考虑是否可以对简单子任务使用更轻量的模型，或在满足要求的前提下限制最大执行步数。
Prompt 工程、RAG 和 Agent 是三个层级不同、目标不同的概念。Prompt 工程解决“模型如何理解并执行单次任务”的问题，是 AI 应用的微观基础。RAG 解决“模型如何获取和利用外部知识”的问题，是连接模型与可更新知识源的关键桥梁。Agent 解决“模型如何自主完成多步骤复杂任务”的问题，是让模型从回答器走向执行器的编排框架。
三者的区分不在于谁更先进，而在于它们各自回应了 AI 应用演进中的不同需求。理解三者的差异之后，就不会再把“要不要用 RAG”和“要不要做 Prompt 优化”当成二选一的问题。更务实的思考方式是：当前任务在哪个层面出现了瓶颈，就在哪个层面引入相应的方法，同时控制好新方法带来的复杂度。