# 第六章《AI Agent——让大模型“长出手脚”》高校课堂版语音逐字稿

适用对象：具备一般数字素养的高校学生。  
前置知识：了解大语言模型能够理解和生成文本。  
本章学习结果：
1. 能够说明 AI Agent 与传统大语言模型的关键区别，并说出 Agent 的四步工作闭环。
2. 能够比较 ReAct 与 Function Calling 的作用，并判断它们如何配合。
3. 能够依据任务复杂度选择单 Agent 或多 Agent 架构，并解释 Agent 在具身智能中的桥梁角色。

建议课堂时长：45～55 分钟。  
预计纯语音时长：22～26 分钟。  
课堂时间构成：讲述约 24 分钟，单选思考与反馈约 8 分钟，实操设计与讨论约 15～23 分钟。  
讲解主线：从“会回答”到“能行动” → 行动闭环与工具协议 → 协作架构 → 连接真实世界。

使用说明：仅将每页的“语音逐字稿”正文送入 TTS；互动停顿和教师提示不送入 TTS。

---

## P1【让大模型 长出手脚】章节封面

【本页目标】学生能够用一句话概括 Agent 的价值：让大模型围绕目标调用工具并完成任务。  
【预计播报时长】约 1 分 10 秒

【语音逐字稿】

请看屏幕中央的 AI Agent，以及围绕它的感知、规划、工具和执行四个标签。前几章我们见过大模型的语言能力：它可以解释、写作和编程，但如果它只能停留在对话框里，能力仍主要表现为“说”。

这一章讨论的 Agent，目标是让系统从“回答问题”进一步变成“完成任务”。例如，面对“明天北京是否下雨”的需求，模型若只给出一句天气描述，仍然只是回答；如果它能查询天气、判断降雨条件并发送带伞提醒，才形成了面向目标的行动过程。

这里的“长出手脚”是一个帮助理解的类比，不意味着模型真的拥有身体。它指的是模型被接入感知来源、外部工具和执行接口，并且能依据反馈调整下一步。接下来我们先比较 Agent 与普通大语言模型到底差在哪里。

【教师提示】开场可请学生举一个“只回答还不够，必须继续执行”的校园场景，例如查空教室、整理课程资料或提醒截止时间。

## P2【从“回答”到 “完成任务”】Agent 与 LLM 的区别

【本页目标】学生能够比较传统 LLM 与 Agent 的输入、过程和输出差异。  
【预计播报时长】约 1 分 40 秒

【语音逐字稿】

请先看左侧白色框，它代表传统大语言模型。它接收问题后生成回答，擅长语言理解和文本生成；但它不会自动走出对话框去搜索、下单、发邮件或控制设备。

再看右侧青色框。AI Agent 不只是把用户输入变成文本，而是先识别目标，再拆解任务，必要时调用搜索、数据库、计算器、文件系统或设备接口，最后根据结果继续执行或给出汇总。也就是说，输入不再只是“问题”，输出也不再只是“一段话”，中间多了与环境交互的过程。

因此，不能因为一个产品能调用工具，就断言它一定可靠。工具是否有权限、参数是否正确、返回结果是否经过核验，都会影响最终任务。我们可以记住本页结论：LLM 像聪明的大脑，Agent 则把大脑接上感知、工具和行动能力。

【互动停顿】请学生用 15 秒判断：自动把会议纪要整理后发给指定成员，属于“回答”还是“完成任务”？理由要指出是否存在外部执行。

## P3【Agent 的 四步闭环】工作循环

【本页目标】学生能够按顺序说出感知、规划、工具调用、执行，并说明反馈为何必要。  
【预计播报时长】约 2 分 10 秒

【语音逐字稿】

请从左到右阅读四个彩色方块。第一步是感知。Agent 需要从用户输入、系统提示、上下文记忆和 API 返回结果中判断当前状态与目标。比如用户说“查北京明天天气，如果下雨提醒我带伞”，系统要识别地点、日期、查询对象和“下雨”这个条件。

