Agent 与 RAG 有什么区别和联系？

核心回答

RAG解决“回答时从哪里取得依据”，Agent解决“围绕目标下一步做什么”。 RAG把外部检索结果与模型生成结合起来；Agent根据当前状态和观察选择动作、调用工具并推进任务。它们处在不同维度，可以独立使用，也可以组合。

不能把RAG简单叫作“有记忆的知识库”：知识库和检索只是其中一部分，检索结果如何进入生成、回答是否受证据支持也很重要。也不能只要调用一次API就宣称系统具备完整的自主任务能力。

职责与流程有什么不同

典型两步RAG先检索相关资料，再结合资料回答。离线可以做清洗、切分、索引；在线做查询、过滤、排序和上下文组装。它适合制度、产品文档等知识问答，不需要让模型自主决定整个执行路线。

Agent通常维护任务状态，在“判断 → 执行动作 → 观察结果”之间迭代。工具可以是检索，也可以是计算、代码执行或业务接口。下一步可能随结果改变：查不到材料就换查询，发现条件不足就补充信息，满足目标后停止。

因此，RAG的重点是检索覆盖、证据质量与回答忠实度；Agent还要关心动作正确性、任务完成、执行恢复、成本与权限范围。RAG本身并不等于自动长期记忆，Agent也不一定需要向量数据库。

二者如何组合

例如用户问“退款期限是多少”，检索当前政策并给出出处，固定RAG链路通常足够。若用户要求“查这笔订单是否能退款，并发起申请”，系统还需要识别订单、查询状态、结合政策判断、调用申请接口并验证结果。RAG可以提供政策依据，Agent负责动态组织查询与操作。

在Agentic RAG中，检索成为模型可选择的工具：模型决定何时查、查什么、是否改写问题及何时结束。它适合复杂多跳研究或信息不足时反复补查；代价是调用次数和时延不稳定，还可能重复检索或提前停止。

也可以用固定外层流程约束关键步骤，在某个节点内部允许Agent探索。混合架构通常比“全固定”或“全部自主”更贴近实际业务。

如何选型与评估

问题主要是缺少私有或最新资料，就先优化RAG；路线明确的多步业务用工作流；确实需要根据中间结果调整步骤，再引入Agent。不要为了名字升级而增加循环与多Agent。

评RAG要拆开看资料有没有召回、证据是否足够、回答是否忠实；评Agent还要检查工具、参数、最终环境状态和恢复能力。二者结合时，轨迹能帮助分辨是“没找到政策”“理解错政策”还是“操作接口用错了”。技术亮点是让知识供给与行动控制分别承担职责，并在需要时通过工具连接。

对应教程

参考资料