1. 为什么第13课是整个Agent课程体系的分水岭做了这么多年Agent开发也带过不少从零起步的学员我越来越确定一件事30课体系里最难讲的不是最后那些高并发架构、多智能体协作反而是第13课这种概念扫盲框架选型的中间课。往浅了说学员会觉得你在念文档往深了说学员还没写过几行Agent代码你讲底层原理他们根本接不住。但这个位置又极其关键。按我设计的课程节奏前12课基本完成了两件事一是让学员搞清楚大模型API怎么调、提示词工程怎么写、工具调用Function Calling怎么接二是让学员用裸代码跑通了一个能回答问题、能调工具的最小Agent demo。到这个阶段学员普遍会有一种好像懂了但又说不清的感觉——他们能写出能跑的代码但你说Agent框架HarnessSkill他只能跟着热搜词走脑子里全是浆糊。所以我在第13课做了一个明确的转向从教怎么写代码切换到教怎么看清楚一个Agent系统。这课的目的不是让学员多学会几个API而是帮他们在脑子里搭出一个Agent系统的全局地图。有了这张地图后面学记忆机制、多智能体编排、安全防护才不会觉得是在学一堆孤立的知识点。第13课放在这个位置还有一个原因课程进度到了一半学员的学习动力开始分化。一部分人越写越兴奋另一部分人开始怀疑自己是不是不适合做Agent开发。这种时候如果继续堆砌技术细节只会让第二类学员更焦虑。把节奏放慢回过头用一节课把Agent到底是什么框架解决什么问题我应该学什么、不学什么讲透反而能帮不少人重新找到方向感。这一课我用了一个贯穿始终的类比Agent开发不是写一个函数而是组建一支小队。大模型是队员的大脑工具是队员手里的器械Skill是队员的肌肉记忆Harness是这支小队的作战指挥系统框架则是你把小队组织起来的编制制度。这个类比在后面讲具体技术点的时候反复被调用学员反馈说比直接讲概念好懂得多。2. 先花5分钟厘清五组高频烧脑概念我一直觉得Agent领域入门最大的障碍不是技术难而是概念太多、太容易混。网上搜Agent能搜出七八套互相打架的说法新手根本分不清谁对谁错。第13课的第一大段我专门用来处理五组高频混淆概念。每讲一组我都让学员先自己说理解我再纠正——这样印象才深。2.1 Agent是什么别再说Agent就是AI有个热搜词问得很直接agent是什么。但这类问题底下往往跟着几百条互相矛盾的答案。我在课上给出的定义比较朴素Agent是一个能感知环境、做出决策、采取行动并根据行动结果调整后续行为的自主系统。拆开来看就是四件事感知、决策、行动、反思。感知对应的是接收用户输入、读取工具返回结果决策对应的是由大模型根据当前状态决定下一步该调哪个工具、生成什么内容行动对应的是实际调用工具、执行动作反思对应的是根据执行结果修正判断、决定是否继续迭代。这个定义听着简单但能筛掉一大半所谓Agent项目——很多号称做Agent的产品实际上只是一个套了层皮的大模型聊天框只有感知和生成没有决策、行动、反思的闭环严格来说就是个Chatbot。弄清楚这个边界后面学什么都会顺很多。2.2 Skill和Agent的区别Skill是能力Agent是主体skill和agent的区别agent和skill的区别是出现频率特别高的组合也是学员最容易绕晕的地方。我在黑板上画了一张图左边一个圆圈写Agent圆圈里挂了好几个标签标签上分别写着Skill ASkill BSkill C。Skill是一个可以被调用的、封装好的能力单元。它可以是提示词模板、一段代码逻辑、一个外部API的封装甚至是一套完整的工作流定义。它本身没有自主性不会自己决定什么时候该用我需要外部有东西来调用它。Agent则是那个有脑子的主体。它负责理解目标、规划步骤、决定在什么场景下调用哪个Skill并根据调用结果推进任务。打个比方Skill是一把螺丝刀Agent是拿着螺丝刀的师傅。螺丝刀不知道自己该拧哪颗螺丝师傅知道。这也是为什么市面上有些项目叫Agent项目其实只写了几个Skill就拿出来卖——它们少了一个最关键的东西决策逻辑。2.3 Harness和Agent的区别Harness是骨架Agent是血肉这是热搜词里技术含量最高的一组harness和agent区别。Harness这个词在中文社区里翻译得很乱有人叫脚手架有人叫编排层还有人直接音译哈尼斯。我在课上的定义是Harness是Agent运行时的骨架它定义了Agent在每一轮迭代中先做什么、再做什么、异常了怎么办的固定流程。一个典型的Harness流程长这样初始化 → 接收任务 → 调用Planner规划 → 按计划调用工具或Skill → 观察执行结果 → 判断是否完成 → 未完成则回到规划/行动循环 → 完成则输出最终答案 → 清理资源这个循环本身不依赖具体某个大模型也不依赖具体的工具列表它就是一套执行框架。Agent的血肉模型选择、工具配置、Skill注入、提示词风格可以千变万化但骨架是稳定的。你换掉Harness等于把这个Agent的行为节奏整个换掉你换掉模型和工具只是换了表演者节奏还是那套。2.4 Agent框架和Agent编排不是一回事agent框架和agent框架与编排两个搜索词几乎形影不离但细究起来是两个层面的东西。框架Framework是一个开发工具集它给你提供了构建Agent需要的各种基础组件模型接入、工具调用协议、内存管理、日志系统等。你基于框架开发不用从零造轮子。编排Orchestration则是运行时的一种设计思想指的是多个Agent、多个工具、多个Skill之间怎么协同配合。举个例子——Spring AI Multi Agent这类项目就明显偏编排它解决的是我有好几个Agent分别负责需求分析、代码生成、代码审查它们之间怎么传递消息、怎么决定谁先上场的问题。而LangChain这类框架偏框架它给你提供了大量基础组件但具体怎么编排还是你自己搭。这个区别搞清楚了你去看项目文档的时候就明白该关注什么框架文档看组件、编排文档看拓扑。2.5 具身智能Agent热搜里的天花板具身智能agent能进热搜词说明这个话题已经从学术圈火到普通从业者视线里了。简单来说具身智能Agent指的是拥有物理身体的智能体它能通过传感器感知物理世界通过执行器机械臂、轮子、腿在物理世界里行动。它和纯软件Agent的核心差异在于两点一是感知和行动的维度变了不再只是读文本、返回文本而是处理图像、点云、力觉等多模态信号二是危险的代价变了——软件Agent调用API失败顶多报个错具身智能体控制机械臂夹错东西可能直接损坏工件。第13课不需要学员深入搞具身智能但我特意提它是为了让学员看明白Agent的核心逻辑感知-决策-行动-反思在所有形态的智能体里是通用的你学的这套思维方法未来不管做纯软件还是做硬件都不过时。3. Agent项目的实际构造从热搜词看真实需求第二个大段我带着学员做了一道很有意思的题不看任何技术文档只看全网热搜词反推大家真正需要什么样的Agent开发知识。这是我自己一直用的学习方法也推荐学员试试。3.1 热搜词里藏着的Agent开发学习路线我把相关的热搜词按学习阶段重新排列了一下得到了一条相当清晰的路径入门期什么是agent、agent是什么、ai agent开发、agent应用——这个阶段的人在解决它到底是什么、能做什么的问题。成长期agent框架、agent框架与编排、springai skill agent、spring ai multi agent——这个阶段的人在选型想搞清楚该用什么工具搭。进阶期agent记忆、agent安全、harness和agent区别、skill和agent的区别——这个阶段的人在解决具体工程问题开始关心系统的可靠性、记忆能力、安全性。冲刺期agent面试、ai agent 面试题、agent八股、python agent开发面试题——这个阶段的人在准备找工作需要把知识体系化应对面试提问。这条路线最让我感慨的是它跟正经的学科知识体系完全一致。先建立概念再学工具再做工程化深化最后体系化输出。也就是说哪怕你完全不看任何课程大纲只跟着热搜词按这个顺序学也能走出一条靠谱的Agent开发学习路线。3.2 Agent记忆这个项目为什么记不住事agent记忆能高频出现是因为几乎所有Agent项目做到第三个版本就会发现模型每轮对话都是失忆的它记不住十分钟前用户说过什么也记不住上午执行过的任务结果。所有人在做Agent时都会撞上这堵墙区别只是撞的时间早晚。我在课上把Agent记忆拆成三层来讲短期记忆当前会话内的上下文窗口。这个最直接说白了就是把聊过的内容塞进上下文里让模型能看到。问题也最明显token数量有限塞太多了又贵又慢。长期记忆跨会话的关键信息存储。需要一个外部存储介质可以是一个向量数据库、关系型数据库甚至就是一个JSON文件关键是Agent知道什么时候读取、什么时候写入。工作记忆执行当前任务过程中的临时状态比如我已经完成了第一步、正在等第二步的工具返回。这三层记忆之间需要一套存取策略来协调。比如短期快满了要不要摘要压缩长期信息用什么方式检索工作记忆的更新节奏是每步都写还是攒批写这些策略组合起来就是网上各种记忆系统的核心逻辑并不神秘。3.3 Agent安全越火越容易忽略的东西另一个高频词是agent安全。我在课堂上专门花了一节来讲这个问题因为我见过太多团队把Agent跑通之后就急着上线结果在不该出问题的地方出问题。一个可靠的Agent系统安全设计至少要覆盖五个层面层面关注问题常见威胁输入层用户输入是否可信提示注入、恶意指令工具层工具调用的权限边界越权调用、参数篡改数据层训练和推理数据是否安全敏感数据泄露、记忆投毒行为层Agent执行过程是否可控不可预期的连环操作审计层出了事能否追溯日志缺失、追踪断裂多数人最容易忽略的是工具层的权限边界。举个例子你开发了一个内部Agent它集成了发邮件的工具。如果你的鉴权设计松松垮垮任何一次工具调用都是一次权限授予——这是我给学员的底线原则。3.4 Agent路由识别节点一个极具工程价值的设计热搜词里有个很具体的条目在agent中路由识别节点。这应该是某篇技术文章或课程里的小节标题但它背后的思想值得单独讲一下。所谓路由识别节点就是Agent在流程中用来判断当前情况、决定下一步走向的节点。它是Harness循环里的关键一环也是图结构Agent设计落地的核心。我再给它加一个功能能感知当前模型的能力边界。复杂题交给强模型简单题交给便宜模型成本直接从十块钱降到一块钱。做路由识别节点有两个工程细节容易踩坑一、判断条件要设计得可观测。也就是说每条路由的触发理由要能被日志记录下来否则线上出了诡异问题根本没法排查。二、要有兜底分支。宁可多设计一个我也不知道走哪条的默认分支也别让路由节点强行从几个已知选项里硬挑一个。硬挑的结果往往是灾难性的——用错工具比不调用工具更糟。4. 框架选型视角为什么同一个需求能吵三天搜热词榜里框架相关的占了四个席位agent框架、agent框架与编排、springai skill agent、spring ai multi agent。框架选型这件事在Agent开发社区里讨论热度非常高几乎每个相关群里都出现过用框架A还是框架B的争论。4.1 框架解决的三类核心问题不管选哪个框架本质上都在解决下面三个问题问题一协议统一。模型调用、工具调用、数据返回的格式五花八门。一个好的框架把这些统一成一套标准协议让开发者的思维可以集中在业务上而不是天天跟JSON格式较劲。问题二流程编排。一个Agent的完整执行通常包含多轮思考→行动→观察的循环中间还有条件跳转、分支逻辑、异常处理。用手写while循环当然也能实现但代码会越写越乱。框架提供了现成的编排原语让流程结构清晰可维护。问题三生态集成。Agent不是孤岛它要接数据库、接消息队列、接监控系统、接各种SaaS工具。成熟框架往往带了丰富的连接器Connector开箱即用。4.2 Skill与框架的搭配默契springai skill agent、agent和skill的区别这类词频繁出现说明大家在用框架时经常会碰到一个问题框架提供了一个技能机制但很多人不知道该往里装什么。我先纠正一个误区——Skill不是简单的提示词。把你是英语老师塞进系统提示词不算Skill。一个合格的Skill至少包含三个部分调用说明这个Skill是干什么的适合什么场景不适合什么场景。执行逻辑具体怎么做是走提示词模板还是调用外部服务。输入输出协议期望接收什么格式的输入返回什么格式的结果。之所以强调输入输出协议是因为如果每个Skill的输入输出格式都随心所欲Agent的调度逻辑就没办法统一处理它们。我自己带团队时甚至要求Skill必须有明确的Schema定义哪怕是一个简单的JSON也有约定这才让后面的路由节点写起来轻松很多。4.3 该不该把多个Agent串起来Multi-Agent的正确打开方式spring ai multi agent能上热搜代表很多人的项目已经复杂到一个Agent不够用的程度了。我在课上给出的判断标准很直接先问自己一个问题——你的任务是不是真的一次生成就能完成如果是那就用单个Agent几个Skill解决没必要上Multi-Agent。多Agent带来的维护成本、协调开销、错误传播会压垮一个小团队。如果任务确实需要多阶段协作、工单流转、不同角色有不同权限那Multi-Agent才是对的方向。拿一个有代表性的场景——代码生成举例需求Agent负责把用户模糊的表述翻译成清晰的需求文档它要访问需求模板库。编码Agent基于需求文档生成代码它要调用代码解释器、访问代码规范库。审查Agent对生成代码做质量审查发现Bug和安全隐患。重构Agent根据审查结果做有针对性的修复。四个Agent之间形成一条流水线每个节点有明确的输入和输出。这种设计的一个关键点在于每个Agent都要做好防御式消费——接收上游传来的结果时先校验格式和合理性再往下推进。因为上游一旦出错错误会在流水线里层层放大最终产物会烂得离谱。4.4 工具选型的一个笨办法框架之争很难有一个绝对答案因为不同团队的技术栈、任务类型、部署环境都不同。我给出的建议不是选某某而是一个笨但有效的选择办法用一张纸列出你项目的三个核心需求然后分别为每个候选框架打分满足3分、部分满足2分、不满足0分。总分最高的不一定是最强的但一定是最适合你当前需求的。这个方法上榜的时候学员通常会笑——太朴素了。但朴素的方法往往最实用。很多人选型纠结的根本原因不是技术不够而是没有把自己的需求写清楚。需求清楚了答案自然就浮出来了。5. 前端转Agent开发从看得见到有逻辑的能力跃迁热搜词里有一句很打动我的话前端转agent开发。看到这个词的时候我就知道背后一定站着一群正在试图转型的前端工程师。我身边也有不少这样的朋友所以第13课专门留出一节聊前端同学怎么走这条路最顺。前端工程师做Agent开发其实有一个隐性优势前端的交互设计思维在处理Agent与用户之间的边界时特别有用。很多Agent项目失败不是模型不够聪明而是不知道什么时候该问用户、什么时候该自己行动。懂交互的人天然有这种分寸感。但前端转Agent开发也有三个明显需要补的短板短板一逻辑链的设计能力。前端代码大多是事件驱动的用户点了按钮触发一个动作更新一个界面。而Agent的逻辑是循环驱动的观察-思考-行动-再观察。这个循环思维需要刻意练习。否则写的Agent代码容易写成一次性脚本做完一步就不知道下一步干什么。短板二服务端与数据流的概念。前端转过来的同学对远程API的概念很熟但对消息队列任务调度状态持久化这些服务端概念往往陌生。而Agent项目如果要上生产环境这些绕不开。不需要精通但至少要看得懂架构图知道哪一块是干什么的。短板三对模型能力的正确认知。很多新接触Agent的开发者会把大模型想得太强或者太弱。太强的人觉得丢给模型什么都能做太弱的人觉得模型只能做聊天。真实情况是大模型像一个记忆不太好但悟性很高的实习生你把上下午的规范讲清楚它能干得漂亮你语焉不详它给你交一堆似是而非的东西。给转型同学的学习路线建议我一般压缩成三步第一步用一周时间把感知-决策-行动-反思循环亲手实现三遍可以用最简单的Python脚本不依赖任何框架。目标是彻底内化这个循环思维。第二步选一个主流框架把官方文档里的Agent示例跑通然后改造它加一个自定义Skill。目标是掌握在框架里做扩展的能力。第三步做一个端到端小项目比如自动整理邮件并生成周报的Agent把路由、工具调用、记忆和错误处理都串起来。目标是体验完整工程链路。这三步走完基本就站到了Agent开发的门内。6. 关于Agent八股背题没用但答案里要有逻辑agent八股、agent面试题、python agent开发面试题这几个热搜词放一起说明求职季真的来了。我自己也当过面试官面过不少自称精通Agent开发的候选人说实话我对八股式回答的态度是背题没用但如果连八股基础都没有那说明系统知识根本没建立起来。一个典型的agent面试问题长这样请解释ReActReason Act和Plan-and-Execute两种Agent执行范式的区别以及各自的适用场景。很多背了八股的候选人能流利地把两个范式背出来ReAct是边想边做每一步都要观察结果、调整下一步适合需要灵活应变的场景Plan-and-Execute是先计划再执行先把任务步骤拆好然后按步骤执行适合结构性强的任务。但当面试官追问你项目中为什么用Plan-and-Execute而不用ReAct时大多数人就露馅了。他们要的是你真正做过之后形成的判断对项目需求的评估、对成本与稳定性的权衡、对失败模式的预期管理。所以我给学员的建议很直白八股要背因为它帮你建立概念地图面试时确保你能听懂面试官在问什么。但更重要的是给自己准备为什么的答案——为什么这么设计为什么选这个方案踩过什么坑才决定换方案的这些才是面试官真正在看的东西。配合agent开发学习路线这个话题我还会问学员一句如果让你给另一个零基础的人讲Agent开发你会怎么讲讲不清楚的人往往自己也没真正学透。7. 第13课留给学员的一道思考题每课我都会留一道思考题第13课的思考题比较特别。我让学员回去做一件看似简单的事打开一个他们日常使用的Agent产品比如某个AI助手连续用五个不同难度的问题测试它然后记录哪些回答感觉顺滑自然哪些环节明显卡顿或者结果不对猜猜背后可能的系统设计是什么。这个作业的目的不是让学员真的去逆向工程别人的系统而是让他们换一个视角从使用者的直觉切换到设计者的思维。什么时候模型觉得应该调用工具而不是直接回答什么情况下系统会判定该转人工为什么同一个问题换一种问法结果差很多这些观察比背一百个概念更能建立起对Agent系统的敏感度。我一直觉得Agent开发的学习本质上不是学代码是学一种如何把复杂的、模糊的任务拆解成可执行的步骤并用自动化的方式去完成的思维方式。这个思维一旦建立具体用什么框架、用什么模型都只是顺手的事。第13课的终点其实也是学员从问什么是Agent到真正开始像一个Agent开发者一样思考的起点。