第二步是规划，也就是把一句笼统目标拆成有顺序的小任务：先查天气，再判断是否有雨，最后决定是否生成提醒。第三步是工具调用。Agent 不能只说“我去查”，还要选择天气接口，并传入北京和日期等参数。

第四步是执行。工具返回天气后，系统要依据结果输出提醒，或者发现信息不足后重新进入下一轮。屏幕下方的虚线反馈强调：这不是一次从左到右就永远结束的流水线。真实任务会遇到缺失数据、工具失败或条件变化，Agent 需要把新观察带回下一轮规划。

【教师提示】强调“工具调用”是请求工具，不等于工具已经成功完成；观察结果必须进入下一轮判断。

## P4【Agent 为什么 需要记忆】短期与长期记忆

【本页目标】学生能够区分上下文短期记忆与向量数据库长期记忆的用途。  
【预计播报时长】约 1 分 50 秒

【语音逐字稿】

请看左右两个记忆框。左边的短期记忆可以类比为工作台：它保存当前对话正在使用的信息，例如用户刚刚说过的旅行时间和预算。它的优点是直接参与当前推理，限制是容量有限，较早的信息可能无法一直同时放在当前上下文中。

右边的长期记忆更像图书馆。历史对话和知识片段会被转成向量表示并存入向量数据库；当 Agent 需要相关内容时，再按语义相似度检索。例如，用户三个月前偏好安静酒店，系统可以在做新旅行计划时检索这条偏好。

请注意，这个“图书馆”类比只帮助理解检索方式。长期记忆不是天然正确的事实库：旧偏好可能已经变化，检索也可能找错片段。因此，涉及重要决定时，系统还要让用户确认，并能追溯它依据了哪条历史信息。下一页会把这种持续感知放到数字孪生场景中。

## P5【在虚实之间 先推演再行动】数字孪生调度

【本页目标】学生能够说明 Agent 在数字孪生中如何连接数据、策略与设备控制。  
【预计播报时长】约 1 分 40 秒

【语音逐字稿】

请看左侧的数字孪生和右侧的设备与预警，中间虚线框是 Agent 调度。数字孪生可以理解为对设备、环境和状态的虚拟映射。Agent 先读取虚拟空间里的传感器数据、设备状态和环境参数，在这个可观察的副本中推演响应策略。

如果策略满足预设条件，Agent 再通过 API 调用控制虚拟设备或推送预警信息。这里的因果顺序很重要：先有状态数据，再有策略判断，最后才是执行指令。这样做并不能自动消除风险，但能让方案在下达前获得一次可检查的推演机会。

因此，Agent 在这个场景中不是简单的聊天界面，而是调度引擎。它仍需要明确权限边界和人工复核，特别是当指令可能影响设备或人员安全时。下面我们转向 Agent 最常见的一种多步推理节奏：ReAct。

## P6【ReAct： 想一步，做一步】推理与行动循环

【本页目标】学生能够解释 Thought、Action、Observation 三者的顺序和作用。  
【预计播报时长】约 2 分 10 秒

【语音逐字稿】

请依次看黄色、粉色和青色三个框。ReAct 这个名称通常用来概括“推理与行动交替”的方式。第一步 Thought，也就是思考：系统先盘点已有信息，判断当前缺什么，而不是马上给出一个看似完整的答案。

第二步 Action，是采取行动或调用工具。此时 Agent 要把想法落实为一个具体请求，例如调用搜索工具，并给出明确的查询条件。第三步 Observation，是观察工具返回的结果，并检查结果是否解决了问题。

举例说，若要查询获奖者年龄，第一轮可以先搜索获奖名单；观察到有两位得主后，下一轮再分别检索出生日期；只有信息齐全时才汇总回答。这个例子说明 ReAct 的价值不在于把英文标签写出来，而在于让每次行动都受前一次观察约束。

