Q: RAG 和 Agent 有什么区别？什么时候用哪个？

一句话答案

RAG 解决”让 LLM 访问外部知识”的问题，Agent 解决”让 LLM 自主决策和行动”的问题。RAG 是知识检索系统，Agent 是任务执行系统。两者不是替代关系，而是互补关系——RAG 可以作为 Agent 的一个工具。

核心对比

维度	RAG	Agent
解决的问题	知识不足（LLM 不知道）	能力不足（LLM 做不到）
工作方式	检索 → 生成（单轮）	规划 → 执行 → 观察 → 调整（多轮）
核心能力	检索 + 生成	规划 + 工具调用 + 记忆
系统复杂度	低～中	中～高
延迟	低（单次检索 + 生成）	高（多轮交互）
可控性	高（流程确定）	中（LLM 自主决策）
适用场景	知识问答、信息检索	多步推理、复杂任务

架构对比

RAG 架构

用户查询
  ↓
查询理解（改写、路由）
  ↓
检索（向量检索 + 关键词检索）
  ↓
重排序（Reranker）
  ↓
上下文组装
  ↓
LLM 生成
  ↓
答案

Agent 架构

用户目标
  ↓
规划（Planning）
  ↓
工具选择（Tool Selection）
  ↓
执行（Execution）
  ↓
观察（Observation）
  ↓
判断是否完成 ──否──→ 回到规划
  ↓是
最终答案

RAG + Agent 结合架构

用户目标
  ↓
Agent 规划
  ├── 调用 RAG 检索知识
  ├── 调用 API 获取数据
  ├── 调用代码执行器
  └── 调用其他工具
  ↓
综合所有结果
  ↓
判断是否完成 ──否──→ 继续规划
  ↓是
最终答案

决策树：什么时候用 RAG，什么时候用 Agent？

你的场景需要什么？
│
├─ 需要访问外部知识（文档、数据库、API）
│   │
│   ├─ 只需要检索和回答（单步）
│   │   └─ ✅ 用 RAG
│   │
│   └─ 需要检索 + 其他操作（多步）
│       └─ ✅ 用 Agent（RAG 作为工具）
│
├─ 需要调用外部工具（API、代码执行、文件操作）
│   └─ ✅ 用 Agent
│
├─ 需要多步推理和决策
│   └─ ✅ 用 Agent
│
└─ 只是简单对话，不需要外部信息
    └─ ✅ 直接用 LLM

典型场景对比

场景	用 RAG 还是 Agent	理由
”红烧肉怎么做？“	RAG	单步知识问答
”Python 的 sorted 怎么用？“	RAG	单步知识问答
”帮我做一顿完整的晚餐”	Agent	需要多步规划（选菜、食材、步骤）
“查一下今天的天气，推荐适合的菜”	Agent	需要调用天气 API
”分析这个 CSV 文件，生成报告”	Agent	需要代码执行
”根据我的冰箱食材推荐菜谱”	Agent + RAG	需要理解食材 + 检索菜谱
”这个项目的代码有什么问题？“	Agent + RAG	需要读代码 + 检索最佳实践

面试追问

[!question] 追问详析

Q1: RAG 和 Agent 能结合使用吗？

可以，而且这是最常见的生产架构。Agent 作为顶层编排器，RAG 作为其中一个工具。例如用户问”帮我做一顿晚餐”，Agent 会：

1. 调用 RAG 检索适合的菜谱
2. 调用库存 API 检查食材
3. 调用日历 API 查看时间
4. 综合所有信息给出建议

RAG 在这里解决”知识检索”问题，Agent 解决”任务编排”问题。

Q2: Agent 的核心组件有哪些？

Agent 有三个核心组件：

1. 规划（Planning）：将复杂任务拆解为多个步骤，决定执行顺序
2. 工具调用（Tool Use）：调用外部 API、数据库、代码执行器等
3. 记忆（Memory）：维护短期（当前对话）和长期（历史交互）记忆

其中工具调用是最关键的能力——没有工具，Agent 就只是一个会规划的 LLM，无法执行实际操作。

Q3: 为什么说 Agent 不能解决 RAG 的质量问题？

因为 Agent 是在 RAG 之上的”决策层”，它的决策质量依赖于底层工具的输出质量。如果 RAG 检索到的内容不相关，Agent 只会基于错误信息做出错误决策，甚至比纯 RAG 更差（因为 Agent 可能会放大错误）。

类比：如果一个人记性不好（RAG 质量差），给他更多自主权（Agent）只会让他犯更多错误。应该先治好记性（优化 RAG），再考虑给他更多自主权。

避坑

[!warning] 常见坑点

坑1：所有场景都用 Agent

# ❌ 错误：单步问答也用 Agent
agent = Agent(tools=[rag_tool, search_tool, ...])
result = agent.run("红烧肉怎么做？")  # 太慢，太复杂

# ✅ 正确：单步问答直接用 RAG
rag = RAGSystem()
result = rag.query("红烧肉怎么做？")  # 快速，直接

原因：Agent 的规划和工具调用会增加 2-5 秒延迟，对于单步问答这是不必要的开销。

坑2：Agent 没有兜底机制

# ❌ 错误：Agent 没有最大步数限制
agent = Agent(tools=[...], max_steps=None)  # 可能无限循环

# ✅ 正确：设置最大步数和超时
agent = Agent(tools=[...], max_steps=10, timeout=60)

原因：LLM 的自主决策可能陷入循环或偏离目标，必须有兜底机制。

坑3：认为 Agent 能解决所有问题

Agent 的能力边界：

• ✅ 有明确工具可调用的任务
• ✅ 可以拆解为明确步骤的任务
• ❌ 需要创造性思维的任务（没有标准答案）
• ❌ 需要实时感知环境的任务（没有对应工具）
• ❌ 需要精确计算的任务（LLM 计算不可靠）

相关笔记

• [[Q-RAG系统优化方向全解析]]
• [[Q-什么时候需要Agent]]
• [[Q-Query-Routing和Skills机制对比]]
• [[Function Calling 深度解析]]
• [[路由在RAG与Agent系统中的作用]]