为什么又重新聊这几个概念？

最近在系统性学习 AI Agent 的构建和落地，喂给了 GPT 一批资料，让它给我整理了一份详细的 roadmap，第一步便是应该先弄清楚这几个概念，GPT 建议我输出一份文档，于是便有了这个文章（但其实这篇文章也是我列好大纲让 AI 写的）。

一、为什么要区分这四个概念

学 AI Agent 的第一步不是写代码，而是搞清楚边界。很多项目失败不是因为技术不行，而是用错了模式——该用 Workflow 的地方强上 Agent，该用 Agent 的地方只做了 RAG。理解这四个概念的区别和关系，是后续所有工程决策的基础。

二、一句话定义

  • Chatbot：基于 LLM 的对话系统，用户问一句答一句，不主动行动，不调用外部工具。
  • Workflow：预定义的固定流程，每一步做什么、调什么工具、输出什么格式都是开发者写死的。
  • RAG（Retrieval-Augmented Generation）：在生成回答前，先从外部知识库检索相关内容注入上下文，让模型基于检索结果回答。
  • Agent：具备自主决策循环的系统，能根据当前状态动态选择下一步行动，包括调用工具、检索信息、追问用户，直到任务完成。

三、用一个场景看区别

任务：”帮我了解 LangGraph 适不适合我们的项目”

系统 它会怎么做 问题在哪
Chatbot 根据训练数据介绍 LangGraph 的基本信息，说完就结束 不了解”你的项目”，信息可能过时，不会主动补充
Workflow 按预设管道：搜索文档 → 提取特性 → 生成表格 如果搜索结果差，不会回头换策略，带着差结果继续跑
RAG 从知识库检索 LangGraph 相关段落，基于检索结果回答 知识库没有的内容就答不上，不会主动获取新信息
Agent 先分析问题 → 搜索文档 → 发现不够 → 搜替代方案对比 → 追问项目需求 → 给出建议 最灵活，但行为不完全可预测，调试成本高

四、六个维度深度对比

4.1 决策权归属

这是最根本的区别。

  • Chatbot / RAG：决策权在用户手里，用户不问它就不动。
  • Workflow：决策权在开发者手里，流程提前设计好。
  • Agent：决策权在系统自身，根据当前状态自主判断下一步。

4.2 处理意外的能力

  • Workflow：遇到意外就出问题，只认识预设路径。
  • Chatbot：遇到意外只能说”我不确定”。
  • RAG：知识库里没有相关内容时，检索结果变成噪声，回答质量断崖式下跌。
  • Agent：可以换策略——搜不到就换关键词，工具报错就试另一个，信息不够就主动追问。

4.3 工具使用方式

  • Chatbot：通常不调用工具。
  • Workflow：按预设顺序调用固定工具。
  • RAG：只调用”检索”这一种工具。
  • Agent：动态选择调用什么工具、什么时候调、调几次，可以组合多个工具。

4.4 上下文来源

  • Chatbot：训练数据 + 当前对话。
  • RAG：训练数据 + 检索到的外部文档片段。
  • Workflow：管道中上一步传递的数据。
  • Agent：综合所有来源（训练知识、检索结果、工具返回值、对话历史、长期记忆），并自己决定什么时候需要获取更多上下文。

4.5 可控性与风险

维度 Chatbot Workflow RAG Agent
可预测性 中 高 中 低
调试难度 低 低 中 高
失败模式 幻觉、过时 流程卡死 召回不准、引用错位 决策失误、工具误用、循环不收敛
适合生产环境 简单场景可直接上 最稳、最适合 需要持续优化检索质量 需要 guardrails + eval 才能上线

4.6 适用场景

用 Chatbot 就够： FAQ、简单信息查询、闲聊。任务单一，不需要外部数据和多步推理。

用 Workflow 更好： 流程确定、步骤固定。例如定时报表生成、工单自动分类、数据管道处理。路径清晰就别用 Agent，Workflow 更稳更快。

用 RAG 更好： 基于特定知识库的问答，且问答模式相对固定。例如企业内部文档问答、产品手册查询、客服知识库。

必须用 Agent： 任务路径不确定，需要多步推理和动态决策。例如线上问题诊断、技术方案调研、需要跨多个数据源才能完成的复杂任务。

五、它们不是互斥的，而是可嵌套的

一个常见误区是把这四个概念当成互斥的选项。实际上它们是不同层次的能力，可以互相嵌套：

1
2
3
4
5
Agent（最上层编排者）
├── 调用 RAG 模块获取知识
├── 调用固定 Workflow 处理子任务
├── 底层对话能力 = Chatbot
└── 通过工具与外部世界交互

一个成熟的 Agent 系统的运行过程可能是：用户提问 → Agent 判断需要查资料 → 调用 RAG 检索 → 发现不够 → 调用搜索工具补充 → 按 Workflow 格式整理结果 → 用对话能力生成自然语言回复。

六、关键判断：什么时候该用 Agent

在决定是否使用 Agent 之前，先问三个问题：

  1. 任务路径是否确定？ 如果每次执行的步骤都一样，用 Workflow。
  2. 是否需要动态使用多个工具？ 如果只需要检索，RAG 就够。
  3. 是否需要系统自主做出决策？ 如果人类可以轻松预定义所有分支，不需要 Agent。

一个简单的原则：能用简单方案解决的，就不要用复杂方案。 Agent 的灵活性是有代价的——更难调试、更难预测、更难保证质量。只有当任务的复杂度确实需要自主决策时，Agent 才是正确的选择。

七、三个核心认知

  1. Agent 的”行动能力”来自工具。 LLM 只能生成文本，是工具让它能搜索、能调 API、能读写文件。工具设计的质量直接决定 Agent 的能力上限。

  2. 光有 LLM 不等于有 Agent。 LLM 是被动的输入-输出系统。Agent 需要一个持续运行的控制循环：感知 → 决策 → 行动 → 观察结果 → 再决策。LLM 是 Agent 的一个组件，不是 Agent 本身。

  3. 复杂度是有成本的。 不是所有问题都需要 Agent。选择 Chatbot / Workflow / RAG / Agent 的依据不是”哪个更高级”，而是”任务的不确定性有多高”。

附：引用