它的边界也很清楚：如果观察结果来源不可靠，或者工具参数错误，多轮循环会放大错误。因此，关键步骤应记录工具调用和返回结果，便于复核。

## P7【函数调用是 通信协议】Function Calling

【本页目标】学生能够按画面顺序说明 Function Calling 的五步技术流程。  
【预计播报时长】约 2 分 10 秒

【语音逐字稿】

请从左到右阅读五个方块。第一步是函数定义：开发者事先声明可用工具的名称、用途、参数和类型。第二步是模型决策：模型根据用户需求判断是否应该调用某个函数，以及参数应怎样填写。

第三步是 JSON 请求。JSON 是一种结构化的数据表示方式；在这里，模型输出的不是“我准备去查天气”这样的自然语言，而是可被程序读取的调用请求。第四步由外部代码真正执行函数或 API，例如向天气服务发出查询。第五步把执行结果重新放回模型上下文，让模型基于真实返回继续推理和表达。

所以，Function Calling 不是让模型直接拥有所有权限，而是一套通信协议。权限控制、参数校验、错误处理和日志记录仍由产品系统负责。它的优势是结构稳定，适合明确的工具调用；下一页我们把它和 ReAct 放在一起比较。

## P8【心法加招式： ReAct + Function】两者关系

【本页目标】学生能够区分 ReAct 是推理范式，Function Calling 是技术协议。  
【预计播报时长】约 1 分 45 秒

【语音逐字稿】

请看左边粉色的 ReAct 和右边绿色的 Function Calling。ReAct 关注的是“怎么想”：它用思考、行动、观察的循环组织多步任务。只要通过提示词约定输出格式，很多模型都可以采用这种推理节奏；代价是文字格式可能不稳定，程序解析时需要更谨慎。

右边的 Function Calling 关注的是“怎么把行动送出去”：模型按预先定义的结构输出函数和参数，程序据此执行。它更适合工具清单明确、希望接口稳定的场景。

因此，屏幕中间的加号不是说二者完全等同。更合适的理解是：ReAct 负责决定下一步为何要做，Function Calling 负责把这一步以可靠的结构化协议交给外部系统。复杂任务可以把两者结合，但仍要用校验和权限控制约束实际执行。

## P9【任务变复杂时 如何分工】单 Agent 与多 Agent

【本页目标】学生能够依据任务可拆解性、专业差异、预算和延迟选择架构。  
【预计播报时长】约 2 分

【语音逐字稿】

请比较左侧单 Agent 和右侧多 Agent 的高度与分工条。单 Agent 由一个系统负责感知、规划、调用工具和输出，适合个人助手、单一领域问答或简单自动化。它的好处是架构简单、上下文一致、通信开销小。

但任务一旦同时包含需求分析、架构设计、编码、安全审计和文档检查，一个 Agent 要在很多专业角色之间切换，容易出现上下文负担和单点故障。此时，多 Agent 可以把不同子任务交给不同专长的 Agent，再由协调者汇总结果。

不过，多 Agent 不是任务一复杂就必然更好。它需要更多 API 调用、更多通信和更复杂的错误追踪。做选择时请问三个问题：任务能否清晰拆开？子任务是否确实需要不同专长？成本与等待时间是否允许？这三个条件共同决定是否值得分工。

【互动停顿】请学生用 20 秒判断：一个只查询天气并提醒穿衣的机器人，是否需要多 Agent？理由应同时考虑任务复杂度和专业分工。

## P10【多 Agent 有 四种队形】协作拓扑

【本页目标】学生能够识别四种协作模式，并为任务依赖关系选择合适模式。  
【预计播报时长】约 2 分 10 秒

【语音逐字稿】

请从左到右看四张小图。第一种是流水线：上一个 Agent 的输出直接交给下一个，适合需求分析、方案设计、代码实现、测试审查这类顺序明确的工作。

