AI Agent 学习路线目录AI Agent 学习路线1.第一步Prompt Function Calling2.第二步建立 Agent 认知2.1.LLM为告诉你怎么完成2.2.Agent是帮你完成2.3.Agent 至少要有四个能力1. 规划知道任务要怎么拆2. 工具能连接外部世界3. 执行一步一步把任务跑完4. 反馈看结果再决定下一步2.4.Agent 和 Workflow的差异2.5.Agent 是一套系统2.6.面试官可能会问3.第三步Agent 设计模式3.1.ReAct3.2.Reflection1. 结果容易有格式错误2. 任务有明确验收标准3. Agent 容易过早交付3.3.Plan3.4.如何选择3.5.面试官可能会问4.第四步Agent vs Workflow4.1.Workflow4.2.Workflow Agent4.3.面试官可能会问1.第一步Prompt Function Calling请看【LLMAI应用开发 八股文】--2.Prompt与调用基础-CSDN博客的2、7章节2.第二步建立 Agent 认知Agent到底是什么和普通大模型问答有什么区别2.1.LLM为告诉你怎么完成先别急着定义 Agent我们从最熟的普通问答说起。普通大模型问答是什么就是用户输入一句话模型根据上下文生成一段回复。比如你问帮我解释一下 Redis 为什么快模型会回答Redis 快主要因为它基于内存、单线程避免锁竞争、使用 IO 多路复用、数据结构高效……这就是典型的大模型问答。它可以很聪明可以讲得很细也可以帮你写代码、改简历、总结文章。但它有一个核心特点它主要是在生成文本。你让它讲 Redis它讲给你听。你让它写 SQL它把 SQL 写出来。你让它分析日志它只能基于你贴给它的日志分析。这类系统的交互方式很简单用户给问题 - 模型生成答案 - 用户继续追问。整个过程中模型大多数时候没有真正动手。它不知道你的数据库现在有什么数据不会自己去查监控不会自己打开系统后台不会自己执行脚本也不会在发现第一步失败后自动换方案。所以普通问答更像一个知识很强的顾问。它能给建议但行动还得你来做。2.2.Agent是帮你完成Agent 的关键不是更会说而是更会做。这句话很重要。普通问答的核心产物是答案。Agent 的核心产物是完成任务的过程和结果。举个例子。你对普通大模型说帮我分析一下这个网站为什么最近转化率下降。如果是普通问答它可能会给你一套分析思路看流量来源有没有变化看页面加载速度有没有变慢看按钮点击率有没有下降看最近有没有改版看用户反馈里有没有负面信号这些建议可能都对但你还是要自己去查数据。如果是一个真正的 Agent它应该能做更多事先拆解问题转化率下降可能来自流量、页面、价格、性能、用户路径。调用数据工具查最近 30 天 PV、UV、点击率、跳出率、支付转化。调用日志工具看接口延迟、错误率、页面加载耗时。对比历史数据找出异常时间点。生成初步结论比如移动端支付页加载时间从 1.2 秒涨到 4.8 秒。继续验证查看是否和某次发布有关。最后输出结论和建议哪个环节出问题证据是什么下一步怎么修。你看这里已经不是回答问题了。它是在围绕一个目标自己决定下一步做什么并不断根据结果调整。这才是 Agent 的味道。2.3.Agent 至少要有四个能力先记住这四个能力规划、工具、执行、反馈。没有这四个东西很多所谓 Agent 其实只是披了个名字。1. 规划知道任务要怎么拆用户给 Agent 的往往不是一个简单问题而是一个目标。帮我整理一下这个仓库的技术债并给出优先级。这不是一句话能答完的。Agent 需要先拆任务先看项目目录再看核心模块再看最近提交再找重复代码、复杂函数、缺测试的地方再判断哪些问题影响最大最后整理成报告这一步就是规划。没有规划Agent 就会变成想到哪做到哪。很多 Agent 翻车就是因为计划不稳定一开始说要检查测试跑着跑着忘了一开始说要分析全仓库最后只看了两个文件就开始总结。2. 工具能连接外部世界没有工具Agent 很多时候只能会说不会做。工具可以是搜索工具数据库查询工具文件读写工具代码执行工具浏览器工具业务 API发邮件、发消息、创建工单的接口工具的意义是让模型从文本生成器变成能操作环境的执行者。比如用户问帮我查一下昨天订单失败最多的原因。普通问答只能说你可以从支付失败、库存不足、风控拦截几个方向排查。Agent 应该能调用订单数据库查失败码分布再调用日志系统看异常接口最后给出真实结论。这就是 Function Calling / Tool Use 为什么重要。它不是 Agent 的附属能力而是 Agent 行动能力的入口。3. 执行一步一步把任务跑完会规划不等于会执行。很多模型特别擅长列计划第一步收集数据第二步分析问题第三步输出报告。听起来很完整但真正执行时就散了。因为执行不是写计划而是把每一步真的做完。比如查数据库失败怎么办工具返回为空怎么办某个接口超时怎么办发现数据不够要不要换一个工具继续查这些都属于执行过程。真正的 Agent需要能在执行中处理分支而不是只按一张固定清单往下走。4. 反馈看结果再决定下一步Agent 和普通程序最大的区别之一是它会根据中间结果调整动作。比如它先查订单失败原因发现失败最多的是支付超时。那下一步就不应该继续查库存而应该去查支付接口延迟、第三方支付回调、网关错误日志。这就是反馈。它的基本循环是思考 - 行动 - 观察结果 - 再思考 - 再行动。很多人听过 ReAct其实就是这个思路。Reasoning 是思考Acting 是行动中间靠 Observation 把工具结果带回来。一个简单判断它有没有自己决定下一步怎么判断一个系统是不是 Agent我给一个很实用的判断标准看它有没有在任务过程中自己决定下一步做什么。如果它只是固定流程用户输入问题系统检索知识库模型总结答案返回给用户这更像 RAG 问答不一定是 Agent。如果它是用户给一个目标模型判断需要先查知识库查完发现信息不够又决定查数据库数据库结果异常又决定调用日志工具根据日志继续定位问题最后生成结论这就更像 Agent。因为它不是在机械执行固定流程而是在根据任务状态做动态决策。这里要注意不是用了大模型就叫 Agent。也不是用了 Function Calling 就一定叫 Agent。如果工具调用路径完全固定没有开放决策那它可能只是一个带工具的 Workflow。Agent 的核心是目标驱动 动态决策 外部行动 反馈迭代。这四个词面试时可以直接说。2.4.Agent 和 Workflow的差异Agent 和 Workflow 很容易混。Workflow 是工作流。它适合流程明确、步骤稳定、规则清楚的任务。比如发票审核OCR 识别发票提取金额、税号、日期校验字段调用财务系统入账返回审核结果这个流程很固定用 Workflow 就很好。你不需要让模型每次自由发挥我想想接下来要不要入账。那太危险了。Agent 适合什么适合任务开放、路径不固定、需要中途判断的场景。比如帮我定位线上接口变慢的原因。这个任务没有固定路径。可能是数据库慢可能是缓存击穿可能是某个服务发布导致可能是第三方 API 超时。你没法提前写死每一步。这时候 Agent 的价值就出来了它可以根据查到的现象决定下一步查哪里。所以别神化 Agent。能用 Workflow 稳定解决的问题就不要硬上 Agent。Agent 的自由度更高但不代表更可靠。自由度越高越需要约束、评估、权限控制和失败恢复。2.5.Agent 是一套系统这点很容易被忽略。很多人说我用了 GPT-5所以我做了 Agent。模型只是 Agent 的一部分。一个完整 Agent 系统通常至少包括模型负责理解、推理、生成Prompt定义角色、目标、边界工具连接外部系统执行器真正调用工具、处理返回结果状态管理记录当前任务进度记忆系统保存跨轮信息评估机制判断做得对不对权限控制限制能做什么、不能做什么失败恢复出错后能不能重试、回滚、停止所以 Agent 不是一个更强模型。它更像一个围绕模型搭起来的工程系统。模型负责思考但系统负责让它安全地行动。这也是为什么同样用一个模型不同团队做出来的 Agent 效果差很多。差距往往不在模型本身而在工具设计、上下文管理、执行编排、评估观测这些工程细节。2.6.面试官可能会问如果面试官问你怎么理解 Agent不要只回答Agent 是智能体可以自主完成任务。这句话太虚了。你可以这样回答我理解的 Agent不是单纯的大模型问答而是一个围绕目标持续行动的系统。它会根据用户目标进行任务规划选择合适的工具调用外部环境执行中观察工具返回结果再决定下一步动作。普通 ChatBot 主要是生成回答而 Agent 更强调行动、反馈和迭代。它的核心不是模型更聪明而是系统具备规划、工具调用、执行编排和状态反馈能力。这个回答就比较稳。如果面试官继续问那 Agent 和 Workflow 有什么区别你可以补一句Workflow 更适合步骤固定、规则明确的任务Agent 更适合路径不确定、需要动态决策的任务。工程上不是所有场景都应该上 Agent如果流程能写死用 Workflow 往往更稳定、更可控。这句话很加分。因为它说明你不是看到 Agent 热就硬套而是知道取舍3.第三步Agent 设计模式这三个词不是三套神秘框架而是三种很朴素的 Agent 做事方式ReAct边想边做看一步走一步Reflection做完回头看发现问题再改规划执行先拆任务再按计划推进重点不是背概念而是知道什么场景用哪种为什么面试官喜欢追问 ReAct。3.1.ReAct边思考边行动边观察ReAct 是 Agent 里最经典的一种思路。它的名字来自两个词Reasoning推理先想清楚下一步为什么这么做Acting行动调用工具或执行动作但只记这两个还不够。ReAct 真正关键的是中间还有一个 Observation观察。也就是工具执行后的观察结果。一个典型 ReAct 循环长这样Thought我现在需要知道什么Action我要调用哪个工具Observation工具返回了什么Thought根据结果我下一步该做什么举个例子。用户问“帮我定位接口/api/pay昨天晚上为什么变慢。”ReAct Agent 可能这样跑Thought先看接口延迟曲线确认变慢时间段。Action调用监控查询工具查询/api/pay昨晚 P95 延迟。Observation22:10 后 P95 从 300ms 涨到 3.8s。Thought需要看这个时间点有没有发布。Action调用发布记录工具。Observation22:05 发布了支付服务 v2.3.1。Thought继续查错误日志和下游接口耗时。Action调用日志工具。Observation第三方支付回调超时明显增加。你看ReAct 的特点很明显它不要求一开始就把完整计划想完而是每拿到一个结果再决定下一步。这就是为什么 ReAct 特别适合工具调用场景。因为真实环境里你一开始根本不知道问题在哪。你只能查一步看一步再决定下一步。ReAct 适合路径不确定的任务但必须配合步数限制、工具权限、状态记录和停止条件。3.2.Reflection不是让模型自嗨而是让它检查结果Reflection 翻译过来叫反思。很多人一听反思就以为是让模型输出一句“我再仔细检查一下。”这没用。模型说自己检查了不代表真的检查了。Reflection 的核心不是一句提示词而是给 Agent 一个明确的检查环节。比如 Agent 写完一段 SQL不要直接交付。让它回头检查字段有没有写错WHERE 条件有没有漏是否会全表扫描返回结果是否符合用户目标再比如 Agent 生成一份问题分析报告也不要直接交付。让它检查结论有没有证据支撑是否遗漏关键时间点是否把相关性当成因果建议是否能落地这才是 Reflection。它不是让模型“感觉自己更认真”而是让模型按照标准检查输出。1. 结果容易有格式错误比如结构化输出、SQL、配置文件、接口参数。模型第一次生成很可能看起来对但细节错。这时候加一个检查环节能拦住很多低级问题。2. 任务有明确验收标准比如单测是否通过JSON 是否符合 SchemaSQL 是否能执行报告是否包含指定字段简历项目是否包含四要素有标准Reflection 才有抓手。没有标准只让模型“反思一下”它很容易给你一段漂亮废话。3. Agent 容易过早交付很多 Agent 的问题不是不会做而是做了一半就开始总结。Reflection 可以在交付前加一道门当前结果是否已经满足用户目标如果不满足还缺什么证据是否需要继续调用工具这个检查能把“半成品交付”挡住一部分。但 Reflection 也有边界。如果模型本身不知道正确答案长什么样它反思十遍也没用。比如让模型判断一个线上故障根因它没有日志、没有监控、没有发布记录只靠自我反思最后还是猜。所以 Reflection 最好和工具、规则、测试、评估一起用。不要把它当玄学许愿。3.3.Plan规划执行先拆任务再推进Plan-and-Execute。它的逻辑很简单先让模型根据用户目标生成一个计划。然后再按计划一步一步执行。比如用户说“帮我分析这个仓库的技术债并给出优先级。”如果用规划执行Agent 不能一上来就随便翻几个文件。它应该先生成计划了解项目结构和技术栈。找核心模块和高频变更文件。检查复杂函数、重复代码、缺测试模块。结合影响范围评估优先级。输出技术债清单和修复建议。然后再执行每一步。规划执行的优点是任务更有方向不容易一开始就跑偏。尤其适合复杂任务。比如代码库分析竞品调研数据分析报告多文件重构长文档整理面试题系统总结这些任务如果完全靠 ReAct一步一步临时想容易走散。先规划再执行会稳很多。计划不是不可修改的剧本而是可更新的任务清单 当前假设集合。 每执行完一个子任务收集观测结果、更新任务状态校验支撑当前计划的假设是否仍然成立如果假设被证伪、目标路径变化触发重规划调整后续任务保留已经验证有效的成果不是全盘推倒重来。3.4.如何选择举个真实一点的例子。用户说“帮我定位线上支付接口变慢并给出修复建议。”比较稳的 Agent 设计应该是先规划确认要查监控、日志、发布记录、下游依赖。中间 ReAct根据每次查询结果决定下一步查哪里。最后 Reflection检查结论是否有证据建议是否对应根因。这就比单独讲某一种模式更成熟。因为真实任务不是教科书。它不会乖乖按照某个模式走完。3.5.面试官可能会问面试官问你怎么理解 ReAct不要只说“ReAct 是 Reasoning and Acting。”可以这样答“ReAct 是一种让 Agent 在推理和行动之间循环的设计方式。模型先判断当前需要什么信息再选择工具执行拿到 Observation 后再决定下一步。它适合故障排查、数据查询这类路径不确定的任务。工程上要注意限制步数、记录状态、设置停止条件否则容易跑偏或陷入无效工具调用。”面试官问Reflection 有什么用可以这样答“Reflection 不是简单让模型‘再想想’而是在交付前增加一个检查环节。它要基于明确标准检查结果比如格式是否符合 Schema、结论是否有证据、任务目标是否完成。如果没有外部标准或工具结果Reflection 容易变成模型自我安慰所以最好结合测试、规则和评估机制使用。”面试官问规划执行Plan和 ReAct 有什么区别可以这样答“规划执行Plan更强调任务开始前先拆解步骤适合复杂长任务ReAct 更强调执行过程中根据观察结果动态决策适合路径不确定的任务。实际项目里一般会组合使用先做粗粒度规划中间用 ReAct 调工具推进最后用 Reflection 做交付前检查。”这套回答基本够用了。4.第四步Agent vs Workflow不是所有任务都需要 Agent。很多场景硬上 Agent反而是在给系统制造不稳定。这篇就专门讲一个面试和项目里都很常见的问题Agent 和 Workflow 到底怎么选什么时候根本不需要 Agent主题别盲目上 Agent能写死流程的场景优先 Workflow4.1.Workflow先说结论流程能写死就优先 Workflow不少人有个误区Workflow 是低级方案Agent 才更高级。 这个理解不对。Workflow 并不比 Agent “低一等”在大量生产场景里Workflow 反而更可靠。什么是 Workflow 简单讲步骤固定、规则明确输入输出可预期的流程编排。举个例子发票审核。OCR 识别发票图片提取金额、税号、开票日期校验字段合法性调用财务系统入账返回审核结果整个链路清清楚楚先做什么、后做什么、异常如何兜底都可以提前定义。 这种场景完全没必要交给大模型自由思考“我想想下一步要不要入账”。 财务场景追求的不是灵活而是稳定、可审计、可回放、可控。原则一句话如果业务流程可以稳定写死优先选 Workflow不要硬上 Agent。2.Workflow 解决的是「按固定步骤稳定执行」Workflow 的核心价值是把业务逻辑编排成一条可控执行链路。 它关心这些事情每一步执行什么动作每个节点依赖哪些前置输入节点失败如何重试、降级哪些分支需要人工审批介入全链路日志、状态记录方便追踪客服退款流程就是典型带分支的 Workflow 用户提交退款申请校验订单是否存在判断是否在退款时效内判断商品是否发货未发货自动退款已发货流转人工审核写入退款记录通知用户虽然存在分支判断但它依旧是 Workflow。 因为分支条件是确定规则写死在代码里超过 7 天不可退、已发货转人工…… 如果交给 Agent 去解读业务规则反而引入风险模型可能误读规则、边界 case 幻觉。 Workflow 的优势就是规则一旦固化每次执行都严格一致不会随机发挥。1.Agent 的核心价值路径未知的动态探索决策Agent 的真正价值只存在于目标明确但执行路径无法提前穷举的场景。线上故障排查、业务数据下跌分析等场景根因多种多样事前无法预判排查顺序只能边执行、边观察、边决策。这类场景中Workflow 完全无法适配而 Agent 可以通过 ReAct、动态规划执行的能力根据实时观测结果动态调整后续工具调用和排查步骤完成开放式探索任务。这里纠正一个关键误区有分支≠需要 Agent。规则固定的分支是业务逻辑归 Workflow只有执行中才会出现、无法提前定义的未知分支才需要 Agent 动态决策。2.过度 Agent 化是项目翻车的核心原因盲目追求智能化把简单确定性流程包装成 Agent是工程最大的坑会带来四大硬伤1.成本更高Workflow 仅需简单接口调用Agent 需要多轮模型推理工具调用消耗大量 Token2.延迟更高多余的意图解析、规划、总结链路严重影响用户体验3.稳定性更差模型动态决策存在不确定性容易选错工具、执行跑偏高风险业务无法兜底4.排查更难Workflow 节点日志清晰可定位Agent 推理链路黑盒多调试成本极高。先问自己这件事能不能画成固定流程图。4.2.Workflow Agent最稳的方案往往是 Workflow Agent真实项目很少简单二选一。生产上更靠谱的方案是混合架构外层用 Workflow 守住主流程仅把少数开放节点交给 Agent。智能工单就是典型例子。 主流程走 Workflow接收工单、判断工单类型、分配处理队列、处理完成通知用户、记录结果。主链路必须稳定。 而「分析工单根因」节点交给 Agent。工单问题各不相同有的查日志、有的查订单、有的看用户行为、有的查上线记录没法预先写死排查路径适合动态探索。核心思路Workflow 管控边界与主流程Agent 做开放问题求解。不要让 Agent 接管整个系统只在真正需要动态判断的地方使用同时拿到稳定性和灵活性。4.3.面试官可能会问面试官问Agent 和 Workflow 有什么区别“Workflow 适合步骤明确、规则稳定、可提前编排的任务核心是稳定执行Agent 适合目标明确但路径不确定、需要中途观察结果并动态决策的任务核心是探索和调整。工程上不是所有场景都要用 Agent如果流程能写死用 Workflow 更稳定、更便宜、更容易审计。”面试官问你们项目里为什么不用纯 Agent“因为纯 Agent 的自由度太高成本、延迟和不确定性都会上升。我们一般把主流程放在 Workflow 里保证权限、状态流转和异常处理可控只有在路径不确定的节点比如故障定位、原因分析、复杂数据查询才让 Agent 调工具动态判断。”面试官问怎么判断一个场景该不该上 Agent“我会先看流程能不能提前画清楚。如果步骤固定、分支规则明确就用 Workflow如果路径无法提前穷举需要根据中间结果不断调整下一步才考虑 Agent。同时还要看风险、成本、延迟和可解释性要求不能为了技术热度硬套 Agent。”这套回答就比较稳。它说明你不是只会追热点而是知道工程取舍。