第1讲：Agent 到底是什么——Chatbot / RAG / Agent / Multi-Agent 的边界与选型

一、先给一张全景图很多人把能联网搜索叫 Agent把能调用计算器叫 Agent把两个 LLM 互相聊天也叫 Agent。这些说法都不算错但工程化落地时必须分清层级。复杂度 / 自主性 / 风险 ▲ │ ┌────────────────┼────────────────┐ │ Multi-Agent System │ ← 多个 Agent 分工协作 │ (Orchestrator Workers) │ ├────────────────┼────────────────┤ │ Agent │ ← 自主决策 工具调用 记忆 │ (ReAct / Plan-Execute) │ ├────────────────┼────────────────┤ │ RAG Tool Call │ ← 检索增强 单次工具调用 │ (无自主规划被动响应) │ ├────────────────┼────────────────┤ │ RAG │ ← 检索 生成无工具 ├────────────────┼────────────────┤ │ Chatbot │ ← 纯对话无外部依赖 └────────────────┴────────────────┘核心区别不在于能不能调接口而在于谁决定什么时候调什么接口。二、逐层拆解2.1 Chatbot纯对话定义​ 只有 LLM Prompt不访问任何外部系统。用户输入 → LLM → 文本输出特征无检索、无工具、无记忆除了对话窗口里的上下文输出完全靠模型参数内化知识不可控幻觉、知识截止于训练日期适用场景闲聊、创意写作、头脑风暴原型验证、Demo对事实准确性要求极低的场景工程复杂度​ ★☆☆☆☆2.2 RAG检索增强生成定义​ LLM 外部知识库检索输出前先查资料。用户输入 → Query理解 → 检索(向量/BM25) → 拼接上下文 → LLM → 带引用的输出特征知识来源可控企业文档、数据库可追溯、可更新换索引就是换知识LLM 只负责阅读理解和组织语言不负责回忆适用场景企业知识库问答、客服、文档助手需要引用来源的场景合规、审计知识频繁更新的场景工程复杂度​ ★★☆☆☆你已经在前面的第8讲做了完整的生产化实现。2.3 RAG Tool Call工具增强定义​ RAG 单次工具调用能力。模型可以请求调用某个函数但不做多步规划。用户输入 → LLM(判断是否需要工具) → 调用工具 → 结果回填 → LLM 最终输出 ↑ 一次性不循环特征模型可以调用搜索、计算器、数据库查询、API但每一步都由用户输入触发模型不会主动下一步我要查另一个东西典型的 Function Calling 模式适用场景需要实时数据的问答天气、股价、库存需要精确计算的场景数学、汇率转换简单的表单填写、数据查询工程复杂度​ ★★★☆☆2.4 Agent自主智能体定义​ LLM 工具 记忆 自主规划与循环执行。用户输入 ↓ LLM(规划: 需要几步? 用什么工具?) ↓ 调用工具1 → 观察结果 ↓ LLM(反思: 结果够了吗? 还需要什么?) ↓ 调用工具2 → 观察结果 ↓ LLM(判断: 任务完成) → 最终输出特征循环执行模型自己决定下一步做什么不需要用户每一步都输入动态规划任务拆解、子目标管理记忆记住中间结果、失败经验、用户偏好自我纠错工具调用失败后可以重试或用替代方案典型实现模式模式核心思想代表ReAct思考→行动→观察→再思考LangChain AgentPlan-Execute先制定完整计划再逐步执行BabyAGIReflexion执行后自我批评改进再试Reflexion AgentToolformer模型自己学习何时调用工具论文实现适用场景复杂多步任务调研报告、数据分析、代码生成调试需要与环境交互的任务操作数据库、发邮件、改配置不确定性的任务需要探索、试错工程复杂度​ ★★★★☆2.5 Multi-Agent System多智能体系统定义​ 多个 Agent 分工协作每个 Agent 有独立角色、工具集、记忆空间。Orchestrator / Router / | \ / | \ Researcher Coder Reviewer Agent Agent Agent | | | 搜索/读文档 写代码/调试 审查/打分 | | | └──────────────┼──────────────┘ 聚合器 ↓ 最终输出特征角色分工每个 Agent 只做一件事做深做专消息传递Agent 之间通过结构化消息通信仲裁机制冲突时谁来拍板人工介入 / 投票 / 上级 Agent共享 vs 隔离记忆哪些信息全局可见哪些私有常见拓扑拓扑描述适合场景星型一个 Orchestrator 调度多个 Worker大多数生产系统流水线Agent1 → Agent2 → Agent3有明确工序的任务辩论多个 Agent 各自输出由 Judge 裁决评估、审核、创意市场Agent 自由竞标任务实验性、研究性适用场景大型软件开发PM Agent Dev Agent QA Agent研究报告生成搜索 Agent 分析 Agent 写作 Agent 审校 Agent客服升级流程一线 Agent → 二线 Agent → 人工工程复杂度​ ★★★★★三、选型决策树你的场景是什么 │ ├── 只需要聊天、创意、头脑风暴 │ └── Chatbot ✓ │ ├── 需要基于企业内部知识回答问题 │ ├── 只需查文档不调外部工具 → RAG ✓ │ └── 查文档 偶尔查个数据/算个数 → RAG Tool Call ✓ │ ├── 需要完成多步任务比如查资料→分析→出报告 │ ├── 单个角色就能搞定 → Single Agent ✓ │ └── 需要多人分工写代码的人不负责审代码 │ └── Multi-Agent ✓ │ └── 我不确定先做一个试试 └── 从 RAG Tool Call 起步逐步加 Agent 能力四、一个快速判断表维度ChatbotRAGRAGToolAgentMulti-Agent外部知识✗✓✓✓✓工具调用✗✗✓(单次)✓(循环)✓(循环)自主规划✗✗✗✓✓(分工)多步执行✗✗✗✓✓自我纠错✗✗✗✓✓角色分工✗✗✗✗✓工程成本低中低中中高高运维成本低中中高很高适合团队规模1人1-2人1-3人2-5人5-10人五、本讲总结┌─────────────────────────────────────────────────────────────┐ │ 第1讲 核心收获 │ │ │ │ ✅ 理解了 Chatbot → RAG → Tool Call → Agent → Multi-Agent │ │ 的递进关系不是更高级而是更适合复杂场景 │ │ │ │ ✅ 核心分界线 │ │ - 有没有工具调用 │ │ - 有没有循环执行 │ │ - 有没有多角色分工 │ │ │ │ ✅ 选型原则从最简单的能满足需求的方案开始 │ │ - 85% 的场景 RAG Tool Call 就够了 │ │ - Agent 是解决不确定性的不是解决复杂 Prompt的 │ │ - Multi-Agent 是最后的手段不要为了炫技而上 │ │ │ └─────────────────────────────────────────────────────────────┘六、下一讲预告第2讲《ReAct 模式从零实现——不用框架手写一个 Agent 内核》你将亲手实现Thought → Action → Observation 循环工具注册与动态调用最大步数与终止条件错误恢复与重试完整的 Go 实现不到 300 行 开发之余的小工具推荐写代码过程中经常要处理 Base64 解码、JSON 格式化、JWT 解析、时间戳转换这类小需求。我习惯用一个纯前端本地工具箱 zz365.top所有计算都在浏览器里完成文件不上服务器关掉页面就自动清除。免费、无登录、无广告适合当浏览器的常驻标签页。