第二种是辩论模式。多个 Agent 先独立分析同一个问题，再互相审查观点，最后形成综合结论。它适合存在多种解释、需要降低单一视角偏差的任务。第三种是层级模式：领导 Agent 负责分配任务、跟踪进度、整合结果，下方执行 Agent 各自专注一个领域。

第四种是市场模式，Agent 通过竞标或竞争方式获得任务。无论采用哪一种，关键不在 Agent 数量，而在任务依赖关系。若一个步骤必须等待前一步完成，就不应假装并行；若多个审查任务彼此独立，就可以并行后再汇总。协作拓扑应服务任务，而不是为了显得复杂。

## P11【大脑与身体之间 需要一座桥】具身智能中的 Agent

【本页目标】学生能够说明大模型、Agent 与机器人硬件的职责分工。  
【预计播报时长】约 2 分 10 秒

【语音逐字稿】

请看屏幕中的三段结构。左边的大模型负责理解任务、制定策略和推理决策；右边的机器人硬件，包括机械臂、传感器、摄像头和底盘，负责在物理世界执行动作并采集环境数据。

中间的 AI Agent 是连接桥梁。它把高层计划翻译为可执行的机器指令，例如移动、扫描、抓取；同时把传感器反馈送回给大模型。假如机器人接到“去客厅拿红色杯子”的指令，Agent 要协调语音转文本、物体识别、导航、抓取和状态反馈；如果杯子被遮挡，还要触发重新规划。

这也解释了具身智能的挑战：物理世界要求及时响应，错误可能造成设备损坏或安全后果，仿真中成功的策略也可能在现实中遇到差距。因此，Agent 的桥梁角色不仅是“连接”，还包括监控、限制、验证与必要时交给人类处理。

## P12【Agent 进入现实 要过四道关】现实系统边界

【本页目标】学生能够说明 Agent 从屏幕走向物理世界时必须同时面对实时性、安全与可靠性、多模态融合和 Sim-to-Real 四类约束。  
【预计播报时长】约 1 分 20 秒

【语音逐字稿】

请沿着页面中的四个关卡依次观察。第一关是实时性：物理动作往往需要毫秒级响应，而大模型推理可能需要数百毫秒到数秒，所以高层决策与底层控制不能不加区分地放在同一节奏中。第二关是安全与可靠性：屏幕上的错误可能只是答案不准确，物理世界中的错误却可能损坏设备，甚至影响人员安全。

第三关是多模态融合。机器人需要同时处理视觉、语言、触觉和力觉，任何单一信号都可能不完整。第四关是 Sim-to-Real，也就是仿真到现实的迁移差距；仿真中可行的策略，遇到真实摩擦、噪声和环境变化后仍可能失效。因此，Agent 的行动能力必须放在明确边界和反馈机制中。下一页进入总结，把闭环、工具协议、协作和现实约束连成一条主线。

## P13【Agent 如何 把想法变行动】本章总结

【本页目标】学生能够用三个关联的心智模型回顾本章。  
【预计播报时长】约 1 分 30 秒

【语音逐字稿】

请看总结页的三张卡片。第一张是形成闭环：感知、规划、工具调用、执行和反馈，让语言模型不止停留在生成文本。第二张是可靠行动：ReAct 组织多步思考，Function Calling 让工具请求以结构化方式传递。

第三张是扩展到现实。任务简单时可以用单 Agent；任务可拆解且需要不同专长时再考虑多 Agent。进入具身智能后，Agent 进一步成为大模型和机器人身体之间的桥梁。

请把这三张卡片连成一句话：Agent 先理解环境和目标，再用可控的工具协议行动；当任务或环境变复杂时，用合适的协作架构与反馈机制保持可验证性。下面进入测验，用题目检查这一条主线是否真正建立起来。

## P14【单选题 10 题】知识检查

