这门课到底讲什么一句话说清楚把Agent从能聊天推到能干活。第3课是整个系列的分水岭前两课铺垫了大模型基础、提示词设计和最简单的对话Agent到了这里才真正进入Agent的核心战场——工作流编排、记忆系统、工具调用这三样东西决定了你做出来的东西是一个聊天玩具还是一个能交付任务的系统。如果你正在跟着课程做自己的Agent项目或者打算把Agent开发教给别人这节课的价值在于它把Agent会调用工具从一句口号变成了可拆解、可练习、可验收的具体技能。整节课的教学设计围绕一个核心矛盾展开模型本身不会记忆、不会主动执行外部操作但业务场景恰恰同时需要这两点。下面把我设计这门课时的完整思路、课堂Demo的搭建过程、还有踩过的坑一起放出来。1. 第3课整体设计与思路拆解1.1 为什么第3课必须切入工作流而不是继续堆概念很多Agent课程讲到第3课还在讲什么是LangChain有哪些框架Agent的发展历史学员听完感觉懂了很多上手还是写不出一个能自动调用搜索和写文件的程序。我的判断是第3课恰恰是建立操作直觉的最佳窗口期学员已经有基本提示词能力但还没形成系统思维这时候用一整个课时的篇幅去拆解单个工作流比任何理论铺垫都有效。我把第3课的定位设计为从单次对话到多步执行核心教学目标是让学员理解并实现一个最小可用的Agent循环接收任务、拆解需求、决定是否调用工具、获得工具结果、生成最终回答。这个循环看起来朴素但它是所有复杂Agent应用的地基包括后面要讲的多Agent协作、自主规划、长期记忆全部建立在这个循环之上。整个课时的节奏我故意设计得慢而深宁可一个Demo拆开揉碎讲透也不追求覆盖面。因为Agent开发的难点不在某个单独环节有多难而在于多个环节如何衔接。举个例子只说记忆这个概念很容易但什么时候把记忆写入存储什么时候从存储里提取提取到的信息和当前上下文冲突了怎么处理这些都是衔接处的细节不实操根本不会暴露。另外一个设计考量是可复现性。第3课选用的技术栈尽量精简不引入重量级框架直接使用模型接口原生的函数调用能力加一个简单的JSON文件存储。原因有两点一是框架封装太厚学员出问题时很难判断是模型的问题、代码的问题还是框架流程的问题二是课程时间有限把时间花在框架API上不如花在理解Agent本身的逻辑上。等你理解了原生实现再去套任何框架都是顺手的事。1.2 三个教学模块的逻辑记忆、工具、编排第3课主体分成三个模块每个模块解决一个具体问题。第一个模块解决Agent怎么记住该记的东西。这里我会先让学员体验一个冲击性对比同一个任务不带记忆模块的Agent每次都要用户重复背景信息而带记忆模块的Agent只需一次就能记住。这个对比不是为了炫技而是让学员直观感知记忆系统解决了什么真实痛点。然后给出一个分层记忆模型短期工作记忆承载当前任务上下文长期记忆以结构化片段的方式存到外部存储项目记忆保存当前用户的核心档案。三个层级的读取优先级和更新规则各自不同这是整个模块的核心知识。第二个模块解决Agent怎么调用外部能力。这里不会单独讲什么是工具调用而是把工具调用放在模型输出受限的框架下来理解模型本身不能执行操作它只能输出一段结构化的意图真正执行动作的是你写的代码。学员要完成一个关键认知转变工具调用的设计重心不在模型侧而在你如何定义工具的描述、参数和返回值这直接决定模型能不能在合适的时机选对合适的工具。第三个模块是把前两个模块串起来设计一个完整的编排循环。我选择了一个贴近真实办公场景的任务——根据会议录音整理行动项因为它同时需要调用文本处理工具、读取历史记录工具、写入任务清单工具而且输出结果是看得见摸得着的学员能直观感受到这个Agent确实帮我干活了。整个Demo代码控制在200行以内方便学员逐个函数去读。这三个模块的顺序不是随便排的记忆模块建立状态的概念工具模块建立动作的概念编排模块把状态和动作接起来。前两个模块是并行能力第三个模块是综合运用符合先局部后整体的学习规律。2. 核心细节解析与实操要点从记忆到工具调用2.1 记忆分层的设计与数据结构的实操写法记忆这块最忌讳的就是一上来就上向量数据库。第3课里我明确告诉学员先别急着搞embedding检索先用最土的标签结构化文本方案把记忆的读写逻辑跑通理解清楚了再升级也不迟。很多人在记忆上翻车不是因为技术选型不够高级而是因为读写逻辑本身就乱了。实际操作中我用的记忆数据结构是一个JSON文件每条记忆包含四个字段content记忆内容、tags标签列表、timestamp时间戳、source来源是用户主动告知还是Agent推断的。这个结构看起来很简朴但它支持三种关键操作按标签精确筛选、按时间排序、按来源区别处理。写记忆的时机是学员最容易纠结的地方。我给出的规则是三写三不写出现了新实体人名、项目名、专有名词时写用户明确表达了偏好或禁忌时写任务状态发生变化时写。反之随口闲聊不写、模糊表达不写、与当前任务无关的细节不写。这个规则本身不复杂但需要反复练才能形成判断力。读记忆的策略要更小心。实际项目里最常出的问题是记忆提取过多导致上下文混乱我教给学员的做法是分级召回每次对话开始时只加载该项目的高优先级标签记忆比如用户身份、核心目标当对话过程中模型判断需要更多记忆时再按当前话题的标签去检索二次补充。这种按需加载比一次性把所有记忆塞进上下文要稳得多。这里还要强调一点记忆和上下文的冲突处理。我见过太多人忽略这条——当新信息和旧记忆矛盾时课程里给出的默认策略是让模型以新信息为准同时把冲突的旧记忆标记为待确认而不是直接覆盖。这样既尊重用户最新的表达又保留了回溯纠错的可能性。这个处理机制实现起来也就十几行代码但对Agent的长期可靠性提升非常明显。2.2 工具调用的正确打开方式核心在描述不在实现很多初学者以为工具调用是模型端的神奇能力其实它的本质特别朴素你在代码里定义好若干函数每个函数配上名称、描述和参数结构模型生成回复时如果判断需要执行某个函数就会输出一个特殊格式的调用请求你的代码收到后执行这个函数把结果塞回给模型模型拿到结果后继续生成最终回复。这个流程里最影响成败的是工具描述怎么写而不是函数本身多复杂。我们经常说给模型一个选择工具的地图描述写得模糊模型就会瞎选。举个例子get_weather这个工具如果描述只写获取天气模型可能在用户问今天适合穿什么时不调用它如果描述写成获取指定城市的当前天气和未来三天预报当用户提到天气、穿衣、出行安排时调用模型的选择准确率会显著提升。我在课上给出了一个工具描述的编写模板使用场景、触发条件、输入参数说明、返回内容说明、不使用时的影响。五要素不一定每次都写全但什么时候调用和输入参数是什么这两项必须有缺一个就容易出问题。实操中还有一个细节参数描述要用模型视角的措辞比如时间参数不要写start_time然后描述开始时间要写成会议开始时间格式为YYYY-MM-DD HH:mm时区为北京时间这样模型才真正知道该传什么值。工具调用的错误处理也是第3课的必修内容。工具不可能永远返回成功文件可能不存在搜索可能没结果。关键是错误信息怎么回传给模型。我的做法是把错误包装成结构化的返回体不是只丢一个出错了而是带上错误类型、出错环节、可能的替代方案这样模型才能在下一轮做出正确的兜底决策而不是反复调用同一个失败的工具。这一步是你和拥抱异常大法的Agent之间的分水岭。2.3 编排循环的最小实现框架当记忆和工具都准备好了第3课的重头戏就是编排循环。我在课上给出的最小循环框架是四步循环接收输入、判断意图、执行动作、生成回答。这里的判断意图是整个循环的核心——模型需要判断当前这一步到底应该调用工具、追问用户细节还是直接作答。这个判断不能交给死板的if-else规则而是要交给模型本身这就是Agent区别于传统自动化的地方。意图判断的提示词写得越具体越好。我的模板里会写明你是任务助手你有以下工具可用请判断当前用户请求是否完整。如果缺少执行工具所必需的参数请追问用户如果所有参数齐备请调用对应工具如果一次任务需要多个工具请按顺序逐步调用。这个模板看着简单但它把模型自主决策圈定在一个安全的范围内防止模型乱跑偏。循环的退出条件也需要显式定义不然Agent会陷入调用工具-处理结果-再调用工具的死循环。我给学员三个终止信号模型明确表示任务已完成、达到最大迭代次数、模型判断需要用户介入确认。特别要说的是最大迭代次数这个护栏它常被忽视却在真实场景里价值极大——一个失控的Agent循环不仅浪费token更可能把错事做上好几轮一个合理的上限比如10轮能兜住绝大多数坏情况。3. 完整实操从零搭建一个会议行动项整理Agent Demo3.1 Demo需求定义与工具集设计第3课的实操Demo我选的是根据会议笔记整理行动项这个场景。需求描述如下用户给出一段会议记录文本Agent需要做到三件事提取待办事项和负责人、查询当前项目已有任务以避免重复、把新行动项写入任务清单并返回整理后的结果。围绕这个需求我设计了三个工具让学员感受工具规划设计的过程。第一个是extract_actions输入是原始会议文本输出是结构化的行动项列表每个行动项包含负责人、内容描述、截止时间第二个是query_existing_tasks输入是项目名输出是当前已有任务列表第三个是add_task输入是任务内容、负责人、截止时间输出是写入后的任务记录。这三个工具一个负责处理输入一个负责查询状态一个负责写入状态覆盖了读-查-写三种典型的工具类型。工具设计这里有个很容易被忽略的教学点我先不把三个工具的实现代码给全而是让学员先看工具描述再来猜函数内部大概要做什么然后才给出实现。这样做的目的是让学员建立描述先行的意识——好的工具设计是先想清楚这个工具是干什么的、什么情况下被调用再动手写代码而不是反过来。实现上我用一个纯Python脚本完成整个Demo存储用JSON文件不引入数据库。整个流程大概是这样的第一步读取系统提示词和工具清单第二步建立循环将用户输入与历史消息拼装后发送给模型第三步解析模型响应若包含工具调用请求则执行对应函数并把结果追加到消息列表第四步无工具调用请求时把模型回答返回给用户。这个流程代码量在150行上下核心部分是一个消息列表的不断追加。身为教学素材它的好处是没有任何框架魔法每一步数据怎么流动都能直接看到。3.2 系统提示词的写法与参数配置经验系统提示词在这个Demo里起的作用非常关键我给出的是一个分段的模板首先是角色定义然后是工作流程说明再是工具使用规则最后是输出格式要求。四段各司其职避免把提示词写成一坨混沌文本。角色定义部分我写得比较具体你是某团队的项目助理你的职责是根据会议记录整理行动项。你具备提取行动、查询已有任务、写入新任务的能力。工作流程部分告诉模型先读会议文本再检查重复再写入清单。工具使用规则部分强调只有参数完全齐备才能调用工具缺失参数时先向用户询问。输出格式部分要求最终回复用清单模式包含负责人和截止时间。参数配置上有几个具体数值我实测后比较稳定temperature设为0.2左右Agent类任务不需要太多创造性max_tokens设为1024足够大多数回答使用最大循环次数设为8轮。这些数值不是拍脑袋定下来的后面的第4课会专门带着学员做参数实验但在第3课先用稳定参数避免变量干扰。整个Demo跑起来后我给学员演示了一个完整的对话案例用户粘贴了一段包含两个行动项的会议记录Agent先调用extract_actions提取出行动项然后调用query_existing_tasks发现其中一个任务已经在列表里于是只把新的那项写入add_task最后用清单形式输出整理结果。这个案例演示了Agent的判断能力不是机械地执行全部工具而是根据查到的状态决定下一步动作整个流程学员能看到每一步的调用日志和中间结果。3.3 实操中的环节衔接与演示节奏控制上课时的实操环节要特别注意衔接问题。第一个卡点是工具描述术语不统一模型的参数名其实只对模型有意义学员容易把函数参数名当展示文本用导致模型传值混乱。解决办法是在工具描述里明确用中文自然语言描述参数含义而不是只写参数名字比如负责人姓名中文全名不要用昵称就比单纯的owner字段直观得多。第二个卡点是JSON解析容错。模型返回的工具调用不总是严格合法的JSON特别是参数里带换行或者特殊符号时直接解析会抛异常。我在代码里加了一个简单兜底当解析失败时把原始返回附加一条输出格式错误请重新输出规范的JSON的消息再发给模型让模型自己纠正。这个解析失败把错误反馈给模型的模式比在代码里做各种花式字符串修正要可靠得多也是推荐给所有学员的通用套路。第三个卡点是演示节奏。整堂课的实操环节我控制在40分钟以内前15分钟跟跑完整流程接下来15分钟让学员自己改一个工具描述再跑一遍对比工具选择准确率的变化最后10分钟开放一个挑战给Agent增加一个删除任务的工具然后重新规划系统提示词。这样一个Demo讲完学员既掌握了基础又完成了从模仿到微创新再到独立扩展的三级跳。4. 第3课常见问题与排查技巧实录4.1 模型假装调用工具的识别与处理实操中最高频的问题之一模型在回复里写了我将调用extract_actions工具但没有真的触发函数调用只是把这句话当作自然语言输出。首次遇到的学员一般会愣住以为是代码写错了其实这是模型对工具调用协议理解不到位导致的。判断标准很简单看模型的响应里有没有原生的工具调用结构字段。如果只有文字没有结构字段就说明模型没有走正式通道。我给的排查顺序是先检查API请求里是否传了tools参数再检查系统提示词里是否明确说了调用工具时必须通过函数调用机制输出不要口头说明最后检查是不是模型版本本身不支持该能力。这三个环节排查完九成问题都能解决。另一个相关问题是模型在工具结果返回后仍然拒绝执行下一步回复我已经完成。这种通常是工具执行结果里信息不够模型不知道下一步还能做什么。这时在提示词中增加一条规则会显著改善每次工具调用返回后你要判断任务是否真正完成。如果返回结果不足以生成最终答案继续调用或追问。实测这个提示词能让模型的主观完成减少很多。4.2 记忆越攒越乱怎么收敛记忆系统的常见问题是写得太频繁系统跑上几轮之后JSON里塞满了大量低质量、重复、过期的记忆然后Agent提取出来的信息变得互相矛盾。这个现象的根源是该过滤的没过滤该合并的没合并。我的收敛策略分三层。第一层是写入前检查每次写入前先按标签搜一下是否已有相似记忆如果有则执行合并而不是新增。合并规则是保留较新时间戳的版本但把旧版本里的独有信息追加进content。第二层是定期清理设计一个记忆压缩函数根据timestamp把超过30天且从未被命中的记忆标记为归档不参与正常检索。第三层是课堂上的一个金句记忆系统是维护出来的不是写完就一劳永逸的课程结束时会专门演示一次迭代维护记忆数据的过程。这里我还想提一个很多开发者都会犯的错把用户的每一次聊天都存成一条记忆造成大量噪音。我在第3课的练习里设置了一道辨析题给出五段对话文本让学员判断哪些该写入记忆、为什么再从错误中选择最像自己做法的那条反思原因。这种先判断后编码的练习比单纯讲规则有效得多。4.3 编排死循环与重复执行的现场排查死循环是Agent开发里最需要提前预判的问题。现场演示时比较容易遇到的场景是Agent反复调用同一个查询工具因为查询结果没有变化但Agent也不改策略就一直查下去。这种问题不设置最大循环次数的话会烧掉大量token。我给出的排查工具是调用日志加计数器。在Demo里我们对每一次工具调用打点记录调用顺序、工具名、返回结果摘要和轮次序号。一旦某个工具连续被调用超过3次且返回结果一样就打印一条警告并触发表层兜底策略——直接停止新的工具调用转而向用户说明当前情况并请求额外信息。设置这个规则不是为了惩罚Agent而是要让它意识到这条路走不通需要换一种方式或问用户。有时候循环的根源是工具返回的格式不便于模型判断结果比如查询工具返回了一个巨长的JSON列表模型难以快速识别没有匹配项。解决办法是让工具返回自带摘要共找到2条相关任务其中1条与当前输入重复度较高项目二期部署。这样模型一眼就能看到关键信息就不容易在解析长文本时绕圈子。4.4 常见问题速查对照表我把第3课里被问得最多的问题整理成一张速查表方便学员在实操时快速检索。现象可能原因排查顺序与建议模型回复中出现我将调用XX工具但没执行工具调用协议未走原生通道1.检查请求参数tools是否传递2.检查提示词是否要求通过函数机制3.换支持原生调用的模型版本工具偶尔选错工具描述含糊或参数定义不清1.按场景-触发-参数-返回模板重写描述2.加上不调用时的后果说明工具返回后模型反复调用同一工具返回信息不足以支撑决策或缺失迭代上限1.在返回体前增加摘要段2.设置最大调用次数3.连续重复时主动向用户提问Agent拒绝调用任何工具系统提示词里把工具使用说成了可选项1.明确该任务必须调用工具后再回答2.降低temperature记忆写入太频没有在写入前做去重与合并1.写入前按标签检索相似记忆2.执行合并逻辑3.引入时间戳与归档机制这张表在实际教学中反馈很好学员做完练习后对照自查能独立解决大部分基础问题。帮你练习时可以把它打印成操作卡放在手边比翻课件效率高多啦。5. 从Demo到教学素材第3课授课与练习设计经验5.1 演示课与实操课的节奏设计课程开发如果只讲技术点不给可落地的教学节奏读者听着容易疲惫。第3课在设计时我就区分了两种课型演示课和实操课节奏完全不同。演示课的定位是看懂我完整跑一次Demo学员不操作只观察每一步的输入、输出和中间日志。这个阶段我会刻意把Agent的思维过程说得很细——为什么这里调了查询工具、为什么那里选择追问用户而不是直接给答案。演示课的目标不是让学员记住代码而是建立对Agent决策路径的心理预期。实操课的定位是动手学员自己把Demo跑通。实操课的题目设计遵循难度阶梯原则第一题是改一个参数再跑一次最低成本的熟悉第二题是照着模板写一个新工具的描述观察模型选择准确率的变化中等难度第三题是自由设计一个闹钟提醒Agent自己规划记忆结构和工具集综合应用。通常做完这三题学员对第3课的知识点掌握就相当扎实了。实操过程中的掐点环节需要提前准备。比如学员的本地环境依赖版本不一致直接导致Demo跑不起来。我的经验是在课前提供一个环境检查脚本自动检测Python版本、库依赖、API连通性学员跑脚本确认OK再开始动手能省去大量课堂时间。此外每个Demo都要准备一个降级演示方案如果模型接口超时或者网络不稳定导致线上调用失败就切换到本地缓存的示例响应继续走流程保证课程不中断。5.2 课堂练习的验收标准与常见教学坑课堂练习如果没有验收标准学员容易停留在跑通了很开心但不知道自己是否做对了。我给第3课练习定了三条硬性验收线第一完成一个包含至少两个工具调用的完整任务对话第二任务结束后记忆文件里出现了正确的持久化记录第三能口头解释自己设计的工具描述中每一个字段的含义。三条全过才算真正完成本课。第一条检验端到端流程是否跑通第二条检验记忆模块是否真的在工作第三条检验学员是否理解工具调用的核心逻辑。实践中我发现很多学员写出的工具描述能跑通但被问到为什么要写触发场景时会卡壳说明他们还是在模仿没有真正理解描述信息。验收标准的价值就是把这些隐性要求显性化。教学坑方面要提醒三个一是网络代理类环境问题导致API调用失败课上要准备离线可用的降级方案二是模型随机性导致的演示不确定性关键演示环节要固定随机种子或用低温度参数三是学员容易在工具函数内部做太多的智能处理把本该由模型承担的任务放到代码里导致整个Agent逻辑变得死板——我要反复强调的是工具函数应该保持简单、独立、可复用复杂的判断决策尽量让模型来工具负责执行决策交给提示词。5.3 把第3课扩展成系列课的一个思路单个第3课全讲完其实还有很大的延伸空间这也是课程开发指南这个系列课的特色。如果后续要扩展我建议在三个方向上做增量一是记忆系统的进阶引入向量检索和语义相关度排序替换掉标签匹配二是工具自主发现让Agent从一个工具列表里自适应选择而不是固定绑定三是多Agent协作两个Agent分别负责信息收集和任务执行通过消息队列通信。扩展时注意保持第3课确立的原则不变先理解原生的数据流再引入框架或者更重的手段。比如向量记忆的引入必须是在学员已经理解文件型记忆的全流程之后。否则直接上向量数据库会让学员把注意力全放在库的操作上反而模糊了记忆模块本身的逻辑。有了第3课的底子后续课做这些扩展就会非常顺滑学员也更容易意识到框架是为了省事不是必须。6. 课后的个人体会与一点实战建议每次上完第3课我最深刻的体会是Agent开发的核心不是模型有多强而是你能不能把任务拆成记忆、工具、编排这三个清晰的维度。很多项目做着做着变得不可控往往不是模型的锅而是没有把这三个维度理清楚。记忆解决它知道什么工具解决它能做什么编排解决它怎么决定做什么这三件事是Agent系统的骨架任何时候都优先于具体算法和模型调优。我给学员的最后一个建议是学完第3课之后别急着学更多复杂的技术先拿这个最小编排循环去做一件真实的小事比如自动归档你每天收到的邮件摘要、整理周报的待办、定时拉取某个数据源并保存。真实场景会逼着你面对各种Demo里不会遇到的脏数据、意外输入和需求变化这些麻烦才是真正教会你Agent开发的老师。记住跑通Demo只代表你理解了处理意外才算你真的能用。
