Agents - 智能代理

尚硅谷大模型技术之LangChain V1.1.0

目录

章节	主题	核心内容
一	Agent 介绍	概念、核心组件、工作机制、与Chain对比
二	工具定义与使用	Function Calling原理、@tool装饰器、create_agent
三	MCP工具接入	MCP协议、Server编写、LangChain集成
四	记忆管理	Checkpointer、Thread ID、多会话隔离
五	Agent中间件	消息压缩、人工审核
六	Agent最佳实践	工具设计、提示词优化、调试与性能
七	综合实例	智能客服Agent完整项目
八	课程总结	知识回顾、常见问题、进阶方向

---

1、Agent 介绍

1.1 从Chain到Agent

在前面的课程中，我们已经学会了用 Chain（链） 来组合LLM调用。但为什么还需要Agent？Chain的工作方式是：预先定义好一条固定的处理流程，输入数据按顺序流经每一步，最终得到输出。

Chain的工作方式：

   用户输入 → 提示词模板 → LLM → 输出解析 → 结果
              └────────────────────────────┘
                     固定流程，预先编排

这种方式在很多场景下运行得很好。但现实中有一类问题，Chain处理不了——你事先不知道该走哪条路。

举个例子： 用户问"帮我查查北京明天会不会下雨，如果下雨，帮我取消明天的户外预约"。

要完成这个任务，程序需要：

1. 先调用天气API查天气
2. 根据查到的结果（下雨/不下雨）做出判断
3. 如果下雨，再调用日程API取消预约；如果不下雨，直接回复用户

问题来了：步骤2的"判断"和步骤3的"是否执行"，在编写代码时无法预先确定。 你不能把这个流程硬编码成一条固定的Chain，因为每次用户输入不同，需要走的路径也不同。

这就是 Agent（智能代理） 要解决的问题。

1.2 什么是Agent

Agent的核心思想是：把LLM当作"大脑"，让它自己决定下一步做什么。

Agent = LLM + 自主决策 + 【工具调用】

在Chain中，是开发者（你）决定执行流程；在Agent中，是LLM自己决定执行流程。LLM会根据用户的输入和当前的上下文，自主选择要调用哪个工具、要执行什么操作，然后观察执行结果，再决定是否需要继续行动。

用一句话总结二者的区别：

Chain：开发者编排流程，LLM负责执行 → "你告诉它怎么做"
Agent：LLM自主编排流程，工具负责执行 → "你告诉它要做什么，它自己想怎么做"

1.3 核心组件

理解了Agent是什么之后，我们来看它由哪些部件组成。Agent有四个核心组件，它们不是独立存在的，而是协作运转的：

四个组件之间的协作关系：

组件	角色	和其他组件的关系
① LLM（大脑）	理解用户意图，做出每一步的决策	是整个Agent的中枢，驱动其他三个组件
② Tools（工具）	执行LLM的决策，与外部世界交互	LLM"想"，工具"做"，工具的执行结果会反馈给LLM
③ Memory（记忆）	存储上下文，让Agent"记住"对话历史	为LLM提供决策所需的历史信息
④ Planning（规划）	把复杂任务分解成可执行的步骤	指导LLM按合理顺序调用工具

注意： 并不是每个Agent都需要四个组件全部具备。最简单的Agent只需要LLM + Tools即可工作。Memory和Planning是增强能力，让Agent能处理更复杂的任务。

1.3.1 关于Planning（规划）

你可能在一些文章或论文中看到Agent的架构被描述为四个组件：LLM、Tools、Memory、Planning（例如Lilian Weng那篇著名的Agent论文）。那么Planning去哪了？

在LangChain的工程实现中，Planning并不是一个独立的物理组件，而是一种隐含在Agent运行机制和提示词中的"能力"。你不需要手写planning = ...这样的代码——规划能力已经被融合在了LLM的推理过程和Agent的执行引擎中。

具体来说，Planning在不同类型的Agent中以不同的方式体现：

方式一：边走边看（ReAct模式）

这是LangChain中最基础、最常用的模式，也是create_agent默认使用的模式。

用户："帮我查北京天气，如果下雨就取消明天的会议"

  第1步局部规划（Thought）：我需要先查天气 → 调用天气工具
  第2步局部规划（Thought）：天气是下雨，所以下一步取消会议 → 调用日程工具
  第3步局部规划（Thought）：两件事都做完了 → 回复用户

在这种模式下，Planning发生在每一次工具调用的前一刻——LLM每走一步都思考一下"接下来该干什么"。它没有全局规划，而是步步为营。这个"思考"过程就是LLM内部的推理，体现在提示词引导的Thought步骤中。