【本页目标】学生能够独立作答，并用本章机制解释选择理由。  
【预计播报时长】约 4 分 30 秒，另含学生作答时间

【语音逐字稿】

这一页共有十道单选题，屏幕一次显示一道。请先自行阅读题干和四个选项，再点击你认为正确的答案；系统会锁定本题选择，显示得分和讲义解析。

作答时不要只记结论。前四题重点检查 Agent 的自主行动闭环、四步顺序、ReAct 三要素和 Function Calling 的结构化机制。中间几题要求你根据任务复杂度判断多 Agent 的适用性，并识别层级协作的特点。最后几题回到具身智能、长期记忆、国内平台支持与现实世界挑战。

每答完一题，请用一句话说明你依据的是哪一个机制。例如，判断工作循环顺序时，要能指出为什么工具调用在规划之后；判断长期记忆时，要能说出为什么需要按语义检索。完成后再查看解析，用错误选项反推自己混淆的是能力、协议还是架构。

【互动停顿】每题预留 15～25 秒。全部完成后教师按错题最多的两类进行讲解。

【教师提示】学生作答前不朗读答案。作答后课件会展示正确答案与讲义解析；优先反馈“传统 LLM 与 Agent 的区别”“ReAct 三要素”“层级模式”和“多模态挑战”四类易混点。

## P15【实操：旅行规划 ReAct 工作流】任务设计

【本页目标】学生能够设计至少四轮 Thought、Action、Observation，并为每轮选择合适工具与参数。  
【预计播报时长】约 2 分，另含 8～12 分钟设计时间

【语音逐字稿】

请阅读屏幕上的任务：设计一个智能旅行规划 Agent。它要根据目的地和天数完成天气查询、景点搜索、每日行程规划和预算估算。请先不要点击标准答案。

先从用户目标开始，把“大任务”拆成可验证的子任务。每一轮都要写清三件事：Thought 说明当前为何要做这一步；Action 写出要调用的工具和参数；Observation 记录工具返回了什么，以及这个结果如何影响下一轮。

例如，天气结果会影响景点与行程安排，行程结果又是估算预算的输入。请同时检查工具名称是否反映功能，参数是否足以让工具执行。最后别忘了明确使用哪一个国内大模型平台作为 Agent 的大脑。

【互动停顿】个人或小组设计 8～12 分钟。展示时优先检查是否达到四轮完整循环、工具参数是否合理、步骤之间是否有逻辑依赖。

【教师提示】学生提交后再点击“显示讲义标准答案与评分标准”。反馈时按讲义的五项分值检查：循环完整性、工具定义、流程逻辑、平台选择和输出完整性。

## P16【实操：代码审查 多 Agent 协作】协作架构设计

【本页目标】学生能够设计至少三个职责清晰的 Agent，并说明分发、审查、汇总、输出的协作流程。  
【预计播报时长】约 2 分，另含 8～12 分钟设计时间

【语音逐字稿】

最后一题要求设计一个代码审查多 Agent 协作系统。请先确定一个调度角色，再决定哪些审查任务可以由不同 Agent 分别承担。至少三个职责必须清楚区分，例如代码风格、安全检查、性能分析或文档审查。

随后用箭头写出协作过程：用户上传代码后，调度 Agent 如何分发；各审查 Agent 如何独立输出发现；调度 Agent 又如何收集、去重、按严重程度排序，并形成综合报告。这里的关键不是堆砌更多角色，而是让每个角色都对最终输出有明确贡献。

最后，请至少从三个维度比较多 Agent 与单 Agent，例如审查覆盖面、分析深度、容错性、扩展性或并行效率。同时也要承认代价：更多角色意味着更多通信、协调和调试成本。

【互动停顿】小组设计 8～12 分钟，每组用一分钟说明角色分工和协作流程。

【教师提示】学生汇报后再展开讲义标准答案与评分标准。重点核对职责定义、协作流程、优势分析、国内平台选择和整体设计质量五项要求。