方式二：谋定而后动（Plan-and-Execute模式）

对于特别复杂的任务（如"调研三个国家的AI市场并写一份对比报告"），步步为营容易迷失方向。这时可以用Plan-and-Execute架构——先规划再执行：

用户："调研中美欧三地的AI市场，写一份对比报告"

  阶段一（Planner）：先调用LLM纯思考，输出步骤清单：
    步骤1：搜索中国AI市场数据
    步骤2：搜索美国AI市场数据
    步骤3：搜索欧洲AI市场数据
    步骤4：对比分析三地差异
    步骤5：撰写报告

  阶段二（Executor）：按清单逐一执行，调用工具完成每个步骤

这种模式需要通过LangGraph来构建更复杂的工作流，不在本课的基础范围内。

总结： Planning的灵魂隐藏在你选择的Agent类型和系统提示词中。在LangChain开发中，你实际需要动手构建的核心组件是三个：LLM、Tools、Memory——这也是本课程后续章节的学习主线。

1.4 工作机制

Agent不是"一次调用就出结果"，而是通过一个"感知→推理→行动"的循环（Loop）来逐步完成任务。

关键理解：这个循环可能执行多轮。 LLM每次"推理"后，如果判断任务还没完成，就会继续调用工具、观察结果、再推理……直到它认为可以给出最终答案为止。

1.5 完整例子

回到1.1节的例子，看看Agent内部是怎么一步步处理的：

用户："帮我查查北京明天会不会下雨，如果下雨，帮我取消明天的户外预约"

第1轮循环：
  ① 感知：收到用户消息
  ② 推理：用户想知道天气，我需要先查天气 → 决定调用"天气查询"工具
  ③ 行动：调用 get_weather("北京", "明天") → 返回"明天北京：小雨"

第2轮循环：
  ① 感知：收到工具返回结果"小雨"
  ② 推理：明天下雨，用户要求下雨时取消户外预约 → 决定调用"取消预约"工具
  ③ 行动：调用 cancel_appointment("户外预约", "明天") → 返回"已取消"

第3轮循环：
  ① 感知：收到工具返回结果"已取消"
  ② 推理：天气查了，预约也取消了，任务完成 → 决定直接回复用户
  ③ 输出："北京明天预报有小雨，我已经帮您取消了明天的户外预约。"

注意观察： 整个过程中，没有任何一行代码预先规定了"先查天气再取消预约"这个流程。是LLM根据用户意图和中间结果，自主决定了每一步该做什么。如果明天不下雨，LLM在第2轮就会直接回复用户，根本不会调用取消预约的工具。

这就是Agent和Chain的根本区别：执行路径不是写死的，而是由LLM动态决定的。

1.6 Agent与Chain对比

现在我们可以更深入地对比二者：

对比维度	Chain（链）	Agent（智能代理）
谁决定流程	开发者在代码中预定义	LLM在运行时自主决定
执行路径	线性的，固定的	循环的，动态的
工具调用	在固定位置调用固定工具	LLM按需选择工具，调用次数不确定
处理意外情况	无法应对预期之外的情况	LLM可以根据工具返回结果调整策略
适合的任务	结构明确、步骤固定的任务	开放式、需要判断和决策的任务
可预测性	高——每次执行路径相同	低——不同输入可能走不同路径
开发复杂度	低——流程清晰可控	较高——需要设计好工具和提示词

实际开发建议： 不要所有场景都用Agent。如果你的任务流程是确定的（比如"翻译一段文字"），用Chain更简单可靠。只有当任务需要动态判断和多步决策时，才需要Agent。

1.7 技术栈定位

回顾我们整个课程的学习路径，Agent处于技术栈的最上层：

每一层都是在上一层的基础上增加新的能力：Model I/O让你能调用模型，Chain让你能编排流程，RAG让模型拥有知识，而Agent让模型拥有"判断力"和"行动力。

1.8 本章小结

本章的核心内容可以归结为三句话：

1. 为什么需要Agent： Chain只能处理固定流程，面对需要动态判断的任务无能为力，Agent通过让LLM自主决策来解决这个问题。
2. Agent是什么： LLM作为大脑，配合工具（执行）和记忆（上下文）三大核心组件，通过"感知→推理→行动"的循环来完成任务。规划能力则隐含在LLM的推理过程和提示词策略中。
3. 什么时候用Agent： 任务流程固定用Chain，任务需要动态判断和多步决策用Agent。

接下来的章节，我们将学习如何用LangChain实际构建一个Agent——从定义工具开始。